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

Gorry Fairhurst <> Wed, 16 June 2021 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB383A077E for <>; Wed, 16 Jun 2021 01:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7z15E9weGKm9 for <>; Wed, 16 Jun 2021 01:20:02 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id 52C463A076F for <>; Wed, 16 Jun 2021 01:20:02 -0700 (PDT)
Received: from GF-MBP-2.lan ( []) by (Postfix) with ESMTPSA id AEDE41B0025B; Wed, 16 Jun 2021 09:19:54 +0100 (BST)
To: "Holland, Jake" <>, David Black <>, Wesley Eddy <>
Cc: David Pollington <>, Transport Area Working Group Discussion List <>
References: <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Wed, 16 Jun 2021 09:19:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Jun 2021 08:20:07 -0000

The response I provided to GSMA was that 
draft-amend-tsvwg-multipath-dccp would be discussed on the list and at 
the next IETF Meeting (111).

I affirm that work on this topic would fall within TSVWG, but that any 
adoption call would need to be considered by the IETF WG Process. Input 
to any decision will include whether the list discussion shows interest 
in developing specifications, who would implement and deploy, and what 
is needed to reach a common specifcation. That would be good to discuss 

TSVWG has no plan to work on MP-QUIC; although if progressed, we see 
that an experimental method for DCCP might also prove helpful in 
informing discussions within the QUIC WG. We will continue to liaise 
with the QUIC WG Chairs.

In short, it would be great to discuss the use-case on list!


On 15/06/2021 18:36, Holland, Jake wrote:
> 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?
> (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" <> wrote:
> Title: LS to IETF TSVWG on MP-DCCP
> Submission Date: 2021-05-17
> URL of the IETF Web page:
> From: David Pollington <>
> To: Gorry Fairhurst <>,David Black <>,Wesley Eddy <>
> Cc: Zaheduzzaman Sarker <>,Martin Duke <>,Transport Area Working Group Discussion List <>,Wesley Eddy <>,Gorry Fairhurst <>,David Black <>
> Response Contacts: David Pollington <>
> 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 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:
> 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:
> 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 [].
> Attachments:
>      ZTC_LS_01%20-%20GSMA%20ZTC%20LS%20to%20IETF%20TSVWG