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

[Matt Mathis <[e-mail]>]

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
problem?

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.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm