Re: [tcpm] 1323bis - preparing for WGLC

[Andre Oppermann <[e-mail]>]

On 20.03.2013 17:25, Joe Touch wrote:
> 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.

Seconded.

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

Is required the correct RFC keyword?  Shouldn't the sentence be rewritten
to make it use the "MUST" keyword?

-- 
Andre

>>     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
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>