From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (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 BD5C53CB35 for ; Tue, 12 Jul 2022 18:28:01 -0400 (EDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oBOMI-006diG-Dt; Wed, 13 Jul 2022 00:27:58 +0200 Received: from ip-81-73.sn2.clouditalia.com ([83.211.81.73] 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 1oBOMH-0006fJ-84; Wed, 13 Jul 2022 00:27:58 +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: <32A9050A-B81F-4838-BE7F-691F0670DB84@gmx.de> Date: Wed, 13 Jul 2022 00:27:54 +0200 Cc: Dave Taht , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <9412D3D7-E141-4441-A46C-A8A4F765E60F@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> <95FB54F9-973F-40DE-84BF-90D05A642D6B@ifi.uio.no> <0BAAEF4C-331B-493C-B1F5-47AA648C64F8@ifi.uio.no> <9DF7ADFC-B5FC-4488-AF80-A905FECC17E8@gmx.de> <32A9050A-B81F-4838-BE7F-691F0670DB84@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3696.100.31) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 83.211.81.73 is neither permitted nor denied by domain of ifi.uio.no) client-ip=83.211.81.73; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 88E576D52A4A79773DF6DA3C6C85E38283B05C32 X-UiOonly: 6AC7E94C9C0292DAEE479005CEBB16C4E95188BC 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: Tue, 12 Jul 2022 22:28:01 -0000 I=E2=80=99ll cut some clutter: >> What you=E2=80=99re doing is jumping ahead. I suggest doing this with = research rather than an email discussion, but that=E2=80=99s what = we=E2=80=99re now already into. >=20 > [SM] Sure, except my day job (snip) that=E2=80=99s ok - I wasn=E2=80=99t trying to tell you off for = discussing ideas! - I was just trying to clarify: 1. we agree there=E2=80=99s a problem; 2. our paper made the point that research is needed; 3. now you=E2=80=99re discussing possible research ideas, which is the = step that comes after. =E2=80=A6 and trying to discuss 3. in depth easily gets hand-wavy, = unless one actually does the research first. My So all I say is that = this discussion is a bit pointless (I=E2=80=99m trying to end it - = please! :-) ) > Maybe a reason for me to respectfully bow out of this discussion as = talk is cheap and easy to come by even without me helping. Well, let=E2=80=99s at least try to keep this short=E2=80=A6 >> Okay, there is ONE thing that such a flow gets: the RTT. =E2=80=9CBlind= except for RTT measurements=E2=80=9D, then. >=20 > [SM] I guess your point is "flow does not know the maximal = capacity it could have gotten"? Yes. >> Importantly, such a flow never learns how large its cwnd *could* have = become without ever causing a problem. Perhaps 10 times more? 100 times? >=20 > [SM] Sure. ATM the only way to learn a path's capacity is = actually to saturate the path*, but if a flow is done with its data = transfer, having if exchange dummy data just to probe capacity seems = like a waste all around. That=E2=80=99s an example of details of a possible future mechanism. And = yes, I wouldn=E2=80=99t advocate this particular one. > I guess what I want to ask is, how would knowing how much available = but untapped capacity was available at one point help? >=20 >=20 > *) stuff like deducing capacity from packet pair interval at the = receiver (assuming packets sent back to back) is notoriously imprecise, = so unless "chirping" overcomes that imprecision without costing too many = round trips worth of noise supression measuring capacity by causing = congestion is the only way. Not great. We=E2=80=99re dealing with a world of heuristics here; nothing is ever = 100% known beforehand about Internet transfers in general. So, something = like your aside here would also never be a binary 100% bad case - how = bad it would be depends on many parameters which are worth = investigating, per envisioned mechanism - and then we=E2=80=99re doing = research. So =E2=80=9CI imagine mechanism X, but this will never work=E2=80= =9D is exactly the kind of discussion that's a waste of time, IMO. >> I don=E2=80=99t even think that this name has that kind of history. = My point was that they=E2=80=99re called PEPs because they=E2=80=99re = *meant* to improve performance; >=20 > [SM] That is not really how our economic system works... = products are primarily intended to generate more revenue than cost, it = helps if they offer something to the customer, but that is really just a = means to extract revenue... >=20 >=20 >> that=E2=80=99s what they=E2=80=99re designed for. You describe =E2=80=9C= a PEP that does not enhance performance=E2=80=9D, which, to me, is like = talking about a web server that doesn=E2=80=99t serve web pages. Sure, = not all PEPs may always work well, but they should - that=E2=80=99s = their raison d=E2=80=99=C3=AAtre. >=20 > [SM] That is a very optimistic view, I would love to be able to = share. This is not about optimism. If a device doesn=E2=80=99t improve = performance, it shouldn=E2=80=99t be called a PEP. If someone does it = nevertheless, okay, but then that=E2=80=99s not the device we=E2=80=99re = discussing here. I.e.: I say =E2=80=9Cbut we=E2=80=99re discussing a web server, not a = DNS server=E2=80=9D and you say =E2=80=9Cthis is optimistic=E2=80=9D. = That=E2=80=99s just weird. >>>> There are plenty of useful things that they can do and yes, I = personally think they=E2=80=99re the way of the future - but **not** in = their current form, where they must =E2=80=9Clie=E2=80=9D to TCP, cause = ossification, >>>=20 >>> [SM] Here I happily agree, if we can get the nagative = side-effects removed that would be great, however is that actually = feasible or just desirable? >>>=20 >>>> etc. PEPs have never been considered as part of the congestion = control design - when they came on the scene, in the IETF, they were = despised for breaking the architecture, and then all the trouble with = how they need to play tricks was discovered (spoofing IP addresses, = making assumptions about header fields, and whatnot). That doesn=E2=80=99t= mean that a very different kind of PEP - one which is authenticated and = speaks an agreed-upon protocol - couldn=E2=80=99t be a good solution. >>>=20 >>> [SM] Again, I agree it could in theory especially if = well-architected.=20 >>=20 >> That=E2=80=99s what I=E2=80=99m advocating. >=20 > [SM] Well, can you give an example of an existing = well-architected PEP as proof of principle? It doesn=E2=80=99t really exist yet - else I wouldn=E2=80=99t need to = advocate it :-) but: e.g., for QUIC, one could extend MASQUE proxies = with performance-enhancing functions. I believe that colleagues from = Ericsson are advocating that. For TCP, RFC 8803 sets a very good = example, IMO. >>> [SM] This is no invention, but how capitalism works, sorry. The = party paying for the PEP decides on using it based on the advantages it = offers for them. E.g. a mobile carrier that (in the past) forcible = managed to downgrade the quality of streaming video over mobile links = without giving the paying end-user an option to use either choppy high = resolution or smooth low resolution video. By the way, that does not = make the operator evil, it is just that operator and paying customers = goals and desires are not all that well aligned (e.g. the operator wants = to maximize revenue, the customer to minimize cost). >>=20 >> You claim that these goals and desires are not well aligned (and a = PEP is then an instrument in this evil) >=20 > [SM] Again this is expected behavior in our economic system, I = have not and will not classify that as "evil", but I will also not start = believing that companies offer products just to get a warm and fuzzy = feeling. It is part of the principle of how a market economy works that = the goals of the entities involved are opposite of each other, that is = how a market is supposed to optimize resource allocation. >=20 >> - do you have any proof, or even anecdotes, to support that claim? >=20 > [SM] The claim that sellers want the highest revenue/cost ratio = while buyers want the lowest cost/utility seems hardly controversial or = requiring a citation. Aha. No, I understand you now. But it *is* more subtle than that, = because the market will also make unhappy customers switch to a = different company, except when they have no choice (monopoly). >> I would think that operators generally try to make their customers = happy (or they would switch to different operators). Yes there may be = some misalignments in incentives, but I believe that these are more = subtle points. E.g., who wants a choppy high resolution video? Do such = users really exist? >=20 > [SM] I might be able to buffer that choppy video well enough to = allow smooth playback at the desired higher resolution/quality (or I = might be happy with a few seconds to compare quality of displays), given = that I essentially buy internet access from my mobile carrier that = carrier should get out of my way. (However if the carrier also offers = "video-optimization" as an opt-in feature end-users can toggle at will = that is a different kettle of fish and something I would consider good = service). IIRC a German carrier was simply downforcing quality for all = video streaming at all time, mostly to minimize cost and bandwidth = usage, which pretty much looks like an exercise to minimize operational = cost and not to increase customer satisfaction. So yes there are = "misalignments in incentives" that are inherent and structural to the = way we organize our society. (I am sort of okay living with that, but I = will not sugar coat it). You say =E2=80=9Cyou=E2=80=9D might be able to buffer - but was this = about a specific application? Anyway, let=E2=80=99s say a provider downgrades Netflix and instead = tries people to opt in to their own, costly service instead. I suspect = that this would make most customers want to switch their provider. So - in this way, the market does enforce a certain alignment of = interests nevertheless. >> Now, if we just had an in-network device that could divide the path = into a =E2=80=9Ccore=E2=80=9D segment where it=E2=80=99s safe to use a = pretty large IW value, and a downstream segment where the IW value may = need be smaller, but a certain workable range might be known to the = device, because that devices sits right at the edge=E2=80=A6 >=20 > [SM] This seems to be problematic if end-to-end encryption is = desired, no? But essentially this also seems to be implemented already, = except that we call these things CDNs instead of proxies ;) (kidding!) Potentially solvable with MASQUE proxies (see above). >>> [SM] I understand, however I see clear reasons why L4S is = detrimental to your stated goals as it will getting more information = from the network less likely. I also tried to explain, why I believe = that to be a theoretically viable way forwards to improve slow-start = dynamics. Maybe show why my proposal is bunk while completely ignoring = L4S? Or is that the kind of "particular solution" you do not want to = discuss at the current stage? >>=20 >> I=E2=80=99d say the latter. We could spend weeks of time and tonds of = emails discussing explicit-feedback based schemes=E2=80=A6 instead, if = you think your idea is good, why not build it, test it, and evaluate its = trade-offs? >=20 > [SM] In all honesty, because my day-job is in a pretty different = field and I do not believe I can or even would want to perform = publishable CS research after hours (let alone find a journal accepting = layman submissions without any relevant affiliation). That=E2=80=99s totally fine, but then it=E2=80=99s not worth the time to = discuss the idea, frankly. >> I don=E2=80=99t see L4S as being *detrimental* to our stated goals, = BTW - but, as it stands, I see limitations in its usefulness because TCP = Prague (AFAIK) only changes Congestion Avoidance, at least up to now. = I=E2=80=99m getting the impression that Congestion Avoidance with a = greedy sender is a rare animal. >=20 > [SM] Erm, DASH-type traffic seems quite common, no? There the = individual segments transmitted can be large enough to reach (close to) = capacity? Here I don=E2=80=99t have enough data (though there are some papers we = could dig into)=E2=80=A6 but I suspect that the answer is: no, they are = probably not large enough to reach capacity (and "close to=E2=80=9D: who = knows?). Cheers, Michael