[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                          L. Eggert
Internet-Draft                                                S. Schuetz
Expires: March 11, 2005                                        S. Schmid
                                                                     NEC
                                                      September 10, 2004



              TCP Extensions for Immediate Retransmissions
                draft-eggert-tcpm-tcp-retransmit-now-01


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.  This document may not be modified, and derivative works of
   it may not be created, except to publish it as an RFC and to
   translate it into languages other than English.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on March 11, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document describes a modification to TCP's standard
   retransmission scheme that improves performance across intermittently
   connected paths.  In addition to the regular retransmission attempts
   scheduled at exponentially increasing intervals, this extension




Eggert, et al.           Expires March 11, 2005                 [Page 1]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   causes additional, speculative retransmission attempts upon receiving
   external connectivity indicators.  One example of such a connectivity
   indicator is "first hop router reachable." This document does not
   define the specifics of such connectivity indicators, although it
   describes some examples.  Instead, it defines how a conforming TCP
   implementation operates when it receives a connectivity indicator.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Examples of Connectivity Indicators  . . . . . . . . . . . . .  5
   5.  TCP Immediate Retransmission Extension . . . . . . . . . . . .  6
     5.1   Variant Based on Fast Retransmit . . . . . . . . . . . . .  8
     5.2   Variant Based on Retransmission Option . . . . . . . . . .  9
   6.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 11
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 12
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 12
       Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16
























Eggert, et al.           Expires March 11, 2005                 [Page 2]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



1.  Introduction


   Depending on the specific path between two nodes in the Internet,
   disruptions in connectivity may be frequent.  Host mobility and other
   factors can further increase the likelihood of connectivity
   disruptions.  When hosts communicate with the Transmission Control
   Protocol (TCP) [1], their connections may abort during periods of
   disconnection.


   The main reason for connection aborts during periods of disconnection
   is TCP's "user timeout." It defines the maximum amount of time that
   transmitted segments may remain unacknowledged.  If a disconnection
   lasts longer than the user timeout, the TCP connection will abort.
   Many TCP implementations default to user timeout values of a few
   minutes [7].  The proposed TCP Abort Timeout Option [8] allows
   conforming TCP implementations to use longer user timeout values and
   consequently tolerate long disconnections without disruption.


   Although the TCP Abort Timeout Option enables TCP connections to
   survive extended periods of disconnections, experiments have shown
   that TCP connections perform significantly worse when operating along
   paths with frequent disconnections [9][10].  This decrease in
   performance is caused by TCP's retransmission behavior after
   connectivity is restored.


   This document describes a modification of TCP's retransmission scheme
   to improve performance over a path with frequent disconnections.  The
   basic idea is to trigger a speculative retransmission attempt when a
   TCP implementation receives an indication that connectivity to a
   previously disconnected peer node may have been restored.
   [Comment.1]


   Section 3 discusses TCP performance over intermittently connected
   paths in more detail, comparing it to similar proposals [11][12][13],
   and Section 4 describes the proposed "immediate retransmission"
   extension to TCP.  Section 7 investigates security aspects of the
   proposed modification and Section 8 summarizes and concludes this
   document.


2.  Conventions


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].


3.  Background


   When a disconnection occurs along the path between a host and its




