Internet Engineering Task Force      Audio/Video Transport Working Group
INTERNET-DRAFT                                        Scott Petrack, IBM
draft-petrack-crtp-00.txt
 Jun 1996                                         Expires: December 1996

                 Compression of Headers in RTP Streams

Status of this Memo

This document is a draft of a part of 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.

Please see the acknowledgements at the end of this note for a special
comment about the past, present, and future contributors to this note.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete 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."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

Abstract

We analyze the requirement to compress the headers of RTP
data streams. It is argued that there is a need to
define two different compression schemes: an "interim solution" in
which only RTP headers are compressed, and a "complete solution"
which compresses the RTP/UDP/IP headers only across serial links.
It is argued that the complete solution must include a new
"guaranteed header compression service," if it is to be useful.

The two solutions are described, along
with a transition strategy which ensures that only the
complete solution will be used when this is possible.

. Introduction

RTP [1] is finding acceptance as the standard means of transporting
time related data over the Internet.
Unfortunately, it is often impossible to use RTP/UDP/IP
over a low-bitrate link - the header overhead leaves no room at all for
data, or at the very least implies an unacceptable delay in the delivery
of the data, because too much data must be lumped into a single packet.

This paper gives two precise solutions. The central theme
common to both is to compress the headers of the RTP data stream.


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 2

The first solution involves compressing the RTP/UDP/IP headers
within the stream. Enabling this
requires specific additions to the current Internet infrastructure.
We show that these are necessary to produce a "complete" solution.
The modifications involved are similar in
spirit to those of the general framework outlined in [2].
But we claim that something stronger is needed.
Indeed, one can consider our solution as a definition of a new
service to be provided in the context of Integrated Services.

The second solution requires compressing only RTP itself, and can
be implemented immediately.  Because of its more limited nature, the
second solution gives only interim relief, and it is intended that it
will disappear seamlessly once the necessary Internet infrastructure
has been established. That is, the interim solution has enough
knowledge of the complete solution so that it can recognize the presence
of the complete solution in the network, and turn itself off.
We describe precisely the way in which
the "interim solution" will transform into the "complete solution."

This document is a submission to the IETF AVT working group. Although
our solution does indeed have implications for other IETF
working groups, the essential center of the work is a new algorithm
for the compression of headers which include RTP headers,
and how this header compression will
fit into Internet infrastructure. The problem that is
solved is how to enable the transport of real-time data
that cannot be transported using the full RTP/UDP/IP headers as
currently defined, when crossing a low bitrate link.

. What's the matter?

The smallest (and most common) size of an RTP header is 12 bytes [1]. When
combined with UDP and IP, this implies at least a 40 byte per header
overhead. There are many discussions available about the adverse effect
of header overhead on interactivity in general. See [3] for a discussion
of the particular problem of interactive telnet traffic.
This was a primary motivation for TCP/IP header compression now in
widespread use.
When the traffic involved is interactive voice, then header compression
ceases to be something extremely useful and becomes something absolutely
necessary. Indeed, consider transmitting voice over a link of bandwidth
b bytes/sec. Suppose that each there are:
        n bytes per each compressed voice-frame,
        f voice-frames/sec,
        h bytes/packet-header,

and suppose one decides to lump together k voice frames into each network
packet, in order to make it fit into the bandwidth b. A moment's thought
shows that the bandwidth required is:

                b = (nk + h) * (f / k) bytes/sec;



draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 3

Equivalently if we have b bandwidth available, then:

                k = (h * f)/(b-nf) voice-frames/network-packet.

k is the measure of the delay in the voice communication, so
this means that the delay will increase linearly with the total
header size.

There are at least two situations where the overhead is unnacceptable:

a. low-bandwidth serial links
    The explosion of modem dial-up links to the Internet, (and the
    explosion in the desire of users to run audio and video over
    those links), makes it imperative that RTP scale down to links
    of bandwidth 14.4kbps and 28.8kbps.

b. multiple RTP streams
    Some multimedia applications require several real-time streams
    to be running simultaneously, and each stream is a separate RTP
    session.

