CC BY
263
Анализ работы реализаций стека TCP в беспроводных сетях связи
Ключевые слова: протокол ТСР беспроводные сети передачи данных, механизм управления потоком, механизм скользящего окна, механизм управления перегрузкой, реализации ТСР, медленный старт, исключение перегрузки.
TCP, представленный в 1988 г. в RFC 793, является наиболее распространенным протоколом транспортного уровня. C тех пор протокол претерпел множество изменений, однако, до сих пор является наиболее используемым протоколом транспортного уровня. На настоящий момент более 80% всего Интернет трафика занимает TCP трафик. Большое количество Интернет приложений использует протокол TCP в качестве нижележащего протокола транспортного уровня: web (HTTP), e-mail (SMTP), file-transfer (FTP) и др. C самого начала протокол TCP разрабатывался для проводных сетей передачи данных. Но в связи с повсеместным распространением беспроводных сетей, важно, чтобы эти приложения поддерживались не хуже, чем для проводных сетей. В случае беспроводных сетей TCP показывает значительно худший результат. Надежность протокола TCP получается за счет отслеживания последовательности передачи пакетов и получения подтверждений. Pабота TCP основывается на предположении о том, что все потери пакетов происходят вследствие перегрузок в сети. В случае потери пакета TCP применяет механизмы избегания перегрузки и снижает скорость передачи. Но для беспроводных сетей, где потери пакетов в большинстве случаев происходят вследствие внезапных ухудшений характеристик канала связи, обусловленных его беспроводной природой, уменьшение полосы пропускания является серьезной проблемой. Для улучшения эффективности передачи было разработано множество реализаций TCP, основанных на сложных механизмах прогнозирования состояния канала и доступной полосы пропускания. Представлено исследование и сравнение основных реализаций TCP.
Зайцева Ю.М.,
аспирант, МТУСИ, ymzaytseva@gmail.com
В настоящее время протокол ТСР являет наиболее распространенным протоколом транспортного уровня, обеспечивающим надежную доставку данных. Логика доставки сегментов ТСР заключается в том, что поток данных делится на сегменты. Каждый сегмент имеет специальную метку номера последовательности для обеспечения гарантии доставки сегментов нужном порядке. Надежность протокола ТСР достигается за счет подтверждений о доставке (ACK), которые высылаются отправителю в случае успешной доставки сегментов. Если получателю приходит непоследовательный сегмент, то высылается ACK с номером нужного сегмента. В случае, когда отправитель не получает подтверждения доставки переданного пакета в течение таймера RTT (round triptime — время на передачу и подтверждения приема), то он либо передает пакет заново, либо прекращает передачу, если обнаруживается, что соединение разорвано. Такой метод реализации надежности обеспечивает гарантированную доставку данных, однако, ресурсы канала связи используется крайне неэффективно.
Для борьбы с данной проблемой в протоколе ТСР разработан механизм окна. Так как между отправкой сегмента данных и обработкой подтверждения доставки проходит некоторое время, то целесообразно использовать это
время на передачу данных. В некоторых протоколах с гарантированной доставкой данных реализован механизм передачи данных с ожиданием подтверждения доставки нескольких сегментов, при условии что, размер окна получателя является достаточным, чтобы их обработать. В таком варианте реализации надежной доставки данных говорят о механизме фиксированного окна. Недостатком данного механизма является то, что размер окна является фиксированным и не меняется во время всего сеанса вне зависимости от условий передачи. Таким образом, в случае, когда получатель по каким-либо причинам не может принять для обработки то количество данных, которое было заявлено при инициализации размера окна, отправитель все равно пытается отправить фиксированный блок данных. Но не получив за КП подтверждение о доставке, считает данные недоставленными и осуществляет отправку вновь. В итоге, одни и те же данные отправляются не-
сколько раз, что загружает канал связи и увеличивает время доставки.
Для избегания ситуаций подобного рода и увеличения эффективности передачи в протоколе ТСР реализован механизм управления потоком, суть которого заключается в том, чтобы передавать максимально возможное количество данных без подтверждения, не вызывая при этом их повторную передачу. Главным критерием, регулирующим поток данных, является механизм скользящего окна. В такой реализации размер окна может меняться динамически во время всего соединения ТСР (скользящее окно ТСР, рис. 1). Размер окна — количество передаваемых за раз пакетов — определяется на этапе установки соединения (трехфазное квитирование). В случае успешной доставки пакетов получателем высылается подтверждение с номером следующей ожидаемой последовательности, тем самым подтверждая, что все переданные сегменты были доставлены, а также но-
PKa 1. 0<ользящее окно TCP
TCP
SACK Tahoe
(RFC 2018) (RFC 2001)
Reno (RFC 2581) Vegas
New Reno (RFC 2582) Westwood (RFC 6077)
Westwood+
Pkfc 2. Hаследственнасть моделей реализации TCP [1]
вый размер окна, то есть количество данных, которое может быть передано.
Если подтверждение не доставлено, то по истечении таймера неподтвержденные сегменты передаются повторно. Окно может быть сколь угодно большим, однако, если получатель не может принять то количество данных, которое отправитель готов ему передать, то данные отбрасываются и отправителю придется передавать их заново. В случае "неготовности" получателя принять следующий блок данных для обработки вместе с подтверждением доставки предыдущего блока отправителю высылается нулевой код последовательности. Таким способом отправителю сообщается, что буфер получателя полон, и данные не могут быть приняты на обработку.
После освобождения достаточного места в буфере получателем высылается индикатор готовности, то есть номер следующей ожидаемой последовательности данных, и передача сегментов возобновляется. Повторная передача данных требует дополнительного времени и занимает ресурсы сети.
Механизм скользящего окна, реализованный в классической версии ТСР (RFC 793), определяет, какое количество данных без подтверждения может быть отправлено с точки зрения получателя. В данном случае следующая группа сегментов не может быть отправлена до получения подтверждения доставки предыдущей или истечения времени RTT. Вследствие этого скорость передачи данных не будет высокой и будет напрямую зависеть от параметра RTT и размера окна. Так как в проводных сетях ПД для которых изначально разрабатывался протокол ТСР, потеря пакетов происходит в большинстве случаев из-за перегрузок в сети, были разработаны алгоритмы, позволяющие динамически менять размер окна для более эффективной передачи с точки зрения отправителя.
Данные алгоритмы используют параметр окна управления перегрузкой — c_win (congestion window), размер которого определяется при установлении виртуального соединения между хостами. При успешной доставке сегментов размер окна перегрузки увеличивается. Потеря же сегмента является индикатором того, что в сети произошла перегрузка, вследствие чего необходимо уменьшить окно перегрузки. В различных реализациях ТСР разработаны сложные механизмы прогнозирования состояния канала, основанные на специализированных алгоритмах, и механизмы уменьшения и увеличения параметров управления потоком для наиболее эффективного использования доступной полосы пропускания (TCP Tahoe, TCP Reno, TCP New Reno, TCP Vegas и т д ). Однако, не все они были успешными и лишь немногая часть из них была стандартизована.
В данной статье будут рассмотрены основные реализации ТСР (рис. 2).
Параметры управления перегрузкой
c_win(congestion window) — окно перегрузки r_win (receiver advertised window) — объявленное получателем окно
Ss_tr (slow start threshold) — порог медленного старта
Анализ реализации ТСР Tahoe ТСР Tahoe был разработан Ван Якобсоном в 1988 г. В нем были впервые применены три алгоритма исключения перегрузки: медленный старт (slow start), исключение перегруз-i^(congestion avoidance) и быстрая повторная передача (fast retransmit) (рис. 3).
Преимущества TCP Tahoe по сравнению с основной версией протокола очевидны. Однако существенным недостатком данной реали-
i i
c_win
зации является включение алгоритма медленного старта при каждой потере пакета, и установка значения окна перегрузки равным одному сегменту. В результате наблюдается большая потеря эффективности использования полосы канала. Что в случае беспроводных сетей передачи данных имеет серьезной проблемой, так как вследствие непостоянной природы беспроводного канала связи потери пакетов происходят очень часто. Еще одним недостатком TCP Tahoe является неэффективность алгоритма быстрой повторной передачи в случае множественных потерь пакетов.
Анализ реализации ТСР Reno
TCP Reno был разработан в 1999 году и является наиболее часто применяемой версией протокола ТСР! TCP Reno является улучшенной версией ТСР Tahoe. В данной реализации рабо-
Таймаут
Рис. 3. Медленный старт и исключение перегрузки
тают все методы исключения перегрузки, которые были реализованы для ТСР Tahoe (алгоритм медленного старта, алгоритм "исключения перегрузки" и алгоритм быстрой повторной передачи). Для данной версии отличие от TCP Reno является применение алгоритма быстрого восстановления (Fast recovery).
Алгоритм Reno работает хорошо только при отсутствии потерь пакетов или когда потери относительно небольшие. При потере нескольких пакетов в рамках размера одного окна производительность Reno падает, и он его результативность становится аналогичной реализации Tahoe при большом числе потерянных пакетов. Причина низкой эффективности обработки потери нескольких пакетов заключается в том, что Reno может определить только один потерянный пакет и величина c_win может уменьшаться дважды.
Анализ реализации ТСР NewReno
TCP NewReno является модификацией TCP Reno. В данной версии улучшен процесс повторной передачи в алгоритме быстрого восстановления TCP Reno. За счет этих улучшений TCP NewReno способен обнаруживать множественные потери пакетов.
В отличие от предыдущей версии TCP NewReno не прекращает работу алгоритма быстрого восстановления пока все неподтвержденные сегменты не будут подтверждены. Таким образом, TCP NewReno избегает многократного уменьшения значения окна перегрузки за счет постоянного включения алгоритма быстрого восстановления при множественных потерях сегментов, как это было в TCP Reno.
Алгоритмы медленного старта, быстрой повторной передачи и быстрого восстановления в TCP NewReno работают также как и в TCP Reno. Отличие заключается в том, что TCP NewReno заканчивает фазу быстрого восстановления только после получения подтверждений доставки от всех неподтвержденных сегментов. Далее значение окна перегрузки устанавливается равным порогу медленного старта, и начинается фаза избегания перегрузки. В процессе работы фазы быстрой повторной передачи в TCP NewReno реализуется идея частичных подтверждений (partial ACKs). Благодаря этим усовершенствованиям TCP NewReno имеет возможность лучше справляться с множественными потерями пакетов. Различия в работе TCP NewReno и TCP Reno незначительны, когда потери пакетов единичны, TCP NewReno значительно превосходит в работе TCP Reno, когда потери пакетов возрастают.
Значительным улучшением TCP NewReno является эффективность в случае множественных потерь пакетов. Однако, когда потеря пакетов не
происходит, но пакеты приходят с нарушением последовательности более чем на три номера, TCP NewReno ошибочно запускает фазу быстрого восстановления. В этом случае пакеты, которые не нужно передавать повторно, передаются, и увеличивается число подтверждений.
Анализ реализации TCP SACK
TCP SACK (TCP with selective acknowledgment) позволяет приемнику выборочно подтверждать сегменты с нарушением очередности за счет подтверждения последнего сегмента, пришедшего в правильном порядке. Приемник подтверждает сегменты, пришедшие не в порядке очередности, а отправитель затем передает только пропавшие сегменты данных, а не все неподтвержденные сегменты.
TCP Reno with SACK действует похожим образом, что и TCP Tahoe и TCP Reno, которые отличаются устойчивостью в случае нарушения очередности доставки сегментов.
Tакже TCP SACK помогает улучшить работу в условиях множественных потерь пакетов. В течение фазы быстрого восстановления в TCP SACK существует переменная pipe (труба), которая показывает оцененное количество недоставленных пакетов. Передатчик отправляет новые, либо повторно передает недоставленные пакеты, пока оцененное количество пакетов в маршрутизаторе меньше значения окна перегрузки. Значение переменной pipe увеличивается на единицу, когда отправитель передает новый сегмент, либо повторно передает старый, и переменная уменьшается на единицу, когда отправитель получает дублирующее подтверждение.
Анализ реализации TCPVegas
До середины 1990х во всех реализациях TCP оценка задержки сегмента основывалась по последнему переданному пакету в буфере получателя. В отличие от этого в реализации TCP Vegas задержка оценивается для каждого сегмента в буфере отправителя. За счет этого TCP Vegas обнаруживает перегрузку на стадии роста значений RTT пакета, в отличие от предыдущих версий, которые обнаруживали перегрузку по потерям пакетов после того, как она уже произошла.
Tакой алгоритм работы основывается на тщательном определении базового значения RTT. Tак как если это значение мало, то пропускная способность соединения будет меньше доступной полосы, в противном случае наоборот.
Однако, несмотря на преимущества TCP Vegas, если совместить работу этой версии с предыдущими версиями (например, TCP Reno), то хорошего результата не будет, более того работа TCP ухудшится. Это объясняется тем, что TCP Vegas снижает скорость передачи до того,
как это сделает ТСР Reno, так как в реализации ТСР Vegas перегрузки в сети обнаруживаются раньше. Таким образом, снижение скорости отправки за счет ТСР Vegas предоставляет большую полосу для сосуществования потоков ТСР Reno.
Анализ реализации TCP Westwood
Версия TCPWestwood является еще один совершенствованием линейки TCPReno. В данной версии по сравнению TCPNewReno был модифицирован алгоритм быстрого восстановления. Также был добавлен алгоритм оценки полосы пропускания (bandwidth estimation — BWE).
По аналогии с версией Vegas BWE использует значение RTT и значение количества данных, отправленных за этот промежуток времени, чтобы вычислить и оценить оптимальную скорость передачи. Данное значение используется для установки окна перегрузки и порога медленного старта, когда обнаруживаются потери пакетов.
Главная цель такой работы заключается в том, чтобы улучшить пропускную способность в беспроводных сетях, где потери пакетов в большинстве случаев вызваны проблемами в канале связи,а не перегрузками сети.
Еще одним преимуществом версии TCPWestwood является то, что начало фазы избегания перегрузки начинается с более высоких значений, что снижает время восстановления в большинстве сетей, что в свою очередь сокращает время передачи.
Анализ реализации TCP Westwood+
Ключевой идеей реализации TCP Westwood+ является использование потока подтверждений доставки пакетов для оценки доступной полосы в обоих концах соединения, чтобы после перегрузки установить нужные значения c_win и ss_tr, тогда как в предыдущих реализациях ТСР значения устанавливались вслепую путем уменьшения значения окна перегрузки вдвое.
TCP Westwood+ является усовершенствованием предыдущей реализации TCP Westwood на клиентской стороне. Механизм работы данной версии основан на оценке доступной полосы пропускания на обоих концах соединения для того, чтобы установить значения окна перегрузки и порога медленного старта после наступления перегрузки (последовательно получение трех дублированных подтверждений, либо наступление таймаута). Пропускная способность канала определяется путем точной оценки количества возвращающихся пакетов подтверждения посредством сглаживающего фильтра.
Главным преимуществом реализации TCP
Westwood+ является то, что при ее использовании в беспроводных сетях можно значительно повысить пропускную способность канала. Работа данной реализации в проводных сетях ничем не уступает предыдущим реализациям ТСР (New)Reno. Однако, существенным недостатком реализаций TCP Westwood(+)также, как и рассмотренной выше TCP SACK, является то, что их преимущества проявляются в случае, если клиентская и серверная сторона их поддерживает. На данный момент это условие практически нереализуемо, так как большинство сайтов, к которым обращается пользователь Интернета (новости, социальные сети, погода, почта и др.), на серверной стороне поддерживают стандартную версию ТСР NewReno.
Выводы
Как уже говорилось выше, протокол ТСР является наиболее используемым протоколом в современных сетях передачи данных. Вследствие того, что данный протокол изначально предназначался для работы в проводных сетях, для данного вида сетей его работа наиболее эффективна.
Так как на данный момент беспроводные сети передачи данных получили широкое распространение, протокол ТСР должен был претерпеть изменения с целью повышения эффективности своей работы в беспроводной среде.
Стандартные механизмы ТСР не позволяют эффективно обнаруживать потери пакетов, не связанные с перегрузками в сети, так как изначально протокол разрабатывался для борьбы с перегрузками в проводных сетях.
Механизмы борьбы с потерями пакетов и избеганиями перегрузок в ТСР являются ключевой темой многих исследований. С момента разработки протокола ТСР было разработано множество алгоритмов борьбы с перегрузками в сети, однако, но не все они были успешными. Ключевыми механизмами борьбы с перегрузками
являются рассмотренные выше: TCP Tahoe, TCP Reno, TCP NewReno, TCP SACK, TCP Vegas и др.
Однако, следует заметить, что данные механизмы корректно работают в условиях проводной среды, где потери пакетов происходят как правило из-за перегрузок в сети, полагая, что состояние канала связи постоянное. В беспроводных же сетях связи, где канал является по своей природе нестабильным, потеря данных, как правило, происходит из-за ухудшения характеристик канала. Поэтому, механизмы борьбы с потерей пакетов, эффективно работающие в проводных сетях ПД для беспроводных сетей во многих случаях являются неэффективными и только замедляют работу.
Рассмотрим работу указанных выше реализаций ТСР на примере ситуации, когда абонент находится в состоянии хэндовера и пакеты данных не доставляются вследствие того, что на какое-то непродолжительное время связь становится недоступной для данного абонента. В данном случае, стандартные механизмы борьбы с потерями пакетов предполагают, что в сети произошла перегрузка и запускают механизмы борьбы1 с ней, снижая тем самым скорость передачи данных во много раз. Через некоторое время, оказавшись в радиусе действия другой БС, абонент снова может передавать данные, и ему доступна достаточная полоса пропускания для передачи. Но из-за того что были запущены! алгоритмы борьбы с перегрузкой в сети абонент может передавать данные очень небольшими порциями. Вследствие чего, канал оказывается незагруженным, а абонент терпит неудобства из-за медленной передачи данных, хотя ему доступна достаточная полоса пропускания.
Существуют также реализации ТСР, предназначенные специально для работы в беспроводной среде ПД (TCP Westwood, TCP WestwoodNew). Данные механизмы значительно усовершенствованы по сравнению с предыдущими версиями, однако, они также не
берут во внимание реальное состояние сети, а лишь прогнозируют ее состояние по динамически изменяющимся параметрам, таким как RTT и др. Поэтому целесообразно было бы обеспечить передачу информации о состоянии сети с физического уровня на сетевой для прогнозирования состояния сети и более эффективного управления потоком.
Литература
1. S. Hagag, A. El-Sayed Enhanced TCP Westwood Congestion Avoidance Mechanism (TCP WestwoodNew) / International Journal of Computer Applications (0975-8887). Vol.45. No.5, May 2012. Рр. 21-29.
2. G. A Abed, M. Ismail, K. Jumari. A Survey on Performance of Congestion Control Mechanisms for Standard TCP Versions/ Australian Journal of Basic and Applied Sciences, 5(12). Рp. 1345-1352.
3. W. G. Zeng, Ljlljana Trajkovic TCP Packet Control for Wireless Networks/ International Journal of Computer Applications (0975-8887). Vol.45. No.5, May 2012. Р^ 1-8.
4. M. Crocker, Y Chen, W. Hu, and W. Zhu. A Survey of Reliable Transport Protocols/ Mississippi State University, Center for advanced vehicular systems, September 30, 2005. Рp. 1 -35.
5. Md N. Islam Khan, R. Ahmed, Md. T. Aziz. A survey of TCP Reno, New Reno and SACK over mobile ad-hoc network / International Journal of Distributed and Parallel Systems (IJDPS). Vol.3, No.1, January 2012. Р^ 49-63.
6. L Subedi, M. Najiminaini, and L Trajkovic Performance evaluation of TCP Tahoe, Reno, Reno with SACK, and NewReno using OPNET modeler/ Simon Fraser University. F’p. 1 -7.
7. Nishant Chaurasia, Prof. S. Sharma / International Journal of Modern Engineering Research (UMER). Vol.2, Issue.3, May-June 2012. Рp-1039-1045.
8. Семёнов Ю.А. Модели реализации протокола TCP и его перспективы/ book.itep.ru, 2004, 21.05.2013.
9. J. Poste, Transmission control protocol, RFC 793, Sept. 1981.
Analysis TCP variants for wireless networks
Julia Zaytceva, postgraduate student, MTUCI, ymzaytseva@gmail.com
Abstract
Currently the most widely used Internet transport protocol is reliable connection-orientated TCP, performed in RFC 793 in 1988. Since that time it changed greatly, but it still the most commonly used one. Today TCP traffic accounted to 80% of the whole Internet traffic. Huge variety of Internet application used it as the underlying transport protocol: web (HTTP), e-mail (SMTP), file-transfer (FTP) etc. From the beginning TCP created for wired networks and all its variants were carefully designed for wired environment. Today with the growing deployment of weriless networks, it is much important to support these applications for wireless environment as well as for wired. But there are some problems with it, because TCP shows worst performance for wireless. Reliability of TCP established on receiving acknowledgements. And TCP supposes that all packet loss take place due to the network congestion. This way it applies congestion control algorithms, and as the result transmission rate reduces. But due to the fact that considerable packet losses in wireless networks occurs owing to an obvious reason of the wireless link nature: link errors, delay variations, long sudden delays etc. in that way strong measures which TCP implemented in case of packet losses are not applicable for wireless environment as well as for wired. That's way drastic reduce of the transmission rate made by standard congestion avoidance algorithms is serious problem for wireless systems. TCP was optimized to perform well in wireline networks even more several TCP variants was designed specially to perform well in wireless. In the article performed analysis of more commonly used TCP variants.
Keywords wireline networks, TCIp congestion avoidance algorithms, slow start, fast retransmission, TCP sliding window, TCP variants.
