Re: [tcpm] [Technical Errata Reported] RFC8312 (5907)

[Mirja Kuehlewind <[e-mail]>]

Hi Neal, hi all,

I rejected this errata, as I think you are right about section 4.2. However, the text in section 5.1 does not really indicate that this is the case, so I guess we could file a separate editorial errata to clarify this.

Do the authors have any opinions here?

Mirja


> On 15. Nov 2019, at 20:54, Neal Cardwell <[e-mail]> wrote:
> 
> On Thu, Nov 14, 2019 at 12:53 PM Neal Cardwell <[e-mail]> wrote:
>> 
>> On Thu, Nov 14, 2019 at 12:12 PM RFC Errata System
>> <[e-mail]> wrote:
>>> 
>>> The following errata report has been submitted for RFC8312,
>>> "CUBIC for Fast Long-Distance Networks".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid5907
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Elliott Ecton <[e-mail]>
>>> 
>>> Section: 5.1
>>> 
>>> Original Text
>>> -------------
>>> +--------+----------+-----------+------------+-----------+----------+
>>>   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
>>>   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
>>>   +--------+----------+-----------+------------+-----------+----------+
>>>   |  10^-2 |       12 |        12 |         12 |        12 |       12 |
>>>   |  10^-3 |       38 |        38 |         38 |        38 |       59 |
>>>   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
>>>   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
>>>   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
>>>   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
>>>   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
>>>   +--------+----------+-----------+------------+-----------+----------+
>>> 
>>>                                  Table 1
>>> 
>>> Corrected Text
>>> --------------
>>> +--------+----------+-----------+------------+-----------+----------+
>>>   |   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
>>>   | Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
>>>   +--------+----------+-----------+------------+-----------+----------+
>>>   |  10^-2 |       12 |        12 |          3 |         6 |       11 |
>>>   |  10^-3 |       38 |        38 |         19 |        33 |       59 |
>>>   |  10^-4 |      120 |       263 |        120 |       187 |      333 |
>>>   |  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
>>>   |  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
>>>   |  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
>>>   |  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
>>>   +--------+----------+-----------+------------+-----------+----------+
>>> 
>>>                                  Table 1
>>> 
>>> Notes
>>> -----
>>> The CUBIC average window sizes for 10^2 and 10^3 are incorrect in the original text using expression 6.
>> 
>> I strongly suspect that the original text is correct.
>> 
>> Note that the proposed edit would cause the average congestion window
>> size of CUBIC to be below that of "TCP W", the Reno [RFC5681] window,
>> in the cases with loss rates of 10^-2 and 10^-3. But as mentioned in
>> section 4.2. "TCP-Friendly Region", where the native CUBIC curve
>> computation produces a target congestion window that is lower than the
>> congestion window Reno would use, the CUBIC algorithm instead uses the
>> Reno target congestion window. So the average congestion window size
>> of CUBIC should not be below that of Reno. I believe that is why in
>> the original table the average congestion window for "TCP W" and CUBIC
>> match in cases with loss rates of 10^-2 and 10^-3 and with CUBIC using
>> C=0.04 or C=0.4.
>> 
>> Are there tests or simulations showing CUBIC achieving a lower
>> congestion window in these cases with loss rates of 10^-2 and 10^-3?
>> 
>> best,
>> neal
> 
> I got a bounce from my "reply-all". It seems there was a typo in the
> e-mail address of the report, and it should have been:
>  Elliott Ecton <[e-mail]>
> ...rather than:
>  Elliott Ecton <[e-mail]>
> 
> I am following up to make sure the [e-mail] address
> has the reply and the thread has the correct e-mail address.
> 
> best,
> neal
>