Ранее подробно были рассмотрены методы управления перегрузками на базе протокола TCP и был отмечен тот факт, что целью этих методов является обеспечение справедливого распределения ресурсов среди конкурирующих потоков в рамках сетевого узла, причем ресурс, полученный каждым потоком, должен быть ненулевой. Рассмотрим подробно обеспечивает ли алгоритм управления перегрузками на базе алгоритма «аддитивное увеличение - мультипликативное снижение» AIMD (см. п. 1.3.2.5.2, глава 1) «справедливое распределение ресурсов» при условии, что в реальных системах различные соединения TCP устанавливаются в различное время и имеют различные размеры окна. Для ответа на этот вопрос обратимся к доказательству, представленному в [Chiu89]. Рассмотрим простейшую сетевую схему, представленную на рис. 2.4. Два соединения TCP разделяют (совместно используют) полосу пропускания R в рамках одного узла. Предположим, что оба TCP соединения имеют одинаковые MSS и

RTT, тогда если эти соединения имеют одинаковый размер окна, то и создаваемая нагрузка одинакова. Также предположим, что через оба соединения предполагается передача достаточно большого количества данных и никакие другие TCP и UDP потоки не проходят через данный узел. Для простоты пропустим фазу медленного старта для обоих соединений и будем рассматривать случай работы в состоянии предотвращения перегрузки (congestion avoidance mode).

Рис. 2.4. Два соединения ТСР разделяют сетевые ресурсы в рамках одного узла На рис. 2.5 представлен график нагрузки, содаваемой обоими соединениями TCP. Если эти соединения разделяют полосу пропускания поровну, или равномерно, то на графике линия должна быть прочерчена под углом 45 градусов, назовем ее «линией равнозначности». В идеале сумма нагрузок, создаваемых обоими соединениями, должна быть равна максимальной полосе пропускания R. Таким образом, в реальном случае целью является максимально возможное (оптимальное) приближение к линии равнозначности.

Далее рассмотрим алгоритм приближения к линии равнозначности. Пусть в определенный момент времени соединения 1 и 2 создают нагрузку, занимающую полосу пропускания, обозначенную точкой А на рис. 2.5. В связи с тем, что суммарная нагрузка, создаваемая обоими соединениями, не превышает размер максимальной полосы пропускания R, потерь не происходит и каждое соединение повышает значение размера окна на 1*MSS за один RTT (в соответствии с алгоритмом TCP «предотвращения перегрузки» и стратегией «аддитивное увеличение» Additive Increase - см. главу 1, п. 1.3.2.5.2). Таким образом, в связи с увеличением размера окна обоих соединений растет нагрузка и происходит постепенное приближение к линии равнозначности. В определенный момент времени размер полосы пропускания, необходимый для обслуживания суммарной нагрузки, начинает превышать R, вследствие чего происходят потери. Предположим, что впервые в нашем эксперименте потери происходят в точке В. Вследствие перегрузки соединения 1 и 2 уменьшают размер окна в соответствии со стратегией «мультипликативное снижение» Multiplicative Decrease (см. главу 1, п. 1.3.2.5.2), в результате чего нагрузка падает и теперь занимает полосу пропускания, обозначенную С. Далее в соответствии с описанной стратегией за некоторое количество циклов осуществляется максимально возможное приближение к линии равнозначности, при этом суммарная нагрузка продолжает осциллировать относительно R даже при достижении оптимального состояния.

Рис. 2.5. Равнозначное распределение полосы пропускания Рассмотренный пример является достаточно идеализированным, как минимум потому, что мы предположили существование только ТСР соединений, а также в связи с тем, что каждая пара «отправитель-приемник» имело всего одно TCP соединение. В реальных же сетях подобные предположения не выполняются. Достаточно большое количество приложений используют протокол TCP по двум основным причинам: обеспечение надежной передачи данных и возможность использования механизмов управления перегрузками. Однако, большинство современных мультимедийных приложений, таких как распределенные игры, передача видео, 1Р-телефония и пр., используют протокол UDP, а не TCP именно из-за того, что отсутствие механизмов управления трафиком в протоколе UDP делает его более простым, а также делает возможным передачу бесконтрольного количества трафика. Т.е. трафик UDP можно назвать классическим трафиком Best Effort - ни ресурсы, ни источник не контролируются.

Трафик UDP также именуют «неадаптивным» (non-elastic), в отличие от трафика TCP, называемого «адаптивным» (elastic). Например, в случае TCP при обнаружении перегрузки в сети источник понижает нагрузку и в результате, с высокой вероятностью, восстанавливается производительность сети. В свою очередь, UDP трафик бесконтрольно (со стороны источника) заполняет буферные пространства и создает перегрузку, в англоязычной литературе для обозначения подобной ситуации используется термин «to steal buffer space» (воровать буферное пространство). Для упомянутых типов приложений предпочтительным является передача в сеть большого количества UDP пакетов с постоянной скоростью и возможная потеря некоторых пакетов, нежели следование принципу «справедливого распределения ресурсов», вследствие чего необходимо будет увеличивать/уменьшать нагрузку, но не терять пакеты. Исследователями был разработан целый ряд алгоритмов [Anjum99, Floyd99], позволяющих выявлять «неадаптивный» трафик и применять к нему пенализацию.

Однако даже если заставить UDP трафик вести себя в соответствии с принципом «справедливого распределения ресурсов», проблема все-таки не будет решена полностью. Проблема заключается в том, что каждое приложение может для своих нужд использовать несколько параллельно существующих соединений TCP. Когда приложение использует несколько соединений, оно получает большую часть ресурсов по сравнению с приложением, использующим одно TCP соединение. Например, пусть канал с пропускной способностью R используется пятью соединениями TCP, причем каждое соединение принадлежит отдельному приложению. В данном случае каждое приложение использует примерно R -1/5. Пусть новое приложение также использует одно TCP соединение, тогда каждое приложение будет использовать примерно R -1/6. Однако, если новое приложение ини4 Зак. 863

циирует пять TCP соединений, тогда это приложение будет использовать для своих нужд примерно половину всей пропускной способности канала Л, в то время как остальные приложения будут использовать примерно Л-1/10. В этом примере явно представлена возможность несоблюдения принципа «справедливого распределения ресурсов». Описанный пример не является теоретическим, а достаточно часто встречаем, например, в приложениях Web-серфинга.

⇐Принцип «справедливого распределения ресурсов» | Управление трафиком и качество обслужевания в сети | Критерий max-min⇒