[Bloat] [iccrg] Musings on the future of Internet Congestion Control

[Sebastian Moeller]

Hi Michael,

On 13 July 2022 00:27:54 CEST, Michael Welzl <michawe at ifi.uio.no> wrote:
>I’ll cut some clutter:
>
>
>>> What you’re doing is jumping ahead. I suggest doing this with research rather than an email discussion, but that’s what we’re now already into.
>> 
>> 	[SM] Sure, except my day job
>(snip)
>
>that’s ok - I wasn’t trying to tell you off for discussing ideas!   - I was just trying to clarify:
>1. we agree there’s a problem;

Apparently I was not clear enough; no, I do not see current slow start as a big problem. As I said some quantitative fine tuning might be possible/in order. But I do not see a qualitative change as a realistic possibility. Yes, as a researcher in the field I might see things your way bit as the amateur I am, I disagree. But no matter the perceived magnitude of possible improvements research in this field is interesting and worthwhile, I think.


>2. our paper made the point that research is needed;
>3. now you’re discussing possible research ideas, which is the step that comes after.

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 opinion on whether research is needed would be of interest to no one.


>
>… 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’m trying to end it - please!  :-)  )

Fair enough, thanks for the friendly and interesting discussion.

Regards
        Sebastian


>
>
>> 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’s at least try to keep this short…
>
>
>>> Okay, there is ONE thing that such a flow gets: the RTT. “Blind except for RTT measurements”, then.
>> 
>> 	[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?
>> 
>> 	[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’s an example of details of a possible future mechanism. And yes, I wouldn’t 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?
>> 
>> 
>> *) 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’re 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’re doing research. So “I imagine mechanism X, but this will never work” is exactly the kind of discussion that's a waste of time, IMO.
>
>
>>> I don’t even think that this name has that kind of history. My point was that they’re called PEPs because they’re *meant* to improve performance;
>> 
>> 	[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...
>> 
>> 
>>> that’s what they’re designed for. You describe “a PEP that does not enhance performance”, which, to me, is like talking about a web server that doesn’t serve web pages. Sure, not all PEPs may always work well, but they should - that’s their raison d’être.
>> 
>> 	[SM] That is a very optimistic view, I would love to be able to share.
>
>This is not about optimism. If a device doesn’t improve performance, it shouldn’t be called a PEP. If someone does it nevertheless, okay, but then that’s not the device we’re discussing here.
>I.e.: I say “but we’re discussing a web server, not a DNS server” and you say “this is optimistic”. That’s just weird.
>
>
>>>>> There are plenty of useful things that they can do and yes, I personally think they’re the way of the future - but **not** in their current form, where they must “lie” to TCP, cause ossification,
>>>> 
>>>> 	[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?
>>>> 
>>>>> 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’t mean that a very different kind of PEP - one which is authenticated and speaks an agreed-upon protocol - couldn’t be a good solution.
>>>> 
>>>> 	[SM] Again, I agree it could in theory especially if well-architected. 
>>> 
>>> That’s what I’m advocating.
>> 
>> 	[SM] Well, can you give an example of an existing well-architected PEP as proof of principle?
>
>It doesn’t really exist yet - else I wouldn’t 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).
>>> 
>>> You claim that these goals and desires are not well aligned (and a PEP is then an instrument in this evil)
>> 
>> 	[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.
>> 
>>> - do you have any proof, or even anecdotes, to support that claim?
>> 
>> 	[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?
>> 
>> 	[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 “you” might be able to buffer - but was this about a specific application?
>Anyway, let’s 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 “core” segment where it’s 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…
>> 
>> 	[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?
>>> 
>>> I’d say the latter. We could spend weeks of time and tonds of emails discussing explicit-feedback based schemes…  instead, if you think your idea is good, why not build it, test it, and evaluate its trade-offs?
>> 
>> 	[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’s totally fine, but then it’s not worth the time to discuss the idea, frankly.
>
>
>>> I don’t 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’m getting the impression that Congestion Avoidance with a greedy sender is a rare animal.
>> 
>> 	[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’t have enough data (though there are some papers we could dig into)…  but I suspect that the answer is: no, they are probably not large enough to reach capacity (and "close to”: who knows?).
>
>
>Cheers,
>Michael
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.