RFC 2689

Providing Integrated Services over Low-bitrate Links

📅 published September 1999, from ietf

okay bestie, let's get into it 🎀 This one is from September 1999 and it's by C. Bormann from Universitaet Bremen TZI 🦋. It's Informational, so it's sharing info for the Internet community and is NOT a standard. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🧚

Status of this Memo ✨

okay so this memo is giving info for the Internet community 🫶 It does NOT specify an Internet standard of any kind, and you can distribute it as much as you want (distribution is unlimited) 💅

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

Abstract 🌸

this doc describes an architecture for giving integrated services over low-bitrate links like modem lines, ISDN B-channels, and sub-T1 links 💜 it only covers the lower parts of the Internet Multimedia Conferencing Architecture [1]. Extra components needed for app services like Internet Telephony (for example, a session initiation protocol) are out of scope here 🙈

the main pieces are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols that apps use so this negotiation can happen ✨

1. Introduction ✨

okay so the Internet is famous for "best-effort" service, right? Well, there are now extra service types ("integrated services") that support real-time multimedia, and they're being developed and deployed 🌈 The big pieces are:

  • forwarding mechanism parameters that suit real-time info [11, 12],
  • a setup protocol that lets you set up special forwarding for real-time flows (RSVP [4]),
  • a transport protocol for real-time info (RTP/RTCP [6]).

on top of the network and transport levels of the Internet Multimedia Conferencing Architecture [1], you still need more components to define app services like Internet Telephony, such as protocols for session initiation and control 🧚 Those are out of scope for this doc 💅

here's the tea 🍓 Until now, the new services either couldn't run or ran super inefficiently over forwarding paths with low-bitrate links, like 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN B-channels, or even sub-T1 links 😭 The encapsulation formats on these links aren't good for sending arbitrary data and real-time info (which has strict delay requirements) at the same time. Sending a 1500 byte packet over a 28.8 kbit/s modem link ties up that link for about 400 ms, so no real-time stuff can go through during that time. That adds a worst-case delay that makes real-time apps have round-trip delays of at least a second, which is totally unacceptable for a real-time convo 💀

