One document matched: draft-walid-mptcp-congestion-control-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC6356 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6356.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="2"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-walid-mptcp-congestion-control-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MPTCP Congestion Control">Balanced Linked Adaptation Congestion Control Algorithm for MPTCP</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Anwar Walid" initials="A." surname="Walid">
<organization>Bell Labs</organization>
<address>
<postal>
<street>600 Mountain Ave</street>
<!-- Reorder these if your country does things differently -->
<city>New Providence</city>
<region>NJ, USA</region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>anwar@research.bell-labs.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Qiuyu Peng" initials="Q." surname="Peng">
<organization>Caltech</organization>
<address>
<postal>
<street>Department of Electrical Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Pasadena</city>
<region>CA, USA</region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>qpeng@caltech.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jaehyun Hwang" initials="J." surname="Hwang">
<organization>Samsung Electronics</organization>
<address>
<postal>
<street>Advanced Technology Group, Networks Business</street>
<!-- Reorder these if your country does things differently -->
<city>Suwon, Gyeonggi-do</city>
<region>Republic of Korea</region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>jhyun.hwang@samsung.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Steven H. Low" initials="S.H." surname="Low">
<organization>Caltech</organization>
<address>
<postal>
<street>Department of Computing + Mathematical Sciences</street>
<street>Department of Electrical Engineering</street>
<!-- Reorder these if your country does things differently -->
<city>Pasadena</city>
<region>CA, USA</region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>slow@caltech.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2015" month="July" day="23" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Multipath TCP</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Balia</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes the mechanism of Balia, the "Balanced linked
adaptation", which is a congestion control algorithm for Multipath
TCP (MPTCP). The recent proposals, LIA and OLIA, suffer from either
unfriendliness to Single Path TCP (SPTCP) or unresponsiveness to
network changes under certain conditions. The tradeoff between
friendliness and responsiveness is inevitable, but Balia judiciously
balances this tradeoff based on a new design framework that allows
one to systematically explore the design space. Balia has been
implemented in the Linux kernel and also included in the UCLouvain's MPTCP
implementation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Various congestion control algorithms have been proposed as
extensions of TCP NewReno to MPTCP. A straightforward extension is to
run TCP NewReno on each subpath, e.g., <xref target="HONDA09" />. This algorithm,
however, can be highly unfriendly when it shares a path with a SPTCP
user. This motivates the Coupled algorithm which is fair because it
has the same underlying utility function as TCP NewReno, e.g.,
<xref target="KELLY05" />, <xref target="HAN04" />. It is found in <xref target="RFC6356" />, however, that the
Coupled algorithm responds slowly in a dynamic network environment.</t>
<t>The current default congestion control algorithm for MPTCP, called
LIA (Linked-Increases Algorithm), is more responsive than the Coupled
algorithm. However, it has been reported that LIA can sometimes be
excessively aggressive toward SPTCP users without any benefit to
multipath users <xref target="KHALILI12" />. Recently, OLIA (Opportunistic Linked-
Increases Algorithm) <xref target="KHALILI12" /> was proposed as a variant of Coupled
algorithm <xref target="KELLY05" /> which is as friendly as the Coupled algorithm.
We have found, however, that OLIA can be unresponsive to changes in
network conditions in some scenarios (e.g., when the paths used by a
user have similar round trip times (RTTs)) <xref target="PENG14" />.</t>
<t>In this draft, we introduce Balia, the "Balanced linked adaptation",
which is a window-based congestion control algorithm for MPTCP. The
main design goal of Balia is to systematically tradeoff different
properties such as TCP friendliness and responsiveness by developing
structural understanding of MPTCP algorithms in a new design
framework. For instance, it is widely suspected that there is a
tradeoff between friendliness and responsiveness and it is proved in
this framework that this tradeoff is indeed inevitable. By
parameterizing different structural properties, Balia generalizes
existing algorithms and explicitly balances the tradeoff. We also
prove mathematically that Balia has a unique equilibrium point, and
that it is asymptotically stable. Therefore, Balia can provide
balanced performance in terms of friendliness and responsiveness.</t>
<t>In <xref target="PENG14" />, we compare the performance of several MPTCP algorithms
over a testbed, including Balia, OLIA and LIA. Our experimental
results show that Balia is friendlier than LIA and more responsive
than OLIA. It also solves LIA's problem identified by <xref target="KHALILI12" />.
Balia has been implemented in the Linux kernel and also included in the UCLouvain's MPTCP
implementation.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119" />.</t>
</section>
<section title="Terminology">
<t>Regular/Singlepath TCP (SPTCP): The standard version of TCP <xref
target="RFC5681" />
that uses a single pair of IP address and ports per connection.</t>
<t>Multipath TCP (MPTCP): A modified version of the regular TCP that
simultaneously uses multiple paths between hosts.</t>
<t>LIA: The Linked-Increases Algorithm for MPTCP <xref target="RFC6356" />.</t>
<t>OLIA: The Opportunistic Linked-Increases Algorithm for MPTCP
<xref target="KHALILI12" />.</t>
<t>Balia: The Balanced linked adaptation algorithm for MPTCP <xref target="PENG14" />.</t>
<t>AIMD: The Additive Increase Multiplicative Decrease algorithm used in
TCP congestion avoidance.</t>
<t>w_r: The congestion window on a path r.</t>
<t>rtt_r: The Round-Trip Time (RTT) on a path r.</t>
</section>
</section>
<section title="Balanced Linked Adaptation Algorithm">
<t>Balia is a generalized MPTCP algorithm that strikes a good balance
between friendliness and responsiveness. The algorithm only applies
to the AIMD part of the congestion avoidance phase. The other parts
such as slow start, fast retransmit/recovery algorithms are the same
as in TCP <xref target="RFC5681" />. The minimum ssthresh is set to 1 MSS instead of
2 when more than 1 path is available.</t>
<t>Each source s has a set of paths r. As a special case, the set can be
a singleton in which case Balia reduces to TCP Reno (see below). Each
path r maintains a congestion window w_r and measures its round-trip
time rtt_r. The window adaptation of Balia is as follows:</t>
<t>- For each ACK on path r, increase w_r by:</t>
<figure align="center">
<artwork align="left"><![CDATA[
x_r 1 + alpha_r 4 + alpha_r
-------------------- * ( ----------- ) * ( ----------- )
rtt_r * (SUM(x_k))^2 2 5
]]></artwork>
</figure>
<t>- For each packet loss on path r, decrease w_r by:</t>
<figure align="center">
<artwork align="left"><![CDATA[
w_r
----- * min { alpha_r, 1.5 }
2
]]></artwork>
</figure>
<t>where x_r = w_r / rtt_r and alpha_r = max { x_k } / x_r.</t>
<t>Note that Balia's decrement algorithm multiplies the MD algorithm of
TCP Reno by a factor in the range of [1, 1.5].</t>
<t>If a Balia user uses only a single path, then alpha_r = 1, in which
case both the increment and the decrement algorithms of Balia reduce to
those of TCP Reno. Hence Balia reduces to TCP Reno on single paths.</t>
</section>
<section title="Theoretical justification">
<t>In <xref target="PENG14" />, we have developed a unified model of MPTCP algorithms
and characterized the design space. This provides a framework to
systematically design MPTCP algorithms and analyze their behavior in
a large network at design time. For instance, it has allowed us to
identify designs that guarantee the existence, uniqueness and
stability of network equilibrium. Balia is designed using this
framework to achieve specific design goals. In this section, we will
focus on how Balia balances three often conflicting design goals, TCP
friendliness, responsiveness and window oscillation.</t>
<t>TCP friendliness characterizes how much more throughput a MPTCP flow
will get when it competes with an SPTCP flow. A MPTCP flow is said to
be "TCP friendly" if it does not dominate the available bandwidth
when it shares the same network with a SPTCP flow.</t>
<t>Responsiveness characterizes how fast the MPTCP algorithm reacts to
changes in network conditions.</t>
<t>The window oscillation property characterizes how severely the window
size fluctuates around the equilibrium point. It is an inherent
property of AIMD-like algorithms.</t>
<t>In <xref target="PENG14" />, it is proved mathematically that there is an inevitable
tradeoff between TCP friendliness and responsiveness, and between
responsiveness and window oscillation. Thus, it is theoretically
impossible to maximize the performance in all three metrics
simultaneously.</t>
<t>Our design philosophy is to allow window oscillation up to an
acceptable level in order to improve both friendliness and
responsiveness. This is achieved by explicitly parameterizing these
properties and systematically choosing these parameters.</t>
</section>
<section title="Implementation considerations">
<t>To enable Balia to operate in a wide spectrum of applications scenarios,
i.e., with wide range of w_r and rtt_r, we need to re-write the Balia's additive increase (AI)
formula in an equivalent form which allows easier implementation
in the Linux kernel with fixed point operations, and avoids integer-overflow problems.
Note that in an extreme case, the sending rate on a path, x_r, may increase to 2^30 (w_r/rtt_r) or more.
In such a case, the term (SUM(x_k))^2 in the current formula can easily cause 64-bit integer overflow.
In addition, there can be also a significant rounding error when we do a fixed-point division by a large number.</t>
<t>Therefore, to mitigate the above issues, we rewrite Balia's additive increase (AI) formula as follows:</t>
<figure align="center">
<artwork align="left"><![CDATA[
x_r x_r + max{x_k} 4 * x_r + max{x_k}
-------------------- * ( -------------- ) * ( ------------------ )
rtt_r * (SUM(x_k))^2 2 * x_r 5 * x_r
]]></artwork>
</figure>
<t>which can be simplified to:</t>
<figure align="center">
<artwork align="left"><![CDATA[
(x_r + max{x_k}) * (4 * x_r + max{x_k})
---------------------------------------
w_r * (SUM(x_k))^2 * 10
]]></artwork>
</figure>
<t>Now the term x_r is computed in bytes/sec and may increase up to about 2^52.
Thus we need to scale the sending rate through bit-shift operations so that max{x_k} does not
exceed a cerntain value, e.g., 2^25, to safely calculate the term (SUM(x_k))^2.
At this point, if max{x_k} is a very large number, a small x_r can be sometimes 0
after the right shift operation. This may hurt the accuracy of the calculation.
But we have seen that the overall rounding error is not significant
since max{x_k} is the dominant term in the formula while x_r would be neglible in such cases.</t>
</section>
<section title="Experimental results">
<t>In this section, we summarize our experimental results that
illustrate the weaknesses of the current algorithms (LIA and OLIA).
We evaluate the MPTCP algorithms using the UCLouvain's MPTCP implementation
<xref target="MPLKI" />. The network parameters such as network bandwidth
and one-way delay are implemented by Dummynet <xref target="DUMMYNET" />.
Iperf is used to generate traffic and measure the throughput.</t>
<section title="Khalili's scenario">
<t>In <xref target="KHALILI12" />, it has been revealed that LIA can be unfriendly to
SPTCP users even when its own MPTCP throughput is saturated. That is,
the throughputs of SPTCP flows are significantly degraded without any
benefit to MPTCP flows. To reproduce this scenario, we create a
testbed as shown in Figure 1. In this scenario, N1 type1 users can be
either single-path or multipath while N2 type2 users are always
single-path.</t>
<figure align="center">
<artwork align="left"><![CDATA[
+----+
N1 | | Server
Type1 ---------------------------------| C1 |-- for type1
flows --\ /--| | flows
\ / +----+
\ / Router1
\ +----+ +----+ /
\--| | | |--/
N2 | C2 |---| | Server
Type2 ---------| | | |------------------ for type2
flows +----+ +----+ flows
Router2 Router3
]]></artwork>
</figure>
<t>Figure 1: Testbed topology for Khalili's scenario. The Router1
emulates the server-side bottleneck for type1 users and the Router2
emulates the shared bottleneck.</t>
<t>The aggregate throughputs of these users are shown in Table 1 for the
case when all users are SPTCP and the case when all type1 users are
upgraded to MPTCP users using different algorithms. We observe that
upgrading type1 users to MPTCP decreases type2 users' throughput
without any benefit to type1 users if LIA is used; the type2 users
are worse off by 19% when N1=N2=5 and by 25% when N1=15 and N2=5.
Both OLIA and Balia are more friendly than LIA to SPTCP (type2)
users.</t>
<figure align="center">
<artwork align="left"><![CDATA[
C1=C2=10Mbps
+-------------+----------------------------------+
| Type1 users | Type1 users are multipath |
| are +-----------+----------+-----------+
| single-path | LIA | OLIA | Balia |
+------+-------------+-----------+----------+-----------+
N1=5 |type1 | 9.47 | 9.26 | 9.25 | 9.25 |
+------+-------------+-----------+----------+-----------+
N2=5 |type2 | 9.29 | 7.55 | 8.13 | 8.32 |
------+------+-------------+-----------+----------+-----------+
N1=15 |type1 | 9.39 | 8.96 | 8.93 | 9.02 |
+------+-------------+-----------+----------+-----------+
N2=5 |type2 | 9.29 | 6.94 | 7.41 | 7.98 |
+------+-------------+-----------+----------+-----------+
Values are in Mbps.
]]></artwork>
</figure>
<t>Table 1: Throughput obtained by type1 and type2 users: Upgrading
type1 users to MPTCP decreases type2 users' throughput without any
benefit to type1 users.</t>
</section>
<section title="Responsiveness">
<t>To demonstrate the dynamic performance of MPTCP algorithms, we
implement a testbed topology as shown in Figure 2. One-way delay
of each single-path is about 10ms. In this scenario,
a MPTCP flow is long lived while 5 SPTCP flows start at 40s and end
at 80s. Table 2 shows the convergence time, which is defined as the
first time the congestion window on the second path via Router2
reaches the average congestion window after the SPTCP users have
left.</t>
<figure align="center">
<artwork align="left"><![CDATA[
Router1 Router3
+-------+ 20Mbps,10ms +-------+ 40Mbps
1 MPTCP ----------| |-------------| |-------- Server
flow --\ | | /-----| |
(0-200s) \ +-------+ / +-------+
\ /
\ 20Mbps,10ms
\ +-------+ /
\--| |--/
5 SPTCP ----------| |
flows +-------+
(40-80s) Router2
]]></artwork>
</figure>
<t>Figure 2: Testbed topology for the responsiveness scenario.</t>
<figure align="center">
<artwork align="left"><![CDATA[
+------------------+-----------+----------+-----------+-----------+
| | Coupled | OLIA | LIA | Balia |
+------------------+-----------+----------+-----------+-----------+
| Convergence time | 94.36 | 58.5 | 17.75 | 14.73 |
+------------------+-----------+----------+-----------+-----------+
Values are in seconds.
]]></artwork>
</figure>
<t>Table 2: Responsiveness: Convergence time of MPTCP user after SPTCP
users have left the network.</t>
<t>We observe that in this scenario Balia and LIA are quite responsive
while both Coupled and OLIA algorithms take an excessively long time
to recover. Note that in this scenario, the increment/decrement
algorithms of Coupled and those of OLIA are similar, and therefore
they behave in a similar way. For both algorithms, the excessively
slow recovery of the congestion window on the second path is due to
the design that increases the window roughly by w_r / (SUM(w_k))^2 on
each ACK assuming the RTTs are similar. After the SPTCP users have
left, w_2 is small while w_1 is large, so that w_2 / (w_1 + w_2)^2 is
very small. It therefore takes a long time for w_2 to increase to its
steady state value. In general, under the Coupled algorithm, a route
with a large throughput can greatly suppress the throughput on
another route even though the other route is underutilized.</t>
</section>
<section title="NorNet experiment">
<t>To show that Balia works well on real Internet environments, we create two
virtual machine hosts A and B over the NorNet Core, a country-wide (Norway)
multi-homed research testbed <xref target="NORNET" />. Host A is connected
to Internet via ISP(Internet service provider)-1 while host B is connected
via ISP-2 and ISP-3.</t>
<t>Considering a scenario where host B downloads a file from host A via two interfaces,
we measure the througputs of both SPTCP and MPTCP with Reno and Balia respectively, as shown in Table 3.
There are two logical paths between the hosts, (ISP-1 to ISP-2) and (ISP-1 to ISP-3),
so we measure the bandwidth of each single-path with SPTCP and both of the two paths with MPTCP.
The measurement is repeated 30 times for each case.
In Table 3, it is observed that MPTCP with Balia aggregates the bandwidths of the two paths well.</t>
<figure align="center">
<artwork align="left"><![CDATA[
+------------------+-------------+-------------+--------------+
| | SPTCP(Reno) | SPTCP(Reno) | MPTCP(Balia) |
| | A(1)->B(2) | A(1)->B(3) | A(1)->B(2,3) |
+------------------+-------------+-------------+--------------+
| Avg. throughput | 3.976 | 3.823 | 7.508 |
+------------------+-------------+-------------+--------------+
| Max. throughput | 4.08 | 3.83 | 7.69 |
+------------------+-------------+-------------+--------------+
| Min. throughput | 3.93 | 3.82 | 7.2 |
+------------------+-------------+-------------+--------------+
Values are in Mbps.
]]></artwork>
</figure>
<t>Table 3: Throughputs of SPTCP and MPTCP over the NorNet Core.
Numbers in parenthesis refer to the ISP number.</t>
</section>
</section>
<section title="Conclusion">
<t>In <xref target="PENG14" />, we have developed a model for MPTCP and identified
designs that guarantee the existence, uniqueness and stability of the
network equilibrium. We also characterize the design space and study
the tradeoff among TCP friendliness, responsiveness, and window
oscillation. Base on better understanding of the design space, our
new congestion control algorithm for MPTCP, Balia, generalizes prior
algorithms and strikes a good balance between friendliness and
responsiveness. Balia has been implemented in the Linux kernel and
tested in various scenarios.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC5681;
&RFC6356;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="HONDA09">
<front>
<title>Multipath congestion control for shared bottleneck</title>
<author initials="M." surname="Honda"></author>
<author initials="Y." surname="Nishida"></author>
<author initials="L." surname="Eggert"></author>
<author initials="P." surname="Sarolahti"></author>
<author initials="H." surname="Tokuda"></author>
<date year="2009" />
</front>
<seriesInfo name="PFLDNeT" value="Workshop" />
</reference>
<reference anchor="KELLY05">
<front>
<title>Stability of end-to-end algorithms
for joint routing and rate control</title>
<author initials="F." surname="Kelly"></author>
<author initials="T." surname="Voice"></author>
<date year="2005" />
</front>
<seriesInfo name="ACM" value="SIGCOMM Computer
Communication Review, vol. 35, no. 2, pp. 5-12" />
</reference>
<reference anchor="HAN04">
<front>
<title>Overlay tcp for multi-path routing and congestion
control</title>
<author initials="H." surname="Han"></author>
<author initials="S." surname="Shakkottai"></author>
<author initials="C." surname="Hollot"></author>
<author initials="R." surname="Srikant"></author>
<author initials="D." surname="Towsley"></author>
<date year="2004" />
</front>
<seriesInfo name="IMA" value="Workshop on Measurements and Modeling of the
Internet" />
</reference>
<reference anchor="KHALILI12">
<front>
<title>MPTCP is not Pareto-optimality: Performance
issues and a possible solution</title>
<author initials="R." surname="Khalili"></author>
<author initials="N." surname="Gast"></author>
<author initials="M." surname="Popovic"></author>
<author initials="U." surname="Upadhyay"></author>
<author initials="J.-Y." surname="Le Boudec"></author>
<date year="2012" />
</front>
<seriesInfo name="ACM" value="CoNext" />
</reference>
<reference anchor="MPLKI" target="http://multipath-tcp.org/">
<front>
<title>MultiPath TCP-Linux kernel implementation</title>
<author>
<organization>UCL, Louvain-la-Neuve, Belgium</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="PENG14">
<front>
<title>Multipath TCP: Analysis, Design, and Implementation</title>
<author initials="Q." surname="Peng"></author>
<author initials="A." surname="Walid"></author>
<author initials="J." surname="Hwang"></author>
<author initials="S. H." surname="Low"></author>
<date year="2014" />
</front>
<seriesInfo name="IEEE/ACM" value="Transactions on Networking, vol. PP, no. 99" />
</reference>
<reference anchor="DUMMYNET">
<front>
<title>Dummynet revisited</title>
<author initials="M." surname="Carbone"></author>
<author initials="L." surname="Rizzo"></author>
<date year="2010" />
</front>
<seriesInfo name="ACM" value="SIGCOMM Computer Communication Review, vol. 40, no. 2, pp.
12-20" />
</reference>
<reference anchor="NORNET">
<front>
<title>NorNet Core - A multi-homed research testbed</title>
<author initials="E. G." surname="Gran"></author>
<author initials="T." surname="Dreibholz"></author>
<author initials="A." surname="Kvalbein"></author>
<date year="2014" />
</front>
<seriesInfo name="Elsevier" value="Computer Networks, vol. 61, pp. 75-87" />
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:37:26 |