Following the launch of our commitment to speed and quality we are providing statistics on how well we manage an uncongested network.
|Link||Daytime un-errored seconds||24 hour un-errored seconds||Non-premium||Premium|
|Last 7 days|
|Last 14 days|
|Last 28 days|
Links to carriers
We have links to back-haul carriers BT and TT. There may be additional independent links in future for QoS priority traffic, etc.
Our target is that we operate a uncongested links to the carriers. This means that if the general trend is that the link will be getting full we order more capacity from carriers. The capacity we order is expensive, takes time to change and has minimum terms. This means it can be difficult to perfectly manage the traffic. We allow some head room but not more than necessary. It is technically impossible to guarantee that the link is always uncongested (not without having a pipe the size of all internet links in the world added together) but by careful monitoring and allowing enough headroom we can aim for that target.
This page shows an analysis of how well we meet our target.
The unerrored seconds report is the simplest statistic to understand. If we drop even a single packet in a second then this counts as an errored second. Given that we can be handling hundreds of thousands of packets every second, this can be a very sensitive measure of congestion. Bear in mind we will drop the larger packets first which will normally be TCP which re-sends the dropped plackets. This helps ensure VoIP and interactive uses of the internet are unaffected.
Daytime unerrored seconds are based only on 9am to 6pm Monday to Friday
We also consider 100 second samples. If we have reduced the throughput of non-premium lines at all (as a result of dropped packets for several seconds in a row) then the whole 100 seconds is considered to have affected non-premium customers. Because we are looking at 100 seconds at a time it is possible for very short busts of traffic to cause this to show a worse figure than the unerrored seconds. Even if traffic was reduced by 0.5% for part of the 100 second period the whole 100 seconds counts as errored.
Considering the 100 seconds samples, there is a limit to how much we will reduce the non-premium customers. If that limit is reached then we consider the whole 100 second sample is having an impact on premium lines. This is a sign of much more severe bursts of congestion for several minutes. Bear in mind, a single 100 second sample in a day is more than 0.1% of the day, and even if this does happen VoIP and interactive services should be unaffected.
What happens if there is congestion
Each of these links has (in the case of BT) an agreed commit level. We run a traffic limiter to match that, but we actually have significant extra headroom on the BT side to allow for bursts and ensure we are managing the traffic rather than BT. This is important as, in the event of congestion, we want to ensure that we provide a sensible balance and usable service to our customers rather than simply increasing latency or randomly dropping packets (as BT do). If there is congestion we prioritise smaller packets to give DNS and VoIP a good service and allow protocols like TCP to adapt to a slightly lower rate. We also rate limit non-premium lines in gradual increments to manage the capacity. The recent heavy streaming after the general election and during the world cup meant we could see short periods of congestion which allowed the system to be tested well. It faired much better than links within BT and ensured that VoIP continued to work even with heavy load, and ensured a balanced approach to customers using the service without giving undue preference to bit torrent users (as random packet drops would have) as well as giving premium customers a clear advantage. The customer complaints following this congestion were related to the issues in BT (over much longer time periods) and not issues with our links being congested.
Congestion on the internet as a whole is less common. I.e. the large carriers have a lot of capacity. What is more common is internet congestion at specific sites, such as busy web servers or games servers. Generally such issues are resolved over time as networks are upgraded.
Broadband carrier congestion
In addition to monitoring our links to carriers we also monitor their network as much as possible and report any faults and congestion we find. This can take time to identify and to get fixed. The carriers do not generally offer any guarantees for their internal networks, but we have been very successful in the past at putting pressure on BT to upgrade network links when necessary. Within BT the premium option we offer is meant to provide extra weighting in the event of congestion. This only applies at some specific parts of their network though and not in all places that could suffer from congestion.
Gaming & VoIP
Packet loss and latency are key factors for game players and voice over IP users. Interactive traffic for games, and VoIP traffic, use smaller packets than used by file transfers and torrents so this traffic gets priority in our traffic management even if heavily congested. Our traffic management never delays any packets. This means that game play should not be affected by us. Sadly the broadband carrier networks, and the internet as a whole, can have congestion which does cause packet loss and latency but this affects multiple ISPs and is outside our control.