From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 27A513CB35 for ; Wed, 13 Jul 2022 02:16:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657693014; bh=VIdOcEFYwmSUqOL6/IEze+7HMrLClkij3pT4rdllfeg=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=iBIm1VpBl//L8sxm1HiPDHqMRqr0WSpfy5w56AGNbTKrozTZyiP5ftbR7GVv2qtND nGiXz+SMLZ7lmtYtEs2JUXx9uHpqmoYn9NvAiKoEOj0QPrgEfVu/C4hsWBTPAQf/Ae JkTcim5dAXhjLLRs8OMnVaPfhErkoea2wljdfpwA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([80.187.112.125]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MWih0-1o4phO071U-00X2ir; Wed, 13 Jul 2022 08:16:54 +0200 Date: Wed, 13 Jul 2022 08:16:51 +0200 From: Sebastian Moeller To: Michael Welzl CC: Dave Taht , bloat User-Agent: K-9 Mail for Android In-Reply-To: <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> <9412D3D7-E141-4441-A46C-A8A4F765E60F@ifi.uio.no> Message-ID: <7BCCAC37-5460-4CFA-9DF0-B55B775071BA@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8U+lomPaBM6l9lsoGr33JmV7/5cNkfeeK1O3kpjkmyyFrWvf/2p GDg2D/AgiLvE8KNg/LUg9yPsCdnBlU+/R6OjvnqAn2slAwO9MMEdGGWhvqEz9Y9dGk4Xh4w XDUei3/sUiu1uBGYjKs0dyVpD+pHNCxk3BtMoUGzAgDtHsJ6XKcswWNPINdzK7XojVccSY0 9GlodHTwFtdnrNRkssKPQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gY7EXvTyME8=:DIPnh/wGCNSQLqm1yWACOn TNEwyDDGU9ncfddCM8RbL+mNd73GAJT76CU68mYAHCZhpgn5nVYZN/q/gloZb/OmP3Xv+9Kgz K6uyzLko+v6+Q4paMqphcyMmyQk9Ee4TVTjvk+6CxDK9EcgLRLZM8uTK1PSJXbYtuaAI41i16 lAXlQyNPHSMz5iU5oDN9RTdVb72Ud79GqBBK090pCK1mvx008B6s1yX1X2vAkNbjaRriILShd wAOobshUPEZgfHpQ5U4owPASAYY5p1J9BYZjvsiIfAVUsnvdiI7ZDvGhHdDejXkWKXuuxmV1O wONzHaQpu8uqyB5+wv3ui+VS60nqqDP+IwAJj+vz3zQQsnUi8pHnXiZyRjTnzW07oQVqc8wZ5 bEhcdW5muzsjzO7wmt7om/2k9aI3xwQ9DMWGLruonAsX9ibK5SaSJzyq0IjxmasUq9wJiDV/U Eu7GuwdFeeLcoBvpWD5NokZeTAIXYQYkWUc/ftqoJ+X+SmZ2VnjmJwLpMbXwO7wz44lyN0dwi uDTi0+5sgCW4APzZkKhIioj1t9c3dM30X/pV/KtOtq5k+lOFcVdEIovdpZlnosH23tiHZ91LQ ck8DrBj900riuM23N7NElL3kofMQykIF+56QoQnCIbBBAspJvl3sFoNQlUTkAReJDJfGEZx2y AzMkKu444NOIIXRKD7Ie4G90z5qfxO/HXlqMVaE5XDmgh1F04NzvwSZrfp5h5w/7Nu+83fn/T J4qiMWaebaEN3vw3/iR+3OhcSv+QkRva3TbvLaMg4f+sClmQ0Joz9+CVmmUI2CSC2fauXFNNx c6DXnBziwriWfXoV5vdwj1gy4hRgIX6nuiCTvpGHg0/SXZdADu1RbnzjuTc8RiZdMevxAosOl W7DtPIqchZpdbjvfAmEyDqiyH4ZCojNq2CGrmCtKBssteNlV4hDu0ZzhCe6edjSaX9XHsYzxl rfxPNopbDjJQb8UiNeMXlO7mDEofsWVbHvRNcyUgO+draG9opktzTW2pXunQGiBYCavkbcQ/z PLOgOLqdn/JnuK8DiJP/s2E6avPKBHU490irZwELUvexx05PT4aAT/XnRElS6cVku4gTfo4Fd ReQU+SRO6L61pp2ZO5TMPRnpsjVq1elBvkATXRrlXfK4HcdY7yRp8HWGQ== 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: Wed, 13 Jul 2022 06:16:56 -0000 Hi Michael, On 13 July 2022 00:27:54 CEST, Michael Welzl wrot= e: >I=E2=80=99ll cut some clutter: > > >>> What you=E2=80=99re doing is jumping ahead=2E I suggest doing this wit= h research rather than an email discussion, but that=E2=80=99s what we=E2= =80=99re now already into=2E >>=20 >> [SM] Sure, except my day job >(snip) > >that=E2=80=99s ok - I wasn=E2=80=99t trying to tell you off for discussin= g ideas! - I was just trying to clarify: >1=2E we agree there=E2=80=99s a problem; Apparently I was not clear enough; no, I do not see current slow start as = a big problem=2E As I said some quantitative fine tuning might be possible/= in order=2E But I do not see a qualitative change as a realistic possibilit= y=2E Yes, as a researcher in the field I might see things your way bit as t= he amateur I am, I disagree=2E But no matter the perceived magnitude of pos= sible improvements research in this field is interesting and worthwhile, I = think=2E >2=2E our paper made the point that research is needed; >3=2E now you=E2=80=99re discussing possible research ideas, which is the = step that comes after=2E True, but that is because that is what interested me on your paper, and I = am confident as an outsider unlikely to contribute actual research my opini= on on whether research is needed would be of interest to no one=2E > >=E2=80=A6 and trying to discuss 3=2E in depth easily gets hand-wavy, unle= ss one actually does the research first=2E My So all I say is that this dis= cussion is a bit pointless (I=E2=80=99m trying to end it - please! :-) ) Fair enough, thanks for the friendly and interesting discussion=2E Regards Sebastian > > >> Maybe a reason for me to respectfully bow out of this discussion as tal= k is cheap and easy to come by even without me helping=2E > >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=2E =E2=80=9CBl= ind except for RTT measurements=E2=80=9D, then=2E >>=20 >> [SM] I guess your point is "flow does not know the maximal capacity it= could have gotten"? > >Yes=2E > > >>> Importantly, such a flow never learns how large its cwnd *could* have = become without ever causing a problem=2E Perhaps 10 times more? 100 times? >>=20 >> [SM] Sure=2E ATM the only way to learn a path's capacity is actually t= o 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= =2E > >That=E2=80=99s an example of details of a possible future mechanism=2E An= d yes, I wouldn=E2=80=99t advocate this particular one=2E > > >> 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 receiv= er (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=2E Not great=2E > >We=E2=80=99re dealing with a world of heuristics here; nothing is ever 10= 0% known beforehand about Internet transfers in general=2E So, something li= ke 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 envi= sioned mechanism - and then we=E2=80=99re doing research=2E So =E2=80=9CI i= magine mechanism X, but this will never work=E2=80=9D is exactly the kind o= f discussion that's a waste of time, IMO=2E > > >>> I don=E2=80=99t even think that this name has that kind of history=2E = My point was that they=E2=80=99re called PEPs because they=E2=80=99re *mean= t* to improve performance; >>=20 >> [SM] That is not really how our economic system works=2E=2E=2E product= s are primarily intended to generate more revenue than cost, it helps if th= ey offer something to the customer, but that is really just a means to extr= act revenue=2E=2E=2E >>=20 >>=20 >>> that=E2=80=99s what they=E2=80=99re designed for=2E You describe =E2= =80=9Ca PEP that does not enhance performance=E2=80=9D, which, to me, is li= ke talking about a web server that doesn=E2=80=99t serve web pages=2E Sure,= not all PEPs may always work well, but they should - that=E2=80=99s their = raison d=E2=80=99=C3=AAtre=2E >>=20 >> [SM] That is a very optimistic view, I would love to be able to share= =2E > >This is not about optimism=2E If a device doesn=E2=80=99t improve perform= ance, it shouldn=E2=80=99t be called a PEP=2E If someone does it neverthele= ss, okay, but then that=E2=80=99s not the device we=E2=80=99re discussing h= ere=2E >I=2Ee=2E: 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=2E Th= at=E2=80=99s just weird=2E > > >>>>> There are plenty of useful things that they can do and yes, I person= ally think they=E2=80=99re the way of the future - but **not** in their cur= rent 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 r= emoved that would be great, however is that actually feasible or just desir= able? >>>>=20 >>>>> etc=2E PEPs have never been considered as part of the congestion con= trol 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 ab= out header fields, and whatnot)=2E That doesn=E2=80=99t mean that a very di= fferent kind of PEP - one which is authenticated and speaks an agreed-upon = protocol - couldn=E2=80=99t be a good solution=2E >>>>=20 >>>> [SM] Again, I agree it could in theory especially if well-architecte= d=2E=20 >>>=20 >>> That=E2=80=99s what I=E2=80=99m advocating=2E >>=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 adv= ocate it :-) but: e=2Eg=2E, for QUIC, one could extend MASQUE proxies wi= th performance-enhancing functions=2E I believe that colleagues from Ericss= on are advocating that=2E For TCP, RFC 8803 sets a very good example, IMO= =2E > > >>>> [SM] This is no invention, but how capitalism works, sorry=2E The pa= rty paying for the PEP decides on using it based on the advantages it offer= s for them=2E E=2Eg=2E a mobile carrier that (in the past) forcible managed= to downgrade the quality of streaming video over mobile links without givi= ng the paying end-user an option to use either choppy high resolution or sm= ooth low resolution video=2E By the way, that does not make the operator ev= il, it is just that operator and paying customers goals and desires are not= all that well aligned (e=2Eg=2E the operator wants to maximize revenue, th= e customer to minimize cost)=2E >>>=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 no= t 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=2E It i= s 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 supp= osed to optimize resource allocation=2E >>=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=2E > >Aha=2E No, I understand you now=2E But it *is* more subtle than that, bec= ause the market will also make unhappy customers switch to a different comp= any, except when they have no choice (monopoly)=2E > > >>> I would think that operators generally try to make their customers hap= py (or they would switch to different operators)=2E Yes there may be some = misalignments in incentives, but I believe that these are more subtle point= s=2E E=2Eg=2E, who wants a choppy high resolution video? Do such users real= ly 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 hap= py with a few seconds to compare quality of displays), given that I essenti= ally buy internet access from my mobile carrier that carrier should get out= of my way=2E (However if the carrier also offers "video-optimization" as a= n opt-in feature end-users can toggle at will that is a different kettle of= fish and something I would consider good service)=2E 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 exer= cise to minimize operational cost and not to increase customer satisfaction= =2E So yes there are "misalignments in incentives" that are inherent and st= ructural to the way we organize our society=2E (I am sort of okay living wi= th that, but I will not sugar coat it)=2E > >You say =E2=80=9Cyou=E2=80=9D might be able to buffer - but was this abou= t 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=2E I suspect that th= is would make most customers want to switch their provider=2E >So - in this way, the market does enforce a certain alignment of interest= s nevertheless=2E > > >>> Now, if we just had an in-network device that could divide the path in= to 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 sm= aller, but a certain workable range might be known to the device, because t= hat 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)=2E > > >>>> [SM] I understand, however I see clear reasons why L4S is detrimenta= l to your stated goals as it will getting more information from the network= less likely=2E I also tried to explain, why I believe that to be a theoret= ically viable way forwards to improve slow-start dynamics=2E 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=2E We could spend weeks of time and tonds o= f emails discussing explicit-feedback based schemes=E2=80=A6 instead, if y= ou think your idea is good, why not build it, test it, and evaluate its tra= de-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 re= search after hours (let alone find a journal accepting layman submissions w= ithout any relevant affiliation)=2E > >That=E2=80=99s totally fine, but then it=E2=80=99s not worth the time to = discuss the idea, frankly=2E > > >>> I don=E2=80=99t see L4S as being *detrimental* to our stated goals, BT= W - but, as it stands, I see limitations in its usefulness because TCP Prag= ue (AFAIK) only changes Congestion Avoidance, at least up to now=2E I=E2=80= =99m getting the impression that Congestion Avoidance with a greedy sender = is a rare animal=2E >>=20 >> [SM] Erm, DASH-type traffic seems quite common, no? There the individu= al 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 co= uld dig into)=E2=80=A6 but I suspect that the answer is: no, they are prob= ably not large enough to reach capacity (and "close to=E2=80=9D: who knows?= )=2E > > >Cheers, >Michael > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E