Фильтрация uTP (Torrent UDP) внутри PPTP GRE

[nuclight]

Краткое содержание: как отфильтровать uTP на FreeBSD в теме на Наге уже сказали, однако для случая пакетов внутри туннеля PPTP GRE решения не было, о чем здесь и будет рассказано, но сначала - предыстория.

У вас вдруг стал хуже работать Интернет?..

В конце 2008 года разработчики uTorrent собрались заменить транспортный протокол с TCP на UDP, реализовав поверх него свою прослойку под названием чTP - дескать, так будет эффективнее. Тогда же исследователь по имени Ричард Беннет заявил, что это будет полная жопа для всего Интернета - UDP менее 2% во всём трафике, он используется для приложений реального времени (игры, телефония) и для критически важного DNS, в общем, пострадают все, из-за отсутствия в нём нормального congestion control (обработки перегрузок сети). Разработчики на это ответили, что они сделают congestion control еще лучше, чем в TCP, и торрент станет даже меньше забивать каналы и мешать другим, чем сейчас. И включили по умолчанию новый протокол uTP в бета-версиях uTorrent 1.8 (правда, сначала только на прием). Время шло, обещанной жопы всея Интернета не было...
До этого февраля. Буквально в понедельник админы бывшего СССР начали спрашивать друг друга, у всех ли отмечено сильное возрастание нагрузки за последние дни. Таки да, оказалось у многих. Выяснилось, что месяц назад вышел uTorrent 2.0, у кучи народа вылезло окошко с предложением обновиться, и с начала февраля пошел рост PPS (нагрузки по пакетам в секунду), причем обратите внимание, не трафика. Много где оборудование к такому неожиданному повороту сюжета было не готово, и проблемы работы Интернета ощутили на себе все, не только "качки". Более того, не только оборудование провайдеров - у многих стали гнать домашние роутеры и ADSL-модемы (вот пост на Хабре на тему), хотя опять же человек может не связать обновление у себя uTorrent и начать обвинять провайдера.

Вот это обсуждение на nag.ru: http://forum.nag.ru/forum/index.php?showtopic=55025&st=160&p=478584
В этой теме было много интересного, например, такая проблема не только у нас, в Амстердаме тоже отмечают увеличение PPS за этот месяц. На этот топик понабежали "хомячки" после обсуждений на том же Хабре и даже на закрытом torrents.ru начали подозревать, что это связано с происками провайдеров. Там было найдено и решение - блокировать пакеты установления соединения поверх UDP по сигнатуре, она оказалась достаточно простая, приведены строки конфигов для разного железа. Надо отметить, что провайдеры имеют на это полное моральное право (потому что разработчики долбоебы, см. ниже), но есть и юридическое обоснование, в теме приведена выдержка из Постановления РФ по такому случаю. Кто-то даже предлагал привлечь разработчиков uTorrent по ст. 272-273 УК РФ (благо среди них есть русские) - за фактический DDOS на оборудование.

Нехрен выебываться, если не понимаешь в протоколах

Обнаружилось и много других интересных вещей, теперь по технической части. Во-первых, спецификация uTP на http://www.bittorrent.org/beps/bep_0029.html оказалась не той, что реально применяется сейчас - и разработчики uTorrent сказали кому-то в IRC, что сейчас ловят по одному из начальных значений, которое в будущем будет меняться, то есть приведенные решения в будущем перестанут работать. А учитывая, что количество обновляющихся на новую версию юзеров всё растёт... думаю, понимание принципов его блокировки еще пригодится, чтобы адаптировать способы.

Разработчиков спрашивали на форумах еще в прошлом году и критиковали за ряд решений. Более того, спецификация еще и не была доступна для публичного review, как это принято в нормальном случае разработки стандартов Internet. На http://forum.bittorrent.org/viewtopic.php?id=162 заметили, что реальные пакеты uTP не соответствуют спецификации, но ответа разработчиков пока нет. Но - они ж опробовали в локалке, и всё работало замечательно, хехе. К чему нам опыт 30-летней разработки TCP, который разрабатывался, заметим, учеными в университетах?.. Которые его отлаживали и исправляли до действительно массового внедрения на реальных ошибках - первый опыт перегрузки (meltdown) Сети был в конце 80-х. Суть введенных тогда механизмов congestion control (контроля перегрузок) - при отправке данных TCP-стек вашего компьютера постепенно "разгоняет" поток, до тех пор, пока принимающая сторона не сообщит, что часть пакетов не дошла. Тогда делается вывод, что канал забит полностью, надо немного понизить скорость (и такие проверки делаются постоянно, потому что маршруты в Интернете могут в любой момент измениться, и в канале могут еще находиться пакеты других пользователей). Со временем оно обросло сложной математикой (чтобы точнее и быстрее сходилось), оборудование у провайдеров также рассчитано на такое поведение TCP, все методы регулировки полосы и обеспечения качества связи это учитывают. А на UDP отклика от другой стороны нет, можно послать слишком много пакетов и "засрать" канал (причем не только себе), этот отклик придется делать вручную (фактически изобретая TCP заново).

У этого протокола есть ряд принципиальных архитектурных проблем, которые ведут к большому числу пакетов. Это мешает даже его непосредственной цели - улучшить скачивание. Например, на http://forum.utorrent.com/viewtopic.php?id=69592 отметили, что "uTP used 13130 packets, and TCP only 8499 (uTP used 55% more packets than TCP!)" - а это значит, что для файла того же размера трафика на TCP будет меньше.

Одна из ключевых проблем - поверх UDP эмулируется такой же потоковый протокол, как TCP, то есть, пакеты приложению должны приходить по порядку. Фактически, uTP - это во многом изобретение велосипеда, справедливо указывали, что можно было бы просто внедрить нужные механизмы в TCP (правда, это потребует апгрейд всех операционных систем, да). Но и без этого, протоколу передачи файлов, а особенно такому, как BitTorrent, совершенно неважно, в каком порядке передаются блоки файла, можно было бы в UDP это соптимизировать. Им предлагались решения получше. Я бы еще добавил туда DCCP - он, например, хотя бы ECN поддерживает, в отличие от.

Другая из проблем, увеличивающих PPS - это репакетизация и MTU. Максимальный размер пакета на Ethernet 1500 байт, в случае PPPoE (например, ADSL) - он будет уже 1492 байта. Если целый пакет "не пролезает" - без проблем, TCP нумерует байты, он может разбить их на два пакета так, что будет использован максимальный доступный MTU. Но в uTP нумеруются не байты, а пакеты. Это значит, что если был потерян пакет, то его нельзя разбить, надо перепослать его же целиком, иначе будет ошибка в нумерации. А если он не пролезает из-за MTU - его остается только фрагментировать на том роутере, где уменьшается. То есть, после такой точки в сети (а это типичный случай на том же ADSL, от компа до модема 1500, от модема до провайдера 1492) пойдет в два раза больше пакетов.

У TCP на это дело есть худо-бедно, но работающий механизм PMTUd, обнаруживает и подстраивается. Разработчики uTP решили, что можно им воспользоваться - если в ответ пришлют ICMP need-fragment. Но они не учли, что дофига где неграмотные админы блокируют на файрволах ICMP целиком, чем ломают этот механизм. Если у вас когда-нибудь была странная ситуация (особенно на ADSL), что одни сайты работают, другие ни в какую; или же короткие письма (комментарии в форму на сайт, etc.) пролезают, длинные нет - это вот оно. На этот случай производители кабельных модемов и всяких других решений уже давно делают "костыль" - проходящим TCP-пакетам автоматически правится MSS на поменьше. И для всех приложений, работающих по TCP, это прозрачно. Но здесь-то UDP... Вот им и остается уповать на фрагментацию, которая резко увеличит количество пакетов.

Далее, http://forum.bittorrent.org/viewtopic.php?id=131 сообщает, что "Acks are required for every packet". В TCP давно уже научились экономить на ответных пакетах, посылая их только когда надо, совсем не на каждый. А сделано это затем, чтобы как можно точнее измерять задержку между пакетами. Спрашивается, зачем минимизация задержки приложению передачи файлов, ведь в TCP для bulk transfer через long fat pipe давно уже есть алгоритмы?..

Тут и вылезает главная причина увеличения 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.

Другими словами, как только uTP обнаруживает потерю пакета вследствие шейпинга или достижения ширины канала, он начинает уменьшать размер пакета, что ведет к увеличению нагрузки, вследствие того еще большим потерям и дальнейшему уменьшению размера пакета, вот такая больная рекурсия. При этом и изначальный-то размер пакета невелик - всего 300 байт...

Но хватит о грустном. Решение для обычного не-туннельного уже применяют, теперь пришла пора сделать для случая PPTP.

Составим выражение для tcpdump...

В предыдущем посте я описывал принципы работы BPF. Когда увидел в теме на Наге просьбу аналога для PPTP, вспомнил, что у меня же была похожая задача, там же и описана. В самом деле, там искалось DHT, здесь просто другая сигнатура. Итак, назовём файл tcpdump-gre-utp-cpp и поправим:

#define IPHDRLEN(firstbyte) ((ip[firstbyte]&0xf)<<2)
#define GRESTART IPHDRLEN(0)
/* Check that is GREv1 with seq num and proto set per RFC 2637 */
#define VALID_PPTP_GRE ((ip[GRESTART:4] & 0xff7fffff) = 0x3001880b)
/* ACK is optional 4 bytes to previous 12 */
#define GRE_DATA_START (GRESTART + ((ip[GRESTART+1] & 0x80) >> 5) + 12)
/* Actual IP byte values to find in the UDP payload of inner IP datagram */
#define IS_TORRENT_UTP(udp_hdr_start)   (ip[(udp_hdr_start+20):4]=0x7fffffff)
/* Check inner IP has UDP payload (proto 17) then calculate offset and pass it to UTP macro */
#define INNER_IS_UDP(ppp_hdr_len)       (ip[GRE_DATA_START+ppp_hdr_len+9]=17)
#define INNER_UDP_OFFSET(ppp_hdr_len)   (GRE_DATA_START+ppp_hdr_len+IPHDRLEN(GRE_DATA_START+ppp_hdr_len))
#define INNER_IS_UTP(ppp_hdr_len)       (INNER_IS_UDP(ppp_hdr_len) and IS_TORRENT_UTP(INNER_UDP_OFFSET(ppp_hdr_len)))

/*
 * Finally, expression: sort by most frequent pattern first.
 * We check four possible PPP headers corresponding to IP, then
 * pass length of matched PPP header to checking macros.
 */
proto gre and VALID_PPTP_GRE and (
        (
                (ip[GRE_DATA_START]=0x21) and INNER_IS_UTP(1)
        ) or (
                (ip[GRE_DATA_START:2]=0xff03) and (ip[GRE_DATA_START+2]=0x21) and INNER_IS_UTP(3)
        ) or (
                (ip[GRE_DATA_START:4]=0xff030021) and INNER_IS_UTP(4)
        ) or (
                (ip[GRE_DATA_START:2]=0x0021) and INNER_IS_UTP(2)
        )
)

Засунем это дело в скрипт из предыдущего поста, и...

...и обламываемся

Не работает. Не матчит. Запуск tcpdump -Xs 0 -ni em0 `cpp -P tcpdump-gre-utp-cpp` тоже молчит. Значит, дело не в ng_bpf. Заменяю в итоговом выражении UTP на UDP - начинает ловить все UDP-пакеты в туннеле. Ага, значит дело в финальной части выражения. Делаю тестовый пакет, выкусываю комментариями лишние ветки - всё равно не матчит. Начинаю смотреть в tcpdump -d - там теперь всего 70 с небольшим инструкций, это уже поддается анализу человеком. Ага, таки да - обнаружен баг, tcpdump генерирует неверный код. Отправил баг-репорт (см. kern/144325), но эта бага практически наверняка есть и на линуксе - проект tcpdump отдельный...

Придется писать вручную
Что ж, придется применить знания по ассемблеру BPF и заняться тяжелым ручным трудом. Правда, имея перед глазами файл для препроцессора, перевести несколько проще, даже применяя оптимизации. Примерно 4 часа работы, включая отладку, и вот что получилось:

