Internet Engineering Task Force S. Dawkins
INTERNET DRAFT G. Montenegro
M. Kojo
V. Magret
May 30, 1998
Performance Implications of Link-Layer Characteristics:
Slow Links
draft-ietf-pilc-slow-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
Comments should be submitted to the PILC mailing list at
pilc@grc.nasa.gov.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The PILC (Performance Implications of Link-Layer Characteristics)
Working Group in IETF was chartered to develop a series of
recommendations for improved protocol performance in network paths
that traverse "extreme" link conditions. This document is part
of the PILC series, and focuses on network paths that traverse "very
low bit-rate" links.
Expires November 30, 1999 [Page 1]
INTERNET DRAFT PILC - Slow Links May 1999
"Very low bit-rate" implies "slower than we would like". This
recommendation may be used in any network where hosts can saturate
available bandwidth, but the design space for this recommendation
explicitly includes connections that traverse 4800 bit-per-second
links.
This document discusses general-purpose mechanisms. Where
application-specific mechanisms can outperform the relevant
general-purpose mechanism, we point this out and explain why.
Expires November 30, 1999 [Page 2]
INTERNET DRAFT PILC - Slow Links May 1999
1.0 Introduction
The Internet protocol stack was designed to span a wide range of
link speeds, and has met this design goal with only a limited number
of enhancements (for example, the use of RFC 1323 TCP window
scaling for very-high-bandwidth connections).
Pre-World Wide Web application protocols tended to be either
interactive applications sending very little data (Telnet) or bulk
transfer applications that did not require interactive response
(File Transfer Protocol, Network News).
The World Wide Web has given us traffic that is both interactive and
"bulky", including images, sound, and video.
The World Wide Web has also popularized the Internet, so that there
is significant interest in accessing the World Wide Web over link
speeds that are much "slower" than typical desktop host speeds.
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 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.
2.0 Header Compression Alternatives
Mechanisms for TCP and IP header compression defined in
[RFC1144, RFC2507, RFC2508, RFC2509] provide the following
benefits:
- Improve interactive response time
- Allow using small packets for bulk data with good line
efficiency
- Allow using small packets for delay sensitive low data-rate
traffic
- Decrease header overhead (for the smallest MTU of 512 the
header overhead of TCP over IP can decrease from 11.7 to less
than 1 per cent.
- Reduce packet loss rate over lossy links.
Expires November 30, 1999 [Page 4]
INTERNET DRAFT PILC - Slow Links May 1999
Van Jacobson (VJ) header compression [RFC1144] describes a
Proposed Standard for TCP Header compression that is widely
deployed. It uses TCP timeouts to detect a loss of
synchronization between the compressor and decompressor. [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).
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 [RFC2509].
VJ header compression should only be enabled when operating over
reliable "slow" links, because even a single bit error results in
a full TCP window being dropped, followed by a costly recovery
via slow-start.
3.0 Payload Compression Alternatives
Compression of IP payloads is also desirable. "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 FTPed), or are already encrypted above
the IP layer (SSL/TLS, etc.). These payloads will not "compress"
further, limiting the benefit of this optimization.
For uncompressed HTTP payload types, HTTP/1.1 [RFC2068] 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.
The current HTTP-NG proposal [HTTP-NG] replaces the text-based HTTP
header representation with a binary representation for compactness.
In general, application-level compression can often outperform
IPComp, because of the opportunity to use compression dictionaries
Expires November 30, 1999 [Page 5]
INTERNET DRAFT PILC - Slow Links May 1999
based on knowledge of the specific data being compressed.
All these compression techniques will reduce the need for IPComp,
especially for WWW users.
Recommendation: IPComp may optionally be implemented. Track
HTTP-NG standardization and deployment for now.
4.0 Summary of Recommended Optimizations
This section summarizes our recommendations regarding the previous
mechanisms, for end nodes that are capable of saturating available
bandwidth.
Header compression should be implemented. [RFC1144] header
compression can be enabled over robust network connections. [RFC2507]
should be used over network connections that are expected to
experience loss due to corruption as well as loss due to congestion.
IP Payload Compression [RFC2393] should be implemented, although
compression at higher layers of the protocol stack (examples:
[RFC 2068, HTTP-NG]) may make this mechanism less useful.
For HTTP/1.1 environments, [RFC2068] payload compression should be
implemented and should be used for payloads that are not already
compressed.
All of the mechanisms described in this document are stable
standards-track RFCs (at Proposed Standard status, as of
this writing), with the exception of [HTTP-NG], which is included
for completeness.
Of the above mechanisms, only Header Compression (for IP and TCP)
ceases to work in the presence of IPSec.
5.0 Acknowledgements
This recommendation has grown out of the Internet Draft "TCP Over
Long Thin Networks", which was in turn based on work done in the
IETF TCPSAT working group.
6.0 References
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for
Expires November 30, 1999 [Page 6]
INTERNET DRAFT PILC - Slow Links May 1999
Low-Speed Serial Links," RFC 1144, February 1990. (Proposed
Standard)
[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. (Proposed Standard)
[HTTP-NG] H. Frystyk Nielsen, Mike Spreitzer, Bill Janssen, Jim
Gettys, "HTTP-NG Overview", draft-frystyk-httpng-overview-00.txt,
November 17, 1998, expired, but also available from
http://www.w3.org/Protocols/HTTP-NG/1998/11/.
[RFC2393] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP
Payload Compression Protocol (IPComp)," RFC 2393, December
1998. (Proposed Standard)
[RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink. "IP
Header Compression," RFC 2507, February 1999. (Proposed
Standard)
[RFC2508] S. Casner, V. Jacobson. "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links," RFC 2508, February 1999.
(Proposed Standard)
[RFC2509] Mathias Engan, S. Casner, C. Bormann. "IP Header
Compression over PPP," RFC 2509, February 1999. (Proposed
Standard)
Authors' addresses
Questions about this document may be directed to:
Spencer Dawkins
Nortel Networks
P.O. Box 833805
Richardson, Texas 75083-3805
Voice: +1-972-684-4827
Fax: +1-972-685-3292
E-Mail: sdawkins@nortelnetworks.com
Expires November 30, 1999 [Page 7]
INTERNET DRAFT PILC - Slow Links May 1999
Gabriel E. Montenegro
Sun Labs Networking and Security Group
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303
Voice: +1-650-786-6288
Fax: +1-650-786-6445
E-Mail: gab@sun.com
Markku Kojo
University of Helsinki/Department of Computer Science
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-7084-4179
Fax: +358-9-7084-4441
E-Mail: kojo@cs.helsinki.fi
Vincent Magret
Corporate Research Center
Alcatel Network Systems, Inc
1201 Campbell
Mail stop 446-310
Richardson Texas 75081 USA
M/S 446-310
Voice: +1-972-996-2625
Fax: +1-972-996-5902
E-mail: vincent.magret@aud.alcatel.com
Expires November 30, 1999 [Page 8]
INTERNET DRAFT PILC - Slow Links May 1999
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 Header Compression Alternatives . . . . . . . . . . . . . . . . 3
3.0 Payload Compression Alternatives . . . . . . . . . . . . . . . . 5
4.0 Summary of Recommended Optimizations . . . . . . . . . . . . . . 6
5.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
6.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' addresses . . . . . . . . . . . . . . . . . . . . . . . . . 7
Expires November 30, 1999 [Page 3]