Eggert, et al.           Expires March 11, 2005                 [Page 3]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   peer while the host is transmitting data, it stops receiving
   acknowledgments.  After the retransmission timeout (RTO) expires, the
   host attempts to retransmit the first unacknowledged segment.  TCP
   implementations that follow the recommended RTO management proposed
   in RFC 2988 [3] double the RTO after each retransmission attempt
   until it exceeds 60 seconds.  This scheme causes a host to attempt to
   retransmit across established connections roughly once a minute.
   (More frequently during the first minute or two of the disconnection,
   while the RTO is still being backed off.)


   When the disconnection ends, standard TCP implementations still wait
   until the RTO expires before attempting retransmission.  Figure 1
   illustrates this behavior.  Depending on when connectivity becomes
   available again, this can waste up to a minute of connection time for
   TCPs that implement the recommended RTO management described in RFC
   2988 [3].  For TCP implementations that do not implement RFC 2988,
   even more connection time may be lost.  For example, Linux uses 120
   seconds as the maximum RTO.


        sequence
        number      X = successfully transmitted segment
         ^          O = lost segment
         |     :                     :              : X
         |     :                     :              :X
         |     XO O  O    O        O :              X
         |    X:                     :              :
         |   X :                     :<------------>:
         |  X  :                     :    wasted    :
         | X   :                     :  connection  :
         |X    :                     :     time     :
         +-----:---------------------:--------------:-------->
               :                     :              :       time
          connectivity          connectivity       TCP
             gone                  back         retransmit


   Figure 1: Standard TCP behavior in the presence of a disconnection


   This retransmission behavior is not efficient, especially in
   scenarios where connected periods are short and disconnections
   frequent [14].  Experiments show that TCP performance across a path
   with frequent disruptions is significantly worse compared to a
   similar path without disruptions [9][10].


   In the ideal case, TCP would attempt a retransmission as soon as
   connectivity to its peer was re-established.  Figure 2 illustrates
   the ideal behavior.






Eggert, et al.           Expires March 11, 2005                 [Page 4]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



        sequence
        number      X = successfully transmitted segment
         ^          O = lost segment
         |     :                     : X            :
         |     :                     :X             :
         |     XO O  O    O        O X              :
         |    X:                     :              :
         |   X :                     :<------------>:
         |  X  :                     :  efficiency  :
         | X   :                     :  improvement :
         |X    :                     :              :
         +-----:---------------------:--------------:-------->
               :                     :              :       time
          connectivity          connectivity      next
             gone             back = immediate  scheduled
                               TCP retransmit   retransmit


    Figure 2: Ideal TCP behavior in the presence of a disconnection


   The ideal behavior is difficult to achieve for arbitrary connectivity
   disruptions.  One obviously problematic approach would use
   higher-frequency retransmission attempts to enable earlier detection
   of whether connectivity was restored.  This can generate significant
   amounts of extra traffic.  Other proposals attempt to trigger faster
   retransmissions by retransmitting buffered or newly-crafted segments
   from inside the network [11][12][13].  Section 6 compares these
   approaches to the "immediate retransmission" extension.


4.  Examples of Connectivity Indicators


   This section describes examples of connectivity indicators, which the
   retransmission mechanism described in the next section acts upon.
   This document does not define the specifics of such connectivity
   indicators but merely discusses them to illustrate the operation of
   the "immediate retransmission" extension.


   Connectivity indicators signal TCP when connectivity to a previously
   disconnected peer may have been restored.  They depend on the
   specifics of a node and its environment, for example network-layer
   mechanisms such as DHCP [15], MobileIP [16] or HIP [17].  The IETF's
   Detection of Network Attachment (DNA) working group currently
   investigates the specifics of providing such connectivity indicators
   [18].


   One example of a connectivity indicator is "next hop reachable." This
   indicator could occur if a combination of the following conditions is
   true, depending on host specifics:





