Re: Take multipath to a BoF

[Jana Iyengar <[e-mail]>]

Thanks, Martin, for this suggestion. While it seems inflammatory, and while
the chairs/ADs may disagree with wanting this to become a BoF, I agree with
your reasoning. A few points.

First, I want to say that multipath is a good thing to have in the long
term. It will take work -- even if you disagree that it will, it would be a
mistake to assume that it won't -- and I think we ought to do the work
necessary to make it happen.

However, the timing of this conversation is poor. In Martin Thomson's words:

"If the group had nothing else to do, then I'd be less concerned about the
time being spent on this.  I have no real interest, but I could go
elsewhere. But QUICv1 is hardly done.  We have more deployment experience
to learn from, version negotiation, datagrams, performance tuning, and
enough stuff to keep this community busy."

I find myself questioning the urgency and the timing of this discussion. I
do not want to put aside stuff that we ought to be doing to ensure that
QUICv1 gets out there and is adopted widely, which is where a number of
folks are spending cycles right now (many of the folks deeply engaged in
QUICv1 are now actively trying to deploy and iterate.) The success of
QUICv1 depends on these deployments succeeding, and we need to provide room
in the WG for these discussions.

I'll also re-emphasize that we need strong interest and commitment to
implement and experiment. In Marten Seemann's words: "people who’re
actually willing to put in the work to implement it, experiment with it on
an internet-wide scale and gather data to inform future specification work".

Even if it's not in a BoF, we ought to be asking the same questions of
starting this work within this WG right now.

On Wed, Oct 7, 2020 at 2:55 PM Ted Hardie <[e-mail]> wrote:

> Howdy,
>
> On Wed, Oct 7, 2020 at 2:33 PM Martin Duke <[e-mail]>
> wrote:
>
>> Hi Ted,
>>
>> (no hats here)
>>
>> 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.
>>>
>>>
>> Depending on what you mean, I'm not sure I agree with the bolded part.
>> There is almost certainly some amount of protocol (frame types, etc) that
>> have to be defined in QUIC, and I agree that this should happen in the WG.
>>
>> That's the key thing I think we need, so I'm glad we agree at least up to
> here.
>
>
>> But there are other more interesting problems (scheduling, congestion
>> control, etc) that are applicable to all the failover-capable transports
>> (MPTCP, SCTP, QUIC). I could be persuaded otherwise, but I think the latter
>> is best done not in QUIC, but instead either in TSVWG or a WG purpose-build
>> to do so.
>>
>
> I continue to disagree here, largely because what you can do about
> scheduling, congestion control, etc. varies among the different
> transports.  There are certainly common research topics, and if we were
> describing an RG, I'd agree that a dedicated group with a scope that
> included all of them would be a good result.  But for a working group, the
> engineering constraints and opportunities are sufficiently different that I
> don't think any of them are well served by being lumped together.  You
> might get a common solution, but there's a real possibility that it would
> be the least common denominator.
>
> Just my opinion, of course.
>
> Ted
>