RFC 2689 (rfc2689) - Page 5 of 14
Providing Integrated Services over Low-bitrate Links
Alternative Format: Original Text Document
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



