Subject: QUIC - Our schedule and scope

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Oct 2017 17:26:58 +1100

Working Group Participants,

Since the Working Group is now approximately one year old, it's a good time to step back and consider how well our work is proceeding.

As chairs, we've been concerned about successfully delivering QUIC since we started this effort. Introducing what is effectively a new transport protocol for the Internet that incorporates not only reliability, congestion control and multiplexing, but also encryption and key exchange, 0RTT handshakes, and what is effectively yet another version of HTTP is a tall order, especially when we started without broad implementation or deployment experience beyond a single vendor.

The nature of our discussions has also caused us some concern, since we seem to range over a variety of topics that are difficult to pin down, thanks to the interdependencies between them. We've explicitly given the editors license to make bold changes in this start-up period as a way to move forward, but even with that, we've struggled to manage our workload -- currently at 170 open issues, with every sign of growing.

Our charter instructs us to deliver the "core" four documents in March 2018, five months away. Many in the Working Group have viewed that milestone as aspirational, but it's becoming clear that on our current course, we'll be lucky to deliver QUIC in 2019.

In our considered view that is unacceptable, because it requires a commitment (in time and effort) that many implementers and engineers will be unwilling to make -- thus impacting the quality of participation we see, and therefore the quality (and success) of QUIC.

To address this, we think two things are necessary:

1) Our Milestone for delivering the "core" QUIC documents (plus applicability and manageability statements) to the IESG should be moved to December 2018, with the understanding that this is a deadline we intend to meet.

2) V1 of QUIC should *only* address the use case of HTTP.

This has a few implications:

* Proposals for changes that are not realistically achievable in the timeline of #1 will be rejected on that basis, because the WG has consensus that the schedule is important.

* V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond.

* Discussion of anything else (including issues, drafts, proposals) that doesn't address the needs of HTTP-over-QUIC will be postponed until after V1 has shipped. 

It's important to understand that this approach is predicated on the notion that QUIC is not the one chance that we have to evolve transport protocols; rather, it represents the start of an evolution, to be followed by any number of new versions that are enabled by assuring that the extensibility and versioning mechanisms are appropriately "greased" (i.e., we take measures to assure that they are available in the future; in other words, counter-ossification).

Please discuss on-list; we'll also be covering this in Singapore, and will call for consensus after gathering further input there.

Regards,

- Your Chairs, Lars Eggert and Mark Nottingham

---

From: Ian Swett <[email-masked]>
Date: Fri, 27 Oct 2017 09:49:43 -0400

I think pushing back the date for the core documents to December 2018 and
focusing on finishing HTTP-over-QUIC is the right choice for all the
reasons you outline above.

On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <[email-masked]> wrote:

> Since the Working Group is now approximately one year old, it's a good
> time to step back and consider how well our work is proceeding.
>
> As chairs, we've been concerned about successfully delivering QUIC since
> we started this effort. Introducing what is effectively a new transport
> protocol for the Internet that incorporates not only reliability,
> congestion control and multiplexing, but also encryption and key exchange,
> 0RTT handshakes, and what is effectively yet another version of HTTP is a
> tall order, especially when we started without broad implementation or
> deployment experience beyond a single vendor.
>
> The nature of our discussions has also caused us some concern, since we
> seem to range over a variety of topics that are difficult to pin down,
> thanks to the interdependencies between them. We've explicitly given the
> editors license to make bold changes in this start-up period as a way to
> move forward, but even with that, we've struggled to manage our workload --
> currently at 170 open issues, with every sign of growing.
>
> Our charter instructs us to deliver the "core" four documents in March
> 2018, five months away. Many in the Working Group have viewed that
> milestone as aspirational, but it's becoming clear that on our current
> course, we'll be lucky to deliver QUIC in 2019.
>
> In our considered view that is unacceptable, because it requires a
> commitment (in time and effort) that many implementers and engineers will
> be unwilling to make -- thus impacting the quality of participation we see,
> and therefore the quality (and success) of QUIC.
>
> 1) Our Milestone for delivering the "core" QUIC documents (plus
> applicability and manageability statements) to the IESG should be moved to
> December 2018, with the understanding that this is a deadline we intend to
> meet.
>
> * Proposals for changes that are not realistically achievable in the
> timeline of #1 will be rejected on that basis, because the WG has consensus
> that the schedule is important.
>
> * V1 will need to document the "invariants" of QUIC -- i.e., the parts on
> the wire that will not change -- to allow other use cases to be addressed
> by V2 and beyond.
>
> * Discussion of anything else (including issues, drafts, proposals) that
> doesn't address the needs of HTTP-over-QUIC will be postponed until after
> V1 has shipped.
>
> It's important to understand that this approach is predicated on the
> notion that QUIC is not the one chance that we have to evolve transport
> protocols; rather, it represents the start of an evolution, to be followed
> by any number of new versions that are enabled by assuring that the
> extensibility and versioning mechanisms are appropriately "greased" (i.e.,
> we take measures to assure that they are available in the future; in other
> words, counter-ossification).
>
> Please discuss on-list; we'll also be covering this in Singapore, and will
> call for consensus after gathering further input there.
>
> Regards,
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Oct 2017 11:13:42 -0400

Hi All,

First, the observation that elapsed time impacts participation and
participation impacts quality is a good observation. Finishing faster (I
personally want to go way way faster) is consistent with that and we should
look at how we're organized to help make that a reality. Thanks for doing
that.

I'm also not quite as pessimistic as the chairs are. I don't really think
this is a linear process - as we get more input from more implementations I
think the process will naturally accelerate. The challenge at that later
stage will be on not re-opening issues that we have reached consensus on.
That's different than the challenge we've been going through for the last
year; for the last year we've been building up the basic blocks from an
explicitly 0-consensus starting point. Its both not surprising, and a good
thing, that many issues have been given scrutiny during that phase.

> To address this, we think two things are necessary:
Just for clarification, you're suggesting these 2 bullets as updates in
some form to the wg charter?

> that the schedule is important.
This needs to be severely unpacked and I do not support it in the way I'm
interpreting it.

