Re: [tcpm] [EXTERNAL] Re: Linux doesn’t implement RFC3465

[Neal Cardwell <[e-mail]>]

I think Yoshifumi is suggesting that if the WG re-spins  RFC5681 then in
addition to folding in discussion of ABC/RFC3465 the RFC5681bis could also
include the IW10 content in RFC6928. That could help save time in avoiding
promoting RFC6928 from experimental to proposed standard.

That sounds reasonable to me as well. Although the initial window is a
somewhat independent issue that might evolve independently from the
congestion algorithm itself, so I can imagine advantages to keeping it
separate.

neal


On Mon, Aug 9, 2021 at 12:39 PM Yuchung Cheng <ycheng=
[e-mail]> wrote:

> Sorry I don't understand your suggestion. Is that related to ABC? could
> you explain more
>
> On Mon, Aug 9, 2021 at 1:41 AM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>> I don't have a strong opinion on this yet, But, if we *could* move in
>> this direction, it might be good to think about the IW explanation in
>> RFC5681 as well?
>> if we do this, we might not need to discuss promoting RFC6928.
>> --
>> Yoshi
>>
>> On Sat, Aug 7, 2021 at 7:57 AM Neal Cardwell <ncardwell=
>> [e-mail]> wrote:
>>
>>> I also agree with Yuchung’s suggestion, for all of the reasons he
>>> provided.
>>>
>>> best,
>>> neal
>>>
>>>
>>> On Fri, Aug 6, 2021 at 3:59 PM Vidhi Goel <vidhi_goel=
>>> [e-mail]> wrote:
>>>
>>>> I agree with Yuchung’s suggestion for all the reasons he provided. And
>>>> its better to have it at one place.
>>>>
>>>> Vidhi
>>>>
>>>> On Aug 6, 2021, at 12:53 PM, Yuchung Cheng <
>>>> ycheng=[e-mail]> wrote:
>>>>
>>>> Hi WG
>>>>
>>>> I have been wondering if we (= IETF) should just update RFC5681
>>>> directly, instead of another RFC3465-bis with experimental status.
>>>>
>>>> Appropriate byte counting is essential but the RFC5681 of L=1 is
>>>> detrimental. There are far more people who read RFC5681 to implement the
>>>> new stack instead of RFC3465. So we should fold the experimental RFC3465
>>>> updates into RFC5681 directly, and obsolete RFC3465.
>>>>
>>>> This is orthogonal to the final value of L :-)
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 3, 2021 at 9:42 AM Yuchung Cheng <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> In experiments a few years ago on DC networks, values over L=8
>>>>>>>> resulted in a noticeable increase in packet drops and retransmissions
>>>>>>>> (without pacing). Windows TCP has been using L=8 for many years now. If we
>>>>>>>> do want to specify a fallback L value for implementations that cannot pace,
>>>>>>>> my suggestion would be to use the value 8.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Neal, are there cases where Linux is or can be deployed with
>>>>>>>> infinite L and no pacing?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, "infinite L and no pacing" is the default behavior for Linux
>>>>>>> TCP, starting in 2013 for slow-start and then starting in 2015 for
>>>>>>> congestion avoidance.
>>>>>>>
>>>>>> To be more clear: both fq_pacing and TCP pacing have been disabled by
>>>>>> default in Linux upstream. We do not know how much Linux senders enable
>>>>>> them today besides the Google servers.
>>>>>>
>>>>>> Regarding L = 8, to avoid another round of why or why not. We could
>>>>>> say inf-L causes line-rate burst up to the stretched ACK degree so put a
>>>>>> comfortable L if you prefer, then mention implementation practice like
>>>>>> yours. At the end of the day it's ad-hoc (or "art") and subject to change.
>>>>>> It might be sensible to cap at cwnd to disincentivize receivers /
>>>>>> middle-boxes bunching up 10 rounds of ACKs.
>>>>>>
>>>>> Sorry please ignore my previous message about the cwnd cap. It is
>>>>> completely unnecessary -- since with ack-clocking and appropriate counting,
>>>>> a correct sender would never release more than a cwnd-worth of data. I was
>>>>> imagining the multiple application-limited burst could let the receiver
>>>>> keep holding up ACKs, but that can never exceed a cwnd worth of data.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> Yuchung pasted the URLs for the exact Linux commits above, which are:
>>>>>>>
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f9843a751d0a2057f9f3d313886e7e5e6ebaac9
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cd981dcf174d26805a032aefa791436da709bee
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c22bdca94782f05b9337d8548bde51b2f38ef17f
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=814d488c61260521b1b3cc97063700a5a6667c8f
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e73ebb0881ea5534ce606c1d71b4ac44db5c6930
>>>>>>>
>>>>>>> But I understand that not everyone is in a position to read
>>>>>>> GPL-licensed code. :-)
>>>>>>>
>>>>>>> best regards,
>>>>>>> neal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* tcpm <[e-mail]> *On Behalf Of * Neal Cardwell
>>>>>>>> *Sent:* Monday, August 2, 2021 4:18 PM
>>>>>>>> *To:* Vidhi Goel <[e-mail]>
>>>>>>>> *Cc:* Extensions <[e-mail]>; Mark Allman <[e-mail]>
>>>>>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn’t implement RFC3465
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> > The fact is that Linux CC has long moved to infinite L since 2031,
>>>>>>>>
>>>>>>>> So, if our experience is with L=\infinity and it is demonstrably OK
>>>>>>>> why don't we say *THAT* instead of "make L=5 or L=10"?  I would
>>>>>>>> submit that it makes more sense to leverage experience than it does
>>>>>>>>
>>>>>>>> to make things up.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, I agree that would be a great approach to take.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> So, we are saying it is fine to ignore L completely and simply
>>>>>>>> increase cwnd by bytes_acked during slow start? And if this causes large
>>>>>>>> bursts to be sent out (when an implementation doesn’t do pacing), that is
>>>>>>>> fine?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, I think that is the proposal on the table, and it sounds good
>>>>>>>> to me.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A rationale would be:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> (1) Implementations SHOULD pace (RFC 7661).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> (2) Implementations that don't pace will generally be causing large
>>>>>>>> bursts for many different reasons anyway (data and/or ACK aggregation in
>>>>>>>> the network or end hosts), restart from idle,...) so having a constant L
>>>>>>>> does not provide enough protection from bursts to justify the cost in
>>>>>>>> reduced performance (in the form of slower slow-start). In support of this,
>>>>>>>> experience with this as the default behavior in Linux TCP over the
>>>>>>>> 2013-2021 period suggests this works well enough in practice.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> neal
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tcpm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>>
>>>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>>
>>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>