> On Jun 19, 2022, at 6:53 PM, Sebastian Moeller via Bloat > <bloat@lists.bufferbloat.net> wrote: > > 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?
Using multiple flows is a way to do it, albeit not a very good way (better to use a better congestion control than just run multiple instances - but of course, one works with what one can - a download manager is on the receiver side and can achieve this there). This is not related to the IW issue which is relevant for short flows, which are the most common type of traffic by far (a point that our paper makes, along with many prior publications). >> On Jun 15, 2022, at 19:49, Dave Taht via Bloat <bloat@lists.bufferbloat.net> >> wrote: >> >> ---------- Forwarded message --------- >> From: Michael Welzl <mich...@ifi.uio.no> >> Date: Wed, Jun 15, 2022 at 1:02 AM >> Subject: [iccrg] Musings on the future of Internet Congestion Control >> To: <ic...@irtf.org> >> Cc: Peyman Teymoori <peym...@ifi.uio.no>, Md Safiqul Islam >> <safiq...@ifi.uio.no>, Hutchison, David <d.hutchi...@lancaster.ac.uk>, >> Stein Gjessing <ste...@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? In a scenario where a connection-splitting PEP is installed before a lower-capacity downstream path segment, this PEP can already ask for more data today. It’s doing it in an ugly way, by “cheating” TCP, which yields various disadvantages… so I’d say that this is part of the problem. PEPs exist, yet have to do things poorly because they are treated as if they shouldn’t exist, and so they become unpopular for, well, having done things poorly... > 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 ;) I guess you are. This is about middleboxes doing much “heavier” stuff. Cheers, Michael
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
