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