Linux Advanced Routing & Traffic Control HOWTO
Шрифт:
См. описание /proc/sys/net/ipv4/route/gc_elasticity.
Максимальный размер задержки перед сбросом кэша маршрутов.
Максимальный размер кэша маршрутов. Устаревшие записи будут удаляться из кэша только после достижения размера кэша этой величины
FIXME: Восполните этот пробел.
Минимальный размер задержки перед сбросом кэша маршрутов.
FIXME: Восполните этот пробел.
FIXME: Восполните этот пробел.
Факторы, влияющие на принятие решения о пересылке сообщений перенаправления на заданный хост. Перенаправление не производится в случае, если величина нагрузки или количество отправленных сообщений достигли своего предела.
См. описание /proc/sys/net/ipv4/route/redirect_load
Таймаут перенаправления. По истечении этого периода времени, сообщение о переадресации посылается снова, независимо от того были ли достигнуты пределы redirect_load или redirect_number.
Глава 14. Специализированные дисциплины управления очередями.
Если вы придете к выводу, что ранее упомянутые дисциплины организации очередей вас не устраивают, то ядро может предложить вам ряд более специализированных дисциплин.
14.1. bfifo/pfifo
Эти бесклассовые дисциплины еще более просты, чем pfifo_fast — они не имеют внутренних полос, все виды трафика в них равноправны. Единственное их преимущество — возможность получения некоторых статистик. Таким образом, если вы не собираетесь ограничивать трафик или раскидывать его по приоритетам, то использование этой дисциплины позволит вам получить дополнительную информацию, которая поможет выявить узкие места на интерфейсе.
Длина pfifo измеряется в пакетах, bfifo — в байтах.
14.1.1. Параметры и порядок использования.
Задает длину очереди. Для pfifo измеряется в пакетах, для bfifo — в байтах. По-умолчанию имеет значение: для pfifo — txqueuelen интерфейса (см. раздел pfifo_fast), в пакетах, и txqueuelen * mtu байт — для bfifo.
14.2. Алгоритм Кларка-Шенкера-Чанга.
Этот алгоритм настолько "заумный", что даже Алексей (главный автор CBQ) утверждает — будто бы не до конца понял его суть. С его слов:
David D. Clark, Scott Shenker и Lixia Zhang. Поддержка Приложений Реального Времени в Пакетных Сетях c Интеграцией Сервисов: Архитектура и Механизм.
Насколько я понял, основная идея заключается в создании WFQ-потоков для каждого из сервисов с гарантированным качеством обслуживания и привязка оставшейся пропускной способности к фиктивному потоку flow-0 . В поток flow-0 отправляется весь предиктивный трафик и трафик, который обслуживается по принципу "лучшее из оставшегося" (best effort). Планировщик потока в первую очередь пропускает предиктивный трафик, а оставшаяся пропускная способность отдается трафику "best effort".
Примечательно, что в CSZ-потоках (Clark-Shenker-Zhang) НЕ производится наложения ограничений пропускной способности. Предполагается, что поток уже прошел входной контроль QoS сети и не нуждается в дополнительном формировании. Любая попытка что-то улучшить или ограничить, на промежуточных переходах, может привести к нежелательным задержкам и увеличению нестабильности.
На сегодняшний день CSZ – единственный планировщик, который может дать настоящую гарантию качества обслуживания. Другие схемы (включая CBQ) не гарантируют величину задержки.
В настоящее время не может быть рекомендован к использованию, если вы не читали или не достаточно четко понимаете содержимое упомянутого документа.
14.3. DSMARK.
Esteve Camps
<marvin@grn.es>
Этот текст — отрывки из моих тезисов Поддержка QoS в Linux, сентябрь 2000 года.
Исходные документы:
• Draft-almesberger-wajhak-diffserv-linux-01.txt
• Примеры, прилагаемые к дистрибутиву iproute2
• White Paper-QoS protocols and architectures и IP QoS Frequently Asked Questions.
Автор главы: Esteve Camps <esteve@hades.udg.es>.
14.3.1. Введение.
Прежде всего, было бы неплохо, если бы вы предварительно ознакомились с RFC, посвященными данной теме (RFC2474, RFC2475, RFC2597 и RFC2598) по адресам: IETF DiffServ working Group и домашняя страничка проекта diffserv.
14.3.2. Что такое Dsmark и с чем его "едят"?
Dsmark– — это дисциплина организации очереди, которая предлагает возможности, необходимые в "Differentiated Services" (известной также, как DiffServ, или просто — DS). DiffServ — фактически одна из двух архитектур QoS (вторая называется "Integrated Services"), которая базируется на значении поля DS в заголовке IP-пакетов.
Одним из первых решений в IP, которое предлагало некоторый уровень QoS, был "Type of Service" (Тип Обслуживания) — поле TOS в IP-заголовке. Изменяя это поле, можно было выбрать высокую/низкую пропускную способность, минимальную задержку или высокую надежность. Но это решение не обеспечивало достаточной гибкости, которую требовали вновь появляющиеся услуги (например, приложения реального времени, интерактивные приложения и т.п.). С появлением новых требований, появились и новые архитектуры. Одна из них — DiffServ, которая подменяет первые шесть битов ToS в пакете IPv4 или октет "класс трафика" в пакете IPv6, полем, с названием DS, в котором можно указать до 64 классов трафика.
14.3.3. Основные принципы.
Differentiated Services (Дифференцированное Обслуживание) ориентирован на группы. Имеется ввиду, что эта технология ничего не знает о потоках, она ориентирована на группы, а применяемые правила зависят от того, к какой группе направляется пакет.
Сеть маршрутизаторов с поддержкой механизмов DiffServ называют "облаком DiffServ" (или "доменом DiffServ"). Классификация, формирование и установка меток (под установкой меток понимается установка значений в поле DS) происходит на входе в "облако". Внутри домена метка определяет — какой уровень QoS должен применяться к трафику внутренними маршрутизаторами сети.