Internet DRAFT - draft-aravind-mptcp-optimized-subflows
draft-aravind-mptcp-optimized-subflows
MPTCP Working Group Kesava. Krupakaran
Internet-Draft Aravind Prasad Sridharan
Intended Status: Informational Shathish Muthu Venkatesan
Expires: October 9, 2015 DELL
April 7, 2015
Optimized Multipath TCP subflows using Traceflow
draft-aravind-mptcp-optimized-subflows-00
Abstract
This document proposes a solution for optimized usage of MPTCP and
its subflows.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 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
(http://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
<Author> Expires October 9, 2015 [Page 1]
INTERNET DRAFT <Document Title> April 7, 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Issues existing currently in MP TCP . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Overall Protocol Operation . . . . . . . . . . . . . . . . . 3
3.1.1. Transmitting and receiving the TraceFlow frames . . . . 4
3.1.2 Interpreting the response frames . . . . . . . . . . . . 4
3.1.3. Generating topology between the source and the
destination . . . . . . . . . . . . . . . . . . . . . . 4
3.1.4. Detecting the number of sub-flows to be used . . . . . 4
3.1.5. Modifying the flow parameters . . . . . . . . . . . . . 5
3.2. Modifications to Traceflow protocol . . . . . . . . . . . 5
3.2.1. Flow Discovery Request packet . . . . . . . . . . . . . 5
3.2.2. Flow Discovery Request TLV . . . . . . . . . . . . . . 6
3.2.3. Flow Discovery Response TLV . . . . . . . . . . . . . . 7
4. Advantages of proposed solution . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Multipath TCP is a modified version of regular TCP that implements a
multipath transport service enabling a transport connection to
operate across multiple paths simultaneously and transparently to the
application.
1.1. Terminology
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 RFC 2119 [RFC2119].
<Author> Expires October 9, 2015 [Page 2]
INTERNET DRAFT <Document Title> April 7, 2015
2. Issues existing currently in MP TCP
The path management in MPTCP is a separate function from the packet
scheduling, subflow interface, and congestion control functions.
Currently, no efficient mechanisms exist to identify the exact set of
available multiple paths between any Source and Destination Hosts.
And due to the absence of any quantitative approach to identify the
exact set of multipaths existing between the hosts, the decision on
number of subflows to be used in MP TCP are taken arbitrarily. The
problem with this approach is that, the number of subflows chosen
could either be more than the actual existing number of multiple
paths in network (excessive overhead on MPTCP) or less than the
existing number of paths (under-utilization of available multiple
paths). Also, if the multiple paths may combine to same single path
for the most of the hops, the use of multiple sub flows may not be
efficient and could increase the computation costs and become
counterproductive.
One well known mechanism is to provide different address pairs at
source and destination hosts if they are multi-homed respectively so
that MP TCP can initiate the corresponding number of subflows. This
approach experiences the same set of problems discussed above and the
number of subflows may not map efficiently with the actual number of
multiple paths existing in the network between the hosts.
3. Proposed Solution
The basic idea is to determine the exact set of multiple paths
existing between the source and destination Hosts and make decision
on number of subflows based on it.
We propose to use a lighter and modified version of Traceflow
protocol ([I-D.janapath-intarea-traceflow]). It helps to determine
the path taken by a flow through a network and also capture all
relevant information at each hop of the network that pertains to the
flow. The complete explanation of modified version of Traceflow
protocol is provided in section 3.2.
3.1 Overall Protocol Operation
We would like to split the protocol operation into following steps
for better understanding:
1. Transmitting and receiving the TraceFlow frames
2. Interpreting the response frames
<Author> Expires October 9, 2015 [Page 3]
INTERNET DRAFT <Document Title> April 7, 2015
3. Generating topology between the source and the destination
4. Detecting the number of sub-flows to be used
5. Modifying the flow parameters
If the source has got multiple network interfaces to the destination,
all the above steps would be carried out on each of the network
interface individually.
3.1.1. Transmitting and receiving the TraceFlow frames
The source will first send a TraceFlow detection frame with special
MAC address. This frame will encapsulate the flow for which the path
has to be detected. Upon receiving this frame, the intermediate
switches/routers will read the flow parameters and determine all
possible egress ports (LAG or ECMP), LAG/ECMP hash logic to be used
to choose the egress port among all the egress ports, actual egress
port that will be chosen for the given flow and send back these
details (through the response frame explained above) to the sender.
3.1.2 Interpreting the response frames
When an intermediate device receives the TraceFlow request frame, it
will propagate it on all possible egress interfaces. If a LAG exists
with the next hop router/switch, then multiple copies of the
TraceFlow request frame would be sent to the same device. Hence, the
receiving device would now reply for each of the response packet
resulting in multiple replies being sent to the source. Therefore,
receiving multiple replies from an intermediate source implies that
multiple paths share a common network device. The same is applicable
when ECMP exists along the network path. On the other hand, if the
source receives only one reply frame from each of the intermediate
device, then it is inferable that only one unique path exists from
source to destination.
3.1.3. Generating topology between the source and the destination
Once the source receives the reply from all of the intermediate
devices and the destination, it computes the topology between the
source and the destination. The result of this computation provides
the possible paths (similar to linked-list of connected nodes)
existing between the source and the destination and the number of
common routers that multiple paths share.
3.1.4. Detecting the number of sub-flows to be used
<Author> Expires October 9, 2015 [Page 4]
INTERNET DRAFT <Document Title> April 7, 2015
The above steps gives us the set of paths that exist between the
source and destination. Then we set overlap of each of the path with
another paths in the set. If more than 50% of the devices overlap,
then we pick only one path between those two paths. After overlapping
and redundant path removal is done, this will result in the number of
reasonably unique paths that exist from source to destination. We
will use as many number of sub-flows as reasonably unique path in the
MP-TCP session.
3.1.5. Modifying the flow parameters
Even after initiating the required number of sub-flows, we cannot
guarantee that each of the sub-flow will choose the required unique
path as identified in the above step. This is where we make use of
ECMP/LAG hash logic used in the intermediate device. The objective of
this step is to tweak the sub-flow parameters in such a way (using
the hash login information received from intermediate devices) to
make sure that sub-flow passes through the required unique path as
determined in step (4).
3.2. Modifications to Traceflow protocol
We propose the following changes to Traceflow protocol:
1) Since, Traceflow packets are encapsulated with UDP, the Layer-2
switches may not able to identify and process them. Hence, we propose
to use a special MAC address for Traceflow packets instead of UDP
encapsulation.
2) Use of slightly modified version of the Flow Discovery Request
packet, Request and Response TLVs. Other additional TLVs specified in
Traceflow protocol may not be required.
The following packet would be sufficient for the protocol usage:
1) Flow Discovery Request packet
And the following TLVs will be used for carrying flow related info.
1) Flow Discovery Request TLV
2) Flow Discovery Response TLV
3.2.1. Flow Discovery Request packet
<Author> Expires October 9, 2015 [Page 5]
INTERNET DRAFT <Document Title> April 7, 2015
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hopcount | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Query ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: The version number of the protocol. This document defines
protocol version 1.
Hopcount: Allows keeping track of the number of transit nodes that
processed the Flow Discovery Request packet. This field is
decremented at each device that processes the Flow Discovery Request
packet. This field also helps in determining if there were any legacy
devices not supporting TraceFlow protocol along the way.
Length: Length of the packet
Type: 1 Flow Discovery Request
2 Response for the Flow Discovery Request
Query ID: A unique identifier generated by the originator that allows
it to co-relate the responses from the transit nodes with the Flow
Discovery Request packet generated.
3.2.2. Flow Discovery Request TLV
This TLV is included in the Flow Discovery Request packet and
identifies the traffic flow that the originator device is interested
in probing. This is a mandatory TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Information | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the TLV. In this case, the value is 1 meaning Flow
<Author> Expires October 9, 2015 [Page 6]
INTERNET DRAFT <Document Title> April 7, 2015
Descriptor TLV
Code: The Code identifies the sub-type of the TLV. In this case, this
field is not defined. It SHOULD be set to 0.
Length: The length of the TLV
Flow information : This specifies the flow. For example, incase of
TCP/IP network, this is src IP, dest IP, src port, dest port.
Padding: This might be necessary to ensure the packet ends on a word
boundary.
3.2.3. Flow Discovery Response TLV
This TLV is used by the devices processing the Flow Discovery Request
packet to provide the information requested by the originator device.
This is a mandatory TLV. It should be included in the response sent
to the device originating the Flow Discovery Request packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 Response for the Flow Discovery Request
Code: 1 Interface ifIndex that will be chosen for the given flow
2 LAG/ECMP details - list of ifIndexes of channel members if
the destination port is a LAG/ECMP
3 Hash algorithm - hash algorithm used and parameters used for
hash computation.
For the Hashing algorithm, the data part will provide the info of the
parameters used for hashing and algorithms used.
The hashing parameters and algorithm are provided as Sub-TLVs in data
part.
Sub-TLV code: 1 - Hashing parameter 2 - Hash Algorithm
<Author> Expires October 9, 2015 [Page 7]
INTERNET DRAFT <Document Title> April 7, 2015
Sub-TLV value part will be 1 byte of length and contain the code
value of the corresponding field.
Following shows a sample set of hashing parameters and Algorithms
with codes.
Hash Name
Code
1 Source MAC Address
2 Destination MAC Address
3 Source IP Address
4 Destination IP Address
5 TCP Source Port
6 TCP Destination Port
7 UDP Source Port
8 UDP Destination Port
9 VLAN ID
Algorithm Name
Code
1 RTAG-7
2 Vendor-specific
4. Advantages of proposed solution
1. Optimized use of actual available paths in network
Helps to avoid possible Network Congestions by preventing
multiple flows following a single path in network.
2. Reduce unnecessary MP TCP transport overhead:
Helps to avoid forming multiple unnecessary flows and thereby
reducing the processing overload.
5. Security Considerations
This document does not introduce any new security concerns or any
other specifications referenced in this document.
6. IANA Considerations
No IANA actions required.
<Author> Expires October 9, 2015 [Page 8]
INTERNET DRAFT <Document Title> April 7, 2015
7. References
7.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols",
RFC 6356, October 2011.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[I-D.zinjuvadia-traceflow]
Zinjuvadia, V., Manur, R., Krishnamurthy, S., and
Viswanathan, "TraceFlow Extended",
draft-zinjuvadia-traceflow-02, Feb 2009.
[I-D.janapath-intarea-traceflow]
Janardhanan, N., Balaji, V., Rich, G. and Peter, H,
"Traceflow", janapath-intarea-traceflow-00, Jan 2012.
8. Authors' Addresses
Kesava Vijaya Krupakaran
India
Phone: +91 9894847772
Email: Kesav.j@gmail.com
Shathish Muthu Venkatesan
DELL
Olympia Technology Park
Guindy, Chennai 600032
India
Phone: +91 44 4220 1619
<Author> Expires October 9, 2015 [Page 9]
INTERNET DRAFT <Document Title> April 7, 2015
Email: Shathish_Venkatesan@Dell.com
Aravind Prasad Sridharan
DELL
Olympia Technology Park
Guindy, Chennai 600032
India
Phone: +91 44 4220 8658
Email: aravind_sridharan@dell.com
<Author> Expires October 9, 2015 [Page 10]
