[Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Jonathan Morton]

On 18 Mar, 2011, at 12:20 am, Rick Jones wrote:

>>> So initialRTO is specced currently to be 3 seconds, with a small but
>>> non-trivial effort under way to reduce that, but once established
>>> connections have a minimum RTO of less than or equal to a second don't
>>> they?
>> 
>> If the RTT they measure is low enough, then yes.  If the queues
>> lengthen, the measured RTT goes up and so does the RTO, once the
>> connection is established.
> 
> Right.  I should have been more explicit about "You know it won't
> retransmit any sooner than N." (for some, changing value of N :)

I think there is a minimum value, on the order of 100ms - I don't know precisely.

>> But the *initial* RTO is the important one for unmanaged queue sizing,
>> because that determines whether a new connection can be started
>> without retransmissions, all else functioning correctly of course. 
>> There is no way to auto-tune that.
>> 
>> Note also that with AQM that can re-order packets, the length of the
>> bulk queue starts to matter much less, because the SYN/ACK packets can
>> bypass most of the traffic.  In that case the RTT measured by the
>> existing bulk flows will be higher than the latency seen by new and
>> interactive flows.
> 
> I would think that unless the rest of the segments of the connection
> will also bypass most of the traffic, the SYN or SYN|ACK should not
> bypass - to do so will give the TCP connection a low, unrealistic
> initial estimate of the RTT.

> SYN and SYN|ACK segments should not receive special treatment beyond
> what data segments for the same connection would get.

I was thinking of SFQ, which doesn't discriminate based on TCP flags, only on addresses and ports.

With that said, while a low initial estimate of RTT is bad for calculating RTO, it is not so bad for the rest of the congestion control system.  Remember that a major problem with Vegas is that it can grossly overestimate the optimal RTT if, because the queues are already full, it never sees the real propagation time.

 - Jonathan