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

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 2 Dec 2020 11:11:02 +0000

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.

Mirja

From: QUIC <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Date: Wednesday, 28. October 2020 at 22:22
To: Eric Kinnear <ekinnear=[email-masked]>
Cc: Roland Zink <[email-masked]>, "[email-masked]" <[email-masked]>, Christian Huitema <[email-masked]>, Spencer Dawkins at IETF <[email-masked]>, Lucas Pardue <[email-masked]>, QUIC WG <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hey Eric,

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Dec 2020 09:41:38 -0600

On Wed, Dec 2, 2020 at 5:11 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> 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 <[email-masked]> on behalf of Ian Swett <ianswett=
> [email-masked]>
> *Date: *Wednesday, 28. October 2020 at 22:22
> *To: *Eric Kinnear <ekinnear=[email-masked]>
> *Cc: *Roland Zink <[email-masked]>, "[email-masked]" <
> [email-masked]>, Christian Huitema <[email-masked]>, Spencer
> Dawkins at IETF <[email-masked]>, Lucas Pardue <
> [email-masked]>, QUIC WG <[email-masked]>
> *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=
> [email-masked]> 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 <[email-masked]>
> wrote:
>
>
>
> Hey Eric,
>
>
>
> On Sat, Oct 24, 2020 at 2:16 AM Eric Kinnear <[email-masked]> 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.
>
> 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
>
>
>
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 2 Dec 2020 11:29:05 -0500

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 <[email-masked]>
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.
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 2 Dec 2020 11:08:03 -0600

Hi, Ian,

I'm not Mirja, of course,

> deployment experience earlier?

At least some of the presentations at the October virtual interim on QUIC
multipath were not 3GPP ATSSS-related.

I agree with Mirja's point on the difficulty of obtaining experience at
scale in a 3GPP network for an experiment, but I'm hoping there is enough
commonality between other people interested in multipath and QUIC that
SOMEONE will be able to report experiments for a proposal that would also
work for 3GPP.

That's one of the reasons I started working on
https://datatracker.ietf.org/doc/draft-dawkins-quic-what-to-do-with-multipath/
- to see what was common across people with different use cases.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 2 Dec 2020 17:37:52 +0000

Hi all,

Just a reminder that this thread, and Ian's comment that we're picking at,
predates the "Next steps for Multipath" email that Lars sent on November 20
[1].

There's levels of nuance here: a self-test experiment, interoperable
experiments in developer environments, experiments that emulate a
production-like deployment, experiments on in-situ production equipment,
and so on. Interest, ability and time in all of these levels is not
universal.

So my _personal_ take is that folks would like to establish confidence in a
multipath design, as if it were deployed in the production environment that
it is intended, before adopting it as a solution. We've seen before with
stream priorities that a rush to design a signalling mechanism, while
punting on scheduling, can result in defining something that is not
generally useful - the antithesis of standardisation. I think it's fine to
have the logical separation between signalling and scheduling but the
practical engineering reality is that they get deployed together.

Cheers
Lucas

[1] -
https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/

On Wed, Dec 2, 2020 at 5:08 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

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