draft-ietf-mptcp-congestion-05.txt   draft-ietf-mptcp-congestion-06.txt 
Internet Engineering Task Force C. Raiciu Internet Engineering Task Force C. Raiciu
Internet-Draft M. Handley Internet-Draft University Politehnica of
Intended status: Experimental D. Wischik Intended status: Experimental Bucharest
Expires: December 18, 2011 University College London Expires: January 26, 2012 M. Handley
June 16, 2011 D. Wischik
University College London
July 25, 2011
Coupled Congestion Control for Multipath Transport Protocols Coupled Congestion Control for Multipath Transport Protocols
draft-ietf-mptcp-congestion-05 draft-ietf-mptcp-congestion-06
Abstract Abstract
Often endpoints are connected by multiple paths, but communications Often endpoints are connected by multiple paths, but communications
are usually restricted to a single path per connection. Resource are usually restricted to a single path per connection. Resource
usage within the network would be more efficient were it possible for usage within the network would be more efficient were it possible for
these multiple paths to be used concurrently. Multipath TCP is a these multiple paths to be used concurrently. Multipath TCP is a
proposal to achieve multipath transport in TCP. proposal to achieve multipath transport in TCP.
New congestion control algorithms are needed for multipath transport New congestion control algorithms are needed for multipath transport
protocols such as Multipath TCP, as single path algorithms have a protocols such as Multipath TCP, as single path algorithms have a
series of issues in the multipath context. One of the prominent series of issues in the multipath context. One of the prominent
problems is that running existing algorithms such as standard TCP problems is that running existing algorithms such as standard TCP
independently on each path would give the multipath flow more than independently on each path would give the multipath flow more than
its fair share at a bottleneck link traversed by more than one of its its fair share at a bottleneck link traversed by more than one of its
subflows. Further, it is desirable that a source with multiple paths subflows. Further, it is desirable that a source with multiple paths
available will transfer more traffic using the least congested of the available will transfer more traffic using the least congested of the
paths, hence achieving resource pooling. This would increase the paths, achieving a property called resource pooling where a bundle of
overall efficiency of the network and also its robustness to failure. links effectively behaves like one shared link with bigger-capacity.
This would increase the overall efficiency of the network and also
its robustness to failure.
This document presents a congestion control algorithm which couples This document presents a congestion control algorithm which couples
the congestion control algorithms running on different subflows by the congestion control algorithms running on different subflows by
linking their increase functions, and dynamically controls the linking their increase functions, and dynamically controls the
overall aggressiveness of the multipath flow. The result is a overall aggressiveness of the multipath flow. The result is a
practical algorithm that is fair to TCP at bottlenecks while moving practical algorithm that is fair to TCP at bottlenecks while moving
traffic away from congested links. traffic away from congested links.
Status of this Memo Status of this Memo
skipping to change at page 2, line 7 skipping to change at page 2, line 11
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2011. This Internet-Draft will expire on January 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Coupled Congestion Control Algorithm . . . . . . . . . . . . . 6 3. Coupled Congestion Control Algorithm . . . . . . . . . . . . . 6
4. Implementation Considerations . . . . . . . . . . . . . . . . 7 4. Implementation Considerations . . . . . . . . . . . . . . . . 7
4.1. Computing alpha in Practice . . . . . . . . . . . . . . . 8 4.1. Computing alpha in Practice . . . . . . . . . . . . . . . 8
4.2. Implementation Considerations when CWND is Expressed 4.2. Implementation Considerations when CWND is Expressed
in Packets . . . . . . . . . . . . . . . . . . . . . . . . 9 in Packets . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 51 skipping to change at page 4, line 51
meeting the first two goals. meeting the first two goals.
Goals 1 and 2 together ensure fairness at the bottleneck. Goal 3 Goals 1 and 2 together ensure fairness at the bottleneck. Goal 3
captures the concept of resource pooling [WISCHIK]: if each multipath captures the concept of resource pooling [WISCHIK]: if each multipath
flow sends more data through its least congested path, the traffic in flow sends more data through its least congested path, the traffic in
the network will move away from congested areas. This improves the network will move away from congested areas. This improves
robustness and overall throughput, among other things. The way to robustness and overall throughput, among other things. The way to
achieve resource pooling is to effectively "couple" the congestion achieve resource pooling is to effectively "couple" the congestion
control loops for the different subflows. control loops for the different subflows.
We propose an algorithm that couples only the additive increase We propose an algorithm that couples the additive increase function
function of the subflows, and uses unmodified TCP behavior in case of of the subflows, and uses unmodified TCP behavior in case of a drop.
a drop. The algorithm relies on the traditional TCP mechanisms to The algorithm relies on the traditional TCP mechanisms to detect
detect drops, to retransmit data, etc. drops, to retransmit data, etc.
Detecting shared bottlenecks reliably is quite difficult, but is just Detecting shared bottlenecks reliably is quite difficult, but is just
one part of a bigger question. This bigger question is how much one part of a bigger question. This bigger question is how much
bandwidth a multipath user should use in total, even if there is no bandwidth a multipath user should use in total, even if there is no
shared bottleneck. shared bottleneck.
The congestion controller aims to set the multipath flow's aggregate The congestion controller aims to set the multipath flow's aggregate
bandwidth to be the same as a regular TCP flow would get on the best bandwidth to be the same as a regular TCP flow would get on the best
path available to the multipath flow. To estimate the bandwidth of a path available to the multipath flow. To estimate the bandwidth of a
regular TCP flow, the multipath flow estimates loss rates and round regular TCP flow, the multipath flow estimates loss rates and round
skipping to change at page 10, line 20 skipping to change at page 10, line 20
rarely changes between paths so this shouldn't be a problem. rarely changes between paths so this shouldn't be a problem.
However, it is simple to derive formulae allowing packet-based stacks However, it is simple to derive formulae allowing packet-based stacks
to achieve byte rate fairness (and viceversa) if needed. In to achieve byte rate fairness (and viceversa) if needed. In
particular, for packet-based stacks wanting byte-rate fairness, the particular, for packet-based stacks wanting byte-rate fairness, the
formula above changes as follows: cwnd_max is replaced by cwnd_max * formula above changes as follows: cwnd_max is replaced by cwnd_max *
mss_max * mss_max, while cwnd_i is replaced with cwnd_i * mss_i. mss_max * mss_max, while cwnd_i is replaced with cwnd_i * mss_i.
5. Discussion 5. Discussion
To achieve perfect resource pooling, one must couple both increase The algorithm we've presented fully achieves Goals 1 and 2, but does
and decrease of congestion windows across subflows, as in [KELLY]. not achieve full resource pooling (Goal 3). Resource pooling
Yet this tends to exhibit "flappiness": when the paths have similar requires that no traffic should be transferred on links with higher
levels of congestion, the congestion controller will tend to allocate loss rates. To achieve perfect resource pooling, one must couple
all the window to one random subflow, and allocate zero window to the both increase and decrease of congestion windows across subflows, as
other subflows. The controller will perform random flips between in [KELLY].
these stable points. This doesn't seem desirable in general, and is
particularly bad when the achieved rates depend on the RTT (as in the
current Internet): in such a case, the resulting rate with fluctuate
unpredictably depending on which state the controller is in, hence
violating Goal 1.
By only coupling increases our proposal removes flappiness but also There are a few problems with such a fully-coupled controller.
reduces the extent of resource pooling the protocol achieves. The First, it will probe insufficiently paths with high loss rates, and
algorithm will allocate window to the subflows such that p_i * cwnd_i will fail to detect free capacity when it becomes available. Second,
= constant, for all i. Thus, when the loss rates of the subflows are such controllers tend to exhibit "flappiness": when the paths have
similar levels of congestion, the congestion controller will tend to
allocate all the window to one random subflow, and allocate zero
window to the other subflows. The controller will perform random
flips between these stable points. This doesn't seem desirable in
general, and is particularly bad when the achieved rates depend on
the RTT (as in the current Internet): in such a case, the resulting
rate with fluctuate unpredictably depending on which state the
controller is in, hence violating Goal 1.
By only coupling increases our proposal probes high-loss paths,
detecting free capacity quicker. Our proposal does not suffer from
flappiness but also achieves less resource pooling. The algorithm
will allocate window to the subflows such that p_i * cwnd_i =
constant, for all i. Thus, when the loss rates of the subflows are
equal, each subflow will get an equal window, removing flappiness. equal, each subflow will get an equal window, removing flappiness.
When the loss rates differ, progressively more window will be When the loss rates differ, progressively more window will be
allocated to the flow with the lower loss rate. In contrast, perfect allocated to the flow with the lower loss rate. In contrast, perfect
resource pooling requires that all the window should be allocated on resource pooling requires that all the window should be allocated on
the path with the lowest loss rate. the path with the lowest loss rate. Further details can be found in
[NSDI].
6. Security Considerations 6. Security Considerations
None. None.
Detailed security analysis for the Multipath TCP protocol itself is Detailed security analysis for the Multipath TCP protocol itself is
included in [I-D.ford-mptcp-multiaddressed] and RFC 6181 [RFC6181] included in [I-D.ford-mptcp-multiaddressed] and RFC 6181 [RFC6181]
7. Acknowledgements 7. Acknowledgements
skipping to change at page 11, line 37 skipping to change at page 11, line 44
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
9.2. Informative References 9.2. Informative References
[I-D.ford-mptcp-multiaddressed] [I-D.ford-mptcp-multiaddressed]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses",
draft-ford-mptcp-multiaddressed-03 (work in progress), draft-ford-mptcp-multiaddressed-04 (work in progress),
March 2010. March 2010.
[KELLY] Kelly, F. and T. Voice, "Stability of end-to-end [KELLY] Kelly, F. and T. Voice, "Stability of end-to-end
algorithms for joint routing and rate control", ACM algorithms for joint routing and rate control", ACM
SIGCOMM CCR vol. 35 num. 2, pp. 5-12, 2005, SIGCOMM CCR vol. 35 num. 2, pp. 5-12, 2005,
<http://portal.acm.org/citation.cfm?id=1064415>. <http://portal.acm.org/citation.cfm?id=1064415>.
[NSDI] Wischik, D., Raiciu, C., Greenhalgh, A., and M. Handley, [NSDI] Wischik, D., Raiciu, C., Greenhalgh, A., and M. Handley,
"Design, Implementation and Evaluation of Congestion "Design, Implementation and Evaluation of Congestion
Control for Multipath TCP", Usenix NSDI , March 2011, <htt Control for Multipath TCP", Usenix NSDI , March 2011, <htt
skipping to change at page 12, line 18 skipping to change at page 12, line 26
March 2011. March 2011.
[WISCHIK] Wischik, D., Handley, M., and M. Bagnulo Braun, "The [WISCHIK] Wischik, D., Handley, M., and M. Bagnulo Braun, "The
Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num.
5, pp. 47-52, October 2008, 5, pp. 47-52, October 2008,
<http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>. <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
Authors' Addresses Authors' Addresses
Costin Raiciu Costin Raiciu
University College London University Politehnica of Bucharest
Gower Street Splaiul Independentei 313
London WC1E 6BT Bucharest
UK Romania
Email: c.raiciu@cs.ucl.ac.uk Email: costin.raiciu@cs.pub.ro
Mark Handley Mark Handley
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
Email: m.handley@cs.ucl.ac.uk Email: m.handley@cs.ucl.ac.uk
Damon Wischik Damon Wischik
 End of changes. 12 change blocks. 
35 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/