Re: Take multipath to a BoF

Ted Hardie <ted.ietf@gmail.com> Wed, 07 October 2020 21:55 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329593A142D for <quic@ietfa.amsl.com>; Wed, 7 Oct 2020 14:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n36_dipBj3j for <quic@ietfa.amsl.com>; Wed, 7 Oct 2020 14:55:30 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3721C3A142C for <quic@ietf.org>; Wed, 7 Oct 2020 14:55:30 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id n61so3682205ota.10 for <quic@ietf.org>; Wed, 07 Oct 2020 14:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cclOWCsC9M+pm2HZIdHoYaLkQVZC6kO6HeDMPGH66QU=; b=d9PEAMS7rbReCB2jab5aFzTNhBSAHrqF4/FdzlU+GTzPmUR5RmQ+jzCfqOE93VYYnp +S3hdvOKQOxw3E/bKMfgFf/ncX4q0KwYXq9laLkTPn2RxFMQjXuHRXQXoXpMSIkFnXWS dRXmOCCMtMVNMCQT+K0+hotJ5go8PRbS3Ynl/VcD31PDmZJjQF7HurYlFzWs57twpdEX z3c9mYcCVzbn1u9IoDaBA/LQSRI5Vqi8obA1TzZUgIjvqdEDItBNnWE7j/yR7czoPjEf gM2AuvSzCT+sqDcZgcVRdmCrFOLkwQUWha9Z3tYbDMXD6ZoNLB+lMCAv8j7hSjwQiJyF 23/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cclOWCsC9M+pm2HZIdHoYaLkQVZC6kO6HeDMPGH66QU=; b=h7Xr5CfJgcoSdtXWiDXLJffEvInrlXcN8DfRYraKdrwT9eKz73aT6Ie4XaWjcsfIZH sltV0Sz9s4VAHGndDBOnSU08x97wSOsUYpPoO3I/8ryAXaZtwBF0rS1NfURv/RJnA+ZJ 0ymvIKuYYOLQYh3ftPvTFO/ff4emKG5m9Pvj6eY8ha8rXLmGHSbhOUR+p0bCGcq37YRc lLw3kJlhbffiwx4iE6esUovDsxdqborsJoSxsqmJ9zMuIfvL9tFZFk83ry0F415t31Y/ EgUwtX1yqRgvtepBzJToKU9UG2adHIrhRaviFyeLslSBQm7KHHPeGJSPcBW2WgbtiIYW E1TA==
X-Gm-Message-State: AOAM531D6fp3M1QHE23TsN8+XAf9bpcwzRVq6mZfZTAEzss/oyVHWV0h RA1R8LdHEQ+bJxvgRuvQ9QXoggtVrcwpLStO4/c=
X-Google-Smtp-Source: ABdhPJyafwEc5FkaEbudJAE9sHLvk3tHHXB+UvLRZ5/pB25etHkP1cM1fjLnMDEXoJXBLm6XEB+iOsPRASJY37v7Acs=
X-Received: by 2002:a9d:5545:: with SMTP id h5mr2888537oti.269.1602107729560; Wed, 07 Oct 2020 14:55:29 -0700 (PDT)
MIME-Version: 1.0
References: <f7dcea59-985c-4e31-b743-36315f2cb7e3@www.fastmail.com> <E2C884AC-5FC8-46B9-B879-F5A0B6F53C14@ericsson.com> <CAKKJt-eK0rZw5MEoUkoEuFHJd2g5kTF5+y9CaR3iSvj3SW4x_g@mail.gmail.com> <CALGR9obwi_xqEs1uXwa-QknREM4HPd=Dk-r+0ZYpWg=B4yk84Q@mail.gmail.com> <CAKKJt-d6vYmc8_Jmfvqk2zesy3dAybuZPCkEGycbkTKZ6StJDA@mail.gmail.com> <CA+9kkMDrZJ1ujdjC7YUe+7yM1onOM6LwwBh_W--L=jVbCF1=Gg@mail.gmail.com> <CAM4esxTK5kVF5EvCTvVT25=vSmNxuYviWVSQ3233K0r_qmqhhg@mail.gmail.com>
In-Reply-To: <CAM4esxTK5kVF5EvCTvVT25=vSmNxuYviWVSQ3233K0r_qmqhhg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 07 Oct 2020 14:55:03 -0700
Message-ID: <CA+9kkMB--HXmYuvBkfqDYFSjmnkTpTOh1j=CchH0u7eUoRQMBA@mail.gmail.com>
Subject: Re: Take multipath to a BoF
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>, Lucas Pardue <lucaspardue.24.7@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001cc73005b11bc601"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/R2mqTuGR_gTxS0Mb9TXxxb507JM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2020 21:55:32 -0000

Howdy,

On Wed, Oct 7, 2020 at 2:33 PM Martin Duke <martin.h.duke@gmail.com> 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