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

[Mark Allman <[e-mail]>]

Jerry-

A few random thoughts here ...

> I'll start with Lowering initRTO.
> 
> RFC1122 contains the following paragraph:
> 
> The following values SHOULD be used to initialize the
> estimation parameters for a new connection:
> 
> (a)  RTT = 0 seconds.
> 
> (b)  RTO = 3 seconds.  (The smoothed variance is to be
> initialized to the value that will result in this RTO).
> 
> The "3secs SHOULD" is reaffirmed in RFC2988.
> 
> From our own measurement of world wide RTT distribution to Google
> servers we believe 3secs is too conservative, and like to propose it
> to be reduced to 1sect.

I am not at all sure this is a good idea.  I have an easier time
believing the others on your list are perhaps reasonable.  But, this one
seems somewhat dubious to me.  A few things ...

  - The fundamental problem here is that you have *no* information.
    That is, we don't know how long the path is before we have done an
    exchange.  When you start from scratch you have nothing to go on
    except defaults.  So, it seems to me on those grounds alone
    conservativeness is fine.  Because,

  - If it was just an extra small packet or two that got sent out that
    doesn't seem like a Big Deal.  But, once you retransmit the SYN you
    no longer can take an RTT sample from the 3WHS per Karn's algorithm.
    So, if in fact the initial RTO is too short then it isn't just going
    to strobe out an extra packet, but what it means is that it's pretty
    likely that the packets in your initial window---after clumsily
    finishing the 3WHS---will likewise be retransmitted because the RTO
    estimate is low and we did not get the opportunity in the 3WHS to
    take an actual RTT sample to better seed the estimator.  This is RTO
    Hell.

  - At first blush timestamps might help here because if used then we
    don't have to use Karn's algorithm.  But, again, since we are just
    initiating a connection how do we know if the peer is going to use
    timestamps?  If the initiator sends a timestamp option then there is
    a chance that timestamps will be in use and therefore there is a
    chance you'll avoid RTO Hell.  But, there is also a chance you
    won't.  The 3WHS responder (sender of the SYN+ACK) will know if
    timestamps will be in use and therefore could perhaps lower the
    initial RTO (basically, this is the ECNSYN trick).  That doesn't
    seem all that unreasonable to me.

  - Now, if you track information across connections as others have
    noted then, sure.  It seems perfectly acceptable to take the view
    that with high confidence you understand that 1sec (or whatever)
    will be fine for an initial RTO over some path that you have
    transmitted traffic across in the recent past and so then you can
    use that.  In this case, you are picking an initial RTO for a
    connection but not flying completely in the dark.

  - It seems that (per the discussion in today's meeting) a naive
    lowering to 1sec is going to be problematic because we have
    bandwidth-on-demand networks, deep queues in access devices are not
    rare, etc.

In a subsequent email you note:

> Correct so there is a fine line to walk. But if > 98% of all TCP
> connections experience RTT << 1 sec, it just seems too conservative to
> have a global initRTO == 3secs just to avoid spurious retransmission
> in the < 2% category.

I agree that it is a fine line.  But, I think your 98%-vs-2% is far too
glib.  That is, we have to look at how bad we're making it for those 2%.
If we degraded each of those 2% by "a smidge" then who cares.  But, if
we really hose those connections (see second bullet above about RTO
Hell) it doesn't seem like a good tradeoff.  It's useful to remember
that TCP was designed to be general and not optimal.  Certainly we don't
want to unduly penalize most of the traffic (/users) to dogmatically
accommodate every last esoteric situation that might happen to crop up
on the third Tuesday of the 6th month following the most recent blue
moon.  But, we also can err on the other side, too.  I think simple
percentages as you have given are pretty superficial and we'd need to go
beyond that to really decide what line we wanted to walk.

Just my two bits ...

allman