RFC 2689 (rfc2689) - Page 5 of 14


Providing Integrated Services over Low-bitrate Links



Alternative Format: Original Text Document

< Previous
Next >


RFC 2689       Integrated Services over Low-bitrate Links September 1999


   even those that operate on systems that are attached to higher-
   bitrate links.

   Because of this limited effectiveness, the AVT group that is
   responsible for RTP within the IETF has decided to not further pursue
   application level header compression.

   For router and IP stack vendors, the obvious approach is to define
   header compression that can be negotiated between peer routers.

   Advanced header compression techniques now being defined in the IETF
   [2] certainly can relieve the link from significant parts of the
   IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above).

   One of the design principles of the new IP header compression
   developed in conjunction with IPv6 is that it stops at layers the
   semantics of which cannot be inferred from information in lower layer
   (outer) headers.  Therefore, this header compression technique alone
   cannot compress the data that is contained within UDP packets.

   Any additional header compression technique runs into a problem: If
   it assumes specific application semantics (i.e., those of RTP and a
   payload data format) based on heuristics, it runs the risk of being
   triggered falsely and (e.g. in case of packet loss) reconstructing
   packets that are catastrophically incorrect for the application
   actually being used.  A header compression technique that can be
   operated based on heuristics but does not cause incorrect
   decompression even if the heuristics failed is described in [7]; a
   companion document describes the mapping of this technique to PPP
   [10].

   With all of these techniques, the total IP/UDP/RTP header overhead
   for an audio stream can be reduced to two bytes per packet.  This
   technology need only be deployed at bottleneck links; high-speed
   links can transfer the real-time streams without routers or switches
   expending CPU cycles to perform header compression.

4.  Principles of Real-Time Encapsulation for Low-Bitrate Links

   The main design goal for a real-time encapsulation is to minimize the
   delay incurred by real-time packets that become available for sending
   while a long data packet is being sent.  To achieve this, the
   encapsulation must be able to either abort or suspend the transfer of
   the long data packet.  As an additional goal is to minimize the
   overhead required for the transmission of packets from periodic
   flows, this strongly argues for being able to suspend a packet, i.e.
   segment it into parts between which the real-time packets can be
   transferred.



Bormann                      Informational


< Previous
Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions