Выбрать политический курс – одно дело, но сделать так, чтобы он прижился, – совсем другое. Политикам, сделавшим карьеру, хорошо известно, что для успешного продвижения по службе необходимо не только проявить умственные способности, но и приложить определенные мускульные усилия. Эта истина должна быть хорошо усвоена сетевыми архитекторами (network architects) - особенно теперь, когда изготовители коммутаторов утверждают, что им наконец-то удалось добиться предоставления функции QOS для приложений TCP.

Давайте начнем с возможностей, присущих так называемым коммутаторам Уровня 4.

Уровень 4? Да, это так. В отличие от коммутаторов предыдущего поколения, способных назначать трафику приоритеты в зависимости лишь от сетевого адреса, новые устройства могут определять классы трафика на основе некоторого критерия Уровня 4, например, номера порта TCP. Поскольку практически все популярные приложения IP – от Web и электронной почты до пересылки файлов и видеоконференций H.323 – используют различные номера портов, это обстоятельство представляется чрезвычайно важным.

Основное преимущество коммутаторов Уровня 4 состоит в том, что они предоставляют архитектору сети возможность отобрать определенное приложение и предоставить ему более качественное обслуживание – более широкую полосу, меньшие задержки и т.п. Итак, Уровень 4 - это транспортный уровень, и на этом не следует “зацикливаться”. Это то, что касается присвоения приоритетов приложениям.

По крайней мере, так обстоит дело в теории. Чтобы убедиться в способности коммутаторов Уровня 4 выполнять обещанные функции, для испытания этих устройств, обеспечивающих заданный уровень QOS, мы объединили наши усилия с Европейскими сетевыми лабораториями (ENL – European Network Laboratories, Париж). Спустя несколько недель, потраченных на разработку алгоритмов и “выколачивания” изделий от пяти ведущих производителей, мы определенно можем сказать, что механизмы QOS-изделия Уровня 4, скорее всего, работают.

Но нельзя сказать, что все новости были плохими. Показатели у двух коммутаторов были много лучше, чем у остальных; этими коммутаторами оказались Cajun P550 Routing Switch фирмы Lucent Technologies Inc. (Мюррей-Хилл, Нью-Джерси) и Summit4 фирмы Extreme Networks (Санта-Клара, Калифорния). Оба коммутатора хорошо справлялись с передачей высокоприоритетного трафика, сохраняя минимальные задержку и неустойчивость синхронизации, и оба получили почетное звание “Выбор испытателя”.

Но зачем вообще иметь дело с QOS, если большинство сетевых проблем может быть разрешено путем повышения пропускной способности сети? Давайте рассмотрим случай, когда данные передаются неравномерно (bursty). Независимо от пропускной способности тракта ("ширины трубы"), всегда сохраняется возможность возникновения кратковременной перегрузки. Более того, протоколы маршрутизации ничего не знают и не должны знать об уровнях нагрузки, поэтому перегрузка возникает только на некоторых маршрутах, а другие остаются недогруженными. Кроме того, существует неизбежное несовпадение скоростей на границе локальной и глобальной вычислительных сетей (LAN/WAN). Даже в самых высокоскоростных каналах глобальной сети WAN сохраняется возможность возникновения перегрузок в течение весьма продолжительного времени. Такие перегрузки могут быть вызваны трафиком, порожденным сетями университетского масштаба (campus networks), при его поступлении в линии связи глобальной сети. Более того, поскольку число клиентов всегда превышает число серверов, такой трафик будет перегружать маршруты, идущие как к серверным станциям (server farms), так и от них. (Средства балансирования нагрузки для серверных станций мы рассмотрим в предстоящем выпуске журнала.) Наконец, одна лишь полоса пропускания не может обеспечить низкой и предсказуемой задержки. Даже при наличии тракта с громадной пропускной способностью все же существует опасность того, что передача информации при исполнении приложений реального времени будет запаздывать из-за большого объема работ по пересылке файлов.

Именно здесь вступают в действие коммутаторы Уровня 4. При возникновении заторов они будут открывать экспресс-проходы для критически важных приложений. Кроме того, предполагается, что они будут освобождать полосу пропускания для низкоприоритетного трафика сразу же, как только завершится высокоприоритетный сеанс.

