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

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 2 Jun 2014 01:55:25 -0700

Hi Joe,

On Fri, May 30, 2014 at 5:58 PM, Joe Touch <[email-masked]> wrote:

>
>
>  Suppose If we use new code point, do we still have problems you
>> mentioned below?
>>
>
> It depends:
>
> - I don't think it matters vs. using the existing codepoint with a
> different length (e.g., as a flag in the SYN); they are equivalent in being
> uniquely identifiable.
>

OK.

>
> - I don't like the idea of setting new TCP flags or changing the meaning
> of flags in the middle of a connection. That undermines the notion of a
> connection IMO.
>
> To do so, the source would have to keep track of the last byte of the
> segment in which the change occurs, and wait for a confirmation in the ACK
> of that byte; ditto for the other end.
>
> They'd need to resend things if lost *with the same flags* to indicate the
> change.

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.

> 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.
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2014 09:35:41 -0700

On 6/2/2014 1:55 AM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> On Fri, May 30, 2014 at 5:58 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> 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.

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.

--------------

In the case where you CAN continue to flip back and forth between TS-use 
and non-TS, then *very non-TS packet* becomes a time-bomb for both this 
connection and future connections.

That's what PAWS was supposed to avoid, but you're stepping right into it.

-----

My conclusion is that if you turn on TS you have to do it at the 
beginning of a connection, or you might as well not use TS at all.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 02 Jun 2014 13:50:48 -0400

> I think it was Mark Allman who questioned a while ago whether the
> benefits of the timestamp option are worth spending 10 bytes in every
> packet. (But I can't find the email now.) 

Just to be clear ...

  - The RTTM scheme for getting a better RTO seems generally dubious to
    me (based on an old paper I wrote with Vern).  It does not seem
    worthwhile to spend 10 bytes / packet to get more RTT samples per
    RTT from the perspective of getting a better RTO (because we don't).

  - However, if you're sending fast then you still have a sequence wrap
    issue.  The only standard way that I am aware of that we deal with
    that issue is timestamps in every packet.  So, for this I certainly
    think there is value in having the TS option there.

That said, there is ample opportunity to turn TS on in the midst of a
connection before we need it for PAWS, but allowing the vast majority of
the connections to save the bytes.

allman

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 2 Jun 2014 23:18:22 -0700

Hi Joe,

On Mon, Jun 2, 2014 at 9:35 AM, Joe Touch <[email-masked]> wrote:
> 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.
>

> 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