БЫСТРЫЙ TCP
FAST TCP (также называемый FastTCP ) — это алгоритм предотвращения перегрузки TCP , специально предназначенный для междугородных соединений с высокой задержкой, разработанный в Netlab Калифорнийского технологического института и в настоящее время коммерциализируемый компанией FastSoft. FastSoft была приобретена Akamai Technologies в 2012 году. [1]
FastTCP совместим с существующими алгоритмами TCP и требует внесения изменений только в компьютер , отправляющий данные .
Имя
[ редактировать ]Название FAST представляет рекурсивную от FAST , A QM S Calable T где AQM означает активное управление очередью протокол TCP а означает CP передачей управления , собой аббревиатуру .
Принципы работы
[ редактировать ]Роль контроля перегрузки заключается в уменьшении скорости передачи данных («перегрузки») в зависимости от пропускной способности сети и скорости передачи данных другими пользователями. Как TCP Vegas , FAST TCP [2] [3] использует задержку в очереди вместо вероятности потери в качестве сигнала перегрузки.
Большинство современных алгоритмов контроля перегрузки обнаруживают перегрузку и замедляют работу, когда обнаруживают, что пакеты отбрасываются, так что средняя скорость отправки зависит от вероятности потери. Это имеет два недостатка. Во-первых, для поддержания высоких скоростей передачи данных необходимы низкие вероятности потерь; в случае TCP Reno требуются очень низкие вероятности потерь, но даже новые алгоритмы предотвращения перегрузки, такие как H-TCP , BIC TCP и HSTCP, требуют более низких показателей потерь, чем те, которые обеспечиваются большинством беспроводных глобальных сетей . Более того, потеря пакетов дает только один бит информации об уровне перегрузки, тогда как задержка представляет собой непрерывную величину и в принципе дает больше информации о сети.
Поток FAST TCP стремится поддерживать постоянное количество пакетов в очередях по всей сети. Количество пакетов в очередях оценивается путем измерения разницы между наблюдаемым временем прохождения туда и обратно (RTT) и базовым RTT , определяемым как время прохождения туда и обратно при отсутствии очереди. Базовое RTT оценивается как минимальное наблюдаемое RTT для соединения. Если в очереди находится слишком мало пакетов, скорость отправки увеличивается, а если в очереди слишком много, скорость снижается. В этом отношении он является прямым потомком TCP Vegas.
Разница между TCP Vegas и FAST TCP заключается в том, как регулируется скорость, когда количество сохраняемых пакетов слишком мало или велико. TCP Vegas вносит фиксированные корректировки скорости, независимо от того, насколько далека текущая скорость от целевой. FAST TCP делает более крупные шаги, когда система находится дальше от равновесия, и меньшие шаги вблизи равновесия. Это повышает скорость сходимости и стабильность.
Сильные и слабые стороны
[ редактировать ]Алгоритмы, основанные на задержке, в принципе могут поддерживать постоянный размер окна, избегая колебаний, присущих алгоритмам, основанным на потерях. Однако они также обнаруживают перегрузку раньше, чем алгоритмы, основанные на потерях, поскольку задержка соответствует частично заполненным буферам , а потеря возникает в результате полностью заполненных буферов. Это может быть как сила, так и слабость. Если единственный протокол, используемый в сети, основан на задержках, то можно избежать неэффективности потерь; однако, если протоколы, основанные на потерях и задержке, совместно используют сеть, [4] тогда алгоритмы, основанные на задержке, имеют тенденцию быть менее агрессивными. Это можно преодолеть путем подходящего выбора параметров, что приводит к сложным взаимодействиям, изученным Tang et al.
Измерения задержки также подвержены джиттеру в результате планирования операционной системы или конфликтов на шине .
Неясно, преобладают ли сильные или слабые стороны, и это во многом зависит от конкретного сценария.
Задержка распространения используется в алгоритме управления окном FAST. В чистой сети задержка в очередях, поддерживаемая существующими потоками FAST, может быть ошибочно принята за задержку распространения новых потоков, которые присоединяются позже, как показано в моделировании ns-2. [5] Эффект этой ошибки оценки эквивалентен изменению основных функций полезности, чтобы отдать предпочтение новым потокам по сравнению с существующими потоками. Способ устранения этой ошибки предложен в . [5]
Обобщенный FAST TCP
[ редактировать ]FAST TCP оказался многообещающим с точки зрения стабильности системы, пропускной способности и справедливости. Однако, для этого требуется буферизация, которая увеличивается линейно с количеством потоков, узких мест в канале. Бумага [6] предлагает новый алгоритм TCP, который расширяет FAST TCP для достижения ( α , n )-пропорциональной справедливости в устойчивом режиме. состояние, в результате чего требования к буферу растут только в n-й степени количества потоков. Авторы называют новый алгоритм Generalized FAST TCP. Они доказывают устойчивость для случая одного узкого канала с однородные источники при отсутствии задержки обратной связи. Результаты моделирования подтверждают, что новая схема стабилен при наличии задержки обратной связи и что его требования к буферизации могут быть значительно масштабированы лучше, чем стандартный FAST TCP.
Интеллектуальная собственность
[ редактировать ]В отличие от большинства алгоритмов предотвращения перегрузки TCP, FAST TCP защищен несколькими патентами. [7] [8] Вместо того, чтобы добиваться стандартизации со стороны IETF , изобретатели FAST, в частности Стивен Х. Лоу и Ченг Джин, стремятся коммерциализировать его через компанию FastSoft. В настоящее время FastSoft продает одноюнитовое стоечное устройство, которое можно развернуть на стороне отправителя без необходимости каких-либо дополнительных модификаций программного или аппаратного обеспечения с обеих сторон.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Янг, Джефф (13 сентября 2012 г.). «Akamai приобретает FastSoft» . Пиар-новости . Проверено 13 сентября 2012 г.
- ^ Ник, барон; Джин, Ченг; Лоу, Стивен Х. и Хегде, Санджай (2006). «FAST TCP: мотивация, архитектура, алгоритмы, производительность» (PDF) . Транзакции IEEE/ACM в сети . 14 (6): 1246–1259. дои : 10.1109/TNET.2006.886335 . Архивировано из оригинала (PDF) 6 сентября 2006 г.
- ^ Джин, Ченг; Вэй, Д.; Низкий, Ш; Банн, Дж.; Чоу, HD; Дойл, Дж. К.; Ньюман, Х.; Равот, С.; Сингх, С.; Паганини, Ф.; Бурмастер Г.; Коттрелл, Л.; Мартин, О.; У-Чун Фэн (2005). «FAST TCP: от теории к экспериментам» (PDF) . Сеть IEEE . 19 (1): 4–11. дои : 10.1109/MNET.2005.1383434 . Архивировано из оригинала (PDF) 12 мая 2006 г.
- ^ Тан, Ао; Ван, Цзянтао; Лоу, Стивен Х. и Чан, Мунг (март 2005 г.). «Сетевое равновесие гетерогенных протоколов управления перегрузкой» (PDF) . IEEE ИНФОКОМ . Майами, Флорида.
- ^ Jump up to: а б Л. Тан, К. Юань и М. Цукерман, «FAST TCP: вопросы справедливости и организации очередей», IEEE Commun. Летт., т. 9, нет. 8, стр. 762–764, август 2005 г.
- ^ Юань, Цао; Тан, Ляньшэн; Эндрю, Лахлан Л.Х.; Чжан, Вэй; Цукерман, Моше (2008). «Обобщенная схема FAST TCP». Компьютерные коммуникации . 31 (14): 3242–3249. дои : 10.1016/j.comcom.2008.05.028 . hdl : 1959.3/44051 .
- ^ Джин, Ченг; Лоу, Стивен Х.; Вэй, Сяолян (27 января 2005 г.). «Метод и устройство контроля перегрузок сети» . Ведомство США по патентам и товарным знакам . Архивировано из оригинала 14 декабря 2012 года . Проверено 5 ноября 2006 г.
- ^ Джин, Ченг; Лоу, Стивен Х.; Вэй, Дэвид X.; Видровски, Бартек; Тан, Ао; Чхве, Хёджон (9 марта 2006 г.). «Способ и устройство для контроля перегрузки сети с использованием управления очередями и измерения односторонней задержки» . Ведомство США по патентам и товарным знакам . Архивировано из оригинала 14 декабря 2012 года . Проверено 5 ноября 2006 г.