Эти коммутаторы предназначены в первую очередь для сетей университетского масштаба и поступают с разнообразными интерфейсами Ethernet, Fast Ethernet и Gigabit Ethernet (см. табл. 1). Число портов колеблется от 16 Ethernet/Fast Ethernet в коммутаторе Summit 4 фирмы Extreme до 192 портов Ethernet в Catalyst 5505 фирмы Cisco Systems (Сан-Хосе, Калифорния). Следующие три поставщика предлагают также ATM и FDDI: Cabletron Systems Inc. (Рочестер, Нью-Гэмпшир), Cisco и 3Com Corp. (Санта-Клара, Калифорния).

Но одного только Уровня 4 не всегда бывает достаточно. Smartswitch Router фирмы Cabletron осуществляет фильтрацию по такому критерию более высокого уровня, как унифицированный указатель ресурсов URL (Universal Resource Locator). Поскольку зная только номер порта, нельзя отличить заказ покупателя, передаваемый в соответствии с протоколом пересылки гипертекста HTTP (HyperText Transfer Protocol) от Web-сёрфинга (surfing the Web) сотрудников во время перерыва на обед, это довольно важно. Сетевым архитекторам может также понадобиться присваивать приоритеты трафику в зависимости от IP-адреса или подсети источника или получателя; такую возможность обеспечивают все рассматриваемые коммутаторы.

Все коммутаторы могут работать с четырьмя уровнями приоритетов, за исключением коммутатора Cajun фирмы Lucent, который имеет восемь уровней. По утверждению работников 3Com, сетевые архитекторы могут создавать дополнительные уровни внутри каждого приоритета, указывая, какой трафик в каждой очереди в случае возникновения перегрузки нужно отсылать первым.

Три коммутатора для присвоения приоритетов трафику используют так называемый алгоритм взвешенного циклического обслуживания (WRR – Weighted Round Robin), относящийся к категории алгоритмов массового обслуживания с очередями (queuing algorithm). Cabletron осуществляет "взвешенное справедливое обслуживание" в очереди (WFQ – Weighted Fair Queuing). В коммутаторе Catalyst 5505 фирмы Cisco при его размещении на границе сети реализуется алгоритм взвешенного случайного раннего отбрасывания (WRED – Weighted Random Early Discard). Основные переключатели этого коммутатора используют некий алгоритм массового обслуживания, напоминающий WRR. При его применении нам не удалось добиться согласованной работы двух коммутаторов, и поэтому мы завершали тестирование изделий фирмы Cisco, используя только один коммутатор, работающий в режиме WRED.

Самый простой способ - взвешенное равноправное обслуживание в очереди. При этом способе трафик классифицируется на потоки с относительно широкими и узкими полосами частот в зависимости от размера воспринимаемых коммутатором пакетов. При алгоритме WFQ вначале обеспечивается достаточная потенциальная пропускная способность для передачи потоков с относительно узкой шириной полосы, а затем остальная часть общей пропускной способности тракта делится между потоками с относительно широкими полосами частот. Основная задача алгоритма WFQ состоит в том, чтобы исключить “голодную смерть”, вызванную нехваткой полосы частот для низкоприоритетного трафика.

Но когда трафик выстраивается в очередь, поступающие пакеты могут теряться из-за недостатка места в буферах (это явление называют потерей концевых пакетов или "отсечением хвоста"). В свою очередь, это ведет к простоям многочисленных отправителей TCP, которые затем стремятся одновременно повторить свои передачи, вызывая еще большее скопление пакетов в коммутаторе. Все это создает порочный круг, которого алгоритм WRED пытается избежать путем случайного отбрасывания пакетов перед тем, как концевые пакеты начнут теряться из буферов. Такая “рандомизация” предотвращает полный отказ от обслуживания всех пакетов какого-либо одного из сеансов TCP. Вместо этого замедляется обслуживание лишь нескольких сеансов, а буферы освобождаются настолько, насколько это необходимо для того, чтобы избежать отбрасывания дополнительных пакетов.

