Network-RED та ECN – сприяння покращенню характеристик TCP 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Network-RED та ECN – сприяння покращенню характеристик TCP



Хоч TCP є наскрізним протоколом, мережа може сприяти TCP в оптимізації його характеристик. Одна з можливостей полягає у зміні поведінки черги в мережі шляхом використання завчасного випадкового виявлення (Random Early Detection - RED). RED дозволяє мережевому раутеру видаляти пакет, навіть коли наявне додаткове місце у черзі. Така взаємодія між завчасним випадковим виявленням і TCP є дуже ефективною.

RED використовує зважену усереднену довжину черги як коефіцієнт ймовірності видалення пакету. Якщо усереднена довжина черги зростає, то зростає і ймовірність видалення пакету (рис. 3.95).

 
 

Рис. 3.95. Поведінка RED.

Малий блок пакетів можна переслати через фільтр RED відносно цілим, тоді як більші блоки пакетів будуть відчувати зростаючий вищий темп видалення. Підтримане навантаження буде надалі збільшувати темп видалення пакетів. Це веде до того, що TCP-сесія з більшими вікритими вікнами буде мати вищу ймовірність випадків видалення пакетів, обумовлене відступом у розмірі вікна.

Головною метою RED є уникнення ситуацій, у яких всі потоки TCP відчувають перевантаження в той сам час, всі роблять відступ і поновлення від того самого темпу, тобто тенденцій до синхронізації поведінки потоків. При використанні RED найбільш вибухові потоки мають найбільшу ймовірність видалення пакетів, тоді як потоки з меншим рівнем вибуховості можуть пересилатися без надмірних впливів з боку RED. RED також впливає на зменшення засягу впливу повної втрати сигналів ACK, яка веде до паузи і рестарту сесії в режимі повільного старту. Намір полягає в сигналізації найбільш вибуховій сесії TCP ймовірності очікування насичення черги і видалення її кінцівки перед досягненням умови такого видалення, дозволяючи сесії TCP застосувати швидке відновлення за умови відсутності перевантаження. Іншою метою RED є уможливити ефективну роботу черги з масштабованою глибиною черги через цілий розмір черги всередині часової шкали коливань глибини черги того самого порядку, як середнє значення RTT потоку трафіку.

Поза увагою RED є спостереження, що TCP встановлює дуже мало припущень щодо мережі, через яку він мусить оперувати, і що він не може враховувати будь-який сигнал зворотнього зв’язку щодо узгоджених характеристик, який був би генерований мережею. Як мінімальне наближення TCP використовує втрати пакетів як сигнал про характеристики мережі, інтерпретуючи подію втрати пакетів у малому масштабі як подію перевантаження мережі внаслідок піку навантаження, і подію тривалої втрати пакетів як ознаку більш критичного перевантаження. RED сприяє збільшенню кількості сигналів про маломасштабні перевантаження і таким чином уникає довготривалих умовперевантаження.

RED не мусить видаляти випадково вибрані пакети. Метою RED є сигналізувати надавачу про наявну можливість переповнення черги, і надавач повинен пристосуватися до цих умов. Альтернативним механізмом для раутерів є завантаження позначених пакетів з явним прапорцем (бітом) ознайомлений з перевантаженням (Congestion Experienced – CE) у припущенні, що надавач буде бачити і реагувати на це встановлення прапорця у спосіб, порівняльний до реакції на видалення окремого пакету. Цей механізм, який називають явним попередженням про перевантаження (Explicit Congestion Notification – ECN), використовує 2-бітову схему, претендуючи на використання бітів 6 і 7 поля TOS IPv4 (або двох бітів CU (Currently Unused) поля Differetiated Services). Біт 6 встановлюється надавачем для позначення того, що це система транспорту, оснащена ECN (ECT-біт). Біт 7 – це біт CE і він встановлюється раутером, коли середня довжина черги перевищує сконфігурований пороговий рівень.

Алгоритм ECN полягає в тому, що активний раутер буде здійснювати RED, як описано вище. Після того, як пакет вибрано, раутер може позначити біт CE у пакеті, якщо біт ECT встановлений; в іншому випадку, він видалить вибраний пакет (рис. 3.96).

 
 

