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

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 1 Mar 2021 12:53:05 +0000

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 <[email-masked]> On Behalf Of Martin Duke
Sent: den 27 februari 2021 00:13
To: Markus.Amend <[email-masked]>
Cc: [email-masked]; tsvwg <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > 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> .

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: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >
> Sent: Montag, 22. Februar 2021 18:42
> To: Andreas Kassler <[email-masked] <mailto:[email-masked]> >; Anna Brunstrom
> <[email-masked] <mailto:[email-masked]> >; von Hugo, Dirk <[email-masked] <mailto:[email-masked]> >; von
> Hugo, Dirk <[email-masked] <mailto:[email-masked]> >; Amend, Markus
> <[email-masked] <mailto:[email-masked]> >; Amend, Markus <[email-masked] <mailto:[email-masked]> >;
> Stephen Johnson <[email-masked] <mailto:[email-masked]> >; Veselin Rakocevic
> <[email-masked] <mailto:[email-masked]> >
> 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
>

---

From: <[email-masked]>
Date: Mon, 1 Mar 2021 18:19:32 +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 <[email-masked]>
Sent: Montag, 1. März 2021 13:53
To: Martin Duke <[email-masked]>; Amend, Markus <[email-masked]>
Cc: [email-masked]; tsvwg <[email-masked]>; Ingemar Johansson S <[email-masked]>
Subject: RE: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt

Hi

+1

Regards

/Ingemar

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

Hi Markus,

On Fri, Feb 26, 2021 at 2:02 AM <[email-masked]<mailto:[email-masked]>> wrote:

   Dear all,

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

   Br

   Markus et al.

   > From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
   > To: Andreas Kassler <[email-masked]<mailto:[email-masked]>>; Anna Brunstrom
   > <[email-masked]<mailto:[email-masked]>>; von Hugo, Dirk <[email-masked]<mailto:[email-masked]>>; von
   > Hugo, Dirk <[email-masked]<mailto:[email-masked]>>; Amend, Markus
   > <[email-masked]<mailto:[email-masked]>>; Amend, Markus <[email-masked]<mailto:[email-masked]>>;
   > Stephen Johnson <[email-masked]<mailto:[email-masked]>>; Veselin Rakocevic
   > <[email-masked]<mailto:[email-masked]>>
   > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
   >
   > The IETF Secretariat
   >

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 4 Mar 2021 06:51:10 +0000

OK, thanks for the update Markus. 

I am not too updated on ATSSS. Furthermore I follow QUIC mainly from the bench. So I am not in the position to question work items here, see my comments mainly as questions and concerns. 

One possible issue I see with MP-DCCP is that it can potentially experience a similar set of roadblocks (alternatively push back) in TSVWG as your efforts to add support for ATSSS in MP-QUIC has experienced. 

I am not really against MP-DCCP, it is just that there is work on MP-QUIC ongoing and from a 10000m view it appeared to me as double standards work addressing very similar problem statements.

/Ingemar 

From: [email-masked] <[email-masked]> 
Sent: den 1 mars 2021 19:20
To: Ingemar Johansson S <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt

Dear Martin, Ingmar,

 

 

 

Br

Markus 

From: Ingemar Johansson S <[email-masked] <mailto:[email-masked]> > 
Sent: Montag, 1. März 2021 13:53
To: Martin Duke <[email-masked] <mailto:[email-masked]> >; Amend, Markus <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; tsvwg <[email-masked] <mailto:[email-masked]> >; Ingemar Johansson S <[email-masked] <mailto:[email-masked]> >
Subject: RE: [tsvwg] New Version Notification for draft-amend-tsvwg-multipath-dccp-04.txt

Hi

+1

Regards

/Ingemar

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

Hi Markus,

Dear all,

Br

Markus et al.