Фрагментация пакетов :(

[LionHeart]

Фрагментация пакетов

Помогите пожалуйста решить задачку:

На виндовой машине задолбала фрагментация пакетов.
понятное дело что скачать что-либо не мешает...Но смотреть\слушать что-то потоковое - нервы подшаливают моментами.

картина такая :
локаль - впн - инет
по локальной сети от моего компа до впн сервера все ок.
при создании впн подключения , мту автоматом выставляется в значение 1400. Пакеты фрагментируются...при MTU 1400(такое оно по умолчанию) максимальный нефрагментируемый пакет 1370. НО если я в реестре выставляю 1370 - то проходит максимум 1342... и пакеты все равно фрагментирутся.

Вопрос - как избавиться от фрагментации пакетов?
в 98 винде было два параметра
maxmtu и maxmss - но анологичного maxmss я не нашел

 

[eyeland]

с MTU даже в 300 байт все должно работать ок, дело не в МТУ а в чемто другом. обратись к техподдерке своего прова, они должны помочь решить

 

[LionHeart]

не хочеться грубить, но не несите чепуху пожалуйста

я знаю о чем говорю, просто не знаю как в ХР выставить значение аналогичное maxmtu в 9х версиях.

проблема не в размере пакета, а в его фрагментации, которая не желательна, мягко говоря, для всего что является потоковым.

 

[eyeland]

не хочеться грубить, но не несите чепуху пожалуйста

eye ~ # ifconfig eth0 | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:300  Metric:1
eye ~ # ping ya.ru -s 1500
PING ya.ru (213.180.204.8) 1500(1528) bytes of data.
1508 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=56 time=30.9 ms
1508 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=56 time=30.6 ms
1508 bytes from ya.ru (213.180.204.8): icmp_seq=3 ttl=56 time=30.4 ms
^C
--- ya.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 30.488/30.705/30.955/0.278 ms
red ~ #

ок

я знаю о чем говорю, просто не знаю как в ХР выставить значение аналогичное maxmtu в 9х версиях.

почемуто все думают что знают что такое MTU и фрагментация, но на самом деле этого не знает никто из тех кто такое говорит.

проблема не в размере пакета, а в его фрагментации, которая не желательна, мягко говоря, для всего что является потоковым.

MTU 300 байт. зырю ютуб. полёт нормальный. кто не верит может проверить (если знаете как менять MTU в своих любимых осях)

 

[alex444]

LionHeart: а может дело вовсе не в MTU у тебя, а в зарезанном ***** прохождении пакетов PMTUD по трассе? (в некотором особо умном оборудовании пакеты path mtu discovery - "forward disabled" в дефолтах IOS, ну и некоторые админы (этого оборудования) об этом понятия не имеют).

 

[Freesom]

LionHeart: а может дело вовсе не в MTU у тебя, а в зарезанном ***** прохождении пакетов PMTUD по трассе? (в некотором особо умном оборудовании пакеты path mtu discovery - "forward disabled" в дефолтах IOS, ну и некоторые админы (этого оборудования) об этом понятия не имеют).

Что за бред насчет IOS и "пакетов PMTUD" Похоже ты с IOS знаком весьма плохо, но это простительно, а вот насчет "пакетов PMTUD" я поржал от души, спасибо!
Процедура PMTUD запускается на хосте-отправителе и заключается в том, что он ставит бит DF на все пакеты и начинает отправлять пакеты стартуя с самого большого MSS, а потом постепенно уменьшает его, пока не перестанет принимать от промежуточных роутеров сообщение ICMP "Destination Unreachable" с кодом "fragmentation needed and DF set" (type 3, code 4). Задача всех промежуточных роутеров лишь генерить и пропускать пакеты ICMP, а они это по дефолту делают (и железки на IOS не исключение) и задача хоста-отправителя принимать эти пакеты ICMP, но долбодятлы-юзеры частенько всё порежут фаерволом, а потом удивляются, что у них что-то сеть херовенько пашет!

 

[alex444]

Странно, для кого авторы ios-ов это писали....

Problems with PMTUD

There are three things that can break PMTUD, two of which are uncommon and one of which is common.

A router can drop a packet and not send an ICMP message. (Uncommon)

A router can generate and send an ICMP message but the ICMP message gets blocked by a router or firewall between this router and the sender. (Common)

A router can generate and send an ICMP message, but the sender ignores the message. (Uncommon)

The first and last of the three bullets above are uncommon and are usually the result of an error, but the middle bullet describes a common problem. People that implement ICMP packet filters tend to block all ICMP message types rather than only blocking certain ICMP message types. A packet filter can block all ICMP message types except those that are "unreachable" or "time-exceeded." The success or failure of PMTUD hinges upon ICMP unreachable messages getting through to the sender of a TCP/IP packet. ICMP time-exceeded messages are important for other IP issues. An example of such a packet filter, implemented on a router is shown below.
access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

Причём некоторые, повторяю, версии IOS-ов, первое делают "by default" (я с такими дефолтами сталкивался, потом авторы эти дефолты обозвали "своим багом"

This list shows the related software defects.
Cisco bug ID CSCdj11304 ( registered customers only)
Cisco bug ID CSCdi75411 ( registered customers only)
Cisco bug ID CSCdj74245 ( registered customers only)

). Со вторым вариантом также сталкивался - и это был вовсе не роутер у end-юзера, а магистральный маршрутизатор (у считающего себя "квалифицированным" администратора-транзитника).

 

[Freesom]

Странно, для кого авторы ios-ов это писали.... Причём некоторые, повторяю, IOS-ы, первое делают "by default" (я с такими дефолтами сталкивался). Со вторым вариантом также сталкивался - и это был вовсе не роутер у end-юзера, а магистральный маршрутизатор (у считающего себя "квалифицированным" администратора-транзитника).

авторы ios-ов это писали для тех валенков-админов уровня домашнего пользователя, которые пинги блокируют командой access-list 101 deny icmp any any забывая при этом, что ICMP не только пингами живёт!
Но такие ******ы встречаются довольно редко (чего не скажешь о рядовых юзерах с их манией фаерволить всё на свете), потому и написано в скобках Uncommon

Причём некоторые, повторяю, IOS-ы, первое делают "by default" (я с такими дефолтами сталкивался).

хочу себе такой IOS! Скинешь как-нить? Это вроде как машина, у которой по дефолту через час езды отпадут колёса! Такое надо иметь чисто для коллекции артефактов!

This list shows the related software defects.
Cisco bug ID CSCdj11304 ( registered customers only)
Cisco bug ID CSCdi75411 ( registered customers only)
Cisco bug ID CSCdj74245 ( registered customers only)

если цитируешь, то хоть полностью цитируй или в сути проблемы разберись:

This is sometimes due to a lower layer problem with the link, such as a Frame Relay circuit with a too-small MTU and too little buffering, a malfunctioning channel service unit/data service unit (CSU/DSU) or repeater, an out-of-spec cable, or a software or firmware defect.

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

 

[alex444]

хочу себе такой IOS! Скинешь как-нить

IOS 12.2(28),вылезало при "ip icmp rate-limit unreach DF", лечилось только выключением лимита, т.е. "no ip icmp rate-limit ..". Субверсию не помню, ибо давно избавился от этой глюковерсии .

зы В инете на форумах было

 

[Freesom]

а может это был не баг а фича! Да и вообще железа без багов не бывает, но, повторюсь, обобщать это на дефолтные настройки всего, что работает под IOS это по меньшей мере наивно.

 

[Renegade]

Пров тот же что и у лиона. Не в MTU и фрагментации дело.

 

[Freesom]

Пакеты фрагментируются...при MTU 1400(такое оно по умолчанию) максимальный нефрагментируемый пакет 1370. НО если я в реестре выставляю 1370 - то проходит максимум 1342... и пакеты все равно фрагментирутся.

как определил, что пакеты фрагментируются? просто отправлял пинги с заданным размером и битом DF? заголовок 28 бит плюс 1342 вроде влезает в MTU 1370, значит винда делает то что ей поручено. Может проблема в чём то другом? И как именно ощущается это по потоковому видео?

 

[BFG-9000]

Господа, и без умствований было понятно, что дело у ТС не в фрагментации пакетов. Ибо дефолтовый для эзернета МТУ 1400 ОДНОЗНАЧНО будет порезан на трассе до ютуба и возможно будет собран и снова порезан и так несколько раз

 

[eyeland]

Господа, и без умствований было понятно, что дело у ТС не в фрагментации пакетов. Ибо дефолтовый для эзернета МТУ 1400 ОДНОЗНАЧНО будет порезан на трассе до ютуба и возможно будет собран и снова порезан и так несколько раз

врядле дефолтный для ethernet МТУ 1500 будет порезан по дороге к ютубу. (вы ж не думаете что ютубовские серваки подключены к интернету через PPoE лол)

2ТС: максимальный mss не бывает больше чем mtu, поэтому если у вас MTU 1400 то max_mss будет и того меньше (1400 минус размеры заголовков, это пара десятков байт) поэтому от вас к ютубу и назад идут пакеты <=1400, а такой размер везде пролезет (за редкими исключениями, поэтому таки обратитесь в техподдержку провайдера)

 

[LionHeart]

да уж... нашел я где помощи искать...

и так

во первых BFG - для езернет сетей дефолтом всегда был 1500
во вторых alex444 - твоим познаниям и навыкам я всегда доверял (в диспутах) потому уточню : я юзаю программу adapter watch - она в реальном времени показывает фрагментируются пакеты или нет, успешно или нет.
Глюки возникают именно в моменты когда счетчик фрагментируемых пакетов двигается. Если бы это было 1-5-100 пакетов за час работы - я бы вообще внимания не обращал - но значения в тысячах и как уже было сказано четкое совпадение между ростом счетчика фрагментированых пакетов и артефактов в видео (к примеру).

eyeland - Если вы не можете подсказать как внести спрашиваемые изменения в реестр или иным образом повлиять на работы TCP\IP стека - прошу покиньте мою тему.

п.с. для тех кто думает что проблема "где то рядом" - все что работает по UDP - траблов НЕ имеет, что доказывает прямую связь с фрагментацией пакетов!

 

[alex444]

LionHeart: а теперь давай думать здраво. Что есть потоковое видео/аудио, которое ты смотришь/слушаешь? правильно, это поток данных от сервера к тебе. Т.е. фактически у тебя mru "играет".
Теперь смотрим далее - ну уменьшишь ты mtu и mss у себя (т.е. на приёмной стороне) на сетевом интерфейсе (или увеличишь - не суть важно). Ну сообщишь ты серверу, что пакеты, отправляемые к тебе, надо резать не под размер 1372 байт, а на 1200 или на 1438, что от этого на твоей стороне изменится? ничего абсолютно. разве что для сервера чуть больше нагрузка в стеке будет

Теперь обратная сторона.. Абстрактный разговор по тому же скайпу с видеорядом.. тут опять-таки абсолютно пофик стеку - бить поток при передаче на пакеты размером 1472 байта или бить его на пакеты размером 1372 байта.. (случай приёма рассмотрели выше ).
Накладные расходы практически одинаковы (в случае меньшего размера пакетов - немного бОльший оверхед по траффику за счёт заголовочных данных, но у нас же анлим и полоса не 64 килобита?) Согласен?

Если согласен - сам подумай, где узкое место в твоей системе, почему ей настолько некогда заниматься приёмом/передачей данных, что даже размер пакетов она "произвольный" начинает делать? Явно ты не туда рыть начал, по-моему...


зы если ты смотришь на ИТЛ-овское iptv - так оно и у меня квадратит "периодически", с моим-то гигабитом на ИТЛ, отсутствием преобразований размеров пакетов и всего двумя хопами до media.itl.ua - т.е. артефакты-то явно от передающей поток стороны У меня артефакты на приёме появились после перевода Дейнекой уникаст-вещания с http на rtsp.
(впрочем, я сильно подозреваю, что (если) я мозгов своему рабочему компику увеличу до гигабайта с 512 (при работе тачки 600-650 занято)) - артефактов не станет).

 

