Як пов’язані зважені справедливі черги та зважене випадкове раннє виявлення?

Я намагаюся зрозуміти, як працюють системи QoS, і я не впевнений, як саме WFQ та WRED взаємодіють.

Спочатку я подумав, що WFQ - це механізм встановлення черг і що WRED - це механізм уникнення перевантажень. WFQ повинна запланувати пакети в чергах, а WRED є там, щоб скинути їх, коли черги заповнені. Якщо я встановлюю QoS, наприклад, комутатор L3, я створив механізм черги та механізм уникнення перевантажень, тож теоретично я міг би WFQ та WRD працювати разом. Наприклад, цей документ, мабуть, означає, що я був би створений таким чином. Деякі інші документи Cisco згадують, що я міг їх використовувати самостійно.

Тоді я хотів дізнатися більше про те, як вони працюють, і почав шукати Інтернет. Як результат, зараз я поняття не маю, що вони і як працюють.

Деякі сайти (принаймні, наскільки я розумію вміст) стверджують, що алгоритми планування пакетів та алгоритми уникнення перевантажень в основному однакові. Наприклад, у цій статті у Вікіпедії всі вони розміщені в одній групі. Деякі випадкові статті згадували, що я можу використовувати WFQ XOR WRED.

Отже, що я хотів запитати, наскільки пов’язані WFQ та WRED? Коли я використовував би те чи інше, і коли обидва, якщо це навіть можливо?

Зважена чесна черга (WFQ), як назва означає алгоритм встановлення черги. Черга використовується, коли на інтерфейсі є затори. Зазвичай це виявляється через повне передавальне кільце (TX-Ring). Це означає, що інтерфейс зайнятий пересиланням пакетів. Черга не відбувається, якщо на інтерфейсі не виникає заторів. У деяких випадках розміром TX-кільця можна керувати. Невелике кільце TX дає черзі програмного забезпечення більше енергії щодо того, які пакети надсилаються першими, але це не дуже ефективно. Занадто велике TX-кільце зробило б програму чергу майже марною та призвело до збільшення затримки та тремтіння важливих пакетів.

Алгоритм черги за замовчуванням, як правило, First In First Out (FIFO). Це означає, що пакети доставляються саме в тому порядку, коли вони надходять на вхід інтерфейсу. Зазвичай це не бажано, оскільки деяким пакетам слід надавати пріоритет.

Досить часто клієнт купує послугу у постачальника послуг Інтернету (ISP) за субтратом. Тобто, клієнт купує послугу 50 Мбіт / с, але фізичний інтерфейс працює зі швидкістю 100 Мбіт / с. У цьому випадку не буде заторів, але Інтернет-провайдер обмежить кількість трафіку від клієнта. Для введення штучних заторів у цих випадках можна застосувати формувач.

Тому тепер, коли є перевантаженість, можна застосувати алгоритм встановлення черги. Зауважте, що алгоритми встановлення черги не забезпечують додаткової пропускної здатності, вони просто дозволяють нам вирішити, які пакети для нас важливіші. WFQ - це алгоритм, який приймає декілька параметрів і приймає рішення на основі цього. Алгоритм досить складний і в якості параметрів використовує вагу (IP Precedence), розмір пакету та час планування. Тут є дуже детальне пояснення від INE . WFQ - хороший вибір, якщо не хочеться занадто сильно пружитися з чергою, оскільки це забезпечує адекватну пропускну здатність для потоків невеликих розмірів, таких як SSH, Telnet, голос, і це означає, що передача файлів не вкраде всю пропускну здатність.

Зважене випадкове раннє виявлення (WRED) - це механізм уникнення перевантажень. WRED вимірює розмір черг залежно від значення Precedence і починає скидати пакети, коли чергу знаходиться між мінімальним порогом і максимальним порогом. Конфігурація вирішить, що 1 у кожному N пакетів буде відмінено. WRED допомагає запобігти синхронізації TCP та голодуванню TCP. Коли TCP втратить пакети, він перейде в повільний старт, і якщо всі сесії TCP одночасно втратять пакети, вони можуть синхронізуватися, що забезпечує такий графік:

Як видно, якщо WRED не налаштований, графік проходить повний вибух, потім беззвучний, потім повний вибух і так далі. WRED забезпечує більш середню швидкість передачі. Важливо зазначити, що UDP не впливає на падіння пакетів, оскільки він не має механізму підтвердження та розсувного вікна, реалізованого як TCP. Тому WRED не слід реалізовувати на базі UDP класу, як клас, що обробляє SNMP, DNS або інші протоколи на основі UDP.

І WFQ, і WRED можуть і повинні бути розгорнуті разом.

Перш за все, не вірте всьому, що ви читаєте в Інтернеті ;-)

Іноді алгоритми (або спосіб їх фізичної реалізації) не вписуються в теоретичну категорію. Те, що ви називаєте, менш важливе, ніж розуміння того, що він робить.

Вся суть WFQ (або будь-якого іншого алгоритму планування) полягає в розділенні обмеженої пропускної здатності зв'язку між різними потоками. WFQ намагається розподілити пропускну здатність пропорційно кожному потоку. CBWFQ робить те ж саме для кожного "класу". У ідеальному світі, з необмеженими чергами та необмеженою пам’яттю, це було б все, що вам потрібно - ви ділитесь пропускною здатністю і всі раді.

Але оскільки у пристроїв немає необмежених черг і пам'яті, потрібно зробити деякі "ярлики". Оскільки черга має обмежений розмір, існує небезпека, що черга заповниться, спричиняючи падіння хвоста та синхронізацію трафіку. По суті, якщо моя черга переповнена, я більше не контролюю пропускну здатність.

Щоб уникнути переповнення черг, я використовую випадкове раннє виявлення. Цей алгоритм випадковим чином скидає пакети з черги відповідно до того, наскільки черга повна (глибина) - чим повніша черга, тим більше пакетів буде скинуто. Мета - уберегти чергу від переповнення, щоб алгоритм планування міг працювати.

Тоді якийсь яскравий інженер Cisco помітив, що можна використовувати меншу кількість черг (більш просте обладнання) та випадково скидати різні види трафіку на різній глибині черги. WRED скидає трафік з черги на різній глибині залежно від типу трафіку. Хоча ви можете назвати WRED механізмом уникнення перевантажень, оскільки глибина падання трафіку змінюється залежно від типу трафіку, ефект полягає в тому, що різні види отримують менше місця в черзі, а отже, менша пропускна здатність. Таким чином, він також діє як алгоритм планування. Ви кажете по-тай-до, а я кажу по-та-ногу.

Ще одна відмінність: FQ і WFQ працюють на всіх типах трафіку, оскільки вони по суті рахують байти. RED та WRED працюють лише з TCP, оскільки вони залежать від механізму управління потоком TCP, щоб уповільнити трафік та уберегти чергу від переповнення.

(Примітка. Для пояснення я ігнорую пріоритетні черги та LLQ. Це ще одна відповідь).

Я згоден з усім, що сказав і Майк.

Ось приклад CBWFQ та WRED:

політика-карта

клас Голосова
пріоритетність відсотків 20

клас
пропускної здатності відео відсотків 30

пропускна здатність класу P1 відсотків 10
випадкове виявлення dscp на основі
випадкового виявлення dscp af31 26 40 10

Пропускна здатність класу P2 відсотків 15
випадкове виявлення dscp на основі
випадкового детектування dscp af21 24 40 10

class class за замовчуванням
справедлива черга з
випадковим виявленням на основі dscp