За последние годы протокол
управления передачей (TCP) в сочетании с интернет протоколом (IP) стали наиболее
распространенной формой организации сетей между компьютерами. В связи с ведущимися
разработками высокоскоростных сетей и приложений которые используют TCP, проблемы
поведение ТСР имеют повышенную важность. Поведению (т.е. производительность,
количество потерянных пакетов, стабильность и т.д.) во время начальной стадии
необходимо уделять отдельное внимание, так как большинство приложений используют
ТСР для коротких передач, которые завершаются еще до того как ТСР перейдет
к устойчивому поведению.
Один из подходов в исследовании проблем поведения заключается в изучении работы
конкретной реализации TCP. Таким образом в данной работе, с помощью моделирования,
детально изучается поведение нескольких реализаций ТСР(Tahoe, Reno, SACK,
Vegas). На основе этих наблюдений предлагается несколько простых изменений,
которые при определенной ситуации существенно улучшают поведение протокола.
Современные реализации
TCP содержат множество алгоритмов, нацеленных на управление сетевой перегрузкой
при поддержании хорошей производительности пользователя. Ранние реализации
TCP следовали модели, использующей совокупное положительное подтверждение
и требование истечения таймера для повторной посылки данных, потерянных при
транспортировке. Эти TCP немного делали для минимизации перегрузки в сети.
Реализация Tahoe TCP добавила множество новых алгоритмов и усовершенствований
к более ранним реализациям. Новые алгоритмы включают Медленный старт, Предотвращение
перегрузки, и Быструю повторную передачу. Усовершенствования включают модификацию
в оценку времени кругового обращения для установки значения времени ожидания
повторной передачи. Все модификации были описаны в [Jac88].
К алгоритму Быстрой повторной передачи проявляется особый интерес в этой работе,
потому что он модифицируется в последующих версиях TCP. С Быстрой повторной
передачей , после получения маленького числа двойных подтверждений для одного
пакета TCP (dup ACK), источник данных заключает, что пакет был потерян и повторно
передает пакет без того, чтобы ожидать истечения таймера повторной передачи,
что ведет к более высокому использованию канала и производительности связи.
Reno TCP сохраняет расширения,
включенные в Tahoe, но изменяет операцию Fast Retransmit добавляя Быстрое
Восстановление [Jac90]. Новый алгоритм предотвращает путь связи ("канал")
от нахождения в пустом состоянии после Быстрой повторной передачи, таким образом
уходит от потребности Медленного старта для наполнение канала после единственной
потери пакета. Быстрое Восстановление предполагает, что каждый полученный
dup ACK представляет один пакет, покинувший канал. Таким образом, в течение
Быстрого Восстановления отправитель TCP способен делать интеллектуальные оценки
о количестве отправленных данных.
Вход в Быстрое Восстановление отправителем TCP происходит после получения
начального порога dup ACK. Этот порог, обычно известный как tcprexmtthresh,
обычно устанавливается равным трем. Как только порог dup ACK получен, отправитель
повторно передает один пакет и уменьшает его окно перегрузки на половину.
Вместо Медленного старта, как в Tahoe TCP, отправитель Reno использует дополнительный
приход dup ACK, чтобы синхронизировать последующие уходящие пакеты.
Алгоритм Reno Быстрого восстановления оптимален лишь при единичных потерях
пакетов. Отправитель Reno передает не более одного пакета за одно время кругового
обращения. Reno значительно улучшает поведение по сравнению с Tahoe TCP когда
происходит потеря одного пакета, но может существенно ухудшить ситуацию если
произошла потеря нескольких пакетов в пределах одного окна. Данная проблема
иллюстрируется при моделировании.
Алгоритм TCP SACK использует
поле "Опции" заголовка кадра ТСР для дополнительной информации о
полученных пакетах станцией-получателем. Если произошла потеря, то каждый
сегмент dup ACK отправляемый станцией получателем содержит информацию о кадре
вызвавшем посылку данного сегмента. Таким образом отправитель, получив данный
кадр имеет информацию не только о том какой кадр был потерян, но также и о
том какие кадры успешно достигли получателя. Благодаря этому избегается ненужная
повторная посылка сегментов, успешно буферированных на стороне получателя.
Как и Reno, TCP SACK входит в режим Быстрого восстановления при получении
3 дублирующихся подтверждений (dup ACK). Во время Быстрого восстановления
отправитель поддерживает переменную pipe, отображающую число пакетов, находящихся
в сети. Данная переменная увеличивается каждый раз, когда новый сегмент был
отправлен и уменьшается, если было получено очередное подтверждение. Передача
нового пакета в сеть разрешена если значение pipe меньше окна перегрузки .
Отправитель также поддерживает структуру данных scoreboard, которая запоминает
подтверждения из опции SACK прибывающих подтверждений. Если отправителю разрешена
передача, он передает следующий пакет из списка пакетов, считаемых потерянными.
Если таких пакетов, то посылается новый пакет.
На основании особенностей
реализации алгоритмов, представленных выше строится модель для каждого протокола.
Важным моментом в построении модели является сверхточное отображение поведения
прокола в реальной сети с тем, чтобы результаты полученные экспериментальным
путем можно было переносить в реальную сеть.
На рис.1 представлена моделируемая топология в сети, используемая в данной
работе.
Рис.1. Топология модели
На рис.1. круг представляет шлюз с конечным буфером типа FIFO, а квадраты представляют хост отправителя и получателя. Используемое время кругового обращения установлено равным 1 msec. Для простоты все модели представленные в данной работе используют получателя, который посылает АСК на каждый полученный сегмент. Узким местом в сети является шлюз, переполнении буфера которого и представляет перегрузку в сети.
В ходе моделирования были получены следующие результаты.