Internet DRAFT - draft-ietf-pilc-error


Internet Engineering Task Force                               S. Dawkins
INTERNET DRAFT                                             G. Montenegro
                                                                 M. Kojo
                                                               V. Magret
                                                               N. Vaidya

                                                           June 16, 2001

        End-to-end Performance Implications of Links with Errors


Status of This Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Comments should be submitted to the PILC mailing list at

   Distribution of this memo is unlimited.

   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 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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   The rapidly-growing Internet is being accessed by an
   increasingly wide range of devices over an increasingly wide
   variety of links. At least some of these links do not provide
   the degree of reliability that hosts expect, and this expansion into
   unreliable links causes some Internet protocols, especially TCP
   [RFC793], to perform poorly.

Expires December 16, 2001                                       [Page 1]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   Specifically, TCP congestion control [RFC2581], while
   appropriate for connections that lose traffic primarily
   because of congestion and buffer exhaustion, interacts badly
   with uncorrected errors when TCP connections traverse links with
   high uncorrected error rates. The result is that sending TCPs may
   spend an excessive amount of time waiting for acknowledgements that
   do not arrive, and then, although these losses are not due to
   congestion-related buffer exhaustion, the sending TCP transmits at
   substantially reduced traffic levels as it probes the network to
   determine "safe" traffic levels.

   This document discusses the specific TCP mechanisms that are
   problematic in these environments, and discusses what can be done
   to mitigate the problems without introducing intermediate devices
   into the connection.

   This document does not address issues with other transport
   protocols, for example, UDP.

Expires December 16, 2001                                       [Page 2]
INTERNET DRAFT          PILC - Links with Errors               June 2001

Table of Contents

1.0 Introduction ..................................................    4
   1.1 Should you be reading this recommendation?  ................    4
   1.2 Relationship of this recommendation to PEPs ................    5
   1.3 Relationship of this recommendation to Link Layer Mechan-
isms ..............................................................    6
2.0 Errors and Interactions with TCP Mechanisms ...................    6
   2.1 Slow Start and Congestion Avoidance [RFC2581] ..............    6
   2.2 Fast Retransmit and Fast Recovery [RFC2581] ................    7
   2.3 Selective Acknowledgements [RFC2018, RFC2883] ..............    9
3.0 Summary of Recommendations ....................................   10
4.0 Topics For Further Work .......................................   10
   4.1 Achieving, and maintaining, large windows ..................   11
5.0 Security Considerations .......................................   12
6.0 IANA Considerations ...........................................   13
7.0 Acknowledgements ..............................................   13
References ........................................................   13
Authors' addresses ................................................   15
Full Copyright Statement ..........................................   16
Changes (RFC Editor: Please Remove) ...............................   17

Expires December 16, 2001                                       [Page 3]
INTERNET DRAFT          PILC - Links with Errors               June 2001

1.0 Introduction

   Congestion avoidance in the Internet is based on an assumption
   that most packet losses are due to congestion.  TCP's congestion
   avoidance strategy treats the absence of acknowledgements as a
   congestion signal.  This has worked well since it was introduced
   in 1988 [VJ-DCAC], because most links and subnets have
   relatively low error rates in normal operation, and congestion
   is the primary cause of loss in these environments. However,
   links and subnets that do not enjoy low uncorrected error rates
   are becoming more prevalent in parts of the Internet.  In
   particular, these include terrestrial and satellite wireless
   links. Users relying on traffic traversing these links may see
   poor performance because their TCP connections are spending
   excessive time in congestion avoidance and/or slow start
   procedures triggered by packet losses due to transmission

   The recommendations in this document aim at improving
   utilization of available path capacity over such high error-rate
   links in ways that do not threaten the stability of the

   Applications use TCP in very different ways, and these have
   interactions with TCP's behavior [RFC2861]. Nevertheless, it is
   possible to make some basic assumptions about TCP flows.
   Accordingly, the mechanisms discussed here are applicable to all
   uses of TCP, albeit in varying degrees according to different
   scenarios (as noted where appropriate).

   This recommendation is based on the explicit assumption that major
   changes to the entire installed base of routers and hosts are not a
   practical possibility.  This constrains any changes to hosts that
   are directly affected by errored links.

1.1 Should you be reading this recommendation?

   All known subnetwork technologies provide an "imperfect" subnetwork
   service - the bit error rate is non-zero. But there's no obvious way
   for end stations to tell the difference between packets discarded
   due to congestion and losses due to transmission errors.

   If a directly-attached subnetwork is reporting transmission errors
   to a host, these reports matter, but we can't rely on explicit
   transmission error reports to both hosts.

   Another way of deciding if a subnetwork should be considered to have
   a "high error rate" is by appealing to mathematics.

Expires December 16, 2001                                       [Page 4]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   An approximate formula for the TCP Reno response function is given
   in [PFTK98]:

   T = --------------------------------------------------
       RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)


       T = the sending rate in bytes per second
       s = the packet size in bytes
       RTT = round-trip time in seconds
       tRTO = TCP retransmit timeout value in seconds
       p = steady-state packet loss rate

   If one plugs in an observed packet loss rate, does the math and
   then sees predicted bandwidth utilization that is greater than
   the link speed, the connection will not benefit from
   recommendations in this document, because the level of packet
   losses being encountered won't affect the ability of TCP to
   utilize the link. If, however, the predicted bandwidth is less
   than the link speed, packet losses are affecting the ability of
   TCP to utilize the link.

   If further investigation reveals a subnetwork with significant
   transmission error rates, the recommendations in this document will
   improve the ability of TCP to utilize the link.

   A few caveats are in order, when doing this calculation:

   (1) the RTT is the end-to-end RTT, not the link RTT.
   (2) Max(1.0, 4*RTT) can be substituted as a simplification for tRTO.
   (3) losses may be bursty - a loss rate measured over an interval
       that includes multiple bursty loss events may understate the
       impact of these loss events on the sending rate.

1.2 Relationship of this recommendation to PEPs

   This document discusses end-to-end mechanisms that do not require
   TCP-level awareness by intermediate nodes. This places severe
   limitations on what the end nodes can know about the nature of
   losses that are occurring between the end nodes. Attempts to
   apply heuristics to distinguish between congestion and
   transmission error have not been successful [BV97, BV98, BV98a].
   This restriction is relaxed in an informational document on
   Performance Enhancing Proxies (PEPs) which has been developed or
   is in development by the Performance Implications of Link
   Characteristics WG (PILC) [PILC-WEB]. Because PEPs can be placed

Expires December 16, 2001                                       [Page 5]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   on boundaries where network characteristics change dramatically,
   PEPs have an additional opportunity to improve performance over
   links with uncorrected errors.

   However, generalized use of PEPs contravenes the end-to-end
   principle and is highly undesirable given their deleterious
   implications, which include the following: lack of fate sharing
   (a PEP adds a third point of failure besides the endpoints
   themselves), end-to-end reliability and diagnostics, preventing
   end-to-end security (particularly network layer security such as
   IPsec), mobility (handoffs are much more complex because state
   must be transferred), asymmetric routing (PEPs typically require
   being on both the forward and reverse paths of a connection),
   scalability (PEPs add more state to maintain), QoS transparency
   and guarantees.

   Not every type of PEP has all the drawbacks listed above.
   Nevertheless, the use of PEPs may have very serious consequences
   which must be weighed carefully.

1.3 Relationship of this recommendation to Link Layer Mechanisms

   This recommendation is for use with TCP over subnetwork
   technologies (link layers) that have already been deployed.
   Subnetworks that are intended to carry Internet protocols, but
   have not been completely specified are the subject of a best
   common practices (BCP) document which has been developed or is
   under development by the Performance Implications of Link
   Characteristics WG (PILC) [PILC-WEB]. This last document is
   aimed at designers who still have the opportunity to reduce the
   number of uncorrected errors TCP will encounter.

2.0 Errors and Interactions with TCP Mechanisms

   A TCP sender adapts its use of network path capacity based on
   feedback from the TCP receiver. As TCP is not able to distinguish
   between losses due to congestion and losses due to uncorrected
   errors, it is not able to accurately determine available path
   capacity in the presence of significant uncorrected errors.

