The IP Development Network

Welcome to The IP Development Network Blog

Monday, 19 March 2007


Part 2: The cost implications of video

Last week’s article looked at the market for online video and concluded that yes, there is a clear demand from consumers.

I had a very interesting follow up to last week’s piece from Simon Torrance, who runs the Telco 2.0 initiative who rightly stated that what I am describing is what MIT have coined The Broadband Incentive Problem. That “Today’s prevailing business models give … operators the perverse incentive to throttle innovative, high-bandwidth uses of the Internet.” This week’s article will pose the question whether anyone can afford to satisfy this demand. Following on from last week’s elephant theme, is this you in the car…?

Last July, we published research into the cost of 1080p HDTV delivered over a UK LLU network and came to a figure of £2.10 per 2 hour film. This research was of interest to a wide community, from ISPs who bear this cost to internet evangelists who believed that we were somehow in the pocket of the big telcos in the Net Neutrality debate. We were not paid by anyone for that research, nor is anyone paying me a penny for this series of articles but the conclusions then and now clearly support the view that Net Neutrality is likely to neuter the internet. The point then and the point now is that such figures are not economically viable, if this is the best the net can do, then so long and thanks for all the fish...

We stand by those conclusions today as the LLU economics have not changed in the last 9 months. If you are just looking for headlines, this is probably where you should stop reading. The cost of 2 hour HD TV over LLU in the UK is £2.10 and this is too much. IP TV would break the internet, except it won't because ISPs will never allow it to go that far - most content will never reach the internet and the stuff that does will be throttled back by drastic measures that kill the experience for those that try. All but the most determined will be deterred and those that persist will be easily tracked by the sheer volumes over their connections. TV will stay on broadcast platforms until structural issues that drive this £2.10 cost are resolved.

Of course this figure is driven by assumptions but regardless of the assumptions we make, we arrive at costs way in excess of what can be achieved over a broadcast platform, albeit with associated restrictions on the service. There may be niches in which such a premium pricing would be acceptable price for the extra functionality, but unless something changes in the way that the whole thing is organised and built, this £2.10 traffic cost (or whatever it really is) will mean that ISPs need to throttle demand in some way.

If you want to know how we get to this figure, understand some of the assumptions and imperfections in this figure and see how it may vary if you change certain key assumptions, read on!

We will attempt to explain how we build up our costbase to help you understand the nature of this problem in greater, financial detail. It may be far too much detail for some people’s taste, but I have written this in a way I hope allows you to work through your own examples and use your own assumptions to check the costs we publish. At the end of the day, our model is only ever as good as the assumptions we put in you may disagree with some of them. If you do work this through, you will see that what we have published previously is actually on the conservative side.

By explaining how we build our models we will be building a platform for later articles where we look at Managing Traffic Volumes and what the Building Blocks for a Solution may be.

Last year’s research also looked at the comparable cost of delivering the same file over an IP Stream network, which we will not be looking at in this piece as the figures published last year will be out of date on 1st May 2007 when BT Wholesale’s new IP Stream pricing comes into effect. We will be publishing a detailed analysis of the new charges nearer that time.

The rest of this article will look at the £2.10 figure in more detail, so let’s start by making two things clear, the first is that this is the incremental cost for end to end delivery over the internet using an LLU access network and the second is that this is for 1080p (1920 x 1080 pixel) HD.

The importance of the first point is that it includes internet transit as well as the cost of the LLU network. It is worthwhile breaking down that figure into its constituent parts: £1.03 for the transit and £1.07 for the LLU network. This breakdown is important because it highlights the importance of what the source of the content is and whether that means that the ISP has to pay to receive the file as well as to deliver it. We will come back to this in much more detail in later articles.

