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

From: "Holland, Jake" <[email-masked]>
Date: Tue, 15 Jun 2021 17:36:50 +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" <[email-masked]> 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 <[email-masked]>
To: Gorry Fairhurst <[email-masked]>,David Black <[email-masked]>,Wesley Eddy <[email-masked]>
Cc: Zaheduzzaman Sarker <[email-masked]>,Martin Duke <[email-masked]>,Transport Area Working Group Discussion List <[email-masked]>,Wesley Eddy <[email-masked]>,Gorry Fairhurst <[email-masked]>,David Black <[email-masked]>
Response Contacts: David Pollington <[email-masked]>
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 [[email-masked]].
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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 16 Jun 2021 09:19:53 +0100

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 
on-list.

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!

Gorry

---

From: <[email-masked]>
Date: Thu, 17 Jun 2021 11:35:40 +0000

Hi Jake,

please allow me to jump into this dicsussion as one of the MP-DCCP draft authors.

The LS is adressing the ATSSS use case specified in 3GPP Rel. 16, which defines multi-connectivity between terminal and operator over 5G and Wi-Fi (mobil use case) or 5G and fixed access (Hybrid Access use case). A visual representation of both use cases and how MP-DCCP can be engaged there can be found under https://multipath-dccp.org/intro.html.

So far ATSSS specifies MPTCP only to enable the multipath split for TCP related services. UDP services are not covered, which is seen as an issue with the ongoing and upcoming deployments of QUIC on top of UDP.

MP-DCCP is a 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. These characteristics help us to provide multipath transport for UDP services, including QUIC, when they are encapsulated into a MP-DCCP connection between terminal and operator.

Br

Markus

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Holland, Jake
> Sent: Dienstag, 15. Juni 2021 19:37
> To: Liaison Statement Management Tool <[email-masked]>; David Black
> <[email-masked]>; Gorry Fairhurst <[email-masked]>; Wesley Eddy
> <[email-masked]>
> Cc: David Pollington <[email-masked]>; Transport Area Working Group
> Discussion List <[email-masked]>
> Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
> 
> Hi David,
> 
> To: Gorry Fairhurst <[email-masked]>,David Black
> <[email-masked]>,Wesley Eddy <[email-masked]>
> Cc: Zaheduzzaman Sarker <[email-masked]>,Martin Duke
> <[email-masked]>,Transport Area Working Group Discussion List
> <[email-masked]>,Wesley Eddy <[email-masked]>,Gorry Fairhurst
> <[email-masked]>,David Black <[email-masked]>
> 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
> 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
> [[email-masked]].
> Attachments:
> 
>     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
> 
>

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 18 Jun 2021 15:22:54 +0000

Hi Markus,

Thanks.  I think those diagrams are helpful.
https://multipath-dccp.org/intro.html
It looks like the idea is to wrap generic UDP traffic in a
multipath-capable tunnel at the OS level.

That makes sense, and it looks like maybe ease of implementation
on the client devices is among the reasons to prefer it to other
kinds of tunnels, if I'm understanding it.  That seems like a fine
reason.  Thanks for clearing that up.

Best,
Jake

---

From: Anna Brunström <[email-masked]>
Date: Wed, 23 Jun 2021 15:24:35 +0000

> Sent: den 18 juni 2021 17:23
> To: [email-masked]; jholland=[email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> It looks like the idea is to wrap generic UDP traffic in a multipath-capable
> tunnel at the OS level.
>
> That makes sense, and it looks like maybe ease of implementation on the
> client devices is among the reasons to prefer it to other kinds of tunnels, if
> I'm understanding it.  That seems like a fine reason.  Thanks for clearing that
> up.

I think you are correct here Jake, that MP-DCCP is quite light weight is a benefit. You also have the congestion control state, with RTT estimates etc., that can be used as input for scheduling and path management. This of course is a main benefit shared with other transport layer solutions.

Best Regards,
Anna

> Jake

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>.

---

From: <[email-masked]>
Date: Mon, 28 Jun 2021 16:35:55 +0000

Hi Anna, all,

Thanks for raising this important point, why DCCP is a good choice for multipath support especially for non-TCP traffic.

I wonder if there are already testbed installation available which prove and verify MP-DCCP to be lightweight, as well as efficient due to access to path characteristic information (available bandwidth, RTT, ...)? Moreover, are there use cases in which you like to explore MP-DCCP?

For Deutsche Telekom I can reveal, that we have three testbed implementation using the open source Linux reference implementation from https://multipath-dccp.org. These testbeds are setup for PoC and trial activities with real devices and customers.

1. Provide Multipath in enterprise environment, converging Wi-Fi and 5G access.
Autonomous Guided Vehicles (AGV) is a first use case in this scenario, which verifies the resilience provided by MP-DCCP in a real industry environment. Integrated in the AGV and a MP-DCCP Proxy attached to a converged Wi-Fi6 and 5G SA core, builds the foundation of the testbed which is ready to be used in real customer PoCs. See also https://www.telekom.com/en/company/details/deutsche-telekom-demonstrates-multipath-for-fixed-mobile-convergence-on-campus-625838

2. Integrated in Google Pixel 4 devices as part of the OS (and controlled by the Android Network Manager) to verify its applicability towards 3GPP ATSSS. In this scenario, the MP-DCCP proxy is hosted in the public Internet and enables multipath transport between the phone and ANY Internet service. A video demonstrating this with a real Skype call can be found on the start page of https://multipath-dccp.org/. For the purpose of ATSSS, the GSMA ZTC taskforce identified MP-DCCP to be a solution, to close the open gap towards UDP support and therefore triggered the LS https://datatracker.ietf.org/liaison/1741/ towards TSVWG. DT provides all the members in the ZTC round access to their MP-DCCP testbed.

3. As part of internal residential gateway prototypes, MP-DCCP allows us to investigate its Hybrid Access capabilities according to BBF TR-470 on Wireless Wireline Convergence.

To all: I'm highly interested in your experience on MP-DCCP, details about existing testbeds and your potential plans with MP-DCCP. Please feel free to share your insights here...

Br

Markus

> From: Anna Brunström <[email-masked]>
> Sent: Mittwoch, 23. Juni 2021 17:25
> To: Holland, Jake <jholland=[email-masked]>; Amend, Markus
> <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
> 
> > From: tsvwg <mailto:[email-masked]> On Behalf Of Holland, Jake
> > To: mailto:[email-masked]; mailto:jholland=[email-masked];
> > mailto:[email-masked]; mailto:[email-masked]; mailto:[email-masked];
> > mailto:[email-masked]
> > Cc: mailto:[email-masked]; mailto:[email-masked]
> I think you are correct here Jake, that MP-DCCP is quite light weight is a benefit.
> You also have the congestion control state, with RTT estimates etc., that can be
> used as input for scheduling and path management. This of course is a main
> benefit shared with other transport layer solutions.
> 
> Best Regards,
> Anna
> 
> >
> > Best,
> > Jake
> >
> 
> När du skickar e-post till Karlstads universitet behandlar vi dina
> personuppgifter<https://www.kau.se/gdpr>.