WikiDer > FAST TCP - Википедия

FAST TCP - Wikipedia

БЫСТРЫЙ TCP (также написано FastTCP) это Алгоритм предотвращения перегрузки TCP специально предназначенный для междугородних соединений с высокой задержкой, разработанный в Netlab, Калифорнийский технологический институт и теперь коммерциализируется FastSoft. FastSoft была приобретена Akamai Technologies в 2012.[1]

FastTCP совместим с существующими алгоритмами TCP, требуя модификации только для компьютер который отправляет данные.

Имя

Название БЫСТРЫЙ это рекурсивный акроним за FAST АQM Sвызываемый ТCP, где AQM означает Аctive Queue Mпомолвка и TCP означает Тпередача Cконтроль ппротокол.

Принцип работы

Роль управления перегрузкой заключается в том, чтобы регулировать скорость передачи данных в соответствии с пропускной способностью сеть и скорость передачи данных другими пользователями. Нравиться TCP Vegas, БЫСТРЫЙ 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-ая степень числа потоков. Авторы называют новый алгоритм Generalized FAST TCP. Они доказывают устойчивость для случая единственного узкого места связи с однородными источниками при отсутствии задержки обратной связи. Результаты моделирования подтверждают, что новая схема устойчива при наличии задержки обратной связи и что ее требования к буферизации могут быть масштабированы значительно лучше, чем стандартный FAST TCP.

Интеллектуальная собственность

В отличие от большинства алгоритмов предотвращения перегрузки TCP, FAST TCP защищен несколькими патентами.[7][8] Вместо того, чтобы искать стандартизации IETF, изобретатели FAST, в частности Стивен Х. Лоу и Cheng Jin, стремятся коммерциализировать его через компанию FastSoft. В настоящее время FastSoft продает 1-Unit стоечное устройство, которое может быть развернуто на стороне отправителя без каких-либо других модификаций программного или аппаратного обеспечения с обеих сторон.

Смотрите также

Рекомендации

  1. ^ Янг, Джефф (13 сентября 2012 г.). «Akamai приобретает FastSoft». PR Newswire. Получено 13 сентября, 2012.
  2. ^ Ник, Бароне; Джин, Ченг; Низкий, Стивен Х. и Хегде, Санджай (2006). «FAST TCP: мотивация, архитектура, алгоритмы, производительность» (PDF). Транзакции IEEE / ACM в сети. 14 (6): 1246–1259. Дои:10.1109 / TNET.2006.886335. Архивировано из оригинал (PDF) 6 сентября 2006 г.
  3. ^ Джин, Ченг; Wei, D .; Низкий, S.H .; Bunn, J .; Choe, H.D .; Doyle, J.C .; Newman, H .; Равот, С .; Singh, S .; Паганини, Ф .; Бюрмастер, Г .; Cottrell, L .; Martin, O .; У-Чун Фэн (2005). «FAST TCP: от теории к эксперименту» (PDF). Сеть IEEE. 19 (1): 4–11. Дои:10.1109 / MNET.2005.1383434. Архивировано из оригинал (PDF) 12 мая 2006 г.
  4. ^ Тан, АО; Ван, Цзяньтао; Лоу, Стивен Х. и Чанг, Мунг (март 2005 г.). «Сетевое равновесие гетерогенных протоколов управления перегрузкой» (PDF). IEEE INFOCOM. Майами, Флорида.
  5. ^ а б Л. Тан, К. Юань и М. Цукерман, «FAST TCP: проблемы справедливости и очередей», IEEE Commun. Lett., Vol. 9, вып. 8. С. 762–764, август 2005 г.
  6. ^ Юань, Цао; Тан, Ляньшэн; Andrew, Lachlan L.H .; Чжан, Вэй; Цукерман, Моше (2008). «Обобщенная схема FAST TCP». Компьютерные коммуникации. 31 (14): 3242–3249. Дои:10.1016 / j.comcom.2008.05.028. HDL:1959.3/44051.
  7. ^ Джин, Ченг; Низкий, Стивен Х .; Вэй, Сяолян (27 января 2005 г.). «Способ и устройство для контроля перегрузки сети». Бюро патентов и товарных знаков США. Архивировано из оригинал 14 декабря 2012 г.. Получено 5 ноября, 2006.
  8. ^ Джин, Ченг; Низкий, Стивен Х .; Вэй, Дэвид X .; Выдровски, Бартек; Тан, АО; Чхве, Хёджон (9 марта 2006 г.). «Способ и устройство для управления перегрузкой сети с использованием управления очередью и измерения односторонней задержки». Бюро патентов и товарных знаков США. Архивировано из оригинал 14 декабря 2012 г.. Получено 5 ноября, 2006.

внешняя ссылка