The fact that we analysed 1080p and not 720p or 480p is important too. 1080p is regarded as “true HD” and needs at least 10 Mbps to stream. You can get a 1080p TV from Currys online today from £1,199. The cheapest HD Ready is a 720p at £299.98 (oops, it was when I researched the article last week, there is now a cheaper one at £279). 720p needs “only” 6.4 Mbps. It is worth adding to this that 480p requires around 2.5Mbps, standard definition is around 700 kbps, while YouTube is 200 kbps.

The point is that we looked at the highest resolutions and thus arrived at the highest figures. This was perhaps a headline grabbing move at the time, looking as it did into the future rather than the present, but as you can see from the Currys web site, 1080p is already affordable and becoming more so every day.

So where is this £1.07 cost on the LLU network? It is worth understanding this as it will help later when we look at solutions.

Frighteningly, it does not include the cost of the local access loop or the DSLAM / MSAN equipment as these are fixed price items that do not vary with the amount of traffic. We are purely looking for the incremental cost of carrying a file.

This is where it starts to get a little complex because networks are inherently shared between many users so you have to start allocating costs on what will always be an arbitrary basis. This is an important part of the problem.

The actual cost of a network is solely determined by its peak load. Allocating that peak load between the entire user base is never going to be perfect at a summary level because that allocation can’t take into account whether that user’s demand was at a peak point in time (actual cost 100% of usage) or any other period (actual cost 0% of usage). So if Joe Bloggs was using the internet for an 8 Mbps download at 9pm on Monday evening, the exact moment the network peaked at 100 Mbps, his usage would, strictly speaking cost his service provider the full price of the backhaul circuits connecting him to the internet.

We need some numbers here, so using our LLU backhaul model we would cost Joe Bloggs’ usage for that month (along with everyone else who was using the service at that peak time) at £80 because Joe is using 8 Mbps of the 100 Mbps that we are paying £1,000 a month for the backhaul circuit.

The problem with this model is that Joe would be one of a few very expensive customers, who just happened to be using the service at the peak point in time, that month. Next month, Joe may be using the service at 9.30pm or even at 9pm again, but that may not be the peak point in time next month, so his usage would be free.

This model while accurate, it is full of uncertainty that may lead to a light user having the full network cost allocated to them (£80) once every 350 months, with nothing the rest of the time.
In the above chart, only those users active on the service at A would actually drive an increased cost to the ISP. Usage at B and even a small amount at C would not cost the ISP a penny more. Even usage at A doesn’t drive additional costs unless it triggers a step change in the backhaul capacity.

The most common way of dealing with this costing problem is to ignore it and say that everyone bears an equal share of the cost. This though is clearly unfair to the vast majority and there are some stats that I want to bring in here as an aside, which however serve to illustrate the point.
Telco 2.0 Blog. This is clearly a concentration of usage into the hands of fewer people. As
infrastructure capability grows, so the ability for a small number of individuals to dominate increases.

The point for this article at least is that we need to use a method to allocate costs that balances these two extremes. On one extreme having a situation where if you use the service for all but the peak period, you are free. On the other extreme we would allocate the same cost to all users regardless of the likelihood that a heavy user will be using the network at peak times more often than a light user. Contention ratios fall into the latter category and are misleading as a result.

Instead we use a busy hour assumption. This assumption allows the model to take into account how users aggregate onto the shared infrastructure by taking a wider view of the peak window. You have to assume how many busy hours you have in a week and share the cost equally between that number of hours. You then count up how much busy hour usage a customer builds up and allocate that cost to them. The outline is far from perfect, but it at least provides a model within which most users can be allocated a share of the cost, while taking into account the fact that usage off-peak is de-facto free.

Modelling this way allows for applications to be differentiated into those that are very likely to occur during the peak window (TV), against those that occur at off peak times (patches and backups). Because we use a wide window we are able to forecast and review behaviour as opposed to discrete, time sensitive actions

