One document matched: draft-zimmermann-tcp-lcd-00.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 rfc792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY rfc793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY rfc1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY rfc1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY rfc2581 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2581.xml">
<!ENTITY rfc2914 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml">
<!ENTITY rfc2988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2988.xml">
<!ENTITY rfc3522 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3522.xml">
<!ENTITY rfc3819 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3819.xml">
<!ENTITY rfc4138 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4138.xml">
<!ENTITY retransmit-now SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eggert-tcpm-tcp-retransmit-now.xml">
<!ENTITY tcp-rlci SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schuetz-tcpm-tcp-rlci.xml">
<!ENTITY linkup SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dawkins-trigtran-linkup.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.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="no"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- 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="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- 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="exp" docName="draft-zimmermann-tcp-lcd-00" ipr="trust200811">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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="Make TCP more Robust to LCDs">
Make TCP more Robust to Long Connectivity Disruptions</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="A.Z."
surname="Zimmermann"
fullname="Alexander Zimmermann">
<organization>RWTH Aachen University</organization>
<address>
<postal>
<street>Ahornstrasse 55</street>
<city>Aachen</city>
<region></region>
<code>52074</code>
<country>Germany</country>
</postal>
<phone>+49 241 80 21422</phone>
<email>zimmermann@cs.rwth-aachen.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author initials="A.H."
surname="Hannemann"
fullname="Arnd Hannemann">
<organization>RWTH Aachen University</organization>
<address>
<postal>
<street>Ahornstrasse 55</street>
<city>Aachen</city>
<region></region>
<code>52074</code>
<country>Germany</country>
</postal>
<phone>+49 241 80 21423</phone>
<email>hannemann@nets.rwth-aachen.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="January" year="2009" />
<!-- 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>Internet Engineering Task Force</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>Transmission Control Protocol (TCP),
Internet Control Message Protocol (ICMP), Long Connectivity
Disruption</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>TCP was designed with fixed, wired networks in mind. As a result
TCP performs suboptimal in networks where connectivity disruptions
are frequent, e.g., in wireless (multi-hop) networks. One reason for
the performance degradation is TCP's over-conservative behavior in
face of long connectivity disruptions.</t>
<t>This document describes how connectivity disruption indications
provided by standard ICMP messages may be exploited to improve TCP's
performance. An RTO revert strategy is proposed that enables earlier
detection of whether connectivity to a previously disconnected peer
node has been restored or not. The scheme is a sender only
modification which fully respects the TCP congestion control
principles.</t>
</abstract>
</front>
<!-- ***** MAIN MATTER ***** -->
<middle>
<!-- ***** Section: Terminology ***** -->
<section title="Terminology">
<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>
<t>The term "acceptable acknowledgment (ACK)" in this document
refers to a TCP segment that acknowledges previously unacknowledged
data (as defined in <xref target='RFC0793' />). The Transmission
Control Protocol (TCP) sender state variable "SND.UNA" and the
current segment variable "SEG.SEQ" are used as defined in <xref
target='RFC0793' />. SND.UNA holds the segment sequence number of
the oldest outstanding segment. SEG.SEQ is the segment sequence
number of a given segment.</t>
</section>
<!-- ***** Section: Introduction ***** -->
<section anchor="introduction" title="Introduction">
<t>Connectivity disruptions can occur in many different situation.
The frequency of the connectivity disruptions depend thereby on the
property of the end-to-end path between the communicating hosts.
While connectivity disruptions can occur in traditional wired
networks too, e.g., simply due to an unplugged network cable, the
likelihood of occurrence is significant higher in wireless
(multi-hop) networks. Especially, end-host mobility and wireless
interferences are crucial factors. In the case the hosts use the
Transmission Control Protocol (TCP) <xref target='RFC0793' /> for
their communication, the performance of the connection can exhibit
a significant reduction compared to a permanently connected path
<xref target='SESB05' />.</t>
<t>According to Schuetz et. al.
<xref target='I-D.schuetz-tcpm-tcp-rlci' /> connectivity disruptions
can be classified into two groups: "short" and "long" connectivity
disruptions. A connectivity disruption is short if connectivity
returns before the retransmission timeout (RTO) fires for the first
time. In this case, TCP recovers lost data segments through Fast
Retransmit and lost ACKs through successfully delivered later ACKs.
Connectivity disruptions are declared as long for a given TCP
connection, if the RTO fires at least once before connectivity
returns. Whether or not path characteristics have changed when the
connectivity returns after a disruption is second important aspect
for TCP's retransmission scheme
<xref target='I-D.schuetz-tcpm-tcp-rlci' />.</t>
<t>This memo will focus on TCP's behavior in face of long
connectivity disruptions in the time "before" connectivity is
restored. Moreover, this document does not describe any additional
optimization to detect if the path characteristics remain
unchanged. Therefore, TCP's RTO based Loss Recovery and in particular
Slow-Start <xref target='RFC2581' /> will be unchanged.</t>
<t>When a long connectivity disruption occurs on path between two
communicating hosts, the TCP sender stops receiving ACKs. After
expiration of the RTO the TCP sender will repeatedly retransmit the
first unacknowledged segment (SND.UNA) until it is successfully
acknowledged. TCP implementations that follow the recommended RTO
management proposed in RFC 2988 <xref target='RFC2988' /> double the
RTO value after each retransmission attempt. However, the RTO growth
may be bounded by an upper limit maximum RTO, which is at least 60s,
but may be longer: Linux for example uses 120s. If the connectivity
is restored between two retransmission attempts, a TCP still have to
wait until the RTO expires before resuming transmission, since TCP
simply does not have any means to know that the connectivity is
re-established. Therefore, depending on when connectivity becomes
available again, this can waste up to maximum RTO of possible
transmission time.</t>
<t>This retransmission behavior is not efficient, especially in
scenarios or networks like wireless (multi-hop) networks where
connectivity disruptions are frequent. In the ideal case, TCP would
attempt a retransmission as soon as connectivity to its peer was
re-established. In this document a method how the standard Internet
Control Message Protocol (ICMP) can be exploited to improve TCP's
performance is described. The presented scheme is a sender only
modification, i.e., neither intermediate routers nor the TCP receiver
have to be modified. Furthermore, the proposed modification
approaches the ideal behavior, if the network allows for it (i.e.,
no congestion is present). By an RTO revert strategy,
higher-frequency retransmissions can be realized to enable earlier
detection of whether connectivity to a previously disconnected peer
node has been restored.</t>
</section>
<!-- ***** Section: Connectivity Disruption Indication ***** -->
<section anchor="cdi" title="Connectivity Disruption Indication">
<t>As long as the queue of a router experiencing a link outage is
deep enough, i.e., it can buffer all incoming packets, a connectivity
disruption will only cause variation in delay which is handled well
by a contemporary TCP with the help of Eifel <xref target='RFC3522' />
or forward RTO (F-RTO) <xref target='RFC4138' />. However, if the link
outage lasts too long, the router experiencing the link outage is
forced to drop packets and finally to discard the according route.
Means to detect such link outages comprise reacting on failed address
resolution protocol (ARP) queries, unsuccessful link sensing, and the
like. However, this is solely in the responsibility of the respective
router.
<list style="empty">
<t>Note: The focus of this memo is on introducing a method how
ICMP messages may be exploited to improve TCP's performance; how
different physical-and link layer mechanisms underneath the
network layer may trigger ICMP destination unreachable messages
are out of scope of this memo.</t>
</list>
</t>
<t>The removal of the route usually goes along with a notification
to the corresponding TCP source about the dropped packets via ICMP
destination unreachable messages of code 0 (net unreachable) or code
1 (host unreachable) <xref target='RFC1812' />. Therefore, since ICMP
destination unreachable messages of these codes are evidence that
packets were dropped due to a link outage, they can be interpreted
as a connectivity disruption indication.</t>
<t>Note that there are also other ICMP destination unreachable
messages with different codes. Some of them are candidates for
connectivity disruption indications too, but need further
investigation. For example ICMP destination unreachable messages
with code 5 (source route failed), code 11 (net unreachable for TOS),
or code 12 (host unreachable for TOS). On the other side codes that
flag hard errors <xref target='RFC1122' /> are of no use for the
proposed scheme. In the following, the term "ICMP unreachable
message" is used as synonym for ICMP destination unreachable
messages of code 0 or code 1.</t>
<t>A router experiencing a link outage is an obvious candidate for
being heavily congested because it is not just unable to forward
packets fast enough, it is even unable to forward packets at all.
Therefore, TCP's exponential back-off may seem appropriate. However,
taking into account the congestion control principles
<xref target='RFC2914' />, i.e., congestion is indicated by packet
loss, receiving an ICMP unreachable message might be an indication
that there is no congestion. For instance, when a (re-)transmission
is replied to with an ICMP unreachable message, this is a strong
indication that there is no congestion in the network - at least on
that very part of the path which was traveled by both, the TCP
segment eliciting the ICMP unreachable message as well as the ICMP
unreachable message itself. Therefore, it seems a little bit harsh
for TCP to back-off as if there was true congestion.</t>
<t>The accurate interpretation of ICMP unreachable messages as
an connectivity disruption indication is complicated by the following
two peculiarities of ICMP messages. Firstly, they do not necessarily
operate on the same timescale as the packets, i.e., in the given case
TCP segments, which elicited them. When a router drops a packet due
to a missing route it will not necessarily send an ICMP unreachable
message immediately, but rather queues it for later delivery.
Secondly, ICMP messages are subject to rate limiting, e.g., when a
router drops a whole window of data due to a link outage, it will
hardly send as many ICMP unreachable messages as it dropped
TCP segments. Depending on the load of the router it may even send
no ICMP unreachable messages at all. Both peculiarities originate
from RFC 1812 <xref target='RFC1812' />.</t>
<t>Fortunately, according to RFC 792 <xref target='RFC0792' /> ICMP
unreachable messages are obliged to contain in their body the
Internet Protocol (IP) header of the datagram eliciting the ICMP
unreachable messages plus the first 64 bits of the payload of that
datagram, i.e., in case of a TCP segment both port numbers and the
sequence number. This allows the originating TCP to identify the
connection which an ICMP unreachable message is reporting an
error about. Moreover, it allows the originating TCP to identify
which segment of the respective connection triggered the ICMP
unreachable message, provided that there are not several segments
in flight with the same sequence number. This may very well be the
case when TCP is recovering lost segments.</t>
</section>
<!-- ***** Section: Connectivity Disruption Reaction ***** -->
<section anchor="cdr" title="Connectivity Disruption Reaction">
<t>The complete algorithm is specified in <xref target='cdr_alg' />.
In section <xref target='cdr_exp' />, the different steps of the
algorithm are discussed in detail.
</t>
<section anchor="cdr_alg" title="The Algorithm">
<t>The following scheme MAY be used by a TCP sender to avoid
over-conservative back-offs of the retransmission timer in the
case of long connectivity disruptions:
<list style='format (%d)'>
<t>Set a "UndoBackOff" variable to UNPROVED (equal 0)
<list style='empty'>
<t>UndoBackOff := UNPROVED.</t>
</list>
</t>
<t>Wait for the expiration the retransmission timer,
proceed to step (RTO).</t>
<t>Wait either
<list style='empty'>
<t>for the arrival of an acceptable ACK. When an
acceptable ACK has arrived, proceed to step
(ACK),</t>
<t>or for the arrival of an ICMP destination
unreachable message. When ICMP destination
unreachable message has arrived, proceed to
step (4),</t>
<t>or for the expiration the retransmission
timer, proceed to step (RTO).</t>
</list>
</t>
<t>Extract the TCP segment header included in the ICMP
destination unreachable message
<list style='empty'>
<t>SEG := Extract(ICMP_MSG).</t>
</list>
</t>
<t>If "SEG.SEQ == SND.UNA", i.e., ICMP unreachable
message reports on a retransmission, then
<list style='empty'>
<t>If "UndoBackOff == UNPROVED", then set the
"UndoBackOff" variable to PROVED (equal 1)
<list style='empty'>
<t>UndoBackOff := PROVED.</t>
</list>
</t>
<t>else revert one RTO back-off
<list style='empty'>
<t>RTO := max(MINIMUM_RTO, RTO / 2).</t>
</list>
</t>
</list>
</t>
<t>Proceed to step (3).</t>
</list>
<list style='hanging' hangIndent='7'>
<t hangText="(RTO)">This is a placeholder for the
standard TCP behavior that must be executed at this
point in the case the retransmission timer is expired.
Proceed to step (3).</t>
<t hangText="(ACK)">This is a placeholder for the
standard TCP behavior that must be executed at this
point in the case an acceptable ACK is arrived. Proceed
to step (1).</t>
</list>
</t>
</section>
<section anchor="cdr_exp" title="The Algorithm in Detail">
<t>When an RTO expires a TCP marks all outstanding segments as
lost, sets the congestion window (CWND) to one segment,
back-offs the RTO, and retransmits the first unacknowledged
segment SND.UNA (step 2). If the RTO expires again a TCP will
repeat the retransmission of the first unacknowledged segment
and back-off again (step 3c). This pattern will be repeated as
long as no packet arrives or until the maximum RTO expired.</t>
<t>If the first received packet after the retransmission(s) is
an acceptable ACK (step 3a), a TCP will proceed as normal, i.e.,
slow-start the connection. It ignores later ICMP unreachable
messages from the window of data which experienced RTO. Late
ICMP unreachable messages are of no use as the ACK clock is
already restarting due to the successful retransmission.</t>
<t>On the other side if the first received packet after the
retransmission(s) is an ICMP unreachable message, a TCP SHOULD
revert one back-off for each ICMP unreachable message reporting
an error on a retransmission. To decide if an ICMP unreachable
message reports on a retransmission, the sequence number therein
is exploited (step 4, step 5).</t>
<t>Nevertheless, the first unacknowledged sequence number is
suffering from the ambiguity if it refers to the original
transmission or to any of the retransmissions. To be
conservative, it should be considered to belong to the original
transmission (step 5a). However, for each next ICMP unreachable
message reporting on the retransmission, TCP SHOULD revert one
back-off (step 5b).</t>
<t>Upon receipt of an ICMP unreachable message which legitimately
reverts one back-off there is the possibility that this new RTO
has expired already. Then, a TCP SHOULD retransmit immediately,
i.e., an ICMP message clocked retransmission. In case the new
RTO has not expired yet, TCP MUST wait accordingly.</t>
</section>
</section>
<!-- ***** Section: Discussion ***** -->
<section anchor="discussion" title="Discussion">
<t>Apart from the possibility to receive ICMP unreachable messages
reporting on the sequence number of the retransmission, there might
as well arrive ICMP unreachable messages reporting on the original
window of data while a TCP is in RTO induced recovery. As TCP
cannot decide by a single or a few ICMP unreachable messages if the
whole window of data was dropped because of a link outage, there is
the option that at least one of the segments was dropped due to true
congestion in the network, calling for back-off. Therefore, to be
conservative, a TCP MUST NOT revert the back-off in such a case
(step 5a). Although, there is still the unlikely possibility that
the intermediate router indeed sends an ICMP unreachable message for
each dropped segment. Then, TCP should be allowed to even revert the
first back-off. However, as this case is very unlikely and requires
one more state variable to detect it is not recommended in this
document.</t>
<t>Besides the ambiguity if the first unacknowledged sequence number
refers to the original transmission or to any of the retransmissions,
there is another source of ambiguity about the sequence numbers
contained in the ICMP unreachable messages. For high bandwidth paths
like modern gigabit links the sequence space may wrap rather quickly,
thereby allowing the possibility that a late ICMP unreachable message
reporting on an old error may coincidentally fit as input in the
scheme explained above. As a result, the scheme would wrongly revert
one back-off. However, chances for this to happen are minuscule.
Moreover, as the scheme is tailored most conservatively no threat to
the network from this issues may arise.</t>
<t>Finally, the scheme explicitly does not call for a differentiation
of ICMP unreachable messages originating from different routers, as
the evidence of no congestion still holds even if the reporting
router changed.</t>
<t>Another exploitation of ICMP unreachable messages in the context
of TCP congestion control might seem appropriate in case the ICMP
unreachable message is received while TCP is in steady-state and the
message refers to a segment from within the current window of data.
As the round trip time (RTT) up to the router which generates the
ICMP unreachable message is likely to be substantially shorter than
the overall RTT to the destination, the ICMP unreachable message may
very well reach the originating TCP while it is transmitting the
current window of data. In case the remaining window is large, it
might seem appropriate to refrain from transmitting the remaining
window as there is timely evidence that it will only trigger further
ICMP unreachable messages at the very router. Although this might
seem appropriate from a wastage perspective, it may be
counterproductive from a security perspective since ICMP messages
are easy to spoof, thereby allowing an easy attack to the TCP by
simply forging such ICMP messages.</t>
<t>An additional consideration is the following: in the presence of
multi-path routing even the receipt of a legitimate ICMP unreachable
message cannot be exploited accurately because there is the option
that only one of the multiple paths to the destination is suffering
from a connectivity disruption which causes ICMP unreachable messages
to be sent. Then however, there is the possibility that the path
along which the connectivity disruption occurred contributed
considerably to the overall bandwidth, such that a congestion
response is very well reasonable. However, this is not necessarily
the case. Therefore, a TCP has no means except for its inherent
congestion control to decide on this matter. All in all, it seems
that for a connection in steady-state, i.e., not in RTO induced
recovery, reacting on ICMP unreachable messages in regard to
congestion control is not appropriate. For the case of RTO-based
retransmissions, however, there is a reasonable congestion response,
which is skipping further back-off of the RTO because there is no
congestion indication - as described above.</t>
</section>
<!-- ***** Section: Related Work ***** -->
<section anchor="related_work" title="Related Work">
<t>In literature there are several methods, which address TCP's
problems in the presence of connectivity disruptions. Some of them
try to improve TCP's performance by modifying the lower layers. For
example <xref target='SM03'/> introduces a "smart link layer"
that buffers one segment for each ongoing connection and replaying
these segments on connectivity reestablishment. This approach has a
serious drawback: previously state-less intermediate routers have to
be modified in order to inspect TCP headers, track the end-to-end
connection and to provide additional buffer space that lead all in
all to an additional need of memory and processing power.</t>
<t>On the other hand stateless link layer schemes, like proposed in
RFC 3819 <xref target='RFC3819'/>, which unconditionally buffer some
small number of packets may have another problem: if a packet is
buffered longer than the maximum segment lifetime (MSL) of
<xref target='RFC0793' /> 2 min, i.e., the disconnection lasts longer
than MSL, TCP's assumption that such segments will never be received
will no longer be true, violating TCP's semantics
<xref target='I-D.eggert-tcpm-tcp-retransmit-now' />.</t>
<t>Other approaches like TCP-F <xref target='CRVP01' /> or the
Explicit Link Failure Notification (ELFN) <xref target='HV02' />
inform the TCP senders about disrupted paths by special messages
generated from intermediate routers. In case of a link failure they
stop sending data segments and freeze TCP's retransmission timers.
TCP-F stays in this state and remains silent until either a "route
establishment notification" is received or an internal timer expires.
In contrast, ELFN periodically probes the network to detect
connectivity reestablishment. Both proposals rely on changes to
intermediate routers, whereas the scheme proposed in this memo is a
sender only modification. Moreover, ELFN also does not consider
congestion in the network and may impose serious additional load on
the network, depending on the probe interval.</t>
<t>The authors of ATCP <xref target='LS01' /> propose enhancements
to identify different types of packet loss, by introducing a layer
between TCP and IP. They utilize ICMP destination unreachable
messages to set TCP's receiver advertised window to zero and thus
forcing the TCP sender to do zero window probing with exponential
back-off. ICMP destination unreachable messages, which arrive during
this probing period, are ignored. This approach is nearly orthogonal
to this memo, which exploits ICMP messages to revert a RTO back-off,
when TCP is already probing. In principle both mechanisms could be
combined, however, due to security considerations it does not seem
appropriate to adopt ATCP's reaction as discussed in
<xref target='discussion' />.</t>
<t>Schuetz et al. describe in
<xref target='I-D.schuetz-tcpm-tcp-rlci' /> a set of TCP extensions
that improve behavior when transmitting over paths whose
characteristics can change on short time-scales. Their proposed TCP
extensions modify the local behavior of TCP and introduce a new TCP
option to signal locally received connectivity-change indications
(CCIs) to remote peers. Upon reception of a CCI, they re-probe the
path characteristics either by performing a speculative
retransmission or by sending a single segment of new data, depending
on whether the connection is currently in the loss state or
transmitting in steady-state, respectively. The authors focus on
specifying TCP response mechanisms, nevertheless underlying layers
would have to be modified to explicitly send CCIs to make these
immediate responses possible.</t>
</section>
<!-- ***** Section: Acknowledgements ***** -->
<!-- ***** Section: Contributors ***** -->
<!-- ***** Section: IANA Considerations ***** -->
<section anchor="iana" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<!-- ***** Section: Security Considerations ***** -->
<section anchor="security" title="Security Considerations">
<t>The proposed mechanism is considered to be secure. For example an
attacker cannot make a TCP modified with proposed scheme flood the
network just by sending forged ICMP unreachable messages reverting
RTO back-offs. Even in the case the attacker could correctly guess
the sequence number of the current retransmitted segment, the
retransmission frequency is limited by the minimum value for the RTO
of 1s specified by RFC 2988 <xref target='RFC2988' />.</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">
&rfc792;
&rfc793;
&rfc1812;
&rfc2581;
&rfc2988;
</references>
<references title="Informative References">
&rfc1122;
&rfc2119;
&rfc2914;
&rfc3522;
&rfc3819;
&rfc4138;
&retransmit-now;
&tcp-rlci;
<reference anchor="SESB05" target="">
<front>
<title>Protocol enhancements for intermittently connected
hosts</title>
<author surname="Schuetz" initials="S."
fullname="Simon Schuetz">
<organization />
</author>
<author surname="Eggert" initials="L."
fullname="Lars Eggert">
<organization />
</author>
<author surname="Schmid" initials="S."
fullname="Stefan Schmid">
<organization />
</author>
<author surname="Brunner" initials="M."
fullname="Marcus Brunner">
<organization />
</author>
<date year="2005" month="December"/>
</front>
<seriesInfo name="SIGCOMM Computer Communication Review"
value="vol. 35, no. 3, pp. 5-18" />
</reference>
<reference anchor="SM03" target="">
<front>
<title>Link layer-based TCP optimisation for disconnecting
networks</title>
<author surname="Scott" initials="J."
fullname="James Scott">
<organization />
</author>
<author surname="Mapp" initials="G."
fullname="Glenford Mapp">
<organization />
</author>
<date year="2003" month="October"/>
</front>
<seriesInfo name="SIGCOMM Computer Communication Review"
value="vol. 33, no. 5, pp. 31-42" />
</reference>
<reference anchor="CRVP01" target="">
<front>
<title>A feedback-based scheme for improving TCP performance
in ad hoc wireless networks</title>
<author surname="Chandran" initials="K."
fullname="Kartik Chandran">
<organization />
</author>
<author surname="Raghunathan" initials="S."
fullname="Sudarshan Raghunathan">
<organization />
</author>
<author surname="Venkatesan" initials="S."
fullname="Subbarayan Venkatesan">
<organization />
</author>
<author surname="Prakash" initials="R."
fullname="Ravi Prakash">
<organization />
</author>
<date year="2001" month="February"/>
</front>
<seriesInfo name="IEEE Personal Communications"
value="vol. 8, no. 1, pp. 34-39" />
</reference>
<reference anchor="HV02" target="">
<front>
<title>Analysis of TCP performance over mobile ad hoc
networks</title>
<author surname="Holland" initials="G."
fullname="Gavin Holland">
<organization />
</author>
<author surname="Vaidya" initials="N."
fullname="Nitin Vaidya">
<organization />
</author>
<date year="2002" month="March"/>
</front>
<seriesInfo name="Wireless Networks"
value="vol. 8, no. 2-3, pp. 275-288" />
</reference>
<reference anchor="LS01" target="">
<front>
<title>ATCP: TCP for mobile ad hoc networks</title>
<author surname="Liu" initials="J."
fullname="Jian Liu">
<organization />
</author>
<author surname="Singh" initials="S."
fullname="Suresh Singh">
<organization />
</author>
<date year="July" month="2001"/>
</front>
<seriesInfo name="IEEE Journal on Selected Areas in
Communications" value="vol. 19, no. 7, pp. 1300-1315" />
</reference>
<!--
<reference anchor="ZSH08" target="">
<front>
<title>Improving TCP's Robustness to Long Connectivity
Disruptions</title>
<author surname="Zimmermann" initials="A."
fullname="Alexander Zimmermann">
<organization />
</author>
<author surname="Schaffrath" initials="D."
fullname="Daniel Schaffrath">
<organization />
</author>
<author surname="Hannemann" initials="A."
fullname="Arnd Hannemann">
<organization />
</author>
<date year="2008" month="November"/>
</front>
<seriesInfo name="Proceedings of the 20th IEEE Global
Communications Conference (GLOBECOM'08)" value="" />
</reference>
-->
</references>
<!--
<section anchor="appendix" title="Appendix">
<t>This becomes an Appendix.</t>
</section>
-->
<!-- Change Log
v00 2006-03-15 AZ Initial version -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:32:22 |