Re: QUIC - Our schedule and scope

[Spencer Dawkins at IETF <[e-mail]>]

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]> wrote:

> Hi,
>
> On 2017-10-29, at 8:01, Simon Pietro Romano <[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
>