Re: [tsvwg] Further thoughts on maturity of multipath
Ian Swett <ianswett@google.com> Tue, 28 March 2023 10:04 UTC
Return-Path: <ianswett@google.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 27950C14CE52 for <quic@ietfa.amsl.com>; Tue, 28 Mar 2023 03:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.596
X-Spam-Level:
X-Spam-Status: No, score=-22.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt5eDi-6G2Yh for <quic@ietfa.amsl.com>; Tue, 28 Mar 2023 03:04:29 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09947C151554 for <quic@ietf.org>; Tue, 28 Mar 2023 03:04:21 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id q6so5141702iot.2 for <quic@ietf.org>; Tue, 28 Mar 2023 03:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679997861; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+wIB4ljE7nDnu4tAO+p5W41AvhJAOV6s7Rq99c1JuIA=; b=lJrMj/QbKAuBvu8/GGYBFciSMI6rCLjCf9w4sYZ91X6GKTgAjIhMSiEdcV2tpMGZfo Y+Z2Q/dsxxy2T2VLESbKG4dfw5sMBatWAJYLfwTLj9t1YKWKgT7cvHfRmW4413LPt1kR vvn0G/caNHUaNIsBy5V0vVZ86oUiNijlTrykfPJ/CUZUfSv+wXHB3yuauhKEBcPJnBfq RaEe6vAb/S7kgOcafSoiqV5bT2IojwZ1YqLNrWWxtrzgEL5VzxHYdh+avkQdxGXjfcGk JL5hTPNhfAR4+nG4hf9bzxLcohrnwEK8UHdkOZBWechqDvbwKvE5E8O4KIeovVh9GbXf nwJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679997861; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+wIB4ljE7nDnu4tAO+p5W41AvhJAOV6s7Rq99c1JuIA=; b=b5iLHEpAuzAJrgIIzUU4rkmyIksJ6tn3BTdlQSp2Uuf2lyFiGIzoZ8Q0nuURKqihQN fBmfwIliY68Va1KMfQhe1XC3wy5Gd0yEgLsMH4+RLVPoZhY0J55K9jIVfQrxFNyzJauM vm5JrZy3wWLeNrlgA5Rq/wPvMg5/S5c8WeoxpBlCJfH7GzpyH4Z2uIMN5Lm8TpePcXDg A2+9xvtE+lMGlEnvcq6h+bfRHgK7llpRprpX7jqBrdcntsCH9szC152ymBkTAW+kWagO fd5VhRC8pl+4R7UHtuMQ88gn3XsifaTSPn51iPO0p6u2txzSts00dcZtlBoHXZfebw3j dnMQ==
X-Gm-Message-State: AO0yUKVMuAyC4V22J/20t84RLhLvkoksJFnZg4e/jdFxPWROrkMZsWni dSKmeMbxQMKwiwrTrJ6tOQz8kPu8mpEcP9ujtc7Dkw==
X-Google-Smtp-Source: AK7set/pTXiZ1odFlZBbHnaTy4SL2yhKKfIoHXDJinpDWZMOjvXFqyXblJdJqKUQZKuVy5Hq4wpVUYs8PhES8biFkXY=
X-Received: by 2002:a6b:6f12:0:b0:758:4909:fbd6 with SMTP id k18-20020a6b6f12000000b007584909fbd6mr12175173ioc.12.1679997860931; Tue, 28 Mar 2023 03:04:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxSZa1T2_17=j9r463R2AekOMNBsUn8uRTVjK8h0oqN6aw@mail.gmail.com> <FR3P281MB1663518668326DFB9272D1B1FA009@FR3P281MB1663.DEUP281.PROD.OUTLOOK.COM> <BE1P281MB16520F2DDA94B414B6CBAEE9FAB59@BE1P281MB1652.DEUP281.PROD.OUTLOOK.COM> <BE1P281MB1652131E69E7DAF578BAA149FA889@BE1P281MB1652.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <BE1P281MB1652131E69E7DAF578BAA149FA889@BE1P281MB1652.DEUP281.PROD.OUTLOOK.COM>
From: Ian Swett <ianswett@google.com>
Date: Tue, 28 Mar 2023 19:03:59 +0900
Message-ID: <CAKcm_gNFj+=7BtAJsGM=pueHH3HPodfPuz-qocLuxr0Jm7dr5A@mail.gmail.com>
Subject: Re: [tsvwg] Further thoughts on maturity of multipath
To: Markus.Amend@telekom.de
Cc: martin.h.duke@gmail.com, tsvwg@ietf.org, quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b9f61405f7f2fbb4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XZHcTzGMnvOyt478EDW2EyPO7MM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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, 28 Mar 2023 10:04:33 -0000
I don't have a strong opinion on EXP vs PS, but the conceptual structure of MPTCP, MP-QUIC, and MP-DCCP don't seem equivalent to me. On Tue, Mar 28, 2023 at 2:50 PM <Markus.Amend@telekom.de> wrote: > Dear all, > > Thank you to everyone who participated in today's TSVWG discussion on the > proposed section 3.9 for the MP-DCCP draft in the email below. The goal of > this section is to provide a clear recommendation to implementers that > concurrent path use is not a well-verified feature and therefore not > appropriate to be implemented over the Internet. With this statement in the > MP-DCCP draft, authors believe PS track can be followed instead of EXP. > Certainly, this cannot guarantee that implementers will use MP-DCCP without > the concurrent path usage feature over the Internet, but at least the > proposed Section 3.9.1. and the existing statement in the draft that packet > scheduling is out of scope indicate that this is experimental and therefore > at the user's own risk. > > Let me share my conclusion from the meeting and in particular the lack of > discussion that I see in this context to reach a generally accepted > consensus. > > > 1. the voting results on the EXP->PS question during the meeting showed > that more people have an opinion than have actually read the document or > the suggested section 3.9, which was confirmed in another vote earlier. I > would like to encourage these people, especially those who are not in > favor, to comment on the mailing list. As the author, I did not receive any > feedback from them during the meeting as to why they believe PS is not > appropriate. > > 2. I assume that the proposed text reflects a general dilemma of multipath > in the IETF. Therefore, any conclusion related to the change of MP-DCCP > draft from EXP to PS is part of a general multipath discussion that also > affects the ongoing standardization of MP-QUIC, or is also related to the > standardized MPTCP. Since the conceptual structure of MPTCP, MP-QUIC and > MP-DCCP is pretty much the same, this should motivate those involved with > these protocols to share their views here. > > Br > > Markus > > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Amend, Markus > Sent: Donnerstag, 9. März 2023 19:45 > To: martin.h.duke@gmail.com; tsvwg@ietf.org > Subject: Re: [tsvwg] Further thoughts on maturity of multipath > > Hi Martin, all, > > With the MP-DCCP draft-07 a version is now available which includes the > latest reviews from Simone and IANA. So I now come to the discussion from > the last IETF to change to "Proposed Standard". We, the authors, have below > attached a text with the new section 3.9 to the "Step 4b" proposed by you > for this. I am looking forward to the discussion. > > -------------------------------------------------------------------------- > > ### 3.9 Path usage strategies > > MP-DCCP can be configured to realise one of several strategies for path > usage, via selecting one DCCP subflow of the multiple DCCP subflows within > a MP-DCCP connection for data transmission. This can be a dynamic process > further facilitated by the means of DCCP and MP-DCCP defined options such > as path preference using MP-PRIO, adding or removing DCCP subflows using > MP_REMOVEADDR, MP_ADDADDR or DCCP-Close/DCCP-Reset and also path metrics > such as packet-loss-rate, CWND or RTT provided by the Congestion Control > Algorithm. > > Selecting an appropriate method can allow MP-DCCP to realise different > path utilization strategies that make MP-DCCP suitable for end-to-end > implementation over the Internet or in controlled environments such as > Hybrid Access or 5G ATSSS. > > #### 3.9.1 Path mobility > > The path mobility strategy provides the use of a single path with a > seamless handover function to continue the connection when the currently > used path is deemed unsuitable for service delivery. > > Some of the DCCP subflows of a MP-DCCP connection might become inactive > due to either the occurrence of certain error conditions (e.g., DCCP > timeout, packet loss threshold, RTT threshold, closed/removed) or > adjustments from the MP-DCCP user. > > When there is outbound data to send and the primary path becomes inactive > (e.g., due to failures) or de-prioritized, the MP-DCCP endpoint SHOULD try > to send the data through an alternate path with a different source or > destination address (depending on the point of failure), if one exists. > This process SHOULD respect the path prio configured by MP_PRIO or if not > available pick the most divergent source-destination pair from the original > used source-destination pair. > > Note: Rules for picking the most appropriate source-destination pair are > an implementation decision and are not specified within this document. > > Path mobility is supported in the current Linux reference implementation [ > https://multipath-dccp.org/]. > > #### 3.9.2 Concurrent path usage > > This method could be used to support a concurrent path utilization > strategy, which allows multiple path resources to be aggregated for higher > throughput. > > Compared to the path mobility strategy, the selection of DCCP flows is a > per-packet decision and part of the multipath scheduling process which is > out of scope of this specification. > > Concurrent path usage over the Internet can have implications. The choice > of (coupled) congestion control, scheduler, and possible reordering > function has performance and fairness consequences. Since this needs > further investigation, it is recommended that concurrent path usage over > the Internet SHOULD NOT be used. > > Concurrent path usage is also supported in the current Linux reference > implementation [https://multipath-dccp.org/]. > > -------------------------------------------------------------------------- > > > Br > > Markus > > From: tsvwg <mailto:tsvwg-bounces@ietf.org> On Behalf Of Amend, Markus > Sent: Freitag, 11. November 2022 15:22 > To: mailto:martin.h.duke@gmail.com; mailto:tsvwg@ietf.org > Subject: Re: [tsvwg] Further thoughts on maturity of multipath > > Hi Martin, > > > Thank you for your thoughts on the items we raised during the IETF 115 > TSVWG meeting. > > > We believe that 4b is a feasible step. We are currently working on a draft > version -07 that includes the final comments from Simone and IANA. Our plan > is then to provide text for a concurrent path usage section on the mailing > list. > > > Br > > Markus > > From: tsvwg <mailto:tsvwg-bounces@ietf.org> On Behalf Of Martin Duke > Sent: Donnerstag, 10. November 2022 11:44 > To: tsvwg <mailto:tsvwg@ietf.org> > Subject: [tsvwg] Further thoughts on maturity of multipath > > I reflected a bit more on the appropriate maturity level of MP-DCCP and > MP-QUIC, and the result is perhaps a bit more nuanced than what I said at > the mic. > > 1. After the presentations at IETF 115, I feel somewhat better about the > maturity of MP-DCCP. That said, I have no strong opinion as to whether this > has cleared the bar for standards track, and would be interested in the > overall consensus of the WG. > > 2. As I stated at the mic, for all MP protocols I am concerned about a > Proposed Standard that includes concurrent bulk delivery when we don't > really know how to fairly apply congestion control or schedule data streams > across multiple paths. Indeed, one reason I encouraged both the MP-DCCP and > MP-QUIC work is to provide a good experimental platform for the research > community to explore these questions. > > 3. However, that statement glosses over an important point. There are a > variety of use cases that are *not* concurrent delivery. Failover and "hot > standby" are sometimes supported by existing standards, but sometimes not > (for example, QUIC supports client address changes but not server). > > 4. Stepping back from the question of how to spell this in documents, what > I would like is for the non-concurrent cases to be standards track > (assuming they are otherwise mature enough) while implementers are warned > away from the concurrent use case unless they "know what they are doing". > > 4a. One way to do this would be to have a PS document that does not > include concurrency while a smaller experimental extension covers > concurrency. > > 4b. Another would be a PS document with a section concurrency that says, > in some way, implementers SHOULD NOT do this unless they know what they are > doing, perhaps outlining how this can be dangerous if you don't understand > your traffic, etc. > > 5. I am not the responsible AD for QUIC, but I believe a similar framework > is appropriate for MP-QUIC. > > I'm happy to hear the community's thoughts on this. >
- RE: [tsvwg] Further thoughts on maturity of multi… Markus.Amend
- Re: [tsvwg] Further thoughts on maturity of multi… Ian Swett
- Re: [tsvwg] Further thoughts on maturity of multi… Michael Tuexen
- RE: [tsvwg] Further thoughts on maturity of multi… Anna Brunström
- Re: [tsvwg] Further thoughts on maturity of multi… Lucas Pardue
- Re: [tsvwg] Further thoughts on maturity of multi… Ian Swett