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

[Eric Kinnear <[e-mail]>]

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