seek для tcp-потока в условиях шейпинга

Пришла в голову такая идея: пусть сервер отсылает некотрый длинный поток данных по tcp, при этом клиент точно знает что первая половина данных ему не нужна, а вторая нужна как можно быстрее. При этом ограничение скорости определяется наиболее узким местом канала - шейпером у провайдера клиента (или технологией последний мили до клиента(модем)). Также, предполагая худшее, положим что протокол верхнего уровня тупой и не поддерживает seek (например http с отключённым range). Таким образом, единственная возможность получить данные второй части быстрее - это извращения на уровне tcp. А именно предлагается следующее: поскольку причиной того, что сервер отправитель отсылает данные с реальной скоростью канала клиента, а не быстрее является то, что клиентом установлен малый размер tcp-окна и что подтверждения о доставке от клиента приходят не слишком быстро.

Что будет, если клиент установит большое tcp-окно и на те данные которые ему не нужны, будет присылать подтверждения ранее их получения? Насколько я понимаю канал сервера на отдачу будет работать в полную силу и, поскольку канал клиента не может принять столько данных, часть (ненужных клиенту) входящих пакетов будет дропаться (или буферизоваться, но после переполнения буфера опять дропаться).

То есть получится, что первая часть потока будет пропущена "вникуда" на скорости канала сервера, после этого начнётся нормальная закачка нужных данных клиентом на его скорости.

Вопрос скорее теоретический, нежели практический, ибо сейчас ситуация модем + сервер без докачки уже малоактуальна. Однако всё же интересно узнать о том, насколько реалистично выглядит такая реализация "forward seek" для tcp, и какие могут быть проблемы? Возможно кто-то имел опыт с подобными приёмами тогда, когда это было действительно актуально на практике?