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

Joe Touch <> Wed, 30 May 2007 10:41 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HtLcK-00057m-Ms; Wed, 30 May 2007 06:41:24 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HtLcI-00057D-3P for; Wed, 30 May 2007 06:41:22 -0400
Received: from ([]) by with smtp (Exim 4.43) id 1HtLcG-0008Pc-Jt for; Wed, 30 May 2007 06:41:22 -0400
Received: from ([]) by (SMSSMTP with SMTP id M2007053006411608571 ; Wed, 30 May 2007 06:41:16 -0400
X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.099,BAYES_00: -1.665
Received: from [] ([]) by; Wed, 30 May 2007 06:41:13 -0400
Message-ID: <>
Date: Wed, 30 May 2007 03:40:40 -0700
From: Joe Touch <>
User-Agent: Thunderbird (Windows/20070326)
MIME-Version: 1.0
To: David Borman <>
Subject: Re: [tcpm] Re: RFC 1323: Timestamps option
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
Cc: TCP Maintenance and Minor Extensions WG <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1265392090=="

Hi, David,

I had some questions below...

David Borman wrote:
> Hi,
> I've been having some off-line discussion about how to turn on
> Timestamps mid-stream, and I'm coming to a clearer picture.  I'm now now
> leaning towards changing to allow this to happen in a standard way.  I
> think I can now more clearly enumerate the specific issues about
> enumerating them mid-stream.
> First, do you or do you not include Timestamps in the SYN exchange, and
> how much do you care about interoperability with existing 1323
> implementations?  If you do not include Timestamps negotiation, then I
> would expect that mid-stream enabling of Timestamps would only work on
> modified hosts that understand the new rules.
> I've come up with a variation on Option #2
> Option 2a:
> ----------
> The Timestamps option is sent only in the SYN and SYN,ACK packet.  If
> both sides understand deferred enabling of Timestamps, then the
> connection will continue without Timestamps until one of them initiates
> Timestamps by including it in a packet.  Once Timestamps have been sent
> or received after the initial SYN,ACK, they are then sent in all packets
> for the duration of the connection.
> This has the advantage of knowing up front that the other side
> understands the Timestamps option, so when you later decide to enable
> them, you just turn them on and start sending them, you don't have to
> try to figure out midstream whether or not the other side understands
> Timestamps.  When talking to an RFC-1323 implementation, since the other
> side will include Timestamps in all packets, the option will be enabled
> right away

How is reordering handled? I.e., all new packets may be stamped, but
reordering could affect how that's seen at the receiver. (see below...)

> However, I do have an idea for a deterministic way to know when
> Timestamps have been fully enabled.  When you first start sending
> Timestamps (either initiating, or in response to receiving a
> Timestamps), you fill in the exact same value for TSval in every packet
> that you send, until you receive a packet with a TSecr equal to that
> value.  At that point you know that Timestamps are now enabled on both
> sides, and you start sending new TSval values.  You don't do any RTT
> calculations until you get a packet that acknowledges new data, and has
> a TSecr value that is beyond the initial TSval used.  This should
> address all three scenarios: the data receiver initiating enabling
> Timestamps, the data sender initiating enabling Timestamps, and both the
> sender and receiver enabling Timestamps at the same time.  PAWS will
> work just fine, because it doesn't require the clock to tick for each
> packet, just at least once for each sequence space.

The problem with enabling options mid-stream is that you haven't cleared
the packets from the system; this is not the case during SYN exchange.

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?

> So, when a deferred Timestamps implementation connects to an RFC-1323
> implementation, what should be the desired behavior?
>     a) Timestamps are enabled for the entire connection
>     b) Timestamps are disabled for the entire connection
> I think it should be "a".

This is asking whether deferred timestamps disables legacy 1323 use,
IMO, and I agree that the only conclusion is (a).


> On Jan 26, 2007, at 12:33 PM, Borman, David wrote:
>> 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

Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

tcpm mailing list