bpf_prog_len=36 bpf_prog=[
{ code=177 jt=0 jf=0 k=0 }          BPF_LDX+BPF_B+BPF_MSH   X <- 4*(P[k:1]&0xf)      ; X <- outer IP hdr length
{ code=64 jt=0 jf=0 k=0 }           BPF_LD+BPF_W+BPF_IND    A <- P[X+k:4]
{ code=84 jt=0 jf=0 k=0xff7fffff }  BPF_ALU+BPF_AND+BPF_K   A <- A & k
{ code=21 jt=0 jf=31 k=0x3001880b } BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; not VALID_PPTP_GRE, exit
{ code=80 jt=0 jf=0 k=1 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]            ; begin calc GRE hdr length
{ code=84 jt=0 jf=0 k=0x80 }        BPF_ALU+BPF_AND+BPF_K   A <- A & k
{ code=116 jt=0 jf=0 k=5 }          BPF_ALU+BPF_RSH+BPF_K   A <- A >> k
{ code=4 jt=0 jf=0 k=12 }           BPF_ALU+BPF_ADD+BPF_K   A <- A + k
{ code=12 jt=0 jf=0 k=0 }           BPF_ALU+BPF_ADD+BPF_X   A <- A + X               ; now A = GRE_DATA_START
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A
{ code=72 jt=0 jf=0 k=0 }           BPF_LD+BPF_H+BPF_IND    A <- P[X+k:2]
{ code=21 jt=0 jf=3 k=0xff03 }      BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; test PPP first part
{ code=135 jt=0 jf=3 k=0 }          BPF_MISC+BPF_TXA        A <- X
{ code=4 jt=0 jf=0 k=2 }            BPF_ALU+BPF_ADD+BPF_K   A <- A + k
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A                   ; now test 0x21 or 0x0021
{ code=80 jt=0 jf=0 k=0 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]
{ code=21 jt=0 jf=3 k=0 }           BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; test 0x00 (before 0x21)
{ code=135 jt=0 jf=3 k=0 }          BPF_MISC+BPF_TXA        A <- X
{ code=4 jt=0 jf=0 k=1 }            BPF_ALU+BPF_ADD+BPF_K   A <- A + k
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A                   ; that was 0x00, advance X
{ code=80 jt=0 jf=0 k=0 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]
{ code=21 jt=0 jf=13 k=0x21 }       BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; the final 0x21
{ code=135 jt=0 jf=3 k=0 }          BPF_MISC+BPF_TXA        A <- X
{ code=4 jt=0 jf=0 k=1 }            BPF_ALU+BPF_ADD+BPF_K   A <- A + k
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A                   ; now X points to inner IP
{ code=80 jt=0 jf=0 k=9 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]            ; protocol in inner IP
{ code=21 jt=0 jf=8 k=17 }          BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; UDP ?
{ code=80 jt=0 jf=0 k=0 }           BPF_LD+BPF_B+BPF_IND    A <- P[X+k:1]
{ code=84 jt=0 jf=0 k=0x0f }        BPF_ALU+BPF_AND+BPF_K   A <- A & k
{ code=100 jt=0 jf=0 k=2 }          BPF_ALU+BPF_LSH+BPF_K   A <- A << k              ; now A = inner IP hdr len
{ code=12 jt=0 jf=0 k=0 }           BPF_ALU+BPF_ADD+BPF_X   A <- A + X
{ code=7 jt=0 jf=0 k=0 }            BPF_MISC+BPF_TAX        X <- A                   ; now X points to inner UDP
{ code=64 jt=0 jf=0 k=20 }          BPF_LD+BPF_W+BPF_IND    A <- P[X+k:4]            ; imagine inner_udp[20:4]=
{ code=21 jt=0 jf=1 k=0x7fffffff }  BPF_JMP+BPF_JEQ+BPF_K   pc += (A == k) ? jt : jf ; ... = 0x7fffffff ?
{ code=6 jt=0 jf=0 k=65535 }        BPF_RET+BPF_K           accept k bytes           ; match, -s 65535
{ code=6 jt=0 jf=0 k=0 } ]          BPF_RET+BPF_K           accept k bytes           ; return 0 - non-match

