Re: [tcpm] RFC 1323: Timestamps option

Hi Sally,

Yes, thanks.  That is one of the other open issue with 1323.  Over  
the next week or so I'm planning on sending out individual emails for  
each of the other issues, so that they can be discussed individually,  
rather than trying to discuss them all in one big email thread.  But  
since you brought it up, let's begin this thread now. :-)

For the RFC, at a minimum we need to add a description of the  
problem, and say that implementors should take into account the more  
frequent timestamp values.  I don't think we should trying to tell  
them exactly how to address the issue, but it'd be nice to have a  
reasonably example that could be easily implemented and achieve the  
desired effect.

So, my idea is to use a two-tier approach.  As without Timestamps,  
you record the sequence number to begin measuring the RTT.  Until you  
get the ACK for that sequence number, you take all the measurements  
from the Timestamps options and average them together.  Once the ACK  
for the sequence number returns, you take the averaged value and use  
that in the traditional RTO calculations, and reset the sequence  
number and averaged value.  There are probably better algorithms, but  
this one is simple and should be fairly easy to implement, and would  
produce better results than the situation today where all the  
Timestamps are fed into the RTO calculation without adjusting for the  
increased frequency of the measurements.

		-David Borman

On Jan 26, 2007, at 1:09 PM, Sally Floyd wrote:

> David -
>
> I don't have any feedback about *when* to negotiate timestamps, but  
> I do have some feedback
> about how the RTO should be estimated when timestamps are used.   
> Just as something
> to include in a revision of RFC 1323...
>
> Regards,
> - Sally
> http://www.icir.org/floyd/
>
> Here is some old email of mine on this:
>
>> To: mallman@icir.org
>> cc: "Ethan Blanton" <eblanton@cs.purdue.edu>,
>>     "Aaron Falk" <falk@isi.edu>, "Ted Faber" <faber@isi.edu>,
>>     touch@isi.edu, "Scott Bradner" <sob@harvard.edu>
>> Bcc:
>> From: Sally Floyd <floyd@icir.org>
>> Subject: Re: Mark Allman: would this fly?
>> Date: Tue, 09 Aug 2005 13:45:18 -0700
>> Sender: floyd@cougar.icir.org
>>
>> Mark -
>>
>> >> It is worth noting that if timestamps are being used, with the
>> >> currently-specified time constant for estimating the average  
>> RTT and
>> >> variance, then the first thing that needs to be done is to  
>> change the
>> >> time constant so that the average RTT and the variance aren't  
>> being
>> >> estimated over a small fraction of a window of data (as is  
>> possible
>> >> when timestamps are used with current parameters).  (Unless  
>> this has
>> >> already been fixed in recent standards, and I just missed it...)
>> >
>> >I don't think this has been fixed.  And, I don't see this  
>> potential i-d
>> >as the place to fix it.  I wanted this to be an alternative  
>> response to
>> >spurious timeouts, not some general RTO change.  Does that make  
>> sense?
>>
>> It makes sense.  Except that if in fact the average and variance are
>> being estimated over a small fraction of a window size, because
>> the TCP connection is using timestamps and has a moderate-to-large
>> congestion window, then the estimated variance might be very small
>> (because it is measured over RTTs calculated essentially from the
>> most recent N packets, for N < cwnd, and the burstiness for rtts for
>> the most recent fraction of a cwnd might be quite small).
>>
>> So in that situation, increasing the multiple of the variance might
>> have almost no effect on the RTO, because the variance might be
>> unrealistically small when calculated only over this small time
>> scale.  And changing the weight for estimating the rtt average and
>> variance to make sure that the average RTT and variance are estimated
>> from RTTs calculated over a period of several rtts, might make your
>> technique much more powerful, by making the calculated variance
>> much more interesting and useful.  Worth noting, at any rate.  IMHO.
>>
>> - Sally
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm