107,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
The definitive guide to developing robust content delivery networks
This book examines the real-world engineering challenges of developing robust content delivery networks (CDNs) and provides the tools required to overcome those challenges and to ensure high-quality content delivery that fully satisfies operators’ and consumers' commercial objectives. It is informed by the author’s two decades of experience building and delivering large, mission-critical live video, webcasts, and radio streaming, online and over private IP networks.
Following an overview of the field, the book cuts to the chase with in-depth discussions—laced with good-natured humor—of a wide range of design considerations for different network topologies. It begins with a description of the author's own requirement filtration processes. From there it moves on to initial sketches, through considerations of stakeholder roles and responsibilities, to the complex challenges of managing change in established teams. Agile versus waterfall considerations within large blue chip companies, security, commercial models, and value chain alignment are explored in detail. Featured throughout the book are numerous "what if" scenarios that help provide a clear picture of the wide spectrum of practical contexts for which readers may be tasked with building and implementing a CDN. In addition, the book:
- Discusses delivery of live, catch-up, scheduled on-demand, TVOD and SVOD
- Offers insights into the decisions that can to be made when architecting a content distribution system over IP-based networks
- Covers CDN topologies, including Edge-Caching, Streaming-Splitting, Pure-Play, Operator, Satellite, and Hybrid
- Examines computer hosting and orchestration for dedicated appliances and virtualization
- Includes real-world cases covering everything from IETF, regulatory considerations, and policy formation, to coding, hardware vendors, and network operators
- Considers the future of CDN technologies and the market forces driving its evolution
Written by a back-room engineer for back-room engineers, Content Delivery Networks gets readers up to speed on the real-world challenges they can face as well as tried-and-true strategies for addressing those challenges in order to ensure the delivery of the high-quality content delivery networks that clients demand and users expect.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 506
Veröffentlichungsjahr: 2017
Ähnliche
Table of Contents
Cover
Title Page
Frontispiece
Topics Include
About the Book
Synposis
Unique Perspective
Market Need
Audience
1 Welcome
1.1 A Few Words of Introduction
1.2 The “Why” of this Book
1.3 Relevant Milestones of the Personal Voyage
2 Context and Orientation
2.1 History of Streaming
2.2 Industry Evolution
2.3 Consumer Adoption
2.4 Encode > Serve > Play
2.5 What is a CDN
: A Simple Model
2.6 Cloud Inside – New Generation
2.7 The Three Generations of CDN
2.8 Software Definition
2.9 “Service Velocity” and the Operator
3 Workflows
3.1 Live Event Focus
3.2 Backhaul/Contribution and Acquisition
3.3 Cloud Saas
4 Publishing
4.1 Publishers, OVPs, CDNs, and MCNs
4.2 Small Objects, Large Objects, or Continuous Streams
4.3 Desktop and Device Delivery Applications
4.4 Request Routing (The Dark Art of the CDN
)
4.5 Logging Analytics and the Devil in the Detail
5 Service Velocity
6 Charging for IP
‐Delivered Content
6.1 Lessons from the Music Industry
6.2 Success Cases
6.3 Failure Cases
6.4 General Commentary on Commercial Models
7 Competition and the Regulatory Environment
7.1 ISOC, ITU, and WSIS
7.2 Policy – Net Neutrality
7.3 Value Chain Alignment with QoS and SLA
Propositions
7.4 Layer‐2 Workaround?
8 Cultural Change
8.1 Traditional Broadcasters
8.2 The Millenial Subscriber
8.3 ISP
and Content Providers
8.4 Telco
and Telecoms
8.5 Content Providers
9 Preparing for Change in Your Design
9.1 Preface and Philosophy
9.2 Models, Diagrams, and Schematics
9.3 How to do a Good Diagram?
9.4 Scenario Planning
9.5 Risk, Responsibility, and Reassurance
9.6 Optimization and Upsell
9.7 Value Creation/Agility
9.8 Expectation Management
10 Multicast – the Sleeping Giant
10.1 Multicast Recap
10.2 What Happens Now?
10.3 To Singularity and Beyond
11 Deep‐Dives (Case Studies)
11.1 Hitting the TV Screen – IPTV/Hybrid TV and OTT
11.2 Creating Nasdaq’s Cloud‐Based Virtual Workflow
12 Wrap Up
Index
End User License Agreement
List of Tables
Chapter 06
Table 6.1 Drag between music and video services emergence in major rights enabled platforms.
List of Illustrations
Chapter 02
Figure 2.1 Classic live streaming workflow.
Figure 2.2 TCP
/IP
and OSI network layer models compared.
Figure 2.3 Basic building blocks of a content delivery network.
Figure 2.4 Evolution of compute IT with broadcast IT compared. https://commons.wikimedia.org/wiki/File:Human‐evolution‐man.png
Chapter 03
Figure 3.1 My webcast rig set up for a drone race webcast.
Figure 3.2 Streamstar.com's webcast case‐All in One: Great for Sports.
Figure 3.3 Virtual workflow example ‐ Various source videos being acquired, synchronized, and treated for delivery.
Figure 3.4 NASDAQ
web‐based EDL
editor and “cutting interface”.
Figure 3.5 Storage model.
Chapter 06
Figure 6.1 Basic reference model for premium and commercial content delivery.
Figure 6.2 Cable TV’s content (shaded arrow) and revenue (solid arrow) flows.
Figure 6.3 IPTV model’s content and revenue flows.
Figure 6.4 OTT Pureplay (iTunes).
Figure 6.5 OTT and operator CDN models.
Figure 6.6 FOG distribution.
Chapter 09
Figure 9.1 CDN design template I have used on occasion.
Chapter 11
Figure 11.1 Schematic of premium content delivery platforms.
Figure 11.2 Schematic of id3as
' Arqiva workflow for hybrid TV.
Figure 11.3 Operating at scale.
Figure 11.4 Scaling down in quiet times (where public cloud
really
adds value).
Guide
Cover
Table of Contents
Begin Reading
Pages
iii
iv
v
xiii
xiv
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
229
230
231
232
Content Delivery Networks
Fundamentals, Design, and Evolution
By Dom Robinson
Co‐Founder, Director and Creative Fire‐Starter id3as‐company ltd.
This edition first published 2017© 2017 John Wiley & Sons, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Dom Robinson to be identified as the author(s) of this work has been asserted in accordance with law.
Registered OfficesJohn Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
Editorial Office111 River Street, Hoboken, NJ 07030, USA
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of WarrantyThe publisher and the authors make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties; including without limitation any implied warranties of fitness for a particular purpose. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for every situation. In view of on‐going research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. The fact that an organization or website is referred to in this work as a citation and/or potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this works was written and when it is read. No warranty may be created or extended by any promotional statements for this work. Neither the publisher nor the author shall be liable for any damages arising here from.
Library of Congress Cataloguing‐in‐Publication Data
Names: Robinson, Dom, author.Title: Content delivery networks : fundamentals, design, and evolution / Dom Robinson.Description: Hoboken, NJ : John Wiley & Sons, 2017. | Includes bibliographical references and index. | Identifiers: LCCN 2017009407 (print) | LCCN 2017014475 (ebook) | ISBN 9781119249887 (pdf) | ISBN 9781119249894 (epub) | ISBN 9781119249870 (cloth)Subjects: LCSH: Computer networks. | Internetworking (Telecommunication)Classification: LCC TK5105.5 (ebook) | LCC TK5105.5 .R6255 2017 (print) | DDC 004.6–dc23LC record available at https://lccn.loc.gov/2017009407
Cover Design: WileyCover Image: © MickeyCZ/Gettyimages
So family had my credit last time: this time it’s professional!
Thanks and credits:
To those who inspire and allow me the honor to work with them: Adrian Roe and Steve Strong.
To those who have travelled much of the journey with me: Steve Miller‐Jones, Tim Thompson, Tim Gebbett, Dane Streeter, Dom Pates, and Michael O'Rourke
To those who set me on key paths in life but themselves are no longer with us: Chris Daniels and Brian Smith (my Godfather) ‐ RIP both.
To those who gave me a place in the industry: Eric Schumacher‐Rasmussen, Dan Rayburn, Tim Siglin, Jan Ozer, Sjoerd Vogt, Jose Castillo and Joel Unickow and the Streamingmedia.com extended family.
To some of our clients for allowing us to address some very big complicated technical challenges for them: Andreas Heidoetting, Simon Ball, Osman Sen Chadun and Jon Holden‐Dye, Ken Takagi and Mark Myslinski
To these guys who have shepherded my meanderings in various ways over the years: Steve Hatch, Richard Trimble, Tony Ballardie, John Riordan, Eric Van Der Kleij, Harvi Bains, Nick Lansman, Donald Miller‐Jones, Daniel Montuschi, Steve Woolcock, Elle Todd, and John Enser.
To these industry figures who have made key contributions to the sector over the years: Ben Waggoner, Greg Shepherd, Jon Crowcroft, Steve Deering, Kon Wilms, Mark East, Richard Lindsay‐Davis, Lee Atkinson and Stef van der Ziel.
To Mukaddim Pathan ‐ whose nudge ultimately made this book happen (and of course to the entire Wiley team for just being absolutely great!)
To the cast of thousands who have been part of this story (which includes all my readers!)
..and finally to Vint Cerf for both, inventing the Internet, and for taking the time to help me with personal projects on a number of occasions over the years.
Frontispiece
Provides the reader with comprehensive insight into the structural decisions that can to be made when architecting a content distribution system that uses IP‐based networks
The narrative of this book draws on a wealth of real‐world and practical experience that the author has accrued through two decades of coalface experience architecting and delivering large, mission critical live video, webcasts, and radio streaming online, over both the Internet and private IP networks.
From this loosely defined “tradeperson’s” standpoint, rather than the often explored tightly academic or business‐sales point of view, this book takes a broad, humored, and at times pencil‐sucking look at the art of building content delivery workflows.
Topics Include
Delivery of live, catch‐up, scheduled, on‐demand, TVOD and SVOD
CDN
topologies including edge‐caching, stream‐splitting, Pureplay, Operator, Satellite, and Hybrid
Computation hosting and orchestration in models such as dedicated appliances and virtualization
Format considerations and achieving adaptive, format resilient operator networks and backbone infrastructure
General comments on market forces over cycles and eras of evolution of these technologies
This book aims to talk in backroom engineers’ English about the challenges faced in the real world, and to stimulate the reader to think extremely broadly about the options and problem spaces, and how to ensure that delivery is always, at the least, “good enough” for the operator’s and consumers’ commercial objectives.
As we enter what the author calls the “third generation of CDN,” architects who are new to the area can use this text to draw on the author’s own practical experience over the first two generations.
The book will also be an interesting read for those who have themselves built large infrastructure, providing a moment to reflect on other ways around problems. It will be a useful quick‐start tool for those who are trying to understand the complex challenges of large‐scale content delivery.
Not one for hiding opinion, the author also throws a number of challenging “what if” scenarios into the discussion to highlight some possible long‐term design architectures that today may be a little fantastical but tomorrow may evolve based on the clear demand that such architectures could reach, should the commercial model evolve in line.
This discussion zooms in on the recent evolution of software‐defined networking and the changes that this schism will bring as capabilities for many players in the network stack become unlimited, and infrastructure allocated to a particular task can be repurposed at the flick of a bit.
About the Book
While content delivery network architecture texts typically focus on current and forthcoming best practice, few take a deep retrospective view and embrace the cycles in the sector. CDNs also typically comprise 20% of their engineering work on video despite its being 80% of their traffic overhead. The author has focused on live video and audio transmission because the problems span so many layers of the network stack. There are, of course, many application‐specific challenges, with particularly gaming and conferencing and to a lesser extent dynamic website acceleration and small object or large file delivery. Some of these do cause network layer issues, but generally the traffic is not impacting to a network operator – it is impacting to the Software as a Service provider or the application user. There are many complex issues that can be explored, and many are touched on in this book; however, for the main part, the core focus of this book is on live (and to a lesser extent on‐demand) video delivery – TV, radio, video, and live audio over IP networks.
Synposis
Starting in 1973, streaming audio and subsequently video have been baked into the IP protocols. With the web making the quick discovery of content near ubiquitous, the demand for not only huge volumes of text but also for web apps, and significantly for high‐quality video, has exploded.
The likes of the BBC, YouTube, Netflix, and countless other online publishers, have lit up the information highway with literally inconceivable amounts of information conveyed in huge quantities of bytes. Those data have to be delivered to destinations by someone, and the dark art these people practice is called content delivery networking.
Over the past 20 years we have seen several trends emerge, and these exist at both the micro level, where we are encoding pixels of video into a streaming format, and the macro level, where millions of users are able to consume content from hundreds of thousands of servers, reliably and with a great deal of resilience.
Trends in GPUs are changing how encoding resources are deployed. Evolutions in distributed computing are bringing about a macro change in the architecture of these types of services.
This evolution promises greater service levels, more flexibility to meet the customers’ exact requirements, and new security challenges as infrastructure becomes increasingly shared in multi‐tenant public cloud models.
Telecoms network operators are now seeing IP services as a core part of their businesses, and their understanding of their own internal content delivery architecture requirements is a key driver for their rapid adoption of a software operating model. Soon operators will, at‐will, be able to deliver the CDN as an SaaS model on their own infrastructure, and additionally offer other SaaS models in the same infrastructure, providing risk mitigation as they try to underpin services for an ever more divergent target market.
Unique Perspective
The book describes the historical context of the streaming media and content delivery market from the unique perspective of the author who is a true native to the sector. It draws heavily on personal experience and hands‐on examples from 20 years of live webcast production through to public company infrastructure architecture. There are few in the industry who can boast such a rich and varied practical experience across the sector, and this unique insight is fundamental to the narrative.
Aside from the anecdotal and practical commentary, the book takes the implementer through a wide range of design considerations for different network topologies, starting with the author’s own requirement filtration processes through to initial sketches, through to roles and responsibilities, and to the complexity of managing change in established teams, agile as opposed to waterfall considerations, in the context of large blue chips, security and commercial models, and value chain alignment.
This widely embracing viewpoint, supported by examples ranging from IETF discussions, regulatory considerations, policy formation, coders, hardware vendors network operators, and more, is rarely available from one author. The author draws on conversations with peers in the industry, and in the course of writing, he gathers their comments and input too.
While many books on these topic slice and dice these seemingly unrelated schools of thinking into their constituent parts of commercial, technical, operational (etc.), this book can help service designers embrace the worldview of influences that need to be considered when architecting a robust and high‐quality content delivery service for today’s online consumers and business users.
Market Need
Today’s market is just about to fully enter what the author call its third generation.
The first – which spanned until around 2005 – was the appliance era dedicated hardware and software
The second – which spanned from 2005 until around 2014 – was the virtual machine
era when software could be moved machine to machine
The third – which started in 2014 – is the emerging container era characterized by software that is highly componentized and is deployed to the resource best suited to the task as the capability is required
As the SDN/NFV models stimulate understanding across the Telco sector, there is about to be a tech refresh like no other: all the hardware that has traditionally been dedicated to task is going to become software driven in entirety. The Telco operators who were about to deploy Gen2 CDNs are holding back to see how the underlying infrastructure is going to evolve, to then deploy their CDN as a gen3 model using the network’s built in resources to deploy the CDN as an SaaS and when a client needs it.
That cycle is going to take a further three to five years.
As it happens, service architects are going to be planning more against customer requirement than against “productizability,” and this requires a breadth of thinking at the COO / CTO level from every engineer and commercial participant too.
Designing a CDN for tomorrow is a broad challenge – and this book strives to get the reader thinking like a content delivery network designer.
Audience
Target: Streaming media readership, IP / cable/ satellite / Telco / mobile and TV operators, content producers, ISPs, policy and regulatory (net neutrality and content rights), and all stakeholders in networks that may deliver large quantities of video or audio (and data / applications too).
1Welcome
1.1 A Few Words of Introduction
I am literally buzzing from the past few days. When the team at Wiley got me involved in the previous title I worked on with them (Advanced Content Delivery, Streaming, and Cloud Services, 2014), I was feeling some way out of my comfort zone. I normally write extensive commentary around the streaming media and content delivery network sector for a variety of trade presses, and very much with a hands‐on tradeperson’s view. This was the first time I was to contribute some writing to the community among recognized academics: a notably different focus to the engineers in enterprises who read the trade press that has been my writing home for two decades.
While I am no academic, I was bought up at the knees of academics. My godfather was head of Maths and Physics at Sussex University for many years, and he was my favorite babysitter! The opportunity to build the first Mac network at the university in the mid‐1980s (unboxing the gift from Apple was a way to occupy a 9‐year‐old during a holiday), through to, at 17 in 1991, having a log‐in (including an email and remote access to the William Herschel Telescope) to Starlink, which was one of the early global IP networks, my teenage years were spent as a geek.
However, I left two different degree courses (Astrophysics and Artificial Intelligence) to pursue commercial ventures. I was typically always naturally more entrepreneurial and impatient more than patient and academic, so I wanted to get to the place where the interesting changes could be made by applying the right technology at the right time. And I believe I have been lucky enough to be in a sufficient number of good places at the right time, and – importantly – with the right people, to have achieved some interesting things, both in delivery of that new technology but, more importantly, achieving the end goal that the technology was underpinning.
The academic world has, to an extent, caught up with the front line of practical implementations of the types of solutions, architectures, and services that I am familiar with, and the previous title was exciting, in part for its success and recognition but also, for me, to write for a wider audience than those who read trade magazines!
My style was welcomed by Wiley, and the team felt that my perspective added a lot of context. Immediately after publication there was a hint that, should I have some ideas that could commit to paper, there may be interest in another publication.
Over the summer this past year I came to the conclusion that there may be some use not in trying to define an empirical best practice, but to impart a more general range of insights and to write more gutturally about the overall experience and insights I have gained from the front lines in evolving many CDN architectures, and using many others.
While my idea was being discussed with the Wiley team during these last weeks, I chaired the Content Delivery World 2015 conference (a regular “gig” for me). A speaker couldn’t show, so I was asked to fill a 30 minute slot at short notice. With discussion about this book fresh in my head, I filled the 30 minute slot by talking from the top of my head about many of the topics in these pages. The room filled up to about 300 people – many CTOs and chief architects of large global blue chip Telcos, mobile networks, and broadcasters – and afterward I had a rain of business cards inviting me in to follow up. For me, this was some validation of the relevance of a sector‐tradesperson’s experience to the community, and reinforced my feelings that this book would have some value to readers.
The Wiley team contacted me literally as I returned from that conference and said “let’s do the book,” sent me the contract, and I returned it within a few minutes.
Well, you only live once. So if this isn’t the right time to record some of my insights and experience, I have no idea when it will be!
I hope you find the book fun, enlightening, at times challenging, and, if nothing else, stimulating to your thought processes as you develop your content delivery strategy.
1.2 The “Why” of this Book
Today there is a wealth of excellent documentation available to the CDN architect that defines best practices. Be that for the core technical services architectures, compute paradigms, CoDec configurations, hardware setups or any other aspect, there is generally speaking both a “For Dummies” guide and a “Master Engineer” pool of literature.
There is, however, a complete lack of middle ground material. Most people who engage with streaming media, video delivery, and scaling large service platforms tend to pass through the space, and their interest is part of a specific project or role they have taken for a while in a larger corporation. They require deep understanding to address the problem space they are in, but once they acquire or develop those insights, they may move on to a new role with different responsibilities or even a completely different focus. This means that as each generation passes through some of the niche, their specific learning is then diffused away. To use an analogy, the “aural” tradition of the “bush hunter” is lost to the anthropologist’s archive, and the practical tips and tricks that are only learned on the job, or spoken about at 2 am during the drive home from an event, fail to get passed on in any formal text. I aim to capture some of this and share it with you.
There is an intentional levity in my writing. I have been writing about deeply technical subjects for years, and in trade press if you don’t instantly engage the reader, the reader will turn the page. My style is to develop a sense of backroom chat, and so from that perspective I hope you will allow me some creative scope and license – particularly on the analogies, which quite often are not supposed to microscopically represent the accurate details of a story but aim to help contextualize the next part of the voyage.
Do feel free to jump around: you will for sure have your own focus and reasons to pick up the book. While I try to take the reader on a voyage from start to finish, some of you will want to go head deep into my opinions on a certain scope. Do it! I am not a linear person, and I myself tend to read books in many directions! Don’t be hesitant! Make it work for you.
… And do email me [email protected] if you want to throw virtual eggs or discuss any of the finer points!
1.3 Relevant Milestones of the Personal Voyage
So at the risk of writing what could become a CV – and no, I am not looking for a job (as you will see I have rather an awesome job) – let me give you a little potted history of some of my key milestones that will form the spine of the coming journey.
As mentioned, I was brought up on a university campus and was essentially computer conversant by the time I was squeezing pimples. In my generation that was unusual: the nerds were the ones who would get bullied by the “jocks” at school, unless they were me and large enough to give as good as I got. So I was largely left alone to geek‐out, building radio telescopes and working out how to do wireless telemetry between early personal computers (BBC Micro/ ZX81 being my early platforms of choice!). You got the picture. I am assuming I am among company.
However, as university loomed, and girls got more interesting, I became more interested in music. In fact I got more interested in music and production than in astrophysics and computers. While computers were becoming more dominant, I was drawn extensively to event production/PAs/sound engineering/video production/VJing, and so on. After a few months working at Raves, and a longer spell putting on drum and bass and “chill out” club nights I left university to one side.
Two key things happened at this time.
The first, I was encouraged by a friend, Chris Daniels, to focus not on club promotion but on the promotion of micro‐billing systems.
In 1994 and 1995 the UK Premium Rate Information Services and Paging Services were all the rage, and I essentially had an idea to give pagers to all the students at a very large local university for free. The plan was to allow the university to message the students with email headers if they had something in their university email (saving the poor students traveling in for email to the university network, as 90% did at the time in the pre‐laptop era), and all the while charging a premium tariff to friends and family for messages sent to the students pager. The idea was well received by a variety of key people and with the support of not just the vice chancellor but also the government committee that had just published a report about how critical it was to “wire up” the students. So I – and a friend, Steve Miller‐Jones, who will feature again later in the book – managed to raise £250,000 for the pager CAPEX from a wealthy venture capitalist, who himself ran a large cable network operation across Europe called UPC.
The second major thing that happened was that while the club promotion was still ongoing, I was invited to bring our Brighton club night to the Ministry of Sound in London for that year’s London Institute Student Union’s freshers’ night festivities.
And so it was in 1996 that we wired a Real Audio encoder stream from the decks at the Ministry of Sound to an online‐hosted server and then relayed it to our “normal” club in Brighton in “stereo” over a phone line. Yes, it was a 48 kbps audio feed. Yes, it was impressive that we managed to make it work at all, and yes, it was life changing.
Through that single event I saw quite how much the Internet was about to change the “music industry.” The disintermediation of the record company’s Vinyl monopoly was only a matter of time.
In what was so nearly my sharpest move, I missed registering the domain mp3.com by two weeks but managed to grab m3u.com – which was the streaming meta‐file that was universally associated with mp3 and enabled instant playback through what is called progressive download.
Meanwhile my pager project had hit some issues in its test. We had a sample of 30 pagers and a class of computer science students. They were to help us measure if the revenue from their friends and family messages would help show significant enough return for us to commit the £250k investment and launch the business across the university. The test was scheduled to run for one month.
We failed to allow for the fact that the “meme” of a student’s pager number needed to propagate to many places and have enough opportunity to be used before a sufficient volume of friends and family would call back and generate the level of income we required.
In the 30 days of our 30‐person trial, of course, that did not happen. There was only one thing to do – to take that £250k cheque back to its owner intact. That I did.
At once that decision put me out of pocket, but in a place of deep regard with the venture capitalist. The VC then in turn asked what else I was working on, and I explained about mp3.com and m3u.com.
He instantly invested in “me,” providing me expenses for R&D, travel and a living salary. Within a few months I was in the full throes of the late 1990s dot‐com boom. I was in a plane every other day traveling Europe, East Coast US, and West Coast, meeting some of the folks from companies that then became internationally known. We helped get the download mp3.com functioning with its “listen now” feature, replacing the.mp3s with.m3us that pointed to the mp3s in their charts – simple but an instant effect. I recall being seated in their facilities as the my.mp3.com furore hit, and as their valuation went into the billions, and at the same time became the pre‐Napster hot potato.
I knew Napster and Scour as they kicked off – having met them at early Streaming Media Conferences (one at which Bill Gates gave the keynote), although was in practice closer to mp3.com myself. I also engaged with Real Networks and Microsoft Netshow Theatre as it became Windows Media.
It was an awesome, electric time.
However, in 2000 the bubble was already showing severe signs of deflation, and it was time to come back to focus on the UK and establish my own base and business, rather than continue to work in an Incubator that itself was struggling to turn out some big wins in a turning tide.
So I set up as a streaming media and IPTV consultant and webcaster, and went about getting my first major client. Thanks to another crazy, but close friend – known as Timmy or “TT” – who is one of the more fearless sales guys I have ever met, we essentially walked up to the UK Prime Minister’s office and engaged the webmaster there in a discussion about improving the PMO’s communications using video (and a demo of streaming live drum and bass to an HP Jornada over a 9.6 band infrared modem on a Nokia phone!).
From there I was put forward to help a small company, Westminster Digital, with their deployments of video workflows for both the PMO and for Parliament; in particular, I helped develop the workflow that brought the weekly Prime Minister’s questions to the web.
With that on my CV, establishing engagements with interesting broadcasters and Internet companies proved much easier, and my freelance consulting and webcasting managed to keep me fed, while the stability of regular article writing for the ISPWorld and Streaming Media helped with both marketing and cash flow. I managed to hook into most of the London‐based former DVD authoring – now webcasting – companies as their ad hoc live encoding engineer. This allowed me to get involved with literally hundreds, if not thousands, of live events – ranging from simple audio conferences through to the Glastonbury Festival, FatBoySlim, and many others.
I have worked with three heads of state, royalty on two occasions, many pop stars and CEOs, and some downright dirty and dodgy people too, both public sector and private! It gave me pragmatism about the real “honesty” of media, although my impartial addiction to the technical was what kept me fed. I recall producing the conference league soccer for BT and Talkpoint over a couple of years: what kept me directing the production was an absolute lack of interest in the sport. I could always be relied on to be watching the kit over and above the game, although did on occasion confuse the audiences by putting up scores on the displays for the wrong teams ….
However, I grew increasingly frustrated by the lack of UK‐based CDNs and the limitations that working with US CDNs always carried. They typically sought minimum monthly commitments for 6 to 18 months even if you only wanted to do a single event. They had maximum throughput on long contribution feeds into US servers maxing me at 400 Kbps with no UK entry points, etc.
I was also increasingly fascinated with IP multicast – an amazing technology that I saw has the potency to disintermediate broadcast networks in the same way that mp3 disintermediated the monopoly of the record industry.
I could use it on my own LANs and my clients’ privately run Enterprise networks, but I couldn’t multicast on the Internet. It took me a significant amount of deep reading to understand why. I subsequently tracked down those few academics – mostly huddled around Professor Jon Crowcroft, then of UCL and now at Cambridge – who understood the problem, and had some solutions technically, but as I was to discover, the academics had not really focused on the real‐world business case that would drive the technological adoption …
… and that was where I realized I had something, perhaps entrepreneurial, to add to that community.
I rounded on Dr. Tony Ballardie. He had, as part of his academic career, pioneered key multicast protocols CBT, PIM‐SM/SSM, and MBGP, and later, after a project we worked on together, he introduced AMT at a BOF in the IETF …. And if you didn’t follow that, then be ready to Google some of those terms when you see them appear again later on!
He and I met when I arrived at a tennis match he was competing in, in 2001, and I convinced him to sit down for a coffee, whereupon I explained my vision for how multicast eventually would have to be scaled up to deliver content to large audiences, as the evolution of TV online would demand it.
Remember, this was at a time when the FT had published a report for the recording industry saying that the Internet would never be capable of delivering multicast in a consumer friendly way, and they should focus on using it for DVD e‐Commerce sales ….
It was then I realized that while there were many things multicast was developed for, TV being one of them, which the Multicast pioneers had foreseen for their technology, it was also clear that none of them came from or knew the broadcast and production world …
… which was generally where a “webcaster” hung out. I could see the real‐world commercial arrival of this disruptive technology. Tony knew how it worked.
With the huge dot‐com crashes happening around us, it was a complicated time. However, in the midst of the Enron crisis (also accompanied by the Global‐Crossing collapse that directly affected Global‐MIX) a sudden beam of business broke through and gave the online video sector validity, and that was something called “Fair Disclosure” – which, in short, means that public companies suddenly had to webcast their annual and quarterly analyst briefings to their shareholders. I will deep dive more on this later, particularly in the case studies around NASDAQ OMX.
So Tony and went to ground together for some time, and in early 2003 we took an architecture to Keith Mitchell, one of the founders of the London Internet eXchange, who gave us some nominal resources to build the world’s first Multicast Interconnect eXchange, Global‐MIX.
Come 2004 we were in service acquiring live video feeds from dozens of TV channels, and using Windows Media services’ multicast capabilities, we were forwarding multicast live streams onto the MIX where anyone at the exchange could take on direct delivery of the IP multicasts.
Naturally, because we were trying to seed something, the adoption was patchy, and it took us a further year or two, and a large commercial content delivery project or two, to really understand that the insurance‐stream unicast, which was essentially a low‐SLA backup that most of our clients actually used – since their ISP was not MIX / MBGP peered – was increasingly our best weapon.
As an ISP, we would point out to our peers where large quantities of the same traffic were impacting their general peering, and we would work with them to establish a single multicast peering, and sometimes reduce many Gbps of traffic to a few Mbps. We gauged that at peak we managed to reach 15% of our audience with a multicast, and for a decade this was the largest such peak with public ISP delivery. The biggest problem was the churn of the ISPs we peered. Even when we managed to get multicast peering, and flow right through to the ISP subscribers with a particular ISP, we were such an anomaly to normal ISP operations that we would often find that the multicast would be switched off overnight across a large multicast peer as part of some other service deployment, or network policy, would seep in and prevent the flow.
The amount of saving it was making was relatively small – video was in its infancy – and even if it had represented a significant saving, there was another critical problem. As we increased our unicast fallback volumes, our buying power put us in a position where we could compete well in the same market as other unicast providers – however, if we optimized our network and our traffic volumes on the unicast side dropped, then our price on the 85% of our traffic that was unicast jumped up. Our own efficiency became a thorn in our side. While multicast is great for an operator, the commercial model had problems for an OTT player such as Global‐MIX a decade ago, and indeed persists for most CDNs today.
Additionally operational overhead of managing OTT multicast was considerable for those ISPs we peered with, and as 2008 cut in, and as the advertising market, and YouTube pushed everyone to Adobe’s Flash (which could not be multicast), we could see the writing on the wall for Windows Media.
Worse in that climate, we had just developed a first of its type virtual encoder ourselves, and yet we were still running our core business on an appliance‐built infrastructure. So we didn’t have agility when we needed it most.
Along the way I have also built a dozen or so small start‐ups in and around (and occasionally miles away from) the online media space – particularly live TV or webcasting online. Most of these were rolled into Global‐MIX between 2007 and 2009, and individually they had degrees of success ranging from “not very interesting,” either to this audience or to anyone focused on financial opportunities, through to ones that created jobs and were recognized on international stages. I will give examples of these where they become relevant in the text.
At the end of 2009 I dissolved Global‐MIX, and we handed the business to peers in the sector in a very controlled way – allowing us to maintain the professional relationships with our long‐standing clients. This meant that the team became almost universally embedded in key roles in some of the up and coming online video companies, including Limelight, Origin Digital, and Sharp‐Stream.
For my part, I teamed up with Dr. Adrian Roe and Steve Strong, who I had been considering working with to implement our AMT Gateway suite as Global‐MIX was in its zenith a short while before.
These guys were something different; they had a deep background in Fintech and Retail software at scale, virtualized, with stringent regulatory and service level frame works, and yet, after 20 years building several companies up to three‐figure headcounts, they wanted a break from Fintech and Retail and wanted to come to deploy some of their skill, insights, and experience to the online media space.
I had a list of problems in the sector needing solutions, and Adrian and Steve were no mere systems integrators; they were pure code alchemists. This meant we could (nearly) always solve the problems; the decision was which to do first and which would show the best return.
Since then we have never been short of id3as (“ideas”) – there will be plenty of discussion about our outlook, approach, and projects in the next pages.
2Context and Orientation
OK. With that preamble and personal contextualization complete, let me now take you through a little deep dive into the broad history of the industry and its technologies. Much of the content relating to live streaming (in particular) here was also covered in my chapter in Advanced Content Delivery, Streaming, and Cloud Services, and I have bought forward some of the key points from there verbatim. However, I have re‐hashed that content somewhat, since it was heavily focused only on live and linear streaming, to include more insights into streaming of on‐demand content too.
While I have a particular personal fascination with, and interest in the challenges live linear distribution presents, I am also strongly aware that the larger part of the market is focused on the immediacy of on‐demand delivery – so much so that still to this day I hear broadcasters and large content service providers describe the Internet as if it was only able to deliver on‐demand content. Interestingly they often view the Internet content models as if they were junior brothers, and simply not going to be able to participate in the live linear distribution that has traditionally been the preserve of broadcasters.
I am well known on the conference circuit for challenging such views. I will discuss my challenges a little as we go, but for now just take it as spoken that I believe all “broadcast” will be simulcast online as “the norm” within just a few years, and with time the commoditization in the IP technologies and pressure on spectrum will show traditional DTH and DTV broadcast to be ineffective commercially, despite not being “broken” or limited in any functional way. The challenge for broadcast will be to increase its value proposition by factors such as increasing the quality of the content production (and story) and secondarily the quality of images broadcast … why do you think it is that 4 k and UHD are so popular at the time of writing! Yes, the fastest way to roll out such capability may be via broadcast – and no, it doesn’t matter that the end user cannot even perceive the benefit; people will buy in herds anyway, if for nothing else than to feel social inclusion with the neighbors …
… but I digress into opinion. Let us go back to some basics.
2.1 History of Streaming
While there are many isolated events and micro steps that have converged to evolve today’s rich and versatile range of live streaming applications and technologies, there are a few milestones that demark clear step‐changes of note.
The live streaming systems in use today are all derived from voice conferencing technologies. Largely because audio requires less bandwidth to transmit over a network than video does, it is also worth noting that voice and audio streaming pre‐dates video streaming and in fact the birthdate of live streaming within an Internet Protocol context is arguably the date of introduction of the Network Voice Protocol1 on ARPANET.
While the formal RFC741 was not published until November 22, 1977, NVP was, according to that RFC, first tested in December 1973, a mere two months after TCP for “Internetworking Protocols” was introduced to the world by Vint Cerf and Robert Kahn in Sussex University (September 1973). Here is an excerpt from that RFC:
The Network Voice Protocol (NVP), implemented first in December 1973, and has been in use since then for local and trans‐net real‐time voice communication over the ARPANET at the following sites:
Information Sciences Institute, for LPC and CVSD, with a PDP‐11/45 and an SPS‐41
Lincoln Laboratory, for LPC and CVSD, with a TX2 and the Lincoln FDP, and with a PDP‐11/45 and the LDVT
Culler‐Harrison, Inc., for LPC, with the Culler‐Harrison MP32A and AP‐90
Stanford Research Institute, for LPC, with a PDP‐11/40 and an SPS‐41
An unpublished memorandum from USC /ISI in April 1, 1981, by Danny Cohen is widely referenced as adding extensions to the Network Voice Protocol called the NVP‐II or “Packet Video Protocol,” and this seems to mark a clear starting point for the formalization of combined real‐time audio and video delivery over Internet‐worked networks.
In the process of compiling this history Vint Cerf was referenced for his views on who the pioneers were when specifically looking for who did the first webcasts, and he in turn pointed us to both Danny Cohen and also to Stephen Casner of ISI. Though they were part of multiple teams, it is clear that Cohen and Casner had key insights to the creation of the first audio streaming over what was then the ARPANET.
Here is the history as communicated in an email to me by Stephen Casner:
Danny and I, along with others at ISI and at several other cooperating institutions, worked on transmission of packet voice over the ARPAnet starting in 1974. It was specific to voice rather than any audio signal because we needed significant bandwidth compression using voice coding (vocoding) to fit in the capacity of the ARPAnet. This was not voice over IP because IP did not exist yet, but it was packet voice using ARPAnet protocols.
It was not until the early 1980's that we expanded to video when a higher capacity packet satellite network called Wideband Net was installed. The first video was, indeed, crackling black & white with variable frame rate depending upon how much of the image was changing. Later we adapted commercial videoconferencing CoDecs that had been designed to work over synchronous circuits to instead work over the packet network. These provided colour and higher fidelity.
While work on developing our packet video system occurred during the first half of the 1980s, the packet video system wasn't completed and operational until 1986. The following is an excerpt from the Internet Monthly Report for March, 1986:
Multimedia Conferencing Demo
On April 1, a real‐time multimedia teleconference was held between ISI and BBN using packet video and packet voice over the Wideband Net, along with the presentation of text and graphics on Sun workstations at each end. This was the first use of packet video for a working conference. Participants included BBN, ISI and SRI, plus sponsors from DARPA and NOSC.
The teleconference was the culmination of several efforts during March. Our packet video installation at Lincoln Lab was moved to BBN for ready access by the multimedia conferencing researchers there. Performance of the Voice Funnel and Packet Video software was tuned to allow maximum throughput and to coordinate the simultaneous use of packet voice with packet video. And last but certainly not least, the Wideband Net stream service and QPSK modulation were made available to provide the high bandwidth and low delay required for good packet video.
– Steve Casner
So, for the purposes of live video streaming over the Internet Protocols, the definitive birthdate of live streaming is April 1, 1986 – the day the ARPANET was turned off leaving only the Internet – although it is clear that in the context of the ARPANET a very similar range of streaming had been pioneered some years before.
It is also interesting to note that these technologies took at least 10 years to evolve into the media players and production tools that have since become increasingly familiar to today’s Internet browser and connected TV users.
So what of on‐demand content delivery? Well, to understand the drivers and technologies that turned file delivery into streaming content delivery, we should take a moment to think about what streaming really means.
2.1.1 Foundations – What does “Streaming” Really Mean?
Just as there are many histories of the origins of live streaming, there are many interpretations of what the term means!
Live streaming typically has four key stages that align to form a “workflow.”
As Figure 2.1 shows, the encoding stage converts the video feed into a suitable form for streaming (typically compressing it to “fit” within the bandwidth of the available network), and “contributes” it to the network, sending it to the publishing server. Once “acquired,” the publishing server prepares the audio or video for distribution and forwards it to a network of relays that forms the content distribution network (CDN). Each client then uses a directory or schedule such as a webpage or electronic program guide (EPG) to discover the content they want to consume, and metadata is passed to the decoding media player. The decoding media player connects to the distribution network, requests and receives the stream, and subsequently decodes the encoded video or audio, presenting it to the user’s display.
Figure 2.1 Classic live streaming workflow.
For most people, the experience of using a simple webcam‐based videoconference system, such as those that Apple Facetime or Skype can provide, has become a common experience of live streaming. The real‐time facility of being able to hold a conversation in a natural way between two remote locations is a solid starting point for understanding what we mean, in common language, when we talk about video being “live.” But, while it seems obvious at first, “live” is not a simple term in the context of data delivery.
In the context of data delivered electronically or digitally, the speed of light alone determines a small delay between the moment an action occurs (or a sound is made) and when the recipient experiences it. This delay is a combination of two effects: propagation delay and latency. Propagation delay is a simple physical effect, specific to the length of network link that the transmission occurs over and caused by the time the electrons or photons carrying the signal take to traverse that length, where latency also includes delays caused by intermediate processes within the network. We will explore latency and these contributory intermediate processes later in this chapter; however, it is worth noting that latency is often used as a single term including propagation delay, since with the exception of satellite transmission, propagation delay is usually relatively insignificant in comparison to the latency effects of processing.
Typically in telephony and real‐time conversation a maximum end‐to‐end latency of 150 ms is thought to be acceptable (Telecommunication Standarization Sector of ITU, 2013). This is an important starting point for the understanding of what can be considered to be live in the context of networked audio visual content delivery. If 150 ms latency is acceptable for two humans to hold a natural conversation, then this can most certainly be considered to be real‐time live conversation. This synchronicity of communication gives the users of the system a sense that they are both with each other in “real life” despite the separation caused by the telecommunications (note tele = “far” in Greek).
Now, although this form of video is two way, obviously the key here is that events happening at either location are percieved to be seen “live” at the other remote location. Interestingly, if we now turn off one of the two‐way channels, we might assume that we are watching the same live content. However, we would actually have no frame of reference should that video from the remote location be delayed by a further few tens of milliseconds, or even minutes or hours. For a viewer at a remote location with no other way to know when the remote events occur, they are still perceived to be live.
This can cause some confusion when talking about live video transmission. Indeed it is possible for a viewer to, for example, make a phone call to the source and discover that the phone call has lower latency – in a “real‐time” experience, where the video may take considerably longer to transmit back – resulting in the caller hearing the source on the phone say hello some moments before they are seen to say hello on the video signal.
Strictly speaking it would be better to use a slightly different term to describe what is commonly called “live video.” Often the term “linear video” is used for televisual content that is transmitted to its receiver synchronously as it is created by its origin or source, while “nonlinear video” is used to describe content that is accessed “randomly” by the receiver asynchronously, or some time after it has been created – for example, an on‐demand movie viewing.
Incidentally, while the concepts are similar the terms “linear video” and “nonlinear video” are not to be confused with linear and nonlinear editing – while they are similar and in many ways related, they are different, and refer to techniques of editing video content.
2.1.2 Streaming
Despite the term having entered common vernacular, “streaming” remains a distinctly difficult term to accurately and clearly define. By understanding why a “live” stream may lag behind “real life,” we begin to appreciate that in the context of digital televisual communications “things must happen” to enable the communication. These “things” can be one or a series of continuous, synchronous processes all working together to bring the subject of the video to the receiver as fast as possible, or these “things” can be a sequence of asynchronous processes that occur over a much wider timespan, sometimes occurring a long time after the event that is the subject of the video is over, and where the audience can access the content at a later time, be that of their choosing or of the video service providers scheduling.
In a packet network, such as the Internet, whatever the underlying processes that contribute to a communication of data, that “item” of data will, by definition, be broken up into a series of constituent packets that must be sent in a coordinated way over the network, sequenced by the receiver, usually having any missing packets “re‐ordered and re‐delivered,” and then the receiver must process those packets to reconstitute the item and restore it to being a usable communication.
Typically, when we think about these “items” of data being sent over the Internet, we think of messages, files, images, or pages. This thinking persists for most people when they think about video, not least because most people make extensive use of on‐demand services such as YouTube and Netflix, and the impression is that some entire “film” is being downloaded in the same way an email is downloaded when you wish to read it. Our traditional perception of obtaining such data in the nonvirtual world is filled with content in the form of letters, books, photographs, and so on, and we have a tradition of understanding the content being preserved as discrete items in some form of medium – Intellectual Property lawyers call these “fixations.”
Streaming changes that.
One of the first things to be understood when trying to understand streaming is what it tries to achieve. Let’s take a look at mp3 audio as an example. In the early 1990s when the Internet was expanding into the domestic environment, users typically could access via dial up over standard telephone lines, and the typical access speed was 14.4 kbps. Today domestic broadband speeds are usually faster than 1Mbps – so over a thousand times faster than in the mid‐1990s – and many are over 100Mbps. In this new age a single 5 MB mp3 file may only take a few seconds to download – noticeably less time than it takes to play that mp3 file – however, in the mid‐1990s, when mp3 first emerged, it could take at least as long as the play duration of the file to download – so a 5 minute long piece of music would take often more than 5 minutes between the point of choosing to listen to it, and the point it could be heard. This is was far from satisfactory from the user’s point of view.
One of the problems was that once a download of the mp3 was started, even though much of the audio data was available on the local computer, the computer itself could not make sense of the file – it was not a discrete item.
