Now here is a look at the Broadband Incentive Problem. We recently have the announcement that Google is going to bring the web to the TV. Apple is rumoured to be redesigning Apple TV. That’s good news for us consumers. But what about to the people delivering the backend like Starhub, Singtel and M1? Here is a good article on it. Overall the author attributes that this is a classic example of the broadband incentive problem and that it is not cost effective for the telcos on a flat all-you-can-eat data plan
Analysis Can anyone afford to satisfy the demand for internet video?
Users want it, but today, the business models give operators the incentive to throttle, rather than encourage, high-bandwidth uses of the internet. MIT calls this the ‘Broadband Incentive Problem’.
Last July, my company IP Development published research into the cost of 1080p HDTV [PDF, 128k] delivered over a UK LLU network and came to a figure of £2.10 per two 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 – but the conclusions then and now clearly support the view that Net Neutrality is likely to neuter the internet.)
The point is that such figures are not economically viable, and 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 economics of the LLU (Local Loop Unbundling network) have not changed in the last nine months. If you are just looking for headlines, this is probably where you should stop reading. The cost of two hours of HD TV over LLU in the UK is £2.10 and this is too much. IP TV, if fully deployed, 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.
Doing the maths
We will attempt to explain how we build up our cost base to help you understand the nature of this problem in greater, financial detail.
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. 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.
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 for £279. 720p needs “only” 6.4 Mbps. It is worth adding to this that 480p requires around 2.5mbit/s, standard definition is around 700 kbps, while YouTube is 200 kbps.
So we looked at the highest resolutions and thus arrived at the highest figures. 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?
Frighteningly, it does not include the cost of the local access loop or the DSLAM / MSAN access 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.
We need some numbers here, so using our LLU backhaul model we would cost out 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 8mbits/s of the 100mbits/s 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.
Utilisation figures from an ISP: The X-axis represents time (by hour), the Y-axis utilisation in mbits/s. Click to enlarge for traffic details.
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.
According to research by Ellacoya, five per cent of broadband users generated 45.3 per cent of traffic – while 40 per cent of users account for only 3.8 per cent of traffic. This tallies with earlier research which indicates that 10 per cent of users account for 65 per cent of traffic.
In South Korea and Japan, four per cent of users make up 75 per cent of traffic demand according to the 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.
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 not charged. 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’, which allows the model to take into account how users aggregate onto the shared infrastructure by taking a wider view of the peak window. Using this approach, the operator assumes how many busy hours there are to be in a week, and shares the cost equally between the number of hours. The operator then adds up how much busy hour usage a customer builds up, and allocates 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).
We base our assumption on 100 Mbps backhaul costing £1,000 per Month. Ie a cost of £10 per Mbps which is close to reality and makes the numbers easier to walk through. In our models we use 45 ‘busy hours’ per week (Monday to Friday, 6pm to 11pm and 10am to 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. Remember that 1mbits-hour is about 450MB. So let’s multiply the number of busy hours (45) in a month by number of weeks in a month (4.3) to give busy hours per month.
So you have 1 Mbps costing £10, which you are using for 195 hours per month. This gives you a cost per Mbps Hour of £0.05168 – or about 5p. 1 Mbps used for 1 hour delivers 450 Megabytes, so to get a cost per Gigabyte you take your cost per Mbps Hour and divide by 0.45. 0.05168 / 0.45 = 0.1148, so 1 Gigabyte would cost you around 11.5p Let’s say Joe Bloggs is using 2GB of data a month. His cost is therefore £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. The BARB website shows this to be around 25 hours per week, fluctuating with the season and the weather.
Using the same model, if Joe Bloggs watches 25 hours of 1080p HD TV per week, he’s using 448 GB of data a month. That is going to cost the service provider £51.45. Tying this back to our previous research, we stated that the cost of a two-hour, 1080p programme (a 9GB file) would be £1.07 for the backhaul. 45 busy hours results in a monthly cost of £1.03. The difference between this and the £1.07 is in the rounding.
Last year’s 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, but I will save that for another day.)
The Cost of Prime Time
In summary, the cost of delivering an hour of peak time HD TV over IP can be calculated according to the variables you choose. But what doesn’t change with these assumptions is the view that the economics of HD TV over IP simply does 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 (three hours per day, say 7pm to 10pm.)
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. ®