Рис. 3.96. Операції ECN.

Взаємодія з TCP впроваджена дещо далі. Початкове підтвердження TCP SYN включає додаткову можливість використання прапорців ECN-echo і зменшене вікно перевантаження (Congestion Window Reduced – CWR), що дозволяє довільній системі узгоджувати зі своїм відповідником, який з них буде обслуговувати пакети зі встановленим бітом CE протягом пересилання даних. Надавач встановлює біт ECN у всі пакети, які він висилає. Якщо надавач приймає пакет TCP з прапорцем ECN-echo, встановленим у заголовку TCP, то надавач регулює своє вікно первантаження так, ніби він здійснив швидке відновлення внаслідок втрати окремого пакету. Наступний висланий пакет буде мати встановлений TCP-прапорець CWR для вказівки приймачу, що він повинен відреагувати на перевантаження. Додатковим попередженням є те, що надавач буде реагувати таким чином щонайбільше один раз протягом кожного інтервалу RTT. Далі, пакети TCP з встановленим прапорцем ECN-echo не будуть впливати на надавача всередині того самого інтервалу RTT. Приймач буде встановлювати прапорець ECN-echo у всі пакети, якщо він прийме пакет зі встановленим бітом CE. Це буде продовжуватися доти, доки він не прийме пакет зі встановленим бітом CWR, який вказує, що надавач відреагував на перевантаження. Прапорець ECT встановлюється тільки в пакетах, які містять дані. Пакети ACK TCP, які не містять даних, будуть вислані з невстановленим бітом ECT. Сполучення не потребує очікувати на приняття трьох здубльованих ACK для виявлення умови перевантаження. Замість цього приймач повідомлений про зародження умови перевантаження через явне встановлення відповідного біта вказівки, який повертається до надавача у відповідному ACK.

Моделювання ECN з використанням функції маркування RED показує дещо кращу перепускну здатність у порівнянні з конфігуруванням RED з функцією видалення пакетів. Однак широке впровадження ECN не очікується в найближчому майбутньому, зокрема, в контексті протоколу IPv4. На даному етапі відсутня явна стандартизація полів всередині заголовка данограми IPv4, в якому переноситься ця інформація, і база впровадження IP тепер настільки широка, що будь-які модифікації семантики полів у заголовку данограми IPv4 мусять бути дуже старанно розглянені, щоб змінена інтерпретація полів не привела до неправильної поведінки у старших версіях стеку TCP або у старших впровадженнях програмного забезпечення раутерів.

ECN забезпечує певен рівень покращення характеристик порівняно з схемою вилучення пакетів RED. При пересиланні великих обсягів даних покращення помірне і базується на різниці між повторним пересиланням пакетів та регулюванням вікна перевантаженням в RED і регулюванням вікна перевантаження в ECN. Найбільш помітне покращення, відзначене в експериментах з моделюванням ECN, виявляється для коротких транзакцій TCP, наприклад, при роботі з Web, коли вилучення пакетів алгоритму RED з початкового потоку даних може викликати шестисекундну затримку повторного пересилання. Порівняно з цим ECN дозволяє здійснювати пересилання без цієї затримки.

Головною проблемою при ECN є потреба зміни операцій в обидвох раутерах і програмному забезпеченні стеку TCP для пристосування до операцій ECN. Хоч пропозиції ECN старанно побудовані, щоб дозволити суттєво нескоординоване уведення до Internet без негативних побічних ефектів, однак ефективність ECN щодо покращення загальної перепускної здатності мережі буде безсумнівною тільки після того, як цей підхід буде широко сприйнятий. Оскільки Internet збільшується, то інерційна маса створює природній опір подальшим технологічним змінам, тому може минути декілька років, перш ніж ECN буде широко впроваджене як у програмному забезпеченні станцій, так і в системах раутінгу Internet. З другого боку, RED може бути швидше впроваджено в Internet, бо він вимагає тільки локальної модифікації поведінки раутерів і залежить від наявної реакції TCP на вилучення пакетів.



Поделиться:


Последнее изменение этой страницы: 2016-08-01; просмотров: 111; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.17.128.129 (0.006 с.)