Компьютерные сети

Многоуровневая архитектура Интернета

Архив за апреля, 2008

Выравнивание скоростей

Опубликовано 20 апреля, 2008

Предположим, что к TCP-соединений между разными хостами используют одну и ту же проблемную линию связи с пропускной способностью R бит/с (говоря «проблемная линия», мы имеем в виду, что в каждом соединении все остальные линии связи не перегружены и скорость передачи по ним значительно ближе к их пропускной способности, чем по проблемной линии). Предположим, что по каждому из соединений передается файл большого размера и в проблемной линии связи отсутствует UDP-трафик. Говорят, что механизм контроля перегрузки обеспечивает выравнивание скоростей, если средняя скорость передачи каждого соединения составляет приблизительно R/K; другими словами, пропускная способность линии связи делится между всеми использующими ее соединениями поровну.
Читать далее »

Мы знаем, что регулирование скорости передачи протоколом TCP приводит к графику, напоминающему зубья пилы (см. рис. 3.46). Каково среднее значение скорости передачи ТСР-соединения с длительным временем жизни? Мы попытаемся ответить на этот вопрос, исключив из рассмотрения фазы медленного старта (как правило, они являются очень короткими, поскольку передающая сторона экспоненциально наращивает скорость передачи). Скорость передачи во время оборота определяется текущим размером окна перегрузки и длительностью интервала. Ранее мы упоминали, что если размер окна составляет w байтов, а время оборота равно величине RTT, то скорость передачи источника определяется как w/KYT. TCP увеличивает скорость передачи на величину MSS каждый раз по истечении времени оборота до тех пор, пока не произойдет потеря пакета. Пусть W — размер окна в момент обнаружения факта потери пакета; учитывая, что значения Wu RTT почти не меняются для конкретного соединения, скорость передачи источника находится в интервале от W/(2 х RTT) до W/RTT.
Читать далее »

Находится в разделе Контроль перегрузок в TCP

Согласно предыдущему описанию, размер окна перегрузок протокола TCP, будучи изначально равным величине MSS, экспоненциально растет до первой потери пакета, после чего в силу вступает алгоритм аддитивного увеличения и мультипликативного уменьшения. Эта картина уже весьма близка к реальной, однако и она останется неполной, если мы не раскроем еще одну деталь механизма контроля перегрузок TCP: оказывается, по истечении интервала ожидания протоколом предпринимаются иные действия, нежели при получении трех дублирующих квитанций. В последнем случае поведение TCP соответствует описанному выше: размер окна перегрузки уменьшается вдвое, а затем начинает линейно расти. Однако по истечении интервала ожидания передающая сторона TCP входит в состояние медленного старта, уменьшая размер окна перегрузки до величины MSS и далее позволяя ему увеличиваться по экспоненциальному закону до тех пор, пока он не достигнет половины своего значения до истечения интервала ожидания. После этого рост значения CongWin вновь становится линейным.
Читать далее »

Находится в разделе Контроль перегрузок в TCP

Медленный старт

Опубликовано 17 апреля, 2008

При установлении TCP-соединения начальным значением переменной CongWin является величина MSS; следовательно, начальная скорость передачи источника составляет MSS/RTT, где RTT — время оборота для соединения. Например, если MSS = 500 байт, a RTT = 200 мс, то начальная скорость передачи соединения равна приблизительно 20 Кбайт. Поскольку максимально возможная скорость передачи значительно превосходит величину MSS/RTT, линейное увеличение начальной скорости нерационально, так как этот процесс тянется слишком долго. Для решения проблемы на начальном этапе вместо линейного увеличения используется экспоненциальное увеличение, то есть значение CongWin возрастает вдвое после каждого истечения времени оборота. Экспоненциальный рост продолжается до первой потери пакета, после чего значение CongWin уменьшается вдвое и в дальнейшем увеличивается по линейному закону. Итак, в первой фазе, называемой медленным стартом, источник начинает передачу с низкой скоростью, которая растет по экспоненциальному закону. Подобный рост обеспечивается следующим образом.
Читать далее »

Находится в разделе Контроль перегрузок в TCP

