Re: [tsvwg] Further thoughts on maturity of multipath
Ian Swett <ianswett@google.com> Thu, 30 March 2023 04:29 UTC
Return-Path: <ianswett@google.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6DC14CF05 for <tsvwg@ietfa.amsl.com>; Wed, 29 Mar 2023 21:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.596
X-Spam-Level:
X-Spam-Status: No, score=-17.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_NONE=-0.0001, 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 6fgn4xpZvLXK for <tsvwg@ietfa.amsl.com>; Wed, 29 Mar 2023 21:29:14 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 F3F38C1595FE for <tsvwg@ietf.org>; Wed, 29 Mar 2023 21:29:01 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id p34so10070171wms.3 for <tsvwg@ietf.org>; Wed, 29 Mar 2023 21:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680150540; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ON765dkK0jRLLJpIyUdD/ZKmJ2SwBtKwA5IsFder9IY=; b=HygMTGUM+YnVpQG3hwg89A61yYPTjabOejEdtaYauw5Qmmlvea+HaoZ1rJAdanUpEJ MWs79u3EpJYcqYKlaqIkHQNgZN/uRStcXWOeQrBR4a2vl5P+2L83Fuu74NeZd304PUm4 4Jj9tJBznDHrYACoPG1Zyfcqvt9zrsVQYMqI5Agb41I6si4y4+EfrORcb9d6p4cCD6TB HoTCGn1sqnrFOBq7+/DOi4MZI5K0S4nWKMaTyKV/T5QZzmA5P+2vVbc7XgaubGmCzJeK SIsRENGzI+NvL2j8zdhOSzk4vtVNaTBt0dXLxrayMQg0qH86O2RRfNV5vMVS6tz4oVF5 9eXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680150540; 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=ON765dkK0jRLLJpIyUdD/ZKmJ2SwBtKwA5IsFder9IY=; b=t/6ICmAKySYgGSLGGmicGYAOUuguVkPGa+6Go8WuwfUL5wORUg07YNLM2tt1aFaPnW MfX72eJkNUaRl0gmllQkUPg8k57lT+CCy5zFNhjmc3QYJChXiNLBV0bOCXTceMMhS3BR OC6d0My9beAOJbkweVjeFErQ5Xd44X832irxwJh18PU/AaydH53RBJMI42SjaPls93si 8DOezdwiZZm+Kj9RJnUHK1CS0rmLvCJqnFRpE0ElZ3rxPvNjqGTGRnk8wgOYnzLtp6+c bpcqNrMmX8X/ATuMUDbnwEY9xd14hl/MWKUIz+XVYHc2X4cDVbETeQL/v1L6224H0sx4 i4VQ==
X-Gm-Message-State: AAQBX9dA2U1SZz2uuxyb9ihUDhKA0+/7lkjsAftE4h5jzfk4kY9Nq2PO RbROnTSiigHaTI5wgdIga/RpBnCCZOeudBfA28NLVQ==
X-Google-Smtp-Source: AKy350bIrAZpVO1tjnfNsMXEsdnos0n6c+L5p5imWaHYa6coyZlNu1FAzu8fXf79WF2T4xGQ4NuQSO+3n1Cm0fvAIoM=
X-Received: by 2002:a7b:c005:0:b0:3ef:5dd6:2f94 with SMTP id c5-20020a7bc005000000b003ef5dd62f94mr15073405wmb.31.1680150540145; Wed, 29 Mar 2023 21:29:00 -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> <CAKcm_gNFj+=7BtAJsGM=pueHH3HPodfPuz-qocLuxr0Jm7dr5A@mail.gmail.com> <4c482e70379c47a787371a1d720e82de@kau.se>
In-Reply-To: <4c482e70379c47a787371a1d720e82de@kau.se>
From: Ian Swett <ianswett@google.com>
Date: Thu, 30 Mar 2023 13:28:48 +0900
Message-ID: <CAKcm_gP49U8E8BN3yUou676hNCqpeYV2hg_ORK7H-rtnL8WVDA@mail.gmail.com>
To: Anna Brunström <anna.brunstrom@kau.se>
Cc: "Markus.Amend@telekom.de" <Markus.Amend@telekom.de>, "quic@ietf.org" <quic@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001de36105f81688a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ww2RmYtSiQDVuUPzp4gVvd7LjZo>
Subject: Re: [tsvwg] Further thoughts on maturity of multipath
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2023 04:29:18 -0000
Apologies, in terms of the implications on simultaneously using multiple paths at the same time, I agree that they're approximately equivalent. In other ways, the 3 protocols have more substantial differences. On Thu, Mar 30, 2023 at 9:01 AM Anna Brunström <anna.brunstrom@kau.se> wrote: > > > > > *From:* tsvwg <tsvwg-bounces@ietf.org> *On Behalf Of *Ian Swett > *Sent:* den 28 mars 2023 12:04 > *To:* Markus.Amend@telekom.de > *Cc:* quic@ietf.org; tsvwg@ietf.org > *Subject:* Re: [tsvwg] Further thoughts on maturity of multipath > > > > 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. > > > > Hi Ian, could you expand on what conceptual differences you see with > respect to concurrent path usage? Is it related to safety or you are > thinking of something else? > > > > The potential safety issues involved in concurrent use of more than one > path seem conceptually similar to me for all three protocols (ask well as > for SCTP), even if there are other differences between the protocols. > > > > The publication of MPTCP as PS suggests that concurrent path usage is > considered safe. But I can agree with Martin that the use may have been > mostly for particular use cases so far and perhaps not much general use and > there is no coupled CC published as PS yet. It is also very easy to get > wrong. From that perspective, I think it makes sense to leave general use > of concurrent paths out of scope. > > > > Unless someone sees other safety issues, I am in favor of PS for both > MP-DCCP and MP-QUIC. From my understanding, this will make it easier to > make use of the protocols by other standardization organization. That seems > desirable from an IETF perspective. > > > > BR, > > Anna > > > > 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. > > När du skickar e-post till Karlstads universitet behandlar vi dina > personuppgifter <https://www.kau.se/gdpr>. > When you send an e-mail to Karlstad University, we will process your > personal data <https://www.kau.se/en/gdpr>. >
- [tsvwg] Further thoughts on maturity of multipath Martin Duke
- Re: [tsvwg] Further thoughts on maturity of multi… Markus.Amend
- Re: [tsvwg] Further thoughts on maturity of multi… Gorry Fairhurst
- Re: [tsvwg] Further thoughts on maturity of multi… Shihang(Vincent)
- Re: [tsvwg] Further thoughts on maturity of multi… Martin Duke
- Re: [tsvwg] Further thoughts on maturity of multi… Markus.Amend
- 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