    Network Working Group                                         S. Dawkins
    Request for Comments: 3155                                 G. Montenegro
    BCP: 50                                                          M. Kojo
    Category: Best Current Practice                                V. Magret
                                                                   N. Vaidya
                                                                 August 2001

            End-to-end Performance Implications of Links with Errors

    Status of this Memo

       This document specifies an Internet Best Current Practices for the
       Internet Community, and requests discussion and suggestions for
       improvements.  Distribution of this memo is unlimited.

    Copyright Notice

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

    Abstract

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

    Table of Contents

       1.0 Introduction .............................................    2
          1.1 Should you be reading this recommendation?  ...........    3
          1.2 Relationship of this recommendation to PEPs ...........    4
          1.3 Relationship of this recommendation to Link Layer
              Mechanisms.............................................    4
       2.0 Errors and Interactions with TCP Mechanisms ..............    5
          2.1 Slow Start and Congestion Avoidance [RFC2581] .........    5
          2.2 Fast Retransmit and Fast Recovery [RFC2581] ...........    6
          2.3 Selective Acknowledgements [RFC2018, RFC2883] .........    7
       3.0 Summary of Recommendations ...............................    8
       4.0 Topics For Further Work ..................................    9
          4.1 Achieving, and maintaining, large windows .............   10
       5.0 Security Considerations ..................................   11
       6.0 IANA Considerations ......................................   11
       7.0 Acknowledgements .........................................   11
       References ...................................................   11
       Authors' Addresses ...........................................   14
       Full Copyright Statement .....................................   16

    Dawkins, et al.          Best Current Practice                  [Page 1]

    RFC 3155                PILC - Links with Errors             August 2001

    1.0 Introduction

       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.

       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 acknowledgement 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 does not address issues with other transport protocols,
       for example, UDP.

       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 acknowledgement 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 errors.

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

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

    Dawkins, et al.          Best Current Practice                  [Page 2]

    RFC 3155                PILC - Links with Errors             August 2001

       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.

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

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

       where

           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.

    Dawkins, et al.          Best Current Practice                  [Page 3]

    RFC 3155                PILC - Links with Errors             August 2001

       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) [RFC3135]. Because PEPs can be placed 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

    Dawkins, et al.          Best Current Practice                  [Page 4]

    RFC 3155                PILC - Links with Errors             August 2001

       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 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
             acknowledgement, 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
             completely.

    Dawkins, et al.          Best Current Practice                  [Page 5]

    RFC 3155                PILC - Links with Errors             August 2001

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

    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 acknowledgement carries the same
       expected sequence number as an acknowledgement that has already been
       sent for the last in-order segment received, these acknowledgement
       are called "duplicate ACKs".

       Because IP networks are allowed to reorder packets, the receiver may
       send duplicate acknowledgments 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

    Dawkins, et al.          Best Current Practice                  [Page 6]

    RFC 3155                PILC - Links with Errors             August 2001

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

    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.

    Dawkins, et al.          Best Current Practice                  [Page 7]

    RFC 3155                PILC - Links with Errors             August 2001

       [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 acknowledgments 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 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 size.

       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
       acknowledgments before the retransmission timeout interval expires,
       forcing full TCP slow-start.

    Dawkins, et al.          Best Current Practice                  [Page 8]

    RFC 3155                PILC - Links with Errors             August 2001

       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
       acknowledgments.  This specification is deemed 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

    Dawkins, et al.          Best Current Practice                  [Page 9]

    RFC 3155                PILC - Links with Errors             August 2001

       connections with relatively short packets.  For SMTP [RFC2821], 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
       acknowledgments are lost.

    4.1 Achieving, and maintaining, large windows

       The recommendations described in this document will aid TCPs in
       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.

    Dawkins, et al.          Best Current Practice                 [Page 10]

    RFC 3155                PILC - Links with Errors             August 2001

    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 acknowledgments 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 (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, "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.

    References

       [ALL99]    M. Allman, "TCP Byte Counting Refinements," ACM Computer
                  Communication Review, Volume 29, Number 3, July 1999.
                  http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-
                  99.html

       [BS00]     Balakrishnan, H. and S. Seshan, "The Congestion Manager",
                  RFC 3124, June 2001.

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

    Dawkins, et al.          Best Current Practice                 [Page 11]

    RFC 3155                PILC - Links with Errors             August 2001

       [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 1998.

       [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
                  http://www.research.digital.com/wrl/techreports/abstracts/
                  95.4.html

       [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
                  http://www.cs.tamu.edu/faculty/vaidya/mobile.html

       [PILC-WEB] http://pilc.grc.nasa.gov/

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

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

       [RFC2821]  Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
                  2821, April 2001.

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

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

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

       [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow "TCP
                  Selective Acknowledgment Options", RFC 2018, October 1996.

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

    Dawkins, et al.          Best Current Practice                 [Page 12]

    RFC 3155                PILC - Links with Errors             August 2001

       [RFC2309]  Braden, B., Clark, D., Crowcrfot, J., Davie, B., Deering,
                  S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
                  Partridge, C., Peterson, L., Ramakrishnan, K., Shecker,
                  S., Wroclawski, J. and L, Zhang, "Recommendations on Queue
                  Management and Congestion Avoidance in the Internet", RFC
                  2309, April 1998.

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

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

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

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

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

       [RFC2861]  Handley, H., Padhye, J. and S., Floyd, "TCP Congestion
                  Window Validation", RFC 2861, June 2000.

       [RFC2883]  Floyd, S., Mahdavi, M., Mathis, M. and M. Podlosky, "An
                  Extension to the Selective Acknowledgement (SACK) Option
                  for TCP", RFC 2883, August 1999.

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

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

       [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
                  Shelby, "Performance Enhancing Proxies Intended to
                  Mitigate Link-Related Degradations", RFC 3135, June 2001.

       [VJ-DCAC]  Jacobson, V., "Dynamic Congestion Avoidance / Control" e-
                  mail dated February 11, 1988, available from
                  http://www.kohala.com/~rstevens/vanj.88feb11.txt

    Dawkins, et al.          Best Current Practice                 [Page 13]

    RFC 3155                PILC - Links with Errors             August 2001

       [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

       Phone: +1-972-479-3782
       EMail: spencer.dawkins@fnc.fujitsu.com

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

       Phone: +33 476 18 80 45
       EMail: gab@sun.com

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

       Phone: +358-9-1914-4179
       EMail: kojo@cs.helsinki.fi

    Dawkins, et al.          Best Current Practice                 [Page 14]

    RFC 3155                PILC - Links with Errors             August 2001

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

       Phone: +1 818 878 4485
       EMail: vincent.magret@alcatel.com

       Nitin H. Vaidya
       458 Coodinated Science Laboratory, MC-228
       1308 West Main Street
       Urbana, IL 61801

       Phone: 217-265-5414
       E-mail: nhv@crhc.uiuc.edu

    Dawkins, et al.          Best Current Practice                 [Page 15]

    RFC 3155                PILC - Links with Errors             August 2001

    Full Copyright Statement

       Copyright (C) The Internet Society (2001).  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
       followed, or as required to translate it into languages other than
       English.

       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
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS 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.

    Acknowledgement

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

    Dawkins, et al.          Best Current Practice                 [Page 16]