[tcpm] Extending RFC 1323 window scaling?

[Michael Scharf <[e-mail]>]

Hi all,

I'd like to put for discussion an idea for a new TCP option that would
extend RFX 1323. Some background information why this option might be
useful can be found in later sections. I would appreciate very much
any comments, suggestions, or objections concerning this idea.

The new TCP option would offer a slight extension of the window scaling
mechanism according of RFC 1323. The sole purpose is to allow a scaled
receive window in <SYN,ACK> segments, which RFC 1323 forbids. This
could be realized by a new TCP option that may be added to <SYN,ACK>
segments that already include an RFC 1323 WSopt option. The format
of the option could be:

  +---------+---------+------------------+
  | Kind    |Length=4 |SSEG.WND (shifted)|
  +---------+---------+------------------+

The SSEG.WND field includes the receive window, shifted by the scale
factor announced in the WSopt option. The usage of this new option
would be very simple (using the nomenclature of RFC 1323):

 - If a host decides to announce a receive window larger than 64 KB in
   a <SYN,ACK>, it may add this new TCP option. The SSEG.WND field is
   scaled by the scale factor in WSopt, in the same way as the
   receiver window in the TCP header is scaled in non-<SYN> segments:

     SSEG.WND = RCV.WND >> Rcv.Wind.Scale

   The receive window SEG.WND field in the TCP header should be set to
   SEG.WND=min(RCV.WND,64 KB).

 - If a host receives this option in a <SYN,ACK> segment, it determines
   the receiver's advertised window as 

     SND.WND = max(SEG.WND, SSEG.WND << Snd.Wind.Scale)

   This means that a larger receive window included in the new option
   should overwrite the unscaled receive window in the TCP header, which
   can be at most 64 KB.

The option is backward-compatible and therefore should not create
interoperability problems: If a host does not understand this option,
it just uses the receive window SEG.WND in the TCP header. It may thus
underestimate the amount of available buffer space at the other host,
but this is not critical. The implementation of this new TCP option
would be straightforward, given that it is only a slight modification
of the window scaling according to RFC 1323.



Motivation and background information:

The motivation for proposing this new TCP option is the experimental
Quick-Start TCP extension (RFC 4782). As described in the draft
"draft-scharf-tsvwg-quick-start-flow-control-00.txt", in one usage
scenario Quick-Start may only be effective if the other host announces
a large amount of free buffer space in the <SYN,ACK> segment.

According to RFC 1323, the receive window in a <SYN> or <SYN,ACK> is
never scaled, even if the connection endpoints successfully negotiate
window scaling. One reason seems to be backward compatibility to
non-RFC 1323 capable hosts. As a consequence, the maximum amount of
free buffer space that a host can announce in a <SYN> or <SYN,ACK>
segment is 64 KB. However, when a Quick-Start request is included in
the <SYN> segment, and a corresponding response is in the <SYN,ACK>, a
host may want to announce a receive window larger than 64 KB in this
<SYN,ACK>, in order to allow the other TCP host to fully use the
approved Quick-Start rate.

As workaround, "draft-scharf-tsvwg-quick-start-flow-control-00.txt"
proposes to send an additional empty <ACK> segment after the
<SYN,ACK>, which includes the true amount of available buffer
space. This is a simple solution that probably does not cause
significant deployment problems. However, this proposal results in an
overhead of an additional (empty) segment and is sensitive to packet
reordering.

As a consequence, it would make sense to have a mechanism that is able
to announce a receive window larger than 64 KB in the <SYN,ACK>
segment itself (there is no need to do this in <SYN> segments). There
are two basic possibilities:

  (1) The semantics of the SEG.WND field in the TCP header could be
      changed, i. e., the receive window is scaled in <SYN,ACK>
      segments under some constraints. Whether or not the receive
      window is scaled could be announced explicitly by a flag, or
      implicitly, e. g., due to the presence of Quick-Start options or
      other options. However, changing the semantics of the receive
      window header field creates interoperation issues with hosts
      that do not implement such a modification.

  (2) The true amount of free buffer space is announced somehow, and
      overwrites the (unscaled) value in the TCP header, which remains
      unscaled in order to be compatible with hosts that do not
      implement this mechanism. This requires some new mechanism to
      signal a scaled receive window in <SYN,ACK> segments.

The proposed new TCP option is a straightforward realization of
approach (2).

Currently, only hosts supporting the experimental Quick-Start
extension could benefit from this new option, since announcing large
receive windows during a standard TCP slow-start does not make
sense. Still, the new option could also be useful for other future
experimental TCP congestion control modifications (e. g., XCP?), if
they cause a behavior that is much more aggressive than today's TCP
standard slow start.

Any comments? Opinions?

Michael

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm