Internet Engineering Task Force S. Dawkins
INTERNET DRAFT G. Montenegro
M. Kojo
V. Magret
N. Vaidya
November 17, 2000
End-to-end Performance Implications of Links with Errors
draft-ietf-pilc-error-06.txt
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
pilc@grc.nasa.gov.
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.
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.
Abstract
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 May 17, 2001 [Page 1]
INTERNET DRAFT PILC - Links with Errors November 2000
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 May 17, 2001 [Page 2]
INTERNET DRAFT PILC - Links with Errors November 2000
Table of Contents
1.0 Introduction .................................................. 4
1.1 Should you be reading this recommendation? ................ 4
1.2 Relationship of this recommendation to [PILC-PEP] .......... 5
1.3 Relationship of this recommendation to [PILC-LINK] ......... 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 Acknowledgements .............................................. 12
Changes ........................................................... 12
References ........................................................ 13
Authors' addresses ................................................ 15
Full Copyright Statement .......................................... 17
Expires May 17, 2001 [Page 3]
INTERNET DRAFT PILC - Links with Errors November 2000
1.0 Introduction
Congestion avoidance in the Internet is based on an assumption that
most packet losses are due to congestion. TCP participates in a
congestion avoidance strategy which treats the absence of
acknowledgements as a congestion signal. This has worked well since
it was introduced in 1988 [VJ-DAC], 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. These
particularly include in particular 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 paket losses due to transmission errors.
This document makes recommendations about what the participants
in connections that traverse high error-rate links may wish
to consider doing to improve utilization of available path capacity
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 [HPF-CWV]. 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 May 17, 2001 [Page 4]
INTERNET DRAFT PILC - Links with Errors November 2000
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 and then does the
math and 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 [PILC-PEP]
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]. A companion
PILC document on Performance Enhancing Proxies, [PILC-PEP],
relaxes this restriction; 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.
Expires May 17, 2001 [Page 5]
INTERNET DRAFT PILC - Links with Errors November 2000
However, generalized use of PEPs contravenes the end-to-end
principle and is highly undesirable given their deleterious
implications, which include the following [PILC-PEP]: 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 [PILC-LINK]
This recommendation is for use with TCP over subnetwork technologies
that have already been deployed. A companion PILC recommendation,
[PILC-LINK], is for designers of subnetworks that are intended to
carry Internet protocols, but have not been completely specified,
so that the designers 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
Expires May 17, 2001 [Page 6]
INTERNET DRAFT PILC - Links with Errors November 2000
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
completely.
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 implemetation 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 acknowledgements are called "duplicate
ACKs".
Because IP networks are allowed to reorder packets, the receiver
may send duplicate acknowledgements for segments that arrive
Expires May 17, 2001 [Page 7]
INTERNET DRAFT PILC - Links with Errors November 2000
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
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
Expires May 17, 2001 [Page 8]
INTERNET DRAFT PILC - Links with Errors November 2000
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.
[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
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
Expires May 17, 2001 [Page 9]
INTERNET DRAFT PILC - Links with Errors November 2000
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
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" [ABF00] has been proposed as an optimization
extending Fast Retransmit/Fast Recovery for TCP connections with
small congestion windows that won't generate three duplicate
acknowledgements. This proposal seems safe, and also provides
benefits for TCP connections with larger congestion windows when
losses occur at or near the right edge of the window. Implementors
may wish to study this proposal, especially if it enters the IETF
standards track.
Expires May 17, 2001 [Page 10]
INTERNET DRAFT PILC - Links with Errors November 2000
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 - and, 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
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
Expires May 17, 2001 [Page 11]
INTERNET DRAFT PILC - Links with Errors November 2000
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
All recommendations included in this document are applicable to TCP
connections protected by IPSec.
6.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.
Changes
Changes between versions 05 and 06:
o Incorporate editorial comments from Dan Grossman, Lloyd Wood,
John Border, and Mark Allman.
Expires May 17, 2001 [Page 12]
INTERNET DRAFT PILC - Links with Errors November 2000
o Correct errors in Spencer's understanding of appropriate byte
counting.
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
Work".
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.
References
[ABF00] M. Allman, H. Balakrishnan, S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", August, 2000. Work in
progress, available as draft-ietf-tsvwg-limited-xmit-00.txt.
[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] H. Balakrishnan and S. Seshan, "The Congestion Manager",
November, 2000. Work in progress, available as
draft-ietf-ecm-cm-03.txt.
[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
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.
Expires May 17, 2001 [Page 13]
INTERNET DRAFT PILC - Links with Errors November 2000
[HPF-CWV] M. Handley, J., Padhye, S., Floyd, "TCP Congestion
Window Validation," March 2000. Approved as an Informational RFC,
available as draft-handley-tcp-cwv-02.txt.
[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-LINK] P. Karn, et al, "Advice for Internet Subnetwork
Designers", July 2000. Work in progress, available as
draft-ietf-pilc-link-design-03.txt.
[PILC-PEP] J. Border, et al, "Performance Enhancing Proxies",
October 2000. Work in progress, available as
draft-ietf-pilc-pep-04.txt.
[PILC-SLOW] S. Dawkins, G. Montenegro, M. Kojo, V. Magret,
"End-to-End Performance Implications of Slow Links", July 2000. Work
in progress, available as draft-ietf-pilc-slow-04.txt
[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.
Expires May 17, 2001 [Page 14]
INTERNET DRAFT PILC - Links with Errors November 2000
[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).
[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.
[VJ-DCAC] V. Jacobson, "Dynamic Congestion Avoidance / Control"
e-mail dated Feberuary 11, 1988, available from
http://www.kohala.com/~rstevens/vanj.88feb11.txt
[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.
Authors' addresses
Questions about this document may be directed to:
Expires May 17, 2001 [Page 15]
INTERNET DRAFT PILC - Links with Errors November 2000
Spencer Dawkins
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, Texas 75082
Voice: +1-972-479-3782
E-Mail: spencer.dawkins@fnc.fujitsu.com
Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
32, chemin du Vieux Chene
38240 Meylan
FRANCE
Voice: +33 (0)476 41 53 45
E-Mail: gab@sun.com
Markku Kojo
University of Helsinki/Department of Computer Science
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-7084-4179
Fax: +358-9-7084-4441
E-Mail: kojo@cs.helsinki.fi
Vincent Magret
Corporate Research Center
Alcatel Network Systems, Inc
1201 Campbell
Mail stop 446-310
Richardson Texas 75081 USA
M/S 446-310
Voice: +1-972-996-2625
Fax: +1-972-996-5902
E-mail: vincent.magret@aud.alcatel.com
Expires May 17, 2001 [Page 16]
INTERNET DRAFT PILC - Links with Errors November 2000
Nitin Vaidya
Dept. of Computer Science
Texas A&M University
College Station, TX 77843-3112
Voice: +1 409-845-0512
Fax: +1 409-847-8578
Email: vaidya@cs.tamu.edu
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
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.
Expires May 17, 2001 [Page 17]
