RFC 3150

End-to-end Performance Implications of Slow Links

📅 published July 2001, from ietf
  • Network Working Group (the group that wrote it 🧚)
  • RFC number: 3150
  • BCP: 48
  • Category: Best Current Practice 💅
  • Authors: S. Dawkins, G. Montenegro, M. Kojo, and V. Magret 👑
  • Date: July 2001 🌸
  • Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🙈

Status of this Memo 🦋

Okay so this document is an Internet Best Current Practice for the Internet Community, and it's literally begging for discussion and suggestions for improvements 🫶. Distribution of this memo is unlimited ✨.

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

Abstract 💜

This doc gives performance-related recommendations for users of network paths that go through "very low bit-rate" links 🐢.

"Very low bit-rate" basically means "slower than we would like" 😭. This recommendation could be useful in any network where hosts can saturate the available bandwidth, but the design space here explicitly includes connections that go over 56 Kb/second modem links or 4.8 Kb/second wireless access links. Both of those are widely deployed, so it's not a niche thing 💖.

This doc talks about general-purpose mechanisms. When application-specific mechanisms can outperform the relevant general-purpose one, we point that out and explain why 🔥.

This doc has some recommendations in common with RFC 2689, "Providing integrated services over low-bitrate links" ✨, especially in areas like header compression. This doc focuses more on traditional data applications where "best-effort delivery" is appropriate 🍓.

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 work across a wide range of link speeds, and it's met that design goal with only a limited number of enhancements. One example is the use of TCP window scaling, described in "TCP Extensions for High Performance" [RFC1323], for very-high-bandwidth connections 🚀.

Pre-World Wide Web application protocols were usually either interactive apps sending very little data (like Telnet), or bulk transfer apps that didn't need interactive response (like File Transfer Protocol or Network News) 📚. Then the World Wide Web showed up and gave us traffic that's both interactive and often "bulky", including images, sound, and video 🎬.

The Web also popularized the Internet, so lots of people want to access it over link speeds that are much "slower" than typical office networks 🐌. Honestly, a big chunk of current Internet users connect over a relatively slow last-hop link 😭. In the future, that number is likely to jump fast, since various mobile devices are expected to attach to the Internet over slow wireless links 📱.

To give the best interactive response for these "bulky" transfers, implementors may want to minimize the number of bits actually sent over these "slow" connections 🧠. There are two areas to look at: compressing the bits that make up the overhead of the connection, and compressing the bits that make up the payload being carried over it 💅.

Also, implementors may want to think about TCP receive window settings and queuing mechanisms as ways to improve performance over low-speed links ✨. These techniques don't involve protocol changes, but they're included here for completeness 🫶.

2.0 Description of Optimizations 🧚

This section describes optimizations that have been suggested for situations where hosts can saturate their links 🔥. The next section summarizes recommendations about using these optimizations 👑.

2.1 Header Compression Alternatives 🎀

Mechanisms for TCP and IP header compression, defined in [RFC1144, RFC2507, RFC2508, RFC2509, RFC3095], give you 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 drop from about 13 percent with typical 40-byte headers to 1-1.5 percent with 3-5 byte compressed headers, for most packets. This makes small packets usable for delay-sensitive, low data-rate traffic, and gives 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 the 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, and it's widely deployed 🌍. Unfortunately, it's vulnerable on lossy links, because even a single bit error causes the compressor and decompressor to lose synchronization 😩. It uses TCP timeouts to detect that loss of synchronization, but these errors result in loss of data (up to a full TCP window), delay of a full RTO, and unnecessary slow-start 💀.

A more recent header compression proposal, [RFC2507], includes an explicit request for retransmission of an uncompressed packet. That lets it resynchronize without waiting for a TCP timeout (and without running congestion avoidance procedures) 🙌. This works much better on links with lossy characteristics 💖.

The scheme above stops performing well under conditions as extreme as those of many cellular links, where error conditions are 1e-3 or 1e-2 and round trip times are over 100 ms 📶. For these cases, the 'Robust Header Compression' working group developed ROHC [RFC3095] 🦾. Extensions of ROHC to support compression of TCP headers are also under development 🧩.