2.1 Slow Start and Congestion Avoidance [RFC2581]

   Slow Start and Congestion Avoidance [RFC2581] are essential to
   the current stability of the Internet. These mechanisms were
   designed to accommodate networks that do not provide explicit
   congestion notification. Although experimental mechanisms such as
   [RFC2481] are moving in the direction of explicit congestion
   notification, the effect of ECN on ECN-aware TCPs is essentially

Expires December 16, 2001                                       [Page 6]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   the same as the effect of implicit congestion notification through
   congestion-related loss, except that ECN provides this notification
   before packets are lost, and must then be retransmitted.

   TCP connections experiencing high error rates on their paths
   interact badly with Slow Start and with Congestion Avoidance,
   because high error rates make the interpretation of losses
   ambiguous - the sender cannot know whether detected losses are due
   to congestion or to data corruption. TCP makes the "safe" choice and
   assumes that the losses are due to congestion.

      - Whenever sending TCPs receive three out-of-order
        acknowledgements, they assume the network is mildly congested
        and invoke fast retransmit/fast recovery (described below).

      - Whenever TCP's retransmission timer expires, the sender
        assumes that the network is congested and invokes slow start.

      - Less-reliable link layers often use small link MTUs. This slows
        the rate of increase in the sender's window size during slow
        start, because the sender's window is increased in units of
        segments. Small link MTUs alone don't improve reliability. Path
        MTU discovery [RFC1191] must also be used to prevent
        fragmentation. Path MTU discovery allows the most rapid
        opening of the sender's window size during slow start, but a
        number of round trips may still be required to open the window

   Recommendation: Any standards-conformant TCP will implement Slow
   Start and Congestion Avoidance, which are MUSTs in STD 3 [RFC1122].
   Recommendations in this document will not interfere with these

2.2 Fast Retransmit and Fast Recovery [RFC2581]

   TCP provides reliable delivery of data as a byte-stream to an
   application, so that when a segment is lost (whether due to either
   congestion or transmission loss), the receiver TCP implementation
   must wait to deliver data to the receiving application until the
   missing data is received. The receiver TCP implementation
   detects missing segments by segments arriving with out-of-order
   sequence numbers.

   TCPs should immediately send an acknowledgement when data is
   received out-of-order [RFC2581], providing the next expected
   sequence number with no delay, so that the sender can retransmit
   the required data as quickly as possible and the receiver can resume
   delivery of data to the receiving application. When an

Expires December 16, 2001                                       [Page 7]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   acknowledgement carries the same expected sequence number as an
   acknowledgement that has already been sent for the last in-order
   segment received, these acknowledgements are called "duplicate

   Because IP networks are allowed to reorder packets, the receiver
   may send duplicate acknowledgements for segments that arrive
   out of order due to routing changes, link-level retransmission,
   etc. When a TCP sender receives three duplicate ACKs, fast
   retransmit [RFC2581] allows it to infer that a segment was
   lost. The sender retransmits what it considers to be this lost
   segment without waiting for the full retransmission timeout,
   thus saving time.

   After a fast retransmit, a sender halves its congestion window
   and invokes the fast recovery [RFC2581] algorithm, whereby
   it invokes congestion avoidance from a halved congestion window,
   but does not invoke slow start from a one-segment congestion window
   as it would do after a retransmission timeout. As the sender is
   still receiving dupacks, it knows the receiver is receiving packets
   sent, so the full reduction after a timeout when no communication
   has been received is not called for. This relatively safe
   optimization also saves time.

   It is important to be realistic about the maximum throughput that
   TCP can have over a connection that traverses a high error-rate
   link. In general, TCP will increase its congestion window beyond the
   delay-bandwidth product. TCP's congestion avoidance strategy is
   additive-increase, multiplicative-decrease, which means that if
   additional errors are encountered before the congestion window
   recovers completely from a 50-percent reduction, the effect can be a
   "downward spiral" of the congestion window due to additional
   50-percent reductions. Even using Fast Retransmit/Fast Recovery,
   the sender will halve the congestion window each time a window
   contains one or more segments that are lost, and will re-open the
   window by one additional segment for each congestion window's worth
   of acknowledgement received.

   If a connection's path traverses a link that loses one or more
   segments during this recovery period, the one-half reduction takes
   place again, this time on a reduced congestion window - and this
   downward spiral will continue to hold the congestion window below
   path capacity until the connection is able to recover completely
   by additive increase without experiencing loss.

   Of course, no downward spiral occurs if the error rate is constantly
   high and the congestion window always remains small; the
   multiplicative-increase "slow start" will be exited early, and the

