Re: "Proxying" multipath usecases and application scheduling

[David Schinazi <[e-mail]>]

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
>
>