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

[Eric Kinnear <[e-mail]>]

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

Thanks,
Eric

> On Oct 23, 2020, at 4:02 PM, Lucas Pardue <[e-mail]> wrote:
> 
> Maybe I just lack imagination but this is the part of the "put it in transport and everyone gets it for free" line that I've not understood. 

> 
> For example, Cloudflare's quiche implementation of QUIC is I/O agnostic, you put application data in, it gives you QUIC packets back and you do with them what you like. This flexibility means it's portable to lots of platforms and applications. It's been able to slide into curl and nginx implementations without a need to re-architect. More people using the library means more diverse use cases and better coverage of protocol features.
> 
> I don't know what a TAPS-quiche integration would look like or provide. From looking at https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-7.1.7 <https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-7.1.7> a lot of the decisions are "implementation specific". I'd hazard a guess that each implementation would make its own decisions and want to expose different things to the application. And even if *it* didn't expose network information, it would need access. So either it sits in the application and uses a platform API that could've been used all along, or it gets compiled into the platform and now we lose agility. 
> 
> Cheers
> Lucas