IETF Logo Mail Archive

Multipath (was: Re: Re-chartering for extension work)

Lars Eggert <lars@eggert.org> Mon, 16 December 2019 07:19 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 02FE01200E3 for <quic@ietfa.amsl.com>; Sun, 15 Dec 2019 23:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 sozOzsxeQJri for <quic@ietfa.amsl.com>; Sun, 15 Dec 2019 23:19:04 -0800 (PST)
Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A29C12009E for <quic@ietf.org>; Sun, 15 Dec 2019 23:19:04 -0800 (PST)
Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 51DBB20329; Mon, 16 Dec 2019 09:19:02 +0200 (EET)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 4716220289; Mon, 16 Dec 2019 09:19:02 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 1A31E40041; Mon, 16 Dec 2019 09:18:59 +0200 (EET)
Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 1975BA7152B; Mon, 16 Dec 2019 09:18:53 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <752D0B90-8B29-4DBC-9B2F-09E834335598@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F834608E-8470-4683-B429-5BE2218DD266"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Multipath (was: Re: Re-chartering for extension work)
Date: Mon, 16 Dec 2019 09:18:52 +0200
In-Reply-To: <1E872371-F543-4822-8C11-05601913A72E@tessares.net>
Cc: Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <1E872371-F543-4822-8C11-05601913A72E@tessares.net>
X-MailScanner-ID: 1975BA7152B.A647E
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/91Gqm233vJD3LVPF1kvEouF3cLs>
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: Mon, 16 Dec 2019 07:19:06 -0000

Hi,

On 2019-12-13, at 20:05, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
> Do you have any specific plans for the multipath work ?

thanks for reminding us about that! There is of course no intention of dropping the multipath work item from the charter. It's already in the charter and will remain there, so it's not affected by this rechartering.

(One could call multipath an extension and mention it alongside the others in the modification that Mark posted in the first message of this thread. Personally, I see it as a much more fundamental - and difficult - update to the base protocol, and therefore would keep it highlighted in the way it currently is in the charter.)

I think we'll be ready to start having discussions on multipath in parallel to working on these new extensions; I do expect the multipath work to progress at a slower pace, however. While we don't have to start at zero thanks to MPTCP, hard challenges remain (e.g., when pooling capacity, can we do it in a way that doesn't leave us operating near the max. RTT of the paths?)

Lars

v2.23.0 | Report a Bug | By Email