I think the only way we're going to finish quickly and still create a good
product is if all the participants are focused on getting to yes. A shot
clock process fix isn't going to get a high quality result - we need an
attitude fix :)

The current charter says "Note that consensus is required both for changes
to the current protocol mechanisms and retention of current mechanisms. In
particular, because something is in the initial document set does not imply
that there is consensus  around the feature or around how it is specified."
This remains an important property for the evolution of IETF QUIC. We need
to work through all the details as a working group.. I think we can do it
faster, but not by inventing an arbitrary forcing function.

A firm timebox severely undermines the consensus process via simple
gamificiation to 'run out the clock' in favor of existing text. That is not
in the interest of the end result or getting consensus in a
multi-stakeholder process. Indeed it probably increases the chances for a
disastrous last call period. However, getting to yes is in everybody's
interest. That's a much better motivator.

I think a better path would be for the chairs to more aggressively declare
rough consensus at an earlier stage of discussion than is typically done.
I'm not suggesting a different threshold of consensus, just less indulgence
in letting issues play all the way out in hopes of convergence. Perhaps
also an appeal to all WG members to consider the implications of expressing
an opinion on a topic .. Every issue does not need to be a poll for
everyone's opinion.. save it for places where your opinion makes a material
difference to you. (i.e. acknowledge that two people will disagree on what
is a bikeshed vs what is meaningful and stay out of it in the name of
progress if you are on the bikeshed side).

I have no objection to updating the milestone delivery date to something
more reasonable, but I do think elevating schedule to be a higher order
concern than consensus on the RFC content is wrong.

I think your second suggestion, scoping around HTTP for v1, is more likely
to get us to a successful finish. As we get later in this process, it will
be more important.

> doesn't address the needs of HTTP-over-QUIC will be postponed until after
Browsing through the archives I actually don't see very many issues that
are totally non-http (certainly < 10%). But there probably are quite a few
that are simpler to resolve if only http is taken into account.

-P

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Oct 2017 16:20:15 +0000

You might also want to consider what TLS 1.3 is going through and allow an escape hatch if you’ve got a good protocol but current Internet conditions prevent it from getting acceptably-wide deployment.  And then, the follow-on question: what *would* be an acceptable level of interference/blockage – 1, 5, 10%?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Oct 2017 16:23:58 +0000

*   I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong.

I very strongly agree with this!

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 09:25:37 -0700

On Fri, Oct 27, 2017 at 9:20 AM, Salz, Rich <[email-masked]> wrote:

> You might also want to consider what TLS 1.3 is going through and allow an
> escape hatch if you’ve got a good protocol but current Internet conditions
> prevent it from getting acceptably-wide deployment.  And then, the
> follow-on question: what **would** be an acceptable level of
> interference/blockage – 1, 5, 10%?
>

Well, we already know there's going to be a fair amount of blockage because
lots of firewalls block UDP entirely. Estimates vary, but generally what
I've seen is on the order of low single digit %ages. Any deployment of QUIC
is going to need some way to fall back to TLS over TCP. So, it's kind of a
cost benefit calculation of are you getting enough QUIC penetration to make
it worth it. The public experience with WebRTC suggests that the answer
will be yes, though...

-Ekr

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 27 Oct 2017 16:36:51 +0000

Hi Mark,

> Our charter instructs us to deliver the "core" four documents in March 2018,
> five months away.
<snip>
> 1) Our Milestone for delivering the "core" QUIC documents (plus applicability
> and manageability statements) to the IESG should be moved to December
> 2018, with the understanding that this is a deadline we intend to meet.
>
> * Proposals for changes that are not realistically achievable in the timeline of
> #1 will be rejected on that basis, because the WG has consensus that the
> schedule is important.
>
> * V1 will need to document the "invariants" of QUIC -- i.e., the parts on the
> wire that will not change -- to allow other use cases to be addressed by V2
> and beyond.
>
> * Discussion of anything else (including issues, drafts, proposals) that doesn't
> address the needs of HTTP-over-QUIC will be postponed until after V1 has
> shipped.
>

To date, I've tried to avoid mentioning Multipath on list and bring it up now only as it relates to the WG Charter Milestones.

Can you be more explicit on how your proposals affect the current Multipath extension document dates? I could infer that the proposed changes to the core docs are independent of the extension doc, or more realistically the rescheduling also punts Multipath off another ~6 months (minimum) or until QUIC V2. What is more aligned with your current thinking?

Kind regards
Lucas

-----------------------------
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: Fri, 27 Oct 2017 18:30:04 +0000

Hi,

On 2017-10-27, at 17:13, Patrick McManus <[email-masked]> wrote:
> On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Just for clarification, you're suggesting these 2 bullets as updates in some form to the wg charter?
> 

I haven't synced with Mark on this, but my personal view is that neither of these affect the charter text. (1) changes the date of our milestones. (2) is - in my view at least - already what the charter expresses: it doesn't talk about applications other than HTTP as something that work is occurring on.

> This needs to be severely unpacked and I do not support it in the way I'm interpreting it.
> 
> I think the only way we're going to finish quickly and still create a good product is if all the participants are focused on getting to yes. A shot clock process fix isn't going to get a high quality result - we need an attitude fix :)

Agreed.

> The current charter says "Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus  around the feature or around how it is specified." This remains an important property for the evolution of IETF QUIC. We need to work through all the details as a working group.. I think we can do it faster, but not by inventing an arbitrary forcing function.

Reading your comment, I can now see how the original text could be interpreted this way. However, at least my understanding of what we were trying to express that there is an urgency to deliver, and we hope that by narrowing the discussion on what is important for H2 we can avoid going down some ratholes that are unrelated, or at least avoid going down them quite as deeply.

But if there are design choices that the WG has consensus on that are important for H2, and they would postpone shipping v1 *and* the WG is OK with that, too, then that's what it'll be. But we should all be conscious of the quality vs. time tradeoff.

> A firm timebox severely undermines the consensus process via simple gamificiation to 'run out the clock' in favor of existing text. That is not in the interest of the end result or getting consensus in a multi-stakeholder process. Indeed it probably increases the chances for a disastrous last call period. However, getting to yes is in everybody's interest. That's a much better motivator.

Full agreement.

