Traffic shaping options: Difference between revisions

Back up to the Technical Documents category
From AAISP Support Site
mNo edit summary
m (clean up, typos fixed: one week → one-week, 500Mb/s → 500Mbit/s (2), have have → have)
 
Line 1: Line 1:
<indicator name="Front">[[File:Menu-document.svg|link=Category:Technical_Documents|30px|Back up to the Technical Documents category]]</indicator>
<indicator name="Front">[[File:Menu-document.svg|link=Category:Technical Documents|30px|Back up to the Technical Documents category]]</indicator>
Firstly, it is important to realise that we don't have traffic shaping to slow down some protocols or users in order to manage traffic. Our policy is not to be the bottleneck whenever possible. However, this page explains some of the shaping options that exist and that we are working on. The fact that we have a usage based charging model means that more usage pays for additional costs so we can maintain this policy. The same is true within BT. We pay for usage, so BT can upgrade links as necessary to provide a quality service to us and hence you. Sadly BT don't always manage this very well. Equally, we can get caught out by some sporting events and the like. So the way shaping works is important.
Firstly, it is important to realise that we don't have traffic shaping to slow down some protocols or users in order to manage traffic. Our policy is not to be the bottleneck whenever possible. However, this page explains some of the shaping options that exist and that we are working on. The fact that we have a usage based charging model means that more usage pays for additional costs so we can maintain this policy. The same is true within BT. We pay for usage, so BT can upgrade links as necessary to provide a quality service to us and hence you. Sadly BT don't always manage this very well. Equally, we can get caught out by some sporting events and the like. So the way shaping works is important.


Line 7: Line 7:
Whilst there is no shaping on uplink (other than what you may impose on your end with your own equipment), downlink does his shaping at the BRAS (Broadband Remote Access Server) within BT. This limits downlink traffic based on line speed. On 20CN circuits BT actually limit to some defined values (usually nearest Mb/s) and set the value below your line speed. On 21CN the rate is set based on the sync speed of your line each time you connect.
Whilst there is no shaping on uplink (other than what you may impose on your end with your own equipment), downlink does his shaping at the BRAS (Broadband Remote Access Server) within BT. This limits downlink traffic based on line speed. On 20CN circuits BT actually limit to some defined values (usually nearest Mb/s) and set the value below your line speed. On 21CN the rate is set based on the sync speed of your line each time you connect.


==Matching BRAS rate our end:==
==Matching BRAS rate our end==
We match the BRAS rate our end, limiting your line in the same way. This is in line with us not being the bottleneck as we set the rate the same as the BRAS. For 20CN, we even have a system to seamlessly change this rate without dropping your connection as soon as BT advise us of a BRAS rate change which can be hours after the line changes to a new sync speed. On 21CN the rate updates every time you connect.
We match the BRAS rate our end, limiting your line in the same way. This is in line with us not being the bottleneck as we set the rate the same as the BRAS. For 20CN, we even have a system to seamlessly change this rate without dropping your connection as soon as BT advise us of a BRAS rate change which can be hours after the line changes to a new sync speed. On 21CN the rate updates every time you connect.


We do this for two main reasons - (a) to allow load balancing if you have multiple lines - sending the right amounts of traffic to each line, and (b) handling attacks. If someone was to send, say, 500Mb/s to your line, we do not want 500Mb/s going to BT only to be thrown away by the BRAS - we limit the traffic we send to BT to what your line will take and so do not affect other customers if your line is attacked. We also use this as the benchmark for working out if you are being attacked so we can disconnect your line (talk to us on irc if you want more details on this). This limit also stops the discarded traffic in an attack counting against your chargeable usage.
We do this for two main reasons - (a) to allow load balancing if you have multiple lines - sending the right amounts of traffic to each line, and (b) handling attacks. If someone was to send, say, 500Mbit/s to your line, we do not want 500Mbit/s going to BT only to be thrown away by the BRAS - we limit the traffic we send to BT to what your line will take and so do not affect other customers if your line is attacked. We also use this as the benchmark for working out if you are being attacked so we can disconnect your line (talk to us on irc if you want more details on this). This limit also stops the discarded traffic in an attack counting against your chargeable usage.


We have options allowing users to set their line at a lower rate, e.g. 95% of BRAS. This is useful for things like VoIP as our shaper is smarter than BTs and allows small packets through more readily than large packets. Customers have tested VoIP on a 95% rate whilst running torrents and downloads and found it works well.
We have options allowing users to set their line at a lower rate, e.g. 95% of BRAS. This is useful for things like VoIP as our shaper is smarter than BTs and allows small packets through more readily than large packets. Customers have tested VoIP on a 95% rate whilst running torrents and downloads and found it works well.
Line 19: Line 19:
The link to BT has a rate limit for what we are buying from BT at present. The idea is that this has enough headroom for normal traffic so that we are not the bottleneck. As the usage increases we order more capacity from BT.
The link to BT has a rate limit for what we are buying from BT at present. The idea is that this has enough headroom for normal traffic so that we are not the bottleneck. As the usage increases we order more capacity from BT.


There can be exceptions. Cases like the tennis recently which lots of people watched on iplayer and so there was a massive increase in usage for a few hours during two afternoons. If we know this is happening, we could allow for it, but there are practical limits. The issue is that BT have a one week lead time on changing bandwidth. So, whilst we aim never to be the bottleneck, there may be the occasional unexpected exception like this. Even so, we try and ensure there is some headroom to allow for smaller events without any problem.
There can be exceptions. Cases like the tennis recently which lots of people watched on iplayer and so there was a massive increase in usage for a few hours during two afternoons. If we know this is happening, we could allow for it, but there are practical limits. The issue is that BT have a one-week lead time on changing bandwidth. So, whilst we aim never to be the bottleneck, there may be the occasional unexpected exception like this. Even so, we try and ensure there is some headroom to allow for smaller events without any problem.