Возможность взвешивания при использовании алгоритма WREQ обусловлена тем, что для различных приоритетов могут быть определены разные пороговые значения. При проведении наших испытаний представители фирмы Cisco так сконфигурировали свои коммутаторы, что они начинали отбрасывать пакеты низкого приоритета при заполнении буфера на 30%, а пакеты высокого приоритета – на 60%.

Кроме того, мы конфигурировали каждый из 32 пограничных портов как собственную подсеть IP. Таким образом, коммутаторы должны были осуществлять маршрутизацию IP при передаче трафика между отправителями и получателями.

По обе стороны пограничных коммутаторов мы устанавливали анализаторы Smartbits 2000 фирмы Netcom Systems Inc. (Чатсуорт, Калифорния), выполняющие специально разработанную для данного теста (см. “Методология тестирования”) программу TCP/IP. Эта программа отмечает время посылки и приема каждого пакета со точностью 100 нс, предоставляя нам беспримерную возможность наблюдения за работой механизма QOS, предназначенного для контроля TCP. Некоторые из поставщиков говорили, что используемые нами механизмы тестирования превосходят их собственные, и что они дают возможность лучше понять, как работает этот механизм QOS.

Мы провели четыре серии тестов. Во-первых, мы воспользовались установившимся трафиком и выполнили контрольные измерения скоростей пересылки без QOS и без перегрузок. Во-вторых, мы вводили перегрузки и вновь измеряли скорости пересылки без QOS. В третьих, мы запустили механизм QOS и измерили скорости пересылки для высоко- и низкоприоритетного трафика. Наконец, мы воспользовались неравномерным трафиком и измерили время запаздывания и неустойчивости синхронизации для высоко- и низкоприоритетного трафика.

В контрольных тестах для организации 27 сеансов ECP на каждом из десяти входящих портов Fast Ethernet (кроме коммутаторов Cabletron и Cisco), которые соединялись с таким же числом портов по другую сторону основной магистрали, мы воспользовались Smartbits. Девять из этих 27 сеансов служили для передачи высокоприоритетных данных в соответствии с почтовым протоколом POP3 (Post Office Protocol Version 3) через TCP порт 110; уравновешивалось это низкоприоритетными сеансами HTTP с использованием TCP порта 80. Во время высоко- и низкоприоритетных сеансов по основной магистрали передавался один мегабайт данных TCP.

Поскольку теоретически трафик от десяти портов Fast Ethernet может передаваться по каналу Gigabit Ethernet без потерь, в этом контрольном тесте мы коммутаторы не перегружали. (Коммутатор Cisco тестировался с использованием восьми пограничных портов Fast Ethernet, причем весь трафик передавался по опорной магистрали800 Мбит/с. Коммутатор Cabletron тестировался с десятью входящими портами Ethernet с пропускной способностью 10 Мбит/с.).

Быстрее всех передавал данные коммутатор Cajun фирмы Lucent; его средняя скорость пересылки TCP составляла 389 Кбайт/с за сеанс (см. рис. 1). Если скорость в 389 Кбайт/с для коммутатора Gigabit Ethernet покажется вам слишком низкой, учтите, что через каждый порт организуется 27 сеансов, - это определяет суммарную скорость передачи данных через порт Fast Ethernet свыше 86 Мбит/с. Кроме того, наши измерения TCP не учитывают передачу заголовков пакетов (это несколько повышает скорость пересылки) и необходимость повторной передачи потерянных пакетов, которая может привести к существенному снижению производительности. Очень близкие показатели имели коммутаторы 5505 Cisco и Summit4 фирмы Extreme; их средняя скорость составила свыше 300 Кбайт/с за сеанс TCP.

Результаты у остальных коммутаторов оказались намного хуже. 3Com Corebuilder 3500 передавал пакеты со скоростью всего в 157 Кбайт/с за сеанс. Средняя скорость пересылки пакетов у коммутатора Smartswitch Router фирмы Cabletron составила 40.4 Кбайт/с, что примерно на порядок хуже, чем у изделий, использующих каналы с гигабитной пропускной способностью. (Это говорит о том, что изделие Cabletron могло бы работать с такой же скоростью, что и коммутаторы Cisco и Extreme, если его снабдить платой Gigabit Ethernet, однако подтвердить это нам не удалось.)

