Компьютерные сети. 6-е изд. - Эндрю Таненбаум

связь разных типов: явную и неявную, точную и неточную.

Илл. 6.22. (а) Быстрая сеть и получатель с малой емкостью. (б) Медленная сеть и получатель с большой емкостью

Пример явной точной обратной связи — ситуация, когда маршрутизаторы сообщают источникам свою допустимую скорость отправки. Так работает, к примеру, явный протокол перегрузки (eXplicit Congestion Protocol, XCP) (Катаби и др.; Katabi et al., 2002). Явная и неточная схема — использование явного уведомления о перегрузке (Explicit Congestion Notification, ECN) с TCP. В этом случае маршрутизаторы специальным образом маркируют пакеты, страдающие от перегрузки, сообщая отправителю, что ему следует уменьшить скорость передачи данных, но не указывая насколько.

В других схемах явный сигнал отсутствует. FAST TCP измеряет задержку в пути туда и обратно и использует ее в качестве параметра для контроля перегрузки (Вэй и др.; Wei et al., 2006). Наиболее распространенный в современном интернете метод контроля перегрузки использует TCP и маршрутизаторы с отбрасыванием конца очереди или RED-маршрутизаторы. Показателем перегрузки в этом случае является число потерянных пакетов. Существует множество вариантов такого TCP, в частности, CUBIC TCP, используемый в системе Linux (Ха и др; Ha et al., 2008). Возможны комбинации нескольких методов. Например, Windows содержит Compound TCP (составной TCP), где в качестве сигналов обратной связи используется и задержка, и число потерянных пакетов (Тань и др.; Tan et al., 2006). Все эти варианты представлены в таблице на илл. 6.23.

Протокол

Сигнал

Явный?

Точный?

XCP

Скорость, которую следует использовать

Да

Да

TCP с ECN

Предупреждение о перегрузке

Да

Нет

FAST TCP

Сквозная задержка

Нет

Да

Compound TCP

Потеря пакетов и сквозная задержка

Нет

Да

CUBIC TCP

Потеря пакетов

Нет

Нет

TCP

Потеря пакетов

Нет

Нет

Илл. 6.23. Сигналы некоторых протоколов контроля перегрузки

Получив явный и точный сигнал, транспортная подсистема может установить скорость отправки пакетов в соответствии с новым рабочим режимом. К примеру, если XCP сообщает отправителям рекомендуемую скорость, они могут просто использовать ее. Но в остальных случаях транспортные подсистемы вынуждены действовать наугад. В отсутствие сигнала о перегрузке отправители должны увеличивать скорость отправки, а при наличии — уменьшать. Рост и снижение скорости происходит согласно закону управления (control law). Он оказывает решающее влияние на производительность.

Рассматривая бинарный сигнал о перегрузке, Чиу и Джейн (Chiu and Jain, 1989) пришли к выводу, что закон аддитивного увеличения и мультипликативного уменьшения (Additive Increase Multiplicative Decrease, AIMD) позволяет эффективно вычислять рабочий режим с учетом идеи равнодоступности. Чтобы это показать, они привели простой наглядный пример, в котором два соединения соперничают друг с другом за ресурс общего канала. На илл. 6.24 пропускная способность для пользователя 1 располагается на оси X, а для пользователя 2 — на оси Y. При справедливом распределении оба пользователя получают одинаковое количество ресурса. Оно обозначено с помощью прямой равнодоступности (пунктирная линия). Когда суммарная пропускная способность, выделяемая всем пользователям, составляет 100 % (то есть равна емкости канала), распределение эффективно. Оно располагается на прямой эффективности. Когда суммарная

Илл. 6.24. Аддитивное и мультипликативное регулирование пропускной способности

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

Пусть изначально пользователям 1 и 2 выделено некоторое количество пропускной способности. Посмотрим, что произойдет, если они оба начнут аддитивно ее увеличивать. К примеру, они могут повышать скорость отправки пакетов на 1 Мбит/с каждую секунду. В результате рабочий режим пересечет прямую эффективности и оба пользователя получат от сети сигнал о перегрузке. В этот момент им придется снизить свою пропускную способность. Однако аддитивное уменьшение просто приведет к колебаниям значений вдоль аддитивной прямой (см. илл. 6.24). Рабочий режим останется близким к эффективному, однако не обязательно будет справедливым.

Теперь рассмотрим ситуацию, в которой оба пользователя увеличивают свою пропускную способность мультипликативно до тех пор, пока не поступит сигнал о перегрузке. Например, они могут каждую секунду повышать скорость отправки пакетов на 10 %. Если после получения сигнала о перегрузке пользователи начнут мультипликативно уменьшать пропускную способность, рабочий режим будет колебаться вдоль мультипликативной прямой (см. илл. 6.24). Наклон мультипликативной прямой отличается от наклона аддитивной прямой. (Мультипликативная прямая проходит через начало координат, а аддитивная имеет наклон в 45°.) Однако это ничего нам не дает. Ни в том ни в другом случае оптимальная скорость отправки достигнута не будет.

Разберем другой сценарий. Предположим, пользователи аддитивно увеличивают пропускную способность, а после получения сигнала о перегрузке начинают мультипликативно ее уменьшать. Такой метод называется законом управления (AIMD control law) (илл. 6.25). Оказывается, что в результате таких преобразований рабочий режим сходится к оптимальной точке, в которой распределение пропускной способности является одновременно справедливым и эффективным, причем это происходит независимо от начальной точки. Поэтому AIMD широко применяется на практике. При обратном варианте —

Илл. 6.25. Закон управления AIMD

мультипликативном увеличении и аддитивном уменьшении — рабочий режим будет отклоняться от оптимальной точки.

TCP использует AIMD не только по этой причине, но и по соображениям стабильности (поскольку перейти в состояние перегрузки гораздо проще, чем из него выйти, политика увеличения должна быть мягкой, а уменьшения — агрессивной). Но в результате распределение пропускной способности является не совсем справедливым. Дело в том, что размер окна задается исходя из времени в пути туда и обратно (round-trip time, RTT), индивидуального для каждого соединения. Поэтому соединения с ближними хостами получают большую пропускную способность, чем соединения с удаленными хостами (при прочих равных условиях).

В разделе 6.5 мы подробно поговорим о том, как с помощью AIMD в TCP осуществляется регулировка скорости отправки пакетов и контроль перегрузки. Это гораздо сложнее, чем может показаться. Проблемы возникают из-за того, что значения скорости измеряются через определенный интервал времени, а трафик, как правило, неравномерный. Часто вместо прямого регулирования скорости задается размер раздвижного окна. Такая стратегия используется и в TCP. Если размер окна равен W, а время в пути туда и обратно — RTT, то эквивалентная скорость равна W/RTT. Это удобно, поскольку управление потоком данных также основано на регулировке размера окна. Кроме того, такой метод обладает важным преимуществом: если подтверждения о доставке пакетов перестанут приходить, через время RTT скорость отправки уменьшится.

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