Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"

"Holland, Jake" <jholland@akamai.com> Tue, 15 June 2021 17:37 UTC

Return-Path: <jholland@akamai.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 E2E483A3797; Tue, 15 Jun 2021 10:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 x6v0E_3s8g9t; Tue, 15 Jun 2021 10:37:05 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF20B3A3795; Tue, 15 Jun 2021 10:37:04 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 15FHZNvG008058; Tue, 15 Jun 2021 18:36:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=jrCYevG58gA97EP8ScI5K6WwpCvLMO1H67BGNIhcajQ=; b=TxM2IEWpJEx3Z45/mjeReMW4KesAqo5gp6HWtgOf3CblaLF3IESYRelImEP8hR4C+sXJ JVAwXZ7WLAv4xWXTOztHS24eEsGlmXew+oyXeHW7MP0By7IO9O9XR8zOM9dT4S9MuDKq DATFzkgQhi0GREqj1dQLdQzJ+HRc6g4QMSQs5cyrjuOU4GY8Erg9pGDn3q3IDqz9sITS yOpRt5CJUtajbSb8CqciCPAQt6pQ/aYTMgQfjYVxiso3+7AFr8p58OhibykuEj2wL9+G ObyqfMC3uI4gSpg9uFFFKPzkr7m4TZIk4k69OAG98AnBjZtmSksgxzhJlBZRv6FFlYUo dQ==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 396yfatk9j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Jun 2021 18:36:52 +0100
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 15FHXbfn006465; Tue, 15 Jun 2021 13:36:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 396c1ft9xc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Jun 2021 13:36:51 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 15 Jun 2021 12:36:50 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1497.018; Tue, 15 Jun 2021 12:36:50 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Liaison Statement Management Tool <statements@ietf.org>, David Black <david.black@dell.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Wesley Eddy <wes@mti-systems.com>
CC: David Pollington <GSMALiaisons@gsma.com>, "Transport Area Working Group Discussion List" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
Thread-Index: AQHXS0ep5Yjopr9F3EOuPZYpUWrBHasVYfOA
Date: Tue, 15 Jun 2021 17:36:50 +0000
Message-ID: <12030134-E2F9-4621-9F26-A7139E2D784F@akamai.com>
References: <162127490513.10263.5800886336891576953@ietfa.amsl.com>
In-Reply-To: <162127490513.10263.5800886336891576953@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.49.21050901
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <ED0B37DA24109549825417A9AFE37CFB@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-15_07:2021-06-15, 2021-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 adultscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106150109
X-Proofpoint-GUID: 4SyJwzNkLJ-lnjkGkjJRfpEh9NXwMwLF
X-Proofpoint-ORIG-GUID: 4SyJwzNkLJ-lnjkGkjJRfpEh9NXwMwLF
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-15_07:2021-06-15, 2021-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 mlxscore=0 malwarescore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106150109
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=jholland@akamai.com smtp.helo=prod-mail-ppoint8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jXTZHxKb2c3LrJHpatVRtrfPWaQ>
Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
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: Tue, 15 Jun 2021 17:37:10 -0000

Hi David,

I'm confused.  Please forgive me if it's a dumb question, but
could you elaborate on the use case?

In particular, how would MP-DCCP help with QUIC?  Wouldn't multipath
QUIC be a better thing to ask about if the goal is to address the
QUIC traffic mix that MP-TCP won't address?
https://multipath-quic.org/

(It occurred to me that maybe the idea is to tunnel the QUIC over
DCCP so that MP-DCCP can take care of the multipath part, but then
I was still confused as to why that would be preferred to e.g. SR?)

Best regards,
Jake

[EOM. original message included below for context]



On 05-17, 11:08 AM, "Liaison Statement Management Tool" <statements@ietf.org> wrote:

Title: LS to IETF TSVWG on MP-DCCP
Submission Date: 2021-05-17
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1741/ 

From: David Pollington <GSMALiaisons@gsma.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>,David Black <david.black@dell.com>,Wesley Eddy <wes@mti-systems.com>
Cc: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>,Martin Duke <martin.h.duke@gmail.com>,Transport Area Working Group Discussion List <tsvwg@ietf.org>,Wesley Eddy <wes@mti-systems.com>,Gorry Fairhurst <gorry@erg.abdn.ac.uk>,David Black <david.black@dell.com>
Response Contacts: David Pollington <GSMALiaisons@gsma.com>
Technical Contacts: 
Purpose: For information

Body: 1. Background

The GSMA Zero Touch Connectivity (ZTC) taskforce is working on a number of propositions with a strong focus on operator provided multi-connectivity solutions for residential (Hybrid Access) and mobile customer usage based on 3GPP ATSSS, TS23.501 as well as alternative ‘ATSSS’ Overlay solutions independent of the 5G Core.

The operators engaged in GSMA ZTC consider MP-TCP (RFC8684; RFC8803) to be very beneficial based on the results from a number of ZTC trials. However, with the increasing share of QUIC in the overall traffic mix, a solution based solely on MP-TCP becomes a limiting factor and precludes delivery of a comprehensive customer proposition. 

For that reason, the GSMA ZTC taskforce has identified the multipath extension of DCCP (MP-DCCP) as a suitable network protocol for addressing this shortfall. MP-DCCP is an interesting candidate approach for the multipath transport of latency sensitive services and/or services with no or little demand on reliable delivery and also supports adjustable re-ordering.

The GSMA ZTC taskforce see MP-DCCP as an interesting solution to support multipath delivery of most traffic types in both residential broadband and cellular (3GPP) solutions. Available prototypes based on open source code from https://multipath-dccp.org/ have already shown an ability to provide Steering, Switching and Splitting.

Having formal support for MP-DCCP within IETF at the working group level would facilitate adoption in other standards bodies and vendor solutions and ensure a timely and satisfying solution for operator provided multi-connectivity services.

2. Request to IETF TSVWG
The GSMA ZTC taskforce kindly requests IETF TSVWG to adopt:
https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-dccp/
for standard track as a complement to MP-TCP to meet Operator needs for multipath support.
Along with this, GSMA ZTC would like to request that you continue work on:
https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-framework-mpdccp/
https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/ 

3. Contact
In the case of further questions and/or feedback to actions requested in the present document these can be directed to David Pollington, GSMA ZTC taskforce lead or Markus Amend, ZTC technical lead at DT [Markus.Amend@telekom.de].
Attachments:

    ZTC_LS_01%20-%20GSMA%20ZTC%20LS%20to%20IETF%20TSVWG
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-05-17-gsma-ztc-tsvwg-ls-to-ietf-tsvwg-on-mp-dccp-attachment-1.docx