Чтобы увидеть, что происходит с трафиком на перегруженной магистрали без QOS, мы разрешили передавать по ней трафик от 16 портов. По существу, мы старались пропустить через магистраль 1 Гбит/с поток со скоростью до 1.6 Гбит/с. Что-то должно было произойти…

Главным образом, нас интересовало, повышаются ли скорости пересылки для высокоприоритетного трафика при включении QOS. Нас интересовало также, что будет происходить с низкоприоритетным трафиком, – будут ли коммутаторы обеспечивать соотношение 4:1?

Запуск режима QOS влиял на все коммутаторы, но по-разному, – между ними отмечались большие различия. Lucent Cajun продвигал высокоприоритетные пакеты со скоростью 426 Кбайт/с – это даже быстрее, чем при контрольных испытаниях на 10 портах Fast Ethernet. 3Com Corebuilder действительно увеличивал скорость, перемещая пакеты в среднем со скоростью 271 Кбайт/с за сеанс, что почти в два раза быстрее, чем без перегрузки канала, и почти в пять раз быстрее, чем при перегрузке, но с заблокированным режимом QOS.

Коммутаторы Cabletron, Cisco и Extreme оказались более медлительными с включенным режимом QOS, чем без QOS и без перегрузки. Но их показатели были значительно лучше, чем при испытаниях с перегрузкой и без QOS: для Cisco это соотношение составило 247 против 189 Кбайт/с, а для Extreme – 308 против 217 Кбайт/с.

Но что же происходит с низкоприоритетным трафиком? Мы ожидали, что при таких настройках коммутаторов скорости пересылки пакетов для низкоприоритетного трафика будут составлять примерно одну четверть от соответствующих скоростей для высокоприоритетного трафика.

Но и здесь отмечались большие различия. Близкое к соотношению 4:1 значение было получено только для коммутатора Cisco, хотя средние скорости пересылки пакетов в каждом низкоприоритетном сеансе были значительно ниже, чем при любом контрольном тесте.

Но основную озабоченность вызвали у нас результаты тестов Cisco: механизм WRED привел к значительному замедлению низкоприоритетного трафика, лишь незначительно повысив скорость передачи высокоприоритетных пакетов. Действительно, при использовании WRED для завершения низкоприоритетных сеансов требовалось гораздо больше времени (в четыре с лишним раза), а высокоприоритетные сеансы происходили всего на 30% быстрее, чем при отключенном механизме WRED. Cisco утверждает, что WRED осуществляет все, чего от него можно было бы ожидать. Но мы обратили внимание на то, что коммутаторы Cisco теряли большое количество пакетов низкоприоритетного трафика даже после прекращения передач пакетов в рамках высокоприоритетных сеансов. По нашему предположению, это происходит вследствие того, что при реализации WRED в Catalyst 5505 используется только по одной очереди для каждого выходящего порта, независимо от уровня приоритетов. Низкоприоритетный трафик постоянно подвергался усечению, поскольку мы непрерывно поддерживали указанную очередь заполненной.

До сих пор мы обращали внимание только на средние скорости пересылки. Но, как нам удалось установить, средние скорости не всегда отражают реально происходящее во время конкретного сеанса или в конкретном порту.

О чем говорят цифры, полученные для одного сеанса? Здесь можно увидеть несколько удивительных вещей. Мы сравнивали минимальное и максимальное время, необходимое для завершения одного сеанса TCP. В идеальном случае они должны были бы совпадать, или между ними могло быть небольшое различие.

Но мы обнаружили совсем иное. Для передачи одного мегабайта высокоприоритетных данных TCP с включенным режимом QOS коммутатору Smartswitch фирмы Cabletron в среднем за сеанс требовалось 43 000 мс. Однако различие между самым коротким и самым длинным сеансами составило около 12 000 мс, то есть почти 30%. Аналогичное различие для коммутатора Summit4 фирмы Extreme составляло около 10%. Хорошие вести заключаются в том, что большинство коммутаторов во время высокоприоритетных сеансов показывают меньшие различия, чем при другом виде трафика.

Столь же интересные результаты были получены при попытке изучения порядка следования пакетов через индивидуальные выходящие порты. Если коммутатор близок к достижению соотношения 4:1, естественно предположить, что каждый порт получит четыре высокоприоритетных пакета и вслед за ними один низкоприоритетный. Иными словами, мы ожидали увидеть чередование на уровне пакетов.

