Re: [tcpm] MSL 120sec still a good value?

["[e-mail]" <[e-mail]>]

> On Nov 9, 2022, at 4:07 PM, Jonathan Morton <[e-mail]> wrote:
> 
>> On 9 Nov, 2022, at 5:39 pm, [e-mail] wrote:
>> 
>> quick question for TCP implementers:
>> TCP end points stay in TIMEWAIT for 2 MSL and RFC 9293 says MSL is 120 sec.
>> Is this still a good value anymore? Wouldn't it make sense to use the maximum
>> round trip time observed on the connection or some multiple of it?
>> Any information how implementations do it right now appreciated.
> 
> IIRC, the reason for TIMEWAIT is to guard against the possibility of packets caught in a routing loop and later released.

See:
Faber, T.; Touch, J.; Yue, W.
The TIME-WAIT state in TCP and Its Effect on Busy Servers <> Inproceedings
In: Infocom, pp. 1573-1583, IEEE, 1999

It’s more than just routing loops - it’s also things like reboots.

>  The period of 2x120 seconds is derived from the maximum value of the TTL field and the assumption that the "time" may be one second per TTL decrement.

Per RFC791 and RFC1812, IPv4 TTL is supposed to be decremented at least once a second, but also no less than once per forwarding operation. When time is being ignored, it counts routers (not links). I.e., a packet with a TTL of zero should successfully traverse a link (or switched LAN).

> However, TTL has rarely if ever been decremented more than once per hop when the delay exceeded 1 second at any given hop.  Additionally, TTL must be decremented by at least one per hop even when the delay is much less (by orders of magnitude) than one second at that hop.  This makes the term "time" in the name of the TTL field farcical.

It was accurate as intended when written; perhaps what is farcical is how some implementers have ignored it - because, as you note, this has implications elsewhere (TIME-WAIT, but also receiver reassembly).

> I think the question we should ask is: how robust are today's TCP implementations against packets released from a routing loop?  Is this risk therefore small enough that TIMEWAIT can be reduced to, say, some multiple of the (expected or measured) path RTT, or calculated in a similar way to RTO?

Servers already ignore TIME-WAIT for their own convenience - since the 1990s, as noted in the paper above. There are already other ways to address this, e.g., RFC6191. The only issue is that this RFC assumes clocks.

That said, why is this an issue that needs to be addressed further?

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com