Re: [tcpm] 1323bis - preparing for WGLC

[David Borman <[e-mail]>]

On Mar 20, 2013, at 11:25 AM, Joe Touch <[e-mail]> 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.

That really depends on the TCP option.

Turning on timestamps midstream without it being in the initial SYN isn't
technically that hard, as long as once you start sending and receiving them,
you continue to send/receive them for the rest of the connection.

The original reason for negotiating options in the SYN was twofold:
1) SYNs are reliably delivered, hence no additional negotiation
mechanism is needed.  2) At the time, all TCP implementations would
handle unknown options in the SYN, but some implementations would
crash if they received unknown TCP options in non-SYN packets.

Hopefully reason #2 is no longer needed.

Enabling TS midstream on the receiver is easy: if you receive any
packet with TS, then enable TS and use it for the duration of the
connection.  On the sender, you just start sending TS in every
packet, and remember the seq# of the first non-retransmitted packet
that was sent with TS.  If a TS is received in any packet, then enable
TS for the duration of the connection.  If no TS has been received when
an ACK that covers the initial TS seq# is received, then disable
sending TS for the duration of the connection.

As long as an unexpected TS mid-stream doesn't crash the other
side, then you're good to go, provided you take care of using
the TS for PAWS during the transition.

Other options, like WS, have to be negotiated in the SYN; trying
to change the WS value mid-stream using the current option would
require implementing additional negotiating mechanisms, since
ACKs are not reliably transmitted.

Honestly, the dictum that all TCP options have to be negotiated
in the SYN is to avoid sending TCP options mid stream to the other
side that the other side doesn't understand and isn't able to
properly ignore without crashing.  Be conservative in what you
send, liberal in what you receive.  But maybe it's time to say
that any TCP implementation that can't safely ignore unknown
options mid-stream is just plain broken and the standards shouldn't
continue to try to accommodate them anymore. 

			-David Borman

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

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.