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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

I'm wondering if you presume that using the existing code point for late
negotiation.
Suppose If we use new code point, do we still have problems you mentioned
below?

Thanks,
--
Yoshi

On Tue, May 27, 2014 at 1:04 PM, Joe Touch <[e-mail]> wrote:

> Hi, all,
>
> Late negotiation has too many problems, as have been repeatedly raised on
> this list:
>
>         - prevents use of the timestamp to help address PAWS for
>         the initial SYN
>
>         - a new connection that either avoids TS in SYN or
>         uses just "use TS" (two-byte) flag can't know when
>         to engage the timestamp and what initial value to use
>
> Joe
>
>
> On 5/27/2014 11:36 AM, Yoshifumi Nishida wrote:
>
>> Hi folks,
>>
>> I've submitted a proposal for this a while ago:
>> http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00
>> Although it's expired now, I will submit a new version within a couple
>> of weeks or so.
>> The late negotiation is also discussed in the draft.
>> As it will change the semantics of TS, it presumes to use new code point
>> (or use timestamp field in SYN). But, I'm happy to discuss on this point.
>>
>> One tricky thing for RFC1323 is that it uses TS for two purposes:
>> timestamping and PAWS and one purpose of the draft is to separate them.
>> I appreciate any feedback on the draft.
>>
>> Thanks,
>> --
>> Yoshi
>>
>> On Tue, May 27, 2014 at 5:12 AM, Scharf, Michael (Michael)
>> <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>      > Well, if it's just for Timestamps, just use an "invalid" length
>>     of 2 as
>>      > a "Late TS permitted".
>>      >
>>      > Maintaining the same option value and this would be rather straight
>>      > forward.
>>
>>     Interesting proposal. But actually we are not really short of option
>>     numbers. If we get e.g. 8 bytes in a significant number of SYNs
>>     (which is our real bottleneck), I think we could also spend a new
>>     option codepoint.
>>
>>      > Personally, I'd like to combine this with a change in semantics, if
>>      > SACK is negotiated on the same session as well, to allow more
>>     efficient
>>      > loss recovery (lost retransmission detection during a loss recovery
>>      > episode). I should have a unpublished draft sitting around here
>> about
>>      > that aspect.
>>
>>     A change in semantics would also be a reason for a new codepoint,
>> imho.
>>
>>     Michael
>>
>>
>>      > The TS option handling seems to be rather generous by middleboxes,
>> in
>>      > general.
>>      >
>>      > Richard Scheffenegger
>>      >
>>      > > -----Original Message-----
>>      > > From: tcpm [mailto:[e-mail]
>>     <mailto:[e-mail]>] On Behalf Of Scharf,
>>      > Michael
>>      > > (Michael)
>>      > > Sent: Dienstag, 27. Mai 2014 13:49
>>      > > To: Scheffenegger, Richard; Eggert, Lars; Joe Touch
>>      > > Cc: [e-mail] <mailto:[e-mail]>
>>      > > Subject: Re: [tcpm] timestamp options (was Re: New Version
>>      > Notification
>>      > > for draft-touch-tcpm-tcp-edo-01.txt)
>>      > >
>>      > > > For late TS, we would still need at least 2 Bytes during
>>      > > > <SYN>/<SYN,ACK> to allow that capability.
>>      > > >
>>      > > > However, as the useful values of Window Scale only cover
>>     0..14 [1],
>>      > > > one approach to save SYN option space would be to negotiate
>>     up to 4
>>      > > > binary
>>      > > > (on/off) plus WS in a new single 3-byte option.
>>      > >
>>      > > I might be wrong, but I've thought so far that "replacing" the
>>     window
>>      > > scale option would be pretty difficult. We already had reports of
>>      > > middleboxes that parse this option because they try to understand
>>      > rwnd (or
>>      > > they do not parse the option even if they should, or they have
>>      > entirely
>>      > > broken logic to mess up TCP...). I think one example are
>> firewalls
>>      > that
>>      > > try to detect whether segments are in-window. Another example
>> could
>>      > be
>>      > > PEPs that try to tune rwnd (if they still exist in the wild).
>>      > >
>>      > > My understanding so far was that a solution only for timestamps
>>     would
>>      > be
>>      > > the most low-hanging fruit.
>>      > >
>>      > > Michael
>>      > >
>>      > > _______________________________________________
>>      > > tcpm mailing list
>>      > > [e-mail] <mailto:[e-mail]>
>>
>>      > > https://www.ietf.org/mailman/listinfo/tcpm
>>
>>     _______________________________________________
>>     tcpm mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>>