Рис. 6.18. Изменение распределения пропускной способности с течением времени

6.3.2. Регулирование скорости отправки

Теперь самое время перейти к основному вопросу: как можно регулировать скорость отправки, чтобы получить необходимую пропускную способность? Скорость отправки может зависеть от двух факторов. Первый из них — управление потоком данных, которое требуется, если буфер получателя обладает недостаточной емкостью. Второй фактор — перегрузка, которую необходимо учитывать при недостаточной пропускной способности сети. На рис. 6.19 эта проблема проиллюстрирована на примере водопровода. На рис. 6.19, а мы видим толстую трубу, ведущую к получателю с небольшой емкостью. Это тот случай, когда ограничительным фактором является управление потоком данных. До тех пор пока отправитель не посылает воды больше, чем может поместиться в ведро, вода не будет проливаться. На рис. 6.29, б ограничительным фактором является не емкость ведра, а пропускная способность сети. Если из крана в воронку вода будет литься слишком быстро, то уровень воды в воронке начнет подниматься, и, в конце концов, часть воды может перелиться через край воронки.

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

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

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

Рис. 6.19. Быстрая сеть и получатель малой емкости (а); медленная сеть и получатель большой емкости (б)

В других схемах явный сигнал отсутствует. FAST TCP измеряет круговую задержку и использует ее в качестве параметра для контроля перегрузки (Wei и др., 2006). Наконец, метод контроля перегрузки, наиболее распространенный в современном Интернете, использует TCP и маршрутизаторы с отбрасыванием конца очереди или маршрутизаторы со случайным ранним обнаружением перегрузки. Показателем перегрузки сети в нем является число потерянных пакетов. Существует множество вариантов этого вида TCP — в частности, CUBIC TCP, использующийся в системе Linux (Ha и др., 2008). Возможны также комбинации нескольких методов. К примеру, Windows включает Compound TCP (составной TCP), в котором показателями насыщения являются и круговая задержка, и число потерянных пакетов (Tan и др., 2006). Эти схемы показаны в табл. 6.3.

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

Таблица 6.3. Сигналы некоторых протоколов контроля насыщения

Протокол

Сигнал

Явный?

Точный?

XCP

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

Да

Да

TCP с ECN

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

Да

Нет

FAST TCP

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

Нет

Да

Compound TCP

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

Нет

Да

CUBIC TCP

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

Нет

Нет

TCP

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

Нет

Нет

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

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

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

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

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