> I think a better path would be for the chairs to more aggressively declare rough consensus at an earlier stage of discussion than is typically done. I'm not suggesting a different threshold of consensus, just less indulgence in letting issues play all the way out in hopes of convergence. Perhaps also an appeal to all WG members to consider the implications of expressing an opinion on a topic .. Every issue does not need to be a poll for everyone's opinion.. save it for places where your opinion makes a material difference to you. (i.e. acknowledge that two people will disagree on what is a bikeshed vs what is meaningful and stay out of it in the name of progress if you are on the bikeshed side).

These are good suggestions. Instead of the chairs declaring consensus earlier, we preferred to give the editors a lot of discretion about merging changes. Maybe the chairs need to become more involved in cases where there is disagreement amongst some editors.

Lars

> I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong.
> 
> I think your second suggestion, scoping around HTTP for v1, is more likely to get us to a successful finish. As we get later in this process, it will be more important.
> 
> 
> Browsing through the archives I actually don't see very many issues that are totally non-http (certainly < 10%). But there probably are quite a few that are simpler to resolve if only http is taken into account.
> 
> -P
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 27 Oct 2017 18:35:50 +0000

Hi,

> Can you be more explicit on how your proposals affect the current Multipath extension document dates? I could infer that the proposed changes to the core docs are independent of the extension doc,…

I'd prefer to not take on multipath as part of v1. I know we have a milestone about adopting a document on it just about now, but the WG simply hasn't had the cycles to dive into the topic, and doing so will IMO definitely delay shipping v1. So my preference would be to push the multipath milestones back as well.

Lars

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Oct 2017 21:13:14 +0200

On Fri, Oct 27, 2017 at 11:13:42AM -0400, Patrick McManus wrote:
> A shot

I agree. It's also important to keep in mind that there are periods in the
year where people are more busy by their work than other periods and this
can give the impression that everything stalls, but participating less does
not necessarily imply not thinking to come back later with clearer views or
more willingness to accept others' proposals.

> an opinion on a topic .

That's exactly what I was thinking as well. I'm fine with delaying a release
for a very good reason, but in general very good reasons more easily achieve
a rough consensus. It's the same with accepting not to delay because the
reason is not very good. If all WG members keep in mind that they take a
responsibility for delaying stuff by opening issues, it can get better.

> concern than consensus on the RFC content is wrong.

Agreed as well, we all know a few minor design mistakes that ended up in
H2 and HPACK for the sole reason that we stubbornly refused to play with
a few bits at the end. It makes none of us suffer, but it makes
implementations slightly more painful to write and the protocol slightly
less efficient. I tend to consider that important design must be defined
first and that small variations must be considered at the end. But we must
just accept the fact that a deployed beta version doesn't count as a good
reason for not fixing the last bits at the end, otherwise everyone will
still bikeshed to ensure the small bits that matter to them are committed
first to prevent the H2 process from happening again.

> to get us to a successful finish. As we get later in this process, it will

I think it's reasonable as well, it's hard to try to design for everything
at once, especially in such a very new area.

> > doesn't address the needs of HTTP-over-QUIC will be postponed until after

In fact we should start to speak about QUICv1 (Q1?) and not QUIC to make
this clear for everyone.

Just my two cents,
Willy

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 27 Oct 2017 21:29:35 +0000

Hi,

Being a keen listener and observer of QUIC WG (so far passively), and someone itching to move on to apply a "QUICv1" in different contexts as well as taking the next steps, such as multipath and RTCWEB, WebSocket and gRPConQUIC, getting a "QUICv1" with HTTP RFC in place is very desirable. If we fail to deliver a "v1", then QUIC future could perhaps be seen by some to be in doubt, and this not a good signal to send.

I support the chairs intent and find Patrick views very convincing. In short:

- Express intent to target eof 2018 with "QUICv1" focus as a signal to WG members to focus.
- Limit scope to HTTP on QUIC.
- A strong +1 on McManus comments on chair actions.

Best Regards
Göran

On 2017-10-27, 17:14, "QUIC on behalf of Patrick McManus" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Oct 2017 09:54:34 +1100

Hi Patrick,

> On 28 Oct 2017, at 2:13 am, Patrick McManus <[email-masked]> wrote:
> 
> Hi All,
> 
> First, the observation that elapsed time impacts participation and participation impacts quality is a good observation. Finishing faster (I personally want to go way way faster) is consistent with that and we should look at how we're organized to help make that a reality. Thanks for doing that.
> 
> I'm also not quite as pessimistic as the chairs are. I don't really think this is a linear process - as we get more input from more implementations I think the process will naturally accelerate. The challenge at that later stage will be on not re-opening issues that we have reached consensus on. That's different than the challenge we've been going through for the last year; for the last year we've been building up the basic blocks from an explicitly 0-consensus starting point. Its both not surprising, and a good thing, that many issues have been given scrutiny during that phase.
> 
> 

The milestones are a charter update, but chairs can submit revised milestones with approval by the AD, as always. 

I don't think (2) requires a charter update, but if that makes people more comfortable, we can talk about it.

> This needs to be severely unpacked and I do not support it in the way I'm interpreting it.

Understood. We anticipated some discussion. :)

> I think the only way we're going to finish quickly and still create a good product is if all the participants are focused on getting to yes. A shot clock process fix isn't going to get a high quali…

I agree, and that's a better way to say it. Thanks.

For those who weren't there, HTTP/2 had a similar focus on "getting to yes", through an understanding that our milestones were serious. It was not "consensus at any cost", it was an agreement that we wanted to ship something we agreed on in a reasonable amount of time. That agreement informed the decisions of individual WG participants -- but in a positive way, as you outline.

> A firm timebox severely undermines the consensus process via simple gamificiation to 'run out the clock' in favor of existing text. That is not in the interest of the end result or getting consensu…

If you see someone acting strategically like that, please bring it to our attention; it indicates participation in bad faith, and will need to be dealt with.

> I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong.

To be clear -- this does not magically give the chairs the ability to ignore or circumvent the process. We can't elevate anything higher than consensus.

