Re: [tcpm] 793bis: question on TCP RTO timer

> On 27. Aug 2021, at 12:52, Geert Jan de Groot <GeertJan.deGroot@ymbk.nl> wrote:
> 
> 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.
Can't you use fast retransmission to recover from the loss? What about using RACK?

Best regards
Michael
> 
> 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
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm