Русская Википедия:FAST TCP

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

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

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

Название

Название FAST это рекурсивный акроним где F - Быстрый , A - Активное Управление Очередью (AQM) , S - Масштабируемый , T - Протокол Управления Передачей (TCP).

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

Роль управления перегрузкой состоит в управлении скоростью на которой передается информация, согласно пропускной способности сети и скорости передачи других пользователей. Подобно TCP Vegas, FAST TCP[2][3] использует задержку организации очередей , вместо вероятностей потерь, как сигнал перегруженности. Актуальнейшие алгоритмы управления перегрузкой обнаруживают перегрузку и замедляют скорость передачи, когда они обнаруживают, что пакеты отбрасываются, так, чтобы средняя скорость отправки зависела от вероятности потерь. У данного способа есть два недостатка. Во-первых, для того чтобы выдерживать высокие скорости передачи данных требуются низкие вероятности потерь; в случае TCP Reno требуются очень низкие вероятности потерь, но даже новые алгоритмы предотвращения перегрузки, такие как H-TCP, TCP BIC и HSTCP требуют уровней потерь ниже, чем у большей части беспроводной глобальной сети . Кроме того, пакетная потеря обеспечивает только единственный бит информации об уровне перегрузки, тогда как задержка это непрерывное количество битов и в принципе предоставляет больше информации о сети.

Поток FAST TCP стремится поддержать постоянное количество пакетов в очередях повсюду в сети.Количество пакетов в очередях оценено путем измерения разницы между наблюдаемой круговой задержкой (RTT) и основной RTT, определенной как круговая задержка, когда нет никакой организации очередей . Основной RTT оценивается как минимальный наблюдаемый RTT необходимый для соединения. Если в очередь поставлено слишком мало пакетов,скорость передачи увеличивается, в то время как, при большом количестве пакетов в очереди, скорость уменьшается .В этом отношении это - прямой потомок TCP Vegas.

Различие между FAST TCP и TCP Vegas состоит в том как корректируется скорость передачи при разных количествах пакетов стоящих в очередях. TCP Vegas вносит корректировки фиксированного размера в скорость передачи, независящие от того, насколько велика разница текущей скорости передачи от нужной .FAST TCP делает большие шаги, когда система далека от равновесия и меньшие когда находится около равновесия. Это улучшает быстроту сходимости и устойчивость.

Достоинства и недостатки

Основанные на задержке алгоритмы могут, в принципе, поддерживать постоянный размер окна, избежав колебаний, свойственные алгоритмам основанным на потере пакетов. Однако они тоже обнаруживают перегрузку раньше, чем основанные на потере алгоритмы, так как задержка соответствует частично заполненным буферам, в то время как потеря соответствует заполненным буферам. Это может быть как достоинством так и недостатком. Если единственный протокол, используемый в сети, основан на задержке, тогда неэффективности потери можно избежать; однако, если основанные на потере и основанные на задержке протоколы совместно используют сеть,[4] тогда основанные на задержке алгоритмы имеют тенденцию быть менее агрессивными. Это может быть преодолено подходящим выбором параметров, приводящим к сложным взаимодействиям, изученными Таном (англ. Tang) и др.

Измерения задержки также подвергаются дрожанию в результате планирования операционной системой, или конфликтной ситуации при обращении к шине.

Преобладание достоинств над недостатками или наоборот, целиком и полностью зависит от определения сценария работы .

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

Обобщенный FAST TCP

FAST TCP показал себя с точки зрения системной устойчивости, пропускной способности и честности. Однако FAST TCP требует буферизации, которая увеличивается линейно с количеством потоков упирающихся в ссылке. Работа [6] представляет новый алгоритм TCP, который расширяет FAST TCP, чтобы достигнуть ($\\alpha$; n) - пропорциональная справедливость в устойчивом состоянии, приводя к буферным требованиям,которые растут только в качестве n степени из числа потоков. Авторы называют новый алгоритм Обобщенный FAST TCP. Они доказывают устойчивость для случая единственного узкого места ссылки с гомогенными источниками в отсутствие задержки обратной связи. Результаты моделирования подтверждают, что новая схема стабильна в присутствии задержки обратной связи, и что ее требования буферизации масштабируются значительно лучше, чем у стандартного алгоритма FAST TCP.

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

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

См. также

Ссылки

Шаблон:Reflist

Внешние ссылки

  1. Шаблон:Cite web
  2. Шаблон:Статья
  3. Шаблон:Статья
  4. Шаблон:Cite web
  5. 5,0 5,1 L. Tan, C. Yuan, and M. Zukerman, “FAST TCP: fairness and queuing issues,” IEEE Commun. Lett., vol. 9, no. 8, pp. 762–764, Aug. 2005.
  6. Шаблон:Статья
  7. Шаблон:Cite web
  8. Шаблон:Cite web