Компьютерные сети

Информация обратной связи
В применяемых сегодня методах обратной связи используются следующие основные типы сообщений:
□ признак перегрузки;
□ максимальная скорость передачи;
□ максимальный объем данных (кредит);
□ косвенные признаки.

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

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

Сообщение о максимальном объеме данных используется в широко применяемом в пакетных сетях алгоритме скользящего окна (подробнее о нем рассказывается в главе 17). Этот алгоритм позволяет не только обеспечивать надежную передачу данных, но и реализовать обратную связь для контроля потока между конечными узлами. Параметром, несущим информацию обратной связи, является «окно» — число, тесно связанное с текущим размером свободного пространства в буфере принимающего узла. Окно также называют кредитом, который принимающий дает передающему узлу. Передающий узел может с любой скоростью передать объем информации (или определенное количество пакетов, если окно измеряется в пакетах), соответствующий кредиту. Но если кредит исчерпан, то передающий узел не имеет права передавать информацию, пока не получит следующий кредит. При перегрузках принимающий узел уменьшает размер окна, тем самым снижая нагрузку. Если эффект перегрузки исчезает, то принимающий узел увеличивает размер окна. Недостатком этого алгоритма является то, что он работает только в протоколах с установлением соединения.

И, наконец, в некоторых случаях передающий узел определяет, что принимающий узел (или узлы) испытывает перегрузку, по некоторым косвенным признакам, без получения сообщения обратной связи. Такими косвенными признаками могут быть факты потери пакетов. Для того чтобы протокол мог обнаруживать факты потерь пакетов, это должен быть протокол с установлением соединения. Тогда истечение тайм-аута или приход дубликата положительной квитанции косвенно свидетельствует о том, что пакет потерян. Однако потеря пакета не всегда свидетельствует о перегрузке сети. Перегрузка сети — это только одна из возможных причин потери пакета, другой причиной может быть ненадежная работа коммуникационных устройств (отказы оборудования, искажения данных из-за помех). Тем не менее так как реакция на перегрузки и ненадежную работу сети должна быть одинаковой и состоять в снижении скорости передачи, то неоднозначность причины потери пакета не является проблемой.

Примером протокола, использующего неявную информацию о перегрузках, является протокол TCP. Этот протокол с помощью явной информации обратной связи (о размере окна) осуществляет контроль потока, а с помощью неявной (потери пакетов, дубликаты квитанций) — управляет перегрузкой.
Резервирование ресурсов
Резервирование ресурсов и контроль допуска

Рассмотренные методы поддержания качества обслуживания ориентированы в основном на борьбу с перегрузками или предотвращение их в пределах отдельного узла сети. Вместе с тем понятно, что для обеспечения гарантированного уровня качества обслуживания некоторого потока пакетов необходимо скоординированное применение этих методов на всем пути следования потока через сеть. Такой координирующей процедурой является процедура резервирования ресурсов сети для определенного потока. Эта процедура позволяет настроить все механизмы поддержания качества обслуживания вдоль следования потока таким образом, чтобы поток с некоторыми заданными характеристиками скорости был обслужен с заданными характеристиками QoS.

Основная идея процедуры состоит в том, что каждому узлу сети вдоль маршрута следования потока задается вопрос, может ли этот узел обслужить некоторый новый поток с заданными характеристиками QoS, если известны предельные характеристики скорости потока, такие как средняя и пиковая скорости? Каждый узел при ответе на этот вопрос должен оценить свои возможности, то есть проверить, достаточно ли у него свободных ресурсов, чтобы принять на обслуживание новый поток и обслуживать его качественно. При положительном ответе узел должен некоторым образом зарезервировать часть своих ресурсов для данного потока, чтобы при поступлении пакетов потока на входные интерфейсы использовать эти ресурсы для их обслуживания с гарантированным уровнем качества.

В общем случае каждый узел самостоятельно решает, какие ресурсы он должен резервировать для обслуживания некоторого потока с заданным качеством. Как показывает практика, основным ресурсом, требуемым для качественного обслуживания пакетов, является пропускная способность интерфейса, через который пакеты потока покидают узел. Поэтому в дальнейшем мы будем, несколько упрощая действительное положение дел, употреблять формулировку «резервирование пропускной способности» вместо «резервирование ресурсов».

Смысл резервирования состоит в том, чтобы ограничить уровень перегрузок определенного потока или нескольких потоков некоторой приемлемой величиной. Эта величина должна быть такой, чтобы механизмы QoS (управления очередями, кондиционирования трафика и обратной связи), применяемые в узлах сети, справлялись с кратковременными небольшими перегрузками и обеспечивали требуемые значения характеристик QoS.

Однако что же означает резервирование пропускной способности в сетях с коммутацией пакетов? Ранее мы не встречались с таким механизмом, все предыдущие объяснения работы сетевых устройств обходились без него. Дело в том, что этот механизм не является обязательным, а используется только в тех случаях, когда требуется гарантированное выполнение требований качества обслуживания пакетов.

Резервирование пропускной способности в сетях с коммутацией пакетов похоже на аналогичную процедуру в сетях с коммутацией каналов тем, что определенному потоку данных назначается определенная часть пропускной способности линии связи. Однако это назначение здесь гораздо более гибкое — если отведенная пропускная способность в какой-то период времени недоиспользуется потоком, то она может быть передана другим потокам. Это обстоятельство позволяет более эффективно расходовать пропускную способность линий связи, но приводит к эффекту постепенной деградации качества транспортного сервиса из-за перегрузок и очередей вместо простого отказа в обслуживании, который имеет место в сети с коммутацией каналов, когда пропускной способности оказывается недостаточно для обслуживания некоторого потока. Цель гибкого резервирования — обеспечить поток зарезервированной пропускной способностью в те периоды, когда она ему нужна вся, то есть в периоды перегрузок. Другим отличием резервирования в пакетных сетях является то обстоятельство, что оно может выполняться не только «из конца в конец», но и для каких-то отдельных узлов по маршруту потока, однако этот случай не может гарантировать необходимый уровень характеристик QoS, так как перегрузка даже в одном узле может привести к задержкам и потерям пакетов.

Резервирование пропускной способности в пакетной сети «из конца в конец» начинается с операции, называемой контролем допуска в сеть потока, который просит зарезервировать для своего обслуживания некоторую пропускную способность сети между ее двумя конечными узлами. Эта операция состоит в проверке наличия доступной (то есть незарезервированной для других потоков) пропускной способности в каждом из узлов сети на протяжении всего маршрута следования потока (здесь мы не останавливаемся на проблеме поиска маршрута потока, она подробно рассматривается далее в разделе «Инжиниринг трафика»). Очевидно, что максимальная средняя скорость потока должна быть меньше, чем запрашиваемая пропускная способность, иначе поток будет обслужен с очень плохим качеством даже несмотря на то, что ему была зарезервирована некоторая пропускная способность.

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

Нужно подчеркнуть, чтб резервирование — это процедура, которая выполняется перед тем, как реальный трафик будет направлен в сеть.
Давайте теперь посмотрим, каким же образом выполняется собственно выделение пропускной способности потоку в моменты времени, когда его пакеты поступают на вход коммуникационного устройства 52, которое запомнило факт резервирования пропускной способности для потока F1 на выходном интерфейсе Р2 (рис 7.16).
Контроль допуска = Да
Рис. 7.15. Контроль допуска потока

Остальные
потоки
Устройство S2
Устройство S1
Все потоки
Потоки F1
Рис. 7.16. Выделение зарезервированной пропускной способности
Такое выделение можно обеспечить разными способами, в нашем примере это будет сделано с использованием взвешенных очередей.

Пусть потоку F1 при резервировании было выделено 25 % пропускной способности интерфейса Р2 (обычно резервирование можно выполнять как в абсолютных величинах, например в мегабитах в секунду, так и в процентах; это, собственно, детали реализации механизмов QoS в конкретных устройствах). Также для простоты будем считать, что резервирование было выполнено только для потока F1, в то же время для всех других потоков, которые проходят через выходной интерфейс Р2, резервирования не производилось.

Для того чтобы добиться желаемого результата, достаточно организовать для выходного интерфейса две взвешенные очереди — очередь для потока F1 с весом 25 % и очередь «по умолчанию» для всех остальных потоков. Кроме того, необходимо активизировать классификатор, который будет проверять пакеты на всех входных интерфейсах устройства 52 (на рис. 7.16 показан только один входной интерфейс Р1), отбирать пакеты потока F1 по заданным при резервировании признакам и направлять их в очередь для потока F1. В те периоды времени, когда скорость потока F1 окажется меньше зарезервированной пропускной способности в 25 %, неиспользованная ее часть будет потребляться потоками из очереди «по умолчанию» — в силу алгоритма работы взвешенных очередей. Зато в периоды, когда скорость потока F1 достигнет заявленного максимума средней скорости в 25 %, вся зарезервированная пропускная способность выходного интерфейса будет выделяться потоку F1, а все остальные потоки будут довольствоваться оставшимися 75 %. Значения в 75 % может оказаться недостаточно для качественного обслуживания этих потоков, и тогда их пакеты будут задерживаться или даже теряться при переполнении очереди «по умолчанию». Может оказаться и так, что значения в 75 % окажется слишком много для остальных потоков, и они будут обслуживаться с высоким качеством; какая из двух ситуаций будет наблюдаться чаще, мы не знаем, так как у нас нет никакой предварительной информации о «других» потоках. Этот пример хорошо иллюстрирует особенность методо

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

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