We're asking for the WG to gain consensus that it wants to take the milestone seriously, to inform its further discussions. We'll still need to gather consensus on other things, and if the WG forms a new consensus that a particular proposal merits exceeding the milestone, it can do so. And of course we'll still need to gain consensus on what we put in the documents (and what we leave out).

> Browsing through the archives I actually don't see very many issues that are totally non-http (certainly < 10%). But there probably are quite a few that are simpler to resolve if only http is taken…

Indeed.

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Oct 2017 09:55:29 +1100

Hi Rich,

> On 28 Oct 2017, at 3:20 am, Salz, Rich <[email-masked]> wrote:
> 

Doubtless we'll deal with that if and when it comes. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Oct 2017 09:57:30 +1100

Hi Lucas,

> On 28 Oct 2017, at 3:36 am, Lucas Pardue <[email-masked]> wrote:
> 

I think multipath would remain a post-V1 activity, which implies that the dates would be pushed out.

Cheers,

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Oct 2017 23:52:28 +0000

I'm with Patrick.  While I do believe that HTTP/2 stayed on the right side of the line most of the time, I have heard other people in the HTTP community who very vocally expressed their opinion that we put finishing on time above being willing to re-examine issues as broader experience arose.  To some extent, that's self-fulfilling -- the longer the process takes, the less something we reached consensus on 20 months ago is guaranteed to represent the consensus of the currently-active participants, and we'll naturally have to rehash the same discussions whenever the composition of the group changes too much.

I'm supportive of reiterating that our "first and best" customer for v1 will be HTTP, and implementing a policy of tabling non-HTTP-blocking issues until v2.  I don't believe that's inconsistent with our current charter, other than to recognize that there may be more such issues than just multipath.  As the saying goes, shipping is a feature, and it's going to be more important than some other features in our backlog.  But the right path is to reach consensus on that prioritization, not to set a date (even a revised one) and say we're going to the IESG on that date come what may.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Friday, October 27, 2017 3:55 PM
To: Patrick McManus <[email-masked]>
Cc: QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: QUIC - Our schedule and scope

Hi Patrick,

Indeed.

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C0ceb5fbd79e84c7e3b1e08d51d8dba4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447416919107375&sdata=egqQsHDuy89iTrPcB%2FdMnBaTMFJPn4%2F%2Ftw5ZncLRmgk%3D&reserved=0

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 28 Oct 2017 10:04:37 +0200

hi Mark, all,

Broadly, I support Patrick's intepretation here. I'll point out that there seems to be some inconsistency between two points below:

> On 27 Oct 2017, at 08:26, Mark Nottingham <[email-masked]> wrote:
> 

and

> * V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond.

That QUIC's handshake, pre-version-negotiation wire image, and ossification-prevention features will be "baked in" in V1 is clear, and I thought it already had been, though thanks for calling it out here.

Focusing on *only* addressing HTTP in this wire image, though, seems like it might be dangerous in ways I can't fully articulate yet... HTTP is an explicitly asymmetric protocol, with different roles for client and server well beyond the initial handshake, and as it is presently most commonly deployed, wildly different architectures for client-side and server-side implementations. Many of the things that we suspect we'll want to bring on top of QUIC in the future are less so; even Web protocols like WebSockets fit here. Will this focus lead to invariants that will make less asymmetric applications harder to build and deploy? Should we be concerned about that at this point?

Thanks, cheers,

Brian

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 28 Oct 2017 11:12:18 +0000

I do support the intent to target Dec 2018 with QUICv1 and limiting its scope to HTTP
I am confident that we can reach that

I want also to give a strong +1 on Patrick and Mike comments on chair actions,
 especially on finding in the process the right balance between the delivery date and consensus on the RFC content

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Friday, October 27, 2017 3:55 PM
To: Patrick McManus <[email-masked]>
Cc: QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: QUIC - Our schedule and scope

Hi Patrick,

Indeed.

---

From: Roni Even <[email-masked]>
Date: Sun, 29 Oct 2017 06:33:44 +0000

Hi,
I am OK with the proposal and support the need to focus on what is relevant for the first release supporting HTTP/2 over QUIC.

I have some concerns about
"* V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond."

My understanding is that the objective is to design a general Transport Protocol that is not only for HTTP/2.

HTTP/2 is a one specific use case (client server case) while there are already other use cases in the pipe described in individual drafts (RTP, DNS, Multicast, unreliable streams,...). 
I think we must be very careful when defining the "invariants" to allow for other uses. For example look at https://tools.ietf.org/id/draft-aboba-avtcore-quic-multiplexing-00.txt  that tries to discuss one issue in the QUIC point to point case.

Roni 

> Sent: יום ו 27 אוקטובר 2017 09:27
> To: QUIC WG
> Cc: Lars Eggert; Spencer Dawkins at IETF
> Subject: QUIC - Our schedule and scope
> 
> Since the Working Group is now approximately one year old, it's a good time
> to step back and consider how well our work is proceeding.
> 
> As chairs, we've been concerned about successfully delivering QUIC since we
> started this effort. Introducing what is effectively a new transport protocol
> for the Internet that incorporates not only reliability, congestion control and
> multiplexing, but also encryption and key exchange, 0RTT handshakes, and
> what is effectively yet another version of HTTP is a tall order, especially when
> we started without broad implementation or deployment experience
> beyond a single vendor.
> 
> seem to range over a variety of topics that are difficult to pin down, thanks to
> the interdependencies between them. We've explicitly given the editors
> license to make bold changes in this start-up period as a way to move
> forward, but even with that, we've struggled to manage our workload --
> five months away. Many in the Working Group have viewed that milestone
> as aspirational, but it's becoming clear that on our current course, we'll be
> lucky to deliver QUIC in 2019.
> 
> It's important to understand that this approach is predicated on the notion
> that QUIC is not the one chance that we have to evolve transport protocols;
> rather, it represents the start of an evolution, to be followed by any number
> of new versions that are enabled by assuring that the extensibility and
> versioning mechanisms are appropriately "greased" (i.e., we take measures
> to assure that they are available in the future; in other words, counter-
> ossification).
> 
> Please discuss on-list; we'll also be covering this in Singapore, and will call for
> consensus after gathering further input there.
> 
> Regards,
>