Но мы увидели нечто, больше напоминающее чередование на уровне окна TCP: одно окно (45 пакетов) высокоприоритетного трафика и вслед за ним 45, 90 или даже 135 пакетов низкоприоритетного.

Это представляет собой проблему по двум причинам. Во-первых, желаемое соотношение 4:1 превращается почти в обратное, и высокоприоритетные пакеты располагаются между большим числом пакетов низкоприоритетного трафика. Э ведет к задержкам; приложение может перейти в состояние ожидания за то время, которое требуется на пересылку даже одного окна низкоприоритетного трафика.

Но существует еще одна скрытая проблема. В опорной сети, где протекает трафик от 16 выходящих портов, все может выглядеть довольно хорошо. Но разделите эти потоки и исследуйте трафик от одного выходящего порта, - и выяснится, что чередования на уровне пакетов в нем не происходит. Вместо этого вы увидите следующую последовательность окон: высокоприоритетное/низкоприоритетное/низкоприоритетное.

По крайней мере, частично эта проблема вскрыта нами. Мы просили поставщиков присваивать приоритеты трафику в соответствии лишь с одним критерием – номером порта TCP. Коммутаторы выполняли это (в большей или меньшей степени), когда мы перегружали магистральный канал. Но нам потребовался еще один критерий – адрес IP порта назначения, чтобы рассортировать трафик для любого данного сеанса или любой группы сеансов.

Мораль отсюда следующая: перед назначением приоритетов нужно знать ожидаемый конечными пользователями уровень обслуживания. Чем ближе сеть к реализации механизма QOS вдоль всего тракта передачи данных, тем лучше чувствуют себя пользователи.

Хорошо известно, что трафик носит неравномерный характер. Но данные в течение миллиона секунд, столь же неравномерны, как и в течение одной секунды. По этой причине коммутаторы скорее должны быть приспособлены для работы с “выбросами” высокоприоритетных данных, чем для обслуживания предсказуемых стационарных потоков.

Для оценки того, насколько хорошо аппаратные переключатели Уровня 4 работают с неравномерным трафиком, мы использовали в качестве основных показателей время запаздывания (задержку) и неустойчивость синхронизации. (Невозможно выполнить осмысленные измерения скорости пересылки, поскольку неравномерность по определению предполагает “броски” трафика.) Время запаздывания – задержка, вносимая коммутатором, – по меньшей мере, столь же важна, как и скорость пересылки, особенно при передаче речи, видео и мультимедиа в реальном времени. Неустойчивость синхронизации (изменения задержки) также имеет ключевое значение для передачи речи и видео.

Изучая формируемые анализатором Smartbits журналы регистрации пакетов, мы могли сравнивать время запаздывания и неустойчивость синхронизации для высоко- и низкоприоритетного трафиков. Выделив части регистрации, полученные тогда, когда коммутаторы передавали и высокоприоритетные пачки, и низкоприоритетный трафик, мы смогли вычислить время запаздывания, неустойчивость синхронизации и отношения между высоко- и низкоприоритетными данными.

Лучше всего отвечал предписанным отношениям коммутатор Cabletron, хотя вносимая им задержка для высокоприоритетного трафика была больше, чем у других. И хотя Extreme Summit4 не отвечал соотношению 4:1, его совокупная задержка, составляющая 455 мкс (для высокоприоритетного трафика) и 3 423 мкс (для низкоприоритетного трафика), была самой низкой.

Мы также измеряли неустойчивость синхронизации для высоко- и низкоприоритетного трафика (см. рис. 3). Самыми согласованными при разрешенной функции QOS, показав разброс всего в 73 и 62 мкс для высоко- и низкоприоритетных пакетов были, несомненно, коммутаторы Cisco. Наименьшую неустойчивость синхронизации, составляющую 56 мкс, мы зарегистрировали у коммутатора Lucent. Коммутатор Smartswitch Router 2000 фирмы Cabletron обладал большей неустойчивостью синхронизации на высокоприоритетных сеансах, чем на низкоприоритетных.

