Re: Take multipath to a BoF

[Kazuho Oku <[e-mail]>]

My +1 goes to MT too.

While I do not have a strong opinion (or knowledge) of the IETF process, I
think it would be better to talk about what MT mentioned: supporting use
cases, credible solutions, and interested participants.

Let's agree on where the goal is, before starting to discuss how we should
reach the goal.


2020年10月7日(水) 12:15 David Schinazi <[e-mail]>:

> I agree with Martin here. I would personally attend the BoF
> and commit to reviewing drafts, but I think that separating
> multipath from other work items that are more critical to the
> success of QUICv1 is the right thing to do.
>
> David
>
> On Tue, Oct 6, 2020 at 7:02 PM Martin Thomson <[e-mail]> wrote:
>
>> I know that this subject line might be taken to be inflammatory, but no
>> point in burying the lede.
>>
>> The original charter for QUIC included multipath, partial reliability,
>> and FEC.  Multipath was definitely firmer than the others, but it was still
>> aspirational.  As part of a larger package deal, it seemed OK at the time.
>>
>> What has become clear to me over time is that there are only a small
>> number of people who want to pursue multipath.  And I don't know whether
>> those people have common use cases or even if a single solution is
>> appropriate for all of those use cases.
>>
>> Right now, it is not clear to me that we have the right combination of
>> problem statements (or use cases), plausible solutions, and participants to
>> successfully drive toward a design.  I've followed the discussion recently
>> and this has become increasingly apparent.
>>
>> The IETF processes for deciding whether to take on new work are designed
>> to prove that there is a need for a standard.  That need depends on proof
>> of three things: supporting use cases, credible solutions, and interested
>> participants.  That process, by which I mean BoFs, is imperfect, but they
>> are the best we have.  And it looks like this working group is on a path to
>> avoid that process.  That would be a mistake.  By coasting into a decision
>> here, we risk confusing enthusiasm for QUIC as a whole for interest in this
>> one feature.
>>
>> I appreciate that some people believe that there was an understanding
>> reached on this topic.  I know we've talked about this a number of times.
>> But discussion was always about deferral in the past.  We're now talking
>> about concretely committing time to this.
>>
>> 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.
>>
>> If this community is not committed to building multipath capabilities,
>> then forcing that upon them would be counterproductive.  If the community
>> is indeed committed, then a demonstration of that commitment should not be
>> difficult to muster.
>>
>> Deciding whether the IETF should design a multipath QUIC needs to go to a
>> BoF.
>>
>>

-- 
Kazuho Oku