Project

General

Profile

Bug #8725

Update TCP's RTO even if incoming segment's TSecr is 0

Added by Dan McDonald almost 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Category:
networking
Start date:
2017-10-19
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

As reported by Lauri Tirkkonen:

Anyway, the issue this patch fixes happens when:
- fast retransmissions are dropped due to congestion (to facilitate
  reproducing this, use:
      ndd -set /dev/tcp tcp_dupack_fast_retransmit 1000
  which will pretty much prevent fast retransmits from being sent)
- timer based retransmission happens, and tcp_timer_backoff is
  incremented for exponential backoff
- new ACK segments from peer have timestamp options, but set TSecr=0
  (RFC 1323 specified that TSecr must be 0 if there is no valid recent
  timestamp to echo, but 7323 obsoleted that. OpenBSD happened to set
  TSecr=0 in some circumstances)
- new rtt measurements are not made: tcp_set_rto is never called again
  because the zero echo replies are all ignored. this causes
  tcp_backoff_timer to go up whenever timer-based retransmission
  happens and _never_ go down, resulting in quite pathological
  performance when illumos is sending (60sec pauses for every
  timer-based retransmission!):

This pathology is also addressed in the FreeBSD TCP stack, see here:

http://src.illumos.org/source/xref/freebsd-head/sys/netinet/tcp_input.c#2785

History

#1

Updated by Dan McDonald almost 2 years ago

Some additional historical notes:

1.) The pre-fixed behavior has been around in illumos since before the splitting of TCP into smaller files.

2.) The interoperability-with-Microsoft and 0-timestamps issues has been understood in FreeBSD going back as far as 2002 (see https://github.com/freebsd/freebsd/commit/494e59ef36b7b311f00285ac94cd6e7c2e7d8f9d)

Also available in: Atom PDF