Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Рис. 6.21.Закон управления AIMD

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

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

Наконец, иногда в одной сети используются разные транспортные протоколы. Что произойдет, если эти протоколы будут одновременно пытаться контролировать перегрузку с помощью разных законов управления? Ответ очевиден: распределение пропускной способности не будет справедливым. Поскольку самой распространенной формой контроля перегрузки в сети Интернет является TCP, новые транспортные протоколы настоятельно рекомендуется разрабатывать так, чтобы при совместной работе с TCP выполнялось условие справедливого распределения ресурсов. Использовавшиеся ранее протоколы потокового вещания не соответствовали этому требованию, существенно уменьшая пропускную способность TCP. В результате стала развиваться идея дружественного к TCP контроля перегрузки, при котором транспортные протоколы TCP и не-TCP могут работать вместе, не мешая друг другу (Floyd и др., 2000).

6.3.3. Проблемы беспроводного соединения

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

Если протокол использует закон управления AIMD, большая пропускная способность требует минимальной потери пакетов. Исследования Padhye и др. (1998) показали, что пропускная способность растет обратно пропорционально квадратному корню из скорости потери пакетов. На практике это означает, что скорость потери пакетов для быстрых TCP-соединений очень мала; в среднем этот показатель составляет 1 %, а при значении 10 % соединение перестает работать. Однако для беспроводных сетей, таких как локальная сеть 802.11, вполне обычными являются значения скорости потери кадров порядка 10 % и выше. Если этого не учитывать, схемы контроля перегрузки, использующие в качестве сигнала насыщения потерю пакетов, попросту «задушат» беспроводные соединения, крайне ограничив их скорость.

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

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

Рис. 6.22.Контроль перегрузки для пути, содержащего беспроводной канал

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

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