Располагая характеристиками трафика, сеть принимает решение о добавлении нового виртуального канала. Чтобы не произошло перегрузки, сеть может, например, зарезервировать часть пропускной способности для каждого виртуального канала. В этом случае характеристика трафика выступает в качестве договора об обслуживании, которое сеть обязуется предоставить пользователю. В разговоре о предотвращении перегрузки мы слишком рано отклонились в сторону смежной темы, QoS; вернемся к ней чуть позже.
Даже если сеть не берет на себя никаких обязательств, она может использовать характеристики трафика для управления доступом. При этом задача сводится к оценке числа виртуальных каналов, достаточного для обеспечения нужной пропускной способности сети и работы без перегрузок. Предположим, что все виртуальные каналы, которые могут передавать трафик со скоростью до 10 Мбит/с, используют один и тот же физический канал с пропускной способностью 100 Мбит/с. Сколько каналов можно использовать? Очевидно, что при 10 каналах нет никакого риска перегрузки, но это неэффективно в обычной ситуации, поскольку вряд ли все они будут одновременно работать в полную силу. В действующих сетях для оценки числа возможных каналов используются статистические данные. Таким образом, за счет допустимого увеличения риска сеть выигрывает в производительности.
Можно совместить принципы управления доступом и маршрутизации с учетом состояния трафика, направляя маршруты в обход проблемных участков. Для примера рассмотрим сеть на илл. 5.22 (а), в которой два маршрутизатора перегружены.
Илл. 5.22. (а) Перегруженная сеть. (б) Участок сети без перегрузки. Также показан виртуальный канал между A и B
Предположим, что хост, подключенный к маршрутизатору A, хочет установить соединение с хостом, соединенным с B. В других обстоятельствах это соединение прошло бы через один из перегруженных маршрутизаторов. Чтобы этого избежать, сеть усекается, как показано на илл. 5.22 (б). При этом исключаются перегруженные маршрутизаторы и все их линии связи. Пунктиром показан возможный путь виртуального канала в обход перегруженных маршрутизаторов. Подробное описание маршрутизации, чувствительной к нагрузке, можно найти в работе Шейха и др. (Shaikh et al., 1999).
Сброс нагрузки
Когда ни один из описанных методов не помогает в борьбе с перегрузкой, маршрутизаторы могут ввести в бой тяжелую артиллерию — сброс нагрузки (load shedding). По сути, это игнорирование маршрутизаторами пакетов, которые они не могут обработать. Своим происхождением этот термин обязан сфере электроснабжения, где он означает отключение в случае перегрузок отдельных участков во избежание выхода из строя всей системы. Обычно это происходит в жаркие летние дни, когда спрос на электроэнергию (для питания кондиционеров) многократно превышает предложение.
Ключевой вопрос для маршрутизатора, заваленного пакетами, — какой из них исключить. Выбор зависит от типа приложений, использующих данную сеть. При передаче файлов более старые пакеты представляют большую ценность, чем новые. Например, если отбросить пакет 6, но сохранить пакеты 7–10, это заставит получателя выполнить лишнюю работу: поместить в буфер данные, которые он еще не может использовать. Для мультимедийных приложений, работающих в реальном времени, напротив, новый пакет важнее старого, поскольку пакеты становятся ненужными, если не приходят вовремя.
Первую стратегию (старое лучше нового) часто называют винной стратегией (wine), а вторую (новое лучше старого) — молочной стратегией (milk), так как большинство людей предпочтут пить свежее молоко и выдержанное вино, а не наоборот.
Более сложные алгоритмы сброса нагрузки требуют участия отправителей. В качестве примера можно привести пакеты, содержащие сведения о маршрутизации. Они намного важнее обычных пакетов с данными, поскольку устанавливают маршруты; если они будут утеряны, может пострадать связность сети. Другой пример — алгоритмы сжатия видеосигнала (например, MPEG), которые периодически передают полный фрейм, а далее отправляют его измененные версии. В этом случае потеря пакета с изменениями не так страшна, как потеря полного фрейма, так как от него зависят последующие пакеты.
Чтобы реализовать осмысленную стратегию отбрасывания части данных, приложения должны помечать свои пакеты, сообщая сети об их важности. Тогда маршрутизаторы смогут сначала исключить наименее важные пакеты, затем чуть более существенные, и т.д.