Re: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt

Markus.Amend@telekom.de Mon, 01 March 2021 18:19 UTC

Return-Path: <Markus.Amend@telekom.de>
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 D24753A20CA; Mon, 1 Mar 2021 10:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 aCOeYlGFz7js; Mon, 1 Mar 2021 10:19:38 -0800 (PST)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 8DE243A20C9; Mon, 1 Mar 2021 10:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1614622777; x=1646158777; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y9cxpVWn/9h/USqvmKIrCeh1FQb0B04+ALA/kbQ1C9E=; b=D03ZEDk97nLR+QpvUiRhRasZoxwt2kyPgudSz48YTUVCz/o/yLgsc1Ir kizdHsdoJrmLHsIdhnTlpaHIA7ixB9eNrb0METyPWLRu2TJMTvFLSqvY+ QTLhyyvJfU0h+T6/hvs2wSdukaCW48Q/uPKwl4TZb1E8wsOa3fIgc9Xr/ lGKjGZunDPrp4CSYQrVl3MwBRB+h9+r8bFBh6WIpfY8IGWyw/zHdDONGT //Yqnsb0JniPzP0Id6S0bmnmj/7cu+rPTGPb0kVE7pI9Vzo9E0DLsVeL1 tf6fPeW+NVH+88/GM1DXsjEnCewrJyA0r0WNMA45YvFTuRiH7sXRrPFgN Q==;
IronPort-SDR: eGAFlR6/9/8ED75DZn2EHKiYWCJSzkynV9qLS5kE3eVF/Y4r94Ba8IK8Oyd8blJ+uxvwUtpXFg ++I/tZz7HIBQ==
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 01 Mar 2021 19:19:34 +0100
IronPort-SDR: TQyclR5mz+XGmy2i8ciQB2ORfJXeMfHDiPfj4yHVFObeNBofyEGIJTFP9aLhB29DN7yGNO6xR6 w5SLGqELcCCPlWTH84qRX25jkpXZOWFkQ=
X-IronPort-AV: E=Sophos;i="5.81,215,1610406000"; d="scan'208,217";a="289229597"
X-MGA-submission: =?us-ascii?q?MDHv6YDHjQapogEqZqymm9f2sh31HRhMvVTyfv?= =?us-ascii?q?8PYbiA7TkmqQOH65wLKxq+gsGlm2DMAgQAduGDoRzpgwYUqLG11yA6SH?= =?us-ascii?q?RpV3ut3sXTu0B2YxyC4u4j/MeRQi0ks8VhwrRfGUIUVX4Oyll2knWSps?= =?us-ascii?q?NKWfAOZjh5QHrZQ+6V2zB1vw=3D=3D?=
Received: from he199743.emea1.cds.t-internal.com ([10.169.119.51]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 01 Mar 2021 19:19:34 +0100
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199743.emea1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Mar 2021 19:19:33 +0100
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Mar 2021 19:19:33 +0100
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.174) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Mar 2021 19:19:33 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SX/xWur1ZMRHU36jRhX2KN/4sIX2IG80aWs77q3AIITSTAK7fZiNR7KExAaJW7TAVOrk0pZTPN8JiivvFRA+AT+svezlEaynIWcK/6owUyAclJcd1XQbJv28tWu2npFYjsriyinI20wb1/00GfcyVShq9itHaJz5/6BrgsXmxPMZTpxlSXS6ANnQWFBNPzsL/xyErhsNIXSQ7ropmOU5oh2SqObY6pXu4RiNsLyelT200RACBDw1Me019xUVVo3Dk60ajTFisVxwQD2h8tcABYdImYllW4IeVVH6632rg2g9OxFhsDRlcW/vmiuD/mS/ZDOLasVWDPY62mBpwpy+Kw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y9cxpVWn/9h/USqvmKIrCeh1FQb0B04+ALA/kbQ1C9E=; b=aF+ANT0V5BIdL13gPfhd2YccVt/PP4Lm5+zYFp7DYFil7/bn2ZwNHFEfxB7K49hPM2dyyc5av8s495oF88zNjOOQ1k/Mel40U6pCJDD23sCR9GPotfO4LAwkAvflvcboJCVKN+z8y0peKHrusaGFOKNRGXSJuatGYq+gp7BC4xGIBuCU6Lm7GL6lAF957nLPr4V4lgHCuQwFf1DXAFYgTEaNKK0K6HkiOFIlX4bXTagP3alkFJTKK7cE/NrIlrME0ZwJqIIRhLv5aZIxHwB1zGlIB2fx+UcFGQpE/QAuaJMsVpcNP2hy3cqtOzlgfqnfWf1U/dePyo1/ynUOEE2tsA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c::9) by FR2P281MB0108.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Mon, 1 Mar 2021 18:19:32 +0000
Received: from FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM ([fe80::4065:5dca:1a05:d8e8]) by FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM ([fe80::4065:5dca:1a05:d8e8%6]) with mapi id 15.20.3912.016; Mon, 1 Mar 2021 18:19:32 +0000
From: <Markus.Amend@telekom.de>
To: <ingemar.s.johansson@ericsson.com>, <martin.h.duke@gmail.com>
CC: <draft-amend-tsvwg-multipath-dccp@ietf.org>, <tsvwg@ietf.org>
Thread-Topic: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt
Thread-Index: AQHXDJUCRymVMD8hnkexS8HNbkyYt6pvGnqAgAAD1XA=
Date: Mon, 1 Mar 2021 18:19:32 +0000
Message-ID: <FR2P281MB0155DE8C43FBEDDF47199532FA9A9@FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM>
References: <FR2P281MB0155FF3468251D20E8A1E73FFA9D9@FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM> <CAM4esxTLChOthAqawT0vnzN8Cgy=VHNN+42EDgRxzX8BGGU=Ng@mail.gmail.com> <HE1PR0701MB22998FC9BD927123538103E2C29A9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB22998FC9BD927123538103E2C29A9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a0ac5a93-7ae9-4373-9757-08d8dcde8f9a
x-ms-traffictypediagnostic: FR2P281MB0108:
x-ms-exchange-minimumurldomainage: github.com#4892
x-microsoft-antispam-prvs: <FR2P281MB0108D608723C7FB38DFAA696FA9A9@FR2P281MB0108.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Mp51qLe9L2pk8liWCIHPiZfPfsoJoVvthBpYmRYQpms2u8Ef8f+ajAVk8ee1TGlvMv1pPwXU67hyjRWmTaX8cu5WqbNnZ2sUWkHV7n7160do8uivt5z2Y1ef+g0VJuRD7yXoAD9nraA59B0/b5g0KYsme+4MIbD+PYV0hXNFN+mVtJGCH36pJOhXKbLi8M92VdmlRXRYr6Xzpwy0a2D2qKoMD0HLdQSJjgPVcCCLG8QqyVjAu95jGo1aIq1U5q4RoiZUgauMIx0P8jnfY0OcgBKgBBFfjVbyNqWUo7aiDzKqrmjX2zbld3fy4Da+/IlPVb3w6rPYj1YySmRFM6D6Eu6VnlN1Ne4gMHLAoBezDr0yNOJ3UaooOKhdNk8t1XnzYs6I+iFEL/ek2IWcVatcBT7ZAISZflGawc+Vadn4YQYr19jqSGjjzdz48M0N2/x5Sisi23+E8P5qtU/L/BkxqDlXY8wDvsGHsoPUGCagfvr0XCVImr7ac6c4bylPIwcNYp8kigtAXKr1eHKqjElM28dkjZm08g6jOL5xWI826vqyG7yG4jUOw/XD11C2Slnvz5fxfo5ylWmYUTySxvODi5s7CWYPcgIKI5P3mXBTjvfjY/Gt510LPIo9Z2+hQEwUwvbzggIK+/Oa2uC3ITwCRA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(396003)(346002)(376002)(478600001)(30864003)(8676002)(4326008)(53546011)(71200400001)(6506007)(26005)(7696005)(8936002)(166002)(186003)(9686003)(52536014)(76116006)(64756008)(54906003)(110136005)(66556008)(66446008)(66946007)(55016002)(15650500001)(66574015)(316002)(86362001)(66476007)(2906002)(966005)(5660300002)(83380400001)(33656002)(557034005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?SVYrODZjZWJ0dWwzT1VYaEY5MGRMUUM4SlFNbG4zVkxrSkZRSXJOaWJjMWZq?= =?utf-8?B?WHA3a3dLc08xQ1M4L1phVDlnV2Vpb0t4VVRET3IrR2l2cXBudkRxOE9XcGpv?= =?utf-8?B?dzgrWVRUUDhQcjNqaWJCb2NzZ2p6YTdtdGxGeVVzNlJWa1F2TWlZWUszV0Zu?= =?utf-8?B?NSswaUVsSC9KUy9zbVNtTi82TjcrbGJNMlJIK1JvdWV6Uk8zOElOeEl0WjBC?= =?utf-8?B?OUlrZENuM1lDOUdRNUM0SzZsR0ZQeHNSb2t4SXV0Sm1sVUF2Y2pTSzJob1lW?= =?utf-8?B?S0x2ZzRlMzlMUkdwanVPbmpzTjdtUkF5RkR6UGY1dVlDbjRvV00zOGpxMCtZ?= =?utf-8?B?QW5sSGJoTHFlUzg2UkZlVmp0SVpUYWxlRVdZRE04NmpqeUZyQ0Mzc29uak1y?= =?utf-8?B?VWx1MDRNcnVZVm1Kbis3SzRaVEkvb0xIcnVFUG1WUjRzQUh5d0VseVVSRm93?= =?utf-8?B?QkhhbXdQV2JCWVZ3YnlkbDZ0RFZVcG9yS2lreUNhZHZRejFiYWN4T0RTSkxG?= =?utf-8?B?R3krK05xL050RGFUWUMzd2J6cmp2YjhOVXhvRTdsWnlSZDkvRFJaRTIzTFdM?= =?utf-8?B?VVE2M1RIaUhlR05zb1ZhTjU2QWZCVkx0UUtmQXZYRzNjR2RTT1dYcE1PMXVi?= =?utf-8?B?R21wZityaStqSzJiSkNzY2M3WVJXeTlrQmtaWDVNSHhMK2orQmpPQ1p6TVFn?= =?utf-8?B?amVYSDY0Z0JRSzhvb0xNNGREaGZrWGozRlA4TUlqZ09vdjRnOHdHRzZhWWpG?= =?utf-8?B?ck9jNy9JVEM3T016V2Zia0tUcllid1lHNDg0NE9HYkxMdUZqODRNU3VxU2JJ?= =?utf-8?B?MXFQOTZBZUxXSWg4Qk5yZFdwL3pCRkt3Qml0NmowaTJOOURzMHQxOWRvRjNy?= =?utf-8?B?WTg0RzN5MmUwSEhSZFZxL243K3pYVkp2bGlUVk1GSFc5ZjFzdk9maGRQWDBE?= =?utf-8?B?UTBZNWFmZXV2bjFVelpSY3c3bkxEV3FWNElycHVScENidTQybGdLaUpQTDY5?= =?utf-8?B?cXphZHZVa0p0emduUlF3VGozY1ppSlRXQ3MzcXB0SDFaeUdTbVNyeG1JZDRO?= =?utf-8?B?R3VuMkp6ZEZMakZXNDNScjRYZkJ0SmN3U3FZZUlKb2NRR3JYclRubW12T3pC?= =?utf-8?B?M3ovdzJzcWFkMENjajNiVCtxQVRMYWNHTVh2UlFSSzhpdlJWQlBkME1xUXV2?= =?utf-8?B?WjdPU2poYVNjTDBNUjR2bWFFYlZFU21RNDRwS3JqZDEyc1ZQbCsvdmF2VkF4?= =?utf-8?B?alBYRnhKUEprSFgyYXFlRnR5eEN4RUpEVkNrZHIzWExEQmRzYUdMcFREcmly?= =?utf-8?B?YWUyRVdyQ3FDTmJETWVGYnd5cGRJL0cyTnpCbGpmZGVvWnV6Q2hwbzg0WjdQ?= =?utf-8?B?R0xOL1lmVm84NWtiWElpNVhteUJtTmc1UFBsYm1GdldtQWFjZHFjalBENG9z?= =?utf-8?B?Sjh0Uy9wTlh5dUhrTDF0eGlWN25iaFlFWG9CTVU2cktQVitoR0g3RXhTRFlq?= =?utf-8?B?NERXSU80cG1ZSWVXRXE4aXcvRWMrUkdOQVR5L1c3c2hScXZIWjErdDZ3N3cw?= =?utf-8?B?YXNyQ3JnTlhnZkwweHNrNHVuTk5QK0JiaEJSQ2EySlhyaXQvbFhmT0tyU3Vi?= =?utf-8?B?ckpMaUYyT1ZqRlRNdlhZdWFZdTNkeTJjeDRZZFhzL3M1ZmZjWmhaSTBKTTBU?= =?utf-8?B?c0hoak9NMmRtaEFjd1QxTktvVUVuQ1h6SFRWTGFNenBzYXBlcWRWVlZmL2p6?= =?utf-8?Q?yTHaC3PumDnT+r6TOyFLKGzhWffDCMXuojpR602?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FR2P281MB0155DE8C43FBEDDF47199532FA9A9FR2P281MB0155DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0155.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: a0ac5a93-7ae9-4373-9757-08d8dcde8f9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2021 18:19:32.2282 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fsKiAv6vEEyeOC6H+jT7cPzJuMazs/WsUrky5ydR/Sd7upxAQhyqiH1FfS6mVNk640b9UX9BmaBcmEDKxHIuHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0108
X-TM-SNTS-SMTP: F6FE067C814F3BE9499DFEAB8B8FD8498C29F44AB155FA5007CEA2965952F3C82000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3mNAmHJrFshtOV5lW7ilFE12I6E>
Subject: Re: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 01 Mar 2021 18:19:42 -0000

Dear Martin, Ingmar,



Sry, I had overlooked the first question from Martin, so my response to this is included in this email as well.





Currently we are caught in a chicken-and-egg situation. On the one hand there is the idea in 3GPP, that QUIC will solve the open gap related to non-TCP traffic support for splitting purposes. For now, one fully rely in 3GPP on the QUIC WG, that they will fulfill 3GPP ATSSS requirements. On the other hand, 3GPP has no other choice than that, because there is now adequate alternative provided by IETF. Having that understood makes the dilemma apparent, that an ATSSS with full IP coverage is fully dependent on a QUIC WG decision, where it is from today’s perspective not clear how this evolves. In a worst case, QUIC WG will never support the ATSSS use case and further have in mind here, that even within QUIC WG there are dependencies on multiple key technologies: Datagram support, MP support, possibly encapsulation support from MASQUE WG and last but not least interoperability amongst them has to be ensured (e.g. to bring split traffic in sequence again when MP and Datagram becomes combined). Also often forgotten is, when the QUIC WG was shaped, they never focused on supporting a non end-to-end use case like ATSSS. Consequently, and from my view legitimate, there are discussions now in QUIC WG, if ATSSS fits into the scope in general! QUIC is a swiss army knife for (future) transport and a lot of other aspects have to be considered, when the before mentioned key QUIC technologies will be developed. ATSSS is then just one use case among many others and that will probably end in long lasting discussions until we can expect final and/or mature interoperable I-Ds available for ATSSS.



There are quite a few operators who are interested to implement multi-connectivity and they found together more than one year ago in the GSMA Task Force “Zero-Touch-Connectivity” (ZTC). Within this group, the 3GPP ATSSS, Hybrid Access and ATSSS-Overlay – the latter resembles ATSSS but is independent from 3GPP - are discussed. In a setup with terminal and infrastructure vendors, first PoC/trial activities are already ongoing. A central requirement specified from operators within ZTC, is the support of any traffic including TCP, UDP,… - so generally speaking IP. The current situation with MPTCP solely defined in 3GPP Rel. 16 ATSSS, prevent operators from relying on ATSSS for that. That’s why MP-DCCP is currently discussed within the GSMA ZTC group to be pushed as an alternative to QUIC.



MP-DCCP as a lightweight solution, dedicated to support multipath transport for services without strict demand on reliability and in-order delivery, perfectly fits into the 3GPP ATSSS scope, but also in the 3GPP independent scope of Hybrid Access and ATSSS-Overlay. With the availability of a MP-DCCP open source reference implementation this week (separate announcement will follow) and given the (assumed) fact that MP-DCCP reaches some maturity by at least adopting it, allows an immediate integration of MP-DCCP in those 3GPP independent use cases. Expanding this again to the 3GPP ATSSS topic: A TSVWG adoption of MP-DCCP will allow 3GPP to consider MP-DCCP as an alternative to QUIC within the Rel. 18 time frame, which is probably an (last) acceptable timeline for operators. That would solve the chicken-and-egg problem I introduced in the beginning.



So please don’t underestimate the momentum of MP-DCCP, which I expect to get rapidly increasing when it becomes adopted and available as open source Linux Kernel implementation. First infrastructure vendors like Casa Systems have already expressed their strong interest on the mailinglist this week and BT started with the current available draft to contribute directly. I’m confident from the discussion where I was involved so far, that others will follow soon.



Personally, I expect an early usage of MP-DCCP in the Hybrid Access scenario, because CPE and Hybrid Access Gateway are fully located in the operator domain, before we see it in ATSSS like use cases.





… and please don’t assume that I’m against a QUIC based solution, which I can state in good conscience as a co-author of https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00. The main concern is from my view an unpredictable time it needs, to get ATSSS or similar concepts flying based on QUIC, for the above outlined reasons.





Br



Markus



From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Sent: Montag, 1. März 2021 13:53
To: Martin Duke <martin.h.duke@gmail.com>om>; Amend, Markus <Markus.Amend@telekom.de>
Cc: draft-amend-tsvwg-multipath-dccp@ietf.org; tsvwg <tsvwg@ietf.org>rg>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: RE: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt



Hi



+1

I am also curious to know more about the relation to 3GPP.



In addition, I have not followed QUIC as much as I would have liked but I understand that MP-QUIC is supported by at least a few individuals and there is work to enable unreliable datagram transmission in QUIC. And… given that QUIC seems to have more momentum than DCCP, I would believe that it would be easier to make MP-QUIC happen than MP-DCCP ?.



Regards

/Ingemar



From: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> On Behalf Of Martin Duke
Sent: den 27 februari 2021 00:13
To: Markus.Amend <Markus.Amend@telekom.de<mailto:Markus.Amend@telekom.de>>
Cc: draft-amend-tsvwg-multipath-dccp@ietf.org<mailto:draft-amend-tsvwg-multipath-dccp@ietf.org>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: Re: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt



Hi Markus,



Has 3GPP expressed interest in MP-DCCP for this purpose, or is it one possible solution for ATSSS problems? I don't recall a liaison statement from 3GPP asking for this work.



On Fri, Feb 26, 2021 at 2:02 AM <Markus.Amend@telekom.de<mailto:Markus.Amend@telekom.de>> wrote:

   Dear all,

   As you probably have already seen, we, the authors, updated the MP-DCCP draft significantly. MP-DCCP as protocol for providing multipath transport for latency sensitive services and/or services with no or less demand on reliable delivery and optional adjustable re-ordering. Combined with the framework from https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-framework-mpdccp/ it can even provide multi-path transport for UDP or IP traffic and becomes therefore appealing for Hybrid Access and 3GPP ATSSS like scenarios.

   Compared to the last version, BT joined as contributor and we changed/revised a lot of text and filled up formerly empty sections. We further continued to specify relevant MP options like MP_ADDADDR, MP_REMOVEADDR and MP_PRIO as important measures for basic multipath functionality. Another relevant section we elaborated on was the security considerations. In a simplification step we also changed from former XML to Markdown I-D generation, which lowers the barrier for new contributors, see https://github.com/markusa/ietf-multipath-dccp<https://protect2.fireeye.com/v1/url?k=a80816db-f7932fba-a8085640-86d8a30ca42b-deaf4b0f32c663a8&q=1&e=218aab61-02b9-4448-a738-3278c8b2e3ce&u=https%3A%2F%2Fgithub.com%2Fmarkusa%2Fietf-multipath-dccp>multipath-dccp>.

   When we announced last IETF, that we have MP-DCCP implementations for Android smartphones available and that we consider to open source MP-DCCP, we are now taking action. Probably next week, we start to publish MP-DCCP as a Linux reference implementation, enhancing the existing DCCP implementation from the Linux Kernel with the new multipath functionality. That will allow any interested person/party to verify, contribute and modify. A website giving guidance will be setup along with the publication of the source code - but maybe after IETF 110. Some video material is currently under production, demonstrating a Skype call over commercial access networks using our MP-DCCP Android prototype smartphones. As soon as the video is available I will share this with you.

   After last IETF 109 request for adoption, an interesting discussion on the mailinglist started, from which I believe that we have to further elaborate on the MP-DCCP use case. Is the main use case ATSSS and Hybrid Access, which require UDP/IP into DCCP encapsulation, or are there other use cases seen which for example let native DCCP applications profit from a multipath extension? While the authors are mainly coming from the first scenario, a driver for the latter might be the https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/, which prevents middlebox issues by converting DCCP to UDP and vice versa overhead-free.
   When we have more ideas based on your feedback, we will carefully consider the structure of our available drafts. Currently the drafts are structured in a way, that they de-couple the MP-DCCP and the encapsulation framework (https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-framework-mpdccp/). While we were now focused on updating the MP-DCCP draft only, we will then update in the future the framework and converter draft as well.

   We, the authors, are happy to get your feedback.

   Br

   Markus et al.

   > -----Original Message-----
   > From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
   > Sent: Montag, 22. Februar 2021 18:42
   > To: Andreas Kassler <andreas.kassler@kau.se<mailto:andreas.kassler@kau.se>>; Anna Brunstrom
   > <anna.brunstrom@kau.se<mailto:anna.brunstrom@kau.se>>; von Hugo, Dirk <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>>; von
   > Hugo, Dirk <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>>; Amend, Markus
   > <Markus.Amend@telekom.de<mailto:Markus.Amend@telekom.de>>; Amend, Markus <Markus.Amend@telekom.de<mailto:Markus.Amend@telekom.de>>;
   > Stephen Johnson <stephen.h.johnson@bt.com<mailto:stephen.h.johnson@bt.com>>; Veselin Rakocevic
   > <veselin.rakocevic.1@city.ac.uk<mailto:veselin.rakocevic.1@city.ac.uk>>
   > Subject: New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt
   >
   >
   > A new version of I-D, draft-amend-tsvwg-multipath-dccp-04.txt
   > has been successfully submitted by Markus Amend and posted to the
   > IETF repository.
   >
   > Name:         draft-amend-tsvwg-multipath-dccp
   > Revision:     04
   > Title:                DCCP Extensions for Multipath Operation with Multiple
   > Addresses
   > Document date:        2021-02-22
   > Group:                Individual Submission
   > Pages:                25
   > URL:            https://www.ietf.org/archive/id/draft-amend-tsvwg-multipath-dccp-
   > 04.txt
   > Status:         https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-dccp/
   > Html:           https://www.ietf.org/archive/id/draft-amend-tsvwg-multipath-dccp-
   > 04.html
   > Htmlized:       https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp-04
   > Diff:           https://www.ietf.org/rfcdiff?url2=draft-amend-tsvwg-multipath-dccp-
   > 04
   >
   > Abstract:
   >    DCCP communication is currently restricted to a single path per
   >    connection, yet multiple paths often exist between peers.  The
   >    simultaneous use of these multiple paths for a DCCP session could
   >    improve resource usage within the network and, thus, improve user
   >    experience through higher throughput and improved resilience to
   >    network failures.
   >
   >    This document presents a set of extensions to traditional DCCP to
   >    support multipath operation.  Multipath DCCP provides the ability to
   >    simultaneously use multiple paths between peers.  The protocol offers
   >    the same type of service to applications as DCCP and it provides the
   >    components necessary to establish and use multiple DCCP flows across
   >    potentially disjoint paths.
   >
   >
   >
   >
   > Please note that it may take a couple of minutes from the time of submission
   > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
   >
   > The IETF Secretariat
   >