Глава 4. Scheduling

Основы scheduling

С помощью классификатора определили трафик в разные очереди, теперь нужно как-то трафик обрабатывать. Этим процессом как раз занимается scheduler:

• Порядок передачи пакетов
• Скорость передачи пакетов
• Кол-во пакетов, которое можно забуфферизировать
• Разные способы обработки пакетов в случае заторов на сети.

Разная обработка трафика на основании loss-priority.

• Классификация или полисер назначили PLP
• PLP соответствует scheduling traffic profile
• Traffic profile соответствует drop profile
• Drop profile определяет вероятность отброса трафика

Port-based очереди (queues)

Каждый порт может содержать 4-8 очереди.

Одной очереди может быть назначено более одного forwarding class.

PQ-DWRR: priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.

WRED: Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.

Компонениы Scheduling

Transmission rate

Transmission rate - кол-во пропускной способности от физического интерфейса, выделенной для этой очереди. Похоже на CIR.

Очередь может превышать tranmission rate, если есть неиспользуемая полоса (использовать большую полосу, чем выделили изначально). Тут также используется терминология in-profile, out-of-profile.

edit class-of-service schedule <schedule-name> transmit-rate (rate | percent | remainder) exact | rate-limit

• remainder - заполнение оставшегося буфера.
• exact - буферизирует трафик, который превысил transm rate. При наличие неиспользуемой свободной полосы не будет давать очереди её использовать.
• rate-limit - дропает трафик, который превысил transm rate.
• no settings - очередь может превысить transm rate, если есть неиспользуемая полоса.

Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.

Для best-effort - 95, для netw-control - 5.

Unusable bandwidth

В случае, когда у нас сформированы 2 очереди и trasm-rate между ними делится 50/20%, в таком случае получаем неиспользуемую полосу 30%.

Эта неиспользуемая полоса будет использоваться только очередями, у которых есть превышение transm-rate.

Scheduler будет делить неиспользуемую полосу между подходящими очередями.

Чтобы исключить очередь, используем exact или rate-limit в настройке.

Приоритет очереди

Priority - приоритет среди других очередей. Во времена запоров приоритетом определяется в каком порядке будут обрабатываться очереди.

Значения:

• Low
• Medium-low
• Medium-high
• High
• Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.

Остальные очереди передают трафик в порядке убывания приоритета от high к low.

Трафик в in-profile (по transmission rate) low priority, будет обрабатывается до трафика out-profile strict priority.

То есть сначала вне зависимости обрабатывается трафик в in-profile, только потом out-profile.

Но при этом, при передаче каждого пакета в очереди, ниже strict, происходит проверка - есть ли в очереди пакеты из более высокой очереди. Если есть, то начинают передаваться они, а потом продолжает передавать прежняя очередь (если за это время не набежало пакетов из тоже приоритетной очереди).

Strict-priority - опсана! она может сожрать всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.

Чтобы не происходило голодания, мы можем:

1. также важным очередям назначать high-priotity.
2. для strict-priority задавать в transm-rate rate-limit.

Разрешается задавать 1 strict-priority на 1 интерфейс.

edit class-of-service schedule <schedule-name> priority < high / low / medium-high / medium-low / strict-high >

Дефолтные значения для дефолтных fw-class: best-effort - low , network-control - low .

Delay buffers

- Delay buffers - кол-во данных, кот можно хранить.

larger buffer = many packet stores = large supported latency.

Buffer size - это параметр, определяющийся размер буфера интерфейса и также зависит от платформы.

edit class-of-service schedule <schedule-name> buffer-size <percent | temporal | remainder>

percentage: буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.

effective delay buffer (ms) = buffer size (%) * max port buffer size (ms)
effective delay buffer (s) * interf bandwidth (Mbps) / 8 = buffer size (MB) [используется для конвертации в Мбайты]

Пример:

100 ms - max buffer size
1GB ports
для очереди 0 - задаем percentage = 30%: effective delay buffer = 30 ms, buffer size = 0,03 s * 1000 Mbps /8 = 3,75 MB
для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB

temporal: для задания размера такого буфера используются мс. Буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.

buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8
buffer size (MB) = max buffer size (s) * [interface bandw (Mbps) * transmit rate (%)] / 8

Пример:

100 ms - max buffer size
1GB ports
для очереди 2 - задаем transmission rate = 100 Mbps (10%): buffer size = 0,1 * 100 Mbps / 8 = 1,25 MB
для очереди 2 - задаем transm rate = 10% : buffer size = 0,1 * 1000 Mbps * 0.1 / 8 = 1,25 MB
для очереди 3 - задаем transmission rate = 300 Mbps (30%): buffer size = 0,1 * 300 Mbps / 8 = 3,75 MB
для очереди 3 - задаем transm rate = 30% : buffer size = 0,1 * 1000 Mbps * 0.3 / 8 = 3,75 MB
 

