Classes of service and neutrality on the UFB

A couple of months ago (yes, I’m slow to post as always) I was made aware of a proposal that may mean the UFB networks favour certain types of applications and service providers over others, or favour legacy styles of service delivery such as walled gardens over the evolving trend towards over the top delivery.

What this issue boils down to is a guiding principal of neutrality. Now it’s hard to know what if any principals have been guiding the development of the UFB architecture since I cannot find any in the few documents that CFH and the TCF have so far made public. (This may be radical to suggest, but I think CFH needs to be more open and engaging. Hey CFH, how about doing a blog post on what you think about neutrality and take it from there?)

What should be the guiding principal here? Well we need to ask what we are building the UFB for and what we want it to achieve, and I can’t speak for other people, so this is only my perspective, but it’s one I think most people who consider the UFB as a project of strategic importance for New Zealand’s future will agree with.

The Government should not be taking on all the risk of building the UFB simply so that established providers can continue to provide the same services they do today, or entrench their positions. I believe the purpose of the UFB, and any similiar national broadband programme, is to provide a neutral platform that allows retail service providers (RSPs) to compete equally on the basis of how good their products are regardless of their size. For this reason the UFB must aim to minimize its influence on what shape those products take. Thus distinctions must not be made between types of applications or style of service delivery. That must be decided by the consumers and the competition between the RSPs.

So with that in mind I was concerned when I heard that the current proposal is have two classes of service, a high priority class and a low priority class, as illustrated in the table below taken from the TCF UFB Ethernet Access Service Description.

Let me be clear. This is stupid. (Or I’m stupid and not seeing how this is going to be used.)

What does this mean? Well it will depend on how it is going to be used. First let’s take a look at these two classes.

We have a high priority class which has tight SLAs. This class is not colour-aware, meaning that it doesn’t support the concept of bursting above the committed information rate (CIR). Excess traffic over the CIR is dropped. I do approve of the 5 ms frame delay (latency) and 1 ms frame delay variation (jitter) SLA. But I disagree with the 0.1% frame loss ratio. 0.1% is too much for what should be absolutely committed capacity through the network. Instead this frame loss ratio should be closer to 0.01%, but couched with availability, which is supported by the MEF framework that the TCF are sort-of using here. That is, we should say that 99% of the time frame loss will be below 0.01%, but 1% of the time there may be some failure or event on the network that causes it to go higher.

The other class has pathetic, almost non-existent SLAs. It is basically a service where if there is available network capacity at that time the packet will be forwarded, otherwise it may be queued for a full second, and may never get through. There is no defined FD or FDV, and the FLR at 2% is absolutely ridiculous as anyone who knows anything about networking will tell you. This document gives the impression that this class is colour-aware, but actually it’s still a single-rate class as the CIR is always zero.

I really don’t know how they arrived a this, I can imagine there was a lot of debate at the meetings, and I recognise that design by committee can be difficult at the best of times.

Ok-ok, so hurry and get to the point, you’re saying.

To me, the above implies that the two classes of service will be carried in separate queues through the UFB networks. The high priority class is the only class offering a CIR and will carry applications such as voice and video that require committed bandwidth. The low priority class offers no commitment and will carry Internet, possibly with an atrocious quality of service if the SLAs shown are any guide.

So imagine you’ve subscribed to a triple play package from your RSP. You have one phone, and one TV, so your RSP orders a service from the local fibre company with:

• 150 Kbps of high priority bandwidth for voice, enough for one voice call since you have only one phone.
• 10 Mbps of high priority bandwidth for video, enough for delivering one HD stream since you have only one TV.
• 50 Mbps of low priority bandwidth for Internet — an arbitrary number for this example, and presumably this will vary depending on each RSPs packages, e.g. there may be a 10 Mbps package, 50 Mbps package, and 100 Mbps package.

The UFB network receives traffic from many competing RSPs and delivers it to many subscribers over shared links, so queuing and scheduling must be used at these points within the UFB network to provide the desired differentiation between the two classes of service. The indication is that the high priority class will be given bandwidth before the low priority class in a strict priority or weighted fashion. (This is a simplification of the issue sufficient to illustrate the point below, but it should be noted that the problem is actually much larger, requiring the use of H-QoS to ensure fairness between the different RSPs and their respective subscribers.)

Now coming back to our scenario. Consider we are watching a VoD stream from our ISP during peak hour, and this is an HD stream requiring about 9 Mbps of bandwidth (depending on how much action is going on). As we outlined above this is delivered in the high priority class of which we have 10 Mbps to play with, so we can be certain the stream gets through in a timely manner without packet loss and the associated skipped frames or artifacts.

But we get bored of this, so turn to an over-the-top (OTT) video service (such as Hulu, NetFlix, or YouTube) for entertainment. These are delivered over our Internet service, which as we outlined above has 50 Mbps of low priority bandwidth with basically no SLAs.

Now we find that our OTT video service is getting a lot of buffering because it is peak time and there is congestion on the UFB network. It turns out everyone in our neighbourhood has come home after work and started watching TV. All of these TV streams are being carried in the high priority class so getting the share of the bandwidth on the UFB network before our Internet traffic. Our OTT service suffers as a result.

Hang on, you say, you’re no longer watching the VoD stream, but you are paying for 10 Mbps of high priority bandwidth to carry it. So when you’re not using that 10 Mbps for VoD where does it go? And who decided a VoD stream from your RSP is to be treated differently to a VoD stream from an OTT provider? You’re right to ask that. When you aren’t using your 10 Mbps of high priority bandwidth it gets shared out amongst everyone elses low priority traffic — it does not get assigned to you, you see only a fraction of it, even though you’re paying for it. And who decided that VoD from your RSP is more important than VoD from an OTT provider? Apparently CFH and the TCF did back in February.

So what’s the solution? Well this is a complex subject and there are a few solutions. In order to select the best solution the guiding principals must be established and the detailed requirements analysed. One could easily end up writing hundreds of pages on the subject, so given I get no reward for that, I’ll jump to those solutions that are readily apparent.

1. The above two classes of service could be modified to make the low priority class dual-rate, supporting a CIR and EIR, and tightenting its SLAs, with the high priority class priced to discourage its use except for very low bandwidth and special applications. The UFB network will perform the necessary H-QoS to ensure fairness between the RSPs, i.e. between the aggregate of subscribers for each RSP, but not at a per subscriber level. The RSPs will be responsible for performing the H-QoS necessary to ensure fairness between each of their subscribers and appropriately prioritise their applications and if they choose to also OTT applications. (Some inventive RSPs will choose to give the consumer granular control over this through a portal.)
2. As above, but the high priority class is simply dropped because it serves little useful purpose, and simplification is better.
3. The UFB network performs per-subscriber H-QoS on behalf of the RSPs based on the purchased bandwidth profiles. Each subscriber is guaranteed the amount of bandwidth they actually pay for, but the H-QoS is configured with multiple queues in a mix of strict priority and weighted round robin fashions. The RSPs can then manage the markings of different applications to indicate the relative priority of them and which queues they should go into.

If anyone in charge is listening — please take another hard look at this. I am happy to eat my hat if I’m wrong, but this is an issue fundamental to the purpose of the UFB, and we want to get matters such as this correct up front, rather than trying to address it later on when there is no regulatory powers to do so (given the Government’s insistence on a 10 year regulatory holiday).

Advertisement