> Но ценой увеличения трафика на 10%, чудес не бывает. 1) Обычно даже больше чем на 10%.
2) На хороших линках можно "понизить градус" или вообще не пользоваться этим.
> Повторная же передача увеличивает трафик исключительно по необходимости.
С другой стороны, она дает penalty величиной в RTT канала сама по себе. В это время канал попросту бездействует. Просто потому что ремота еще не знает что пакеты вообще надо послать.
А тот миндфак который в TCP сделали к тому же восходит к временам диалапа и проч и умеет коллапсировать в совершенно идиотские величины задержек между повторными попытками.
И когда толпа гранд-комитет-нечто и ветеран-чтототам не может справиться с очевидными сетевыми проблемами, демонстрируя "designed by committee" в хучшем вид, корпы таки решат проблему и без их участия, сделав так чтобы для их юзерей все просто работало, а канали и оборудование не простаивали. Обратное ставит их на бабки.
> Конечно избыточность можно регулировать вплоть до нуля, но при превышении
> процента потерь всё равно потребуются повторные передачи.
FEC можно задизайнить под почти произвольный процент потерь. Просто процент оверхеда будет невкусный, но это может работать даже на односторонних линках. DVB-T и космические линки так и делают. В DVB видите ли зомбоящики передавать не умеют, а в космических линках - ну вон до марса пинг в 1 сторону 2 часа, чтоли по поводу чего перезапрос это минимум 4 часа канала вхолостую.
Простой пример: если слать по 10 одинаковых пакетов, потери 20% не такая уж и проблема. В среднем будет выпадать лишь 2 из 10 и в целом будет декодабельно. С очень редкими выпадениями. Это правда неэффективно, есть сильно более удачные идеи.
Кстати можно гонять FEC поверх FEC (interleaving) так что невозможность декода приведет не к недекодабельности вон того пакета, а к тому что после de-interleave декодированы все пакеты но в них в каждом побит допустим 10-й байт. С чем прекрасно справится "внутренний" FEC. CD-ROM так делает, по поводу чего кой-как живет даже с царапинами и довольно серьезным BER чтения.
> Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах.
Удачи в этом направлении для радиолинков всех мастей и направлений. Представляете, юзеры ща не хотят в кафушке к эзернету стыковаться. И едучи в поезде мувик посмотреть тоже так то мало кто отказался бы.
> К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам
> неизвестна причина потерь?
У настоящего congestion есть сопутствующие атрибуты - например рост RTT. Это можно пытаться детектить. Но вообще-то если где-то есть congestion, вот к нему и надо применить вон ту логику - как то устранить эту проблему, а не пытаться с ним сюсюкаться на уровне протоколов факапя десятки других юзкейсов.
> Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности,
> то потерь будет становиться всё больше и больше и больше.
Возможно, это вообще сойдет за фичу - ленивые админы и жадные провы наконец снимутся с ручника. Или потеряют кастомеров на своих бельевых веревках, и проблема решится другим методом.
