Re: [tcpm] 1323bis - preparing for WGLC

[Joe Touch <[e-mail]>]

Hi, all,

On 3/20/2013 7:07 AM, Scheffenegger, Richard wrote:
> Hi group,
> running up to and during the IETF 86, the following points were raised
> w.r.t 1323bis. I hope this lengthy email makes it through your tl;dr filter…
>
...
>  2. Guidance regarding late TS negotiation:
>
> This is a technical (semantic) change of timestamps; the upcoming -07
> version of the draft will have this text added; is the WG satisfied with
> this wording, or shall more specific (2119) wording be added:
>
>     A TCP MAY send the Timestamps option (TSopt) in an initial <SYN>
>     segment (i.e., a segment containing a SYN bit and no ACK bit).  Once
>     a 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.
>     Note that it is RECOMMENDED to negotiate the use of the timestamp
>     option during the initial handshake.  Although this document is less
>     restrictive regarding the use of the timestamp option when not sent
>     initially, any guidance and discussion of potential issues when
>     timestamp is enabled late in a session is beyond the scope of this
>     document.
 >
> 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.

> Another suggestion was to add a sentence like “Timestamps MUST be
> negotiated in <SYN> and <SYN,ACK> unless another mechanism allows
> enabling them in during an established session.  Such a  mechanism is
> outside the scope of this document.”

This is the one I expected, and is fine. It can either be confirmed by 
the option itself or by some other option; the overall assumption is 
that "the set of options that MAY be used during a TCP connection MUST 
be negotiated during the 3WHS". (that text is outside the scope of this 
doc, though)

>  3. More appropriate introductory text; the following statement will
>     supersede very old text (that apparently addressed WS, TS and SACK
>     back in RFC1072); this was already presented at IETF 86 and received
>     no objections.
>
>     The window scale option negotiates fundamental parameters of the TCP
>     session.  Therefore, it is only sent during the initial handshake.
>     Furthermore, the window scale option will be sent in a <SYN,ACK>
>     segment only if the corresponding option was received in the initial
>     <SYN> segment.
>     The timestamps option may appear in any data or ACK segment, adding

The "*" inserted below is explained further down...

>     12 bytes to the 20-byte TCP header. *  It is recommended that this TCP

Again, IMO recommended should be REQUIRED (in all caps too).

>     option will be sent on non-SYN segments only after an exchange of
>     options on the SYN segments has indicated that both sides understand
>     the extension.

The portion below is a bit different:

>                   We believe that the bandwidth saved by reducing
>     unnecessary retransmission timeouts will more than pay for the extra
>     header bandwidth.

it talks about the bandwidth of the overall connection; it's not 
specific to the SYN exchange. It might be useful to move this up to the 
"*" above.

Joe