Re: Take multipath to a BoF

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

Hi, Lucas,

On Wed, Oct 7, 2020 at 10:15 AM Lucas Pardue <[e-mail]>
wrote:

> Hey Spencer,
>
> On Wed, Oct 7, 2020 at 3:30 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> The other reason a BOF would make sense, IMO, is to find out whether
>> people are willing to work on something that's not already chartered, but
>> QUIC is already chartered to work on multipath.
>>
>
> To tug on this thread a little and speak as an individual. I find the
> charter pretty light on detail wrt multipath. Yes it is mentioned but
> AFAICT the capability has complexity of implementation and deployment that
> is at least on par with any of the other standalone focus areas. Each of
> those has a pararaph with some even leaning on other groups' definitions.
> In contrast, multipath has scant information for what is in scope of
> discussion or not. How can people say decisively what they signed up for?
>

Let me emphasize strongly that I have no hat to wear in this discussion ...

In discussions about the QUIC charter in 2016, my opinion was that it was
silly to charter a major transport protocol with no mention of multipath,
because we kept chartering work on transport protocols to retrofit
multipath (with MP-TCP being only one example, but it was the one freshest
in my mind).

But adding it to the charter without a lot of details was fine with me. My
overarching consideration was whether we could deliver a transport protocol
that worked well enough for Google to use it for HTTP, and if the answer to
that had been "no", we wouldn't be having this conversation.

With my encouragement as then-AD, the chairs focused on getting QUICv1
finished, and that seems to have been the case after Magnus replaced me,
until fairly recently (the datagram extension is probably the biggest
exception to my statement).

I hear you, on complexity of implementation and deployment, and that's one
of the reasons I was speaking in favor of Experimental status.


> It is also unclear to me how multipath relates to our other deliverables
> of Applicability and Manageability drafts. Do those get held up, or does
> MPQUIC get its own equivalent?
>

We asked similar questions about the relationship of what
became draft-ietf-quic-recovery and what became draft-ietf-quic-transport,
but the working group Did The Right Thing (IMO). I've seen at least one
person asking why multipath isn't part of the core QUIC protocol, but I
think that's a conversation better had later, after there's experience with
an Experimental draft.

I'd hope the working group would do the right thing then, too.


> Without the WG agreed on the problem statement and use cases, I can forsee
> future challenges if divisive topics come up. We've seen instances through
> the course of QUIC interop and design iteration where an issue has come up
> and there have been multiple competing options. We've been able to overcome
> those, in part, because we can fall back on the charter's key goals of
> "minimizing connection establishment and overall transport latency for
> applications" and "Providing multiplexing without head-of-line blocking",
> and the secondary goals or constraints in each paragraph.
>
> Do those key goals apply equally to MP-QUIC? I've asked this in other
> threads and the response has seemed to indicate that uptime and bandwidth
> is more important...
>

I might have opinions, but that's (IMO) the right question for a QUIC Chair
to be asking.

Thanks for tugging on all of this.

Best,

Spencer

p.s. In about 2001, I asked Bob Braden why the IESG was chartering so many
working groups to do use cases, problem statements, and requirements before
they started doing actual protocol work. Bob looked at me and said, quote,
"is it not obvious to you that's to slow people down while we figure out
whether they're crazy?"

I honestly have no idea whether he was kidding, and I can't ask him now,
but ... so I'm hoping experience with Experimental specifications can
inform that, as was the case with Multipath TCP, now Standards Track.