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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Fri, May 30, 2014 at 5:58 PM, Joe Touch <[e-mail]> 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