[tcpm] RFC 1323: Timestamps option

[David Borman <[e-mail]>]

One of the topics that has been discussed in the past for the  
revision of RFC 1323 is to relax the requirement on when to send the  
Timestamps option.  I'd like to come to some resolution on this issue.

Current:
The Timestamps option is negotiated during the initial SYN exchange.   
If both sides support it, then every packet in the connection has to  
have the Timestamps option.

Option #1
---------
The proposed change is to relax the requirement that Timestamps have  
to be negotiated in the initial SYN, and instead allow them to be  
enabled later on in the connection.  At the time 1323 was originally  
written, there was a big concern for legacy TCP stacks that didn't  
handle unknown options in the middle of the connection, but were able  
to properly ignore unknown options during the SYN exchange.  But that  
was a long time ago, and unknown options in the middle of a TCP  
connection *shouldn't* be as big of an issue anymore.

The rules for enabling Timestamps mid-stream would be:
1) If you receive a Timestamps option mid-stream, you can enable  
Timestamps.  From then on, every packet sent will need to contain a  
Timestamps option.
2) If you want to enable Timestamps mid-stream, you can only do so on  
a data packet.  You record the sequence number of that data packet,  
and include the Timestamps option on every packet from then on, until  
you receive an ACK for that sequence number.  If at any time you  
receive a packet with the Timestamps option, then they are enabled  
for the rest of the connection.  If you do not receive a packet with  
a Timestamps option by the time you get the ACK for that initial  
sequence number, then the other side has not enabled Timestamps and  
you must stop sending Timestamps for the duration of the connection.

The restriction on only being able to initiate Timestamps on a data  
packet is that they are the only packets that are delivered reliably,  
so determining whether or not the other side supports them is  
deterministic by getting the ACK for that data.


Option #2
---------
This is similar to Option #1, but not quite the same.  In this case,  
the Timestamps would be negotiated in the initial SYN as before, but  
then no additional packets would have Timestamps options.  At any  
point during the connection, either side can enable the use of  
Timestamps just by starting to send them.  Since we already know that  
both sides support them, once you start sending them you never stop.   
And if you every receive one, you are then required to also send them  
for the duration of the connection.

The question then is, how do you negotiate Timestamps without turning  
them on?  My suggestion would be to send a Timestamps option with the  
special format TSval=0,TSecr=0.  If you receive this in a SYN, then  
the request is to negotiate knowledge of the Timestamps option.  The  
returning SYN,ACK would also need to contain TSval=0,TSecr=0 to  
complete the negotiation.  If you are connecting to a site that  
doesn't support this feature but does support Timestamps, it would  
respond with TSval=xxx,TSecr=0.  At that point, Timestamps are now  
enabled.  The downside of this is that now the originator has started  
their Timestamps values at 0, and must continue from there with their  
timestamps; they can't just suddenly jump to some arbitrary value  
because that could break PAWs.


Option #3
---------
Do nothing, and leave Timestamps alone as they are currently  
defined.  You negotiate them in the SYN, and then include them in  
every packet from then on.

One of the issues with Timestamps is that the TSecr value is defined  
to be valid anytime the ACK bit is set.  This works well with the  
initial SYN negotiation, but when you enable Timestamps midstream,  
the initiator has to send a Timestamps option with an invalid TSecr  
value, but the ACK bit will be set.  That's the case for both of the  
previous options.

So why should we change things?  My recollection was that the primary  
motivation was to conserve option space, to avoid having to put in  
the extra 12 bytes of TCP options on every packet until we get to the  
point where the sequence space might wrap, and then turn them on so  
that we can get PAWS to protect the rest of the connection.  But I'm  
not sure I buy that argument.  One of the things that you lose by  
deferring enabling Timestamps is that you don't get the RTT  
measurements that Timestamps provide.  Without Timestamps, using the  
typical BSD algorithm of timing one segment and waiting for an ACK,  
and adding in the Karn algorithm that you have to invalidate any  
measurements if you had to retransmit in that window, means that at  
best, you'll get one measurement per RTT.  At worst, you can get in a  
state where you never get a valid RTT measurement.  When you use the  
Timestamps option, the worst case is that you'll only get one  
measurement per RTT, and the best case is that you'll get multiple  
valid samples,

My viewpoint
------------
Right now, I'm inclined to leave the Timestamps option alone; you  
negotiate it during the SYN exchange, and then include it on every  
packet.  I'm willing to be convinced otherwise, but now I've placed a  
stake in the ground, and the mailing list will have to decide if  
there is sufficient reason to change the behavior.

			-David Borman


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm