Re: Privacy considerations of multipath (Re: My BoF report: multipath)

[Mirja Kuehlewind <[e-mail]>]

Hi Ian,

one comment about using multipath QUIC in production and 3GPP: The scenario in 3GPP has different players who need to implement this, the MNO with the ATSSS function in the UPF and the UE on the other end. Therefore it is not possible to just deploy something and try it out as Google often does, without having a spec that is stable enough that these two systems can interoperate. I’d say that is what we have standardization for.  3GPP needs to refer something in their specs and that will then get implemented and probably stay like that for a long time. We spend a lot of time to tell 3GPP that it is not wise to refer individual drafts and I also don’t think that we want 3GPP to standardize their own multipath QUIC spec. Luckily 3GPP is not planning to do that, but I think we should try to help them as much as we can, whatever that means.

Mirja


From: QUIC <[e-mail]> on behalf of Ian Swett <ianswett=[e-mail]>
Date: Wednesday, 28. October 2020 at 22:22
To: Eric Kinnear <ekinnear=[e-mail]>
Cc: Roland Zink <[e-mail]>, "[e-mail]" <[e-mail]>, Christian Huitema <[e-mail]>, Spencer Dawkins at IETF <[e-mail]>, Lucas Pardue <[e-mail]>, QUIC WG <[e-mail]>
Subject: Re: Privacy considerations of multipath (Re: My BoF report: multipath)

Based on what I've heard, I think there might be enough people to work on this, but it may not be the people most involved in QUIC v1.  If Eric and the 3GPP could agree on a common(minimal) feature set and design they'd like to deploy, that would make me more interested in accepting this into the working group.  At this point, I think we're a ways from that.

In terms of the 3GPP liason request, if this is time sensitive, I'd suggest publishing your own draft and once you have some deployment experience, come back.  From personal experience, the IETF is not in the business of preventing people from widely deploying experimental technologies.  I would love to see people using QUIC multipath in production, and I do believe there are use cases that would benefit.

Ian

On Wed, Oct 28, 2020 at 3:21 PM Eric Kinnear <ekinnear=[e-mail]<mailto:[e-mail]>> wrote:
Thanks Lucas! Totally agree with what you’re saying here, was just noting that there we’re broadening the scope of implementation/experimentation possibility from “kernel vendors” to “platform/service vendors/someone who really wants to put a lot of work into a single application” — this is really really great, especially for many participants in the QUIC WG and the IETF, and as you say there’s still going to be a lot of folks depending on participants in the WG/platform/service vendors to supply APIs and configuration options to exercise much of this functionality.

I think one of the things that we’re coming to realize as we discuss multipath is that many of the considerations around the different options we could choose depend on external factors (like $$$ and policies of different industry players) more than the actual technology that’s under discussion. If we think those things will be solved (and probably not by the IETF), then great!

From a technology standpoint, we’ve opened up some really awesome possibilities with QUIC in the realm of being able to move forwards more rapidly with deployment, as you noted, and I think on that front I’d be totally interested in defining a multipath extension for folks to go deploy, collect data, and then present the delta between those benefits for an end-user vs. connection migration. We can decide on how far down the standards process we’d want that to go, one could argue that we’re already at that point with the various I-Ds that are present.

Thanks,
Eric



On Oct 23, 2020, at 7:35 PM, Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:

Hey Eric,

On Sat, Oct 24, 2020 at 2:16 AM Eric Kinnear <[e-mail]<mailto:[e-mail]>> wrote:
I generally agree with some of the thinking here, but I can definitely see a case where “everyone gets it for free” is a thing.
For example, one could imagine that Cloudflare might use quiche to allow its customers to enable HTTP/3 “for free” via a checkbox in their configuration, or even just enable it on their websites.

That’s not necessarily fully in sync with what the “QUIC is in userspace and therefore everyone should bring their own implementation that they can change at will” thinking is going towards, but I do expect there are quite a few folks creating end-user-facing software who don’t know that much about networking and are more interested in “hit this REST endpoint” than “tune my congestion control for the specific quirks of my traffic content that are unique to me and only me”.

I’m not saying anything against that type of tuning, that’s often how we can push the boundaries and really move things forward.
I also think QUIC is in a really good place to enable a lot of awesome experimentation in that area.

But I do think we can acknowledge that there are folks (even if I personally might tend towards the “let’s experiment and push the boundaries” side of things) who have a very legitimate desire to abstract that away underneath something that generally does a “pretty good” job of handling it. If that's better than what exists today in terms of end-user visible benefits, even if not 100% optimally tuned for their specific traffic patterns, that seems like a good start.

There’s definitely a balance to strike between ultimate experimentation and moving meaningful numbers of people forward who either don’t have time or aren’t interested in that experimentation. Where are the cases where it’s most useful, leads to the most end-user benefit, or enables things not previously possible? Those seem like the things to focus on not abstracting away — is multipath in QUIC one of those? (I genuinely don’t have an answer to that.)

To clarify a little. The point I was trying to make is that just adding some support for $multipath frames$ parsing to something like quiche would not be a complete solution. Something would still have to glue it to a network. And I'm not sure if there's a consistent network API across platforms that exposes path information required for something like that to work. So the application has a lot of work to do to. If they have to build to the nuances of every platform API, firmware or middleware, that's more than just free. To build on Christian's earlier point, many projects have picked their own way to do things, for good or bad.
Absolutely! I do think it would be really nice to have a common set of ways to represent much of this functionality (even just connect-by-name is nice, long before you get to multipath).


The QUIC WG has benefited from its ability to openly and agily interoperate. Many implementations are there for people to just pick up and start running with. I'm not steadfast in belief that everyone has to use a user-space library and bundle up everything. There's absolutely a value in making technology accessible to folks that just want to get on with business via simpler or stabler means. And both these worlds can exist (and most definately should interoperate!). But I think it's prescient to consider the accessibility of new transport features to different parts of the community.

Cheers
Lucas