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

[Ian Swett <[e-mail]>]

Thanks Mirja, that deployment setup sounds like it could make it difficult
to get deployment experience prior to publishing an RFC?  Given the
complexity of multipath, shipping an RFC without deployment experience
seems unappealing to me, but maybe there is an opportunity to get some
deployment experience earlier?

On Wed, Dec 2, 2020 at 10:41 AM Behcet Sarikaya <[e-mail]>
wrote:

>
>
> On Wed, Dec 2, 2020 at 5:11 AM Mirja Kuehlewind <mirja.kuehlewind=
> [e-mail]> wrote:
>
>> 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.
>>
>>
>>
>
> +1
>
> Behcet
>
>> 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]> 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]>
>> wrote:
>>
>>
>>
>> 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.
>>
>> 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
>>
>>
>>
>>