Eggert, et al.           Expires March 11, 2005                 [Page 5]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   o  Network-layer connectivity along the path to the destination is
      restored, e.g., the outbound interface has an IP address and a
      next-hop router is known, maybe due to DHCP [15] or IPv6 router
      advertisements [19].


   o  Link-layer connectivity of the link to the next-hop router along
      the path to the destination is restored (e.g., link-layer "link
      up").


   o  Other local conditions that affect reachability of the destination
      are satisfied (e.g., IKE exchanges [20], MobileIP binding updates
      [16] or HIP readdressing [21] have completed).


   The "next hop reachable" connectivity indicator only depends on
   locally determinable information (e.g., state of directly-connected
   links, etc.) and does not require network cooperation.  It can signal
   TCP to restart active connections across intermittently connected
   links where disruptions occur on the first or last hop.  This simple
   indicator has the potential to improve TCP performance in many cases,
   because connection disruptions at the first or last hop are arguably
   the most common cause of disconnections in today's Internet.


   A second, more general example of a connectivity indicator would be
   "end-to-end connectivity restored." If hosts have the ability to
   detect or be notified of connectivity changes inside the network
   (i.e., not only at the first or last hop), a more general
   retransmission mechanism could act on those pieces of information.
   This can improve TCP performance across intermittently connected
   paths where disruptions occur at arbitrary links along the path, even
   inside the network.  However, providing this more general
   connectivity indicator is problematic due to its dependence on remote
   information and its related issues, such as trust.


   Connectivity indicator are generally asymmetric, i.e., they may occur
   on one peer host but not the other.  As discussed above, a local
   event at one host may trigger the "immediate retransmission"
   mechanism, while the other host is unable to detect this event across
   the network.  Symmetric connectivity indicators are a special case
   and always occur concurrently at both communicating hosts.  Examples
   for such symmetric connectivity indicators are handshake events such
   as IKE exchanges or HIP readdressing.  Symmetric indicators are an
   important special case, because the retransmission procedure required
   in response to a symmetric indicator is simpler than that for an
   asymmetric one.  The next section will describe this in detail.


5.  TCP Immediate Retransmission Extension


   This section describes the main contribution of this document, i.e.,




Eggert, et al.           Expires March 11, 2005                 [Page 6]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   TCP extensions for immediate retransmission in response to
   connectivity indicators.  The basic idea behind the "immediate
   retransmission" extension is to allow TCP to restart stalled
   connections as soon as it receives an indicator that connectivity to
   previously disconnected peers may have been restored.


   This document does not specify how TCP determines which connections
   are affected by a specific connectivity indicator, i.e., for which
   connections it should initiate retransmission attempts.  This is a
   property of individual connectivity indicators.  For example, the
   "next hop reachable" indicator described in the previous section
   affects connections to all destinations routed through that hop.


   It is important to note that this retransmission extension does not
   modify TCP's basic congestion control, fairness properties or
   slow-start algorithms.  The only difference in TCP behavior is the
   timing of retransmission events and, in some cases, a minor, fixed
   increase in the number of initially retransmitted segments.  The
   "immediate retransmission" extensions increases performance through
   better utilization of connected periods, not through sending traffic
   at a faster rate or modifying TCP's congestion control mechanisms.


   Hosts that implement the "immediate retransmission" TCP extension
   MUST implement the following retransmission mechanism whenever a
   connectivity indicator is received:


   When receiving a symmetric or asymmetric connectivity indicator,
   conforming TCP implementations MUST immediately initiate the standard
   retransmission procedure for connections affected by the connectivity
   indicator - just as if the RTO for those connections had expired.


   If the connectivity indicator is symmetric, i.e., all peers receive
   it concurrently; this simple change is sufficient to kick-start the
   relevant TCP connections.


   If the connectivity indicator is asymmetric, this simple extension is
   not always sufficient, because only one peer has received the
   indicator.  In case the host receiving the connectivity indicator has
   no (or too little) unacknowledged data awaiting retransmission, it
   will not emit enough segments to cause its peer node, which may have
   unacknowledged data as well, to attempt retransmission.  Transmission
   would thus only resume in one direction, which is ineffective for
   two-way communication.


   To avoid this issue, conforming TCP implementation MUST perform a
   different retransmission procedure in response to an asymmetric
   connectivity indicator.  The following sections describe two
   alternative TCP modifications that aim to improve retransmission




Eggert, et al.           Expires March 11, 2005                 [Page 7]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   behavior after receiving an asymmetric connectivity indicator.
   Section 5.1 describes the first variant.  As described in an earlier
   revision of this document, this variant generates duplicate ACKs to
   activate the peer's fast retransmit algorithm.  Section 5.2 describes
   the second variant, based on an explicit, new TCP "immediate
   retransmission" option.


5.1  Variant Based on Fast Retransmit


   This variant of improving TCP retransmission scheme based on
   connectivity indicators uses duplicate ACKs.  Conforming TCPs MUST
   send at least four segments that all acknowledge the last segment
   received from a peer for all connections affected by the connectivity
   indicator.  These triple-duplicate ACKs will activate the peers' fast
   retransmit algorithms and cause them to immediately restart
   communication in the reverse direction, i.e., before their next
   scheduled retransmission.


   In this variant, if a TCP connection affected by a connectivity
   indicator has four or more unacknowledged data segments in the
   retransmission queue, it SHOULD piggyback the triple-duplicate ACK to
   the regular retransmissions of those data segments.  In this case,
   the "immediate retransmission" TCP extension does not require
   additional messages, compared to standard TCP.


   For connections where the retransmission queue contains only three or
   less unacknowledged data segments, TCP implementations supporting the
   "immediate retransmission" TCP extension MUST send additional pure
   ACKs until a complete triple-duplicate ACK has been sent.  In the
   worst case, when the retransmission queue is empty, this scheme
   requires four additional ACKs, compared to standard TCP.


   After the peer's fast retransmit algorithm sends the assumed missing
   segment, TCP performs either fast recovery or a slow-start [4],
   depending on the length of the disconnection.  If the connectivity
   indicator occurs before the RTO, i.e., for very short disconnections,
   TCP has not yet lost its ACK clock and can thus perform fast
   recovery.  After longer disconnections, TCP falls back to slow-start
   to restart the ACK clock, just as it does at the beginning of a
   connection.


   The result of this modification is twofold.  First, TCP connections
   receiving the connectivity indicator attempt retransmission of their
   unacknowledged segments before the next scheduled RTO.  This
   increases utilization of connected periods.  Second, TCP connections
   receiving the connectivity indicator use an existing TCP mechanism
   (triple-duplicate ACK) to signal their peer.  Although the peer may
   not have received a connectivity indicator itself (e.g., the




Eggert, et al.           Expires March 11, 2005                 [Page 8]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   indicator was asymmetric), this causes it to attempt faster
   retransmission as well.


   As mentioned above, the "immediate retransmission" scheme can
   generate up to four additional segments, compared to standard TCP.
   All additional segments are pure ACKs and hence small, resulting in a
   minor total overhead.  Furthermore, measurements have shown that
   increasing TCP's initial window is not problematic [22]; this may
   indicate that a minor increase in traffic at retransmission time may
   be tolerable as well.


5.2  Variant Based on Retransmission Option


   Unlike the mechanism described in the previous section, the second
   variant described in this section does not overload an existing TCP
   mechanism - i.e., fast retransmit - to improve retransmission after a
   disconnection.  Generating duplicate ACKs in the manner described in
   Section 5.1 was criticized by some working group participants as an
   abuse of a well-defined TCP mechanism for an unrelated purpose.


   The variant described in this section uses a newly defined TCP
   "Immediate Retransmission" Option to explicitly signal the remote
   peer to activate its fast retransmit algorithm instead of generating
   duplicate ACKS.  It was suggested by Kacheong Poon [23].


   In this variant, conforming TCP implementations MUST send a single
   segment to each peer affected by a connectivity indicator.  This
   segment will contain the TCP Immediate Retransmission Option and may
   either be a retransmission or a pure ACK if the connection has no
   data awaiting retransmission.  Upon reception of such an option,
   conforming TCPs MUST immediately initiate their fast retransmit
   algorithm.


   The TCP Immediate Retransmission Option could be a single-byte
   option.  Use of this option MUST be negotiated during the SYN
   handshake in the usual way.  [Comment.2]


   One major drawback of this variant compared to the one described in
   Section 5.1 is that it requires both communicating TCPs to implement
   this modification.  Triggering a peer's fast retransmit with
   duplicate ACKs only requires the triggering local peer to support
   this extension - the triggered remote peer may run an unmodified TCP
   stack.  Additionally, firewalls may block segments carrying unknown
   TCP options.  Finally, TCP option space is becoming limited.


6.  Related Work


   Several other approaches try to improve TCP performance in the




Eggert, et al.           Expires March 11, 2005                 [Page 9]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   presence of connectivity disruptions [11][12][13].  They attempt to
   improve TCP startup after a disconnection by retransmitting buffered
   or newly-crafted segments from inside the network.


   These proposals can be problematic, because TCP is built on the
   assumption that segments older than the maximum segment lifetime
   (MSL) of 2 minutes [1] will never be received.  When a disconnection
   lasts longer than the MSL, these proposals will either become
   ineffective or risk leaking buffered old segments onto new
   connections, violating TCP's semantics.


   The "immediate retransmission" modification also improves performance
   over a path with frequent disconnections.  The basic idea is to
   schedule an additional, speculative retransmission attempt when a TCP
   implementation receives an indication that connectivity to a peer
   node has been restored.  Unlike the other proposals, the "immediate
   retransmission" scheme uses regular retransmissions, i.e.,
   retransmits data that is buffered at the end systems.  Because that
   data has not entered the network yet, it is not subject to the
   problematic MSL rule.  Consequently, the "immediate retransmission"
   scheme remains effective even for disconnections longer than the MSL,
   without the risk of compromising connection integrity.


   Other transport-layer approaches such as the Explicit Link Failure
   Notification [24] or TCP-F [25] use specific messages generated by
   intermediate routers to inform TCP senders about disrupted paths.
   The former extends the TCP state machine with a new "stand by" state
   during which the standard retransmission timers are disabled.  In
   this state, TCP periodically probes the network to detect
   connectivity reestablishment.  Depending on the frequency of the
   probes and the network environment, this can cause significant
   amounts of extra traffic.  TCP-F completely suspends ongoing
   connections until receiving "route reestablishment notifications"
   that indicate peer reachability.  Both proposals are primarily
   designed for ad hoc networks and rely on changes to intermediate
   routers, whereas the "immediate retransmission" extension only
   requires end system support.


   ATCP [26] uses a similar approach as the Explicit Link Failure
   Notification, but discovers link failures through ICMP Destination
   Unreachable messages.  Caceres and Iftode [27] propose and evaluate a
   solution similar to the TCP "immediate" retransmission extension that
   improves performance during MobileIP handoffs.  Unlike the solution
   proposed in this paper, the handoff mechanism is targeted at
   disconnections of a few seconds.







Eggert, et al.           Expires March 11, 2005                [Page 10]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



7.  Security Considerations


   To protect against abuse of the TCP "immediate retransmission"
   extension, e.g., denial-of-service attacks by flooding TCP with
   connectivity indicators, a control mechanism that "rate-limits" these
   indicators may be effective.  This document does not currently
   discuss the security aspects of connectivity indicators and the
   "immediate retransmission" extension to TCP.


8.  Conclusion


   This document described the "immediate retransmission" extension to
   TCP's standard retransmission scheme.  The new extension improves
   performance across intermittently connected paths through additional,
   speculative retransmission attempts upon receiving external
   connectivity indicators.  One example of such a connectivity
   indicator is "first hop router reachable." This document did not
   define the specifics of such connectivity indicators, although it
   described some examples to illustrate the operation of the "immediate
   retransmission" extension, which is its main contribution.


9.  IANA Considerations


   This section is to be interpreted according to [5].


   This document does not define any new namespaces.  It uses an 8-bit
   TCP option number maintained by IANA at
   http://www.iana.org/assignments/tcp-parameters.


10.  Acknowledgments


   The following people have helped to improve this document through
   thoughtful suggestions and feedback: Marcus Brunner, Kacheong Poon,
   Juergen Quittek and Joe Touch.


   Part of this work is a product of the Ambient Networks project,
   partially supported by the European Commission under its Sixth
   Framework Programme.  It is provided "as is" and without any express
   or implied warranties, including, without limitation, the implied
   warranties of fitness for a particular purpose.  The views and
   conclusions contained herein are those of the authors and should not
   be interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.


11.  References






Eggert, et al.           Expires March 11, 2005                [Page 11]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



11.1  Normative References


   [1]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.


   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [3]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
        Timer", RFC 2988, November 2000.


   [4]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
        RFC 2581, April 1999.


   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.


   [6]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.


11.2  Informative References


   [7]   Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
         Addison-Wesley , 1994.


   [8]   Eggert, L., "TCP Abort Timeout Option",
         draft-eggert-tcpm-tcp-abort-timeout-option-01 (work in
         progress), July 2004.


   [9]   Schuetz, S., "Network Support for Intermittently Connected
         Mobile Nodes", M.S. Thesis, University of Mannheim, Germany,
         June 2004.


   [10]  Schuetz, S., Eggert, L., Schmid, S. and M. Brunner, "Protocol
         Enhancements for Intermittently Connected Hosts", under
         submission (work in progress), July 2004.


   [11]  Scott, J. and G. Mapp, "Link layer-based TCP optimisation for
         disconnecting networks", ACM Computer Communication Review,
         Vol. 33, No. 5, October 2003.


   [12]  Dawkins, S., "End-to-end, Implicit 'Link-Up' Notification",
         draft-dawkins-trigtran-linkup-01 (work in progress), October
         2003.


   [13]  Karn, P., "Advice for Internet Subnetwork Designers",
         draft-ietf-pilc-link-design-15 (work in progress), December
         2003.





Eggert, et al.           Expires March 11, 2005                [Page 12]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   [14]  Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for
         Automobile Users", Proc. INFOCOM 2004, March 2004.


   [15]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.


   [16]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.


   [17]  Moskowitz, R., "Host Identity Protocol Architecture",
         draft-moskowitz-hip-arch-06 (work in progress), June 2004.


   [18]  Choi, J., "Detecting Network Attachment in IPv6 Goals",
         draft-ietf-dna-goals-00 (work in progress), June 2004.


   [19]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.


   [20]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.


   [21]  Nikander, P., "End-Host Mobility and Multi-Homing with Host
         Identity Protocol", draft-nikander-hip-mm-02 (work in
         progress), July 2004.


   [22]  Allman, M., Hayes, C. and S. Ostermann, "An Evaluation of TCP
         with Larger Initial Windows.", ACM Computer Communication
         Review, Vol. 28, No. 3, July 1998.


   [23]  Poon, K., "Personal Communication", August 2004.


   [24]  Holland, G. and N. Vaidya, "Analysis of TCP Performance over
         Mobile Ad Hoc Networks", Proc. 5th Annual ACM/IEEE
         International Conference on Mobile Computing and Networking,
         1999.


   [25]  Chandran, K., Raghunathan, S., Venkatesan, S. and R. Prakash,
         "A Feedback Based Scheme For Improving TCP Performance In
         Ad-Hoc Wireless Networks", IEEE Personal Communication Systems
         (PCS) Magazine: Special Issue on Ad Hoc Networks, Vol. 8, No.
         1, February 2001.


   [26]  Liu, J. and S. Singh, "ATCP: TCP for Mobile Ad Hoc Networks",
         IEEE Journal on Selected Areas in Communication, Vol. 19, No.
         7, July 2001.


   [27]  Caceres, R. and L. Iftode, "Improving the Performance of
         Reliable Transport Protocols in Mobile Computing Environments",




