Mobile traffic management - video confusion

A lot of my meetings at MWC two weeks ago were about managing mobile broadband traffic - by offload, by compression, by policy and various other means.

There is a total lack of agreement on where the emphasis should be. Everyone has a solution - and it's far from obvious that they are not pulling in opposite directions. Dump most traffic to WiFi, and it becomes much harder to justify restrictive policies when the phone is "on net". Offer "premium" or "platinum" connectivity - and get let down by poor coverage. Put femtocells in place - and then try to distinguish femto vs. macro traffic in the policy engine, because throttling someone's 3G access *on their own cell & broadband* is a recipe for disaster.

And all this is before we get to the fun-and-games which will ensue in a world with widespread connection-sharing.

The starkest choices seem to be around "what to do about mobile video". Endless copies of Cisco's Visual Networking Index charts were trotted out (or other large vendors' inhouse equivalents) showing terrifying increases in forecast mobile video traffic, swamping all other types. Even leaving aside that other new apps might be even more traffic-generative (maybe augmented reality, for example), there are still huge issues about how to treat video.

First off, let's be clear - there is no single application called "video". There's a mix of downloads and streaming, one-way and two-way, embedded and standalone, numerous codec and frame rate options and so on.

In the eyes of a user, clicking "I like" for a YouTube clip shared on Facebook by a friend, is a very different application to watching the same thing on YouTube.com in a separate window. Context is very difficult manage in a policy engine, especially if it's a web mash-up.

One theme that I heard repeated a few times was the idea that some sort of server or gateway would intercept inbound video traffic on an MNO's main Internet connection, spot who/what was requesting it, and (let's be polite here) "mess about with it" in order to reduce the impact on the network.

It's a very similar idea to the various Web messing-about-with engines ("transcoders" or "content adaptation") we've seen before from the likes of Novarra, ByteMobile and Flash Networks. Yes, they sometimes reduce load, but when first introduced they mangled content and advertising, caused problems with mobile commerce and did some horrible things to sites that were *already* mobile-optimised by the original website owner. Over time, the worst effects of these seem to have been ameliorated, with some sort of grudging consensus now almost attained.

The same set companies, as well as a group of new ones like Acision and Ericsson, are now talking up the idea of compressing video traffic on the fly to protect the network. One comment made was that the network could choose to buffer video traffic itself, rather than let the phone/PC buffer fill up quickly, over the air. YouTube was cited as being "aggressive" in encouraging users to download whole videos upfront, when sometimes they closed the video window and "wasted" a lot of bandwidth, because they hadn't watched the whole thing.

To punish this sort of profligate downloading behaviour, it's envisaged that the network could either compress the video traffic, or "drip feed" the buffer.

Cue consternation from other people they haven't yet spoken to.

First up are the radio guys, who, paradoxically, would much *rather* whole videos downloaded fast rather than being drip-fed. It's more efficient for base stations to blast as much traffic as possible at a user, in a short space of time, if it's not actually congested. And it's also much better for the user's battery to download a big gulp of data in one go, and then switch the radio off. Keeping the connection up for longer may also increase the signalling load even if the actual traffic is reduced.

There is also an interesting regulatory angle here - if mobile broadband speeds have to be advertised on the basis of average actual speeds, rather than theoretical peaks, then the drip-feed approach could have serious marketing consequences.

The compression side of the equation is also likely to be extremely controversial. There's an interesting set of issues of liability if you've paid for HD video (or an advertiser has), and the network arbitrarily steps in and mangles it for you during delivery. There's another interesting set of questions of whether the network can work out exactly what video stream to compress, if it's sent via a CDN like Akamai, which might peer at various points in the network.

But all of these are minor compared to the likely outrage from various video content and aggregation companies that have their content "messed about with".

Put simply, any attempts to "optimise" video in the core of the network are likely to be very ham-fisted, especially if they attempt to compress or transcode. The core is unlikely to be able to know how best to compress a video as it will vary immensely on a genre-by-genre or even scene-by-scene basis.