We are forced to ignore the step change element of the cost equation as this adds more complexity by again adding in the time dimension. It is true that the majority of the time, incremental usage is free, whether it is on top of the peak or not because step changes like upgrading the backhaul circuit are uncommon events. You do not want a user cost model that says that usage is free until some arbitrary point in time when costs are enormous because this would lead you to sell your product for free until you have no more capacity to give and then expect your next customer to pay the cost of the entire network upgrade. As a result, you have to blend this step change into your figures to remove it. You can model the step changes at a network level, but not on a user by user basis.

As a result, our model in this area ignores under-utilisation of the backhaul links. If you wanted to include this you could do so by assuming a certain amount of headroom in the network and reduce the actual capacity of the links to 80 Mbps instead of 100 Mbps for example. We have kept 100 Mbps because it is a conservative view and because the assumption of utilisation could be short down.

One assumption we cannot avoid making is the number of busy hours, which is vital. In our models we use 45 hours per week (Mon – Fri 6pm to 11pm and 10am ‘til 10pm at weekends), where internet use is concentrated. We assume that usage in these 45 hours is equal so we get a fairly low cost per hour but a wide window to forecast user behaviour. The total cost (£1,000 for 100 Mbps in the Joe Bloggs example above) would be divided by 45 times 4.3 weeks per month to give a cost of £0.05 per Mbps Hours.

Wrapping this bit up, 1 Mbps Hour is about 450 Megabytes, so if you add up the amount of peak usage in those terms, you can arrive at a cost for that user. Let’s say Joe Bloggs is using 2 Gigabytes a month. His cost is therefore 2 divided 0.45 times £0.05, a total of £0.23 per month.

So what? £0.23 per month is not going to break the service provider, but consider a month’s IP TV viewing; 25 hours a week at 1080p is 448 GB. That is going to cost the service provider £51.45.

Tying this back to our previous research, we stated that the cost of a 2 hour, 1080p programme (a 9 GB file) would be £1.07 for the backhaul. Above, we have created a calculation that says:
[circuit cost] / [bandwidth] = Cost per Mbps
1,000 / 100 = 10
or 1,000 / 80 = 12.5 if you want to include under utilisation

Cost per Mbps / (45 x 4.3) = Cost per Mbps Hour
10 / 193.5 =

[GB usage in busy hours] / 0.45 x Cost per Mbps Hour = Cost per User
9 / 0.45 x 0.05168 = £1.03.

The difference between this and the £1.07 is in the rounding. Last years estimated circuit cost was £12,462 per year which we rounded in the walk through to £1,000 per month to make the numbers simpler. Re-run the equation with your backhaul circuit set back to £1,038.50 a month and you get back to £1.07

Of course if you have a smaller peak window, the cost goes up and vice-versa. This is the weakness of our forecast model, because if you overestimate the number of busy hours and find that your demand is very peaky you could find your costs escalating rapidly. There is a whole article in itself on peak to mean that is related here, but I will save that for another day.

In summary, the cost of delivering an hour of peak time HD TV over IP can be seen as different values depending on the assumptions you make. What doesn’t change with these assumptions is the view that the economics of HD TV over IP do not work. The two scenarios show our results if we use the standard 45 busy hours. The more extreme example shows a heavier concentration of peak viewing into 21 hours a week (3 hours per day, say 7 to 10pm)

Cost per Hour of Peak Time Viewing

Regardless of the assumptions, we arrive at figures way in excess of what can be achieved over a broadcast platform, albeit with associated restrictions on the service. There may be niches in which such a premium for the functionality would be acceptable, but unless something changes in the way that the whole thing is organised and built, these traffic costs will mean that ISPs need to throttle demand in some way.

That is The Broadband Incentive Problem. Next week we will look at the ways in which the traffic is being managed today and what that means for the industry.

Other Articles in the Series

Part 1: The Online Video Market
Part 2: The cost of Online Video
Part 3: Traffic Management
Part 4: Routing the Money
Part 5: Routing the Packets
Summary Slides


This page is powered by Blogger. Isn't yours?

 Subscribe in a reader