Re: "Proxying" multipath usecases and application scheduling

[Christian Huitema <[e-mail]>]

I have a very hard time understanding who is saying what in this thread. 
The replies come from different agents using different conventions, and 
the result is a bit of a mess. I went back to the mail archive 
(https://mailarchive.ietf.org/arch/browse/quic/) to try to understand 
who said what, but I am still not sure. Anyhow, that will notstop me 
from adding my two cents...

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

For the QUIC WG, we have two relevant works in progress: Masque, and 
multipath. It is pretty clear that if both are defined, then they can be 
combined to deliver something like the 5G proxying service. It is also 
pretty clear that multipath has use cases that do not involve Masque, 
and that availability of QUIC multipath diminishes the need to use 
proxies in order to benefit from multiple paths. I would very much like 
to focus on these "end to end" use cases for now, and only worry about 
combining Masque and multipath once Masque is done.

-- Christian Huitema