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

[Rick Jones]

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.  

rick