---

From: Roni Even <[email-masked]>
Date: Sun, 29 Oct 2017 06:36:23 +0000

Hi,
Sorry for raising the same issue again, I only noticed this email after I sent my feedback
Roni

> From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell
> (IETF)
> Sent: שבת 28 אוקטובר 2017 11:05
> To: Mark Nottingham
> Cc: QUIC WG; Lars Eggert; Spencer Dawkins at IETF
> Broadly, I support Patrick's intepretation here. I'll point out that there seems
> to be some inconsistency between two points below:
> 
> That QUIC's handshake, pre-version-negotiation wire image, and ossification-
> prevention features will be "baked in" in V1 is clear, and I thought it already
> had been, though thanks for calling it out here.
> 
> Focusing on *only* addressing HTTP in this wire image, though, seems like it
> might be dangerous in ways I can't fully articulate yet... HTTP is an explicitly
> asymmetric protocol, with different roles for client and server well beyond
> the initial handshake, and as it is presently most commonly deployed, wildly
> different architectures for client-side and server-side implementations.
> Many of the things that we suspect we'll want to bring on top of QUIC in the
> future are less so; even Web protocols like WebSockets fit here. Will this
> focus lead to invariants that will make less asymmetric applications harder to
> build and deploy? Should we be concerned about that at this point?
> 
> Thanks, cheers,
> 
> Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 29 Oct 2017 06:45:08 +0000

Hi,

On 2017-10-29, at 7:33, Roni Even <[email-masked]> wrote:
> I think we must be very careful when defining the "invariants" to allow for other uses.

agreed. And, we must be very careful to not make future extensions like multipath, partial reliability, etc. more difficult to support than necessary.

So to me personally, that kind of forward-looking discussion - to ensure we retain the extensibility needed for the future - remains fully in scope. But there is a fine line between a general extensibility argument and an argument that says "my proposal for future extension X is this, and therefore QUICv1 needs to do Y now".

Lars

---

From: Simon Pietro Romano <[email-masked]>
Date: Sun, 29 Oct 2017 08:01:32 +0100

The sad thing about multipath is that there have been people who have worked, more than one year ago, on implementing it in a v1-compliant way. Though, the group has never wanted to give multipath a real chance to survive and has always treated it as a “potential future extension”. This has been made so clear in the mailing list that we have stopped trying to push for it.

Simon

Inviato da iPhone

> Il giorno 28 ott 2017, alle ore 00:57, Mark Nottingham <[email-masked]> ha scritto:
> 
> Hi Lucas,
> 
>

---

From: Roni Even <[email-masked]>
Date: Sun, 29 Oct 2017 07:17:49 +0000

Hi,
Just to put the focus

The relevant text in section 5.8 in the transport document is 

"Between different versions the following things are guaranteed to remain constant:

   o  the location of the header form flag,

   o  the location of the Connection ID flag in short headers,

   o  the location and size of the Connection ID field in both header forms,

   o  the location and size of the Version field in long headers,

   o  the location and size of the Packet Number field in long headers, 

   o  the type, format and semantics of the Version Negotiation packet."

This is what we need to agree on.

Roni

> From: Eggert, Lars [mailto:[email-masked]]
> Sent: יום א 29 אוקטובר 2017 08:45
> To: Roni Even
> Cc: Mark Nottingham; QUIC WG; Spencer Dawkins at IETF
> agreed. And, we must be very careful to not make future extensions like
> multipath, partial reliability, etc. more difficult to support than necessary.
> 
> So to me personally, that kind of forward-looking discussion - to ensure we
> retain the extensibility needed for the future - remains fully in scope. But
> there is a fine line between a general extensibility argument and an
> argument that says "my proposal for future extension X is this, and therefore
> QUICv1 needs to do Y now".
> 
> Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 29 Oct 2017 08:25:03 +0000

Hi,

> The sad thing about multipath is that there have been people who have worked, more than one year ago, on implementing it in a v1-compliant way. Though, the group has never wanted to give multipath…

I don't think that's a fair summary.

First, there is no v1. We're busy specifying it at the moment, and many, many fundamental things are still changing. These are taking all the cycles the WG has at the moment, and we're still not progressing at a satisfactory pace. (Which was the message that started this thread.) I also don't think that the implementations are at a stage where they can realistically think about adding multipath - most haven't even really looked at recovery in detail.

Multipath *is* in the charter, and we're fully committed to supporting it. I simply can't see how getting the WG working on the details at multipath at this time will help speed up work on the protocol fundamentals. And it seems that we'd need to continuously rework multipath while we're still changing protocol fundamentals, which would create additional busy work.

Lars

---

From: Simon Pietro Romano <[email-masked]>
Date: Sun, 29 Oct 2017 11:26:32 +0100

Hi,

> I don't think that's a fair summary.

…it’s "my" summary. BTW, the mailing list logs are there. The IETF is a tough place to be, we all know. If it weren’t a contradiction in terms, I’d call it an “oligarchic democracy”.

Simon

                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked] <mailto:[email-masked]>

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

> On 29 Oct 2017, at 09:25, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 
> On 2017-10-29, at 8:01, Simon Pietro Romano <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Simon Pietro Romano <[email-masked]>
Date: Sun, 29 Oct 2017 11:33:38 +0100

Hello Lars,

last comment and I’ll shut up, promised!

> Multipath *is* in the charter, and we're fully committed to supporting it. I simply can't see how getting the WG working on the details at multipath at this time will help speed up work on the prot…

Which is exactly what I’d call adding multipath capabilities to a protocol “by design”, rather than trying to add multipath after the protocol has been specified. I think that security should have taught us a lot, when it comes to distinguishing the "patch it” vs “think of it at design time” approach.

Simon
                     				            _\\|//_
                           				   ( O-O )

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 29 Oct 2017 11:14:17 +0000

Hi,

> Which is exactly what I’d call adding multipath capabilities to a protocol “by design”, rather than trying to add multipath after the protocol has been specified. I think that security should have…

so we did add multipath to TCP later, and it was painful, but not because we had issues extending TCP's design - it was painful, because the Internet had ossified around a pretty detailed set of assumption about what TCP would look like on the wire.

