[tcpm] 1323bis - preparing for WGLC

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

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


a)      Is it necessary or useful, to have an Appendix D giving a Pseudo Code example?

     This section was added early in the process of creating the draft. As a couple of years have passed since, it was suggested to poll the WG if this text is valuable, or if the document would be better off without a strict Pseudocode example. Note that certain points that were added later  in the text of the draft, are not reflected in the Pseudocode (ie. late TS negotiation), and the Pseudocode also does NOT touch any of the interactions with other TCP subsystems (ie. Window Retraction).

     From an editorial point of view, removing an incomplete example, that may be misleading, is easier than working out a full-fledged pseudocode covering all the edge cases... (I updated my view of this from neutral to remove; the document is long enough even without an incomplete example).

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

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

c)      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
   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.  We believe that the bandwidth saved by reducing
   unnecessary retransmission timeouts will more than pay for the extra
   header bandwidth.

d)      Better text in the new section 2.4. describing the corner case when the Window Scale  option results in a Window Retraction during Loss Recovery; but no suggestions for better wording have been made so far. Does the WG agree with these steps, or should there be a different description around that particular case:

2.4.  Addressing Window Retraction

   When a non-zero scale factor is in use, there are instances when a
   retracted window can be offered [Mathis08].  The end of the window
   will be on a boundary based on the granularity of the scale factor
   being used.  If the sequence number is then updated by a number of
   bytes smaller than that granularity, the TCP will have to either
   advertise a new window that is beyond what it previously advertised
   (and perhaps beyond the buffer), or will have to advertise a smaller
   window, which will cause the TCP window to shrink.  Implementations
   MUST ensure that they handle a shrinking window, as specified in
   section 4.2.2.16 of [RFC1122].

   For the receiver, this implies that:

   1)  The receiver MUST honor, as in-window, any segment that would
      have been in-window for any ACK sent by the receiver.

   2)  When window scaling is in effect, the receiver SHOULD track the
      actual maximum window sequence number (which is likely to be
      greater than the window announced by the most recent ACK, if more
      than one segment has arrived since the application consumed any
      data in the receive buffer).

   On the sender side:

   3)  The initial transmission MUST honor window on most recent ACK.

   4)  On first retransmission, or if the sequence number is out-of-
      window by less than (2^Rcv.Wind.Scale) then do normal
      retransmission(s) without regard to receiver window as long as the
      original segment was in window when it was sent.

   5)  On subsequent retransmissions, treat such ACKs as zero window
      probes.



I'm currently in the process of updating the -07 "Changes " Appendix to split it into an technical/editorial part, as mentioned in my IETF 86 talk. Once that finishes, -07 will be submitted, together with any changes which the WG agrees.

Best regards,

Richard Scheffenegger