3.2 Fast Retransmit/Fast Recovery
Получателю TCP следует незамедлительно передавать дубликат ACK при получении сегмента с нарушением порядка доставки. Это делается для того, чтобы с помощью пакета ACK информировать отправителя о том, что сегмент был получен с нарушением порядка и указать порядковый номер ожидаемого сегмента. С точки зрения отправителя дубликат ACK может быть вызван различными проблемами в сети. Во-первых, причиной может служить отбрасывание сегментов. В этом случае все сегменты после отброшенного будут порождать дубликаты ACK. Во-вторых, дубликаты ACK могут быть обусловлены нарушением порядка доставки сегментов (например, при доставке по разным путям [Pax97]). Наконец, причиной дубликатов ACK может быть репликация пакетов ACK или сегментов данных в сети. В дополнение к сказанному получателю TCP следует незамедлительно передавать подтверждение ACK при получении сегмента, который полностью или частично заполняет пропуски в порядковых номерах. Это позволит предоставить своевременную информ ацию отправителю, выполняющему восстановление после потери с использованием тайм-аута повторной передачи (retransmission timeout), быстрого повтора (fast retransmit) или экспериментального алгоритма восстановления (loss recovery) типа NewReno [RFC2582].
Отправителю TCP следует использовать алгоритм быстрого повтора для детектирования потери и исправления ошибки с использованием входящих дубликатов ACK. Алгоритм быстрого повтора использует прибытие 3 дубликатов ACK (4 идентичных подтверждения ACK без доставки между ними каких-то других пакетов) как индикацию потери сегмента. После получения 3 дубликатов ACK протокол TCP выполняет повторную передачу сегмента, который представляется потерянным, без ожидания завершения отсчета по таймеру повтора передачи.
После того, как алгоритм быстрого повтора передаст те данные, которые представляются включенными в отсутствующий сегмент, алгоритм "быстрого восстановления ("fast recovery") регулирует передачу новых данных, пока не будет получено подтверждение ACK, не являющееся дубликатом. Алгоритм замедленного старта не используется по той причине, что получение дубликатов ACK не только указывает на потерю сегмента, но и говорит о высокой вероятности того, что сегменты покинули сеть (хотя массированное дублирование сегментов в сети может сделать такое допущение некорректным). Иными словами, поскольку получатель может генерировать дубликат ACK только при получении сегмента, этот сегмент покинул сеть и находится в приемном буфере, более не потребляя ресурсов сети. Более того, поскольку "синхронизация" ACK сохраняется [Jac88], отправитель TCP может продолжать передачу новых сегментов (хотя и со сниженным значением cwnd).
Алгоритмы быстрого повтора и быстрого восстановления обычно реализуются вместе, как описано ниже.
- При получении третьего дубликата ACK устанавливается значение ssthresh, которое не превышает значения выражения 3.
- Повторяется передача потерянного сегмента и устанавливается cwnd = ssthresh + 3*SMSS. Это искусственно "увеличивает" размер окна насыщения на число сегментов (три), которые покинули сеть и буферизованы получателем.
- Для каждого принятого дополнительного дубликата ACK значение cwnd увеличивается на SMS S. Это искусственно увеличивает окно насыщения для того, чтобы отразить выход из сети дополнительных сегментов.
- Передается новый сегмент, если это разрешено значениями cwnd и окна, анонсируемого получателем.
- При получении следующего пакета ACK, подтверждающего новые данные, устанавливается cwnd = ssthresh (значение порога, заданное в п. 1). Это приводит к "уменьшению" размера окна насыщения.
Этому пакету ACK следует быть подтверждением, вызванным повтором с п. 1 в течение одного периода RTT после повтора (хотя подтверждение может прийти быстрей при наличии существенного нарушения порядка доставки сегментов данных на приемной стороне). Кроме того, этому пакету ACK следует подтверждать все промежуточные сегменты, переданные между потерянным сегментом и получением третьего дубликата ACK, если ни один из этих сегментов не был потерян.
Примечание: Известно, что этот алгоритм в общем случае не обеспечивает достаточно эффективного восстановления при множественных потерях в одном "звене" пакетов [FF96]. Один из вариантов решения этой проблемы описан в документе [RFC2582].