With, QUIC, if we get the greasing right, that danger is mostly off the table.

Now, we can still mess up the design of QUICv1 so that adding multipath later would be harder than it needed to be, but I'm pretty confident it's enough on our mind that that won't happen.

Lars

---

From: Christian Huitema <[email-masked]>
Date: Sun, 29 Oct 2017 05:35:11 -0700

> Now, we can still mess up the design of QUICv1 so that adding multipath later would be harder than it needed to be, but I'm pretty confident it's enough on our mind that that won't happen.

I would like to see good multipath support in QUIC, but I think we are
right delaying the work. True multipath support would most probably
require a separation between path variables, such as packet sequence
number and acknowledgements, and per connection variables, such as
stream data and control. It will also require serious work on connection
ID and privacy, not to mention a requirement to separate path ID and
connection ID. None of that is impossible, or even very hard, but taken
together it is a set of very disruptive changes for applications. From a
schedule point of view, it seems much more reasonable to wait until V1
is stable.

-- Christian Huitema

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Oct 2017 18:08:23 +0000

> On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi Mark, all,
> 

I do think that peer-to-peer uses of QUIC need attention pre-V1, if they’re to be supported cleanly. At minimum, we need to arrange the QUIC headers to easily demultiplex with STUN on the same UDP port, otherwise we’ll end-up re-inventing STUN within QUIC. Focussing solely on HTTP is going to make this difficult.

See draft-aboba-avtcore-quic-multiplexing-00 for more discussion.

-- 
Colin Perkins
https://csperkins.org/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 29 Oct 2017 20:53:50 -0500

Just to chime in on one point (and remembering that my responsibilities do
not include telling working groups what to think),

On Sun, Oct 29, 2017 at 3:25 AM, Eggert, Lars <[email-masked]> wrote:

> The sad thing about multipath is that there have been people who have
> worked, more than one year ago, on implementing it in a v1-compliant way.
> Though, the group has never wanted to give multipath a real chance to
> survive and has always treated it as a “potential future extension”. This
> has been made so clear in the mailing list that we have stopped trying to
> push for it.
>
>
> First, there is no v1. We're busy specifying it at the moment, and many,
> many fundamental things are still changing. These are taking all the cycles
> the WG has at the moment, and we're still not progressing at a satisfactory
> pace. (Which was the message that started this thread.) I also don't think
> that the implementations are at a stage where they can realistically think
> about adding multipath - most haven't even really looked at recovery in
> detail.
>
> Multipath *is* in the charter, and we're fully committed to supporting it.
> I simply can't see how getting the WG working on the details at multipath
> at this time will help speed up work on the protocol fundamentals. And it
> seems that we'd need to continuously rework multipath while we're still
> changing protocol fundamentals, which would create additional busy work.
>

When we were discussing the QUIC charter, I was very reluctant to charter a
new transport protocol in 2016 that didn't address multipath (other people
have suffered more while adding multipath to a protocol that didn't
anticipate multipath than I have, but I've seen enough suffering). That may
be the point I pressed on most strongly while editing the current charter.
So even though we wanted to minimize the initial charter scope, I included
multipath in the charter I took to the IESG.

I had assumed (without asking anyone) that

- Enabling multipath and forward error correction extensions

(listed as one of the key goals in the current charter) would put "making
sure that extensions were possible" in scope for v1.

I don't have an opinion about how "making sure" happens, of course.

   - If the working group was convinced that "greasing" in v1 is sufficient
   to enable extensions (at appropriate points in time), I would support that.
   - If the working group was convinced that something else is required,
   I'd listen, of course.

Thanks,

Spencer, speaking as responsible AD

Lars

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Oct 2017 06:27:21 +0000

In H2, I argued for the ability to negotiate individual extensions rather than relying on the ALPN token, because there would be many potential extensions and a resulting explosion in ALPN tokens trying to express all the combinations you might support.  But for things as fundamental to the definition of basic concepts as multipath, I’m perfectly content making that a version number difference.  And I think we have a version-negotiation mechanism that’s robust enough that advertising and selecting for that version will be reasonable and compatible.  So on the multipath front, I actually wouldn’t back myself into the design assumed in the charter – we might decide that version-negotiation is a sufficient means of enabling future growth and use that for multipath.

Alternatively, or even if we do, FEC might be a good place to try out an in-version extension model, since it seems less of a fundamental mindset shift.

From: QUIC [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Sunday, October 29, 2017 6:54 PM
To: Eggert, Lars <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Simon Pietro Romano <[email-masked]>; QUIC WG <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: QUIC - Our schedule and scope

Just to chime in on one point (and remembering that my responsibilities do not include telling working groups what to think),

On Sun, Oct 29, 2017 at 3:25 AM, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On 2017-10-29, at 8:01, Simon Pietro Romano <[email-masked]<mailto:[email-masked]>> wrote:
The sad thing about multipath is that there have been people who have worked, more than one year ago, on implementing it in a v1-compliant way. Though, the group has never wanted to give multipath a real chance to survive and has always treated it as a “potential future extension”. This has been made so clear in the mailing list that we have stopped trying to push for it.

When we were discussing the QUIC charter, I was very reluctant to charter a new transport protocol in 2016 that didn't address multipath (other people have suffered more while adding multipath to a protocol that didn't anticipate multipath than I have, but I've seen enough suffering). That may be the point I pressed on most strongly while editing the current charter. So even though we wanted to minimize the initial charter scope, I included multipath in the charter I took to the IESG.

(listed as one of the key goals in the current charter) would put "making sure that extensions were possible" in scope for v1.

  *   If the working group was convinced that "greasing" in v1 is sufficient to enable extensions (at appropriate points in time), I would support that.
  *   If the working group was convinced that something else is required, I'd listen, of course.
Thanks,

Lars

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 30 Oct 2017 11:34:20 +0100

Hi

> On 29. Oct 2017, at 07:45, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 
> So to me personally, that kind of forward-looking discussion - to ensure we retain the extensibility needed for the future - remains fully in scope. But there is a fine line between a general extensibility argument and an argument that says "my proposal for future extension X is this, and therefore QUICv1 needs to do Y now”.

For the sake of getting things done, I totally agree with this statement.

But, as someone working on the yet-out-of-scope feature, I think the WG should find a gentle way to include these projects, and make sure it does to move towards squishing them.

Therefore, I propose 15min yet-out-of-scope feature report in the meetings.

I also think a kind of guideline how yet-out-of-scope features should give input could help, something along:
 - Have a separate daft on the feature with importing considerations and lessons learned from implementation.
 - Have a 4-line TL;DR regarding whether 
   1-2) how difficult implementing the feature is (given the current drafts)
   3-4) roughly what changes would be needed to add the feature
 - Don’t file pull-requests on the current drafts, but maybe have a fork with diffs ready.
 - Raise hands if changes under discussion would totally block / significantly complicate adding the feature later on  
 - Raise hands if changes under discussion would enable / ease implementation of this feature - these arguments might be tie breakers.

