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

["Scheffenegger, Richard" <[e-mail]>]

Hi Joe,

> 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

This one is genuine. However, given the prevalence of non-TS TCP sesssions and no wide-spread havoc caused by NOT having PAWS on the SYN, it appears to me that the impact is manageable. (Of course it would be nicer to have PAWS on SYN, but as long as SYN option space is limited...)

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

Well, as this would be a new mechanism, there should be some broad guidance given; I would assume that the latest onset - if late TS is negotiated for - would be when either direction has sent at most 2^31 - (2^16 << Window.scale) bytes; and a receiver that sees the full TS must then start to reflect TS as usual, independent of its own relative offset into the session. And never relinquish from sending TS even when some packets - ie. retransmissions, or due to middleboxes on a changed path - not contain a TS from the other side.

As for the semantic change, I propose that when the session has SACK enabled as well as late TS, then the TS should reflect the TS of the segment triggering the ACK (we can discuss what should happen during in-sequence delayed ACK processing though; the relevant aspect for me is during loss - SACK recovery - to not mask the timestamps of retransmitted packets as per 1323bis; For legacy RTTM processing, the presence of a SACK option is indicative enough to NOT do normal RTTM processing - although a sender could choose to do so particularly for the loss recovery episodes. Having the (unique) Timestamp/SACK block combinations during loss recovery would allow more efficient, faster and also packet conserving recovery of lost retransmissions - unlike the current method of last resort, RTO.


Best regards,

Richard Scheffenegger


> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Dienstag, 27. Mai 2014 22:04
> To: Yoshifumi Nishida; Scharf, Michael (Michael)
> Cc: Scheffenegger, Richard; Eggert, Lars; [e-mail]
> Subject: Re: [tcpm] timestamp options (was Re: New Version Notification
> for draft-touch-tcpm-tcp-edo-01.txt)
> 
> 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
> >
> >