Re: "Proxying" multipath usecases and application scheduling

[Gorry Fairhurst <[e-mail]>]

So...

I've added something at the end, to note agree on the priority...

On 24/01/2022 23:34, David Schinazi wrote:
> This thread dates back to 15 months ago, I'm not entirely sure why Gorry
> resurrected it without adding any text, but perhaps my email client is 
> confused.
>
> Without going into the vices and virtues of content inspection, let's 
> not increase
> the scope of many working groups too soon. The MASQUE WG already has its
> plate pretty full getting proxying to work, so let's not add multipath 
> into the mix
> until we have proxying working. Similarly, the QUIC WG is going to be 
> solving
> the already hard problem of end-to-end multipath without adding 
> proxying to
> complicate things. If folks want to work on multipath proxying, I 
> strongly suggest
> waiting for both multipath and proxying to exist before trying to 
> combine them.
>
> David, MASQUE and QUIC enthusiast
>
> On Mon, Jan 24, 2022 at 12:34 PM Paul Vixie 
> <paul=[e-mail]> wrote:
>
>
>
>     Christian Huitema wrote on 2022-01-24 12:15:
>     > ...
>     >
>     > Like others, I have mixed feelings about the kind of proxying
>     proposed
>     > in the 5G design. It does look like a power grab by the telecom
>     > companies, force all user traffic through a telco managed proxy,
>     getting
>     > an observation point to see all the user traffic, do all the
>     kind of
>     > "statistics" we could expect in these days of surveillance
>     capitalism,
>     > and be in a position to control how much bandwidth is allocated to
>     > specific content providers.
>
>     i think calling it a power grab when it's done by an internet transit
>     connectivity provider (such as "the telecom companies") makes
>     sense, but
>     that without clarification, could connote untenable meanings.
>
>     managed private networks, such as enterprise, government, university,
>     small office / home office, and home / family networks, already
>     have the
>     power you describe, and will preserve the status quo at "whatever
>     cost"
>     the ietf may impose.
>
>     i pray that we will consistently disambiguate. there will be no wide
>     area UDP on most managed private networks. we can either pressure
>     these
>     networks with endpoint failures (to strong arm them into abandoning
>     their historic powers), or we can rely on fallback (which for new
>     protocols may be more fragile than for the existing WWW), or we can
>     negotiate, in ways approximately alike to the "proxying proposed
>     in the
>     5G design". those are our choices -- there is no fourth way.
>
>     if the ietf wishes to disintermediate on-path actors, then we
>     ought to
>     consistently and carefully identify where the power is (managed
>     private
>     edge networks, and endpoints), and avoid antagonizing those power
>     holders.
>
>     > The only good effect is that proxying will
>     > hide the actual user location from the content providers, which
>     removes
>     > a bit of data from the surveillance capitalism dragnet. But
>     overall,
>     > that's not great, and I would rather not have a feature like
>     that on my
>     > phone. But hey, that's my opinion, people may differ. And I wonder
>     > whether that has much relevance to IETF work.
>
>     if the ietf's mission is to impose societal change, then explicit
>     negotiated proxy service may not be relevant. however if the ietf's
>     mission is to create technology that supports generally desirable
>     work
>     flows, then proxy discovery/negotiation is vitally relevant to that.
>
>     several networks i operate and many that i'm aware of will have to do
>     content inspection. there will be no free lunch for IoT (which is an
>     instance of "surveillance capitalism dragnet"). the ietf has to
>     decide
>     whether to oppose, or ignore, or cooperate with that reality.
>
>     -- 
>     P Vixie
>
I really wanted to be sure the QUIC WG didn't forget that there are 
other use-cases for the MASQUE work.  When I paused to think about what 
to ask in my email, my email client "helpfully" just "sent" my pending 
email.... actually on this occasion that wasn't such a bad thing as it 
turns out, because it generated some responses!

Other people have now mentioned enterprise networks; 5G (using a variety 
of sub-IP technologies) and IoT, there are probably more. I expect the 
future to not be as simple as a transfer of power/trust from operators 
to content providers for all uses of QUIC. Really, this has potential to 
help with QUIC performance for some specific deployment scenarios - if 
the IETF chooses "ignore these use cases" or "design to prevent these 
use cases" - then my guess is that this will not stop those who operate 
networks from doing things, things that might be worse - the example of 
NAT seems a relevant previous use of IETF thinking that if we ignore, it 
will disappear.

And I agee with David: the plan to first do MASQUE (for the clear use 
case accepted by the group); and also to better understand "end to end" 
multipath do seem like a good step in the correct direction. That's all.

Gorry