Consumers are beginning to shift their video viewing habits from linear TV channels to on-demand internet-based sources. Increasingly, the “TV your way” experience pioneered by TiVo (News - Alert) is taking root with broadband consumers. Whether it’s watching the Daily Show or South Park on ComedyCentral.com, or 30 Rock on NBC.com, broadband consumers are beginning to watch what they want, when they want it. This growing sea change in consumer behavior is applying pressure on the infrastructure of broadband service providers (BSP).
While existing traffic engineering technologies must play a role in the effective delivery of on-demand media, traffic engineering by itself is insufficient to ensure the diversity of internet video can be effectively delivered. This article explores the strengths and deficiencies of existing traffic engineering technologies, and outlines what is needed to solve the emerging demands on the BSP’s network.
Before Traffic Engineering
BSP networks have always benefited from the cost effectiveness of over subscription. For example, a DLSAM with 400 connected subscribers receiving a 5 Mbps broadband service might only have a DS3 uplink. This 44:1 over subscription might seem egregious, but for the correct usage pattern it remains completely appropriate. However, as the usage patterns shift from bursty data services to more continuous streaming services, this level of over subscription is no longer appropriate.
Enter Traffic Engineering
While the argument has been made that consumers are increasingly finding and viewing the video content on the Internet, it is not correct to suggest this is the first or only form of “converged” media. Much of the mid decade was focused on the convergence of voice, video, and data on the BSP’s network infrastructure. The real emphasis, however, has been on video, and the many IPTV (News - Alert) deployments that have been pursued.
Traffic engineering takes on a very definitive signature in these deployments. By and large, they all seek to separate the video traffic from other traffic until it reaches the subscriber. This separation has taken on various forms, but we will focus on Differentiated Services (DiffServ). This form of traffic engineering, allows the BSP to identify different traffic types, and to ensure that the available capacities appropriately favor select traffic types, based on modeled usage patterns.
While multi-cast plays a significant role in most IPTV solutions, the most germane equivalent to Internet-based video, is video on demand (VOD), which is often considered a complementary piece of any IPTV offering. The issue with VOD is that the BSP cannot predict when the subscriber will chose to view content. As a result, traffic engineering must assume a certain percentage of subscribers will be viewing VODs at the same time, and will engineer a percentage of the available network capacity to accommodate this.
There are two parts of the BSP’s network that must be modeled for the guaranteed delivery of VOD services. Namely the shared access portion (e.g., the DS3) and the individual subscriber portion (e.g., the DSL line). The issue with the shared portion is fundamentally, “how many concurrent VOD sessions can be present at one time?” This is really a question of take rate. If each VOD session took 1.5 Mbps, then the aforementioned DS3 could only support 30 concurrent sessions, or 8% market penetration. While not ideal, this may well accommodate an early adoption rate of 5%. If this is how the shared portion is modeled, then 62% of the DS3 must be engineered for VOD traffic.
The subscriber line must also be modeled, relative to the number of concurrent VOD sessions each subscriber is expected to view. Given the example of 5 Mbps subscriber line, it may well be the case that 3 VOD sessions per household are modeled, or 90% of the traffic engineered for VOD traffic.
Clearly there are two questions that must be considered. What happens if more than 19 (e.g., 5%) VOD sessions occur at once? And what happens if more than 3 VOD sessions occur to any one subscriber household? The first scenario, if violated, will affect all households, while the second scenario, if violated, will affects all VOD sessions within a single household. Neither scenario is desirable, and should be avoided at all costs.
Unfortunately, it is not the job of traffic engineering (or DiffServ) to prevent a model from being violated. Traffic engineering is simply there to ensure that a well behaved model is supported by the network. To understand how the model remains well behaved, you have to look elsewhere, to the VOD middleware itself. The VOD system might limit the number of VOD sessions any one subscriber household, and possibly even limit the number of concurrent VOD sessions permitted at any one time. The bottom line is that another trusted entity is ensuring that the model reflected by DiffServ is not violated.
Another interesting point regarding traffic engineering, is that packets which are to receive special treatment, must be marked by a trusted body. In the VOD case, it is simply the VOD middleware which marks traffic for priority treatment. This is an important point to think about when a video does not originate from trusted sources.
In a World of Infinite Choice
Given that consumers are starting to acquire their video content from untrusted Internet sources (from a BSP perspective), three glaring problems arise with the conventional traffic engineering approach. One, how do you model network behavior? Two, how do you identify untrusted traffic so that it may ride over the engineered network that resulted from solving the first problem? Lastly, how do you prevent the model used to engineer the network from being violated by the many untrusted sources of video media?
The first problem can only be addressed if it is known what the subscriber usage patterns are going to be. This can be addressed through monitoring subscriber behavior and/or building business models around the delivery of internet based video. The bottom line is that if the BSP has no visibility into the expectations of their subscribers, they surely can’t model that behavior.
The second problem can only be addressed through deeper inspection of the media sessions that are traversing the BSP’s network. Simple tricks such as “all traffic from this IP address” are not sufficient in the era of content delivery networks (CDN). IP addresses may change from day to day, depending on how a CDN might be optimizing its servers. Understanding what is a media session or what the network requirements of the session are all critical. For example, a video may not be based on a uniform data rate, rather may differ based on subscriber preference from standard definition (SD) to high definition (HD).
None of these parameters may be known in advance by the BSP. Yet they are necessary, along with policy preferences, to ensure that service guarantees can be made for the consumer.
Finally, none of these remote services will have any opinion on the limitations that are present within the BSP’s network. Does Amazon care that 15 Netflix sessions are currently active on a given portion of the BSP’s network? Or that half the VOD sessions are actually HD and not SD? These issues might be resolved within a single VOD system, tightly controlled by the BSP, but no such opportunity is available when infinite video sources can compete for network resources without any controls. To solve this problem, the network needs to embody all of these properties itself.
Conclusion
Traffic engineering alone cannot solve the problem of internet video distribution. It certainly plays a role, but it is insufficient to independently resolve the multitude of competing service requests. The BSP must have more powerful ways to identify premium video traffic, and to combine the role of network engineering with identification, enforcement, and adaptation of service models with correspondingly adaptable traffic engineering.
Siegfried Luft is the founder and CTO of Zeugma (News - Alert) Systems. To read more of his columns, please visit his columnist page.Edited by Greg Galitzine