Subject: Multipath Milestones

From: Lucas Pardue <[email-masked]>
Date: Wed, 14 Feb 2018 14:49:39 +0000

Hi,

For fear of kicking a hornet's nest...

This might be a bit pedantic but when the milestones were adjusted back in December, the Multipath extension milestones were left as originally stated (Nov '17, May '19).

Is there any intention to modify these? The Nov '17 adoption has obviously been missed and I'm wondering what I would tell someone less familiar with the WG when they hypothetically asks me what that means.

Kind regards
Lucas

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Feb 2018 19:14:17 +0000

Hi,

On 2018-2-14, at 15:49, Lucas Pardue <[email-masked]> wrote:
> This might be a bit pedantic but when the milestones were adjusted back in December, the Multipath extension milestones were left as originally stated (Nov ’17, May ’19).
> 
> Is there any intention to modify these? The Nov ’17 adoption has obviously been missed and I’m wondering what I would tell someone less familiar with the WG when they hypothetically asks me what that means.

yes, we need to update those milestones.

I can't recall that we explicitly discussed this when we discussed pushing the base-drafts milestones back. But to me personally, the decision to focus all efforts on v1 - and multipath not being part of v1 - implicitly meant that we'd not really start any real effort before the base-drafts are shipped off to the IESG. In other words, WG adoption would probably not happen before Nov 2018, and completion sometime in 2019 (?).

As I said, this is my personal interpretation - it would be good to know if this is the WG consensus.

Lars

---

From: Ian Swett <[email-masked]>
Date: Wed, 14 Feb 2018 14:22:06 -0500

Lars, that was my interpretation as well.

I think the right path forward is for those particularly interested in
multipath to experiment with QUIC extensions inside v1, once the extension
mechanism is defined.  Once some experimentation has happened, we'll be in
a better place to have an informed discussion about some of the points
Christian raised in his multipath requirements draft:
https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01

The recent text being added about Connection Migration should lay some of
the groundwork for adding second paths. https://github.com/
quicwg/base-drafts/pull/1012

On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars <[email-masked]> wrote:

> This might be a bit pedantic but when the milestones were adjusted back in
> December, the Multipath extension milestones were left as originally stated
> (Nov ’17, May ’19).
>
> Is there any intention to modify these? The Nov ’17 adoption has obviously
> been missed and I’m wondering what I would tell someone less familiar with
> the WG when they hypothetically asks me what that means.
>
>
> I can't recall that we explicitly discussed this when we discussed pushing
> the base-drafts milestones back. But to me personally, the decision to
> focus all efforts on v1 - and multipath not being part of v1 - implicitly
> meant that we'd not really start any real effort before the base-drafts are
> shipped off to the IESG. In other words, WG adoption would probably not
> happen before Nov 2018, and completion sometime in 2019 (?).
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 14 Feb 2018 13:33:17 -0800

I agree with Lars and Ian, and I presume this was left out inadvertently.

Lars: maybe the chairs could come up with a "fix" to the milestones and do
a consensus call?

On Wed, Feb 14, 2018 at 11:22 AM, Ian Swett <[email-masked]> wrote:

> the groundwork for adding second paths. https://github.com/quic
> wg/base-drafts/pull/1012
>
>> This might be a bit pedantic but when the milestones were adjusted back
>> in December, the Multipath extension milestones were left as originally
>> stated (Nov ’17, May ’19).
>>
>> Is there any intention to modify these? The Nov ’17 adoption has
>> obviously been missed and I’m wondering what I would tell someone less
>> familiar with the WG when they hypothetically asks me what that means.
>>
>>
>> I can't recall that we explicitly discussed this when we discussed
>> pushing the base-drafts milestones back. But to me personally, the decision
>> to focus all efforts on v1 - and multipath not being part of v1 -
>> implicitly meant that we'd not really start any real effort before the
>> base-drafts are shipped off to the IESG. In other words, WG adoption would
>> probably not happen before Nov 2018, and completion sometime in 2019 (?).
>>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 14 Feb 2018 21:42:41 +0000

Yes I think Ian summarised things well.

>From my own perspective, changing milestone dates to <TBD>, <suspended until further notice> etc would give a more honest reflection of current status. Not sure if the datatracker allows such a thing.

Regards
Lucas
________________________________________
From: Jana Iyengar [[email-masked]]
Sent: 14 February 2018 21:33
To: Ian Swett
Cc: Eggert, Lars; Lucas Pardue; QUIC WG
Subject: Re: Multipath Milestones

Lars: maybe the chairs could come up with a "fix" to the milestones and do a consensus call?

On Wed, Feb 14, 2018 at 11:22 AM, Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
Lars, that was my interpretation as well.

I think the right path forward is for those particularly interested in multipath to experiment with QUIC extensions inside v1, once the extension mechanism is defined.  Once some experimentation has happened, we'll be in a better place to have an informed discussion about some of the points Christian raised in his multipath requirements draft: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01

