RFC relevance of congestion

As per Relevance of the word congestion, we have this rfc below:

Network Working Group S.
Request for Comments: 3150 G.
BCP: 48 M .
Category: Best Current Practice V.
July 2001

End-to-end Performance Implications of Slow

Status of this

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

Copyright

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

This document makes performance-related recommendations for users
network paths that traverse "very low bit-rate" links

"Very low bit-rate" implies "slower than we would like".
recommendation may be useful in any network where hosts can
available bandwidth, but the design space for this
explicitly includes connections that traverse 56 Kb/second
links or 4.8 Kb/second wireless access links - both of which
widely deployed

This document discusses general-purpose mechanisms.
application-specific mechanisms can outperform the relevant general
purpose mechanism, we point this out and explain why

This document has some recommendations in common with RFC 2689,
"Providing integrated services over low-bitrate links", especially
areas like header compression. This document focuses more
traditional data applications for which "best-effort delivery"
appropriate

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

RFC 3150 PILC - Slow Links July 2001

Table of

1.0 Introduction ................................................. 2
2.0 Description of Optimizations ................................. 3
2.1 Header Compression Alternatives ...................... 3
2.2 Payload Compression Alternatives ..................... 5
2.3 Choosing MTU sizes ................................... 5
2.4 Interactions with TCP Congestion Control [RFC2581] ... 6
2.5 TCP Buffer Auto-tuning ............................... 9
2.6 Small Window Effects ................................. 10
3.0 Summary of Recommended Optimizations ......................... 10
4.0 Topics For Further Work ...................................... 12
5.0 Security Considerations ...................................... 12
6.0 IANA Considerations .......................................... 13
7.0 Acknowledgements ............................................. 13
8.0 References ................................................... 13
Authors' Addresses ............................................... 16
Full Copyright Statement ......................................... 17

1.0

The Internet protocol stack was designed to operate in a wide
of link speeds, and has met this design goal with only a
number of enhancements (for example, the use of TCP window scaling
described in "TCP Extensions for High Performance" [RFC1323]
very-high-bandwidth connections).

Pre-World Wide Web application protocols tended to be
interactive applications sending very little data (e.g., Telnet)
bulk transfer applications that did not require interactive
(e.g., File Transfer Protocol, Network News). The World Wide Web
given us traffic that is both interactive and often "bulky",
including images, sound, and video

The World Wide Web has also popularized the Internet, so that
is significant interest in accessing the Internet over link
that are much "slower" than typical office network speeds. In fact
a significant proportion of the current Internet users is
to the Internet over a relatively slow last-hop link. In future,
number of such users is likely to increase rapidly as various
devices are foreseen to to be attached to the Internet over
wireless links

In order to provide the best interactive response for these "bulky
transfers, implementors may wish to minimize the number of
actually transmitted over these "slow" connections. There are

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

RFC 3150 PILC - Slow Links July 2001

areas that can be considered - compressing the bits that make up
overhead associated with the connection, and compressing the
that make up the payload being transported over the connection

In addition, implementors may wish to consider TCP receive
settings and queuing mechanisms as techniques to improve
over low-speed links. While these techniques do not involve
changes, they are included in this document for completeness

2.0 Description of

This section describes optimizations which have been suggested
use in situations where hosts can saturate their links. The
section summarizes recommendations about the use of
optimizations

2.1 Header Compression

Mechanisms for TCP and IP header compression defined in [RFC1144,
RFC2507, RFC2508, RFC2509, RFC3095] provide the following benefits

- Improve interactive response

- Decrease header overhead (for a typical dialup MTU of 296
bytes, the overhead of TCP/IP headers can decrease from
13 percent with typical 40-byte headers to 1-1.5 percent
with 3-5 byte compressed headers, for most packets).
enables use of small packets for delay-sensitive low data-
traffic and good line efficiency for bulk data even with
segment sizes (for reasons to use a small MTU on slow links
see section 2.3)

- Many slow links today are wireless and tend to be
lossy. Header compression reduces packet loss rate over
links (simply because shorter transmission times expose
to fewer events that cause loss).