Content can be delivery-optimised in various ways: frame rate, frame size, key frame rate, audio rate, etc. all can affect bandwidth, however the best encoding recipe may be influenced by the type of content: sport, talking heads, music video, being genres of content that could be argued to have opposing views as to what's the best encoding recipe. Think of an interviewer static in a chair with a fixed background, versus a live-streamed F1 race. Applying a single policy to both videos is likely to be very crude, and result in a very poor user experience.

Some policies are already causing consternation - for example, by blocking overhead-light delivery protocols such as RTSP/RTP over UDP, forcing publishers to more inefficient alternatives.

Other side-effects of network-centralised video policy management may be to push a greater processing burden down onto the handsets (and hence their batteries) - for example, re-coding video in formats like H.264. As well as requiring a lot of network-side processing power to do this in real time, we could end up with the interesting situation of power consumption differing on a per-network basis. That could make for some interesting marketing angles for operators "Get your XYZ handset on the network that gives you 3 hours longer between recharges!"

(Hat-tip here to input from my friend David Springall, CTO of Yospace, which provides platforms to mobile video content publishers).

One answer seems to be to optimise mobile video through a balanced combination of editorial control and network technology. If operators (or their network partners) provide adequate guidelines on making mobile-friendly video, it may be that providers all the way back through the value chain can help - for example, content can be editorially controlled to be more compressable, such as by avoiding unnecessarily moving cameras during production. This is similar to attempts by operators and device vendors to encourage their app developers to follow "network friendly" approaches like fewer server pings.

It seems unlikely that video publishers will pay operators "cold hard cash" for QoS (or even an SLA) on mobile broadband, despite the rhetoric around DPI / policy management boxes. It's simply too difficult to control end-to-end quality as far as the device UI - and *prove* it to the content provider. But publishers would likely respond to doing what they can with their video content to make it 'work better' on mobile networks. Although they don't have the technical ability to do this, they are using third-party platform providers to deliver their video and it is these third parties that can implement whatever is considered best practice by the networks.

Operators could publish clear guidelines to help third parties optimise video on their networks; platform providers should work to these guidelines in the interests of delivering a better user experience (assuming some measure of consistency across operators, of course - it's unlikely that they would wish to see 800 different sets of rules across the world - or, worse, 2400 if they vary for 2G, 3G and pseudo-4G networks). It would also help video content publishers if MNOs provided APIs that provided more information about the network quality in realtime, allowing platform providers to be more sympathetic to the network. While this may also be feasible via handset-side APIs, the network may enable a more consolidated view to be provided. Over time, this could even evolve to cell-by-cell "traffic reports" allowing video to be delivered differentially to those in the best/worst radio or backhaul congestion conditions.

Depending on the laws in each country, well-behaving video traffic (however that is measured and defined) could be prioritised in some circumstances.

One issue that is likely to crop up is how to deal with PC-based video traffic transiting mobile broadband networks via 3G dongles. This is a little more problematic than smartphone video, as it is usually marketed as being a direct alternative to ADSL or cable broadband. Nevertheless, some form of in-application smarts could still allow optimisation - it's been pretty common for years to have a choice of different broadband speeds / types before starting a video "Are you watching on: ADSL, LAN, 3G, WiFi etc" might put the user back in their normal state of control. There's also a very strong argument to prefer outright offload for PC-Internet traffic to WiFi (or femto) and avoid the core network and compression argument altogether.

Overall, I definitely think that the question of how to deal with mobile video is still at very early stages. Although various solutions are emerging, it seems probable that the initial knee-jerk attempts to reduce network load will have some fairly nasty unintended consequences in terms of user experience, device battery life, radio performance and content-mangling - and hence generate support calls and dissatisfaction. The idea that the network can somehow magically reduce the impact of video traffic, without any input from video publishers or aggregators / platforms, seems misguided.