Содержание к диссертации
Введение
ГЛАВА 1 Анализ основных алгоритмов протокола TCP 17
1.1 Введение и постановка задачи 17
1.2 Архитектура протокола TCP 18
1.2.1 Стек протоколов TCP/IP 18
1.2.2 Формат TCP-сегмента 19
1.3 Основные функции и алгоритмы протокола TCP 23
1.3.1 Назначение протокола TCP. Общие положения 23
1.3.2 Базовая передача данных 24
1.3.3 Процедура мультиплексирования/демультиплексирования 24
1.3.4 Обеспечение достоверности 24
1.3.5 Управление соединением 27
1.3.6 Управление потоком 29
1.3.7 Управление перегрузкой и
особенности различных реализаций протокола TCP 32
1.4 Анализ использования различных реализаций протокола TCP 44
Выводы 46
ГЛАВА 2 Анализ основных методов оценки средней скорости передачи данных по протоколу tcp 47
2.1 Введение и постановка задачи 47
2.2 Математическая модель общей реализации протокола TCP (Tcpreno/Newreno/Sack) 49
2.2.1 Используемые предположения 49
2.2.2 Построение модели 50
2.2.3 Анализ модели 53
2.3 Математическая модель tcp reno (pftk-модель) 53
2.3.1 Используемые предположения 54
2.3.2 Построение модели 55
2.3.3 Анализ модели 70
Выводы 74
ГЛАВА 3 Разработка методов оценки средней скорости передачи данных по протоколу TCP 75
3.1 Введение и постановка задачи 75
3.2 Используемые предположения 76
3.3 Метод оценки средней скорости передачи данных по протоколу TCP RENO 78
3.3.1 Обнаружение потери в результате получения трех повторных АСК. 78
3.3.2 Обнаружение потери в результате получения трех повторных АСК или истечения RTO ...86
3.3.3 Ограничение скорости передачи данных со стороны приемника 91
3.3.4 Результирующая формула средней скорости передачи данных по протоколу TCP Reno 94
3.4 Метод оценки средней скорости передачи данных по протоколу tcp newreno (вариант slow-but-steady) 94
3.4.1 Обнаружение потери в результате получения трех повторных АСК. 95
3.4.2 Обнаружение потери в результате получения трех повторных АСК или истечения RTO 103
3.4.3 Ограничение скорости передачи данных со стороны приемника 107
3.4.4 Результирующая формула средней скорости передачи данных
по протоколу TCP NewReno (вариант Slow-but-Steady) ПО
Выводы ПО
ГЛАВА 4 Анализ точности разработанных методов оценки средней скорости передачи данных по протоколу TCP 112
4.1 Введение и постановка задачи 112
4.2 Сценарий имитационного моделирования 113
4.2.1 Конкурирующий трафик 114
4.2.2 Топология сети и параметры конфигурации 115
4.3 Анализ точности разработанного метода оценки средней скорости передачи данных по протоколу tcp reno 118
4.4 Анализ точности разработанного метода оценки средней скорости передачи данных по протоколу TCP Newreno 123
Выводы 129
Заключение 131
Список литературы
- Архитектура протокола TCP
- Математическая модель общей реализации протокола TCP (Tcpreno/Newreno/Sack)
- Метод оценки средней скорости передачи данных по протоколу TCP RENO
- Сценарий имитационного моделирования
Введение к работе
Актуальность проблемы. Протокол управления передачей (Transmission
Control Protocol, TCP) является доминирующим протоколом транспортного
уровня в Интернет. Согласно исследованиям [70], от 60% до 90% всего трафика в
Интернет, включая трафик службы World Wide Web, передачи файлов (FTP),
электронной почты (E-mail) и т.д., передается с помощью протокола TCP. Столь
широкое применение протокола TCP определило пристальное внимание к нему со
стороны специалистов, занимающихся проблемами обеспечения качества
обслуживания (Quality of Service, QoS) в Интернет. Помимо традиционных
измерений и имитационного моделирования, в последнее десятилетие
значительное число исследовательских работ [21,23,27-
29,31,32,34,35,50,55,56,62,63,66,71,75,78,80-82,89,96,112,121] было адресовано разработке математических моделей функционирования протокола TCP. В числе авторов, получивших важные результаты в этой области, можно отметить К.Авраченкова, M.Mathis, J.Padhye, N.Cardwell, B.Sikdar и ряд других авторов.
В то же время предполагается [13,15,36,57,65,74,76], что одну из основных составляющих трафика Интернет в ближайшем будущем будут создавать услуги передачи мультимедийной информации: потоковое видео, Интернет-радио и т.п. Согласно принятой классификации [18], создаваемый данными услугами трафик характеризуется как изохронный и устойчивый к потерям. Изохронность трафика предполагает, что имеется некоторый порог чувствительности к задержкам, при превышении которого резко снижается качество предоставляемой услуги (например, превышение порога задержки в 100-150 мс при передаче голоса резко снижается качество воспроизводимого голоса). Устойчивость данного трафика к потерям объясняется тем, что небольшое количество отсутствующих данных может быть заменено аппроксимацией на основе принятых данных, а также тем, что услуги потокового типа ориентированы на передачу аудио/видео информации и ее незамедлительное воспроизведение, в результате чего оконечный пользователь и является той системой, которая оценивает качество предоставляемой услуги. Устойчивость к потерям также имеет свои границы,
поэтому процент потерянных пакетов не должен превышать некоторый предел (например, не более 1 %).
В связи с отмеченными особенностями, применение протокола передачи пользовательских дейтаграмм (User Datagram Protocol, UDP) для потокового мультимедийного трафика предпочтительнее, чем протокола TCP, так как реализованная в протоколе TCP функция управления перегрузкой с резким уменьшением скорости передачи при обнаружении потери может существенно ухудшить качество предоставляемой услуги за счет увеличения задержки доставки данных и дисперсии этой задержки [15,44,61,76,81,107]. Однако отсутствие каких-либо алгоритмов управления перегрузкой в протоколе UDP может привести к ухудшению условий функционирования параллельных соединений TCP (т.е. соединений TCP, использующих общий канальный ресурс совместно с потоками UDP), а также к перегрузке сети [25,51,52,57,72,74,90].
В последние годы был предложен ряд механизмов [22,25,33,45-46,77,81,91,101,103,106,115-117], позволяющих осуществлять адаптивное управление трафиком, создаваемым, в том числе, и потоками UDP. Протокол дружественного TCP управления скоростью передачи данных (TCP Friendly Rate Control, TFRC), определенный в документе RFC 3448 [103], является одним из наиболее проработанных и перспективных механизмов для адаптивного управления скоростью передачи данных и реализации функции управления перегрузкой при использовании протокола UDP для передачи потокового мультимедийного трафика. Протокол TFRC позволяет прикладному процессу передавать данные примерно с той же скоростью, что и протокол TCP в аналогичных условиях, но при этом избегая резкого уменьшения скорости передачи данных в случае потери пакетов. При использовании данного протокола приемник TFRC сообщает передатчику информацию о потерях, а передатчик TFRC рассчитывает скорость передачи данных на основе полученной информации, времени обращения пакета и формулы, определяющей среднюю скорость передачи данных по протоколу TCP в аналогичных условиях.
Данная формула была получена в работе J.Padhye, V.Firoiu, D.Towsley и J.Kurose (и широко известна как PFTK-модель) на основе математического
моделирования передачи данных по протоколу TCP Reno [82] в длительном соединении в условиях пачечного процесса потерь, возникающим при использовании в маршрутизаторах алгоритма усечения хвоста очереди (Tail-Drop) с дисциплиной обслуживания FIFO (First In, First Out). В то же время анализ показывает, что используемое в PFTK-модели упрощенное представление таких алгоритмов, как быстрая повторная передача и быстрое восстановление, а также отсутствие рассмотрения фазы медленного запуска после таймаута может приводить к существенно завышенной оценке средней скорости передачи данных по протоколу TCP Reno в условиях пачечного процесса потерь.
Необходимо отметить, что указанная модель является одной из важнейших в области математического моделирования функционирования протокола TCP. Результирующая формула, полученная в данной работе, часто применяется для проверки адекватности новых математических моделей [21,31,55,96], а также используется в различных исследовательских работах [34,56,75,112] и книгах [14,95]. Как следствие, неточность данной формулы может приводить к неверным результатам или некорректным выводам. Следовательно, представляется необходимой разработка метода оценки средней скорости передачи данных по протоколу TCP Reno с более полным учетом алгоритмов, используемых в протоколе TCP.
Более того, согласно исследованиям [73,83], наиболее распространенной на сегодняшний день реализацией протокола TCP является TCP NewReno [109]. Анализ опубликованных исследований показывает, что недостаточное внимание было уделено математическому моделированию передачи данных по протоколу TCP NewReno. Соответственно, важной задачей является разработка метода оценки средней скорости передачи данных по протоколу TCP NewReno для последующего использования полученной формулы в протоколе TFRC.
Таким образом, теоретическая и практическая значимость решаемых в диссертационной работе задач определяет ее актуальность.
Цель и задачи исследований. Целью диссертационной работы является разработка методов оценки средней скорости передачи данных по протоколу TCP. С учетом вышесказанного, в качестве рассматриваемых реализаций протокола
TCP были выбраны следующие реализации: TCP Reno и TCP NewReno (вариант Slow-but-Steady). При этом поставленная цель достигается путем решения следующих основных задач:
Анализ основных алгоритмов, используемых в протоколе TCP для обеспечения гарантированной доставки данных, управления потоком данных и реакции на перегрузку сети.
Анализ существующих методов оценки средней скорости передачи данных по протоколу TCP. Определение возможных подходов к разработке метода оценки средней скорости передачи данных по протоколу TCP и недостатков существующих методов.
Разработка метода оценки средней скорости передачи данных по протоколу TCP Reno.
Разработка метода оценки средней скорости передачи данных по протоколу TCP NewReno (вариант Slow-but-Steady).
5. Анализ адекватности разработанных методов. Сравнение разработанных
методов с существующими и результатами имитационного моделирования.
Методы исследования. Проведенные в диссертационной работе исследования основываются на теории вероятностей, теории восстановления, математической статистике и высшей алгебре.
Для проведения численных расчетов и статистического анализа в диссертационной работе использовался пакет программ Mathcad 2000 Professional. Для проверки адекватности разработанных методов оценки средней скорости передачи данных по протоколу TCP использовался программный продукт моделирования сетей связи ns-2 [124]. Для анализа и обработки данных, полученных в результате имитационного моделирования, использовались утилиты awk [123] и Windows Grep [125].
Научная новизна. Основными результатами диссертационной работы, обладающими научной новизной, являются: - метод оценки средней скорости передачи данных по протоколу TCP Reno в
длительном соединении в условиях пачечного процесса потерь;
- метод оценки средней скорости передачи данных по протоколу TCP NewReno
(вариант Slow-but-Steady) в длительном соединении в условиях пачечного
процесса потерь.
Практическая ценность. Основным результатом диссертационной работы, обладающим практической ценностью, являются методы оценки средней скорости передачи данных по протоколу TCP Reno и TCP NewReno в длительном соединении в условиях пачечного процесса потерь.
Использование результатов работы в протоколе TFRC для адаптивного управления скоростью передачи потокового мультимедийного трафика по протоколу UDP позволит обеспечить совместимость с соединениями TCP, где, согласно документу RFC 2309 [90], TCP-совместимым потоком является поток, реагирующий на сообщения о перегрузке и средняя скорость передачи данных которого в установившемся состоянии не превышает среднюю скорость передачи данных в соединении TCP в аналогичных условиях.
Апробация работы и публикации. Результаты диссертационной работы были представлены в форме докладов [6-11,41-43] на следующих научно-технических конференциях:
56-я научно-техническая конференция профессорско-преподавательского состава, научных сотрудников и аспирантов ГУТ им. проф. М.А. Бонч-Бруевича, Санкт-Петербург, 26-30 января, 2004 г.
57-я научно-техническая конференция профессорско-преподавательского состава, научных сотрудников и аспирантов ГУТ им. проф. М.А. Бонч-Бруевича, Санкт-Петербург, 24-28 января, 2005 г.
8-я международная конференция «Internet, Multimedia Systems and Applications», Кауаи (США), 16-18 августа, 2004 г.
3-й международный семинар «Internet Performance, Simulation, Monitoring and Measurements», Варшава (Польша), Технологический Университет Варшавы, 14-15 марта, 2005 г.
3-я международная конференция «Wired/Wireless Internet Communications», Ксанти (Греция), 11-13 мая, 2005 г.
Основные положения, выносимые на защиту:
новые аналитические результаты функционирования протокола TCP в условиях пачечного процесса потерь;
метод оценки средней скорости передачи данных по протоколу TCP Reno в длительном соединении в условиях пачечного процесса потерь;
метод оценки средней скорости передачи данных по протоколу TCP NewReno (вариант Slow-but-Steady) в длительном соединении в условиях пачечного процесса потерь;
численные оценки средней скорости передачи данных по протоколам TCP Reno и TCP NewReno, которые позволяют доказать необходимость учета алгоритмов быстрой повторной передачи, быстрого восстановления и медленного запуска в условиях пачечного процесса потерь.
Личный вклад автора. Основные положения, теоретические выводы и рекомендации, содержащиеся в диссертационной работе, получены автором самостоятельно.
Публикации. Основные результаты диссертационной работы представлены в 9 печатных работах.
Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы и трех приложений.
Работа содержит 155 страниц машинописного текста, включая 37 рисунков, список литературы из 125 наименований и приложения.
СОДЕРЖАНИЕ РАБОТЫ
Во введении обоснована актуальность исследования, сформулированы цели и задачи диссертационной работы, перечислены основные полученные результаты диссертации, определены практическая ценность и области использования полученных результатов. Приведены сведения об апробации работы, представлены основные положения, выносимые на защиту.
В первой главе проводится аналитический обзор алгоритмов, определенных в документах RFC и используемых в протоколе TCP. Анализ проводится с целью выявления основных алгоритмов, которые должны быть учтены в
разрабатываемых методах оценки средней скорости передачи данных по протоколу TCP.
Проведенный анализ показал, что основными алгоритмами, используемыми в протоколе TCP для обеспечения гарантированной доставки данных, управления потоком данных и реакции на перегрузку сети, и, соответственно, которые должны учитываться при разработке методов оценки средней скорости передачи данных по протоколу TCP, являются следующие алгоритмы:
алгоритм определения времени обращения сегмента;
алгоритм управления таймером повторной передачи;
алгоритм Карна;
алгоритм скользящего окна;
алгоритм анонса окна приемника;
алгоритм подтверждения с задержкой;
алгоритм медленного запуска;
алгоритм предотвращения перегрузки;
алгоритм быстрой повторной передачи;
алгоритм быстрого восстановления;
алгоритм реакции на получение частичного подтверждения (в TCP NewReno).
При этом основное отличие между реализациями TCP Reno и TCP NewReno состоит в использовании алгоритмов быстрого восстановления и реакции на получение частичного подтверждения.
Анализ также показал, что, согласно исследованиям [73,83], на сегодняшний день наиболее распространенной реализацией протокола TCP является TCP NewReno.
Во второй главе проводится анализ существующих методов оценки средней скорости передачи данных по протоколу TCP с целью выявления основных подходов к разработке метода оценки средней скорости передачи данных по протоколу TCP для последующего использования в протоколе TFRC.
В данной главе были рассмотрены математическая модель, представленная в работе M.Mathis и др. [71], а также математическая модель, представленная в работе J.Padhye, V.Firoiu, D.Towsley и J.Kurose (PFTK-модель) [82].
Проведенный анализ показал, что оценка среднего значения скорости передачи данных может быть получена на основе теории восстановления как отношение математического ожидания числа сегментов данных, переданных в течение цикла, к математическому ожиданию длительности цикла. При этом значение средней скорости передачи данных определяется как функция от следующих параметров:
вероятность потери сегмента данных;
среднее время обращения сегмента;
средняя длительность таймаута повторной передачи;
число сегментов данных, подтверждаемых одним сегментом
подтверждения;
- максимальное значение окна приемника.
Было доказано, что рассмотренные математические модели имеют ряд существенных недостатков. В частности, данные математические модели не учитывают алгоритмы быстрой повторной передачи, быстрого восстановления и медленного запуска, рассматривая в качестве цикла лишь фазу предотвращения перегрузки между обнаружениями потерь сегментов данных.
Проведенный анализ показал, что если при передаче окна, состоящего из W сегментов данных и потере последовательности сегментов данных, вероятность того, что будет потеряно S сегментов, имеет равномерное распределение от 1 до W, то при использовании реализации TCP Reno и обнаружении потери первого сегмента данных (из числа потерянных) в результате получения трех повторных подтверждений, будет иметь место следующая последовательность действий:
получение трех повторных подтверждений;
инициирование алгоритмов быстрой повторной передачи и быстрого восстановления, повторная передача первого потерянного сегмента данных;
ожидание истечения таймера повторной передачи, установленного после подтверждения приема повторно переданного сегмента данных;
инициирование алгоритма медленного запуска.
Так как при этом происходит существенное снижение скорости передачи данных, то неучет фаз быстрой повторной передачи, быстрого восстановления и медленного запуска может приводить к завышенной оценке средней скорости передачи данных по протоколу TCP Reno в условиях пачечного процесса потерь.
В третьей главе разработаны методы оценки средней скорости передачи данных по протоколам TCP Reno и TCP NewReno (вариант Slow-but-Steady) в длительном соединении в условиях пачечного процесса потерь.
При разработке методов оценки средней скорости передачи данных по протоколу TCP функционирование передатчика TCP рассматривается с точки зрения «раундов». Под раундом понимается интервал времени, который начинается с передачей первого сегмента данных в соответствии с текущим значением скользящего окна и завершается с получением первого подтверждения для одного из переданных в данном окне сегментов данных.
Аналогично PFTK-модели, разработка методов оценки средней скорости передачи данных по протоколу TCP осуществляется поэтапно. На первом этапе определяется средняя скорость передачи данных исходя из предположения, что обнаружение потери первого из числа потерянных в одном раунде сегментов данных происходит исключительно в результате получения трех повторных подтверждений. На втором этапе рассматривается случай с обнаружением потери первого из числа потерянных в одном раунде сегментов данных как в результате получения трех повторных подтверждений, так и в результате истечения таймаута повторной передачи, и определяется влияние последовательности таймаутов на среднюю скорость передачи данных. При этом в обоих случаях предполагается, что величина скользящего окна (и, соответственно, скорость передачи данных) определяется лишь значением окна перегрузки. На заключительном этапе рассматривается случай с ограничением величины скользящего окна (и, соответственно, скорости передачи данных) со стороны приемника.
В четвертой главе проводится анализ точности разработанных методов оценки средней скорости передачи данных по протоколам TCP Reno и TCP NewReno на основе имитационного моделирования, а также сравнение с PFTK-моделью и формулой, используемой в протоколе TFRC.
Для имитационного моделирования использовался программный продукт имитационного моделирования сетей связи ns-2 [124].
Показано, что разработанные методы оценки средней скорости передачи данных по протоколам TCP Reno и TCP NewReno достаточно хорошо согласуются с результатами имитационного моделирования, при этом погрешность оценки средней скорости передачи данных составляет в среднем менее 5% при различных значениях конкурирующего трафика.
Также показано, что PFTK-модель и формула, используемая в протоколе TFRC, дают существенно завышенную оценку средней скорости передачи данных по протоколам TCP Reno и TCP NewReno соответственно, при этом погрешность оценки для PFTK-модели составляет в среднем около 50%, а для формулы, используемой в протоколе TFRC - около 40%. Учитывая, что, согласно исследованиям, реализация TCP NewReno является доминирующей в Интернет, подобное завышение может приводить к более «агрессивному» поведению соединений, использующих протокол TFRC, по сравнению с соединениями TCP.
Таким образом, использование разработанных методов в протоколе TFRC для адаптивного управления скоростью передачи потокового мультимедийного трафика по протоколу UDP позволит обеспечить совместимость данных потоков с соединениями TCP в соответствии с требованиями документа RFC 2309 [90].
Архитектура протокола TCP
Протокол управления передачей (Transmission Control Protocol, TCP) был официально определен в 1981 году в [113]. На сегодняшний день протокол TCP, совместно с протоколом межсетевого взаимодействия (Internet Protocol, IP) [60], составляют основу стека (семейства) протоколов TCP/IP. Согласно исследованиям [70], от 60% до 90% всего трафика в Интернет передается по протоколу TCP. Такие популярные службы как World Wide Web (WWW), служба передачи файлов, электронная почта (E-mail) и многие другие используют для надежной передачи данных протокол TCP. Столь широкое применение протокола TCP определило пристальное внимание к нему со стороны специалистов, занимающихся проблемами обеспечения качества обслуживания (Quality of Service, QoS) в Интернет. При этом, помимо традиционных измерений и имитационного моделирования, в последнее десятилетие значительное число исследовательских работ [21,23,27-29,31,32,34,35,50,55,56,62,63,66,71,75,78,80-82,89,96,112,121] было адресовано разработке математических моделей функционирования протокола TCP.
Целью данной главы является аналитический обзор алгоритмов, используемых в протоколе TCP для обеспечения гарантированной доставки данных, управления потоком данных и реакции на перегрузку сети. Анализ проводится с целью выявления основных алгоритмов, которые должны быть учтены в разрабатываемом методе оценки средней скорости передачи данных по протоколу TCP.
В данной главе рассмотрены основные функции и алгоритмы протокола TCP в соответствии с [37,59,92,102,104,105,108,109,113]. После краткого обзора стека протоколов TCP/IP приведено описание формата TCP-сегмента. Далее определены основные функции протокола TCP и алгоритмы, используемые для выполнения данных функций, а также представлены основные отличия различных реализаций протокола TCP.
TCP/IP - собирательное название для стека протоколов разных уровней, используемых в Интернет. Стек протоколов ТСРЯР делится на четыре уровня [12,18,69]: прикладной (Application), транспортный (Transport), межсетевой (Internet) и уровень сетевого интерфейса (Network interface). Термины, применяемые для обозначения блока передаваемых данных, различны [18] при использовании разных протоколов транспортного уровня - TCP и протокола передачи пользовательских дейтаграмм (User Datagram Protocol, UDP) [114] (рис. 1.1).
Соответствие уровней стека TCP/IP семиуровневой модели взаимодействия открытых систем (Open System Interconnection, OSI) показано на рис. 1.2 [17,69].
Заголовок TCP-сегмента состоит из 32-разрядных слов и имеет переменную длину, зависящую от размера поля «Опции», но всегда кратную 32 битам. За заголовком непосредственно следуют данные - часть потока данных прикладного процесса, передаваемая в данном ТСР-сегменте. Значения полей заголовка следующие. Номер порта отправителя (source port) (16 бит), номер порта получателя (destination port) (16 бит) - номера портов процесса-отправителя и процесса-получателя соответственно.
Порядковый номер (Sequence Number, SN) (32 бита) - порядковый номер первого байта в поле данных TCP-сегмента среди всех байтов потока данных для текущего соединения, т.е. идентификация положения текущего TCP-сегмента в потоке данных отправителя. Если в заголовке TCP-сегмента установлен бит SYN (фаза установления соединения), то в поле SN записывается начальный номер (Initial Sequence Number, ISN). Номер первого байта данных, посылаемых после завершения фазы установления соединения, равен ISN+1.
Номер сигнала подтверждения (acknowledgment number) (32 бита) - если установлен бит АСК, то это поле содержит порядковый номер байта, который отправитель данного TCP-сегмента желает получить. Это означает, что все предыдущие байты (с номерами от ISN+1 до АСК-1 включительно) были успешно получены.
Длина заголовка (data offset) (4 бита) - длина TCP-заголовка в 32-битных словах (указывается смещение области данных относительно начала ТСР-сегмента).
Резерв (reserved) (6 бит) - зарезервировано для использования в будущих стандартах протокола; заполняется нулями. Код TCP-сегмента (control bits) (6 бит) - управляющие биты, определяющие формат и содержимое TCP-сегмента; активным является положение «бит установлене 1»: URG - поле указателя срочных данных задействовано; АСК - поле подтверждения приема задействовано; PSH - осуществить немедленную отправку данных. Если модуль TCP получает TCP-сегмент с установленным битом PSH, то он немедленно передает все данные из буфера приема процессу-получателю для обработки, даже если буфер не был заполнен; RST - сброс текущего соединения; SYN - запрос на установление соединения; FIN - запрос на закрытие соединения. Размер окна (window) (16 бит) - размер окна в байтах. В данном поле модуль TCP указывает количество байтов, которые он может принять (т.е. указывает размер своего приемного буфера).
Контрольная сумма (checksum) (16 бит) - контрольная сумма, представляет собой 16-битовое целое число, которое используется для проверки целостности полученных данных и заголовка TCP-сегмента (само поле контрольной суммы перед вычислением обнуляется). Контрольная сумма, кроме заголовка ТСР-сегмента и поля данных, учитывает 96 бит псевдозаголовка, который для внутреннего употребления ставится перед ТСР-заголОБКОМ. Этот псевдозаголовок содержит IP-адрес отправителя (4 байта), IP-адрес получателя (4 байта), нулевой байт, 8-битное поле «Тип протокола», аналогичное полю в IP-заголовке, и 16 бит длины TCP-сегмента, измеренной в байтах.
Математическая модель общей реализации протокола TCP (Tcpreno/Newreno/Sack)
Одним из возможных применений результатов математического моделирования функционирования протокола TCP является следующее. Ожидается [13,15,36,57,65,74,76], что одну из основных составляющих трафика Интернет в ближайшем будущем будут создавать услуги передачи мультимедийной информации: потоковое видео (streaming video), Интернет-радио (Internet radio), интерактивные игры (interactive games) и т.п. Как показано в [44,61,65], для большинства мультимедийных услуг, реализованных на прикладном уровне и, как правило, использующих на транспортном уровне протокол передачи пользовательских дейтаграмм (User Datagram Protocol, UDP) [114], достаточно важными параметрами являются задержка доставки пакета и дисперсия этой задержки (джиттер), в то время как случайная потеря пакета, зачастую, не является существенной. В основном это объясняется тем, что услуги потокового типа ориентированы на передачу аудио/видеоинформации и незамедлительное воспроизведение, в результате чего оконечный пользователь и является той системой, которая оценивает качество предоставляемой услуги. Применение протокола UDP для потокового мультимедийного трафика предпочтительнее, чем протокола TCP, так как реализованная в протоколе TCP функция управления перегрузкой с резким уменьшением скорости передачи при обнаружении потери может существенно ухудшить качество предоставляемой услуги [76,81,107]. Однако отсутствие каких-либо алгоритмов управления перегрузкой в протоколе UDP может привести к ухудшению условий функционирования параллельных соединений TCP (т.е. соединений TCP, использующих общий канальный ресурс совместно с потоками UDP) [25,57,74], а также к перегрузке вплоть до полного затора в сети (congestion collapse) [38,39,52,90]. Поэтому был предложен ряд механизмов [22,25,33,45-46,77,81,91,101,103,106,115-117], позволяющих осуществлять адаптивное управление трафиком, создаваемым, в том числе, и потоками UDP. Протокол дружественного TCP управления скоростью передачи данных (TCP Friendly Rate Control, TFRC) [103] является одним из наиболее проработанных и перспективных механизмов для адаптивного управления скоростью передачи. Протокол TFRC осуществляет лишь функцию управления перегрузкой (путем адаптивного изменения скорости передачи данных) и не реализует в полной мере функции протокола транспортного уровня, поэтому он должен использоваться совместно с такими протоколами транспортного уровня как UDP, протокол передачи данных в реальном масштабе времени (Realime Protocol, RTP) [94] и т.п. Протокол TFRC позволяет прикладному процессу передавать данные примерно с той же скоростью, что и протокол TCP в аналогичных условиях, но при этом избегая резкого уменьшения скорости передачи в случае потери пакетов. При использовании данного протокола приемник TFRC сообщает передатчику информацию о потерях, а передатчик TFRC рассчитывает скорость передачи данных на основе полученной информации, времени обращения пакета и формулы, определяющей среднюю скорость передачи данных по протоколу TCP в аналогичных условиях. Данная формула была получена в [82] в результате моделирования функционирования одного передатчика TCP (single source modeling) на основе теории восстановления [93,111].
Таким образом, математическое моделирование функционирования протокола TCP с целью разработки метода оценки средней скорости передачи данных по протоколу TCP в заданных условиях (время обращения сегмента (Round Trip Time, RTT), вероятность потери и т.п.) является важным направлением с точки зрения обеспечения качества обслуживания (Quality of Service, QoS) в Интернет.
Целью данной главы является анализ основных методов оценки средней скорости передачи данных по протоколу TCP. Анализ проводится с целью выявления основных подходов к разработке метода оценки средней скорости передачи данных по протоколу TCP и недостатков существующих методов.
Аналогично Главе 1, TCP-сегмент, не содержащий данных прикладного процесса и с установленным в заголовке битом АСК (acknowledgement -подтверждение), будем называть «АСК».
Также передающий модуль, реализующий функции протокола TCP, будем называть «передатчик», а принимающий модуль, реализующий функции протокола TCP, будем называть «приемник».
Метод оценки средней скорости передачи данных по протоколу TCP RENO
Рассмотрим /-й цикл, представленный на рис. 3.1. Цикл начинается после истечения RTO (событие ТО), соответственно передатчик переходит в фазу медленного запуска. При этом текущее значение W и значение параметра порог медленного запуска (slow start threshold, ssthresh), выраженные в сегментах данных, устанавливаются согласно (1.6), т.е. как W = \ и ssthresh; =max(V _,/2,2). Во время фазы медленного запуска значение W увеличивается на один сегмент данных с получением каждого нового АСК, в результате чего процесс увеличения значения W является показательной функцией от числа раундов [34,42,75]. Фаза медленного запуска продолжается в течение N. раундов до момента, пока величина W не достигнет значения ssthresht, после чего передатчик переходит в фазу предотвращения перегрузки. В фазе предотвращения перегрузки значение W увеличивается на 1/Ь сегментов данных, где Ъ - число сегментов данных, подтверждаемых одним АСК. В [92] рекомендовано значение Ь = 2. Таким образом, число передаваемых сегментов данных возрастает на один каждые Ъ раундов.
Для /-го цикла обозначим число сегментов данных, переданных до первого потерянного сегмента включительно, как ах (см. рис. 3.1), а раунд фазы предотвращения перегрузки, в котором произошла данная потеря, как Xt. Так как сегменты данных до («} — 1) включительно были успешно переданы и подтверждены, то, согласно алгоритму скользящего окна, после сегмента at будет передано еще (W( -і) сегментов данных, после чего в результате TD потеря будет обнаружена в раунде (Х; +1) и фаза предотвращения перегрузки завершится. Таким образом, длительность фазы предотвращения перегрузки, выраженная в раундах, составит (Х. + 1) раундов. После обнаружения потери в результате TD, передатчик переходит в фазу быстрой повторной передачи и быстрого восстановления. Пусть YFR - число сегментов данных, переданных в фазе быстрой повторной передачи и быстрого восстановления в і-ом цикле, a A[R -длительность фазы быстрой повторной передачи и быстрого восстановления в і-ом цикле. Следовательно, в течение / -го цикла будет передано Y. = ai + W{ -1 + Y.FR сегментов данных. Тогда M[r] = M[tf] + M[W]-l + M[r], (3.3) где М[а] - математическое ожидание числа сегментов данных, переданных до первого потерянного сегмента включительно; М [W] - математическое ожидание значения W в конце фазы предотвращения перегрузки; м[У1 - математическое ожидание числа сегментов данных, переданных в фазе быстрой повторной передачи и быстрого восстановления. Согласно (2.64), М ГУ] = 1, тогда, подставляя (2.64) в (3.3), запишем: M[r] = M[ar] + M[W]. (3.4)
Аналогично [82], для определения М[ог], рассмотрим случайный процесс {ап / = 1,2,...}. Согласно введенному предположению относительно независимости потерь сегментов данных в одном раунде от потерь сегментов данных в других раундах, данный случайный процесс может быть представлен как последовательность взаимно независимых одинаково распределенных случайных величин. Следовательно, вероятность того, что at=k, равна вероятности того, что ровно (к-l) сегментов данных были успешно переданы и подтверждены до первого потерянного сегмента [1]. Отсюда Р(а = к) = (1-р)к 1-р, к = 1,2,... (3.5) Тогда М[а] = (1-Р)к-1-р-к = -. (3.6) =i Р Подставляя (3.6) в (3.4), получим: M[YU- + M[W]. (3.7) Р
Для того, чтобы определить M[W] И М[Л], рассмотрим /-й цикл на рис. 3.1. Пусть г- (/,7=1,2,...) - длительность j-ro раунда в /-ом цикле. Тогда длительность / -го цикла может быть определена как А= Z r + + RTO,, /,7 = 1,2,... (3.8) где N. - число раундов в фазе медленного запуска в /-ом цикле; (X; +1) - число раундов в фазе предотвращения перегрузки в /-ом цикле; A[R - длительность фазы быстрой повторной передачи и быстрого восстановления в /-ом цикле; RTOi - длительность таймаута повторной передачи в /-ом цикле. Рассматривая г{. как случайные величины, независящие от величины cwnd и, таким образом, от номера раунда j, находим [1]:
Сценарий имитационного моделирования
Согласно исследованиям [9,12,70], на сегодняшний день в общем трафике Интернет преобладает трафик службы World Wide Web (WWW), причем доля WWW-трафика, по разным оценкам, составляет от 50 до 80%.
Исследования [40,47] показывают, что агрегированный WWW-трафик обладает свойством самоподобия [14,85]. При этом в [118] было доказано, что суперпозиция множества ON/OFF источников трафика с чередующимися периодами ON и OFF (соответствующими интервалу времени с передачей данных с постоянной скоростью и периоду молчания), распределение длительности которых имеет вид Р[Х х] х а, где х- со,0 а 2, создает агрегированный трафик, обладающий свойством самоподобия. На основе результатов, полученных в [118], в [40] было показано, что агрегированный WWW-трафик можно рассматривать как указанную суперпозицию множества ON/OFF источников (WWW-серверов), которые осуществляют передачу запрашиваемого пользователем файла в течение периода ON, а период OFF соответствует интервалу времени между передачами. Так как длительность передачи является функцией от объема передаваемых данных, а исследования [47,84] показывают, что размер файлов, хранящихся на WWW-серверах, имеет распределение по закону Парето, соответственно и распределение длительности периодов ON подчиняется закону Парето. В [40] было доказано, что распределение длительности периодов OFF также подчиняется закону Парето. Соответственно, агрегированный WWW-трафик может быть представлен как суперпозиция множества источников UDP (User Datagram Protocol, UDP), где распределение длительности периодов ON и OFF определяется согласно закону Парето.
Необходимость учета при имитационном моделировании трафика службы WWW и свойства самоподобия данного трафика была отмечена в [53,54,58].
Аналогично [22], для моделирования конкурирующего агрегированного WWW-трафика были выбраны следующие параметры: средняя длительность периода ON TON = 1 с, средняя длительность периода OFF TOFF = 2 с, скорость передачи в течение периода ON составляет 12 кбит/с, коэффициент распределения Парето а = 1,2.
Топология сети и параметры конфигурации
Для имитационного моделирования была выбрана топология, представленная на рис. 4.1. Данная топология использовалась в многочисленных исследовательских работах [22,78,88,96,121] и является стандартом де факто [30,49] для имитационного моделирования с использованием ns-2.
Скорость каналов доступа от источников UDP и рассматриваемого передатчика TCP к маршрутизатору R1 и от приемника UDP и приемника TCP к маршрутизатору R2 была выбрана равной 10 Мбит/с, при этом задержка для данных каналов была установлена равной 1 мс. Скорость канала между маршрутизаторами R1 и R2 была выбрана равной 2 Мбит/с, задержка установлена равной 8 мс. Все указанные каналы являются полнодуплексными. Маршрутизаторы R1 и R2 используют алгоритм усечения хвоста очереди (Tail-Drop) с дисциплиной обслуживания FIFO (First In, First Out).
Так как суммарная пропускная способность каналов доступа от источников UDP и передатчика TCP к маршрутизатору R1 выше пропускной способности канала между маршрутизаторами R1 и R2, соответственно маршрутизатор R1 является «узким местом» (bottleneck) в рассматриваемой топологии. Согласно [98], размер входной очереди в маршрутизаторе R1 установлен равным 50 пакетам.
В представленном сценарии имитационного моделирования анализируемое соединение TCP рассматривается как передача бесконечно большого объема данных по протоколу передачи файлов (File Transfer Protocol, FTP).
Максимальный размер передаваемых сегментов данных (Maximum Segment Size, MSS) в рассматриваемом соединении TCP был установлен равным 1460 байт, как наиболее типичный в WWW-трафике [73,83].
Согласно [92], приемник TCP использует алгоритм подтверждения с задержкой, т.е. Ь = 2, где Ъ - число сегментов данных, подтверждаемых одним сегментом подтверждения (АСК). Размер окна приемника (receiver window, rwnd), выраженный в сегментах данных, установлен как W =10.
Для изменения условий функционирования рассматриваемого соединения TCP (время обращения сегмента (Round Trip Time, RTT), коэффициент потерь) число источников UDP варьировалось от 220 до 420 с шагом в 10 источников. На каждом шаге было проведено 20 испытаний (запусков имитационного моделирования), каждое из которых имело длительность равную одному часу по внутреннему времени ns-2.
Так как в рассмотренных в Главе 2 и предложенных в Главе 3 методах оценки средней скорости передачи данных по протоколу TCP средняя скорость передачи данных определяется для установившегося состояния, то, согласно [89], для исключения влияния переходной фазы на получаемые результаты, из анализа удалялись данные, собранные в первую минуту имитационного моделирования.
Использовавшиеся в работе программы имитационного моделирования соединения TCP Reno и TCP NewReno (вариант Slow-but-Steady) представлены в Приложении 1 и 2 соответственно.
Для последующих расчетов при каждом испытании проводился сбор значений следующих параметров: - ndatapack - общее число переданных сегментов данных; - nrexmitpack - число сегментов данных, переданных повторно; - ncwndcuts - число уменьшений величины скользящего окна в результате обнаружения потери сегментов данных; - rtt - измеренное значение RTT; - srtt - средневзвешенное значение RTT; определяется согласно (1.1);