Основной идеей механизма контроля перегрузки протокола TCP является снижение скорости передачи источника путем уменьшения размера его окна перегрузок при потере пакета. Вполне вероятно, что во всех TCP-соединениях, обслуживаемых перегруженным маршрутизатором, наблюдаются потери пакетов, что приводит к одновременному уменьшению окон перегрузок всеми этими соединениями. Конечный эффект заключается в снижении трафика, проходящего через перегруженный маршрутизатор и, как следствие, в ослаблении перегрузки. Однако все еще остается открытым вопрос о том, насколько существенным должно быть снижение скорости передачи при потере пакета. В протоколе TCP используется так называемое «мультипликативное уменьшение», означающее двойное уменьшение размера окна перегрузки при потере пакета. Если потеря пакета произошла при значении CongWin, равном 20 Кбайт, то последнее будет «урезано» до 10 Кбайт. В случае потери еще одного пакета значение CongWin станет равным 5 Кбайт. Уменьшение размера окна перегрузки может происходить многократно, однако значения CongWin, меньшие максимального размера сегмента (MSS), не допускаются. Заметим, что приведенное выше описание является упрощенным, и изменение размера окна перегрузки на самом деле представляет собой несколько более сложный процесс. Как мы увидим чуть позже, при потере пакета значение CongWin сначала становится равным MSS и лишь затем достигает половины исходного значения.
Читать далее »

Находится в разделе Контроль перегрузок в TCP

Механизм контроля перегрузок в TCP

Опубликовано 15 апреля, 2008

В этом разделе мы вновь возвращаемся к протоколу TCP. Как вы знаете (см. раздел «Протокол TCP — передача с установлением соединения»), TCP предоставляет службу надежной передачи данных прикладным процессам, выполняющимся на разных хостах. Другим ключевым компонентом протокола TCP является механизм контроля перегрузок. В предыдущем разделе мы отметили, что TCP осуществляет контроль перегрузок самостоятельно, поскольку протокол сетевого уровня IP не имеет механизмов поддержания явной обратной связи между сетевыми устройствами и оконечными системами, которые позволили бы информировать отправителей о наличии перегрузок в сети.
Читать далее »

Находится в разделе Контроль перегрузок в TCP

Контроль перегрузок в службе ABR сетей ATM

Опубликовано 14 апреля, 2008

В разделе «Контроль перегрузок в ТСР» мы подробно рассмотрим механизмы контроля перегрузки оконечными системами на примере протокола TCP, а сейчас остановимся на службе ABR сетей ATM, в которой реализован другой вид контроля перегрузок с сетевой поддержкой. Служба ABR была разработана для «эластичной» передачи данных в стиле протокола TCP. При низких нагрузках в сети служба ABR должна была улучшать качество обслуживания, используя свободные ресурсы, а в условиях перегрузки снижать скорости передачи до заранее установленного минимума. Детальное описание механизмов контроля перегрузок в службе ABR сетей ATM и управления трафиком в сетях ATM можно найти в. На рис. 3.45 представлена схема ABR-контроля перегрузки в сетях ATM. Ниже мы будем придерживаться терминологии, принятой в ATM, и употреблять вместо терминов «маршрутизатор» и «пакет» термины «коммутатор» и «ячейка» соответственно. При использовании службы ABR ячейки передаются от отправителя к получателю через последовательность коммутаторов. Среди ячеек с данными содержатся служебные ячейки управления ресурсами (Resource Management, RM). RM-ячейки используются для обмена информацией о перегрузках между хостами и коммутаторами. Получатель отсылает RM-ячейки обратно отправителю, иногда внося изменения в их содержимое. Коммутатор может самостоятельно генерировать RM-ячейки и отправлять их нужным хостам. Таким образом, с помощью RM-ячеек возможна организация как прямой обратной связи, так и обратной связи «через получателя».
Читать далее »

Подходы к контролированию перегрузки

Опубликовано 13 апреля, 2008

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

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

Последнюю ситуацию иллюстрирует рис. 3.42. Четыре хоста обмениваются пакетами, при этом пути пакетов накладываются друг на друга, и каждый путь проходит через два маршрутизатора. Как и ранее, мы будем предполагать, что хосты используют надежную передачу данных, осуществляемую при помощи механизмов интервалов ожидания и повторных передач, скорость передачи всех хостов одинакова и составляет λ(вх), а пропускные способности линий связи равны R байт/с.
Читать далее »

Находится в разделе Причины и следствия перегрузки

Давайте внесем в предыдущую ситуацию несколько изменений (рис. 3.40). Во-первых, будем считать объем буферного пространства маршрутизатора конечным. Это сделает ситуацию более реалистичной, поскольку пакеты, достигающие маршрутизатора с заполненным буфером, будут теряться. Во-вторых, мы предположим, что каждое из соединений является надежным, то есть транспортный уровень осуществляет повторную передачу каждого потерянного пакета. Мы снова обозначим через λ(вх) скорость передачи данных приложения через сокет, а через λ’(вх) — скорость передачи транспортным уровнем сегментов, включающих как новые, так и повторно передаваемые данные. Величину λ’(вх) часто называют прилагаемой нагрузкой.
Читать далее »

Находится в разделе Причины и следствия перегрузки