.. index:: QoS: Quality of Service
.. index:: RSVP: Resource Reservation Protocol
Chapter |Stream|: Real-Time Streaming
Audio and video have been streamed across the Internet for several decades. In the early days there were concerns that specialized queuing and resource reservations might be required to support these latency-sensitive applications, but dramatically increasing bandwidths of access links and the Internet's core has led to a state where video now makes up a majority of the bytes transmitted over an Internet that remains best-effort.
Streaming implies a rather broad class of applications, each with slightly different requirements. For example, early success stories had very loose latency requirements. If you wanted to watch a movie or listen to a song, it was acceptable to wait a few seconds before the stream started. This meant that video streaming services like Netflix and YouTube, as well as music streaming services like Pandora and Spotify, could use substantial buffering at the client to hide any delays in packet delivery. This led to the development of adaptive mechanisms, with the DASH protocol described in Chapter |Apps| being a prime example.
But DASH doesn't work for every scenario. For use cases with tighter latency constraints, such as video conferencing and live events, we need additional tools to manage the delivery of latency-sensitive media. This is why we include the "real-time" qualifier, although even then, there is a spectrum of delay tolerances: a one-second delay when trying to reply to a speaker in a video conference call is much more disruptive than a few seconds of delay at the start of a live sporting event.
This chapter examines the additional challenges in delivering real-time media and some of the technologies and protocols that have been developed to address them. Of particular note, the fact that we are delivering media (i.e., video and audio), and not some other type of data, plays a role in how we make sure delivery is timely. How we represent this data, and how much we compress it so it consumes fewer resources, is necessarily part of the story.
Further Reading
B Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: An Overview. RFC 1633, June 1994.
B Braden (Ed.). Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Internet Architecture: An Overview. RFC 2205, September 1997.
QoS Guarantees
The idea of supporting Quality-of-Service (QoS) guarantees has come up multiple times throughout this book, but with the exception of QoS support being a proclaimed feature of the Mobile Cellular Network in Section 5.4, we are yet to describe how one goes about reserving network bandwidth. Now that we're finally focused on real-time streaming, you would think the answer is imminent, but as the introduction to this chapter indicates, that is not the case.
This is not for a lack of trying. Introducing reservations and QoS guarantees into the Internet was a significant focus of both academic research and protocol standardization throughout the 1990s, resulting in the Integrated Services (Int-Serv) architecture, so called because it supported both best-effort traffic and reservations (see RFC 1633). As an architecture, Int-Serv included several moving parts. Fair Queuing packet schedulers (see Section 8.2) was one necessary component. A way to specify the reservation you wanted—codified in RSVP, the Resource ReSerVation Protocol—was another component.
The chief reason RSVP and Int-Serv never took off is because the applications people cared about worked adequately without them. Hard QoS guarantees turned out to be unnecessary for many streaming applications thanks to innovations like DASH, and interactive applications like video conferencing work sufficiently well thanks to increases in network bandwidth. So while some QoS mechanisms such as fair queuing live on, hard QoS guarantees have not been widely deployed.