Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)

[Mark Allman <[e-mail]>]

> It's necessary to disambiguate which ACK is for which SYN - i.e. if
> you have a _very_ long-delay path, you might send out three SYNs
> before an ACK to the first SYN comes in. But it appears at the time to
> be an ACK to the third SYN, with other responses lost in transit. So
> SYN timestamps really are necessary to disambiguate in this
> situation. I can see a cascading sequence where the first ACK comes in
> just after say the fifth SYN goes out, and it's immediately necessary
> to bump the RTO up to tens of seconds.

Sure.

I guess Jerry and I are talking about the case where with exceedingly
high probability the RTT is covered by the current 3sec RTO and the vast
majority of the connections have an RTT of less than 1sec.  (So, say,
99.99999% < 3sec and 98% < 1sec.)  So, how then do we use 1sec for the
common case, but still reasonably accommodate the fraction that have
RTTs > 1sec but < 3sec?

Would it be nice to keep pushing and accommodate connections with even
larger RTTs?  Ideally, yeah.  But, I am not sure imposing timestamps or
other mechanisms on everyone to deal with that case is useful.  At some
point you have to engineer your edge case for what it is.

allman