Re: [tcpm] Re: RFC 1323: Timestamps option

Hi Joe,

On May 30, 2007, at 12:41 PM, Joe Touch wrote:

> David Borman wrote:
> ...
>>> I'm wondering whether there's a case where you could have started
>>> sending new TSvals, and you get a new data ACK (and start  
>>> calculating
>>> RTTs), and then a packet comes in out of order (e.g., duplicated or
>>> SACK). Could this corrupt the RTT? Could this ever happen?
>>
>> Besides being an ACK for new data, it also has to have a TSecr beyond
>> the initial timestamp you sent.  By the time both of those things are
>> true, you should be into normal RFC-1323 processing.
>
> So two checks for every incoming packet, not just during 'sync',  
> right?
> (just checking; that's not obvious to me from the description)

Good question.  That'll be part of coming up with a good description.

The blind way of doing this is to just believe the TSecr value  
whenever it arrives in a packet that ACKs new data.  You'll get some  
bad samples during the transition when Timestamps are being enabled,  
but they should be averaged out after a little bit.  That might work  
ok most of the time, but that's not a good way to design a protocol;  
I'm looking for a deterministic way to enable timestamps mid-stream,  
and not get erroneous RTT measurements.

One way to simplify things is to restrict enabling timestamp mid- 
stream to data packets only, and go ahead and always put in the  
correct TSval value.  That means that the receiver in a one-way data  
transfer can't start sending timestamps.  This solves the problem of  
having to validate the TSecr values for RTT measurement for one-way  
transfers, but it still leaves ambiguity in the case of a bi- 
directional transfer, if both sides decide to enable Timestamps at  
the same time.  In that case, you can still construct scenarios where  
you get ACK only packets that acknowledge new data, and don't have a  
valid TSecr value.  So, you have the same problem, how to identify  
whether or not the TSecr is valid for RTT measurement.  Hence, I  
didn't propose restricting starting timestamps to data-only packets,  
and came up with an alternate way to identify invalid TSecr values.

But even with the TSecr validation, I'm sure there are clever ways of  
doing implementations to avoid doing extra checks once Timestamps are  
started.  I can some up with a few ideas myself. :-)

If anyone has a better idea of how to identify the invalid TSecr  
values, I'm open to all suggestions.

			-David

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