[RFC1144] header compression is a Proposed Standard for TCP
compression that is widely deployed. Unfortunately it is
on lossy links, because even a single bit error results in loss
synchronization between the compressor and decompressor. It uses
timeouts to detect a loss of such synchronization, but these
result in loss of data (up to a full TCP window), delay of a
RTO, and unnecessary slow-start

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

RFC 3150 PILC - Slow Links July 2001

A more recent header compression proposal [RFC2507] includes
explicit request for retransmission of an uncompressed packet
allow resynchronization without waiting for a TCP timeout (
executing congestion avoidance procedures). This works much
on links with lossy characteristics

The above scheme ceases to perform well under conditions as
as those of many cellular links (error conditions of 1e-3 or 1e-2
round trip times over 100 ms.). For these cases, the 'Robust
Compression' working group has developed ROHC [RFC3095].
of ROHC to support compression of TCP headers are also
development

[RFC1323] defines a "TCP Timestamp" option, used to
"wrapping" of the TCP sequence number space on high-speed links,
to improve TCP RTT estimates by providing unambiguous TCP
timings. Use of TCP timestamps prevents header compression,
the timestamps are sent as TCP options. This means that
timestamped header has TCP options that differ from the
header, and headers with changed TCP options are always
uncompressed. In addition, timestamps do not seem to have much of
impact on RTO estimation [AlPa99].

Nevertheless, the ROHC working group is developing schemes
compress TCP headers, including options such as timestamps
selective acknowledgements

Recommendation: Implement [RFC2507], in particular as it relates
IPv4 tunnels and Minimal Encapsulation for Mobile IP, as well as
header compression for lossy links and links that reorder packets
PPP capable devices should implement "IP Header Compression over PPP
[RFC2509]. Robust Header Compression [RFC3095] is recommended
extremely slow links with very high error rates (see above),
implementors should judge if its complexity is justified (perhaps
the cost of the radio frequency resources).

[RFC1144] header compression should only be enabled when
over reliable "slow" links

Use of TCP Timestamps [RFC1323] is not recommended with
connections, because it complicates header compression. Even
the Robust Header Compression (ROHC) working group is
specifications to remedy this, those mechanisms are not yet
developed nor deployed, and may not be generally justifiable
Furthermore, connections traversing "slow" links do not
protection against TCP sequence-number wrapping

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

RFC 3150 PILC - Slow Links July 2001

2.2 Payload Compression

Compression of IP payloads is also desirable on "slow" network links
"IP Payload Compression Protocol (IPComp)" [RFC2393] defines
framework where common compression algorithms can be applied
arbitrary IP segment payloads

IP payload compression is something of a niche optimization. It
necessary because IP-level security converts IP payloads to
bitstreams, defeating commonly-deployed link-layer
mechanisms which are faced with payloads that have no
"information" that can be more compactly represented

However, many IP payloads are already compressed (images, audio
video, "zipped" files being transferred), or are already
above the IP layer (e.g., SSL [SSL]/TLS [RFC2246]). These
will not "compress" further, limiting the benefit of
optimization

For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also
Content-Encoding and Accept-Encoding headers, supporting a variety
compression algorithms for common compressible MIME types
text/plain. This leaves only the HTTP headers
uncompressed

In general, application-level compression can often
IPComp, because of the opportunity to use compression
based on knowledge of the specific data being compressed

Extensive use of application-level compression techniques will
the need for IPComp, especially for WWW users

Recommendation: IPComp may optionally be implemented

2.3 Choosing MTU

There are several points to keep in mind when choosing an MTU
low-speed links

First, if a full-length MTU occupies a link for longer than
delayed ACK timeout (typically 200 milliseconds, but may be up to 500
milliseconds), this timeout will cause an ACK to be generated
every segment, rather than every second segment, as occurs with
implementations of the TCP delayed ACK algorithm

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

RFC 3150 PILC - Slow Links July 2001

Second, "relatively large" MTUs, which take human-perceptible
of time to be transmitted into the network, create human-
delays in other flows using the same link. [RFC1144]
100-200 millisecond delays as human-perceptible. The convention
choosing 296-byte MTUs (with header compression enabled) for
access is a compromise that limits the maximum link occupancy
with full-length MTUs close to 200 milliseconds on 9.6 Kb/
links

Third, on last-hop links using a larger link MTU size, and
larger MSS, would allow a TCP sender to increase its
window faster in bytes than when using a smaller MTU size (and
smaller MSS). However, with a smaller MTU size, and a smaller
size, the congestion window, when measured in segments,
more quickly than it would with a larger MSS size. Connections
smaller MSS sizes are more likely to be able to send enough
to generate three duplicate acknowledgements, triggering
retransmit/fast recovery when packet losses are encountered. Hence
a smaller MTU size is useful for slow links with
characteristics

Fourth, using a smaller MTU size also decreases the queuing delay
a TCP flow (and thereby RTT) compared to use of larger MTU size
the same number of packets in a queue. This means that a TCP
using a smaller segment size and traversing a slow link is able
inflate the congestion window (in number of segments) to a
value while experiencing the same queuing delay

Finally, some networks charge for traffic on a per-packet basis,
on a per-kilobyte basis. In these cases, connections using a
MTU may be charged less than connections transferring the same
of bytes using a smaller MTU

Recommendation: If it is possible to do so, MTUs should be
that do not monopolize network interfaces for human-
amounts of time, and implementors should not chose MTUs that
occupy a network interface for significantly more than 100-200
milliseconds

2.4 Interactions with TCP Congestion Control [RFC2581]

In many cases, TCP connections that traverse slow links have the
link as an "access" link, with higher-speed links in use for most
the connection path. One common configuration might be a
computer using dialup access to a terminal server (a last-
router), with an HTTP server on a high-speed LAN "behind"
terminal server

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

RFC 3150 PILC - Slow Links July 2001

In this case, the HTTP server may be able to place packets on
directly-attached high-speed LAN at a higher rate than the last-
router can forward them on the low-speed link. When the last-
router falls behind, it will be unable to buffer the traffic
for the low-speed link, and will become a point of congestion
begin to drop the excess packets. In particular, several packets
be dropped in a single transmission window when initial slow
overshoots the last-hop router buffer

Although packet loss is occurring, it isn't detected at the
sender until one RTT time after the router buffer space is
and the first packet is dropped. This late congestion signal
the congestion window to increase up to double the size it was at
time the first packet was dropped at the router

If the link MTU is large enough to take more than the delayed
timeout interval to transmit a packet, an ACK is sent for
segment and the congestion window is doubled in a single RTT. If
smaller link MTU is in use and delayed ACKs can be utilized,
congestion window increases by a factor of 1.5 in one RTT. In
cases the sender continues transmitting packets well beyond
congestion point of the last-hop router, resulting in multiple
losses in a single window

The self-clocking nature of TCP's slow start and congestion
algorithms prevent this buffer overrun from continuing. In addition
these algorithms allow senders to "probe" for available bandwidth -
cycling through an increasing rate of transmission until loss occurs
followed by a dramatic (50-percent) drop in transmission rate.
happens when a host directly connected to a low-speed link offers
advertised window that is unrealistically large for the low-
link. During the congestion avoidance phase the peer host
to probe for available bandwidth, trying to fill the
window, until packet loss occurs

The same problems may also exist when a sending host is
connected to a slow link as most slow links have some local buffer
the link interface. This link interface buffer is subject
overflow exactly in the same way as the last-hop router buffer

When a last-hop router with a small number of buffers per
link is used, the first buffer overflow occurs earlier than it
if the router had a larger number of buffers. Subsequently with
smaller number of buffers the periodic packet losses occur
frequently during congestion avoidance, when the sender probes
available bandwidth

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

RFC 3150 PILC - Slow Links July 2001

The most important responsibility of router buffers is to
bursts. Too few buffers (for example, only three buffers
outbound link as described in [RFC2416]) means that routers
overflow their buffer pools very easily and are unlikely to
even a very small burst. When a larger number of router buffers
allocated per outbound link, the buffer space does not overflow
quickly but the buffers are still likely to become full due to TCP'
default behavior. A larger number of router buffers leads to
queuing delays and a longer RTT

