Re: [tcpm] [Technical Errata Reported] RFC7323 (5585)

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

Hi Marco,

Do you have an example for an actual invalid implementation?

I agree with the assessment that the text is not strictly mathematically 
correct when stating that the maximum receive window may go all the way 
up to 2^30, when the maximum really is 2^30-2^14.

I would suggest to accept these two errata, but hold them for a Document 
Update.

Incidentially, this specific observation is where Yoshi suggested to 
allow a window scale value all the way up to to 15 (as the maximum 
signaled receive window will be (2^31 - 2^15), and still allows 
in-window vs. out-of-window differentiation. (See 
draft-nishida-tcpm-maxwin-02).

Regards,
   Richard


Am 27.12.2018 um 20:30 schrieb RFC Errata System:
> The following errata report has been submitted for RFC7323,
> "TCP Extensions for High Performance".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5585
> 
> --------------------------------------
> Type: Technical
> Reported by: Marco Caspers <[e-mail]>
> 
> Section: 2.2
> 
> Original Text
> -------------
> 2.2.  Window Scale Option
> 
>     The three-byte Window Scale option MAY be sent in a <SYN> segment by
>     a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
>     both send and receive window scaling, and (2) communicate the
>     exponent of a scale factor to be applied to its receive window.
>     Thus, a TCP that is prepared to scale windows SHOULD send the option,
>     even if its own scale factor is 1 and the exponent 0.  The scale
>     factor is limited to a power of two and encoded logarithmically, so
>     it may be implemented by binary shift operations.  The maximum scale
>     exponent is limited to 14 for a maximum permissible receive window
>     size of 1 GiB (2^(14+16)).
> 
> 
> Corrected Text
> --------------
> 2.2.  Window Scale Option
> 
>     The three-byte Window Scale option MAY be sent in a <SYN> segment by
>     a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
>     both send and receive window scaling, and (2) communicate the
>     exponent of a scale factor to be applied to its receive window.
>     Thus, a TCP that is prepared to scale windows SHOULD send the option,
>     even if its own scale factor is 1 and the exponent 0.  The scale
>     factor is limited to a power of two and encoded logarithmically, so
>     it may be implemented by binary shift operations.  The maximum scale
>     exponent is limited to 14 for a maximum permissible receive window
>     size of approximately 1 GiB ((2^30-1) - (2^14-1)).
> 
> 
> Notes
> -----
> Left shift inserts zero's on the right hand side so the maximum window size is actually approximately 16KiB shy of 1 GiB and not exactly 1Gib as stated.
> 
> The calculation given 2^(16+14) is mathematically incorrect.
> Stating invalid calculations will lead to invalid implementations.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC7323 (draft-ietf-tcpm-1323bis-21)
> --------------------------------------
> Title               : TCP Extensions for High Performance
> Publication Date    : September 2014
> Author(s)           : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.
> Category            : PROPOSED STANDARD
> Source              : TCP Maintenance and Minor Extensions
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>