The recent text being added about Connection Migration should lay some of the groundwork for adding second paths. https://github.com/quicwg/base-drafts/pull/1012

On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On 2018-2-14, at 15:49, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
This might be a bit pedantic but when the milestones were adjusted back in December, the Multipath extension milestones were left as originally stated (Nov ’17, May ’19).

Lars

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 15 Feb 2018 08:08:42 +0000

> From my own perspective, changing milestone dates to <TBD>, <suspended until further notice> etc would give a more honest reflection of current status. Not sure if the datatracker allows such a thi…

Unfortunately, it doesn't. It needs a date, I can delete a milestone, or mark as completed.

My suggestion would be to move the "adoption" milestone to Nov 2018, and the completion milestone to July 2019. Do people think we can ship v2 by then?

Lars

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 15 Feb 2018 16:44:09 -0800

Depends on what v2 is. I'd like to ship some v2 by then, but that may not
include multipath... that's a conversation we need to have with more
details about strategy and so on. This is perhaps a can of worms to open in
London?

As I remember it, multipath was on the charter because we wanted to signal
that we were going to work on it, just not yet. If we are agreed on doing
it after v1, I wonder if it makes most sense now to simply remove it from
the charter and re-litigate it when we create a charter for post-v1 work.

On Thu, Feb 15, 2018 at 12:08 AM, Eggert, Lars <[email-masked]> wrote:

> From my own perspective, changing milestone dates to <TBD>, <suspended
> until further notice> etc would give a more honest reflection of current
> status. Not sure if the datatracker allows such a thing.
>
>
> My suggestion would be to move the "adoption" milestone to Nov 2018, and
> the completion milestone to July 2019. Do people think we can ship v2 by
> then?
>
> Lars
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 11:50:25 +1100

I don't have a lot of interest in spending too much time on procedural
issues.  An unrealistic milestone is only a problem if you think that
it is.  I'm more interested in executing on the plan (shipping).

Let's talk about v2 when it is time to work on v2.  I'm aware that
this might be very soon after v1, but I think that talking v2 in
London might be a little premature.

On Fri, Feb 16, 2018 at 11:44 AM, Jana Iyengar <[email-masked]> wrote:
> include multipath... that's a conversation we need to have with more details
> about strategy and so on. This is perhaps a can of worms to open in London?
>
> that we were going to work on it, just not yet. If we are agreed on doing it
> after v1, I wonder if it makes most sense now to simply remove it from the
> charter and re-litigate it when we create a charter for post-v1 work.
>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 15 Feb 2018 16:53:13 -0800

I agree with all that, except multipath is > v1, and it is on the list of
milestones. I'd be in favor of removing it entirely from the list of
milestones.

On Thu, Feb 15, 2018 at 4:50 PM, Martin Thomson <[email-masked]>
wrote:

> details

---

From: Quentin De Coninck <[email-masked]>
Date: Fri, 16 Feb 2018 14:10:58 +0100

Hello,

Le 14/02/18 à 20:22, Ian Swett a écrit :
> multipath to experiment with QUIC extensions inside v1, once the 
> extension mechanism is defined.  Once some experimentation has 
> happened, we'll be in a better place to have an informed discussion 
> about some of the points Christian raised in his multipath 
> requirements draft: 
> <https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01>

I totally agree that experimenting is key. That's why we implemented the 
multipath extensions that we proposed last year in 
https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/

This document has evolved and we'll release a new version before the 
London IETF to take into account various comments received. In parallel 
with that, we are finalizing an iOS application that uses multipath QUIC 
to evaluate how this works in the wild. This application will perform 
various measurements to analyze the benefits of multipath. If you have 
ideas, feel free to contact me offline. If there is interest, I might be 
able to report some results with multipath QUIC in the wild at the 
London IETF.

Quentin

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 16 Feb 2018 13:30:15 +0000

I briefly skimmed the multi path proposal and one thing that comes to mind
is the limit of 256 paths.
I think there could be much more than 256 paths and that path ID’s could be
varint encoded. A single address could have multiple paths over time, key
migration could be tied to paths, although two paths may still share a key.
Path swapping could potentially be used to protect against optimistic ACK
attack. I wrote an issue on segmented packet numbers:
https://github.com/quicwg/base-drafts/issues/1105 here the objective is to
avoid the packet number encryption and to provide simpler per path loss
management, but it overlaps with multi-path. I wonder how much the current
design actually needs to change in order to support multi-path if using
segmented packet numbers. There is already PATH_CHALLENGE.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 16 February 2018 at 14.11.17, Quentin De Coninck (
[email-masked]) wrote:

Hello,

This document has evolved and we'll release a new version before the London
IETF to take into account various comments received. In parallel with that,
we are finalizing an iOS application that uses multipath QUIC to evaluate
how this works in the wild. This application will perform various
measurements to analyze the benefits of multipath. If you have ideas, feel
free to contact me offline. If there is interest, I might be able to report
some results with multipath QUIC in the wild at the London IETF.

Quentin