[tcpm] 793bis: question on TCP RTO timer

[Geert Jan de Groot <[e-mail]>]

Hi folks,

I do apologise for bringing up this question this late in the game, but 
lab tests are not pretty..

The issue is on 793bis section 3.8.1: the RTO timer. The 793bis document 
correctly points to RFC1122, RFC2988, RFC6298.

RFC6298 (and 2988) describe:
    (2.4) Whenever RTO is computed, if it is less than 1 second, then the
          RTO SHOULD be rounded up to 1 second.

I now have discussions with an embedded OS manufacturer who clamps the 
RTO timer at 1 second, even if the network delay and SRTT is much 
smaller (say, two hosts connecting over a typical 1000BASE-T network). 
That means that if a single packet is lost, the TCP connection freezes 
for one second because it needs the RTO-timer to trigger which is one 
second, minimal, per requirement RFC6298/2.4 above.

Put like this, a connection pushing 1gbit/sec traffic freezes for one 
second if a single packet is dropped and the OS manufacturer claims this 
is correct. My feeling says it isn't - we measure SRTT for a reason, a 
packet dropped is simply a signal to lower bandwith (congestion) but not 
to freeze traffic for a second waiting for RTO to trigger. However, 
reading the draft and 6298/2988 I can't definitively fault the OS for 
their one second freeze.

Before sending this to the list, for fear of kicking up dust, I asked 
Wesley and he referred to RFC8961, which suggests to use the RTT, with 
exponential backoff, to estimate the RTO timer value without the one 
second minimal value of RFC6298.

I wonder what the list thinks. When the one-second rule was first 
mentioned, networks were significantly slower than they are today, and 
it only seems logical that timers based on traffic (with appropiate 
backoff measures) make more sense than a one second timer.

Clue appreciated,

Geert Jan