Приоритезация трафкика в условиях канала с менящейся скоростью

А разве для этого не QoS существует?

Если сможешь слинковать шейпер с libastral.so, то можно.

Введение в строй ECN, по идее, проблему должно решить... Но где ж оно, ECN-то?

ECN есть, но далеко не везде. Более того - единственная дисциплина шейпинга трафика в Linux, в которой заявлена поддержка ECN - это RED(ну и вариации а-ля GRED)

все проще

все дело в том - что мы не можем менять очередность пакетов которые приходят от провайдера
мы можем это делать лиш опосредованно через механизм TOS в ip пакетах или же упроавляя задержой доставки пакетов

то что прислал нам провайдер он уже прислал - и мы можем танцевать тока с тем что есть - теми пакетами что уже пришли

и если оин клиент в сотню потоков по udp гонит торрент - а второй открывать одну странчику - то от провайдера придет 100 пакeтов для первого и 1 пакетик для второго (примерно)
и мы НИЧЕГО фактически несможем сделать - если только сортирвоать пакеты

но если нам известна максимальная скорость - скажем 10 мегабит
то мы ограничиваем общию полосу в 9-9.5мегабит - и именно ее нарезаем на 2 равные части - с максимальность скорость в 9.5

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

это не экспертный - это простейший и стандартный вопрос

Но можно же откидывать низкоприоритетные пакеты, когда входящий канал забивается. Однако, как детектить, что именно ВХОДЯЩИЙ канал забывается, когда его скорость неизвестна? Единственное, что приходит в голову, это отслеживание потерь пакетов во всех tcp-сессиях, которые установлены через этот канал. Если потери (во входящих данных) во всех сессиях больше определенного процента, то значит, что канала уже не хватает. Другой вопрос, что я не припомню реализации подобной идеи.

ну откинеш ты низкоприоритетные - дальше то что ?
тебе провайдер на их место непошлет новые - он УЖЕ послал тебе те - которые ты откинул

анализировать тут можно только статистически - а это не мгновенное регулирование
система с обратной связью этакая

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


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

можно же откидывать низкоприоритетные пакеты

Да хоть заоткидывайся: передающий со своей стороны в трубу уже запихал максимум, что туда лезет, откидывая пакеты ты только ухудшаешь ситуацию: их надо будет повторять. Вся надежда только на congestion control в tcp и протоколах приложений.

Поэтому шейпить надо на выходе.

Я не совсем понимаю принципов снижения скорости передачи для tcp/ip. Насколько я понимаю, он начинает снижать скорость отправки запросов в случае, когда с другой стороны часть пакетов начинают пропадать. В таком случае, когда мы начнём отбрасывать пришедшие пакеты, то соединение начнёт сбавлять скорость, что нам и нужно. В чём тогда проблема?

Тут написано о целой кучи модулей ядра, которые подзволяют стеку правильно выбирать скорость и подстраиваться под соединение http://www.protocols.ru/modules.php?name=News&file=article&sid=17 . Почему же тогда нельзя контролировать насыщение на всём интерфейса сразу (когда все tcp-сессии в какой-то момент начинают подходить к насыщению и теряют пакеты), и рулить шейпингом уже на основании этих данных?

Т.е.:
У нас канал с неизвестной, периодически меняющейся скоростью.
Есть 4 tcp-сессии. 1-ая будет иметь приоритет 0 (всегда должна обслуживаться первой), 2-ая - 1, 3 и 4 имеют приоритет 2.
Допустим, все сессии устанавливаются одновременно и пытаются отожрать весь канал (download (к нам) часть канала. upload почти не жрут). Тогда мы видим, что наступило насыщение у всех сессий сразу. В результате чего нужно шейпить входящие пакеты у 2,3,4 сессий. По такому алгоритму:
1. Объединяем все пакеты, ниже приоритета 0 в группу 0.
2. Пытаемся урезать группу 0, пока сессия 1 (приоритет 0) не начнёт обслуживаться без шейпирования.
3. Когда шаг 2 сделан, создаём группу 1, объединяя в ней все сессии с приоритетом меньше 1 (сессии 3,4).
4. Пытаемся урезать группу 1, пока сессия 2 (приоритет 1) не начнёт обслуживаться без шейпирования.
5. Когда шаг 4 сделан, в группе 1 пытаемся урезать сессии 3 и 4 поровну.

Проблема в том, как определить, что шейпирование происходит именно на уровне провайдера, а не уровне конкретного сервера.

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

К Вам аналогичный вопрос.

суть работы tcp - в попытке предсказать будущее - а предсказывать его дело крайне неблагодарное

оно всякими опосредствованными методами - пытается определить сколько же влезет в канал передачи - чтоб не терялось и было как можно быстрее

а опосредствованных методов у него по существу только один - это ВОЗВРАТ ответов от источника

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

а контролировать все соединение нельзя по крайне простой причине - суть в том что tcp рабоатет не только с твоим интерфейсом - он еще и со всеми роутерами на пути работает
и потери и недостаточный канал - бывает нетолько у тебя

лучше опиши - что конкретно нужно у тебя