Удалось уложиться всего в 36 инструкций, и без использования памяти BPF-машины. Стало быть, будет работать быстро. Правда, реализовывать проверку на то, что это пакет именно IPv4 и именно GRE, мне стало лень - да и это может сделать файрвол. Скрипты можно взять в предыдущем посте, хотя здесь они получатся меньше - tcpdump и awk не задействованы. Протестировал нижеследующими командами, работает:

# kldload ng_ipfw
# ngctl mkpeer ipfw: bpf 127 ipfw
# ngctl name ipfw:127 utp_filter
# ngctl name ipfw:127 pptp_utp_filter
# ngctl msg pptp_utp_filter: setprogram '{ thisHook="ipfw" ifMatch="matched" ifNotMatch="ipfw" bpf_prog_len=36 bpf_prog=[ { code=0xb1 } { code=0x40 } { code=0x54 k=4286578687 } { code=0x15 jf=31 k=805406731 } { code=0x50 k=1 } { code=0x54 k=128 } { code=0x74 k=5 } { code=0x4 k=12 } { code=0xc } { code=0x7 } { code=0x48 } { code=0x15 jf=3 k=65283 } { code=0x87 jf=3 } { code=0x4 k=2 } { code=0x7 } { code=0x50 } { code=0x15 jf=3 } { code=0x87 jf=3 } { code=0x4 k=1 } { code=0x7 } { code=0x50 } { code=0x15 jf=13 k=33 } { code=0x87 jf=3 } { code=0x4 k=1 } { code=0x7 } { code=0x50 k=9 } { code=0x15 jf=8 k=17 } { code=0x50 } { code=0x54 k=15 } { code=0x64 k=2 } { code=0xc } { code=0x7 } { code=0x40 k=20 } { code=0x15 jf=1 k=2147483647 } { code=0x6 k=65535 } { code=0x6 } ] }'
# sysctl net.inet.ip.fw.one_pass=0
# ipfw add 127 netgraph 127 gre from any to any via ng0
# ngctl msg pptp_utp_filter: getstats '"ipfw"'

Последняя строчка - снимает статистику. Вместо getstats можно еще использовать getclrstats - тогда оно выведет статистику и атомарно очистит её в ядре.

Ну и следует напомнить, что ввиду отличия спецификации от реальных пакетов, это всё временная мера - можно ожидать, что в будущем сигнатуры придется менять... и не спрашивайте меня, как - в предыдущем посте было достаточно теории по этому вопросу :)

Comments

[blacksun-rise.livejournal.com]

я внимательно прочитал ваши статьи ( кстати спасибо за детальную инфу про файервол на фрюхе ) но никак не могу настроить свой файервол
если вы уделите мне немного внимания ( я уверен пары минут хватит ) то с меня бочка пива

что есть:
компъютер на базе фрюхи (7.1) который работает как роутер для внутренних машин

цель:
1. открыть некоторые порты наружу
2. сделать транспарент прокси для 80го порта
3. все остальные исходящие коннекшины сделать через НАТ

что работает не так: НАТ работает странно, по ссшу доступ изнутре вовне есть, и доступ отличный, а вот 443 (хттпс) не работает... при чём телнетом конекчусь нормально но видимо какието пакеты дропаются
транспарент прокси работает отлично, открытые наружу порты тоже

правила:
// роутим все пакеты между собой и внутренней сетью
00010 123280187 43860442323 allow ip from 192.168.0.0/24 to 192.168.0.0/24 via em0
00010 30262427 4419819070 allow ip from me to me

// ДНС
00020 2879421 255313216 allow ip from me to any dst-port 53,80
00020 2857814 2854257706 allow ip from any 53,80 to me

// transparent proxy -- works ok
00030 2928586 180355566 fwd 127.0.0.1,3128 tcp from 192.168.0.0/24 to not 192.168.0.0/24 dst-port 80 in
00030 2170368 2480435184 allow ip from not 192.168.0.0/24 80 to 192.168.0.0/24 established

// это для VPN connections
00040 29727 13912834 allow ip from 192.168.0.0/24 to 192.168.1.0/24
00040 20944 1572610 allow ip from 192.168.1.0/24 to 192.168.0.0/24

/открытые наружу порты
00050 447299 35132628 allow ip from any to me dst-port 20,21,22,81,88,70,1194
00050 1008796 434221954 allow ip from me 20,21,22,81,88,70,3399,4455,3311,1194 to any
00060 539961 36710052 allow ip from any to me dst-port 3399 // тут все порты которые должны быть открыты наружу

// собсно чтобы мы могли отвечать всем кто пришёл на открытый порт
00075 363200 205586211 allow ip from me to any established

// четыре правила ниже отвечают за НАТ -- что я сделал нетак ??
00080 58290781 72322070391 divert 8668 ip4 from 192.168.0.0/24 to not 192.168.0.0/24 out via em0
00080 7768878 1203676023 divert 8668 ip4 from not 192.168.0.0/24 to me in via em0
00081 8277827 1730677456 allow ip from not 192.168.0.0/24 to 192.168.0.0/24 established
00081 117122141 144756711359 allow ip from 192.168.0.0/24 to not 192.168.0.0/24

// стандартные
00100 28406 2108876 allow ip from any to any via lo0
00100 3713557 309651612 deny ip from any to any
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any

[blacksun-rise.livejournal.com]

забыл добавить -- у сервера только один интерфейс em0
всё ходит через него

[nuclight.livejournal.com]

Так это у вас однорукий роутер, что резко меняет дело. Неясно, какой адрес там под "me", может, что-то пересекается в других правилах. Что такое "работает странно", тоже непонятно. Если дело только в 443, то, учитывая, что его в правилах нигде нет, возможно, что проблема вообще не в файрволе, а в MTU (фиксить MSS) - большие пакеты не пролезают (у ssh интерактивные обычно маленькие, если scp работать откажется, то может быть оно).

Всё же, такие вопросы лучше задавать где-нибудь типа ru_root - вас много, а я один. И по теме поста, а не произвольные.

[blacksun-rise.livejournal.com]

спасибо, задам там

[iskatel.livejournal.com]

uTP появился в том числе и как ответ на массовое нарушение договоров провайдерами, которые стали применять полисеры, задавливая определенный трафик и прямо нарушая таким образом договора с клиентами и законодательство (тк. они фактически вмешиваются в трафик пользователей).

Также хочется напомнить, что любые фильтры по сигнатурам - прямое нарушение договоров и законодательства.
Если оборудование горе-провайдера ложится - это проблемы горе-провайдера, пусть обновляет.

[nuclight.livejournal.com]

"Надо отметить, что провайдеры имеют на это полное моральное право (потому что разработчики долбоебы, см. ниже), но есть и юридическое обоснование, в теме приведена выдержка из Постановления РФ по такому случаю".

Если кому-то ссылки лень целиком читать, не мои проблемы. Ну и у любого грамотного оператора в договоре есть соответствующие положения, так что спорить об этом здесь нет никакого смысла, только демагогию разводить.

[l2tp.livejournal.com]

Посмотрите, пожалуйста, договор с провайдером. На наге прямо поминали
Постановление Правительства Российской Федерации от 10 сентября 2007 г. N 575 г. Москва "Об утверждении Правил оказания телематических услуг связи"
Опубликовано 25 сентября 2007 г.

Правил оказания телематических услуг связи
III. Порядок и условия исполнения договора

27. Оператор связи вправе:
приостанавливать оказание телематических услуг связи абоненту и (или) пользователю в случае нарушения абонентом и (или) пользователем требований, предусмотренных договором, а также в случаях, установленных законодательством Российской Федерации;
осуществлять ограничение отдельных действий абонента и (или) пользователя, если такие действия создают угрозу для нормального функционирования сети связи.

Другой вопрос, что это проблема провайдера, что незначительный прирост pps/bps "убивает" ему сеть

[kondybas.livejournal.com]

Рост пп/ц вдвое - это пц, а не "..незначительный прирост.."

[l2tp.livejournal.com]

Домокабельные сети?

Я у себя вообще не заметила ощутимого прироста, но у меня домашних торрентоводов мало, сосед, у которого в основном домашние пользователи, - тоже не увидел даже 50% прироста pps.

[kondybas.livejournal.com]

Мне вообще все это индифферентно. Я окучиваю мелко-средний биз, которому ставлю трансмиссию демоном с управлением через виндовый гуй. Но вот местные провайдеры оказались явно не готовы к скачку ппц. У людей есть многолетний тренд, инвестиционные и модернизационные планы, и тут - на тебе. Чтобы ублажить дебилов-разрабов нужно все похерить и вне графика вбухиваться в железы? Ага, щяс.

[andrewkochetkov.livejournal.com]

Это только bps растёт незначительно, а pps от *1.5 до местами *2.5. Резерв роста pps в полтора раза мало у кого есть.

[l2tp.livejournal.com]

Ну не видела я такого роста pps, везучая, да? :)

У меня сейчас на отдельно взятом роутере, на интерфейсе, что в клиентскую сторону смотрит, средний размер пакета порядка 765 байт на in и порядка 730 байт на out.

И запас по pps еще есть...

Я просто не видела пока что так, чтобы суммарно был огромный рост pps, все примерами приводят отдельно взятых личностей. Посмотри, у меня под постом с ссылками на этот сумасшедший дом dmarck оценил рост pps у себя примерно в 20-30%.

[andrewkochetkov.livejournal.com]

Ну, в 2.5 раза — это единичный случай, когда пошла цепная реакция и вообще всё раком встало :) Там админу пришлось временно выпилить почти весь udp трафик (кроме dns). Чуется, что масса хомячков-качков врубит шифрование мютипи — хотя таких последствий, конечно, не будет.

[l2tp.livejournal.com]

Тьфу ты, а то я уже думала, что живу в отдельно взятом заповеднике.

Ну, предположим, у меня структура трафика не та, чтобы сильно торрентов бояться, а вот соседа с его большими домосетками надо таки спросить, он собирался прикрутить каунтеры на uTP-трафик по описанному.

[http://users.livejournal.com/_dyr/]

У нас на тысячу клиентов после наложения фильтра pps упал на 40%

[dbg.livejournal.com]

> Тут и вылезает главная причина увеличения 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 возрастает выше определенной величины, тем самым не сильно мешать интерактивному трафику.

[nuclight.livejournal.com]

> Комментарий прямо противоречит цитате. В цитате речь про 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 остальному трафику как-то плохеет.

[http://users.livejournal.com/_blib/]

вообще то есть SCTP
http://en.wikipedia.org/wiki/SCTP

который давно работает, хорошо проработан и есть поддержка в основных системах (хотя вроде в винде он был потом убрали, не уверен...)

в SCTP есть разбивка по блокам (message based), и блоки могут идти в паралель (multistream), и для каждого из блоков можно указать сколько раз его нужно перепосылать
и пр и пр

[nuclight.livejournal.com]

Вы шо таки думаете, я не в курсе про существование SCTP ? Проблема в том, что его в винде вообще никогда и не было. Товарищи пробить изменения в реализациях TCP-то поленились, предпочли сделать велосипед, что уж говорить об отсутствующем протоколе...

поправочка

[dorowa.livejournal.com]

ipfw add 127 netgraph 127 gre from any to any via ng0
очевидно, здесь вместо ng0 здесь должен быть реальный интерфейс и лучше всего смотрящий в локальную сеть, на ng0 пакеты gre не приходят...

чего тут поправлять-то?

[nuclight.livejournal.com]

Любой, кто применять будет, и так догадается, что надо подставить тот интерфейс, где ходят. У меня в тестовой инсталляции они именно поверх ng0 ходили.

[dorowa.livejournal.com]

Ну, в принципе, да, согласен...
Наверное, не так начал предыдущий пост :)... Спасибо, статья прикольная, поддерживаю автора на все 100%, даже добавить нечего, все изложено как надо :)