The main thing is that we have means to monitor the load on each link to BT (separate for 20CN and 21CN) and see if we get caught out but such events and take action. Later in the year BT will be providing a burst option allowing some extra bandwidth at no notice but they too have some limitations.
The main thing is that we have means to monitor the load on each link to BT (separate for 20CN and 21CN) and see if we get caught out but such events and take action. Later in the year BT will be providing a burst option allowing some extra bandwidth at no notice but they too have some limitations.
Line 26: Line 26:
We use a simple system of shaping the overall traffic in to BT. This is where a burst of unusually high traffic fills our link to BT. The shaping applied means that smaller packets have a better chance of getting through than larger packets. In general this means VoIP carries on working but TCP slows down. An event like the tennis can mean only a few percent too much traffic, and losing a few percent of TCP throughput for a few hours whilst maintaining perfect VoIP is a good compromise while we wait for BT to provide more bandwidth.
We use a simple system of shaping the overall traffic in to BT. This is where a burst of unusually high traffic fills our link to BT. The shaping applied means that smaller packets have a better chance of getting through than larger packets. In general this means VoIP carries on working but TCP slows down. An event like the tennis can mean only a few percent too much traffic, and losing a few percent of TCP throughput for a few hours whilst maintaining perfect VoIP is a good compromise while we wait for BT to provide more bandwidth.


We have have also found that shaping traffic slightly below the BRAS rate (a customer controllable option) works well.
We have also found that shaping traffic slightly below the BRAS rate (a customer controllable option) works well.




[[Category:Technical_Documents]]
[[Category:Technical Documents]]

Latest revision as of 00:06, 15 March 2017

Firstly, it is important to realise that we don't have traffic shaping to slow down some protocols or users in order to manage traffic. Our policy is not to be the bottleneck whenever possible. However, this page explains some of the shaping options that exist and that we are working on. The fact that we have a usage based charging model means that more usage pays for additional costs so we can maintain this policy. The same is true within BT. We pay for usage, so BT can upgrade links as necessary to provide a quality service to us and hence you. Sadly BT don't always manage this very well. Equally, we can get caught out by some sporting events and the like. So the way shaping works is important.

Line speed and BRAS

The primary bottleneck for download and upload is your line rate. In many cases this is the only bottleneck. The next most common is the other end of your communications, e.g. web site.

Whilst there is no shaping on uplink (other than what you may impose on your end with your own equipment), downlink does his shaping at the BRAS (Broadband Remote Access Server) within BT. This limits downlink traffic based on line speed. On 20CN circuits BT actually limit to some defined values (usually nearest Mb/s) and set the value below your line speed. On 21CN the rate is set based on the sync speed of your line each time you connect.

Matching BRAS rate our end

We match the BRAS rate our end, limiting your line in the same way. This is in line with us not being the bottleneck as we set the rate the same as the BRAS. For 20CN, we even have a system to seamlessly change this rate without dropping your connection as soon as BT advise us of a BRAS rate change which can be hours after the line changes to a new sync speed. On 21CN the rate updates every time you connect.

We do this for two main reasons - (a) to allow load balancing if you have multiple lines - sending the right amounts of traffic to each line, and (b) handling attacks. If someone was to send, say, 500Mbit/s to your line, we do not want 500Mbit/s going to BT only to be thrown away by the BRAS - we limit the traffic we send to BT to what your line will take and so do not affect other customers if your line is attacked. We also use this as the benchmark for working out if you are being attacked so we can disconnect your line (talk to us on irc if you want more details on this). This limit also stops the discarded traffic in an attack counting against your chargeable usage.

We have options allowing users to set their line at a lower rate, e.g. 95% of BRAS. This is useful for things like VoIP as our shaper is smarter than BTs and allows small packets through more readily than large packets. Customers have tested VoIP on a 95% rate whilst running torrents and downloads and found it works well.

WBMC rate limiting

Once the traffic gets to us there is another possible bottleneck which is the link between BT and us. Fortunately this is something we can change.

The link to BT has a rate limit for what we are buying from BT at present. The idea is that this has enough headroom for normal traffic so that we are not the bottleneck. As the usage increases we order more capacity from BT.

There can be exceptions. Cases like the tennis recently which lots of people watched on iplayer and so there was a massive increase in usage for a few hours during two afternoons. If we know this is happening, we could allow for it, but there are practical limits. The issue is that BT have a one-week lead time on changing bandwidth. So, whilst we aim never to be the bottleneck, there may be the occasional unexpected exception like this. Even so, we try and ensure there is some headroom to allow for smaller events without any problem.

The main thing is that we have means to monitor the load on each link to BT (separate for 20CN and 21CN) and see if we get caught out but such events and take action. Later in the year BT will be providing a burst option allowing some extra bandwidth at no notice but they too have some limitations.

Priority traffic

We use a simple system of shaping the overall traffic in to BT. This is where a burst of unusually high traffic fills our link to BT. The shaping applied means that smaller packets have a better chance of getting through than larger packets. In general this means VoIP carries on working but TCP slows down. An event like the tennis can mean only a few percent too much traffic, and losing a few percent of TCP throughput for a few hours whilst maintaining perfect VoIP is a good compromise while we wait for BT to provide more bandwidth.

We have also found that shaping traffic slightly below the BRAS rate (a customer controllable option) works well.