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

Matt Mathis <> Wed, 30 May 2007 22:23 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HtWZe-0007uS-3S; Wed, 30 May 2007 18:23:22 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HtWZc-0007uA-4w for; Wed, 30 May 2007 18:23:20 -0400
Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] ( by with esmtp (Exim 4.43) id 1HtWZZ-0000ho-S8 for; Wed, 30 May 2007 18:23:20 -0400
Received: from ( []) by (8.13.8/8.13.3) with ESMTP id l4UMNHY2000214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 18:23:17 -0400 (EDT)
Received: from ( []) by (8.13.1/8.13.1) with ESMTP id l4UMNG19011407; Wed, 30 May 2007 18:23:17 -0400
Date: Wed, 30 May 2007 18:23:16 -0400
From: Matt Mathis <>
To: David Borman <>
Subject: Re: [tcpm] Re: RFC 1323: Timestamps option
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: TCP Maintenance and Minor Extensions WG <>, Joe Touch <>
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: <>, <>

You are being more conservative than necessary:   If I start out w/o
timestamps, then I am assuming that I will be at low rate (or perhaps a short
flow), and I don't need PAWS.  I just need to be sure that PAWS is fully
enabled before I would send the same sequence number within one MSL.

As long as I meet this criteria, all prior segments are protected by
either the MSL or as the "minus first" clock tick.

Which raises another point, if I start without timestamps and just a few
seconds later I am already 25% through the sequence space (think 10 Gigabit
Ethernet), and I then try to turn on timestamps and the other end balks, what
do I do?

One answer would be to force the window down to RTT*4294967296/MSL, but people
might think that is just a bit draconian.  Furthermore, this solution has the
nasty marketing problem that a correct highspeed stack is vastly slower than
an incorrect implementation in some situations. Other suggestions?  Ignore the

What happens today if you fail to request timestamps, and the path turns out
to be a much faster than 100 Mb/s?

Although permitting "late timestamps" has been on my todo list for years, I
have come to think that a safer solution is to unconditionally request
timestamps as long as the route of choice does not point to a directly
connected compressing modem on a voice grade line.  There are now several
secondary control algorithms (such as the receiver side autotuning in Linux)
that require timestamps for optimal operation, and thus provide motivation for
(almost) unconditionally turning them on.

Matt Mathis
Work:412.268.3319    Home/Cell:412.654.7529
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Wed, 30 May 2007, David Borman wrote:

> Hi Matt,
> On May 30, 2007, at 10:59 AM, Matt Mathis wrote:
> > I had assumed that you can "fake" paws as follows: once you receive
> > a late
> > timestamp negotiation (in either role), you treat any later
> > untimestamped
> > segments as though they bear the timstamp just before the earliest
> > time stamp
> > seen.   I believe that this is optimal, given other assumptions.
> Yes, for PAWS you only need the clock to tick at least once per
> sequence wrap, so as long as Timestamps are enabled before the first
> wrap, PAWS should work just fine this way.
> >
> > I think it also works well enough to treat any later untimestamped
> > segments as though they bear the timestamp just before the the most
> > recently
> > received timestamp.  This is actually the same if the timestamps do
> > not
> > advance during the negotiation RTT.   (Well enough means that the
> > failures
> > are neither frequent nor serious).
> The problem is, how do you tell that it is a "later untimestamped"
> segment, and not an old segment from before we enabled timestamps?
> This would allow old packets from before we enabled timestamps to
> arrive after the sequence wrap and be treated as OK, the very thing
> that PAWS is trying to prevent.  That's one of the reasons why once
> you enable timestamps, you have to then include them in every packet
> for the duration of the connection.
> 			-David Borman

tcpm mailing list