DCCP Extensions for Multipath Operation with Multiple Addresses
draft-amend-tsvwg-multipath-dccp-02

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

Multipath DCCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional DCCP to support multipath operation. 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 9, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Multipath DCCP in the Networking Stack
• 1.2. Terminology
• 1.3. MP-DCCP Concept
• 1.4. Differences from Multipath TCP
• 1.5. Requirements Language
• 2. Operation Overview
• 3. MP-DCCP Protocol
• 4. Security Considerations
• 5. Interactions with Middleboxes
• 6. Acknowledgments
• 7. IANA Considerations
• 8. Informative References
• Authors' Addresses

1. Introduction

Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP [RFC4340], which enables a transport connection to operate across multiple paths simultaneously. DCCP multipath operations is suggested in the context of ongoing 3GPP work on 5G multi-access solutions [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid access networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.muley-network-based-bonding-hybrid-access]. It can be applied for load-balancing, seamless session handover and aggregation purposes (referred to as steering, switching and splitting in 3GPP terminology [TR23.793]).

This document presents the protocol changes required to add multipath capability to DCCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions.

1.1. Multipath DCCP in the Networking Stack

MP-DCCP operates at the transport layer and aims to be transparent to both higher and lower layers. It is a set of additional features on top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is designed to be used by applications in the same way as DCCP with no changes.

                             +-------------------------------+
                             |           Application         |
+---------------+            +-------------------------------+
|  Application  |            |            MP-DCCP            |
+---------------+            + - - - - - - - + - - - - - - - +
|      DCCP     |            |Subflow (DCCP) |Subflow (DCCP) |
+---------------+            +-------------------------------+
|      IP       |            |       IP      |      IP       |
+---------------+            +-------------------------------+

Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks

1.2. Terminology

[Tbd], could be similar to [RFC6824]

1.3. MP-DCCP Concept

           Host A                               Host B
------------------------             ------------------------
Address A1    Address A2             Address B1    Address B2
----------    ----------             ----------    ----------
  |             |                      |             |
  |         (DCCP flow setup)          |             |
  |----------------------------------->|             |
  |<-----------------------------------|             |
  |             |                      |             |
  |             |  (DCCP flow setup)   |             |
  |             |--------------------->|             |
  |             |<---------------------|             |
  | merge individual DCCP flows to one multipath connection
  |             |                      |             |

Figure 2: Example MP-DCCP Usage Scenario

1.4. Differences from Multipath TCP

Multipath DCCP is similar to Multipath TCP [RFC6824], in that it extends the related basic DCCP transport protocol [RFC4340] with multipath capabilities in the same way as Multipath TCP extends TCP [RFC0793]. However, mainly dominated by the basic protocols TCP and DCPP, the transport characteristics are different.

Table 1 compares the protocol characteristics of TCP and DCCP, which are by nature inherited by their respective multipath extensions. A major difference lies in the delivery of payload, which is for TCP an exact copy of the generated byte-stream. DCCP behaves contrary and does not guarantee to transmit any payload nor the order of delivery. Since this is mainly affecting the receiving endpoint of a TCP or DCCP communication, many similarities on sender side can be stated. Both transport protocols share the 3-way initiation of a communication and both exploit a congestion control to adapt to path characteristics.

Consequently, the multipath features, shown in Table 2, are the same, supporting volatile paths, session handover and path aggregation capabilities. All of them profit by the existence of congestion control.

Therefore the sender logic is not much different between MP-DCCP and MPTCP, even if the multipath session initiation differs. MP-DCCP inherits a robust session establishment feature, which guarantees communication establishment if at least one functional path is available. MP-TCP relies on an initial path, which has to work; otherwise no communication can be established.

The receiver side for MP-DCCP has to deal with the unreliable transport character of DCCP and a possible re-assembly of the data stream. In practice, it is assumed that some sort of re-assembly has to be applied, even if DCCP and the order of delivery is unreliable by nature. Such re-assembly mechanisms have to account for the fact that packet loss may occur for any of the DCCP subflows. Another issue is the packet reordering introduced when a DCCP communication is split across paths with disjoint latencies. In theory, applications using DCCP certainly have to deal with packet reordering, since DCCP has no mechanisms to prevent it. However, in practice, without any multipath extension, packet reordering can be assumed to be very limited. Therefore most services on top of DCCP are not expecting massive packet reordering and degrades their performance if it happens anyway.

The receiving process for MP-TCP is on the other hand a simple "just wait" approach, since TCP guarantees reliable delivery.

1.5. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Operation Overview

[Tbd], could be similar to [RFC6824]

3. MP-DCCP Protocol

[Tbd], could be similar to [RFC6824]

[Tbd] On top it requires particular considerations for:

• The minimum PMTU of the individual paths must be selected to announce to the application. Changes of individual path PMTUs must be re-announced to the application if they are lower than the current announced PMTU.
• Overall sequencing for optional reassembly procedure
• Congestion control
• Robust MP-DCCP session establishment (no dependency on an initial path setup)

4. Security Considerations

[Tbd]

5. Interactions with Middleboxes

[Tbd], should mention standardized technologies like [RFC5597] or [RFC6773] and U-DCCP [I-D.amend-tsvwg-dccp-udp-header-conversion]

6. Acknowledgments

1. Notes

This document is inspired by Multipath TCP [RFC6824] and some text passages for the -00 version of the draft are copied almost unmodified.

7. IANA Considerations

[Tbd], must include options for:

• handshaking procedure to indicate MP support
• handshaking procedure to indicate JOINING of an existing MP connection
• signaling of new or changed addresses
• setting handover or aggregation mode
• setting reordering on/off

should include options carrying:

• overall sequence number for restoring purposes
• sender time measurements for restoring purposes
• scheduler preferences
• reordering preferences

8. Informative References

Authors' Addresses