Адаптация протокола ТСР к особенностям АТМ-технологии

Владимир Заборовский, Юрий Подчурский

Несомненные достоинства АТМ-технологии заставляют разработчиков сетевого программного обеспечения искать пути адаптации существующих программных средств к особенностям АТМ-сетей.

Одним из основных преимуществ АТМ-технологии является возможность обеспечения заданного уровня сервиса - QoS (Quality of Service) - для каждого пользователя или класса пользователей. Однако используемые методы резервирования ресурсов (пропускной способности) часто оказываются непрактичными и требуют дополнительных исследований. Многие авторы считают, что трудности вызваны свойством самоподобия трафика, характерного для приложений реального времени [1, 2].

Фактическое отсутствие новых приложений, способных работать прямо поверх стека протоколов АТМ, а главное, широкое распространение протоколов TCP/IP, не гарантирующих, но предоставляющих сервис “наилучшей попытки” (best effort), заставляют разработчиков обращаться к стеку TCP/IP.     

TCP Boston - новая реализация протокола ТСР

В последние годы предложено несколько методов использования протоколов ТСР/IP в АТМ-сетях, позволяющих применять все разнообразие существующих (базирующихся на TCP/IP) приложений и служб без каких-либо модификаций.

В то же время многочисленные исследования показывают, что применение протоколов TCP/IP поверх протоколов АТМ приводит в ряде случаев к значительному снижению эффективности использования пропускной способности АТМ-сетей [5]. Уменьшение эффективной пропускной способности связано в первую очередь с особенностями протокола ТСР (точнее, с его реализацией), поскольку на этот протокол возложено управление потоком данных и предотвращение перегрузок. (Проблемы применения протокола ТСР в высокоскоростных сетях и сетях с большой емкостью - Long Fat Networks, LFN, а также некоторые пути решения этих проблем изложены в [3,4].). При использовании АТМ-сетей к перечисленным ограничениям протокола ТСР добавляется снижение его производительности из-за фрагментации, возникающей при передаче TCP/IP-пакета в виртуальный канал АТМ. Фрагментация осуществляется на уровне АТМ-адаптации (AAL), одной из функций которой является разбиение TCP/IP-пакета на блоки размером 48 байт и размещение их в АТМ-ячейках. Поскольку размер TCP/IP пакета обычно значительно больше размера ячейки, такое преобразование для приложений, использующих ТСР, неизбежно.

Для успешной передачи ТСР/IP пакета через АТМ-сеть необходимо, чтобы все ячейки, относящиеся к данному пакету, были переданы без потерь. Потеря даже одной ячейки в любом из промежуточных АТМ-коммутаторов равносильна потере всего пакета, поскольку приводит к невозможности восстановления пакета на стороне АТМ-приемника. Отметим, что при потере ячейки в каком-либо коммутаторе остальные ячейки того же пакета продолжают передаваться по виртуальной цепи несмотря на то, что после прибытия в пункт назначения они неизбежно будут отброшены на этапе реассемблирования (восстановления) пакета. Очевидно, что в результате эффективная пропускная способность сети снижается.

Для решения этой проблемы было предложено несколько механизмов, реализуемых, как правило, АТМ-коммутаторами: выборочное отбрасывание ячеек, упреждающее отбрасывание пакетов [5] и др. В [5] показано, что при наличии нескольких промежуточных АТМ-коммутаторов данные механизмы оказываются неэффективными, поскольку улучшают эффективную пропускную способность отдельного коммутатора, а не всего виртуального соединения в целом.

Для комплексного решения этой проблемы в Бостонском университете была разработана новая реализация протокола ТСР, ориентированная на использование сетевой технологии АТМ. Эта реализация получила название TCP Boston [6,7,1]. Новый транспортный протокол использует функцию фрагментации, неизбежность ее применения для приложений ТСР становится преимуществом, фактором, повышающим производительность ТСР вообще и особенно при использовании АТМ.

В основе протокола ТСР Boston лежит алгоритм адаптивного расслоения информации AIDA (Adaptive Information Dispersal Algorithm).    

Алгоритм адаптивного расслоения информации AIDA

Алгоритм AIDA позволяет динамически распределять пропускную способность, обеспечивая заданные временные требования и любую степень конфиденциальности при минимальной избыточности. Для пояснения работы алгоритма рассмотрим сегмент S данных, подлежащий передаче. Пусть S состоит из m фрагментов (называемых далее ячейками). Обрабатывая S специальной операцией (IDA-операция расслоения), можно получить N (N>m) различных фрагментов (ячеек), таких, что любые m ячеек из этого набора позволяют восстановить S с помощью IDA-операции восстановления.