[RFC1323] defines a "TCP Timestamp" option. It's 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 ⏱️. But using TCP timestamps prevents header compression, because the timestamps are sent as TCP options 🙈. Each timestamped header has TCP options that differ from the previous header, and headers with changed TCP options are always sent uncompressed 😤. Also, timestamps don't seem to have much impact on RTO estimation [AlPa99] 🤷‍♀️.

Even so, the ROHC working group is developing schemes to compress TCP headers, including options such as timestamps and selective acknowledgements 🛠️.

Recommendation: Implement [RFC2507], particularly 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 whether 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 fix this, those mechanisms aren't fully developed or deployed yet, and may not be generally justifiable 🥲. Also, connections going over "slow" links don't need protection against TCP sequence-number wrapping 🧘‍♀️.

2.2 Payload Compression Alternatives 🌈

Compressing 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 kind of a niche optimization 🙃. It's necessary because IP-level security turns IP payloads into random bitstreams 🔐. That defeats the commonly-deployed link-layer compression mechanisms, which are faced with payloads that have no redundant "information" that could be represented more compactly 😵.

However, lots of IP payloads are already compressed (images, audio, video, and "zipped" files being transferred), or are already encrypted above the IP layer (for example, SSL [SSL] and TLS [RFC2246]) 🎥. These payloads won't "compress" any further, which limits the benefit of this optimization 📉.

For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also includes Content-Encoding and Accept-Encoding headers 🗜️. These support a variety of compression algorithms for common compressible MIME types like text/plain. That leaves only the HTTP headers themselves uncompressed 📄.

In general, application-level compression can often outperform IPComp, because it can 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 🫶.

Part 1 of 4 is done, bestie! 💖 More sections are coming, so stay tuned 🧚✨

2.3 Choosing MTU Sizes

okay bestie, picking an MTU for low-speed links is a whole vibe 💅 there are a few things to keep in mind, so let's go:

First 🫶 if a full-length MTU hogs the link for longer than the delayed ACK timeout (typically 200 milliseconds, but it can be up to 500 milliseconds), that timeout makes an ACK get generated for every single segment instead of every second one, which is what most implementations of the TCP delayed ACK algorithm do. ngl that's a plot twist 😭

Second 🌸 "relatively large" MTUs take human-perceptible amounts of time to get pushed into the network, and that creates human-perceptible delays for every other flow using the same link. [RFC1144] counts 100-200 milliseconds as human-perceptible. The convention of using 296-byte MTUs (with header compression enabled) for dialup access is a compromise, keeping the maximum link occupancy delay with full-length MTUs close to 200 milliseconds on 9.6 Kb/second links. iconic compromise 👑

Third 🦋 on last-hop links, a larger link MTU means a larger MSS, which lets a TCP sender grow its congestion window faster in bytes than it could with a smaller MTU (and smaller MSS). BUT, lowkey the twist: with a smaller MTU and smaller MSS, the congestion window measured in segments increases more quickly than it would with a larger MSS. Connections using smaller MSS sizes are more likely to send enough segments to generate three duplicate acknowledgements, which triggers fast retransmit/fast recovery when packet losses are encountered. Hence, a smaller MTU is useful for slow links with lossy characteristics 🍓

Fourth 🧚 using a smaller MTU also decreases the queuing delay of a TCP flow (and therefore its RTT) compared to a larger MTU with the same number of packets in a queue. So a TCP flow using a smaller segment size on a slow link can inflate its congestion window (in number of segments) to a larger value while experiencing the same queuing delay. main character energy ✨

Finally 💜 some networks charge for traffic per packet, not per kilobyte. In those cases, connections using a larger MTU may get charged less than connections moving the same number of bytes with a smaller MTU. money talk, periodt 💀

Recommendation: If it is possible to do so, pick MTUs 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]

okay so this one is so relatable 🥺 a lot of TCP connections that cross slow links have the slow link as an "access" link, with faster links doing most of the work on the rest of the path. a super common setup is a laptop on dialup talking to a terminal server (a last-hop router), with an HTTP server sitting on a high-speed LAN "behind" that terminal server 🌈

here's the drama 🔥 the HTTP server can drop packets onto its directly-attached high-speed LAN faster than the last-hop router can forward them down the low-speed link. when the last-hop router falls behind, it can't buffer all that traffic meant for the slow link, so it becomes a point of congestion and starts dropping the excess packets. specifically, several packets can get dropped in a single transmission window when the initial slow start overshoots the last-hop router buffer 😭

