One document matched: draft-bonaventure-mptcp-backup-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.26 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-bonaventure-mptcp-backup-00" category="exp" updates="6824">
<front>
<title abbrev="MPTCP backup">Improving Multipath TCP Backup Subflows</title>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
<organization>UCLouvain</organization>
<address>
<email>Olivier.Bonaventure@uclouvain.be</email>
</address>
</author>
<author initials="Q." surname="De Coninck" fullname="Quentin De Coninck">
<organization>UCLouvain</organization>
<address>
<email>Quentin.Deconinck@student.uclouvain.be</email>
</address>
</author>
<author initials="M." surname="Baerts" fullname="Matthieu Baerts">
<organization>UCLouvain</organization>
<address>
<email>Matthieu.Baerts@student.uclouvain.be</email>
</address>
</author>
<author initials="F." surname="Duchene" fullname="Fabien Duchene">
<organization>UCLouvain</organization>
<address>
<email>Fabien.Duchene@uclouvain.be</email>
</address>
</author>
<author initials="B." surname="Hesmans" fullname="Benjamin Hesmans">
<organization>UCLouvain</organization>
<address>
<email>Benjamin.Hesmans@uclouvain.be</email>
</address>
</author>
<date year="2015" month="July" day="06"/>
<area>Transport</area>
<workgroup>MPTCP Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document documents some issues with the current definition of the
backup subflows in <xref target="RFC6824"/>. The solution proposed in
<xref target="RFC6824"/> works well when a subflow completely fails. However,
if a subflow suffers from huge packet losses, but still remains up,
then the delay to switch to the backup subflow may be very long.
We propose to measure the evolution of the retransmission timer (RTO)
to detect the bad performance of subflows.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Multipath TCP is an extension to TCP <xref target="RFC0793"/> that was specified
in <xref target="RFC6824"/>. A Multipath TCP connection is composed of one or
more subflows. Each subflow is a TCP connection that is established
by using the classical TCP three-way handshake. The subflows that
compose a Multipath TCP connection are not all equal.
<xref target="RFC6824"/> defines two types of subflows:</t>
<t><list style="symbols">
<t>the regular subflows</t>
<t>the backup subflows</t>
</list></t>
<t>The regular subflows can be used to transport any data. The backup
subflows are intended to be used only when all the regular subflows have
failed.
Section 2.5 of <xref target="RFC6824"/> defines them by using the following sentence:
“Hosts can indicate at initial subflow setup whether they wish the
subflow to be used as a regular or backup path – a backup path only
being used if there are no regular paths available.”</t>
<t>Intuitively, a user expects that the backup subflow will be used when
the regular subflow fails to continue the data transfer and minimize
the impact of the failure on the Multipath TCP connection.</t>
<t>In this document, we first describe in <xref target="sec:failure"/>
how Multipath TCP operates when
backup subflows are used and some of the operational problems that
this causes. Backup subflows work well when subflows completely fail due
to, for example, the reception of a RST segment or the invalidity
of the IP address associated to the subflow (expired lease time,
de-attachment from network, etc.).
However, there are many practical situations where the failure of a
regular subflow cannot be quickly detected and the user experience
suffers. We then propose in <xref target="sec:modification"/> a slight modification
to the handling of the
backup subflows in Multipath TCP.</t>
</section>
<section anchor="sec:failure" title="What is a Subflow Failure ?">
<t>Experience with Multipath TCP shows that the backup subflows
that are only used when all the other subflows have failed works
well on fixed hosts where the loss of connectivity can be quickly
detected by the affected host. However, there are many situations
where it can be difficult to detect the failure of a regular subflow.</t>
<figure title="Simple network" anchor="fig-simple"><artwork><![CDATA[
<----- primary subflow ----->
+----link1----router1-------router2---link2---+
| |
Client Server
| |
+----link3----router3-------router4---link4---+
<----- backup subflow ----->
]]></artwork></figure>
<t>To understand the situation, let us consider the simple network shown
in <xref target="fig-simple"/>. In this network, the client has established
two subflows:</t>
<t><list style="symbols">
<t>a regular subflow passing through router1 and router2</t>
<t>a backup subflow passing through router3 and router4</t>
</list></t>
<t><xref target="RFC6824"/> supports two methods to signal that a subflow is a backup
subflow:</t>
<t><list style="symbols">
<t>setting the B bit in the MP_JOIN option that is used to create the
subflow</t>
<t>sending the MP_PRIO option with the B bit set</t>
</list></t>
<t>Note that in both cases, when a host sets the B bit in the MP_JOIN or
sends an MP_PRIO option, it requests the other host to only use the
subflow if the other regular subflows have failed. Setting the B bit
in the MP_JOIN option or sending the MP_PRIO option does not affect the
data sent by the host that sends this option <xref target="RFC6824"/>.</t>
<t>Let us now consider three different failure scenarios. For simplicity, we
assume that all the data flows from the Server to the Client and that
the top subflow is the primary subflow while the bottom subflow was
signaled as a backup subflow.</t>
<t>Our first failure scenario is the simplest one: the failure of link1.
In this case, the Client detects the failure locally. This detection
can be fast with wired link layer technologies and slower with some
wireless technologies. Once the failure has been detected, the Client
can either send a REMOVE_ADDR option to indicate the failure of its address
attached to link1 or send an MP_PRIO option with the B bit reset
over the backup subflow. In both cases, a single segment sent over
the backup subflow is sufficient to inform the Server of the failure
of the primary subflow. Note that the REMOVE_ADDR and the MP_PRIO
options are sent unreliably. This implies that any loss of these
options will further delay the recovery on the Server.</t>
<t>Our second failure scenario is the symmetric scenario: the failure of
link2. In this case, the Server will react by sending a REMOVE_ADDR option
over the backup subflow to indicate the loss of the address attached
to this link. Since the Server knows that the primary subflow has failed,
it can immediately start to use the backup subflow to send data to
the Client. Experiments show that these two failure scenarios work
well <xref target="Cellnet12"/>.</t>
<t>The third failure scenario is a failure of the link between router1 and
router2. Different types of failures are possible on this link. We
consider two extreme cases. The first case is a pure link failure that
is detected by the two routers. Since there is no alternate path between
router1 and router2 in our example network, the Client cannot reach the Server
anymore over the top path. Once router1 and router2 have detected the
failure, they will return ICMP destination unreachable messages
to the Client and the Server. This error message could suggest a
failure of the primary subflow. According to <xref target="RFC1122"/>, this ICMP message
should cause the termination of the top subflow. However, according to
<xref target="RFC5461"/>, current TCP implementations do not follow this recommendation
and ignore the received ICMP messages. This is motivated by the risk
of denial of service attacks that could disrupt existing TCP connections
by sending spoofed ICMP messages. A Multipath TCP implementation could
react differently and for example consider the subflow over which the
ICMP message was received as temporarily unusable to cause the utilization
of other (possibly backup) subflows.</t>
<t>If a Multipath TCP implementation does not react to ICMP messages, the
last resort method to detect the failure of the top path is the
retransmission timer (RTO). TCP implementations apply an exponential backoff
algorithm to the retransmission timeout <xref target="RFC6298"/>. If the primary path
fails, the retransmission timeout associated to this path will double until
it reaches the maximum value configured on the TCP stack.
On many stacks, this limit is in the order of tens of minutes which
does not match the expectations of the Multipath TCP user who expects
that her backup subflow will be used earlier than that. A similar situation
occurs when the link between the two routers remains up but is so
congested that packets sent on the regular subflow rarely traverse
the link <xref target="BD2015"/>. In this case, the user also expects to be able to quickly
use the backup subflow to preserve the end-to-end connectivity.</t>
</section>
<section anchor="sec:modification" title="Detecting Underperforming Subflows">
<t>As explained in the previous section, users cannot accept a too long
delay to detect the failure of a regular subflow and the switch to an existing
backup subflow. <xref target="RFC6824"/> allows a host to specify that a subflow
is a backup subflow, but there is no definition of underperfoming subflows
and no mechanism to allow applications to specify
a switchover time to a backup subflow.</t>
<t>Various techniques exist to detect failures. Shim6 <xref target="RFC5533"/>
includes the REAP protocol <xref target="RFC5534"/> to verify the reachability
of addresses. BFD <xref target="RFC5880"/> is used to detect link failures between
routers and also over multihop paths <xref target="RFC5883"/>. Depending on the
chosen parameters, these protocols can achieve fast detection and/or
low overhead. We do not believe that additional protocols are required
to quickly detect the failure of a subflow. With its retransmission timer
that doubles after each unsuccessful retransmission, Multipath TCP already
has the ability to detect underperforming subflows. If data is transmitted
over a broken subflow, the retransmission timer of this subflow
will quickly increase.
These successive retransmissions are an appropriate mechanism to
detect the failure of a subflow and switch to a backup one provided
that the TCP retransmission timer does not become too high.</t>
<t><xref target="RFC0793"/> specifies an abstract API that allows user applications
to indicate bounds on the retransmission timer. <xref target="RFC5482"/> goes further in
by proposing a TCP option that can be used to signal a
proposed maximum value for the TCP retransmission timeout through the
User Timeout option <xref target="RFC5482"/>. This option specifies the maximum time
that some data can remain unacknowledged before considering the connection
to have failed. In <xref target="RFC5482"/>, the User Timeout is encoded as a 15 bits
field that represents seconds or minutes. This implies that the User Timeout
option cannot be used to signal a bound smaller than 1 second.</t>
<t>With the User Timeout option, the TCP connection must be terminated
once its RTO reaches the signaled maximum value.</t>
<t><xref target="RFC5482"/> defines the following parameters for the RTO:</t>
<t><list style="symbols">
<t>U_LIMIT: the upper limit on the USER TIMEOUT</t>
<t>L_LIMIT: the lower limit on the USER TIMEOUT</t>
</list></t>
<t>In addition, the application can specify, e.g. through a socket option, the
USER TIMEOUT that it wishes to use and advertise to the peer: ADV_UTO.
Similarly, the REMOTE_UTO is the User Timeout option received from the peer.
Then, <xref target="RFC5482"/> defines the USER TIMEOUT with the following formula:</t>
<t>USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))</t>
<t><xref target="RFC6824"/> does not discuss precisely how the User Timeout option should
be handled if received over a Multipath TCP connection. If this option is
set through the regular socket API that does not expose any information
about the subflows, it must apply on the overall Multipath TCP connection.</t>
<t>In this document, we envision an API that exposes some parts
of Multipath TCP to the application to enable them to make a better
utilisation of the features of the protocol. Such an API would
expose some information about the subflows to the applications.</t>
<t>A first possibility to control the performance of the subflows could
be to specify a USER_TIMEOUT on a per subflow basis and terminate
the subflows whose RTO has reached the USER_TIMEOUT. However, terminating
an underperforming subflow may be too severe in environments where there
are transient losses such as wireless networks. An alternative approach
is to tag the subflow as underperforming and modify the operation
of Multipath TCP.</t>
<t>According to <xref target="RFC6824"/>, an established subflow can operate in
two modes :</t>
<t><list style="symbols">
<t>primary mode</t>
<t>backup mode</t>
</list></t>
<t>The initial subflow is always created in primary mode. When a
subflow is created, its mode depends on the B bit of the received
MP_JOIN option. The reception of the MP_PRIO option changes the
mode of the corresponding subflow. We a Multipath TCP implementation
sends data, it always selects one of the available primary subflows
to transmit the data. The backup subflows are only selected if there
is no established subflow in primary mode.</t>
<t>We propose a new mode of operation : the underperforming mode. Subflows
are still established in the primary or backup mode as explained
above. A subflow enters the underperforming mode as soon as its
retransmission timer (RTO) reaches a configurable limit. At this
point, the subflow is considered to be underperforming. An underperforming
subflow cannot be selected for data transmission if there exists another
subflow in primary or backup mode. Once a subflow has been tagged as
underperforming, it remains in this mode as long as there are unacknowledged
data on this subflow. Once all data has been acknowledged, it may return
to the primary or backup mode. Further experimentation is required to
evaluate how quickly an underperforming subflow should leave the
underperforming mode once all data has been acknowledged.</t>
<t>System administrators and/or application developpers (e.g. through
a socket option) should be able to specify the maximum RTO that
causes a Multipath TCP subflow to be tagged as underperforming.
For this, we propose two new parameters:</t>
<t><list style="symbols">
<t>UPERF_ADV_TO: the upper threshold on the RTO that forces the subflow
to be considered as underperforming</t>
<t>UPERF_REMOTE_TO: the upper threshold on the RTO received from the
remote peer</t>
</list></t>
<t>The UPERF_ADV_TO is configured locally on the host. It could be
configured globally or on a per connection basis. The configuration
applies to all subflows of a Multipath TCP connection.</t>
<t>The UPERF_REMOTE_TO is received in a Multipath TCP option. This value
applies only on the subflow over which it has been received.</t>
<t>The UPERF_TIMEOUT that is used to detect underperforming subflows
is then computed by using the following formula:</t>
<t>UPERF_TIMEOUT = min(U_LIMIT, max(UPERF_ADV_TO, UPERF_REMOTE_TO, L_LIMIT))</t>
<t>If a USER_TIMEOUT is defined for the Multipath TCP connection, its value
MUST be larger than the UPERF_TIMEOUT.</t>
<t>The UPERF_REMOTE_TO can be signaled by using a Multipath TCP option
to the remote peer. This document proposes the following experimental
option to encode this information (<xref target="fig-expopt"/> :</t>
<figure title="The UPERF Maximum RTO experimental Multipath TCP option" anchor="fig-expopt"><artwork><![CDATA[
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
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| Flags | Experiment |
+---------------+---------------+-------+-------+---------------+
| Id. (16 bits) | Maximum RTO (milliseconds) |
+---------------------------------------------------------------+
]]></artwork></figure>
<t>We do not use the same encoding as <xref target="RFC5482"/> because the encoding
for the USER_TIMEOUT option cannot support maximum RTOs that are
smaller than one second. There are already use cases where users do not
accept to wait such a long time before switching to a backup subflow.</t>
<t>The Experiment Identifier should be TBD and the flags must be
used as defined in <xref target="I-D.bonaventure-mptcp-exp-option"/>.</t>
<t>If experiments conducted with this option show positive results, it
could be possible to update the MP_PRIO option to encode the
maximum RTO information as shown in <xref target="fig-opt"/>.</t>
<figure title="The UPERF Maximum RTO Multipath TCP option" anchor="fig-opt"><artwork><![CDATA[
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
+---------------+---------------+-------+-----+-+--------------+
| Kind | Length |Subtype| |B| AddrID (opt) |
+---------------+---------------+-------+-----+-+--------------+
| Maximum RTO (milliseconds) |
+-----------------------------------------------+
]]></artwork></figure>
</section>
<section anchor="security-considerations" title="Security considerations">
<t>This document does not modify the security considerations for Multipath TCP.</t>
</section>
<section anchor="iana-considerations" title="IANA considerations">
<t>This document proposes the UPERF experimental Multipath TCP option
whose experiment identifier is TBD.</t>
<t>If experiments are successful, an update to this document will propose
a new format for the MP_PRIO option defined in <xref target="RFC6824"/>.</t>
</section>
<section anchor="conclusion" title="Conclusion">
<t>In this document, we have first explained some issues with the
handling of backup subflows by Multipath TCP. Multipath TCP meets
the expectations of its uses when subflows fail completely. In
this case, Multipath TCP moves the traffic over the backup subflows.
However, if the primary subflows underperform, Multipath TCP implementations
may try to retransmit data over such subflows for a long period
of time instead of switching quickly to the backup subflow.
We have then proposed to set an upper bound on the retransmission timer
(RTO) to detect underperforming subflows. This bound can be set locally
of exchanged through the proposed UPERF Multipath TCP option.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This work was partially supported by the FP7-Trilogy2 project. We would
like to thank Mohamed Boucadair for his useful
suggestions and comments on this document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC6824'>
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<author initials='A.' surname='Ford' fullname='A. Ford'>
<organization /></author>
<author initials='C.' surname='Raiciu' fullname='C. Raiciu'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='O.' surname='Bonaventure' fullname='O. Bonaventure'>
<organization /></author>
<date year='2013' month='January' />
<abstract>
<t>TCP/IP 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 TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t><t> Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='6824' />
<format type='TXT' octets='164866' target='http://www.rfc-editor.org/rfc/rfc6824.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC0793'>
<front>
<title abbrev='Transmission Control Protocol'>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal></address></author>
<date year='1981' day='1' month='September' /></front>
<seriesInfo name='STD' value='7' />
<seriesInfo name='RFC' value='793' />
<format type='TXT' octets='172710' target='http://www.rfc-editor.org/rfc/rfc793.txt' />
</reference>
<reference anchor='RFC5461'>
<front>
<title>TCP's Reaction to Soft Errors</title>
<author initials='F.' surname='Gont' fullname='F. Gont'>
<organization /></author>
<date year='2009' month='February' />
<abstract>
<t>This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='5461' />
<format type='TXT' octets='31749' target='http://www.rfc-editor.org/rfc/rfc5461.txt' />
</reference>
<reference anchor='RFC5533'>
<front>
<title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'>
<organization /></author>
<author initials='M.' surname='Bagnulo' fullname='M. Bagnulo'>
<organization /></author>
<date year='2009' month='June' />
<abstract>
<t>This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5533' />
<format type='TXT' octets='299931' target='http://www.rfc-editor.org/rfc/rfc5533.txt' />
</reference>
<reference anchor='RFC5534'>
<front>
<title>Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming</title>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<author initials='I.' surname='van Beijnum' fullname='I. van Beijnum'>
<organization /></author>
<date year='2009' month='June' />
<abstract>
<t>This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5534' />
<format type='TXT' octets='88152' target='http://www.rfc-editor.org/rfc/rfc5534.txt' />
</reference>
<reference anchor='RFC5880'>
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author initials='D.' surname='Katz' fullname='D. Katz'>
<organization /></author>
<author initials='D.' surname='Ward' fullname='D. Ward'>
<organization /></author>
<date year='2010' month='June' />
<abstract>
<t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5880' />
<format type='TXT' octets='110279' target='http://www.rfc-editor.org/rfc/rfc5880.txt' />
</reference>
<reference anchor='RFC5883'>
<front>
<title>Bidirectional Forwarding Detection (BFD) for Multihop Paths</title>
<author initials='D.' surname='Katz' fullname='D. Katz'>
<organization /></author>
<author initials='D.' surname='Ward' fullname='D. Ward'>
<organization /></author>
<date year='2010' month='June' />
<abstract>
<t>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5883' />
<format type='TXT' octets='11765' target='http://www.rfc-editor.org/rfc/rfc5883.txt' />
</reference>
<reference anchor='RFC1122'>
<front>
<title>Requirements for Internet Hosts - Communication Layers</title>
<author initials='R.' surname='Braden' fullname='Robert Braden'>
<organization>University of Southern California (USC)/ Information Sciences Institute (ISI)</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email></address></author>
<date year='1989' month='October' /></front>
<seriesInfo name='STD' value='3' />
<seriesInfo name='RFC' value='1122' />
<format type='TXT' octets='295992' target='http://www.rfc-editor.org/rfc/rfc1122.txt' />
</reference>
<reference anchor='RFC5482'>
<front>
<title>TCP User Timeout Option</title>
<author initials='L.' surname='Eggert' fullname='L. Eggert'>
<organization /></author>
<author initials='F.' surname='Gont' fullname='F. Gont'>
<organization /></author>
<date year='2009' month='March' />
<abstract>
<t>The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5482' />
<format type='TXT' octets='33568' target='http://www.rfc-editor.org/rfc/rfc5482.txt' />
</reference>
<reference anchor='RFC6298'>
<front>
<title>Computing TCP's Retransmission Timer</title>
<author initials='V.' surname='Paxson' fullname='V. Paxson'>
<organization /></author>
<author initials='M.' surname='Allman' fullname='M. Allman'>
<organization /></author>
<author initials='J.' surname='Chu' fullname='J. Chu'>
<organization /></author>
<author initials='M.' surname='Sargent' fullname='M. Sargent'>
<organization /></author>
<date year='2011' month='June' />
<abstract>
<t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6298' />
<format type='TXT' octets='22454' target='http://www.rfc-editor.org/rfc/rfc6298.txt' />
</reference>
<reference anchor='I-D.bonaventure-mptcp-exp-option'>
<front>
<title>Experimental Multipath TCP option</title>
<author initials='O' surname='Bonaventure' fullname='Olivier Bonaventure'>
<organization />
</author>
<author initials='b' surname='benjamin.hesmans@uclouvain.be' fullname='benjamin.hesmans@uclouvain.be'>
<organization />
</author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
<organization />
</author>
<date month='June' day='16' year='2015' />
<abstract><t>This document proposes a generic format for an experimental Multipath TCP option. This experimental option is expected to replace the option type that was reserved for private use in [RFC6824].</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-bonaventure-mptcp-exp-option-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt' />
</reference>
<reference anchor="BD2015" >
<front>
<title>Multipath TCP with Real Smartphone Applications</title>
<author initials="M." surname="Baerts">
<organization></organization>
</author>
<author initials="Q." surname="De Coninck">
<organization></organization>
</author>
<date year="2015" month="June"/>
</front>
<seriesInfo name="Master Thesis, UCL" value=""/>
</reference>
<reference anchor="Cellnet12" target="http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp">
<front>
<title>Exploring Mobile/WiFi Handover with Multipath TCP</title>
<author initials="C." surname="Paasch">
<organization></organization>
</author>
<author initials="G." surname="Detal">
<organization></organization>
</author>
<author initials="F." surname="Duchene">
<organization></organization>
</author>
<author initials="C." surname="Raiciu">
<organization></organization>
</author>
<author initials="O." surname="Bonaventure">
<organization></organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="ACM SIGCOMM workshop on Cellular Networks (Cellnet12)" value=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:29:56 |