Re: Take multipath to a BoF

[Ted Hardie <[e-mail]>]

Some comments in-line.

On Wed, Oct 7, 2020 at 8:51 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> 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).
>
> Also speaking with no hats on, I think this is an accurate read of why
multipath was in the original charter.  At the very least, we wanted to be
sure that the QUIC working group thought about concurrent use of multiple
paths while working on the method for path switching.  While it certainly
hasn't been at the top of the list, I do think that it has been present
enough in the discussion that our existing toolkit won't need much
extension to get to concurrent path use.

Unfortunately, that doesn't mean we're a short draft away from success.
There are a bunch of different optimization knobs and levers which
magically appear when you move from one path to multipath (along with a few
new failure modes and privacy pitfalls).  Working out what settings on the
knobs and levers should be for different use cases is a good use of the
Experimental track, at least in my opinion, especially given the privacy
issues and failure modes.

If we had no sense of the use cases, then a  non-wg-forming BoF to discuss
them might be a useful step.  I've seen enough of them on this and other
threads to not believe that's needed, but I also won't object if other
folks want that.  But ultimately, I think the work has to remain part of
the core transport work on QUIC.  Without that, I think you get MP-QUIC as
a distinct transport from QUIC, rather than enabling QUIC to both path
switch and run over concurrent paths.  That's a substantially worse
outcome, at least in my opinion. I don't work for Apple, but I will
champion them for a moment without speaking for them:  I am convinced by
their use cases alone that this work is worth doing in the IETF.

Just my two cents,

regards,

Ted Hardie


> 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.
>