> Тут и вылезает главная причина увеличения PPS и проблема протокола - это сделано затем, чтобы уменьшить время между перепосылками при потере пакетов - дескать, при шейпинге в буфере модема лучше пусть место кончится для небольших пакетов, меньше перепосылать придется. Более того, BEP-0029 прямо заявляет:
> In order to have as little impact as possible on slow congested links, uTP adjusts its packet size down to as small as 150 bytes per packet. Using packets that small has the benefit of not clogging a slow up-link, with long serialization delay. The cost of using packets that small is that the overhead from the packet headers become significant. At high rates, large packet sizes are used, at slow rates, small packet sizes are used.
Комментарий прямо противоречит цитате. В цитате речь про serialization delay, а в комментарии про "меньше перепосылать". Совсем не одно и то же.
Насчет роста pps от фрагментации. Непонятно, как это утверждение совместимо с жалобами на посылку маленьких пакетов. Либо маленькие пакеты изначально, либо фрагментация MTU-sized или около того пакетов. Одновременно не бывает.
Стоны про 30-летнюю историю TCP тоже не кажутся мне состоятельными. Если уж эта тридцатилетняя история так священна для автора, то непонятно, как можно при этом упоминать DCCP в положительном ключе :)
> Спрашивается, зачем минимизация задержки приложению передачи файлов, ведь в TCP для bulk transfer через long fat pipe давно уже есть алгоритмы?
Объясняю. TCP с классическими вариантами congestion control реагирует на дропы. Т.е. пока он не зальет буфер доверху, и пакетики не начнут дропаться, TCP не притормозит (пока оставим AQM за рамками беседы). Очевидно, заливая буфер, bulk transfer over TCP будет вызывать buffering delay для интерактивного трафика. Цель uTP в частности и LEDBAT вообще - избежать такого поведения и позволить потоку притормаживать, как только buffering delay возрастает выше определенной величины, тем самым не сильно мешать интерактивному трафику.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2010-03-01 09:28 pm (UTC)> In order to have as little impact as possible on slow congested links, uTP adjusts its packet size down to as small as 150 bytes per packet. Using packets that small has the benefit of not clogging a slow up-link, with long serialization delay. The cost of using packets that small is that the overhead from the packet headers become significant. At high rates, large packet sizes are used, at slow rates, small packet sizes are used.
Комментарий прямо противоречит цитате. В цитате речь про serialization delay, а в комментарии про "меньше перепосылать". Совсем не одно и то же.
Насчет роста pps от фрагментации. Непонятно, как это утверждение совместимо с жалобами на посылку маленьких пакетов. Либо маленькие пакеты изначально, либо фрагментация MTU-sized или около того пакетов. Одновременно не бывает.
Стоны про 30-летнюю историю TCP тоже не кажутся мне состоятельными. Если уж эта тридцатилетняя история так священна для автора, то непонятно, как можно при этом упоминать DCCP в положительном ключе :)
> Спрашивается, зачем минимизация задержки приложению передачи файлов, ведь в TCP для bulk transfer через long fat pipe давно уже есть алгоритмы?
Объясняю. TCP с классическими вариантами congestion control реагирует на дропы. Т.е. пока он не зальет буфер доверху, и пакетики не начнут дропаться, TCP не притормозит (пока оставим AQM за рамками беседы). Очевидно, заливая буфер, bulk transfer over TCP будет вызывать buffering delay для интерактивного трафика. Цель uTP в частности и LEDBAT вообще - избежать такого поведения и позволить потоку притормаживать, как только buffering delay возрастает выше определенной величины, тем самым не сильно мешать интерактивному трафику.