Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt)

[Mark Allman <[e-mail]>]

> You talk about limiting the rate; that doesn't help a connection
> that cannot proceed because packets with the TS option are being
> dropped, e.g., by a midbox. 

Sure- in a spec you'd have to consider that.  But, I am not going to
pretend that it is difficult to detect and react to.

> Further, what happens to the packets? When and how do you know when
> the TS isn't working? When do you give up?

One RTT later.  Don't pretend this is difficult.  I didn't fully specify
it in an **email message**, but don't pretend this is some leap into
the Great Protocol Engineering Unknown, Joe.

> 1323bis talks about a list of mechanisms that rely on timestamps, more
> than just PAWS. What happens to those when TS is optional or started
> late?

If you want to use something and that something needs the TS option to
be on for the entire connection (e.g., Eifel) then you turn it on for
the entire connection.  Fine.  I have no problem with that.  But, then
you're not simply wasting 10 bytes in every packet, but you're getting
something for it.

However, on its own 1323(bis) wastes 10 bytes in every packet because
RTTM is not helpful and PAWS is nearly never needed.  So, it seems to me
that instead of dogmatically putting our foot down we could re-think
providing the information for PAWS when we actually need PAWS.  I guess
that is radical engineering or something, I dunno ...

allman