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

[Ingemar Johansson S <[e-mail]>]

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 <[e-mail]> On Behalf Of Martin Duke
Sent: den 27 februari 2021 00:13
To: Markus.Amend <[e-mail]>
Cc: [e-mail]; tsvwg <[e-mail]>
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 <[e-mail] <mailto:[e-mail]> > 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: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
> Sent: Montag, 22. Februar 2021 18:42
> To: Andreas Kassler <[e-mail] <mailto:[e-mail]> >; Anna Brunstrom
> <[e-mail] <mailto:[e-mail]> >; von Hugo, Dirk <[e-mail] <mailto:[e-mail]> >; von
> Hugo, Dirk <[e-mail] <mailto:[e-mail]> >; Amend, Markus
> <[e-mail] <mailto:[e-mail]> >; Amend, Markus <[e-mail] <mailto:[e-mail]> >;
> Stephen Johnson <[e-mail] <mailto:[e-mail]> >; Veselin Rakocevic
> <[e-mail] <mailto:[e-mail]> >
> 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
>