Of course, "low" is a relative term: an ISDN link is certainly
low bandwidth if one wishes to receive MBONE traffic. In general,
the ideas here will be useful on sub-T1 links as in
[2]. Also, we will restrict our attention to point-to-point links.
But much of the discussion will be valid for other link
technologies as well. We expect that the following technology
will indeed be useful in other contexts where it makes sense.

The current crop of Internet Telephone and Video applications
are very sensitive to this problem. The extra 12 bytes/packet
that RTP imposes has implied simply that these applications do
not use RTP. Now one solution is to blame these
horrible applications; but in fact with the currently common
frame rate of one voice frame every 20 msecs, the 40 byte
RTP/UDP/IP header per packet is already too large to send across
a 14.4kbps link. The problem is a real one.
Even if one excludes 14.4 kbps links (a terrible idea),
one must consider the Internet version of Parkison's
law: a bytestream expands to fill the bandwidth allotted to it.
These internet communication applications will continue to
develop, and they will continue to prefer to use the available
bandwidth for tranporting their data rather than headers.
Surely a decent respect for the prinicples of engineering
requires that one try to compress the transport headers in a
reasonable manner.

Note that although RTP is not quite a third of the total RTP/UDP/IP
bandwidth, it is indeed the difference between the possible and
the impossible for these applications: one can send 36 bytes every
20msecs over a 14.4 link. The result is that most applications
simply have not used RTP for encapsulating voice when there is
a slow serial link between the two ends. They use some non-
interoperable, proprietary scheme which sends at most one or two
bytes in place of RTP's 12.


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 4

Indeed, the problem of encapsulation overhead for real-time
streams has given rise to at least two incompatible ITU-T
standards for mixed voice and data over a serial link.
These developments should worry anyone who shares the dream of
IP and the Internet being used for multiple real-time and non-real
time streams, some of which may or may not be synchronized.
Excluding dial-up users from this game would be very sad, and
extremely counter-productive.

. Previous Suggestions

RTP-only compression as a means of making serial-link Internet Telephony
acceptable and interoperable was first proposed in [4]. It was suggested
to compress
only the RTP headers because not doing this is what made Internet Telephony
impossible, and because anything else requires changes to the Internet
infrastructure. It was immediately noticed [5] that one could combine
RTP-only compression independently with the IPv6 UDP/IP compression of
[6] to obtain a more useful service. And the
already cited [2] argues that compressing RTP makes sense only
in the framework of integrated services and compressing all the
headers RTP/UDP/IP, together with a real-time multiplexing service
for giving guranteed bandwidth or controlled load over a serial link.

There is a fourth possibility, which is recently proposed by Casner
and Jacobson in an upcoming (outcoming?) internet-draft [7], which is
to perform RTP/UDP/IP similarly to the way one now performs
TCP/IP header compression, according to RFC 1144.
This would be simply a new elective protocol for
compression of the RTP/UDP/IP headers across a point-to-point link,
divorced from the ideas of Integrated Services. Indeed,
it is explicitly stated in RFC 1144 that the two reasons not to compress
UDP/IP traffic are that this traffic either lacks coherence from packet to
packet (like DNS traffic), or that other higher level headers overwhelm
the gain from UDP/IP compression (like RPC/NFS). These two arguments are
clearly not valid for a typical RTP stream carrying interactive voice
traffic, if one extends to compress the 40 byte RTP/UDP/IP header.

In some sense these approaches are not contradictory and can co-exist.
But obviously one should not waste valuble time defining
and RTP-only compression scheme if indeed this is not useful, as [2]
argues. And if independent RTP and IPv6 UDP/IP compression is enough, then
there is no need to define a new RTP/UDP/IP standard, or to
juggle the integration that is required by Integrated Services.

. The Requirements

To uncut this difficult knot, let us list the requirements at hand:

a.      It is a requirement to end the current
        chaos of non-interoperable (and non-multicast) audio and video
        applications. This chaos does more and more harm, and a
        concerted effort to tame these applications is necessary immediately.


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 5

This means that an effort should be made to replace the one- (or few-)
byte real time encapsulation used by current realtime non-RTP applications
with some standard encapsulation which is not ruinous in overhead,
and yet allows for multicast and other applications. It is
certainly desireable, and probably required, that this encapsulation
contain all the information that is contained in RTP.

b.      There is a requirement to allow these applications to become good
        citizens without changing the Internet Infrastructure,
        since these applications are not going to wait for RTP/UDP/IP
        compression to become widespread over dialup links, and certainly not
        for Integrated Services to become widely available over dial up links.

This means that there must be some form of end-to-end RTP compression
sanctioned.

c.      There is a requirement to ourselves, to truth,
        justice, and the Internet Way, to decide what the correct solution
        is, or would be, if there were no Internet Telephones that need
        relief right now. Such a complete solution contains the
        following elements:
                1. no end-to-end hard state
                2. special header compresssion only along hops which
                require it - i.e. only along "slow links."
                3. along such slow links, since one must install state and
                new code, all headers should be compressed, not just RTP.
                4. if an application requires that such compression take place,
                there should be some standard interface to allow it.

It was argued in [2] that the PATH message of RSVP is the correct
"standard interface."

The word "requires" in c.4 demands special comment. The suggestions
mentioned above in section 2 all have one important point in common:
they assume that header compression is applied electively.
Even the suggestion to use the PATH message was so that the application
can inform the relevant links that compression is possible and desireable.

We claim that there is an important difference between TCP/IP compression
and the current situation of RTP applications over slow serial links: in the
current situation, the application truly *requires* there to be
header compression in order to make transmission worthwhile. It is not
just a very useful - it is necessary.
Using 40 byte RTP/UDP/IP headers over 14.4 modems implies delays
which are measured in seconds. It is common practise to blame "the
Internet" for such horrible performance, but some experimenting with
two computers connected via a null modem cable (or better, a single
brain connected to some paper and pencil) will convince one that
a single low bandwidth link implies unacceptably large delays.


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 6

For this reason, we are confronted with the need for a new service:
the application must be able to ask the network for a guarantee that
headers will be compressed along slow links. This is
a different service from either of the two usual services of IntServ.
A hard guarantee is required, but not of available bandwidth.
Internet Phones can work just fine without bandwidth guarantees or
even controlled load, but they cannot function with 40 byte
RTP/UDP/IP headers.

We have just argued that requirement c.4 implies the need for a new
service of "guranteed header compression," at least across slow
links.  There is another more unpleasant reason that the complete
solution should be careful to include giving an application
the right to to require guranteed header compression, related to
requirement b:

The current non-RTP one-byte encapsulation schemes have the advantage
that they Internet Telephone and Video applications to exist.
If it can happen with the new standard that there is a slow
link where RTP headers at least are not compressed, then
the applications won't use the new standard.
Certainly nothing is going to go to the
trouble of using a new piece of internet infrastructure unless it
gives them at least as good a service as it was getting with the old
infrastructure.
Only a "guaranteed header compression service" can give an application
the piece of mind that it has now, when it uses a proprietary one-byte
encapsulation. If the new extensions do not offer this much, then
the internet telephone applications will at best agree among themselves
on a new one or two-byte encapsulation.

You might think that the guaranteed bandwidth service,
when it becomes widely available, will suffice. This is unfortunately
not the case. We have seen that the entire bandwidth of a slow serial
link will not suffice if RTP/UDP/IP is used. In any case,
it is preferable to offer a "header compression service"
than to have all those applications use a guaranteed bandwidth service.

The conclusion is that there is requirement for a new service,
where the application can request a guarantee that the RTP/UDP/IP
headers will be compressed over the slow links.

More generally, one could make this service one whose
parameters would be the the protocols of
headers which for which one obtains a guarantee of compression, and
the type of link over which the compression will occur. This
service would be "XXX, YYY, ZZZ header compression over qqq-links."


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 7

