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 <[email protected]> > wrote: > > ---------- Forwarded message --------- > From: Michael Welzl <[email protected]> > Date: Wed, Jun 15, 2022 at 1:02 AM > Subject: [iccrg] Musings on the future of Internet Congestion Control > To: <[email protected]> > Cc: Peyman Teymoori <[email protected]>, Md Safiqul Islam > <[email protected]>, Hutchison, David <[email protected]>, > Stein Gjessing <[email protected]> > > > 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 > [email protected] > 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 > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