and the header overhead on the protocol stacks is also a huge problem on low-bitrate links, where you often want to compress down to a few dozen bytes per real-time packet 🙈 The overhead of at least 44 (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP totally overshadows typical audio payloads, like the 19.75 bytes needed for a G.723.1 ACELP audio frame. A 14.4 kbit/s link is completely eaten by this header overhead alone at 40 real-time frames per second total (that's 25 ms packetization delay for one stream or 50 ms for two streams), with no room left for data at all 😭 You can reduce the header overhead by combining several real-time frames into one packet, but that increases the delay while you fill the packet, which works against the whole goal of real-time multimedia over the Internet 💔

this doc describes an approach to fix all of this 🦋 The main components are:

  • a real-time encapsulation format for asynchronous and synchronous low-bitrate links,
  • a header compression architecture optimized for real-time flows,
  • elements of negotiation protocols used between routers (or between hosts and routers), and
  • announcement protocols used by apps so this negotiation can take place.

2. Design Considerations 💅

the main design goal for an architecture handling real-time multimedia flows over low-bitrate links is minimizing end-to-end delay 👑 More specifically, the worst-case delay (after removing possible outliers, which are basically packet losses from an app's point of view) is what decides the playout points the apps pick, and that's the delay the user actually feels 🎀

any architecture like this should also try its hardest to maximize the bandwidth that's actually available for media data, so overheads have to be minimized ✨

an important part of the integrated services architecture is providing reservations for real-time flows 🔥 One problem for systems on low-bitrate links (routers or hosts) doing admission control for these reservations is that they have to translate the bandwidth requested in the reservation into the bandwidth actually used on the link 💀 Data compression and/or header compression can lower what the link needs, but admission control can only use those lower numbers if it knows enough about the data stream to predict how well the compression will work 🧠 So one goal of the architecture is giving integrated services admission control that info. A nice bonus is that systems might be able to compress better than they could without it 🌸 That might make it worth providing this info even when you're not making a reservation for a real-time flow 🫶

3. The Need for a Concerted Approach 🌈

there are lots of technical approaches that come to mind for these problems, especially a new form of low-delay encapsulation for the delay issue and header compression methods for the overhead issue 💜 This section shows that these techniques should be combined to actually solve the problem ✨

3.1. Real-Time Encapsulation 🧚

the point of a real-time link-layer encapsulation protocol is letting newly arrived real-time packets get into the link-layer data stream without waiting for the currently transmitted (possibly huge) packet to finish 🦋 Honestly, a real-time encapsulation has to be part of any complete solution, because the delays caused by big frames on the link can only be fixed at this layer 🔥

to switch to a real-time packet quickly in an interface driver, you first have to identify packets that belong to real-time flows 👑 You can do this with a heuristic approach (for example, favor transmitting highly periodic flows of small packets carried in IP/UDP, or use the IP precedence fields in a specific way defined within an organization) 🎀 Ideally, you could also use a protocol designed to identify flows that need special treatment, which is RSVP 💅 Of the two service types defined for use with RSVP right now, the guaranteed service will only be available in certain environments. For this and various other reasons, the service type most adaptive audio/video apps will probably use is the controlled-load service 🌸 Controlled-load doesn't provide control parameters for target delay, so it doesn't unambiguously identify the packet streams that would benefit most from a real-time encapsulation format 😭 That means we need a way to provide additional parameters in integrated services flow setup protocols to control the real-time encapsulation ✨

real-time encapsulation isn't enough on its own, though 💔 Even when the relevant flows can be correctly identified for real-time treatment, most apps simply can't work properly on low-bitrate links with the header overhead from HDLC/PPP, IP, UDP, and RTP combined. They absolutely need header compression 🙈

3.2. Header Compression 🫶

header compression can happen in lots of different elements and at lots of different levels of the protocol architecture 🌈 Many Internet Telephony vendors for PCs ship apps, and the most obvious approach for them is cutting overhead with header compression at the application level, which means above transport protocols like UDP (or just using a non-standard, efficiently coded header from the start) 💜

generally, header compression works by installing state at both ends of a path so the receiving end can rebuild info that was left out at the sending end 🧠 A lot of good header compression techniques (RFC 1144, [2]) assume the path won't reorder the frames that were generated. That assumption doesn't hold for end-to-end compression, so you need extra overhead for resequencing state changes and for compressed packets that use those state changes 😭

now imagine a really good app-level header compression solution for RTP flows that could save 11 out of the 12 bytes of an RTP header [3]. Even this perfect solution only cuts the total header overhead by 1/4 💀 And it would have to be deployed in every app, even on systems attached to higher-bitrate links where it doesn't matter 🙄

because of this limited effectiveness, the AVT group (the IETF group responsible for RTP) decided to stop pursuing app-level header compression 🦋

for router and IP stack vendors, the obvious approach is defining header compression that can be negotiated between peer routers ✨

advanced header compression techniques being defined in the IETF [2] can definitely take a big chunk of the IP/UDP overhead off the link (most of the 28 of the 44 bytes mentioned above) 👑

one design principle of the new IP header compression developed alongside IPv6 is that it stops at layers whose semantics can't be inferred from info in the lower layer (outer) headers 🎀 So this header compression technique on its own can't compress the data inside UDP packets 💅

any additional header compression technique runs into a problem, though 🔥 If it assumes specific app semantics (those of RTP and a payload data format) based on heuristics, it risks being triggered falsely. In the case of packet loss, for example, it could reconstruct packets that are catastrophically incorrect for the app actually being used 😱 A header compression technique that can run on heuristics but doesn't cause incorrect decompression even when the heuristics fail is described in [7], and a companion doc describes how to map this technique to PPP [10] 🫶

with all of these techniques together, the total IP/UDP/RTP header overhead for an audio stream can drop to two bytes per packet 🎉 This only needs to be deployed on bottleneck links. High-speed links can carry the real-time streams without routers or switches spending CPU cycles on header compression 🌸

okay bestie, the main goal for a real-time encapsulation is to stop real-time packets from getting stuck waiting 😭 when they show up ready to go while a long data packet is still being sent. so the encapsulation has to be able to either abort or suspend the transfer of that long packet. there's also a second goal: keep the overhead low for packets from periodic flows. that strongly argues for being able to suspend a packet, meaning chop it into parts so real-time packets can slip in between them 🦋

4.1. Using existing IP fragmentation

okay so sending only part of a packet, so higher-priority traffic can cut in and then the rest gets sent later, is a kind of fragmentation 🧩 and fragmentation is already a thing at the IP layer. an IPv4 header already has fields that let a big IP datagram get split into small pieces 💅 a sender's "real-time PPP" implementation could just tell its IP stack to use a small MTU, so all the bigger datagrams get fragmented down to a size that meets the access delay goals 🎀 (this assumes the IP stack can priority-tag fragments, OR the PPP implementation can match the fragments up with the first one that carries the info used for prioritizing, OR only initial fragments can be high-priority). (also, a PPP implementation can negotiate down its peer's MTU, which makes the peer fragment to a small size. that's kind of a scrappy way of negotiating an access delay goal with the peer system, but only if that system supports priority queueing at the fragment level 🙈)

ngl the catch is that a full, 20 byte IP header is needed for each fragment (even more when IP options are used) 😩 that makes it hard to use really small fragments without too much overhead. (also, the size of non-final fragments must be a multiple of 8 bytes, which narrows your choices even more.) with path MTU discovery, IP level fragmentation makes TCP implementations use small MSSs, and that bumps the per-packet overhead up to 40 bytes per fragment 💀

and honestly? fragmentation at the IP level sticks around all the way down the path to the datagram receiver 🌍 so the transmission overheads and router load go up across the whole network. with its high overhead and the bad effect it has on the Internet, IP level fragmentation can only be a stop-gap 🥲 for when no other fragmentation protocol is available in the peer implementation.

so cell-oriented multiplexing like ATM, the stuff with regular points where cells from a different packet can get interpolated, is way too inefficient for low-bitrate links 🙅‍♀️ and the chips used to support the link layer in low-bitrate routers and host interfaces don't even support it.

so instead, the real-time encapsulation should use the capabilities of the chips that are already out there, as much as possible ✨ on synchronous lines, those chips support HDLC framing. on asynchronous lines, an asynchronous variant of HDLC is used, and it's usually implemented in software 💖 both variants of HDLC give you a delimiting mechanism to mark the end of a frame over the link. the obvious way to solve the segmentation problem is to combine that mechanism with an indication of whether the delimiter ends the current packet or suspends it 🎀

this indication could live in an octet appended to each frame information field, but ugh, seven out of eight bits of that octet would be wasted 😭 so instead, the bit could be carried at the start of the next frame, along with the multiplexing info (the PPP protocol identifier etc.) that's needed here anyway 🫶 since real-time flows are periodic in general, this multiplexing info could carry (part of) the compressed form of the header for the packet 🧚 if packets from the real-time flow are usually constant length (or have a defined maximum length that often gets used), the continuation of the suspended packet could be attached to it right away, without spending another frame delimiter. so the interpolation of the real-time packet would have zero overhead 🤯 and since packets from low-delay real-time flows generally won't need to be suspended again, the continuation bit could be reserved for the non-real-time packet stream 💜

one real-time encapsulation format with these (and other) functions is ITU-T H.223 [13], the multiplex used by the H.324 modem-based videophone standard [14] 📞 people checked whether compatibility with it could be achieved, since it'll be used in future videophone-enabled (H.324 capable) modems. but the multiplexing capabilities of H.223 are limited to 15 schedules (definitions of sequences of packet types that can be identified in a multiplex header), so for general Internet usage, a superset or a more general encapsulation would have been needed 🙃 also, a PPP-style negotiation protocol was needed, instead of using (and having to extend) ITU-T H.245 [15] for setting the parameters of the multiplex. in the PPP context, the interactions with the encapsulations for data compression and link layer encryption needed to be defined (including operation in the presence of padding). but the biggest blocker? H.223 needs synchronous HDLC chips that can be configured to send frames without an attached CRC, and that's not possible with all the chips in commercially available routers 😩 so full compatibility was unachievable.

instead of adopting H.223, the decision was to go for an approach that's built for compatibility with both existing hardware and existing software (especially PPP) implementations 💅 the next subsection groups these implementations by their capabilities.

4.3. Implementation models

this section introduces some terms for the kinds of implementations that are likely to show up 👀 it's important to keep these different implementation models in mind, because there's no single approach that's the best fit for all of them 🌈

4.3.1. Sender types

there are two fundamental approaches to real-time transmission on low-bitrate links:

Sender type 1 okay so this is the one where the PPP real-time framing implementation can control the transmission of each byte with some known, bounded delay (e.g., because of FIFOs) 🖥️ this is generally true of PC host implementations, which directly access serial interface chips byte by byte or by filling a very small FIFO. for type 1 senders, a suspend/resume style approach is typically used: when a long frame needs to be sent, the goal is to send it undivided. only if higher-priority packets show up during the transmission does the lower-priority long frame get suspended and later resumed ⏸️▶️ this gives the minimum variation in access delay for high-priority packets, and fragmentation overhead is only incurred when it's actually needed ✨

Sender type 2 with type 2 senders, the interface between the PPP real-time framing implementation and the transmission hardware isn't in terms of streams of bytes, it's in terms of frames 📦 for example, in the form of multiple (prioritized) send queues that are directly supported by hardware. this is often true of router systems for synchronous links, especially those that have to support a large number of low-bitrate links 🏢 since type 2 senders can't suspend a frame once it's been handed down for transmission, they'll typically use a queues-of-fragments approach. long packets are always split into units that are small enough to keep the access delay goals for higher-priority traffic intact 🔥 there's a trade-off here: a large fragment size means more variation in access delay, but a small fragment size means more overhead for every long packet ⚖️

4.3.2. Receiver types

even though the actual work of formulating transmission streams for real-time applications happens at the sender, the receiver's ability to use the info it gets right away depends on its characteristics 🎯

Receiver type 1 type 1 receivers have full control over the stream of bytes received within PPP frames. so bytes received are available immediately to the PPP real-time framing implementation (with some known, bounded delay, e.g. because of FIFOs etc.) 🙌

Receiver type 2 with type 2 receivers, the PPP real-time framing implementation only gets hold of a frame once it's been received completely. in other words, the final flag has been processed (typically by some HDLC chip that directly fills a memory buffer) 🧱

4.4. Conclusion

so because current implementations are so diverse in what they can do, there are now two specifications for real-time encapsulation 🎉 the first one is the multi-class extension to the PPP multi-link protocol. it provides the solution for the queues-of-fragments approach by extending the single-stream PPP multi-link protocol with multiple classes [8]. the other one is PPP in a real-time oriented HDLC-like framing. it builds on the first specification and extends it with a way to dynamically delimit multiple fragments within one HDLC frame [9], which gives the solution for the suspend/resume type approach 👑

5. Principles of Header Compression for Real-Time Flows 🎀

a good baseline for talking about header compression is the new IP header compression specification that was designed alongside IPv6 [2] 💖 the techniques in there can shrink the 28 bytes of IPv4/UDP header down to about 6 bytes (depending on how many concurrent streams there are) 🤏 add in the remaining 4 bytes of HDLC/PPP overhead and 12 bytes for RTP, and the total header overhead can be about halved. but it still ends up bigger than a G.723.1 ACELP frame 😭 also, here's the key difference: this environment assumes there's a full-duplex PPP link, so it can rely on negotiation, where IP header compression needs to keep sending the same info over and over 🔄 (the use of the architecture in this document with link layer multicasting hasn't been examined yet.)

RTP header compression needed extra design work on top of that. applying the concepts of IP header compression to the (at least) 12 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit) would qualify as RANDOM 🎲 DELTA encoding can't generally be used without more info, since the lower layer header doesn't unambiguously identify the semantics, and there's no TCP checksum to rely on to detect incorrect decompression 🙈 only a more semantics-oriented approach can give better compression. (it's just like how RFC 1144 gets really good compression of TCP headers by using semantic knowledge of TCP and its checksumming method 🧠)

for RTP packets, differential encoding of the sequence number and timestamps is an efficient approach for certain payload data formats 🌸 for example, speech flows generally have sequence numbers and timestamp fields that go up by 1 and by the frame size in timestamp units, respectively. the CRTP (compressed RTP) specification takes advantage of this relationship by only encoding these fields when the second order difference is non-zero [7] ✨

6. Announcement Protocols Used by Applications 💌

okay so bestie, remember how the compressor works best when it can tell which streams are real-time and what format the payload is in? 🧠 That's the whole vibe of this section ✨

If the systems involved are routers, this consent has to be installed as router state. If they're hosts, their networking kernels need to know about it. 🖥️ Real-time sources are already telling their kernels and the routers about their flows, using TSpecs in RSVP PATH messages [4]. 💅 These messages use the router alert option, so every router on the path sees them, and path state for the packet stream usually gets installed at each router that runs RSVP 🦋

Apps that want good performance over low-bitrate links can add extra RSVP objects to their PATH messages. Routers that don't care about them just ignore them 🫶 The class number is 11bbbbbb, as defined in [4], section 3.10 🌸

Here's the fun part 🤩 The path state is available in routers even with no reservation, so they can compress best-effort traffic in an informed way. 💖 Not gonna lie though, it's not totally clear how path state could be torn down quickly once a source stops transmitting 😭

7. Elements of Hop-By-Hop Negotiation Protocols 🔁

okay so the IP header compression spec tries to handle simplex and multicast links by only sending info about the compressed streams in the forward direction. 🧭 For example, a full IP/UDP header has to go out after F_MAX_TIME (currently 3 seconds). 🕒 That's a tiny overhead, like one full header every 150 G.723.1 packets, but you have to plan your real-time transmissions around it 🗓️

Simplex and multicast links aren't really the norm in low-bitrate land, though multicast might matter more with wireless systems 📡 So in this document, we assume full-duplex capability 💜

As compression improves, a negotiation between the two peers on the link gives you the most flexibility, both in implementation complexity and for future extensions 🌈 The peers can decide which real-time packet streams get compressed, which header fields don't get sent at all, which multiplexing info to use on the link, and how the remaining fields get encoded 🎀 PPP is a well-tried suite of negotiation protocols, and it's already on most low-bitrate links, so it's the obvious choice 👑 PPP also has to help negotiate real-time encapsulations between systems that aren't set up to do it automatically 🫶 That's why the PPP options negotiable during link setup (LCP) are in [8], [9], and [10] ✨

8. Security Considerations 🔐

Okay, serious moment, bestie 🚨 Header compression protocols that rely on assumptions about application protocols need to be carefully analyzed to see whether someone could subvert other applications, either by doing it on purpose or by accidentally turning those applications on. 💀

It's generally not possible to do significant hop-by-hop header compression on encrypted streams 🙈 With certain security policies, you might run an encrypted tunnel to a network access server that does header compression on the decapsulated packets, then sends them over an encrypted link encapsulation 🔒 See also the short mention of interactions between real-time encapsulation and encryption in section 4 above 🧚 If your security requirements allow it, a special RTP payload data format that encrypts only the data is the preferred option 💅

9. References 📚

  • [1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The Internet Multimedia Conferencing Architecture", Work in Progress.
  • [2] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
  • [3] Scott Petrack, Ed Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression", contribution to the mailing list rem-conf@es.net, February 1996.
  • [4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [5] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
  • [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [7] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
  • [8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
  • [9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
  • [10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
  • [11] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
  • [12] Shenker, S., Partridge, C. and R. Guerin. "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
  • [13] ITU-T Recommendation H.223, "Multiplexing protocol for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
  • [14] ITU-T Recommendation H.324, "Terminal for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
  • [15] ITU-T Recommendation H.245, "Control protocol for multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.

10. Author's Address 📮

Carsten Bormann
Universitaet Bremen FB3 TZI
Postfach 330440
D-28334 Bremen, GERMANY

Phone: +49.421.218-7024
Fax:   +49.421.218-7000
EMail: cabo@tzi.org

Acknowledgements 🫶

Much of the early discussion that led to this document happened with Scott Petrack and Cary Fitzgerald 💬 Steve Casner, Mikael Degermark, Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup on low bitrate links (ISSLOW), and especially the ISSLL WG co-chairs Eric Crawley and John Wroclawski all helped make this architecture a reality 🙌✨

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🌸

📦 where this page comes from