Eggert, et al.           Expires March 11, 2005                [Page 13]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



         IEEE Journal on Selected Areas in Communication, Vol. 13, No.
         5, 1995.


Editorial Comments


   [Comment.1]  LE: The authors have seen the idea of triggering
                retransmits based on connectivity events of
                directly-connected links attributed to Phil Karn, but
                were unable to locate a specific reference. Pointers are
                highly appreciated.


   [Comment.2]  LE: If this variant is seen as superior, the details of
                the negotiation must be described here.



Authors' Addresses


   Lars Eggert
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany


   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   EMail: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/



   Simon Schuetz
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany


   Phone: +49 6221 90511 10
   Fax:   +49 6221 90511 55
   EMail: simon.schuetz@netlab.nec.de
   URI:   http://www.netlab.nec.de/













Eggert, et al.           Expires March 11, 2005                [Page 14]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



   Stefan Schmid
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany


   Phone: +49 6221 90511 54
   Fax:   +49 6221 90511 55
   EMail: stefan.schmid@netlab.nec.de
   URI:   http://www.netlab.nec.de/


Appendix A.  Document Revision History


   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Initial version.                                      |
   | 01        | Updated terminology according to [10]. Added          |
   |           | "retransmission option" variant as Section 5.2.       |
   +-----------+-------------------------------------------------------+
































Eggert, et al.           Expires March 11, 2005                [Page 15]


Internet-Draft    TCP Extensions for Immediate Retransmissions        September 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Eggert, et al.           Expires March 11, 2005                [Page 16]