[Bloat] [iccrg] Musings on the future of Internet Congestion Control

Sebastian Moeller moeller0 at gmx.de
Sun Jun 19 12:53:20 EDT 2022


I might be out to lunch here, but why not accept a "total" speed limit per TCP flow and simply expect bulk transfers to employ more parallel streams; which is what I think download manager apps are already doing for a long time?

And if we accept an upper ceiling per TCP flow we should be able to select a reasonable upper bound for the initial window as well, no?



> On Jun 15, 2022, at 19:49, Dave Taht via Bloat <bloat at lists.bufferbloat.net> wrote:
> 
> ---------- Forwarded message ---------
> From: Michael Welzl <michawe at ifi.uio.no>
> Date: Wed, Jun 15, 2022 at 1:02 AM
> Subject: [iccrg] Musings on the future of Internet Congestion Control
> To: <iccrg at irtf.org>
> Cc: Peyman Teymoori <peymant at ifi.uio.no>, Md Safiqul Islam
> <safiquli at ifi.uio.no>, Hutchison, David <d.hutchison at lancaster.ac.uk>,
> Stein Gjessing <steing at ifi.uio.no>
> 
> 
> Dear ICCRGers,
> 
> We just got a paper accepted that I wanted to share:
> Michael Welzl, Peyman Teymoori, Safiqul Islam, David Hutchison, Stein
> Gjessing: "Future Internet Congestion Control: The Diminishing
> Feedback Problem", accepted for publication in IEEE Communications
> Magazine, 2022.
> 
> The preprint is available at:
> https://arxiv.org/abs/2206.06642
> I thought that it could provoke an interesting discussion in this group.
> 
> Figures 4 and 5 in this paper show that, across the world, network
> links do not just become "faster”: the range between the low end and
> the high end grows too.
> This, I think, is problematic for a global end-to-end standard - e.g.,
> it means that we cannot simply keep scaling IW along forever (or, if
> we do, utilization will decline more and more).
> 
> So, we ask: what is the way ahead?  Should congestion control really
> stay end-to-end?

	Do we really have any other option? It is the sender that decides how much to dup into the network after all. Sure the network could help by giving some information back as a hint (say a 4bit value encoding the maximum relative queue-fill level measured along the full one-way path) but in the end, unless the network is willing to police its idea about acceptable send behavior it is still the sender's decision what tho send when, no?
Given the discussion about L4S and FQ it seems clear that the "network" is not prepared to implement anything close to what is required to move congestion control into the network... I have a feeling though that I am missing your point and am barking up the wrong tree ;)

Regards
	Sebastian


> 
> Cheers,
> Michael
> 
> _______________________________________________
> iccrg mailing list
> iccrg at irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg
> 
> 
> -- 
> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



More information about the Bloat mailing list