Re: [tsvwg] I-D Action: draft-ietf-tsvwg-multipath-dccp-02.txt

[[e-mail]]

Dear all,

it just took us another 15 days to provide again a significant update of the MP-DCCP draft and publish version -02. Two changes I want to emphasize here. 

The first is around the MP_PRIO option which provides now a much more fine granular steering of path priorities, standby paths and disabled paths,
see https://github.com/markusa/ietf-multipath-dccp/pull/34. Especially for Hybrid Access or ATSSS this nicely allows to use in-built functionalities of MP-DCCP to change between Steering, Swiching and Splitting mode and goes far beyond the MP_PRIO definiton of MPTCP. In case there are more ideas on how the MP_PRIO option can be usefully extended, let us know.

The second topic is a more complicated one which requires a strong dicsussion about pros and cons of different MP handshaking strategies. In https://datatracker.ietf.org/meeting/112/materials/slides-112-tsvwg-sessb-71-multipath-dccp-00 we outline the different handshaking procedures we would like to discuss with you. On slide 4, the initial approach, which was previously part of the MP-DCCP draft and is still part of the Open Source implementation, is depicted. It selects a first flow to establish a MP-DCCP connection which is completed after the final DCCP-ACK has arrived at Host B and ensures that all KEY material has been exchanged for secure establishment of subsequent flows. After that, Host B is prepared to accept a flow establishment over a second path - MP_JOIN procedure. The problem arise, when the MP_JOIN arrives before the final DCCP-ACK of the initial flow. At this point a subsequent flow cannot be joined to a MP-DCCP connection because this one is not established at this point. In the Open Source implementation we therefore consequently reply with a DCCP-Reset to the MP_JOIN and its then on the sender path manager to give it another try or - worst case - to give it up.
To solve this issue we defined in the -02 draft a handshake procedure (slide 4, right diagramm) extending the initital approach with a further ACK provided from Host B to Host A - 4 way handshake. This has the benefit, that the initial flow and therefore the MP-connection is definitly established and it is safe to join subsequent flows. After completing the 4-way handshake, the MP_JOIN process can be safely triggered. It is a simple solution, but adds delay and a further dependency to get all messages exchanged successfully. For that reason we are not fully convinced from this solution and we wonder if we can optimize the handshaking procedure as proposed in slide 5.
Starting on the left diagram, this proposes a slight modification of the initial approach with the 3-way handshake, however the check during the establishment of a subsequent flow is shifted from receiving the first MP_JOIN to the time, where the corresponding DCCP-ACK is received 1 RTT later. Having this additional time increase the odds that the initial flow has established in the meantime. This approach works as long as the delay difference between the paths is not too high, otherwise it falls into the same issue as described already for the initial 3-way procedure.
The diagram on the right is what we understand as the optimal approach to have the shortest possible establishment times for subsequent flows and moreover remove any dependency on the initial flow after the Key material has been exchanged. Effectively we still rely on the initial 3-way procedure as depicted in slide 4 left, and trigger the MP_JOIN process after receiving the DCCP-Repsonse with the Key-B sent from Host B. The change is now on implementation side. Instead of creating all the MP strcutures in the OS after the initial flow has been successfully established, the MP structures will already be created with the reception of the DCCP-Request. That has the benefit, that a subsequent flow establishment can continue even if the DCCP-Ack from the intitial flows has not been received and moreover even establish the whole MP connection if the DCCP-Ack from the initial flow fails. The authors wonder if this optimized approach raise security flaws, even if they are convinced that the security level remains unchanged by the proposed modification. Another problem that the authors can imagine could arise from the early creation of MP structures with regard to DoS attacks.


It's important for us to get your feedback on the new proposed handshaking procedures (slide 5) and to reach consenus on this very fundamental and basic topic of MP-DCCP connection establishment procedure.

Thanks & Br

Markus


> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of [e-mail]
> Sent: Dienstag, 9. November 2021 16:58
> To: [e-mail]
> Cc: [e-mail]
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-multipath-dccp-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
> 
>         Title           : DCCP Extensions for Multipath Operation with Multiple Addresses
>         Authors         : Markus Amend
>                           Anna Brunstrom
>                           Andreas Kassler
>                           Veselin Rakocevic
>                           Stephen Johnson
> 	Filename        : draft-ietf-tsvwg-multipath-dccp-02.txt
> 	Pages           : 32
> 	Date            : 2021-11-09
> 
> 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.  Use cases for a Multipath DCCP (MP-DCCP) are
>    mobile devices (handsets, vehicles) and residential home gateways
>    simultaneously connected to distinct paths as, e.g., a cellular link
>    and a WiFi link or to a mobile radio station and a fixed access
>    network.  Compared to existing multipath protocols such as MPTCP, MP-
>    DCCP provides specific support for non-TCP user traffic as UDP or
>    plain IP.  More details on potential use cases are provided in
>    [website], [slide], and [paper].  All these use cases profit from an
>    Open Source Linux reference implementation provided under [website].
> 
>    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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-multipath-dccp-02.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-multipath-dccp-02
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>