Использование взвешенных очередей — не единственный вариант резервирования пропускной способности в пакетных сетях. Для той же цели можно задействовать приоритетные очереди.' Применение приоритетной очереди может быть не только возможным, но и необходимым, если потоку помимо определенного уровня пропускной способности требуется обеспечить минимально возможный уровень задержек пакетов.

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

Нужно подчеркнуть, что резервирование приводит к ожидаемым результатам только в тех случаях, когда реальная скорость потоков, для которых было выполнено резервирование, оказывается не выше, чем пропускная способность, запрошенная при резервировании и реализованная при конфигурировании сетевых устройств. В противном случае результаты могут оказаться даже хуже, чем при наличии единственной очереди «по умолчанию» и обслуживании «по возможности». Так, если скорость потока окажется выше, чем предел, учитываемый механизмом профилирования, то часть пакетов будет отброшена даже в том случае, если устройство не перегружено и могло бы отлично справиться с предложенным трафиком без применения механизмов QoS.

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

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

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

ПРИМЕР-АНАЛОГИЯ -

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

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

При описании процедуры резервирования пропускной способности мы сфокусировались на механизмах выделения пропускной способности некоторому потоку и оставили без внимания одну важную деталь: какую пропускную способность должен запрашивать поток для того, чтобы задержки его пакетов не превышали некоторой величины? Единственное соображение, которое было высказано по этому поводу, заключалось в том, что запрашиваемая пропускная способность должна быть выше, чем максимальная скорость потока, иначе некоторая часть пакетов просто может постоянно отбрасываться сетью, так что качество обслуживания окажется гарантированно низким.

Однако эта «деталь» на самом деле оборачивается сложной проблемой, так как мы не можем, например, сконфигурировать очередь приоритетного или взвешенного обслуживания так, чтобы она строго обеспечила какой-либо заранее заданный порог задержек и их вариации. Направление пакетов в приоритетную очередь только позволяет гарантировать, что задержки будут достаточно низкими — существенно ниже, чем у пакетов, которые обрабатываются в очереди по умолчанию. Мы также знаем, что при наличии взвешенных очередей задержки будут снижаться со снижением относительного коэффициента использования пропускной способности, отведенной очереди. Но это все качественные рассуждения, а вот количественно оценить значения задержек очень сложно.

Каким же образом поставщик услуг может выполнить свои обязательства перед клиентами? Очень «просто» — он должен постоянно измерять фактические значения характеристик трафика в сети и гарантировать пользователям сети величины задержек в соответствии с наблюдаемыми результатами.
ПРИМЕР

Пусть сеть предоставляет три уровня качества обслуживания трафика: золотой для очень чувствительного к задержкам трафика, серебряный для трафика, чувствительного к задержкам и требующего гарантированной пропускной способности, и бронзовый для трафика, обслуживаемого по возможности. Оператор сети может различными способами добиться того, чтобы на золотом уровне обслуживания действительно гарантировались очень низкие величины задержек, вариаций задержек и потерь пакетов для трафика, на серебряном — достаточно низкие значения этих характеристик, но выше, чем у золотого, а на бронзовом гарантировались только определенные величины потерь пакетов и вовсе не гарантировались значения задержек. Для реализации такой стратегии обслуживания оператор может, например, организовать на всех коммутаторах сети приоритетную очередь для обслуживание золотого трафика и отвести ей 25 % пропускной способности на каждом выходном интерфейсе; взвешенную очередь с 50 % пропускной способности для серебряного трафика и взвешенную очередь с оставшимися 25 % для бронзового трафцка. А далее он должен принимать на обслуживание потоки пользователей в каждый класс и выполнять постоянный мониторинг характеристик трафика каждого класса. И если, например, мониторинг показывает, что задержки у 95 % пакетов золотого трафика не превышают 15 мс, то оператор может гарантировать эту величину пользователям золотого уровня обслуживания. Но так как оператору нужно быть готовым к приему на обслуживание новых пользователей,

Все материалы, размещенные в боте и канале, получены из открытых источников сети Интернет, либо присланы пользователями  бота. 
Все права на тексты книг принадлежат их авторам и владельцам. Тексты книг предоставлены исключительно для ознакомления. Администрация бота не несет ответственности за материалы, расположенные здесь