Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 6 Mar 2013 16:13:39 +0000

Hello Michael,

thank you for your comments.

Re Section 1.3, as the next paragraph already talks specifically about the timestamp option, making the distinction clear sounds good. I believe that part of text originated when the RFC was also including the SACK option (which was split off).

How about this wording:
:
   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
   12 bytes to the 20-byte TCP header.  It is recommended that this TCP
   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. ...
:

Re: "new" option - caught a few instances (but only scanned for "new"). 

Re: Appendix G: 
	At least the section appended by me is kept in chronological order of the changes. I think the last editor (David) also appended in chronological order. Sorting them would probably break this ordering, but if the body of the text is found to be finished, I can follow up on this. Until that time, I believe a chronological order is easier to maintain...

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Scharf, Michael (Michael) [mailto:[email-masked]]
> Sent: Mittwoch, 06. März 2013 16:04
> To: Scheffenegger, Richard; tcpm ([email-masked])
> Subject: RE: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-
> 05.txt
> 
> All,
> 
> Since this document really needs feeback/review, please find attached
> three comments from my side (as individual contributor):
> 
> * Section 1.3
> 
>   1323bis states:
> 
>    Therefore, for each of the extensions defined below, it is recommended
>    that TCP options 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 original statement in 1323 is:
> 
>    Therefore, for each of the extensions defined below, TCP options will
> be
>    sent on non-SYN segments only when an exchange of options on the SYN
>    segments has indicated that both sides understand the extension.
> 
>   We discussed in the past quite a bit about late enablement of the
> timestamps
>   option, and I think that the outcome was to be conservative, as also
>   explained in that section in 1323bis.
> 
>   However, reading this new text now again, I wonder if Section 1.3 should
> distinguish
>   between timestamp and window scale option. Window scale options in non-
> SYNs are not
>   allowed by Section 3.1 ("This option is sent only in a SYN segment"), i.
> e., the
>   statement in Section 1.3 did not really apply even in the original 1323
> text.
>   But with the text change in 1323bis, we could maybe fix this.
> 
> * Word "new":
> 
>   1323bis uses at various places the term "new" option from the original
> 1323 text (e. g.,
>   "The scale factor is carried in a new TCP option, Window Scale."). I am
> not sure about the
>   general IETF handling for -bis documents, but given that 1323 options
> are very widely deployed, I
>   could imagine removing the word "new" where applicable.
> 
> * Appendix G
> 
>    Editorial nit: I think that the list of changes compared to 1323 could
> be sorted somehow (e. g. by increasing
>    number of the section where the change occured, or by protocol vs.
> editorial changes...).
> 
> Thanks
> 
> Michael
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Scheffenegger, Richard
> > Sent: Wednesday, February 13, 2013 5:26 PM
> > To: tcpm ([email-masked])
> > Cc: Alexander Zimmermann ([email-masked]);
> > [email-masked]; [email-masked]; Matthew Mathis
> > ([email-masked]); [email-masked]
> > Subject: Re: [tcpm] New Version Notification for
> > draft-ietf-tcpm-1323bis-05.txt
> >
> > Hi,
> >
> > I have updated the draft with the comments from the last IETF (mainly
> > trimmed much of the historic discussions and rationale in the
> > introduction section, leaving alone the detailed discussions and
> > implementers guidelines in the later sections describing the options
> > and mechanisms, after the comments from Matt).
> >
> > So, it really isn't that much shorter overall, but there is less text
> > to read before the real technical content starts.
> >
> > As this is a WG item, there'll probably be a short slot in the next
> > TCPM to get live feedback too!
> >
> > Best regards,
> >
> > Richard Scheffenegger
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Mittwoch, 13. Februar 2013 17:09
> > > To: Scheffenegger, Richard
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: New Version Notification for draft-ietf-tcpm-1323bis-05.txt
> > >
> > >
> > > A new version of I-D, draft-ietf-tcpm-1323bis-05.txt has been
> > > successfully submitted by Richard Scheffenegger and posted
> > to the IETF repository.
> > >
> > > Filename:	 draft-ietf-tcpm-1323bis
> > > Revision:	 05
> > > Title:		 TCP Extensions for High Performance
> > > Creation date:	 2013-02-13
> > > Group:		 tcpm
> > > Number of pages: 43
> > > URL:
> > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-
> > > 1323bis-05.txt
> > > Status:
> > http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis
> > > Htmlized:
> > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-05
> > > Diff:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-
> > > 05
> > >
> > > Abstract:
> > >    This document specifies a set of TCP extensions to improve
> > >    performance over paths with a large bandwidth*delay
> > product and to
> > >    provide reliable operation over very high-speed paths.
> > It defines
> > >    TCP options for scaled windows and timestamps.  The
> > timestamps are
> > >    used for two distinct mechanisms, RTTM (Round Trip Time
> > Measurement)
> > >    and PAWS (Protection Against Wrapped Sequences).
> > >
> > >    This document updates and obsoletes RFC 1323.
> > >
> > >
> > >
> > >
> > > The IETF Secretariat
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 6 Mar 2013 18:19:09 +0100

Hi Richard,

>    options on the SYN segments has indicated that both sides 

Yes, I had something along those lines in mind. Also, it is important to note here that Section 1 does not use RFC2119 language, while later sections are normative. This seems reasonable.

But maybe others have some thoughts as well?

Michael