![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Переупорядочивание пакетов: PPtP и GRE
В продолжение темы.
Умение протоколов компрессии/шифрования трафика автоматически восстанавливаться после потерь или переупорядочивания пакетов в сети это, конечно, хорошо. Но если с потерями почти ничего сделать нельзя (разве что передавать данные с избыточностью/перепосылками на транспортном уровне :-), то с небольшим переупорядочиванием можно и побороться.
Представим себе, что недалеко от точки приёма такого трафика возникают неподконтрольные нам перестановки пакетов - то есть, все пакеты доставляются без потерь, но очень часто соседние пакеты приходят переставленными местами (с таким я столкнулся на практике при использовании арендованной виртуалки в LeaseWeb). В таких условиях MPPE вынужден непрерывно выполнять re-keying и скорость на туннеле, проброшенном через такую сеть, падает ниже плинтуса. И даже если использовать PPP-туннель без шифрования/компрессии, мы получаем огромный процент потерь внутри туннеля, потому что GRE вынужден дропать "опоздавшие" фреймы PPP, так как не имеет права доставлять их с нарушением порядка (дропать - имеет право).
Но если обучить GRE восстанавливать порядок пакетов, то PPP/MPPE даже и не узнают, что были проблемы с доставкой (пока не начнутся настоящие потери). Для ноды ng_pptpgre(4), которую использует mpd при создании PPtP-туннелей, сделал патч. Update 07.09.2016: обновление патча для 11.0
Патч даёт возможность управлять глубиной очереди ожидания переупорядоченных пакетов через sysctl net.graph.pptpgre.reorder_max (ноль отключает восстановление порядка) и таймаутом ожидания "опоздавших" пакетов (в милисекундах) через net.graph.pptpgre.reorder_timeout. Тесты показали хороший результат при reorder_max=16 и таймаутом в 1ms, когда точка переупорядочивания близко к нам и в 50ms, если далеко. Изменять значения этих параметров можно "на лету", без переустановки туннелей. В итоге CCP даже не дергается, если низлежащий GRE успешно восстанавливает порядок.
Патч предварительный в том смысле, что параметры глобальные для всех PPtP-туннелей в системе. Можно улучшить его, сделав эти настройки локальными для каждого туннеля, но, к сожалению, этого нельзя сделать без того, чтобы не сломать ABI ноды ng_pptpgre, после чего старые сборки mpd перестанут вообще работать с патченной нодой. С текущим патчем пересобирать ничего не нужно, кроме ng_pptpgre.ko (или ядра, если нода статически слинкована с ним).
no subject
no subject
no subject
no subject