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

[Joe Touch <[e-mail]>]

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