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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