If router queues become full before congestion is signaled or
full for long periods of time, this is likely to result in "lock
out", where a single connection or a few connections occupy
router queue space, preventing other connections from using the
[RFC2309], especially when a tail drop queue management discipline
being used

Therefore, it is essential to have a large enough number of
in routers to be able to absorb data bursts, but keep the
normally small. In order to achieve this it has been recommended
[RFC2309] that an active queue management mechanism, like
Early Detection (RED) [RED93], should be implemented in all
routers, including the last-hop routers in front of a slow link.
should also be noted that RED requires a sufficiently large number
router buffers to work properly. In addition, the
parameters of RED on a last-hop router connected to a slow link
likely deviate from the defaults recommended

Active queue management mechanism do not eliminate packet drops but
instead, drop packets at earlier stage to solve the full-
problem for flows that are responsive to packet drops as
signal. Hosts that are directly connected to low-speed links
limit the receive windows they advertise in order to lower
eliminate the number of packet drops in a last-hop router.
doing so one should, however, take care that the advertised window
large enough to allow full utilization of the last-hop link
and to allow triggering fast retransmit, when a packet loss
encountered. This recommendation takes two forms

- Modern operating systems use relatively large default TCP
buffers compared to what is required to fully utilize the
capacity of low-speed links. Users should be able to choose
default receive window size in use - typically a system-
parameter. (This "choice" may be as simple as "dial-up access/
access" on a dialog box - this would accommodate many
without requiring hand-tuning by experienced network engineers.)

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

RFC 3150 PILC - Slow Links July 2001

