Re: [tcpm] 1323bis - preparing for WGLC

["Scharf, Michael (Michael)" <[e-mail]>]

To me, this discussion would perfectly fit into a new ID on allowing late TS enabling. It would be short and straightforward. But a separate ID could be easier than adding these kinds of thoughts to the 1323bis document, which we want to finish...

I think that such a new document would be allowed by "The Timestamp option MUST be negotiated during the initial <SYN> and <SYN,ACK> unless another mechanism allows to enable it during an established session.".

Michael (chair hat off)
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Scheffenegger, Richard
> Sent: Thursday, March 21, 2013 4:07 PM
> To: David Borman; Joe Touch
> Cc: tcpm ([e-mail])
> Subject: Re: [tcpm] 1323bis - preparing for WGLC
> 
> 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.
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>