[Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?
rick.jones2 at hp.com
Thu Mar 17 15:20:36 PDT 2011
On Thu, 2011-03-17 at 23:50 +0200, Jonathan Morton wrote:
> On 17 Mar, 2011, at 8:22 pm, 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 :)
> 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. Given the recent change in Linux upstream
to go to cwnd_init of 10 segments, and the prospect of other stacks
following that lead in implementing the draft RFC, if there is a big
slow queue of traffic that the data segments will not bypass, it would
seem better to have the SYN or SYN|ACK get delayed and retransmitted to
get the cwnd down.
SYN and SYN|ACK segments should not receive special treatment beyond
what data segments for the same connection would get.
More information about the Bloat