From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3150.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc3150.txt (limited to 'doc/rfc/rfc3150.txt') diff --git a/doc/rfc/rfc3150.txt b/doc/rfc/rfc3150.txt new file mode 100644 index 0000000..aab7cf0 --- /dev/null +++ b/doc/rfc/rfc3150.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Dawkins +Request for Comments: 3150 G. Montenegro +BCP: 48 M . Kojo +Category: Best Current Practice V. Magret + July 2001 + + + End-to-end Performance Implications of Slow Links + +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 makes performance-related recommendations for users of + network paths that traverse "very low bit-rate" links. + + "Very low bit-rate" implies "slower than we would like". This + recommendation may be useful in any network where hosts can saturate + available bandwidth, but the design space for this recommendation + explicitly includes connections that traverse 56 Kb/second modem + links or 4.8 Kb/second wireless access links - both of which are + widely deployed. + + This document discusses general-purpose mechanisms. Where + 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 in + areas like header compression. This document focuses more on + traditional data applications for which "best-effort delivery" is + appropriate. + + + + + + + + + + + +Dawkins, et al. Best Current Practice [Page 1] + +RFC 3150 PILC - Slow Links July 2001 + + +Table of Contents + + 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 Introduction + + The Internet protocol stack was designed to operate in a wide range + of link speeds, and has met this design goal with only a limited + number of enhancements (for example, the use of TCP window scaling as + described in "TCP Extensions for High Performance" [RFC1323] for + very-high-bandwidth connections). + + Pre-World Wide Web application protocols tended to be either + interactive applications sending very little data (e.g., Telnet) or + bulk transfer applications that did not require interactive response + (e.g., File Transfer Protocol, Network News). The World Wide Web has + 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 there + is significant interest in accessing the Internet over link speeds + that are much "slower" than typical office network speeds. In fact, + a significant proportion of the current Internet users is connected + to the Internet over a relatively slow last-hop link. In future, the + number of such users is likely to increase rapidly as various mobile + devices are foreseen to to be attached to the Internet over slow + wireless links. + + In order to provide the best interactive response for these "bulky" + transfers, implementors may wish to minimize the number of bits + actually transmitted over these "slow" connections. There are two + + + + + +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 the + overhead associated with the connection, and compressing the bits + that make up the payload being transported over the connection. + + In addition, implementors may wish to consider TCP receive window + settings and queuing mechanisms as techniques to improve performance + over low-speed links. While these techniques do not involve protocol + changes, they are included in this document for completeness. + +2.0 Description of Optimizations + + This section describes optimizations which have been suggested for + use in situations where hosts can saturate their links. The next + section summarizes recommendations about the use of these + optimizations. + +2.1 Header Compression Alternatives + + Mechanisms for TCP and IP header compression defined in [RFC1144, + RFC2507, RFC2508, RFC2509, RFC3095] provide the following benefits: + + - Improve interactive response time + + - Decrease header overhead (for a typical dialup MTU of 296 + bytes, the overhead of TCP/IP headers can decrease from about + 13 percent with typical 40-byte headers to 1-1.5 percent with + with 3-5 byte compressed headers, for most packets). This + enables use of small packets for delay-sensitive low data-rate + traffic and good line efficiency for bulk data even with small + 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 significantly + lossy. Header compression reduces packet loss rate over lossy + links (simply because shorter transmission times expose packets + to fewer events that cause loss). + + [RFC1144] header compression is a Proposed Standard for TCP Header + compression that is widely deployed. Unfortunately it is vulnerable + on lossy links, because even a single bit error results in loss of + synchronization between the compressor and decompressor. It uses TCP + timeouts to detect a loss of such synchronization, but these errors + result in loss of data (up to a full TCP window), delay of a full + 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 an + explicit request for retransmission of an uncompressed packet to + allow resynchronization without waiting for a TCP timeout (and + executing congestion avoidance procedures). This works much better + on links with lossy characteristics. + + The above scheme ceases to perform well under conditions as extreme + as those of many cellular links (error conditions of 1e-3 or 1e-2 and + round trip times over 100 ms.). For these cases, the 'Robust Header + Compression' working group has developed ROHC [RFC3095]. Extensions + of ROHC to support compression of TCP headers are also under + development. + + [RFC1323] defines a "TCP Timestamp" option, used to prevent + "wrapping" of the TCP sequence number space on high-speed links, and + to improve TCP RTT estimates by providing unambiguous TCP roundtrip + timings. Use of TCP timestamps prevents header compression, because + the timestamps are sent as TCP options. This means that each + timestamped header has TCP options that differ from the previous + header, and headers with changed TCP options are always sent + uncompressed. In addition, timestamps do not seem to have much of an + impact on RTO estimation [AlPa99]. + + Nevertheless, the ROHC working group is developing schemes to + compress TCP headers, including options such as timestamps and + selective acknowledgements. + + Recommendation: Implement [RFC2507], in particular as it relates to + IPv4 tunnels and Minimal Encapsulation for Mobile IP, as well as TCP + 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 for + extremely slow links with very high error rates (see above), but + implementors should judge if its complexity is justified (perhaps by + the cost of the radio frequency resources). + + [RFC1144] header compression should only be enabled when operating + over reliable "slow" links. + + Use of TCP Timestamps [RFC1323] is not recommended with these + connections, because it complicates header compression. Even though + the Robust Header Compression (ROHC) working group is developing + specifications to remedy this, those mechanisms are not yet fully + developed nor deployed, and may not be generally justifiable. + Furthermore, connections traversing "slow" links do not require + 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 Alternatives + + Compression of IP payloads is also desirable on "slow" network links. + "IP Payload Compression Protocol (IPComp)" [RFC2393] defines a + framework where common compression algorithms can be applied to + arbitrary IP segment payloads. + + IP payload compression is something of a niche optimization. It is + necessary because IP-level security converts IP payloads to random + bitstreams, defeating commonly-deployed link-layer compression + mechanisms which are faced with payloads that have no redundant + "information" that can be more compactly represented. + + However, many IP payloads are already compressed (images, audio, + video, "zipped" files being transferred), or are already encrypted + above the IP layer (e.g., SSL [SSL]/TLS [RFC2246]). These payloads + will not "compress" further, limiting the benefit of this + optimization. + + For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also includes + Content-Encoding and Accept-Encoding headers, supporting a variety of + compression algorithms for common compressible MIME types like + text/plain. This leaves only the HTTP headers themselves + uncompressed. + + In general, application-level compression can often outperform + IPComp, because of the opportunity to use compression dictionaries + based on knowledge of the specific data being compressed. + + Extensive use of application-level compression techniques will reduce + the need for IPComp, especially for WWW users. + + Recommendation: IPComp may optionally be implemented. + +2.3 Choosing MTU Sizes + + There are several points to keep in mind when choosing an MTU for + low-speed links. + + First, if a full-length MTU occupies a link for longer than the + delayed ACK timeout (typically 200 milliseconds, but may be up to 500 + milliseconds), this timeout will cause an ACK to be generated for + every segment, rather than every second segment, as occurs with most + 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 amounts + of time to be transmitted into the network, create human-perceptible + delays in other flows using the same link. [RFC1144] considers + 100-200 millisecond delays as human-perceptible. The convention of + choosing 296-byte MTUs (with header compression enabled) for dialup + access is a compromise that limits the maximum link occupancy delay + with full-length MTUs close to 200 milliseconds on 9.6 Kb/second + links. + + Third, on last-hop links using a larger link MTU size, and therefore + larger MSS, would allow a TCP sender to increase its congestion + window faster in bytes than when using a smaller MTU size (and a + smaller MSS). However, with a smaller MTU size, and a smaller MSS + size, the congestion window, when measured in segments, increases + more quickly than it would with a larger MSS size. Connections using + smaller MSS sizes are more likely to be able to send enough segments + to generate three duplicate acknowledgements, triggering fast + retransmit/fast recovery when packet losses are encountered. Hence, + a smaller MTU size is useful for slow links with lossy + characteristics. + + Fourth, using a smaller MTU size also decreases the queuing delay of + a TCP flow (and thereby RTT) compared to use of larger MTU size with + the same number of packets in a queue. This means that a TCP flow + using a smaller segment size and traversing a slow link is able to + inflate the congestion window (in number of segments) to a larger + value while experiencing the same queuing delay. + + Finally, some networks charge for traffic on a per-packet basis, not + on a per-kilobyte basis. In these cases, connections using a larger + MTU may be charged less than connections transferring the same number + of bytes using a smaller MTU. + + Recommendation: If it is possible to do so, MTUs should be chosen + that do not monopolize network interfaces for human-perceptible + amounts of time, and implementors should not chose MTUs that will + 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 slow + link as an "access" link, with higher-speed links in use for most of + the connection path. One common configuration might be a laptop + computer using dialup access to a terminal server (a last-hop + router), with an HTTP server on a high-speed LAN "behind" the + 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 its + directly-attached high-speed LAN at a higher rate than the last-hop + router can forward them on the low-speed link. When the last-hop + router falls behind, it will be unable to buffer the traffic intended + for the low-speed link, and will become a point of congestion and + begin to drop the excess packets. In particular, several packets may + be dropped in a single transmission window when initial slow start + overshoots the last-hop router buffer. + + Although packet loss is occurring, it isn't detected at the TCP + sender until one RTT time after the router buffer space is exhausted + and the first packet is dropped. This late congestion signal allows + the congestion window to increase up to double the size it was at the + time the first packet was dropped at the router. + + If the link MTU is large enough to take more than the delayed ACK + timeout interval to transmit a packet, an ACK is sent for every + segment and the congestion window is doubled in a single RTT. If a + smaller link MTU is in use and delayed ACKs can be utilized, the + congestion window increases by a factor of 1.5 in one RTT. In both + cases the sender continues transmitting packets well beyond the + congestion point of the last-hop router, resulting in multiple packet + losses in a single window. + + The self-clocking nature of TCP's slow start and congestion avoidance + 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. This + happens when a host directly connected to a low-speed link offers an + advertised window that is unrealistically large for the low-speed + link. During the congestion avoidance phase the peer host continues + to probe for available bandwidth, trying to fill the advertised + window, until packet loss occurs. + + The same problems may also exist when a sending host is directly + connected to a slow link as most slow links have some local buffer in + the link interface. This link interface buffer is subject to + overflow exactly in the same way as the last-hop router buffer. + + When a last-hop router with a small number of buffers per outbound + link is used, the first buffer overflow occurs earlier than it would + if the router had a larger number of buffers. Subsequently with a + smaller number of buffers the periodic packet losses occur more + frequently during congestion avoidance, when the sender probes for + 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 absorb + bursts. Too few buffers (for example, only three buffers per + outbound link as described in [RFC2416]) means that routers will + overflow their buffer pools very easily and are unlikely to absorb + even a very small burst. When a larger number of router buffers are + allocated per outbound link, the buffer space does not overflow as + quickly but the buffers are still likely to become full due to TCP's + default behavior. A larger number of router buffers leads to longer + queuing delays and a longer RTT. + + If router queues become full before congestion is signaled or remain + full for long periods of time, this is likely to result in "lock- + out", where a single connection or a few connections occupy the + router queue space, preventing other connections from using the link + [RFC2309], especially when a tail drop queue management discipline is + being used. + + Therefore, it is essential to have a large enough number of buffers + in routers to be able to absorb data bursts, but keep the queues + normally small. In order to achieve this it has been recommended in + [RFC2309] that an active queue management mechanism, like Random + Early Detection (RED) [RED93], should be implemented in all Internet + routers, including the last-hop routers in front of a slow link. It + should also be noted that RED requires a sufficiently large number of + router buffers to work properly. In addition, the appropriate + parameters of RED on a last-hop router connected to a slow link will + 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-queue + problem for flows that are responsive to packet drops as congestion + signal. Hosts that are directly connected to low-speed links may + limit the receive windows they advertise in order to lower or + eliminate the number of packet drops in a last-hop router. When + doing so one should, however, take care that the advertised window is + large enough to allow full utilization of the last-hop link capacity + and to allow triggering fast retransmit, when a packet loss is + encountered. This recommendation takes two forms: + + - Modern operating systems use relatively large default TCP receive + buffers compared to what is required to fully utilize the link + capacity of low-speed links. Users should be able to choose the + default receive window size in use - typically a system-wide + parameter. (This "choice" may be as simple as "dial-up access/LAN + access" on a dialog box - this would accommodate many environments + 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 manage + network bandwidth using socket buffer sizes. Only in very rare + circumstances will an application actually know both the bandwidth + and delay of a path and be able to choose a suitably low (or high) + value for the socket buffer size to obtain good network + performance. + + This recommendation is not a general solution for any network path + that might involve a slow link. Instead, this recommendation is + applicable in environments where the host "knows" it is always + connected to other hosts via "slow links". For hosts that may + connect to other host over a variety of links (e.g., dial-up laptop + computers with LAN-connected docking stations), buffer auto-tuning + for the receive buffer is a more reasonable recommendation, and is + discussed below. + +2.5 TCP Buffer Auto-tuning + + [SMM98] recognizes a tension between the desire to allocate "large" + TCP buffers, so that network paths are fully utilized, and a desire + to limit the amount of memory dedicated to TCP buffers, in order to + efficiently support large numbers of connections to hosts over + network paths that may vary by six orders of magnitude. + + The technique proposed is to dynamically allocate TCP buffers, based + on the current congestion window, rather than attempting to + preallocate TCP buffers without any knowledge of the network path. + + This proposal results in receive buffers that are appropriate for the + window sizes in use, and send buffers large enough to contain two + windows of segments, so that SACK and fast recovery can recover + losses without forcing the connection to use lengthy retransmission + timeouts. + + While most of the motivation for this proposal is given from a + server's perspective, hosts that connect using multiple interfaces + with markedly-different link speeds may also find this kind of + technique useful. This is true in particular with slow links, which + are likely to dominate the end-to-end RTT. If the host is connected + only via a single slow link interface at a time, it is fairly easy to + (dynamically) adjust the receive window (and thus the advertised + window) to a value appropriate for the slow last-hop link with known + bandwidth and delay characteristics. + + Recommendation: If a host is sometimes connected via a slow link but + the host is also connected using other interfaces with markedly- + different link speeds, it may use receive buffer auto-tuning to + 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 Effects + + If a TCP connection stabilizes with a congestion window of only a few + segments (as could be expected on a "slow" link), the sender isn't + sending enough segments to generate three duplicate acknowledgements, + triggering fast retransmit and fast recovery. This means that a + retransmission timeout is required to repair the loss - dropping the + TCP connection to a congestion window with only one segment. + + [TCPB98] and [TCPF98] observe that (in studies of network trace + datasets) it is relatively common for TCP retransmission timeouts to + occur even when some duplicate acknowledgements are being sent. The + challenge is to use these duplicate acknowledgements to trigger fast + retransmit/fast recovery without injecting traffic into the network + unnecessarily - and especially not injecting traffic in ways that + will result in instability. + + The "Limited Transmit" algorithm [RFC3042] suggests sending a new + segment when the first and second duplicate acknowledgements are + received, so that the receiver is more likely to be able to continue + to generate duplicate acknowledgements until the TCP retransmit + threshold is reached, triggering fast retransmit and fast recovery. + When the congestion window is small, this is very useful in assisting + fast retransmit and fast recovery to recover from a packet loss + without using a retransmission timeout. We note that a maximum of + two additional new segments will be sent before the receiver sends + either a new acknowledgement advancing the window or two additional + duplicate acknowledgements, triggering fast retransmit/fast recovery, + and that these new segments will be acknowledgement-clocked, not + back-to-back. + + Recommendation: Limited Transmit should be implemented in all hosts. + +3.0 Summary of Recommended Optimizations + + This section summarizes our recommendations regarding the previous + standards-track mechanisms, for end nodes that are connected via a + slow link. + + Header compression should be implemented. [RFC1144] header + compression can be enabled over robust network links. [RFC2507] + should be used over network connections that are expected to + experience loss due to corruption as well as loss due to congestion. + For extremely lossy and slow links, implementors should evaluate ROHC + [RFC3095] as a potential solution. [RFC1323] TCP timestamps must be + turned off because (1) their protection against TCP sequence number + wrapping is unjustified for slow links, and (2) they complicate TCP + header compression. + + + +Dawkins, et al. Best Current Practice [Page 10] + +RFC 3150 PILC - Slow Links July 2001 + + + IP Payload Compression [RFC2393] should be implemented, although + compression at higher layers of the protocol stack (for example [RFC + 2616]) may make this mechanism less useful. + + For HTTP/1.1 environments, [RFC2616] payload compression should be + implemented and should be used for payloads that are not already + compressed. + + Implementors should choose MTUs that don't monopolize network + interfaces for more than 100-200 milliseconds, in order to limit the + impact of a single connection on all other connections sharing the + network interface. + + Use of active queue management is recommended on last-hop routers + that provide Internet access to host behind a slow link. In + addition, number of router buffers per slow link should be large + enough to absorb concurrent data bursts from more than a single flow. + To absorb concurrent data bursts from two or three TCP senders with a + typical data burst of three back-to-back segments per sender, at + least six (6) or nine (9) buffers are needed. Effective use of + active queue management is likely to require even larger number of + buffers. + + Implementors should consider the possibility that a host will be + directly connected to a low-speed link when choosing default TCP + receive window sizes. + + Application developers should not attempt to manually manage network + bandwidth using socket buffer sizes as only in very rare + circumstances an application will be able to choose a suitable value + for the socket buffer size to obtain good network performance. + + Limited Transmit [RFC3042] should be implemented in all end hosts as + it assists in triggering fast retransmit when congestion window is + small. + + All of the mechanisms described above are stable standards-track RFCs + (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 a + wide variety of access link speeds. This is not a standards-track + 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) may + 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 Work + + In addition to the standards-track mechanisms discussed above, there + are still opportunities to improve performance over low-speed links. + + "Sending fewer bits" is an obvious response to slow link speeds. The + now-defunct HTTP-NG proposal [HTTP-NG] replaced the text-based HTTP + header representation with a binary representation for compactness. + However, HTTP-NG is not moving forward and HTTP/1.1 is not being + enhanced to include a more compact HTTP header representation. + Instead, the Wireless Application Protocol (WAP) Forum has opted for + the XML-based Wireless Session Protocol [WSP], which includes a + compact header encoding mechanism. + + It would be nice to agree on a more compact header representation + that will be used by all WWW communities, not only the wireless WAN + community. Indeed, general XML content encodings have been proposed + [Millau], although they are not yet widely adopted. + + We note that TCP options which change from segment to segment + effectively disable header compression schemes deployed today, + because there's no way to indicate that some fields in the header are + unchanged from the previous segment, while other fields are not. The + Robust Header Compression working group is developing such schemes + for TCP options such as timestamps and selective acknowledgements. + Hopefully, documents subsequent to [RFC3095] will define such + specifications. + + Another effort worth following is that of 'Delta Encoding'. Here, + clients that request a slightly modified version of some previously + cached resource would receive a succinct description of the + differences, rather than the entire resource [HTTP-DELTA]. + +5.0 Security Considerations + + All recommendations included in this document are stable standards- + track RFCs (at Proposed Standard status, as of this writing) or + otherwise do not suggest any changes to any protocol. With the + exception of Van Jacobson compression [RFC1144] and [RFC2507, + RFC2508, RFC2509], all other mechanisms are applicable to TCP + connections protected by end-to-end IPSec. This includes ROHC + [RFC3095], albeit partially, because even though it can compress the + outermost ESP header to some extent, encryption still renders any + payload data uncompressible (including any subsequent protocol + headers). + + + + + + +Dawkins, et al. Best Current Practice [Page 12] + +RFC 3150 PILC - Slow Links July 2001 + + +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 "Long Thin Networks" [RFC2757], + which in turn benefited from work done in the IETF TCPSAT working + group. + +8.0 References + + [AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End + Network Path Properties", in ACM SIGCOMM 99 Proceedings, + 1999. + + [HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work in + Progress. + + [HTTP-NG] Mike Spreitzer, Bill Janssen, "HTTP 'Next Generation'", + 9th International WWW Conference, May, 2000. Also + available as: http://www.www9.org/w9cdrom/60/60.html + + [Millau] Marc Girardot, Neel Sundaresan, "Millau: an encoding + format for efficient representation and exchange of XML + over the Web", 9th International WWW Conference, May, + 2000. Also available as: + http://www.www9.org/w9cdrom/154/154.html + + [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.html + + [RED93] Floyd, S., and Jacobson, V., Random Early Detection + gateways for Congestion Avoidance, IEEE/ACM Transactions + on Networking, V.1 N.4, August 1993, pp. 397-413. Also + available from http://ftp.ee.lbl.gov/floyd/red.html. + + [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed + 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 Extensions + for High Performance", RFC 1323, May 1992. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol: Version + 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 Congestion + Avoidance in the Internet", RFC 2309, April 1998. + + [RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP + Payload Compression Protocol (IPComp)", RFC 2393, + December 1998. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With + Four Packets Into Only Three Buffers", RFC 2416, + September 1998. + + [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header + Compression", RFC 2507, February 1999. + + [RFC2508] Casner, S. and V. Jacobson. "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, February + 1999. + + [RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header + Compression over PPP", RFC 2509, February 1999. + + [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion + Control", RFC 2581, 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. + + [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and + N. Vaidya, "Long Thin Networks", RFC 2757, January 2000. + + [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing + 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, "RObust + 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 from + http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html. + + [SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL + Protocol: Version 3.0, March 1996. (Expired Internet- + Draft, available from + http://home.netscape.com/eng/ssl3/ssl-toc.html) + + [TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan + Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of a + Busy Internet Server: Analysis and Improvements", IEEE + Infocom, March 1998. Available from: + http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz + + [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.pdf + + [WSP] Wireless Application Protocol Forum, "WAP Wireless + Session Protocol Specification", approved 4 May, 2000, + available from + 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' 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 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 + Fax: +358-9-1914-4441 + EMail: kojo@cs.helsinki.fi + + + Vincent Magret + Alcatel Internetworking, Inc. + 26801 W. Agoura road + Calabasas, CA, 91301 + + Phone: +1 818 878 4485 + EMail: vincent.magret@alcatel.com + + + + + + + + + + +Dawkins, et al. Best Current Practice [Page 16] + +RFC 3150 PILC - Slow Links July 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 17] + -- cgit v1.2.3