Re: My BoF report: multipath

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 23 October 2020 11:56 UTC

Return-Path: <spencerdawkins.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 9F7EB3A0C29 for <quic@ietfa.amsl.com>; Fri, 23 Oct 2020 04:56:15 -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=ham 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 YX--ljEIpdLe for <quic@ietfa.amsl.com>; Fri, 23 Oct 2020 04:56:14 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 2FEAF3A0C31 for <quic@ietf.org>; Fri, 23 Oct 2020 04:56:14 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id o70so984616ybc.1 for <quic@ietf.org>; Fri, 23 Oct 2020 04:56:14 -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=YKiR8W+bdYa/EpLofkQQCrQFJHSMjre2oOPBLT8TOJg=; b=BwzhmGUUAWwUW/U1YCGY2Li0lw1Fep/CkyHO2ER9k+KFUgUwb3zkZA2s1b4w/1Ho2D v9rnOx9e3RjSa79LFRyyBzBIeOlH9K5GmCHN0v/c2P+bkqcuMNMLdSNjn3V3sKT3IIhP nQog8bzey5sMjBdiEaLnFPci/ZsZA24sLie9ishqCtKL/lMAnpBBtNSh5whbDTRx9uIH rVGfmY7uVIV4ZyUNdubZTEaOM519MIUaBudU9/tOPR5O6dirgIibXpa1RxBQcIzOmYLg AjFpQztXvfeqGZMYzKMZnIdHLzT5JWQG1ZBbuzd/sJTh3lYSl0oBS8eAthxikIu/EorG ir5w==
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=YKiR8W+bdYa/EpLofkQQCrQFJHSMjre2oOPBLT8TOJg=; b=ntl2ynVN7uvUkU7M5IXqO7k85soiygBntdvRTSH/Zz9pgVDcgpJ/P9DbzVigfiV4MB D+fm1cD+4q3sbjuaaXdTUPdPbYPePaG34Qxgn/2JTTTQU4TNEYzw8DbmwJKNijMtwaRy NXLdg2n34nOy+fiflvPD9sWaYqKKXeopFDfxVb71rsYGyRqBLggPgfdJdncdRrwGkE+r X0Gye0JiOIl3VPO8IwAmpfUfKCj6kB/vNjf9hswO1LiG3jYvkyaZl9sbcWlSCyw3AkH6 4diM/NUSrrbkgoqSEV4enmQwEJSKd2xF7t+MhutJuwhW0gCO956oiB3D0N8bO1dOvBoa 7Cvg==
X-Gm-Message-State: AOAM533R5X8MBa3D8O6CN4+KgN8DBPeh3PU8T0jWVL45s3nr6i5js9iE E/NpYi2+NIf4U2LjIO0NRuzBNGXt/A7baLsngDM=
X-Google-Smtp-Source: ABdhPJxOomDKGv0UsauriD5PijamaFV0QGuZwVxuShs2RZ7XxaiLk/LIVZTtlFj/ABn9CeedPS9PVIPwp3cra/K9928=
X-Received: by 2002:a25:e0d1:: with SMTP id x200mr3022643ybg.84.1603454173317; Fri, 23 Oct 2020 04:56:13 -0700 (PDT)
MIME-Version: 1.0
References: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com> <5741601d-7e67-898e-5840-70feceb994e9@uclouvain.be> <CALGR9oZW0s6c6+N+3R8bD17yPBPQa4E_cVOaTOSNTVQPYy6sUg@mail.gmail.com>
In-Reply-To: <CALGR9oZW0s6c6+N+3R8bD17yPBPQa4E_cVOaTOSNTVQPYy6sUg@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 23 Oct 2020 06:55:47 -0500
Message-ID: <CAKKJt-eR7-qyv-tECMPBhwCeNMs2bfm0D67evFaOPDieZ1-CWA@mail.gmail.com>
Subject: Re: My BoF report: multipath
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="0000000000006a0d6805b25544ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wwpl7cmVXapm38Z5NqWL-vi3id4>
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: Fri, 23 Oct 2020 11:56:16 -0000

On Fri, Oct 23, 2020 at 4:28 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Posting as an individual.
>
> Thanks to the time that people took to prepare, present and discuss, I
> gained a better understanding of this area.
>
> One main takeaway for me is that thinking of QUIC v1 as singlepath puts it
> in an unfair box. Others, such as Jana, articulated this point better than
> I.
>
> QUIC is path independent, path aware and provides mechanisms, written in
> the core document, for endpoints to interact  and interoperate about
> path-related things. Through the course of specification development things
> might have gone different, and we might be having a conversion now about
> whether the group should adopt a document that describes for instance just
> connection migration.
>
> But migration is in the core and, based on the Slack discussion following
> the interim, there appear to be several parties that have expressed an
> interest in testing deployments of Connection migration. This can be seen
> as some form of success.
>

Could you please add me to the slack channel? I'm assuming that is still a
manual process.

Thanks,

Spencer


> The use cases indicate that things like active-active paths or bandwidth
> aggregation are desirable. But I was unable to discern objectively how more
> of an optimal experience they would provide over a well tuned QUIC v1
> endpoint that use connection migration.
>
> I encourage people to think about the charter goals for the QUIC protocol,
> what success looks like, and whether they think connection migration
> delivers a sufficiently good part of the multipath feature set that was
> vaguely described when we started off.
>
> Cheers
> Lucas
>
>
>
>
>>