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

[Behcet Sarikaya <[e-mail]>]

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