IDA-операции расслоения и восстановления представляют собой простые линейные преобразования, использующие арифметику несократимых полиномов, и могут выполняться в реальном времени. Операция расслоения сводится к матричному умножению, преобразующему m ячеек исходного блока данных в N ячеек блока данных с расслоенной информацией.

Преобразующая матрица имеет размерность Nxm, причем строки преобразующей матрицы [х ij]Nxm выбраны таким образом, что любые m строк взаимно независимы, и, следовательно, матрица, состоящая из любых m таких строк, не является сингулярной и, таким образом, обратима. Это гарантирует возможность восстановления исходного блока данных из любых m расслоенных ячеек.

Алгоритм IDA выгодно отличается от других протоколов, использующих избыточность, тем, что вводимая избыточность однородна, то есть нет различия между данными и контрольной информацией. Эта особенность - основа для адаптивного введения избыточности.

Для этого после операции расслоения, но перед передачей может быть введена операция выделения полосы пропускания (рис. 1). Благодаря этому появляется возможность изменять уровень избыточности при передаче данных. В частности, число ячеек n, подлежащих передаче, может изменяться от n=m (отсутствие избыточности) до n=N (максимальная избыточность).

Рис. 1. Фазы преобразования пакетов при использовании алгоритма AIDA

Таким образом:

1. С алгоритмом AIDA пропускная способность сети используется максимально возможно - никакая ее часть не расходуется напрасно при повторной передаче пакета или при неполной его доставке. Используется каждая ячейка, достигшая приемника. При этом не требуется индивидуального подтверждения передачи каждой ячейки.

2. Для алгоритма AIDA не нужны никакие модификации протоколов на уровне АТМ-коммутаторов, что имеет место при использовании методов селективного отбрасывания ячеек и опережающего отбрасывания пакетов.

3. Применения AIDA в протоколах TCP/IP поверх АТМ требует только дополнения функций интерфейса между уровнями IP и ATM, т.е. на уровне AAL.

На рис. 2. показано окно передачи, управляемое алгоритмом AIDA в протоколе ТСР Boston. Как пояснялось выше, до передачи пакета AIDA преобразует исходный пакет размером m ячеек в набор из N ячеек (N>>m). В зависимости от степени насыщения сети (подстраиваясь под реальные условия загрузки) динамически изменяется размер n окна передачи, который определяет размер реально передаваемого пакета.    

Рис. 2. Размер окна передачи динамически меняется

в зависимости от реальной загрузки сети

Описание протокола ТСР Boston

Основной задачей протокола ТСР Boston как протокола транспортного уровня является обеспечение надежной передачи данных из конца в конец соединения. Протокол может использоваться в любых сетях с коммутацией пакетов, но, будучи ориентирован при разработке на ячейки небольшой длины, максимальной эффективности достигает в АТМ-сетях.

Основные функции, реализуемые протоколом, включают управление сессией, управление сегментами и управление потоком.

Управление сессией. Протокол предусматривает три фазы ТСР-сессии: установление соединения; передача данных; завершение соединения.

Цели и функции, реализуемые в этих фазах, в основном совпадают с соответствующими целями и функциями известных реализаций ТСР. Основное отличие заключается в передаче дополнительной специфичной для алгоритма AIDA информации, необходимой приемнику для восстановления пакетов на стороне получателя (например, величины m). Обмен этой информацией осуществляется на стадии установления соединения во время трехкратного “рукопожатия” (handshaking).

Управление сегментами. Функция управления сегментами осуществляет уникальные (специфичные только для реализации TCP Boston) операции: кодирование и восстановление сегментов.

Кодирование сегментов происходит на стороне источника. При этом входной блок данных (сегмент) размером b байт делится на m ячеек размером с (m=b/c байт). Затем эти m ячеек обрабатываются алгоритмом IDA, в результате чего получается N ячеек, причем N>>m. После этого первые m ячеек пересылаются приемнику в виде единого пакета, а оставшиеся N-m ячеек сохраняются в буфере источника и передаются для компенсации утраченной информации лишь в случае потери какой-либо ячейки.

