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

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 <ycheng@google.com> wrote:

>
>
> On Mon, Aug 2, 2021 at 6:12 PM Yuchung Cheng <ycheng@google.com> wrote:
>
>>
>>
>> On Mon, Aug 2, 2021 at 5:53 PM Neal Cardwell <ncardwell=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>>>
>>>
>>> On Mon, Aug 2, 2021 at 8:46 PM Praveen Balasubramanian <pravb=
>>> 40microsoft.com@dmarc.ietf.org> 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 <tcpm-bounces@ietf.org> *On Behalf Of * Neal Cardwell
>>>> *Sent:* Monday, August 2, 2021 4:18 PM
>>>> *To:* Vidhi Goel <vidhi_goel@apple.com>
>>>> *Cc:* Extensions <tcpm@ietf.org>; Mark Allman <mallman@icir.org>
>>>> *Subject:* [EXTERNAL] Re: [tcpm] Linux doesn’t implement RFC3465
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <vidhi_goel@apple.com> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <mallman@icir.org> 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
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>