Hi Michael,
On 13 July 2022 00:27:54 CEST, Michael Welzl <[email protected]> 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.
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