Based on that, I will continue to submit draft-tiesel-quic-unreliable-streams-01 today

AVE!
  Philipp S. Tiesel / phils…

---

From: Roni Even <[email-masked]>
Date: Mon, 30 Oct 2017 11:42:56 +0000

Hi,
Maybe we can say that future versions may have a different header size signaled for example by the message type . So the location of the payload is not fixed based on having 1 or 0 in the header form bit.
Roni

From: Philipp S. Tiesel [mailto:[email-masked]]
Sent: יום ב 30 אוקטובר 2017 12:34
To: Eggert, Lars
Cc: Roni Even; Mark Nottingham; QUIC WG; Spencer Dawkins at IETF
Subject: Re: QUIC - Our schedule and scope

Hi

On 29. Oct 2017, at 07:45, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 2017-10-29, at 7:33, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

AVE!

---

From: Martin Duke <[email-masked]>
Date: Mon, 30 Oct 2017 09:12:14 -0700

Lars and Mark,

I'm comfortable with being a little more aggressive with respect to the
schedule, as you suggest.

One practical suggestion: can we create an issue category for "deferred"
stuff? There are probably a dozen or issues that are good ideas floating
around (a couple of mine) that we may not have time to address in 2018, but
shouldn't be lost. I would feel a lot better about my stuff being punted if
I knew the WG would formally consider it in v2.

Martin

On Mon, Oct 30, 2017 at 4:42 AM, Roni Even <[email-masked]> wrote:

> Hi,
>
> Maybe we can say that future versions may have a different header size
> signaled for example by the message type . So the location of the payload
> is not fixed based on having 1 or 0 in the header form bit.
>
> Roni
>
>
>
> *From:* Philipp S. Tiesel [mailto:[email-masked]]
> *Sent:* יום ב 30 אוקטובר 2017 12:34
> *To:* Eggert, Lars
> *Cc:* Roni Even; Mark Nottingham; QUIC WG; Spencer Dawkins at IETF
> *Subject:* Re: QUIC - Our schedule and scope
>
>
>
> Hi
>
>
>
> So to me personally, that kind of forward-looking discussion - to ensure
> we retain the extensibility needed for the future - remains fully in scope.
> But there is a fine line between a general extensibility argument and an
> argument that says "my proposal for future extension X is this, and
> therefore QUICv1 needs to do Y now”.
>
>
>
> But, as someone working on the yet-out-of-scope feature, I think the WG
> should find a gentle way to include these projects, and make sure it does
> to move towards squishing them.
>
>
>
>  - Raise hands if changes under discussion would totally block /
> significantly complicate adding the feature later on
>
>  - Raise hands if changes under discussion would enable / ease
> implementation of this feature - these arguments might be tie breakers.
>
>
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 30 Oct 2017 16:40:09 +0000

Hi

On 2017-10-30, at 17:12, Martin Duke <[email-masked]> wrote:
> One practical suggestion: can we create an issue category for "deferred" stuff? There are probably a dozen or issues that are good ideas floating around (a couple of mine) that we may not have time to address in 2018, but shouldn't be lost. I would feel a lot better about my stuff being punted if I knew the WG would formally consider it in v2.

that is a good suggestion, and I will add that tag in GitHub shortly.

I would like to request that the proposers of such deferred issues bring them back at an appropriate time, rather than putting this load on the editors, who are already spread to thinly.

Lars

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 30 Oct 2017 18:19:19 +0100

Spencer,

> When we were discussing the QUIC charter, I was very reluctant to 
> charter a new transport protocol in 2016 that didn't address multipath 
> (other people have suffered more while adding multipath to a protocol 
> that didn't anticipate multipath than I have, but I've seen enough 
> suffering). That may be the point I pressed on most strongly while 
> editing the current charter. So even though we wanted to minimize the 
> initial charter scope, I included multipath in the charter I took to the 
> IESG.
> 
> (listed as one of the key goals in the current charter) would put 
> "making sure that extensions were possible" in scope for v1.

Having spent many cycles at making sure that Multipath TCP can work and 
be deployed, I confirm that it is important to take multipath into 
account early in the design of a new protocol like QUIC.

Quentin De Coninck has been working on Multipath QUIC and has submitted 
a draft that proposes minimal changes to QUIC v1 to support multipath 
capabilities. This could be a good starting point for the working group 
to ensure that the QUIC v1 design does not get stuck in a state where 
middlebox ossification makes multipath much more difficult than it 
should be.

Name:		draft-deconinck-multipath-quic
Revision:	00
Title:		Multipath Extension for QUIC
Document date:	2017-10-30
Group:		Individual Submission
Pages:		20
URL: 
https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/
Htmlized: 
https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-deconinck-multipath-quic-00

Abstract:
    Multipath TCP has shown how a reliable transport protocol can
    efficiently use multiple paths for a given connection.  We leverage
    the experience gained with Multipath TCP to propose simple extensions
    that enable QUIC to efficiently use multiple paths during the
    lifetime of a QUIC connection.

The draft shows that with small extensions and the ability to encode a 
path identifier in the public header, it is possible to have a Multipath 
QUIC design that is both clean and extensible. Quentin also has an 
implementation of Multipath QUIC as an extension of the QUIC-go 
implementation (thus not totally aligned with QUIC v1). His measurements 
that will appear in a forthcoming paper show that Multipath QUIC 
provides very good performance compared with Multipath TCP.

