Subject: Re: [tcpm] 1323bis - TS nego

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Mar 2013 14:30:44 +0000

Hi Andre, Joe,

Thank you for your feedback. Further comments are still very welcome!

> >> I have received suggestions, to increase the "MAY" in the first
> >> sentence to a "SHOULD" (but that might indicate to implementers, that
> >> any TCP session SHOULD have TS enabled, not that TS MAY be used, and
> >> if, it SHOULD be negotiated during SYN).
> >
> > IMO, the first sentence should be a MUST. TCP needs to know about all
> > the options it needs to support during the initial handshake. If you
> > turn on the option later and it isn't supported, there's no way to
> "handshake" to let the other end know.
> 
> Seconded.

That section now reads:

   A TCP MAY send the Timestamps option (TSopt) in an initial <SYN>
   segment.  The Timestamp option MUST be negotiated during the initial
   <SYN> and <SYN,ACK> unless another mechanism allows to enable it
   during an established session.  However, such a mechanism is outside
   the scope of this document.  When TSopt has been sent or received in
   a non <SYN> segment, it MUST be sent in all segments.  Once a TSopt
   has been received in a non <SYN> segment, then any successive segment
   that is received without the RST bit and without a TSopt MAY be
   dropped without further processing, and an ACK of the current SND.UNA
   generated.

I think the "MAY" in the very first sentence is appropriate to underline that this really is an optional enhancement to TCP, not a "REQUIRED" one - not even in the context of RFC1323bis. One can implement/enable Window Scale without TS and vice versa. 

The 2nd Sentence then alludes to the fact, that Joe pointed out, that any TCP option that may be used later in the session, must^h^h^h^h should be negotiated initially.

The particular wording here actually still allows a passive (receiver side) late TS enablement - making the current Linux behavior compliant. Note that this is almost the same wording as in 1323.

Also, it describes a very simple mechanism, actually: 

When a sender eventually starts sending TSopt, it can never go back - even when the ACKs never contain any TSopt. Which IMHO is the only way to do it, really, as potentially a middlebox has not removed the TSopt on the forward path, and only "cleans" the TSopt from the ACKs on the return path. Thus I'm not sure, if "MUST" in the 2nd sentence is the proper 2119 word...

However, 

>> the overall assumption is that 
>> "the set of options that MAY be used during a TCP connection MUST 
>> be negotiated during the 3WHS".

limits the effective number of useful TCP options to 20 (as at the very least, two bytes,  option + len, have to be in the <SYN>). 

Also, such a requirement implicitly rules out potential later suggestions to "collapse" certain sets of options to a single TCP option in the <SYN>. Thus I'm not fully convinced, that we want to make this an explicit requirement (although I see, that effectively it's already an implicit requirement with all the middleboxes).

Best regards,

Richard Scheffenegger

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Mar 2013 13:42:32 -0700

Hi, Richard,

One additional point:

On 3/21/2013 7:30 AM, Scheffenegger, Richard wrote:
> limits the effective number of useful TCP options to 20 (as at the
> very least, two bytes, option + len, have to be in the <SYN>).
>
> Also, such a requirement implicitly rules out potential later
> suggestions to "collapse" certain sets of options to a single TCP option
> in the <SYN>.

I wasn't assuming this, so the limit isn't 20 options.

Further, one trivial solution is to collapse a set of known options to a 
mechanism that doesn't requiring parsing, e.g., to a define a new 
"AGGREGATE OPTION" KIND that consists of a list of the single-byte 
options to be negotiated; that could even allow up to 39 individual 
options ;-)

Yes, that's complex, and yes, it's new, but just poking around the 
solution space for now...

Joe