Re: Preparing for discussion on what to do about the multipath extension milestone

I think that the discussion around prioritization might be showing the problem behind how we have framed the dabate. Multipath is a vague phrase, and to me it seems that people are referring to different features of it. It could be symmetric path migration, bandwidth aggregation, latency reduction

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

On Wed, Sep 30, 2020 at 2:35 PM Martin Thomson wrote: > Wasn't it of interest to the working group? I mean, a Google's interest is > relevant, but only to the extent that it contributed to the overall > interest in the feature. > Sure! I was just objecting to the existing text that overstated Go

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Wasn't it of interest to the working group? I mean, a Google's interest is relevant, but only to the extent that it contributed to the overall interest in the feature. On Thu, Oct 1, 2020, at 02:21, David Schinazi wrote: > To add to what Ian said, I really think that the following > statement fr

Re: Preparing for discussion on what to do about the multipath extension milestone

Hi, Martin, Just a couple of thoughts here: On Wed, Sep 30, 2020 at 12:16 PM Martin Duke wrote: > (Speaking as an individual) > > There is some back-and-forth as to whether these are useful cases are not. > I'll take it on faith, given the proponents, that there is a real hope of > deploying th

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Has it been considered to add a tunnel prefix header, or more generally a virtual path header to QUIC? That would avoid nested QUIC connections with dual loss control etc. in favor or a simpler virtual routing context that might re-encrypt just the actual QUIC header along the virtual path. This si

Re: Preparing for discussion on what to do about the multipath extension milestone

(Speaking as an individual) There is some back-and-forth as to whether these are useful cases are not. I'll take it on faith, given the proponents, that there is a real hope of deploying this. However, I share the desire to not have the WG fully consumed by MP-QUIC for the foreseeable future. I d

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

To add to what Ian said, I really think that the following statement from the draft reply is an overstatement: <<[multipath support for QUIC] was part of the original charter due to its inclusion in the pre-IETF "Google QUIC" protocol>>. As Ian said, the team was considering it but it never made it

Re: Preparing for discussion on what to do about the multipath extension milestone

I'm very receptive to Jana's arguments, but I think it's also worth understanding how much work we believe this will be for the QUIC WG. Many fairly complex multipath problems have already been dealt with by supporting connection migration in QUIC v1, such as path validation and linkability betwee

Re: Preparing for discussion on what to do about the multipath extension milestone

On Wed, Sep 30, 2020 at 3:52 PM Olivier Bonaventure < olivier.bonavent...@uclouvain.be> wrote: > Lucas, > > > > > Personally, I think starting on a basis of ignoring QUIC transport's > > core method of exchanging application data is a bad idea. > > I'm not suggesting that. I suggest that we first

Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas, Personally, I think starting on a basis of ignoring QUIC transport's core method of exchanging application data is a bad idea. I'm not suggesting that. I suggest that we first agree on the basic multipath mechanisms without taking too much time to discuss different and diverging app

Re: Preparing for discussion on what to do about the multipath extension milestone

On Wed, Sep 30, 2020 at 3:17 PM Olivier Bonaventure < olivier.bonavent...@uclouvain.be> wrote: > Lucas, > > > It's this special sauce that concerns me. > I don't know how I'd > objectively measure that the MP-QUIC design and all > > the implementation effort would actual result in improvement. For

Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas, It's this special sauce that concerns me. > I don't know how I'd objectively measure that the MP-QUIC design and all the implementation effort would actual result in improvement. For instance, more bandwidth via aggregation can still be misused; some types of streams will be more laten

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

Dear Magnus/QUIC and Martin/MASQUE, On Wed, Sep 30, 2020 at 6:43 AM Lars Eggert wrote: > Hi, > > On 2020-9-30, at 14:27, Flinck, Hannu (Nokia - FI/Espoo) < > hannu.fli...@nokia-bell-labs.com> wrote: > ... > > > Also the question Qn-2 in LS is not well formulated either. What they > really ask

Re: Preparing for discussion on what to do about the multipath extension milestone

Hello all, I don't want to get too deep into this, as I don't have enough experience with multipath to have a well-founded opinion. With regards to Lucas' questions on interfacing HTTP2/3 priorities with multipath TCP/QUIC, I am aware of several recent works that have looked at this problem (e.g.

Multipath inside transport (was: Re: Preparing for discussion on what to do about the multipath extension milestone)

If we're starting the discussion on Multipath, it's likely that starting new email threads would be a good idea. Beyond that ... On Wed, Sep 30, 2020 at 5:28 AM Olivier Bonaventure < olivier.bonavent...@uclouvain.be> wrote: > The main benefit of putting multipath inside the transport is that the

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

Hi, On 2020-9-30, at 14:27, Flinck, Hannu (Nokia - FI/Espoo) wrote: > It seems to me that the response to Qn-2 is a too categorial. how so? An unencrypted QUIC variant is obviously out-of-charter. > Also the question Qn-2 in LS is not well formulated either. What they really > ask is about av

RE: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Hello Lars It seems to me that the response to Qn-2 is a too categorial. Also the question Qn-2 in LS is not well formulated either. What they really ask is about avoidance of avoid multiple encryption layers that occur in QUIC in QUIC tunneling. The motivation for their question is also mentio

Re: Preparing for discussion on what to do about the multipath extension milestone

It's this special sauce that concerns me. I don't know how I'd objectively measure that the MP-QUIC design and all the implementation effort would actual result in improvement. For instance, more bandwidth via aggregation can still be misused; some types of streams will be more latency sensitive th

Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas, As an HTTP/3 implementer, I believe it to be the best example we have of a protocol that exercises the generic transport capabilities. Particularly stream multiplexing, HoL avoidance, synchronisation across independent streams, sensitivity to iwnd and cwnd, and large transfers in both

Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas, > - The complexity involved in making decisions dynamically about which > path to send a given packet on (which could be a research topic, given > certain constraints and goals). The packet scheduling problem is a much simpler problem in multipath transport

Re: Preparing for discussion on what to do about the multipath extension milestone

One of the pillars of standardization work at the IETF is running code. Aside from some proof-of-concept implementations of multipath, I'm not aware of any implementation supporting any kind of MPQUIC, let alone any internet-wide experiments / deployments. From what I've seen on the interop runner,

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Lars, Lucas and Mark, FYI, below is a draft of our intended response to the Liaison Statement "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we intend to send next week. Please feel free to send comments. Thanks, Lars, Lucas and Mark -- Thank you for the update on your

Re: Preparing for discussion on what to do about the multipath extension milestone

On Wed, 30 Sep 2020, 09:07 Olivier Bonaventure, < olivier.bonavent...@uclouvain.be> wrote: > Matt, > > > > > > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert > > > > >> wrote: > > > > > > In par

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Hi, On 2020-9-30, at 11:41, Magnus Westerlund wrote: > So I think your comment about discussion of abandoning Multi-path may have > come > as a surprise to some people. Where has that discussion occurred? it was in the context of the rechartering discussion last December. Matt linked to this

Re: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Hi Lars, So I think your comment about discussion of abandoning Multi-path may have come as a surprise to some people. Where has that discussion occurred? It wasn't on this mailing list what I can find. It doesn't like like an exstensive discussion on the QUICDEV slack either, I did find 10 mess

Re: Preparing for discussion on what to do about the multipath extension milestone

Matt, > > On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert mailto:l...@eggert.org> > >> wrote: > >     In parallel to progressing the "base drafts" towards RFC >     publications, the WG should now also begin to pick up the

RE:(2) Preparing for discussion on what to do about the multipath extension milestone

I second Pr.Olivier. Multipath Protocol gives more benefits and flexibility for Smartphones. Apart from the Aggregation (Cellular + Wi-Fi) and Reliability (Cellular <-> Wi-Fi), it can also provide much advantages (like ndiffmode). The multipath scheduling, path management(pm), and congest

Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

Hi, FYI, below is a draft of our intended response to the Liaison Statement "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we intend to send next week. Please feel free to send comments. Thanks, Lars, Lucas and Mark -- Thank you for the update on your progress and your q