> Комментарий прямо противоречит цитате. В цитате речь про serialization delay, а в комментарии про "меньше перепосылать". Совсем не одно и то же.
Нифига не противоречит: on slow congested links, uTP adjusts ... down. Во всяком случае, алгоритм работы у него именно такой - чуть что, начинает уменьшать размеры. Комментарий - он и до, и после цитаты, как бы.
> Либо маленькие пакеты изначально, либо фрагментация MTU-sized или около того пакетов. Одновременно не бывает.
Это к тому, что у него PPS в любом случае получается завышен - либо маленькие и так, либо (в случае проблем с MTU) большие начнут разбиваться.
> Стоны про 30-летнюю историю TCP тоже не кажутся мне состоятельными. Если уж эта тридцатилетняя история так священна для автора, то непонятно, как можно при этом упоминать DCCP в положительном ключе :)
Это не "священно", а банальное соображение по вылизанности - эволюционно хрень с большей историей наверняка более вылизана и устойчиво, чем нечто только что появившееся. На эту консервативную установку опирается здравый смысл любого нормального админа. Что тут же вылезшие проблемы у нового протокола и подтвердили. Вот если бы они обкатали изменения, согласовали всё с IETF, выпустили RFC и пропихнули изменения в промышленные TCP-стеки - было бы лучше. DCCP был сугубо для примера - это же юзерлэндное приложение, оно не сможет тот же ECN выставить/получить в заголовках IP, к примеру.
> пока он не зальет буфер доверху, и пакетики не начнут дропаться, TCP не притормозит (пока оставим AQM за рамками беседы). Очевидно, заливая буфер, bulk transfer over TCP будет вызывать buffering delay для интерактивного трафика. Цель uTP в частности и LEDBAT вообще - избежать такого поведения и позволить потоку притормаживать, как только buffering delay возрастает выше определенной величины, тем самым не сильно мешать интерактивному трафику.
А тут сразу несколько моментов. Во-первых, на этот счет в роутеры уже давно встраивают соответствующие алгоритмы шейпинга, начиная с RED. Вот там, у провайдера, он пусть на интерактивный и bulk и разделяется, чтобы одно другому не мешало. Во-вторых, реализация uTP - отличается от LEDBAT. Они даже собственной официальной спецификации-то не последовали, вообще пиздец. Ну и в-третьих: допустим даже, ничего этого у провайдеров не было, в теории всё гладко - но тогда почему на практике не так? Вот на http://forum.utorrent.com/viewtopic.php?pid=450764#p450764 сообщают, что при включенном uTP остальному трафику как-то плохеет.
no subject
Нифига не противоречит: on slow congested links, uTP adjusts ... down. Во всяком случае, алгоритм работы у него именно такой - чуть что, начинает уменьшать размеры. Комментарий - он и до, и после цитаты, как бы.
> Либо маленькие пакеты изначально, либо фрагментация MTU-sized или около того пакетов. Одновременно не бывает.
Это к тому, что у него PPS в любом случае получается завышен - либо маленькие и так, либо (в случае проблем с MTU) большие начнут разбиваться.
> Стоны про 30-летнюю историю TCP тоже не кажутся мне состоятельными. Если уж эта тридцатилетняя история так священна для автора, то непонятно, как можно при этом упоминать DCCP в положительном ключе :)
Это не "священно", а банальное соображение по вылизанности - эволюционно хрень с большей историей наверняка более вылизана и устойчиво, чем нечто только что появившееся. На эту консервативную установку опирается здравый смысл любого нормального админа. Что тут же вылезшие проблемы у нового протокола и подтвердили. Вот если бы они обкатали изменения, согласовали всё с IETF, выпустили RFC и пропихнули изменения в промышленные TCP-стеки - было бы лучше. DCCP был сугубо для примера - это же юзерлэндное приложение, оно не сможет тот же ECN выставить/получить в заголовках IP, к примеру.
> пока он не зальет буфер доверху, и пакетики не начнут дропаться, TCP не притормозит (пока оставим AQM за рамками беседы). Очевидно, заливая буфер, bulk transfer over TCP будет вызывать buffering delay для интерактивного трафика. Цель uTP в частности и LEDBAT вообще - избежать такого поведения и позволить потоку притормаживать, как только buffering delay возрастает выше определенной величины, тем самым не сильно мешать интерактивному трафику.
А тут сразу несколько моментов. Во-первых, на этот счет в роутеры уже давно встраивают соответствующие алгоритмы шейпинга, начиная с RED. Вот там, у провайдера, он пусть на интерактивный и bulk и разделяется, чтобы одно другому не мешало. Во-вторых, реализация uTP - отличается от LEDBAT. Они даже собственной официальной спецификации-то не последовали, вообще пиздец. Ну и в-третьих: допустим даже, ничего этого у провайдеров не было, в теории всё гладко - но тогда почему на практике не так? Вот на http://forum.utorrent.com/viewtopic.php?pid=450764#p450764 сообщают, что при включенном uTP остальному трафику как-то плохеет.