Expires December 16, 2001                                       [Page 8]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   congestion window remains low for the duration of the TCP
   connection. In links with high error rates, the TCP window may
   remain rather small for long periods of time.

   Not all causes of small windows are related to errors. For
   example, HTTP/1.0 commonly closes TCP connections to indicate
   boundaries between requested resources. This means that these
   applications are constantly closing "trained" TCP connections
   and opening "untrained" TCP connections which will execute slow
   start, beginning with one or two segments. This can happen even
   with HTTP/1.1, if webmasters configure their HTTP/1.1 servers to
   close connections instead of waiting to see if the connection will
   be useful again.

   A small window - especially a window of less than four segments -
   effectively prevents the sender from taking advantage of Fast
   Retransmits. Moreover, efficient recovery from multiple losses
   within a single window requires adoption of new proposals
   (NewReno [RFC2582]).

   Recommendation: Implement Fast Retransmit and Fast Recovery at
   this time. This is a widely-implemented optimization and is
   currently at Proposed Standard level. [RFC2488] recommends
   implementation of Fast Retransmit/Fast Recovery in satellite

2.3 Selective Acknowledgements [RFC2018, RFC2883]

   Selective Acknowledgements [RFC2018] allow the repair of multiple
   segment losses per window without requiring one (or more)
   round-trips per loss.

   [RFC2883] proposes a minor extension to SACK that allows receiving
   TCPs to provide more information about the order of delivery of
   segments, allowing "more robust operation in an environment of
   reordered packets, ACK loss, packet replication, and/or early
   retransmit timeouts". Unless explicitly stated otherwise, in this
   document, "Selective Acknowledgements" (or "SACK") refers to the
   combination of [RFC2018] and [RFC2883].

   Selective acknowledgements are most useful in LFNs ("Long Fat
   Networks") because of the long round trip times that may be
   encountered in these environments, according to Section 1.1 of
   [RFC1323], and are especially useful if large windows are
   required, because there is a higher probability of multiple
   segment losses per window.

   On the other hand, if error rates are generally low but

Expires December 16, 2001                                       [Page 9]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   occasionally higher due to channel conditions, TCP will have the
   opportunity to increase its window to larger values during periods
   of improved channel conditions between bursts of errors.  When
   bursts of errors occur, multiple losses within a window are likely
   to occur.  In this case, SACK would provide benefits in speeding
   the recovery and preventing unnecessary reduction of the window

   Recommendation: Implement SACK as specified in [RFC2018] and updated
   by [RFC2883], both Proposed Standards. In cases where SACK cannot be
   enabled for both sides of a connection, TCP senders may use NewReno
   [RFC2582] to better handle partial ACKs and multiple losses within a
   single window.

3.0 Summary of Recommendations

   The Internet does not provide a widely-available loss feedback
   mechanism that allows TCP to distinguish between congestion loss
   and transmission error. Because congestion affects all traffic on a
   path while transmission loss affects only the specific traffic
   encountering uncorrected errors, avoiding congestion has to take
   precedence over quickly repairing transmission errors. This means
   that the best that can be achieved without new feedback mechanisms
   is minimizing the amount of time that is spent unnecessarily in
   congestion avoidance.

   The Fast Retransmit/Fast Recovery mechanism allows quick repair of
   loss without giving up the safety of congestion avoidance. In order
   for Fast Retransmit/Fast Recovery to work, the window size must
   be large enough to force the receiver to send three duplicate
   acknowledgements before the retransmission timeout interval
   expires, forcing full TCP slow-start.

   Selective Acknowledgements (SACK) extend the benefit of Fast
   Retransmit/Fast Recovery to situations where multiple segment
   losses in the window need to be repaired more quickly than can
   be accomplished by executing Fast Retransmit for each segment
   loss, only to discover the next segment loss.

   These mechanisms are not limited to wireless environments. They are
   usable in all environments.

4.0 Topics For Further Work

   "Limited Transmit" [RFC3042] has been specified as an
   optimization extending Fast Retransmit/Fast Recovery for TCP
   connections with small congestion windows that will not trigger
   three duplicate acknowledgements. This specification is deemed

Expires December 16, 2001                                      [Page 10]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   safe, and it also provides benefits for TCP connections that
   experience a large amount of packet (data or ACK) loss.
   Implementors should evaluate this standards track specification
   for TCP in loss environments.

   Delayed Duplicate Acknowledgements [MV97, VMPM99] attempts to
   prevent TCP-level retransmission when link-level retransmission
   is still in progress, adding additional traffic to the
   network. This proposal is worthy of additional study, but is not
   recommended at this time, because we don't know how to calculate
   appropriate amounts of delay for an arbitrary network topology.

   It is not possible to use explicit congestion notification [RFC2481]
   as a surrogate for explicit transmission error notification
   (no matter how much we wish it was!). Some mechanism to
   provide explicit notification of transmission error would
   be very helpful. This might be more easily provided in a
   PEP environment, especially when the PEP is the "first hop"
   in a connection path, because current checksum mechanisms
   do not distinguish between transmission error to a payload
   and transmission error to the header. Furthermore, if the header
   is damaged, sending explicit transmission error notification to
   the right endpoint is problematic.

   Losses that take place on the ACK stream, especially while a TCP
   is learning network characteristics, can make the data stream
   quite bursty (resulting in losses on the data stream, as well).
   Several ways of limiting this burstiness have been proposed,
   including TCP transmit pacing at the sender and ACK rate control
   within the network.

   "Appropriate Byte Counting" (ABC) [ALL99], has been proposed as a
   way of opening the congestion window based on the number of bytes
   that have been successfully transfered to the receiver, giving more
   appropriate behavior for application protocols that initiate
   connections with relatively short packets. For SMTP [RFC821], for
   instance, the client might send a short HELO packet, a short MAIL
   packet, one or more short RCPT packets, and a short DATA packet -
   followed by the entire mail body sent as maximum-length packets.
   An ABC TCP sender would not use ACKs for each of these short packets
   to increase the congestion window to allow additional full-length
   packets. ABC is worthy of additional study, but is not recommended
   at this time, because ABC can lead to increased burstiness when
   acknowledgements are lost.

4.1 Achieving, and maintaining, large windows

   The recommendations described in this document will aid TCPs in

Expires December 16, 2001                                      [Page 11]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   injecting packets into ERRORed connections as fast as possible
   without destabilizing the Internet, and so optimizing the use of
   available bandwidth.

   In addition to these TCP-level recommendations, there is still
   additional work to do at the application level, especially with
   the dominant application protocol on the World Wide Web, HTTP.

   HTTP/1.0 (and earlier versions) closes TCP connections to signal
   a receiver that all of a requested resource had been transmitted.
   Because WWW objects tend to be small in size [MOGUL], TCPs carrying
   HTTP/1.0 traffic experience difficulty in "training" on available
   path capacity (a substantial portion of the transfer has already
   happened by the time TCP exits slow start).

   Several HTTP modifications have been introduced to improve this
   interaction with TCP ("persistent connections" in HTTP/1.0,
   with improvements in HTTP/1.1 [RFC2616]). For a variety of
   reasons, many HTTP interactions are still HTTP/1.0-style -
   relatively short-lived.

   Proposals which reuse TCP congestion information across
   connections, like TCP Control Block Interdependence [RFC2140],
   or the more recent Congestion Manager [BS00] proposal, will have
   the effect of making multiple parallel connections impact the
   network as if they were a single connection, "trained" after
   a single startup transient. These proposals are critical to
   the long-term stability of the Internet, because today's users
   always have the choice of clicking on the "reload" button in
   their browsers and cutting off TCP's exponential backoff -
   replacing connections which are building knowledge of the
   available bandwidth with connections with no knowledge at all.

5.0 Security Considerations

   A potential vulnerability introduced by Fast Retransmit/Fast
   Recovery is (as pointed out in [RFC2581]) that an attacker may
   force TCP connections to grind to a halt, or, more dangerously,
   behave more aggressively. The latter possibility may lead to
   congestion collapse, at least in some regions of the network.

   Selective acknowledgements is believed to neither strengthen nor
   weaken TCP's current security properties [RFC2018].

   Given that the recommendations in this document are performed on
   an end-to-end basis, they continue working even in the presence
   of end-to-end IPsec. This is in direct contrast with mechanisms
   such as PEP's which are implemented in intermediate nodes

Expires December 16, 2001                                      [Page 12]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   (section 1.2).

6.0 IANA Considerations

   This document is a pointer to other, existing IETF standards.
   There are no new IANA considerations.

7.0 Acknowledgements

   This recommendation has grown out of RFC 2757, "TCP Over Long
   Thin Networks", which was in turn based on work done in the IETF
   TCPSAT working group. The authors are indebted to the active
   members of the PILC working group. In particular, Mark Allman
   and Lloyd Wood gave us copious and insightful feedback, and
   Dan Grossman and Jamshid Mahdavi provided text replacements.


   [ALL99] M. Allman, "TCP Byte Counting Refinements," ACM
   Computer Communication Review, Volume 29, Number 3, July 1999.

   [BS00] H. Balakrishnan and S. Seshan, "The Congestion Manager",
   May, 2001. Work in progress, available as
   draft-ietf-ecm-cm-04.txt. Approved as a Proposed Standard.

   [BV97] S. Biaz and N. Vaidya, "Using End-to-end Statistics to
   Distinguish Congestion and Corruption Losses: A Negative Result,"
   Texas A&M University, Technical Report 97-009, August 18, 1997.

   [BV98] S. Biaz and N. Vaidya, "Sender-Based heuristics for
   Distinguishing Congestion Losses from Wireless Transmission
   Losses," Texas A&M University, Technical Report 98-013, June

   [BV98a] S. Biaz and N. Vaidya, "Discriminating Congestion Losses
   from Wireless Losses using Inter-Arrival Times at the Receiver,"
   Texas A&M University, Technical Report 98-014, June 1998.

   [MOGUL] "The Case for Persistent-Connection HTTP", J. C. Mogul,
   Research Report 95/4, May 1995. Available as

   [MV97] M. Mehta and N. Vaidya, "Delayed Duplicate-Acknowledgements:
   A Proposal to Improve Performance of TCP on Wireless Links," Texas
   A&M University, December 24, 1997.
   Available at

Expires December 16, 2001                                      [Page 13]
INTERNET DRAFT          PILC - Links with Errors               June 2001


   [PFTK98] J. Padhye, V. Firoiu, D. Towsley and J.Kurose, "TCP
   Throughput: A simple model and its empirical validation", SIGCOMM
   Symposium on Communications Architectures and Protocols, August 1998.

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

   [RFC821] J. Postel, "Simple Mail Transfer Protocol", August 1982.
   RFC 821, STD 10.

   [RFC1122] R. Braden, "Requirements for Internet Hosts --
   Communication Layers", October 1989. RFC 1122, STD 3.

   [RFC1191] J. Mogul and S. Deering, "Path MTU Discovery", November
   1990. RFC 1191.

   [RFC1323] V. Jacobson, R. Braden, and D. Borman. "TCP Extensions
   for High Performance", May 1992. RFC 1323.

   [RFC2018] M. Mathis, et al, "TCP Selective Acknowledgment Options",
   October, 1996. RFC 2018.

   [RFC2140] J. Touch, "TCP Control Block Interdependence", April 1997.
   RFC 2140.

   [RFC2309] B. Braden, et al, "Recommendations on Queue Management
   and Congestion Avoidance in the Internet", April 1998. RFC 2309.

   [RFC2481] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit
   Congestion Notification (ECN) to IP", January 1999. RFC 2481.

   [RFC2488] M. Allman, D. Glover, and L. Sanchez. "Enhancing TCP
   Over Satellite Channels using Standard Mechanisms", January 1999
   RFC 2488, BCP 28.

   [RFC2581] M. Allman, V. Paxson, W. Stevens, "TCP Congestion
   Control," April 1999. RFC 2581 (Proposed Standard).

   [RFC2582] S. Floyd and T. Henderson, "The NewReno Modification to
   TCP's Fast Recovery Algorithm," April 1999. RFC 2582 (Experimental).

   [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Masinter,
   P. Leach, T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1",
   June 1999. RFC 2616 (Draft Standard).

   [RFC2861] M. Handley, J., Padhye, S., Floyd, "TCP Congestion

Expires December 16, 2001                                      [Page 14]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   Window Validation," June 2000. RFC 2861 (Information).

   [RFC2883] S. Floyd, et al, "An Extension to the Selective
   Acknowledgement (SACK) Option for TCP", August 1999. RFC 2883
   (Proposed Standard).

   [RFC2923] K. Lahey, "TCP Problems with Path MTU Discovery",
   September 2000. RFC 2923.

   [RFC3042] M. Allman, H. Balakrishnan, S. Floyd, "Enhancing TCP's
   Loss Recovery Using Limited Transmit", January, 2001. RFC 3042
   (Proposed Standard).

   [VJ-DCAC] V. Jacobson, "Dynamic Congestion Avoidance / Control"
   e-mail dated February 11, 1988, available from

   [VMPM99] N. Vaidya, M. Mehta, C. Perkins, and G. Montenegro,
   "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to
   Improve Performance of TCP over Wireless," Technical Report
   99-003, Computer Science Dept., Texas A&M University, February
   1999. Also, to appear in Journal of Wireless Communications and
   Wireless Computing (Special Issue on Reliable Transport
   Protocols for Mobile Computing).

Authors' addresses

   Questions about this document may be directed to:

          Spencer Dawkins
          Fujitsu Network Communications
          2801 Telecom Parkway
          Richardson, Texas 75082

          Voice:  +1-972-479-3782

          Gabriel E. Montenegro
          Sun Microsystems
          Laboratories, Europe
          32, chemin du Vieux Chene
          38240 Meylan

          Voice:  +33 476 18 80 45


Expires December 16, 2001                                      [Page 15]
INTERNET DRAFT          PILC - Links with Errors               June 2001

          Markku Kojo
          Department of Computer Science
          University of Helsinki
          P.O. Box 26 (Teollisuuskatu 23)
          FIN-00014 HELSINKI

          Voice:  +358-9-1914-4179
          Fax:    +358-9-1914-4441

          Vincent Magret
          Alcatel Internetworking, Inc.
          26801 W. Agoura road
          Calabasas, CA, 91301

          Phone: +1 818 878 4485

          Nitin Vaidya
          Dept. of Computer Science
          Texas A&M University
          College Station, TX 77843-3112

          Voice:  +1 979-845-0512
          Fax:    +1 979-847-8578

Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be

Expires December 16, 2001                                      [Page 16]
INTERNET DRAFT          PILC - Links with Errors               June 2001

   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Changes (RFC Editor: Please Remove)

   Changes between versions 07 and 08:

   o Updated discussion on Limited Transmit, as it is now a proposed
     standard (rfc3042).

   o Updated reference to TCP Congestion Window Validation, as it
     is now an informational rfc (rfc3042).

   o Updated reference to Congestion Manager [BS00], as it has been
     approved as a Proposed Standard.

   o Added reference to Delayed Dupacks on Journal of Wireless
     Communications and Wireless Computing.

   o Updated contact info for: Markku Kojo, Nitin Vaidya and
     Vincent Magret.

   o Reworked the security considerations section.

   Changes between versions 06 and 07:

   o Deleted references to other PILC documents, replacing those by
     reference to [PILC-WEB]. Accordingly, reworded sections 1.2
     and 1.3 on PEP and LINK, respectively.

   o Added IANA recommendations section.

   o Sundry editorial changes (readability, spelling errors).

   Changes between versions 05 and 06:

   o Incorporate editorial comments from Dan Grossman, Lloyd Wood,

Expires December 16, 2001                                      [Page 17]
INTERNET DRAFT          PILC - Links with Errors               June 2001

     John Border, and Mark Allman.

   o Correct errors in Spencer's understanding of appropriate byte

   o Reordered sections 1.1, 1.2, and 1.3.

   o Rewrite of the second half of section 1.1 to reflect the UMass
     empirical model for TCP throughput, at Mark Handley's suggestion.

   o Delete appendices as inappropriate for BCP, the targetted track
     for this document.

   o Add description of "Limited Transmit" in "Topics for Future

   o Add an explicit "Security Considerations" section.

   o Add full copyright section.

   o Update Gab Montenegro's contact information.

   o Consistently format reference section entries.

Expires December 16, 2001                                      [Page 18]