Кратко

  • RFC 3042 разрешает отправителю передавать ранее не отправленные данные на каждом из первых двух последовательных повторных ACK, если это допускают окна.
  • Эти передачи могут дать обратную связь для достижения уже существующего порога в три повторных ACK, однако cwnd увеличивать нельзя.

В описанном в RFC 3042 случае малого окна теряется не только сегмент. Отправителю может не хватить и подтверждений, чтобы сработал уже существующий Fast Retransmit. Если окно перегрузки (cwnd) равно трём сегментам и один из них потерян, вернуться могут максимум два повторных ACK. При таких условиях остаётся ждать тайм-аута повторной передачи.

В январе 2001 года Mark Allman, Hari Balakrishnan и Sally Floyd опубликовали RFC 3042 как стандарт-трек документ. Limited Transmit предписывает: если в очереди есть ранее не отправленные данные, отправителю СЛЕДУЕТ передавать новый сегмент при каждом из первых двух последовательных повторных ACK. Это возможно, только если объявленное получателем окно позволяет отправку, а общий объём неподтверждённых данных не превышает cwnd + 2 сегмента. Ключевой запрет: из-за этих передач отправитель НЕ ДОЛЖЕН менять cwnd.

Именно это разграничение задаёт замысел. Limited Transmit допускает строго ограниченный дополнительный объём данных, чтобы продолжить поток обратной связи; он не объявляет перегрузку исчезнувшей и не выделяет более крупный бюджет окна. Механизм также не повторяет сразу подозреваемый потерянный сегмент. Если новые сегменты и вызванные ими ACK не теряются, может прийти ещё один повторный ACK — и счёт достигнет знакомого порога в три. Тогда повторную передачу разрешает прежнее правило Fast Retransmit. RFC 3042 дополняет его, а не заменяет.

У повторного ACK больше одного объяснения. Он может означать, что получатель увидел данные за пропуском в последовательности, но подобную картину создаёт и переупорядочение пакетов. Повторно передать старый сегмент уже после первого ACK — значит реагировать на более слабый сигнал. RFC 3042 вместо этого отправляет новые данные и сохраняет ритм ACK, что, по обоснованию авторов, устойчивее к переупорядочению. Но число ACK остаётся выводом отправителя, а не физическим доказательством места или причины потери.

Условия строгие: новые данные должны быть готовы к отправке, окно получателя должно оставлять место, а FlightSize — не превышать cwnd + 2 сегмента. При использовании SACK отправитель НЕ ДОЛЖЕН посылать новые данные в ответ на повторный ACK без новой SACK-информации; саму опцию описывает RFC 2018. Если условие не выполнено, либо теряется дополнительный сегмент или его ACK, механизм не гарантирует, что тайм-аута удастся избежать.

Позже RFC 5681 включил отправки на первых двух повторных ACK в сводную последовательность Fast Retransmit/Fast Recovery, сохранив ограничение в два сегмента и неизменность cwnd. Это показывает дальнейшую судьбу правила в документах, но не поведение неизмеренной современной реализации.

Исторический вклад RFC 3042 узок: устранить нехватку обратной связи при некоторых малых окнах, не переписывая управление перегрузкой TCP. Третий повторный ACK, повторная передача и более поздний кумулятивный ACK — разные переходы. Ни один из них сам по себе не устанавливает физическую причину потери и не доказывает, что приложение получило полезные данные.

Источники