Re: Multi-path QUIC Extension Experiments

Lars Eggert <lars@eggert.org> Tue, 20 July 2021 07:14 UTC

Return-Path: <lars@eggert.org>
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 395C33A15A8 for <quic@ietfa.amsl.com>; Tue, 20 Jul 2021 00:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 rtsh0ZDGZcoC for <quic@ietfa.amsl.com>; Tue, 20 Jul 2021 00:14:37 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 413573A15A5 for <quic@ietf.org>; Tue, 20 Jul 2021 00:14:37 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 91EE260035D; Tue, 20 Jul 2021 10:14:29 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626765269; bh=X/YNoBKOWLyGikZQt5GEyR9QmdLMTp/kDsTGJqnC3wY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=JtPZqDXIgm+rD6l7Q4weSNQA68hRNXs1LqOUyOV+ok4wxacNWFl69NCot2MPSzS+c W05+EY32N7FutT/NL+3wHt+4eGq/JFYaXpmRbs35D1QUpQ7XmhLPx9SyerF42zhgaT CUhw3x/88i0GR5mcPOZAyWASEZTWCt8bKEPoiEjw=
From: Lars Eggert <lars@eggert.org>
Message-Id: <41414E77-B01A-4EC1-9FF7-37A03DA5EF5A@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B45204CA-8F41-4C40-9D2B-0C597856F412"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: Multi-path QUIC Extension Experiments
Date: Tue, 20 Jul 2021 10:14:28 +0300
In-Reply-To: <0B9EAA73-802A-49F9-AEA3-A4F6C574A3F9@fb.com>
Cc: Charles 'Buck' Krasic <charles.krasic@gmail.com>, Yunfei Ma <yfmascgy@gmail.com>, Yunfei Ma <yunfei.ma@alibaba-inc.com>, "matt.joras" <matt.joras@gmail.com>, 李振宇 <zyli@ict.ac.cn>, Christian Huitema <huitema@huitema.net>, Mirja Kühlewind <mirja.kuehlewind@ericsson.com>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>
To: Roberto Peon <fenix=40fb.com@dmarc.ietf.org>
References: <8C2E8EFB-756B-449B-84E0-11CD6B57E541@ericsson.com> <0334A48E-B6C6-464C-A48C-4512A453DA81@fb.com> <CAPhuoz0vz2k63_ZaWmUg_XgSHUopid7vf+JY=JVFm_VqQJY87w@mail.gmail.com> <CAHgerOGhX3G_aBMrwZ0zXjN8tu9dqtu-9tu4z7YU80qfqaZkzQ@mail.gmail.com> <CAPhuoz1cG_ZftSFtapg-cKR23Y5AzWLxzqYq3NUfeL-8r890-g@mail.gmail.com> <0B9EAA73-802A-49F9-AEA3-A4F6C574A3F9@fb.com>
X-MailScanner-ID: 91EE260035D.A5D13
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ev76EavcIaaSvZ_pXN-yhNOK8kI>
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: Tue, 20 Jul 2021 07:14:42 -0000

On 2021-7-20, at 1:19, Roberto Peon <fenix=40fb.com@dmarc.ietf.org> wrote:
> 
> If we have to send data along a path in order to discover properties about that path, then sending less data on the path means discovering less about that path.
> 
> The ideal would be to send *enough* data on any one path to maintain an understanding of its characteristics (including variance), and no more than that, and then to schedule the rest of the data to whichever path(s) are best at the moment.

^^^ This.

Because the Internet has no explicit network-to-endpoint signaling, an endpoint must build its understanding of the properties of a path by exercising it, and specifically exercising it to a degree that causes queues to form (to obtain "under load" RTTs, see bufferbloat) and congestion loss to happen (to obtain an understanding of available path capacity.) Some people have called this "putting pressure on a path".

There has been a long-standing assumption that if you exercised a path in the (recent) past you can probably assume that the properties haven't changed much if you want to start exercising it again. This is why heuristics like caching path properties (RTTs, etc.) are often of benefit - often, but not always, and maybe never in some scenarios (e.g., overcommitted CGNs.)

There has been some work on this in the past for MPTCP. For example, on mobile devices - which most often have multiple possible paths to a destination via WiFi and cellular - exercising multiple paths comes at a distinct increase in energy usage. So you need a heuristic to determine if the potential benefit of going multipath is worth the energy cost of probing multiple paths before you do so.

Thanks,
Lars