- Application developers should not attempt to manually
network bandwidth using socket buffer sizes. Only in very
circumstances will an application actually know both the
and delay of a path and be able to choose a suitably low (or high
value for the socket buffer size to obtain good
performance

This recommendation is not a general solution for any network
that might involve a slow link. Instead, this recommendation
applicable in environments where the host "knows" it is
connected to other hosts via "slow links". For hosts that
connect to other host over a variety of links (e.g., dial-up
computers with LAN-connected docking stations), buffer auto-
for the receive buffer is a more reasonable recommendation, and
discussed below

2.5 TCP Buffer Auto-

[SMM98] recognizes a tension between the desire to allocate "large
TCP buffers, so that network paths are fully utilized, and a
to limit the amount of memory dedicated to TCP buffers, in order
efficiently support large numbers of connections to hosts
network paths that may vary by six orders of magnitude

The technique proposed is to dynamically allocate TCP buffers,
on the current congestion window, rather than attempting
preallocate TCP buffers without any knowledge of the network path

This proposal results in receive buffers that are appropriate for
window sizes in use, and send buffers large enough to contain
windows of segments, so that SACK and fast recovery can
losses without forcing the connection to use lengthy
timeouts

While most of the motivation for this proposal is given from
server's perspective, hosts that connect using multiple
with markedly-different link speeds may also find this kind
technique useful. This is true in particular with slow links,
are likely to dominate the end-to-end RTT. If the host is
only via a single slow link interface at a time, it is fairly easy
(dynamically) adjust the receive window (and thus the
window) to a value appropriate for the slow last-hop link with
bandwidth and delay characteristics

Recommendation: If a host is sometimes connected via a slow link
the host is also connected using other interfaces with markedly
different link speeds, it may use receive buffer auto-tuning
adjust the advertised window to an appropriate value

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

RFC 3150 PILC - Slow Links July 2001

2.6 Small Window

If a TCP connection stabilizes with a congestion window of only a
segments (as could be expected on a "slow" link), the sender isn'
sending enough segments to generate three duplicate acknowledgements
triggering fast retransmit and fast recovery. This means that
retransmission timeout is required to repair the loss - dropping
TCP connection to a congestion window with only one segment

[TCPB98] and [TCPF98] observe that (in studies of network
datasets) it is relatively common for TCP retransmission timeouts
occur even when some duplicate acknowledgements are being sent.
challenge is to use these duplicate acknowledgements to trigger
retransmit/fast recovery without injecting traffic into the
unnecessarily - and especially not injecting traffic in ways
will result in instability

The "Limited Transmit" algorithm [RFC3042] suggests sending a
segment when the first and second duplicate acknowledgements
received, so that the receiver is more likely to be able to
to generate duplicate acknowledgements until the TCP
threshold is reached, triggering fast retransmit and fast recovery
When the congestion window is small, this is very useful in
fast retransmit and fast recovery to recover from a packet
without using a retransmission timeout. We note that a maximum
two additional new segments will be sent before the receiver
either a new acknowledgement advancing the window or two
duplicate acknowledgements, triggering fast retransmit/fast recovery
and that these new segments will be acknowledgement-clocked,
back-to-back

Recommendation: Limited Transmit should be implemented in all hosts

3.0 Summary of Recommended

This section summarizes our recommendations regarding the
standards-track mechanisms, for end nodes that are connected via
slow link

Header compression should be implemented. [RFC1144]
compression can be enabled over robust network links. [RFC2507]
should be used over network connections that are expected
experience loss due to corruption as well as loss due to congestion
For extremely lossy and slow links, implementors should evaluate
[RFC3095] as a potential solution. [RFC1323] TCP timestamps must
turned off because (1) their protection against TCP sequence
wrapping is unjustified for slow links, and (2) they complicate
header compression

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

RFC 3150 PILC - Slow Links July 2001

IP Payload Compression [RFC2393] should be implemented,
compression at higher layers of the protocol stack (for example [
2616]) may make this mechanism less useful

For HTTP/1.1 environments, [RFC2616] payload compression should
implemented and should be used for payloads that are not
compressed

Implementors should choose MTUs that don't monopolize
interfaces for more than 100-200 milliseconds, in order to limit
impact of a single connection on all other connections sharing
network interface

Use of active queue management is recommended on last-hop
that provide Internet access to host behind a slow link.
addition, number of router buffers per slow link should be
enough to absorb concurrent data bursts from more than a single flow
To absorb concurrent data bursts from two or three TCP senders with
typical data burst of three back-to-back segments per sender,
least six (6) or nine (9) buffers are needed. Effective use
active queue management is likely to require even larger number
buffers

Implementors should consider the possibility that a host will
directly connected to a low-speed link when choosing default
receive window sizes

Application developers should not attempt to manually manage
bandwidth using socket buffer sizes as only in very
circumstances an application will be able to choose a suitable
for the socket buffer size to obtain good network performance

Limited Transmit [RFC3042] should be implemented in all end hosts
it assists in triggering fast retransmit when congestion window
small

All of the mechanisms described above are stable standards-track
(at Proposed Standard status, as of this writing).

In addition, implementors may wish to consider TCP buffer auto
tuning, especially when the host system is likely to be used with
wide variety of access link speeds. This is not a standards-
TCP mechanism but, as it is an operating system implementation issue
it does not need to be standardized

Of the above mechanisms, only Header Compression (for IP and TCP)
cease to work in the presence of end-to-end IPSEC. However
[RFC3095] does allow compressing the ESP header

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

RFC 3150 PILC - Slow Links July 2001

4.0 Topics For Further

In addition to the standards-track mechanisms discussed above,
are still opportunities to improve performance over low-speed links

"Sending fewer bits" is an obvious response to slow link speeds.
now-defunct HTTP-NG proposal [HTTP-NG] replaced the text-based
header representation with a binary representation for compactness
However, HTTP-NG is not moving forward and HTTP/1.1 is not
enhanced to include a more compact HTTP header representation
Instead, the Wireless Application Protocol (WAP) Forum has opted
the XML-based Wireless Session Protocol [WSP], which includes
compact header encoding mechanism

It would be nice to agree on a more compact header
that will be used by all WWW communities, not only the wireless
community. Indeed, general XML content encodings have been
[Millau], although they are not yet widely adopted

We note that TCP options which change from segment to
effectively disable header compression schemes deployed today
because there's no way to indicate that some fields in the header
unchanged from the previous segment, while other fields are not.
Robust Header Compression working group is developing such
for TCP options such as timestamps and selective acknowledgements
Hopefully, documents subsequent to [RFC3095] will define
specifications

Another effort worth following is that of 'Delta Encoding'. Here
clients that request a slightly modified version of some
cached resource would receive a succinct description of
differences, rather than the entire resource [HTTP-DELTA].

5.0 Security

All recommendations included in this document are stable standards
track RFCs (at Proposed Standard status, as of this writing)
otherwise do not suggest any changes to any protocol. With
exception of Van Jacobson compression [RFC1144] and [RFC2507,
RFC2508, RFC2509], all other mechanisms are applicable to
connections protected by end-to-end IPSec. This includes
[RFC3095], albeit partially, because even though it can compress
outermost ESP header to some extent, encryption still renders
payload data uncompressible (including any subsequent
headers).

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

RFC 3150 PILC - Slow Links July 2001

6.0 IANA

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

7.0

This recommendation has grown out of "Long Thin Networks" [RFC2757],
which in turn benefited from work done in the IETF TCPSAT
group

8.0

[AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-
Network Path Properties", in ACM SIGCOMM 99 Proceedings
1999.

[HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work
Progress

[HTTP-NG] Mike Spreitzer, Bill Janssen, "HTTP 'Next Generation'",
9th International WWW Conference, May, 2000.
available as: http://www.www9.org/w9cdrom/60/60.

[Millau] Marc Girardot, Neel Sundaresan, "Millau: an
format for efficient representation and exchange of
over the Web", 9th International WWW Conference, May
2000. Also available as
http://www.www9.org/w9cdrom/154/154.

[PAX97] Paxson, V., "End-to-End Internet Packet Dynamics", 1997,
in SIGCOMM 97 Proceedings, available as
http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc
97.

[RED93] Floyd, S., and Jacobson, V., Random Early
gateways for Congestion Avoidance, IEEE/ACM
on Networking, V.1 N.4, August 1993, pp. 397-413.
available from http://ftp.ee.lbl.gov/floyd/red.html

[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-
Serial Links", RFC 1144, February 1990.

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

RFC 3150 PILC - Slow Links July 2001

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

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol:
1.0", RFC 2246, January 1999.

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

[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "
Payload Compression Protocol (IPComp)", RFC 2393,
December 1998.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.

[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up
Four Packets Into Only Three Buffers", RFC 2416,
September 1998.

[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP
Compression", RFC 2507, February 1999.

[RFC2508] Casner, S. and V. Jacobson. "Compressing IP/UDP/
Headers for Low-Speed Serial Links", RFC 2508,
1999.

[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP
Compression over PPP", RFC 2509, February 1999.

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

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

[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V.,
N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.

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

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

RFC 3150 PILC - Slow Links July 2001

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro
K., Wiebke, T., Yoshimura, T. and H. Zheng, "
Header Compression (ROHC): Framework and four Profiles
RTP, UDP ESP and uncompressed", RFC 3095, July 2001.

[SMM98] Jeffrey Semke, Matthew Mathis, and Jamshid Mahdavi
"Automatic TCP Buffer Tuning", in ACM SIGCOMM 98
Proceedings 1998. Available
http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html

[SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The
Protocol: Version 3.0, March 1996. (Expired Internet
Draft, available
http://home.netscape.com/eng/ssl3/ssl-toc.html

[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan,
Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of
Busy Internet Server: Analysis and Improvements",
Infocom, March 1998. Available from
http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.

[TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery Strategies
Analysis and Improvements", IEEE Infocom, March 1998.
Available from
http://www.eecs.harvard.edu/networking/papers/ infocom
tcp-final-198.

[WSP] Wireless Application Protocol Forum, "WAP
Session Protocol Specification", approved 4 May, 2000,
available
http://www1.wapforum.org/tech/documents/WAP-203-WSP
20000504-a.pdf. (informative reference).

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

RFC 3150 PILC - Slow Links July 2001

Authors'

Questions about this document may be directed to

Spencer
Fujitsu Network
2801 Telecom
Richardson, Texas 75082

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

Gabriel
Sun Microsystems Laboratories,
29, chemin du Vieux
38240 Meylan,

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

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

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

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

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

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

RFC 3150 PILC - Slow Links July 2001

Full Copyright

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

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

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

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

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

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

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX