datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
RFC 2508

Document type: RFC - Proposed Standard (February 1999)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 2508 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                          S. Casner
Request for Comments: 2508                                 Cisco Systems
Category: Standards Track                                    V. Jacobson
                                                           Cisco Systems
                                                           February 1999

       Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a method for compressing the headers of
   IP/UDP/RTP datagrams to reduce overhead on low-speed serial links.
   In many cases, all three headers can be compressed to 2-4 bytes.

   Comments are solicited and should be addressed to the working group
   mailing list rem-conf@es.net and/or the author(s).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

1.  Introduction

   Since the Real-time Transport Protocol was published as an RFC [1],
   there has been growing interest in using RTP as one step to achieve
   interoperability among different implementations of network
   audio/video applications.  However, there is also concern that the
   12-byte RTP header is too large an overhead for 20-byte payloads when
   operating over low speed lines such as dial-up modems at 14.4 or 28.8
   kb/s.  (Some existing applications operating in this environment use
   an application-specific protocol with a header of a few bytes that
   has reduced functionality relative to RTP.)

Casner & Jacobson           Standards Track                     [Page 1]
RFC 2508             Compressing IP/UDP/RTP Headers        February 1999

   Header size may be reduced through compression techniques as has been
   done with great success for TCP [2].  In this case, compression might
   be applied to the RTP header alone, on an end-to-end basis, or to the
   combination of IP, UDP and RTP headers on a link-by-link basis.
   Compressing the 40 bytes of combined headers together provides
   substantially more gain than compressing 12 bytes of RTP header alone
   because the resulting size is approximately the same (2-4 bytes) in
   either case.  Compressing on a link-by-link basis also provides
   better performance because the delay and loss rate are lower.
   Therefore, the method defined here is for combined compression of IP,
   UDP and RTP headers on a link-by-link basis.

   This document defines a compression scheme that may be used with
   IPv4, IPv6 or packets encapsulated with more than one IP header,
   though the initial focus is on IPv4.  The IP/UDP/RTP compression
   defined here is intended to fit within the more general compression
   framework specified in [3] for use with both IPv6 and IPv4.  That
   framework defines TCP and non-TCP as two classes of transport above
   IP.  This specification creates IP/UDP/RTP as a third class extracted
   from the non-TCP class.

2.  Assumptions and Tradeoffs

   The goal of this compression scheme is to reduce the IP/UDP/RTP
   headers to two bytes for most packets in the case where no UDP
   checksums are being sent, or four bytes with checksums.  It is
   motivated primarily by the specific problem of sending audio and
   video over 14.4 and 28.8 dialup modems.  These links tend to provide
   full-duplex communication, so the protocol takes advantage of that
   fact, though the protocol may also be used with reduced performance
   on simplex links.  This compression scheme performs best on local
   links with low round-trip-time.

   This specification does not address segmentation and preemption of
   large packets to reduce the delay across the slow link experienced by
   small real-time packets, except to identify in Section 4 some
   interactions between segmentation and compression that may occur.
   Segmentation schemes may be defined separately and used in
   conjunction with the compression defined here.

   It should be noted that implementation simplicity is an important
   factor to consider in evaluating a compression scheme.
   Communications servers may need to support compression over perhaps
   as many as 100 dial-up modem lines using a single processor.

[include full document text]