RE: QUIC - Our schedule and scope

[Mike Bishop <[e-mail]>]

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:[e-mail]] On Behalf Of Spencer Dawkins at IETF
Sent: Sunday, October 29, 2017 6:54 PM
To: Eggert, Lars <[e-mail]>
Cc: Lucas Pardue <[e-mail]>; Simon Pietro Romano <[e-mail]>; QUIC WG <[e-mail]>; Mark Nottingham <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

On 2017-10-29, at 8:01, Simon Pietro Romano <[e-mail]<mailto:[e-mail]>> 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.

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.

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