remainder: использует все не занятое другими очередями пространство.

Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные (равные) значения, но это не обязательно вообще.

В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.

Default scheduler settings: Для best-effort - 95 , для netw-control - 5 , что равно дефолтным значениям transm-rate.

Drop profiles (RED/WRED)

RED drop profiles (random early discard) - как отбрасывать трафик, когда возникает запор. Работает напрямую с буфферами. Отбрасывание пакетов зависит от заполненности буфера.

Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).

При этом в RED из-за "случайно отброшенных" пакетов может возникнуть такая ситуация, когда некоторые пакеты одного потока будут отброшены, тогда source перестанет получать acknowledgement от receiver. При этом затор на уже почти перегруженном линке будет только увеличиваться.

В связи с этим более эффективно использовать WRED, он полностью не уберет проблему с "нечестным" отбросом пакетов из одного потока, но хотя бы можно исключить подобную ситуацию для трафика, нетерпимого к подобным потерям. О нем дальше.

Параметры WRED

1. fullness: наполненность буффера.
2. drop probability: вероятность, что пакет будет отброшен.

Для drop-profile задаём значения для этих двух параметров. По сути получается линия на графике, где соотносятся fullness (%) к drop probability (%).

How it works:

1. Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
2. Числа нанесены на график отношения fullness к drop probability (по оси fullness).
3. Когда случайный номер выше линии, пакет передается.
4. Когда случайный номер ниже линии, пакет дропается.

Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика.

Такой подход является более взшешанным (weighted RED = WRED).

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

Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем эффективный максимальный размер буффера. То есть с помощью drop-profile мы можем влиять на "рабочий" размер буфера.

Config options

Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:

• segmented: график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.

Пример конфига:

set class-of-service drop-profiles segmented fill-level 25 drop-probability 25 
set class-of-service drop-profiles segmented fill-level 50 drop-probability 50
set class-of-service drop-profiles segmented fill-level 75 drop-probability 75
set class-of-service drop-profiles segmented fill-level 95 drop-probability 100

• interpolated:

Представляет собой гладкий график, постепенно возвышающийся.

Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.

(0,0) (100,100) - эти координаты включены по умолчанию.

Пример конфига:

set class-of-service drop-profiles interpolated interpolate fill-level [50 75] drop-probability [25 50]

Default settings

fill-level 0 drop-probability 0
fill-level 100 drop-probability 100

Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )

Apply drop profile

Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.

Одной очереди может быть применено более 1 drop profile для разных типов трафика.

Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету. Я так понимаю, что здесь речь о том, то прикрепленный к пакету PLP теперь имеет значение и на его основании, в том числе, будет обработан трафик.

Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.

Drop profile map options

loss-priority: low, medium-low, medium-high, high. any

protocol: tcp, non-tcp, any

drop profile: desired drop-profile.

edit class-of-service schedule schedule-name drop-profile-map loss-priority ... protocol ... drop-profile ...

По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.

Default scheduler settings

edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal

set class-of-service drop-profiles terminal fill-level 100 drop-probability 100

Scheduler map

Используется для группирования сложных наборов schedulers, чтобы можно было применить их к каждому FW class на интерфейсе.

При создании scheduler map мы задаем кол-во сервисов, назначенных каждому FW class и соответствующих приоритетов.

При этом к одной очереди можно применить несколько FW class (queue). Далее трафик можно будет обрабатывать особым образом, основываясь на PLP.

Конфигурация Scheduler

• Configure scheduler, including drop profile

• Transmission rate
• Queue priority
• Delay buffers
• Drop profile - не в рамках scheduler
• Drop profile maps

• Configure scheduler map: schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
• Apply scheduler map to an interface: будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.

Пример:

scheduler

set class-of-service drop-profiles relaxed interpolate fill-level [75 90 100] drop-probability [0 75 100]
set class-of-service drop-profiles aggressive interpolate fill-level [50 75 90 100] drop-probability [0 50 75 100]

set class-of-service schedulers sch-be transmit-rate percent 70
set class-of-service schedulers sch-be buffer-size percent 70
set class-of-service schedulers sch-be priority low
set class-of-service schedulers sch-be drop-profile-map loss-priority high protocol any drop-profile aggressive
set class-of-service schedulers sch-be drop-profile-map loss-priority low protocol any drop-profile relaxed

set class-of-service schedulers sch-pri transmit-rate percent 30
set class-of-service schedulers sch-pri buffer-size percent 30
set class-of-service schedulers sch-pri priority high

scheduler map

set class-of-service scheduler-maps sched-map-example forwarding-class best-effort-data scheduler sch-be
set class-of-service scheduler-maps sched-map-example forwarding-class priority-data scheduler sch-pri

apply to an interface

set class-of-service interfaces ge-0/0/0 scheduler-map sched-map-example

Дополнительная информация

• Глава 5. Hierarchical scheduling
• Глава 1. QoS
• Глава 8. Packet flow