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

[Lucas Pardue <[e-mail]>]

Hey Eric,

On Sat, Oct 24, 2020 at 2:16 AM Eric Kinnear <[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.

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