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
<[email protected]> 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
