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

[Neal Cardwell <[e-mail]>]

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.

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
>
>
>
>
>