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

[Joe Touch <[e-mail]>]

On 5/27/2014 11:06 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> I'm wondering if you presume that using the existing code point for late
> negotiation.

I had.

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

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

IMO, it's not worth the trouble.

Joe


>
> Thanks,
> --
> Yoshi
>
> On Tue, May 27, 2014 at 1:04 PM, Joe Touch <[e-mail]
> <mailto:[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
>         <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)
>         <michael.scharf@alcatel-__lucent.com
>         <mailto:[e-mail]>
>         <mailto:michael.scharf@__alcatel-lucent.com
>         <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]>
>              <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]>
>         <mailto:[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]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>               > > https://www.ietf.org/mailman/__listinfo/tcpm
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>              _________________________________________________
>              tcpm mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/__listinfo/tcpm
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
>