RFC 2689 (rfc2689) - Page 4 of 14

Providing Integrated Services over Low-bitrate Links

RFC 2689       Integrated Services over Low-bitrate Links September 1999


   To be able to switch to a real-time packet quickly in an interface
   driver, it is first necessary to identify packets that belong to
   real-time flows.  This can be done using a heuristic approach (e.g.,
   favor the transmission of highly periodic flows of small packets
   transported in IP/UDP, or use the IP precedence fields in a specific
   way defined within an organization).  Preferably, one also could make
   use of a protocol defined for identifying flows that require special
   treatment, i.e. RSVP.  Of the two service types defined for use with
   RSVP now, the guaranteed service will only be available in certain
   environments; for this and various other reasons, the service type
   chosen for many adaptive audio/video applications will most likely be
   the controlled-load service.  Controlled-load does not provide
   control parameters for target delay; thus it does not unambiguously
   identify those packet streams that would benefit most from being
   transported in a real-time encapsulation format.  This calls for a
   way to provide additional parameters in integrated services flow
   setup protocols to control the real-time encapsulation.

   Real-time encapsulation is not sufficient on its own, however: Even
   if the relevant flows can be appropriately identified for real-time
   treatment, most applications simply cannot operate properly on low-
   bitrate links with the header overhead implied by the combination of
   HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header
   compression.

3.2.  Header Compression

   Header compression can be performed in a variety of elements and at a
   variety of levels in the protocol architecture.  As many vendors of
   Internet Telephony products for PCs ship applications, the approach
   that is most obvious to them is to reduce overhead by performing
   header compression at the application level, i.e. above transport
   protocols such as UDP (or actually by using a non-standard,
   efficiently coded header in the first place).

   Generally, header compression operates by installing state at both
   ends of a path that allows the receiving end to reconstruct
   information omitted at the sending end.  Many good techniques for
   header compression (RFC 1144, [2]) operate on the assumption that the
   path will not reorder the frames generated.  This assumption does not
   hold for end-to-end compression; therefore additional overhead is
   required for resequencing state changes and for compressed packets
   making use of these state changes.

   Assume that a very good application level header compression solution
   for RTP flows could be able to save 11 out of the 12 bytes of an RTP
   header [3].  Even this perfect solution only reduces the total header
   overhead by 1/4.  It would have to be deployed in all applications,



Bormann                      Informational