Best regards,

Olivier Bonaventure

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 30 Oct 2017 19:18:50 +0000

> https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt

My comment on this multicast design is that I do not think this ADD_ADDRESS can work well due to NATs (as the client is not aware of its external addresses).

- Igor

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Monday, October 30, 2017 1:19 PM
To: Spencer Dawkins at IETF <[email-masked]>; Eggert, Lars <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Simon Pietro Romano <[email-masked]>; QUIC WG <[email-masked]>; Mark Nottingham <[email-masked]>; Quentin De Coninck <[email-masked]>
Subject: Re: QUIC - Our schedule and scope

Spencer,

> initial charter scope, I included multipath in the charter I took to 
> the IESG.
> 

Having spent many cycles at making sure that Multipath TCP can work and be deployed, I confirm that it is important to take multipath into account early in the design of a new protocol like QUIC.

Quentin De Coninck has been working on Multipath QUIC and has submitted a draft that proposes minimal changes to QUIC v1 to support multipath capabilities. This could be a good starting point for the working group to ensure that the QUIC v1 design does not get stuck in a state where middlebox ossification makes multipath much more difficult than it should be.

Abstract:

The draft shows that with small extensions and the ability to encode a path identifier in the public header, it is possible to have a Multipath QUIC design that is both clean and extensible. Quentin also has an implementation of Multipath QUIC as an extension of the QUIC-go implementation (thus not totally aligned with QUIC v1). His measurements that will appear in a forthcoming paper show that Multipath QUIC provides very good performance compared with Multipath TCP.

Best regards,

Olivier Bonaventure

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

---

From: Quentin De Coninck <[email-masked]>
Date: Tue, 31 Oct 2017 09:50:56 +0100

Hello Igor,

> My comment on this multicast design is that I do not think this ADD_ADDRESS can work well due to NATs (as the client is not aware of its external addresses).
This design is similar to the ADD_ADDRESS Multipath TCP option, and the 
current Multipath TCP deployments are using this to advertise the public 
addresses of the peer. The ADD_ADDRESS frame can be used to advertise 
other server public addresses, such that the NAT'd client can initiate 
path usage over those public addresses.

Quentin

---

From: Ian Swett <[email-masked]>
Date: Tue, 31 Oct 2017 10:17:31 -0400

Excellent suggestion Martin.

Lars, what is the name of the new label?  I have at least one issue I'd
like to tag as nonblocking(or ponies, or deferred...).

On Mon, Oct 30, 2017 at 12:40 PM, Eggert, Lars <[email-masked]> wrote:

> I would like to request that the proposers of such deferred issues bring
> them back at an appropriate time, rather than putting this load on the
> editors, who are already spread to thinly.
>
> Lars
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 31 Oct 2017 16:07:34 +0000

Thanks, yes, that does make sense for the server to do, similar to the MIGRATE frame (https://github.com/quicwg/base-drafts/issues/560).

- Igor

-----Original Message-----
From: Quentin De Coninck [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2017 4:51 AM
To: Lubashev, Igor <[email-masked]>; Olivier Bonaventure <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; Eggert, Lars <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Simon Pietro Romano <[email-masked]>; QUIC WG <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: QUIC - Our schedule and scope

Hello Igor,

> My comment on this multicast design is that I do not think this ADD_ADDRESS can work well due to NATs (as the client is not aware of its external addresses).
This design is similar to the ADD_ADDRESS Multipath TCP option, and the current Multipath TCP deployments are using this to advertise the public addresses of the peer. The ADD_ADDRESS frame can be used to advertise other server public addresses, such that the NAT'd client can initiate path usage over those public addresses.

Quentin
> Cc: Lucas Pardue <[email-masked]>; Simon Pietro Romano 
> <[email-masked]>; QUIC WG <[email-masked]>; Mark Nottingham 
> <[email-masked]>; Quentin De Coninck <[email-masked]>
>> charter a new transport protocol in 2016 that didn't address 
>> multipath (other people have suffered more while adding multipath to 
>> a protocol that didn't anticipate multipath than I have, but I've 
>> seen enough suffering). That may be the point I pressed on most 
>> strongly while editing the current charter. So even though we wanted 
>> to minimize the initial charter scope, I included multipath in the 
>> charter I took to the IESG.
>>

---

From: Ian Swett <[email-masked]>
Date: Tue, 31 Oct 2017 18:38:13 -0400

I have created a new quicv2 label.  Anyone who created issues that are not
critical to resolve before QUIC v1 should tag the issue with the new QUICv2
tag.  Editors will also tag some issues as quicv2, but it'd be better if
the issue creators did so themselves.

As an example, my Message frame issue:
https://github.com/quicwg/base-drafts/issues/814

Thanks, Ian

---

From: Roni Even <[email-masked]>
Date: Wed, 1 Nov 2017 06:42:32 +0000

Agree with Colin and this is one reason for my concern about the "invariant" in V1 based only on the HTTP use case.
Roni

> From: QUIC [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: יום א 29 אוקטובר 2017 20:08
> To: Brian Trammell (IETF)
> Cc: Mark Nottingham; QUIC WG; Lars Eggert; Spencer Dawkins at IETF
> > Broadly, I support Patrick's intepretation here. I'll point out that there
> seems to be some inconsistency between two points below:
> >
> the wire that will not change -- to allow other use cases to be addressed by
> V2 and beyond.
> >
> > That QUIC's handshake, pre-version-negotiation wire image, and
> ossification-prevention features will be "baked in" in V1 is clear, and I
> thought it already had been, though thanks for calling it out here.
> >
> > Focusing on *only* addressing HTTP in this wire image, though, seems like
> it might be dangerous in ways I can't fully articulate yet... HTTP is an explicitly
> I do think that peer-to-peer uses of QUIC need attention pre-V1, if they’re to
> be supported cleanly. At minimum, we need to arrange the QUIC headers to
> easily demultiplex with STUN on the same UDP port, otherwise we’ll end-up
> re-inventing STUN within QUIC. Focussing solely on HTTP is going to make
> this difficult.
>