From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DF0ED3B29E for ; Sun, 10 Jul 2022 16:01:41 -0400 (EDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oAd7a-003eJm-GQ; Sun, 10 Jul 2022 22:01:38 +0200 Received: from 178.115.63.84.wireless.dyn.drei.com ([178.115.63.84] helo=smtpclient.apple) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1oAd7Z-0007wr-0Q; Sun, 10 Jul 2022 22:01:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) From: Michael Welzl In-Reply-To: Date: Sun, 10 Jul 2022 22:01:17 +0200 Cc: Dave Taht , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <95FB54F9-973F-40DE-84BF-90D05A642D6B@ifi.uio.no> References: <6458C1E6-14CB-4A36-8BB3-740525755A95@ifi.uio.no> <7D20BEF3-8A1C-4050-AE6F-66E1B4203EE1@gmx.de> <4E163307-9B8A-4BCF-A2DE-8D7F3C6CCEF4@ifi.uio.no> To: Sebastian Moeller X-Mailer: Apple Mail (2.3696.100.31) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 178.115.63.84 is neither permitted nor denied by domain of ifi.uio.no) client-ip=178.115.63.84; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 255416E4251836AC5F64956550FD38D0C12E38A7 X-UiOonly: 92DDE809FA741D463041A7B6F6EEC0518FEE6C80 Subject: Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2022 20:01:42 -0000 Hi ! > On Jul 10, 2022, at 7:27 PM, Sebastian Moeller = wrote: >=20 > Hi Michael, >=20 > so I reread your paper and stewed a bit on it. Many thanks for doing that! :) > I believe that I do not buy some of your premises. you say so, but I don=E2=80=99t really see much disagreement here. = Let=E2=80=99s see: > e.g. you write: >=20 > "We will now examine two factors that make the the present situation = particularly worrisome. First, the way the infrastructure has been = evolving gives TCP an increasingly large operational space in which it = does not see any feedback at all. Second, most TCP connections are = extremely short. As a result, it is quite rare for a TCP connection to = even see a single congestion notification during its lifetime." >=20 > And seem to see a problem that flows might be able to finish their = data transfer business while still in slow start. I see the same data, = but see no problem. Unless we have an oracle that tells each sender = (over a shared bottleneck) exactly how much to send at any given time = point, different control loops will interact on those intermediary = nodes. You really say that you don=E2=80=99t see the solution. The problem is = that capacities are underutilized, which means that flows take longer = (sometimes, much longer!) to finish than they theoretically could, if we = had a better solution. > I might be limited in my depth of thought here, but having each flow = probing for capacity seems exactly the right approach... and doubling = CWND or rate every RTT is pretty aggressive already (making slow start = shorter by reaching capacity faster within the slow-start framework = requires either to start with a higher initial value (what increasing IW = tries to achieve?) or use a larger increase factor than 2 per RTT). I = consider increased IW a milder approach than the alternative. And once = one accepts that a gradual rate increasing is the way forward it falls = out logically that some flows will finish before they reach steady state = capacity especially if that flows available capacity is large. So what = exactly is the problem with short flows not reaching capacity and what = alternative exists that does not lead to carnage if more-aggressive = start-up phases drive the bottleneck load into emergency drop territory? There are various ways to do this; one is to cache information and = re-use it, assuming that - at least sometimes - new flows will see the = same path again. Another is to let parallel flows share information. Yet = another is to just be blindly more aggressive. Yet another, chirping. > And as an aside, a PEP (performance enhancing proxy) that does not = enhance performance is useless at best and likely harmful (rather a PDP, = performance degrading proxy). You=E2=80=99ve made it sound worse by changing the term, for whatever = that=E2=80=99s worth. If they never help, why has anyone ever called = them PEPs in the first place? Why do people buy these boxes? > The network so far has been doing reasonably well with putting more = protocol smarts at the ends than in the parts in between. Truth is, PEPs are used a lot: at cellular edges, at satellite links=E2=80= =A6 because the network is *not* always doing reasonably well without = them. > I have witnessed the arguments in the "L4S wars" about how little = processing one can ask the more central network nodes perform, e.g. flow = queueing which would solve a lot of the issues (e.g. a hyper aggressive = slow-start flow would mostly hurt itself if it overshoots its capacity) = seems to be a complete no-go. That=E2=80=99s to do with scalability, which depends on how close to the = network=E2=80=99s edge one is. > I personally think what we should do is have the network supply more = information to the end points to control their behavior better. E.g. if = we would mandate a max_queue-fill-percentage field in a protocol header = and have each node write max(current_value_of_the_field, = queue-filling_percentage_of_the_current_node) in every packet, end = points could estimate how close to congestion the path is (e.g. by = looking at the rate of %queueing changes) and tailor their = growth/shrinkage rates accordingly, both during slow-start and during = congestion avoidance. That could well be one way to go. Nice if we provoked you to think! > But alas we seem to go the path of a relative dumb 1 bit signal giving = us an under-defined queue filling state instead and to estimate relative = queue filling dynamics from that we need many samples (so literally too = little too late, or L3T2), but I digress. Yeah you do :-) Cheers, Michael