The problem of dealing with header compression when using the usual
guaranteed bandwidth service was mentioned in [2], but in the context
of how to enable the routers to use the header compression to allow
them to reserve bandwidth. This is not the same as a guaranteed header
compression service, which is what is required here. A new service
for "guaranteed bandwidth b for my data, which is being sent with
protocols RTP/UDP/IP", although perhaps very useful, is stronger than
what is required. There will be many situations where header compression
is required but not guaranteed reserved bandwidth or even controlled
load. Of course, one might define a "header compression requested"
service to be the controlled-load analogue of the "header compression
required" service considered here.

There is one more feature left to consider, which we consider to be so
obviously desireable as to be a fourth requirement:

d.  There must be a smooth transition from the end-to-end compression
    scheme into the new integrated service being proposed. Indeed,
    it should be possible for any application which can negotiate for
    end-to-end compression to be able to receive and understand
    from the network a message which instructs it "not to bother"
    to perform the end-to-end compression, but to send full RTP
    headers and let the network take care of the compression.

If we can do this, there are very desireable advantages, apart from
the obvious one of planning the obsolence of something disgusting.
The application will be very happy to use the standard solution,
because is it guaranteed that it will obtain improved performance as
soon as the complete solution is in place. This is because the
complete solution will compress RTP/UDP/IP and not just RTP.
Also, it will allow forward compatibility with new applications
which will not know about the interim end-to-end compression.

We have now finished defining the task at hand. Let us list
our conclusions:

. We require an interim standard for end-to-end RTP compression.
. We require a complete solution which uses RTP/UDP/IP compression
        only over the slow links. The complete solution will also include a
        new Integrated Service: "guaranteed RTP/UDP/IP header
        compression over slow serial links."
. We require that the interim solution have enough knowledge of the
        complete solution that it will be able to recognize the presence
        of the complete solution in the network. When it does so, it will
        turn itself off.

The rest of this paper is devoted to defining these two compression
standards, "interim" and "complete." We shall also define
an algorithm by which an implementation of the interim solution will
detect the presence of the complete solution, and a QoS routing algorithm
which is needed to deploy the new Integrated Service.


draft-petrack-crtp-00.txt         Compression of Headers in RTP Streams
 Jun 1996                                                        Page 8


Left to write up:
. RTP/UDP/IP compression
. algorithm for QoS routing for guaranteed header compression on slow links,
   links to ISSLOW (ISSLL) and IntServ.
. RTP-only compression
. RTCP and RTCP/UDP/IP compression
. new RTCP message types to negotiate end-to-end RTP-only compression
. transition from interim to complete solution: using port on local stack
   to request complete solution in interim-solution applications



Acknowledgements:

The author wishes to acknowledge useful discussions with and expressions of
distaste from Steve Casner, Carsten Bormann, and Ed Ellesson.

NB: Steve Casner and Van Jacobson have produced an algorithm for
compression of the RTP/UDP/IP headers [7], which is being produced
as a separate draft at present. The author here both hopes and plans that
the two drafts will be merged into one. It is very important that
no end-to-end compression scheme be allowed which does not already
leave a hook for the complete solution.

The two drafts are at present separate because time considerations precluded
integration of any sort.

References:

[] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP:
        A Transport Protocol for real-time applications." RFC 1889

[] Carsten Borman:  "Providing integrated services over low-bitrate links"
        draft-bormann-issll-isslow-00-pre-3.txt
    (http://www-rn.informatik.uni-bremen.de/research/isslow.html, .txt, .ps)

[] Jacobson, "TCP/IP Compression for Low-Speed Serial Links." RFC 1144

[] Petrack and Ellesson, "Framework for C/RTP: Compressed RTP Using
        Adaptive Differential Header Compression."
        contribution to mailing list rem-conf@es.net,
    Feb. 96 and talk at AVT working group, IETF March 96

[] M. Degermark, private correspondence

[] Degermark et. al.: "Header Compression for IPv6"
                draft-degermark-ipv6-hc-00.txt

[] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for
                Low-Speed Serial Links." draft-casner-jacobson-crtp-00.txt

Author's Location Information

Name=Scott Petrack
Address=IBM Haifa Research Lab, Haifa 31905, Israel
Email=petrack@vnet.ibm.com
Telephone=+972 4 829 6290
Fax=+972 4 829 6112