Re: [tcpm] 1323bis - preparing for WGLC

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

Thank you David!


You made some insightful comments, that I agree with!

To this, I want to add some thoughts:


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


It's really the middleboxes that we need to work around in such a scenario...

1) In the forward path, a middlebox might start dropping segments, that contain TSopt which wasn't negotiated for. Thus a receiver never sees these data segments...

2) Or a middlebox might scrub the TSopt from the data packets before delivery...


3) In the return path, again a middle box might stop forwarding an ACK containing TSopt, if previous segments of that flow didn't have TSopt enabled.

4) Or that middlebox again scrubs the TSopt before delivery.


Cases 1+3 and 2+4 are virtually identical to the sender: 

In 1+3, the sender would not see any ACKs beyond the seq#, where TSopt was stated; Eventually multiple back-to-back RTOs would happen. 

In 2+4, the sender would see the ACKs, but without any TSopt. However, the receiver might have started using TSopt already on the receiver processing, thus it would be better to keep on sending with TSopt enabled.

Only when a RTO (or the 2nd RTO) for the data packet with the Seq# where TSopt was enabled happens, than it would be save to disable TSopt again... But once Snd.Fack or Snd.Una goes beyond the Seq# of the first TSopt segment, there should be no way to disable TSopt again...


Does that sound reasonable?



Richard Scheffenegger




> -----Original Message-----
> From: David Borman [mailto:[e-mail]]
> Sent: Donnerstag, 21. März 2013 15:07
> To: Joe Touch
> Cc: Scheffenegger, Richard; tcpm ([e-mail])
> Subject: Re: [tcpm] 1323bis - preparing for WGLC
> 
> 
> 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.