Восстановление сегментов происходит на стороне приемника и осуществляется следующим образом. По прибытии пакета ячеек протокол сначала проверяет, получено ли m или более различных ячеек сегмента, относящихся к данному пакету. Если получено m или более ячеек, исходный сегмент восстанавливается с помощью алгоритма IDA и вырабатывается сигнал подтверждения (ACK).

Если получено менее m ячеек, они сохраняются в буфере для последующего восстановления, и вырабатывается сигнал подтверждения, дополненный числом принятых ячеек данного сегмента. Такое подтверждение информирует источник о том, что восстановление сегмента невозможно и при повторной передаче необходимо передать оставшиеся ячейки данного сегмента.

Управление потоком. Все механизмы управления потоком, используемые в последних реализациях ТСР (Tahoe, Reno, Vegas), могут с небольшими изменениями использоваться в TCP Boston. При получении ACK источник проверяет флаг, сигнализирующий о результате восстановления (на стороне приемника) сегмента. Если сегмент восстановлен, то вызывается стандартная ACK-процедура. Если восстановление по принятым ячейкам невозможно, источник выделяет из сегмента подтверждения число r ячеек, принятых на стороне приемника, подготавливает m-r дополнительных ячеек данного сегмента и формирует из них новый пакет, который и будет передан во время ретрансляции. Этот процесс продолжается до тех пор, пока не будет получен сигнал ACK, свидетельствующий об успешном восстановлении пакета. После этого оставшиеся ячейки этого сегмента удаляются из буфера передатчика.

В [7] предлагается реализовывать перечисленные выше основные функции отдельными модулями - модулем управления сессией, модулем управления сегментами и модулем управления потоком соответственно. На рис. 3 показано взаимодействие этих модулей как на стороне передатчика, так и на стороне приемника.

Рис. 3. Функционирование TCP Boston на стороне передатчика (а) и приемника (б)

Следует отметить, что при использовании протокола TCP Boston в сетях АТМ требуется модификация протоколов уровня AAL (AAL5). А именно, при потере одной или нескольких ячеек уровень адаптации (AAL5) должен иметь возможность восстанавливать неполные IP-пакеты вместо их отбрасывания. Для этого предложено два простых механизма. Во-первых, AAL5 может просто вставлять фиктивные ячейки на место любой пропущенной. Во-вторых, AAL5 может формировать новый укороченный IP-пакет с соответствующей корректировкой заголовка пакета, отражающей новую, более короткую длину пакета.

Приведенные в [7,1] аналитические и экспериментальные оценки производительности нового протокола в условиях реального времени показывают, что по сравнению с другими реализациями TCP (Reno, Vegas) протокол TCP Boston позволяет обеспечить более высокую эффективную пропускную способность и уменьшить среднее время реакции.

К недостаткам этой реализации следует отнести:

- необходимость ее установки на обоих концах соединения;

- нарушение принципа независимости протокольных уровней (данная реализация ТСР, т. е. протокола транспортного уровня, требует внесения изменений в нижележащие [AAL] уровни).

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

Литература

1. Bestavros A., Kim G. Exploiting Redundancy for Timeliness in TCP Boston. In: Proceedings of RTAS’97: The 1997 IEEE Real Time Technology and Applications Symposium, Montreal, Canada, June 1997.

2. Zaborovski V., Yegorov S., Podgurski Yu., Yu. Shemanin Yu. ATM Network trafic Management analisis and Optimization: Models and Methods. In: Proceedings EUROMEDIA’98, Leicester, UK, January 1998.

3. Stevens W. R. TCP/IP Illustrated, v1. The Protocols. Addison-Wesley Longman, Inc. 1997.- 576 c.

4. Партридж К. Ограничивают ли протоколы TCP/IP производительность каналов связи. ComputerWeek-Moscovs N39, 1997. с. 16 - 18.

5. Romanov A., Floyd S. Dynamics of TCP Traffic over ATM Networks. IEEE Journal on Selected Areas in Communication, 13(4):633-641, May 1995.

6. Bestavros A., Kim G. TCP Boston: A Fragmentation-tolerant TCP protocol for ATM Networks. Technical Report BUCS-TR-96-014, Boston University, Computer Science Derpartment, July 1996.

7. Bestavros A., Kim G. TCP Boston: A Fragmentation-tolerant TCP protocol for ATM Networks. In: Proceedings of Infocom’97: The IEEE International Conference on Computer Communication, Kobe, Japan, April 1997.

К авторам, сотрудникам ЦНИИ робототехники и технической кибернетики, можно обратиться по телефону: (812) 552-4388.