packet loss is happening, but the TCP sender doesn't notice until one RTT after the router buffer space runs out and the first packet gets dropped. that late congestion signal lets the congestion window keep growing, up to double its size at the moment the first packet was dropped at the router. not ideal, bestie 🙈

if the link MTU is big enough that transmitting one packet takes longer than the delayed ACK timeout interval, an ACK gets sent for every segment and the congestion window doubles in a single RTT. if a smaller link MTU is in use and delayed ACKs can be used, the congestion window increases by a factor of 1.5 in one RTT. either way, the sender keeps transmitting well past the last-hop router's congestion point, which causes multiple packet losses in a single window 💀

the good news is that the self-clocking nature of TCP's slow start and congestion avoidance algorithms stops this buffer overrun from continuing. these algorithms also let senders "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 that link. during congestion avoidance, the peer host keeps probing for available bandwidth, trying to fill the advertised window, until packet loss occurs 🦋

the same problems can show up when a sending host is directly connected to a slow link, since most slow links have some local buffer in the link interface. that link interface buffer can overflow in exactly the same way as the last-hop router buffer 🧸

when a last-hop router has a small number of buffers per outbound link, the first buffer overflow happens earlier than it would if the router had more buffers. then, with fewer buffers, the periodic packet losses happen more frequently during congestion avoidance, when the sender is probing for available bandwidth 🥀

the biggest job of router buffers is absorbing bursts ✨ too few buffers (for example, only three buffers per outbound link as described in [RFC2416]) means routers will overflow their buffer pools very easily and are unlikely to absorb even a tiny burst. with a larger number of router buffers per outbound link, the buffer space doesn't overflow as quickly, but the buffers are still likely to fill up because of TCP's default behavior. more buffers also means longer queuing delays and a longer RTT 🫠

if router queues fill up before congestion is signaled, or stay full for long periods, you get "lock-out" 😱 where a single connection or a few connections take over the router queue space and stop other connections from using the link [RFC2309], especially when a tail drop queue management discipline is being used.

so it's essential to have enough buffers in routers to absorb data bursts, while keeping the queues normally small 🎀 to get there, [RFC2309] recommends that an active queue management mechanism, like Random Early Detection (RED) [RED93], be implemented in all Internet routers, including the last-hop routers in front of a slow link. just know that RED needs a sufficiently large number of router buffers to work properly, and the appropriate RED parameters on a last-hop router connected to a slow link will likely differ from the recommended defaults 🌸

active queue management doesn't eliminate packet drops. instead, it drops packets earlier to solve the full-queue problem for flows that respond to packet drops as a congestion signal 💜 hosts directly connected to low-speed links may limit the receive windows they advertise, to lower or eliminate packet drops in a last-hop router. when they do that, take care that the advertised window is still large enough to fully utilize the last-hop link capacity and to trigger 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, which is typically a system-wide parameter. (This "choice" may be as simple as "dial-up access/LAN access" on a dialog box, which would accommodate many environments without requiring hand-tuning by experienced network engineers.)
  • 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 every network path that might involve a slow link 🙅‍♀️ it's applicable in environments where the host "knows" it's always connected to other hosts via "slow links". for hosts that might connect to other host over a variety of links (like dial-up laptops with LAN-connected docking stations), buffer auto-tuning for the receive buffer is a more reasonable recommendation, which we'll get into below 🧚

2.5 TCP Buffer Auto-tuning

okay this section is giving "balance" 🎀 [SMM98] points out a tension between wanting "large" TCP buffers so network paths get fully utilized, and wanting to limit the memory dedicated to TCP buffers so you can efficiently support huge numbers of connections to hosts over network paths that can vary by six orders of magnitude 🌈

the technique they propose is to dynamically allocate TCP buffers based on the current congestion window, instead of preallocating TCP buffers without knowing anything about the network path ✨ this results in receive buffers that suit the window sizes in use, and send buffers big enough to hold two windows of segments. that way SACK and fast recovery can repair losses without forcing the connection into lengthy retransmission timeouts 💅

most of the motivation for this proposal comes from a server's perspective, but hosts connecting through multiple interfaces with markedly different link speeds may find this technique useful too 🦋 this is especially true with slow links, which are likely to dominate the end-to-end RTT. if the host is connected through only a single slow link interface at a time, it's pretty easy to dynamically adjust the receive window (and so the advertised window) to a value that fits that slow last-hop link's known bandwidth and delay characteristics 🫶

Recommendation: If a host is sometimes connected via a slow link, but 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. 🍓

2.6 Small Window Effects 🌸

okay so if a TCP connection settles down with a congestion window of only a few segments (totally expected on a "slow" link 🐢), the sender isn't sending enough segments to produce three duplicate acknowledgements 😭. that means fast retransmit and fast recovery never get triggered. instead a retransmission timeout has to repair the loss, which drops the connection down to a congestion window of just one segment 💀

[TCPB98] and [TCPF98] noticed (in studies of network trace datasets 👀) that TCP retransmission timeouts happen pretty often even when some duplicate acknowledgements are already being sent. the challenge is using those duplicate acks to trigger fast retransmit/fast recovery WITHOUT injecting extra traffic into the network, and especially not in ways that cause instability 🫣

the "Limited Transmit" algorithm [RFC3042] suggests sending a new segment when the first and second duplicate acknowledgements arrive. this way the receiver is more likely to keep generating duplicate acknowledgements until the TCP retransmit threshold is reached, which triggers fast retransmit and fast recovery ✨ when the congestion window is small, this is SO useful for helping fast retransmit and fast recovery fix a packet loss without needing a retransmission timeout 🙌 heads up though: a maximum of two additional new segments will be sent before the receiver either sends a new acknowledgement that advances the window, or sends two additional duplicate acknowledgements (which triggers fast retransmit/fast recovery). and these new segments are acknowledgement-clocked, not back-to-back 🎀

Recommendation: Limited Transmit SHOULD be implemented in all hosts. 💖

this section sums up our recommendations for the earlier 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. and [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 🙅‍♀️

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, so a single connection can't hog everyone else's time on the network interface they share 🫶

Use of active queue management is RECOMMENDED on last-hop routers that provide Internet access to hosts behind a slow link 🛜 also, the 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 need an 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, because only in very rare circumstances will an application be able to choose a suitable value for the socket buffer size to get good network performance 🙈

Limited Transmit [RFC3042] SHOULD be implemented in all end hosts, since it helps trigger fast retransmit when the 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 since it's 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 🔐

4.0 Topics For Further Work 🔭

in addition to the standards-track mechanisms we talked about above, there are still chances to improve performance over low-speed links 🚀

"Sending fewer bits" is the obvious response to slow link speeds 🤏 the now-defunct HTTP-NG proposal [HTTP-NG] swapped the text-based HTTP header representation for a binary one, to be more compact. but 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 went with 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 all WWW communities use, not only the wireless WAN community 🌍 and honestly, general XML content encodings have been proposed [Millau], although they aren't widely adopted yet 🫠

We note that TCP options which change from segment to segment effectively disable the 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 like timestamps and selective acknowledgements 👩‍💻 hopefully, documents that come after [RFC3095] will define such specifications 🤞

another effort worth following is 'Delta Encoding' 👀 here, clients that request a slightly modified version of some previously cached resource would get a succinct description of the differences, instead of the entire resource [HTTP-DELTA] ✨

5.0 Security Considerations 🚨

okay this part is SERIOUS bestie 😤 all recommendations in this document are stable standards-track RFCs (at Proposed Standard status, as of this writing), or they otherwise don't suggest any changes to any protocol. with the exception of Van Jacobson compression [RFC1144] and [RFC2507, RFC2508, RFC2509], all the other mechanisms are applicable to TCP connections protected by end-to-end IPSec. this includes ROHC [RFC3095], albeit partially 🫢 even though it can compress the outermost ESP header to some extent, encryption still makes any payload data uncompressible (including any subsequent protocol headers). so yeah, be careful with the encryption + compression combo 💀🔐

6.0 IANA Considerations 📋

this document is just a pointer to other, existing IETF standards 🧭 so there are no new IANA considerations ✅

7.0 Acknowledgements 🫶

this recommendation grew out of "Long Thin Networks" [RFC2757], which in turn benefited from work done in the IETF TCPSAT working group 🌷 thank you, TCPSAT, you iconic legends 🌈

8.0 References 📚✨

okay bestie, the reference list is where all the receipts live 🧾💅 every single source the RFC leans on is listed here, so you can go read the originals if you want the full story 🌸

Reference list

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

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

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

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

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.

📦 where this page comes from