URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 40868
[ Назад ]

Исходное сообщение
"OpenNews: Несправедливость в современных механизмах контроля перегрузки TCP"

Отправлено opennews , 25-Мрт-08 11:29 
"Fixing the unfairness of TCP congestion control (http://blogs.zdnet.com/Ou/?p=1078)" - размышления на тему несправедливости в современных механизмах контроля перегрузки TCP. Например, P2P клиент может открыть 100 TCP потоков и свести на нет механизм управления перегрузкой, который рассчитан на единичные сессии.

URL: http://blogs.zdnet.com/Ou/?p=1078
Новость: http://www.opennet.me/opennews/art.shtml?num=14927


Содержание

Сообщения в этом обсуждении
"Несправедливость в современных механизмах контроля перегрузки TCP"
Отправлено Jet , 25-Мрт-08 11:29 
странные представления у аффтара о ограничении пользователя по трафику...

"Несправедливость в современных механизмах контроля перегрузки TCP"
Отправлено ZANSWER , 25-Мрт-08 13:15 
В чём странное то???:-\

"Несправедливость в современных механизмах контроля перегрузки TCP"
Отправлено nuclight , 29-Мрт-08 15:00 
Автор явно предвзято относится, забывает некоторые моменты и пиарит странное решение - то ли журналисты в своей манере, то ли проплачены интересы провадйеров.

1) Он почему-то рассматривает только одно направление - upload
2) P2P-клиенты - не единственные программы, использующие несколько соединений, браузеры можно отметить тоже, скажем.
3) Тот же упомянутый BitTorrent писали не дураки - он хоть и держит много открытых соединений, но выбирает из всего swarm'а наиболее быстрые 3-4 коннекта, их и использует одновременно, не более.
4) Congestion Control опять же при реальном заторе приведет к дропу пакетов из разных соединений, так что опять-таки все коннекты станут медленнее в конечном счете.
5) Менять TCP-стэки по всему миру? Кошмар, автор в башне из слоновой кости живет, видимо. Тут бы уже давно придуманные ECN (могущий решить проблему тоже, кстати) у всех целиком внедрить...
6) Самое главное: контроль недаром введен в рамках одного соединения - они могут быть на совершенно разные направления в интернете, со своими характеристиками. Предлагает схему для гашения скоркости у всех сразу. Теперь представим, что с машины идут через ближайший роутер пара коннектов в интернет и один - в соседнюю сеть, не через внешний канал роутера. В каком бы ни был дроп, при предложенной схеме машина уменьшит скорость по ВСЕМ соединениям - то есть пострадают и те соединения, которые могли бы работать быстрее. И это естественно - откуда клиентской машине знать о состоянии каналов? Это задача для роутеров.

В общем, ему там в комментах аргументы приводили, да всё без толку. В том числе и то, что задача сейчас прекрасно решается равномерным шейпингом канала по числу активно пользующих клиентов в текущий момент времени. И это - реальный путь, в отличие от клиентов, которые, к примеру, могут себе и не проапгрейдить стек, а использовать злонамеренно (что опять потребует мер со стороны провайдера).