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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Mon, Jun 2, 2014 at 9:35 AM, Joe Touch <[e-mail]> wrote:
>
>
> On 6/2/2014 1:55 AM, Yoshifumi Nishida wrote:
>
>> Hi Joe,
>>
>> On Fri, May 30, 2014 at 5:58 PM, Joe Touch <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
> ...
>
>      I.e., you'd need to implement a new TWHS per option that changes
>>     state. That's a mess. And I don't even want to think about what
>>     happens when you have multiple options that change state at the same
>>     time.
>>
>> With regard to A-PAWS draft, you don't need tight synchronization
>> between sender and receiver necessarily.
>> It is the receiver to send a signal that "BTW, I support A-PAWS, so you
>> don't have to send TS in every segments"
>> Then, the sender can omit TS segments from time to time, or it can just
>> ignore the signal.
>>
>
> First, you definitely need to negotiate TS-support during SYN exchange IMO.
>
> Second, if you decide to turn on TS use in mid-stream, you have to decide
> what to do with non-TS packets - do you just always accept them? Let's say
> you declare all non-TS packets that come before TS-use to be "before" all
> TS-use packets (the non-TS to TS-use transition provides a a distributed
> systems "consistent cut") - we'll look at the other case below.
>
> In that case - which, AFAICT is the best you can do - you still have:
>
>         - no PAWS protection within the non-TS set within a connection
>
>         - no PAWS protection between different streams (that reuse
>         the port-pair) during non-TS use
>

> The most dangerous time is when a connection starts - that's when you
> really need to avoid having things leak from previous connections that
> could have persisted beyond the expected MSL. So that's when you'd want to
> start using TS, but then you have no gain because (again, AFAICT) once you
> start using TS you should never turn it off.
>

Please let me explain my proposal a bit more.
What I am thinking is something like this:
  1: A-PAWS can be enabled in SYN exchange or in the middle of session.
(I'm still thinking choosing one of them or both)
  2: It presumes the use of TS at the beginning. If TS option is disabled,
the connection never uses TS and there's no PAWS. Period.
  3: If TCP receives non-TS packets before enabling A-PAWS, the behavior
will be out-of-scope of the draft. It should follow the way described in
1323bis
So, it starts using TS and tries to turn it off (unless it won't affect
PAWS). But, I still think this might be possible. Please let me know if I
miss something.

Also, In order to address the issue in connection starts, I have added some
texts in Section 4 in http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00
In a nutshell, we cannot enable this feature under a certain conditions
where there are risks for conflicts between previous connections. If I
overlook some conditions, please let me know.

Thanks,
--
Yoshi