[BFG-9000]

врядле дефолтный для ethernet МТУ 1500 будет порезан по дороге к ютубу. (вы ж не думаете что ютубовские серваки подключены к интернету через PPoE лол

А может ты не будешь так категорично отвечать за ВСЕ хопы по пути к ютубу? У меня получилось 17 штук.
Резка связана со спецификой передачи физических пакетов. Каналообразующее железо представляет собой еще тот зверинец. Так что пакеты режут неоднократно. Или ты думаешь, что там везде эзренет?

 

[Renegade]

Ну, блин... У нас с лёвой один пров, живём на одной улице, подозреваю что даже в одном сегменте. У меня ютуб не артефактит. А ИТЛовский ИПТВ артефактит изредка, да. Но он помоему у всех так глючит А мозгов на тачке щас вообще 256 метров Правда сетёвки все триком, да. И рулит инетом специально обученный Compaq, никакого ВПНа на рабочейтачке

 

[LionHeart]

alex444 -ты комент про различие при работе UDP и TCP\IP стеков мною упомянутые пропустил мимо глаз?

трабла в том что если приложение работает по TCP то "разбивание пакета" означает что там где можно было отправить ровно 100 пакетов отправлено будет 150(к примеру) это вызывает задержку, по русски - ЛАГИ.

Ну сообщишь ты серверу, что пакеты, отправляемые к тебе, надо резать не под размер 1372 байт, а на 1200 или на 1438, что от этого на твоей стороне изменится? ничего абсолютно. разве что для сервера чуть больше нагрузка в стеке будет

Что измениться????
я получу от сервера 100 пакетов а не 150 = меньше задержка при передачи данных.

 

[alex444]

alex444 -ты комент про различие при работе UDP и TCP\IP стеков мною упомянутые пропустил мимо глаз?

нет. А ты подумал о таком "не зависящем от тебя устройстве", как pptp-сервер провайдера и его быстродействие?

я получу от сервера 100 пакетов а не 150 = меньше задержка при передачи данных.

на то именно и есть буфер данных в приложении-проигрывателе.
В общем случае - я тебе пытаюсь втолковать, что (если идти в твоём направлении) - надо уходить в принципе от инкапсуляции в туннель на стороне приёма данных (т.е. между провайдером и тобой), т.к. фрагментация и её механизмы от приёмной стороны (твой комп) не зависит и регулировать ты её на приёмнике не можешь (всё равно в случае наличия помежуточного туннеля ты получаешь перепаковку пакетов с 1472 на 1372 на pptp-сервере. И от изменения размера окна в туннеле - глобально ничто не изменится (всё равно факт перепаковки потока pptp-сервером в направлении "к тебе" будет иметь место)
А если рыть в моём направлении - то надо копать размер буфера данных твоего приложения на верхнем уровне модели osi либо само железо/операционную систему на твоей (приёмной) стороне.