Для всех поставщиков, кроме Cisco, весьма тревожным стало то, что неустойчивость синхронизации оказывалась много выше при разрешенной функции QOS. Например, в случае Extreme Summit4 при разрешении QOS неустойчивость синхронизации для высокоприоритетного трафика скачкообразно увеличивается с 10 мкс до 210 мкс. Еще хуже обстоит дело с низкоприоритетным трафиком; здесь неустойчивость синхронизации увеличивается с 7 мкс (без QOS) до 2 297 мкс (при разрешенной функции QOS).

Для правильной оценки результатов отметим, что даже самая высокая выявленная нами неустойчивость синхронизации у коммутатора фирмы Cabletron, составляющая 4 мс, все же незначительна для большинства приложений. Но следует помнить, что задержка (и неустойчивость синхронизации) накапливается, поэтому ее негативное влияние может быть значительно сильнее в сетях с большим числом коммутаторов. Когда дело касается неустойчивости синхронизации, лучшее качество достигается вовсе без QOS.

Data Comm и ENL выражают признательность фирме Netcom Systems Inc. (Чатсуорт, Калифорния), предоставившей свои анализаторы Smartbits 2000 и платы ML-7710 линий связи. Старший инженер по программному обеспечению Эндрю Корлетт (Andrew Corlett) фирмы Netcom для этих испытаний разработал новую версию тестового программного обеспечения TCP.

При выполнении контрольных тестов мы соединили два коммутатора через одну магистральную линию Gigabit Ethernet (см. рисунок). Мы воспользовались анализаторами трафика Smartbits производства фирмы Netcom Systems Inc. (Чатсуорт, Калифорния) для того, чтобы сформировать трафик TCP, поступающий в один из коммутаторов, который затем по магистральной сети передается в другой коммутатор, являющийся для него пунктом назначения. В этой контрольной конфигурации мы просили поставщиков не использовать возможности своих коммутаторов, связанные с выполнением функции QOS, и создавали трафик с интенсивностью, недостаточной для перегрузки магистральных линий связи.

Для контрольного теста мы настроили 27 сеансов для каждого порта, причем в течение каждого сеанса должна была происходить передача 1 016 400 байт данных TCP. Мы формировали эти 27 сеансов для каждого из десяти входящих портов одного коммутатора, из которого пакеты направлялись к пункту назначения по магистральному каналу, а затем пересылались через десять выходящих портов на другом коммутаторе. Мы использовали “несетчатую” модель. Это означает, что направляемый в порт 1 первого коммутатора весь трафик передается в порт 1 второго коммутатора; весь трафик, направляемый в порт 2, передается в порт 2 второго коммутатора и т.д. Скорость пересылки кадров для каждого сеанса мы определяли, поделив количество данных TCP, направленных в системы в течение сеанса, на время, необходимое для его завершения. Также отмечался разброс в длительности сеансов путем вычисления среднеквадратического отклонения этой длительности.

В этом сценарии с перегрузкой канала использовались две конфигурации. Во-первых, мы попросили поставщиков не разблокировать какие-либо установки режима QOS. Как и при контрольном тесте, мы измеряли скорость пересылки пакетов TCP и разброс длительности сеансов. Затем мы попросили поставщиков включить имеющиеся у них возможности QOS и еще раз выполнили те же измерения; на этот раз мы регистрировали скорость пересылки пакетов и разброс длительности сеансов раздельно для высоко- и низкоприоритетного трафика.

Для проведения тестов с неравномерным трафиком мы попросили поставщиков сконфигурировать свои коммутаторы так, чтобы высокоприоритетный трафик получал в четыре раза большую полосу частот, нежели низкочастотный. На каждый клиентский порт мы направляли пачку высокоприоритетных данных TCP длиной в 64 Кбайт, затем выжидали 300 мс и вновь посылали на него еще одну пачку данных длиной в 64 Кбайт. Одновременно мы направляли в каждый клиентский порт по пять установившихся потоков данных, относящихся к низкоприоритетным сеансам, каждый из которых состоял из 256 Кбайт данных TCP. Для всех высоко- и низкоприоритетных сеансов мы измеряли задержку каждого пакета, и затем для определения неустойчивости синхронизации мы пользовались среднеквадратическим отклонением этой задержки.