QoS FAQs
DSL is the most cost-effective access technology and is now widely available across the UK. Until recently the use of DSL within services was inhibited by the inability to run QoS across the IP Stream network. NetServices innovations in this area mean this is no longer the case.
- Products and Markets
What is QoS?
Why is it important?
What is QoS DSL- IPStream?
How does this technology apply to business?
IPStream is not suitable for voice?
We are running voice over IPStream. Do you really need QoS for convergence?
In what scenarios would you utilise QoS DSL technologies?
What products do NetServices sell that use QoS IPStream?
How do NetServices take these products to market?
Who are we NOT aiming this at?
How much does it cost?
How do NetServices support and manage the services based on QoS DSL?
What is the standard SLA?
- Technical
BTs IPStream doesn't support QoS therefore how can you provide a QoS DSL - IPStream service?
Only DataStream and LLU can offer non-contended DSL?
Can you bond QoS DSL circuits to increase bandwidth?
If IPStream is provided at contention ratios of 20:1 or 50:1 how can a twentieth of 800kb/s provide a suitable level of service?
What QoS DSL IPStream options are available? What limitations are there?
What sizes of queue can be configurabled?
Why does the converged option have a reduced downstream speed to the data only option?
Does the fact that Link Fragmentation and Interleaving is not supported mean that a converged solution will not work?
QoS DSL Services are only available at a limited number of exchanges.
Products and Markets
What is QoS?
Quality of Service, commonly referred to as QoS, is the ability to give priority to certain packets to ensure they cross the network in an
optimum manner. QoS is vital in allowing uninterrupted travel of voice packets across the network, in effect QoS provides a bus route and a
'right of way' to the identified traffic. Several 'classes of services' (bus lanes) can be applied to each circuit and different precedences set so
that different priorities can be allocated on different packets.
[Top]
Why is it important?
All information being transferred across network travels in packets. The order the packets travel through the network is not important for data
- as long as they reassemble themselves correctly on arrival. Voice packets need to be delivered sequentially in order for the voice quality to
be maintained. Any interruption to the flow of voice traffic, e.g. data packets competing for bandwidth, results in a broken sounding poor
quality reception of the call.
QoS is the ability to differentiate traffic types and the capability to set varied priorities on different applications so that the voice / real-time
application / prioritised traffic gets precedence - a 'right-of-way' - in crossing the network.
[Top]
What is QoS DSL- IPStream?
QoS IPStream is the ability to prioritise traffic across the IPStream network. BT operate two networks that support DSL delivery in the UK
- IPStream and DataStream. DataStream offers non-contended services i.e. as 1:1 guaranteed bandwidth, whereas IPStream is contended
network. NetServices can now guarantee that priority is given to the most appropriate traffic across the network.
[Top]
How does this technology apply to business?
QoS IPStream is an access technology that enables converged services to be delivered across one line whilst assigning the appropriate
priorities to the traffic i.e. high to voice and lower to non-essential data traffic. The same result could be achieved by other technologies e.g.
a leased line - however this is vastly more expensive. What QoS IPStream enables is the delivery of a converged solutions and thus business
quality voice (BQV) to locations where previously it would not have been cost-effective to do so. This includes very small businesses,remote or
branch offices as well as teleworkers.
[ Top]
IPStream is not suitable for voice?
Thousands of end-users use IPStream for small number of simultaneous voice calls with no problems at all. However business voice
quality is not available when using IPStream in a converged scenario without the implementation of QoS. This is because without a method of
downstream QoS there is no means of differentiating between voice and data packets in the downstream direction so a large data transfer can
affect voice quality.
A simple workaround for this problem has been to implement a separate IPStream line for voice and a separate IPStream line for data.
[ Top]
We are running voice over IPStream. Do you really need QoS for convergence?
Yes, QoS is required if voice traffic is competing with other applications for bandwidth i.e. in a converged scenario. Traditionally QoS has been
implemented on the outbound CPE interface in the upstream direction on IPStream circuits, although the configuration of QoS in the
downstream direction has not been possible.
A result of this limitation is that the user experience is inconsistent, especially when running a real-time data applications across the service.
For example when making a voice call, speech quality may be acceptable for a long period. This is until a large data file starts downloading
simultaneously with the traffic from a voice call. With no downstream QoS available, voice and data traffic are competing for bandwidth. This
frequently results in jitter, delay and packet loss which ultimately causes speech quality to be detrimentally affected.
[Top]
In what scenarios would you utilise QoS DSL technologies?
- QoS DSL networks are ideal solutions for the retail industry e.g. making a converged network for voice and ePoS feasible for even
small outlets.
- Business voice quality can be delivered to remote workers, alongside their data applications, the QoS feature ensuring that call quality is not
spoiled by simultaneous data transfer.
- Short lead times and reduced contract terms means that transient sites can be serviced e.g. construction and leisure industry.
- QoS DSL networks allows businesses to extend existing applications to sites previously excluded from the current WAN on cost grounds. e.g. extending Cisco Call Manager to remote sites and teleworkers.
- Businesses using applications such as Citrix can now roll these applications out to branch sites across a cost-effective network.
- Where leased line and Ethernet coverage is not available or wouldn't be available within the timescales of an implementation project, QoS DSL technologies form a viable alternative.
[ Top]
What products do NetServices sell that use QoS IPStream?
QoS in itself is not a product - it is an access technology included in a number of services we provide to our customers and partners.
QoS IP Stream is used as the basis of the NetTalk and is available as an access technology for branch site etc within the
Enterprise Voice4IP.
QoS IPStream also forms the basis of the QoS IPStream VPN (cryptic naming policies not being our style!). It is important to note this is an
access technology forming part of a WAN not a product that is sold on a per tail basis. This is a managed solution - i.e. the routers are
configured and ongoing management is part of the service.
The QoS IPStream capability can also be included within a Managed MPLS VPN solution where, in effect, it is just another access technology
used as part of that overall solution in the same way as a leased lines or Ethernet circuit.
[ Top]
How do NetServices take these products to market?
The products are aimed at direct business and partners operating as Systems Integrators or managed service providers, e.g.
Cisco Gold Partners.
NetTalk is a small business solution primarily sold through our channel partners, Enterprise Voice4IP is sold direct and through partners.
QoS IPStream WAN is appropriate in a number of scenarios. Some of our partners have large corporate clients that they already provide and
manage a WAN for. They may now wish to extend this WAN to include branch offices or home workers that previously operated outside the
main VPN. It can also be applied in the retail, leisure or construction industries as previously mentioned, where in the past it would not have
been cost effective to consider a converged WAN. The service can run alongside an existing MPLS WAN which may be provisioned by either
NetServices on a wires only basis or by another provider. This QoS IPStream WAN always includes the CPE which must be managed by us in
order to deliver the QoS capability.
Managed MPLS VPN is most appropriate when dealing with direct clients. Here QoS can be included as just another access technology as we
are managing all the CPE and connectivity involved.
[ Top]
Who are we NOT aiming this at?
QoS IPStream in itself is not a product - it is an access technology included in a number of services we provide to our customers
and partners.
NetServices are not selling QoS tails on a wholesale basis as our Managed User and Managed Capacity services have been withdrawn
following the sale of the wholesale business. Opportunities for this type of provisioning may be considered. Any opportunities would need priced
on application.
[ Top]
How much does it cost?
QoS DSL-IPStream is costed as part of the relevant service, QoS IPStream VPN, MPLS VPN in the same manner as other access technologies
using NetConfigurator where it is titled as QoS DSL IPStream etc. Non-productised applications of the technology such as handover services
are priced on an per opportunity basis.
[Top]
How do NetServices support and manage the services based on QoS DSL?
The CPE is managed by NetServices. In instances of a fault developing NetServices arrange for onsite-hardware diagnosis and will replace the
device if necessary. The hours of coverage for the hardware maintenance as are defined in the appropriate products and details are found in
the Product Sheets and in more detail in the Service Descriptions.
Connectivity support is provided under the BT Standard Care service. This is a 'best efforts' service and service level agreements are restricted
by the limitations of the access circuits with a committed fix of 40 working hours.
The target fault resolution time for QoS IPStream access circuits is 40 hours. BT's Broadband Enhanced Care provides extended hours support
for DSL circuits allowing NetServices to request BT investigate suspected DSL line faults on a 24 x 7 basis. For maximum protection, the
underlying PSTN circuit should also be covered by BT's Total Care service offering. The target fault resolution time is sub 24 hours when the
Enhanced Care option is taken.
For customers having taken the options of Enhanced Care and BT Total Care the target uptime is 99.5%. This figure exceeds the availability
figure provided by BT (98%), but reflects the nature of service that NetServices are receiving.
[Top]
What is the standard SLA?
The SLA is based on a standard MPLS VPN at a solution level. The T-SLA for QoS DSL provides the SLA for the access circuit.
[ Top]
Technical
BTs IPStream doesn't support QoS therefore how can you provide a QoS DSL - IPStream service?
Traditionally the BT IPStream network did not support end-to-end QoS. The BT IPStream Advanced Services feature "Downstream Quality of Service" was introduced in 2006 but only provides QoS in a downstream direction which is charged on a per session basis rather than being consistently applied.
The downstream Quality of Service product over ADSL has a number of limitations that make it unsuitable for the delivery of business voice quality. Most notably it is a session based product and so QoS enabled bandwidth has to be booked and paid for on a usage basis. Although this is may be suitable for applications such as video conferencing itis not a credible solution for an IP Telephony roll-out.
QoS can be provided across any access technology providing that the fundamental building block required for implementation - a guaranteed amount of bandwidth permanently available - is in place. The performance for contended IPStream Max products is defined in terms of 'end-user experience' rather than "contention ratios". BT has stated that the minimum downstream IP throughput range for IPStream ADSL Max lines is 800kb/s.
Due to the asymmetric nature of the data traffic that utilises the IPStream network the downstream capacity of the network, far exceeds the upstream requirement. Therefore there is no congestion in the upstream direction and so QoS can be effectively implemented on the outbound CPE interface.The IPStream network is generally not congested and therefore the 'pinch points' in the network, where congestion can occur, are at the Central Pipe access connections into the IPStream network.
NetServices has harnessed the use of the Cisco feature "per session shaping and queuing over L2TP" to ensure that traffic classes are prioritised and reserved across its Central Pipe infrastructure. Therefore from the NetServices Central Pipe infrastructure through to the end-user CPE router, an 800kb/s channel is provisioned with QoS applied across it.
[ Top]
Only DataStream and LLU can offer non-contended DSL?
True, IPStream provides contended DSL connectivity only. Both DataStream and LLU products offer variable contention ratios, with non-contended services being available.
NetServices has an extensive QoS DSL-DataStream portfolio which can be used in circumstances where greater throughput rates, with a higher level of consistency than QoS DSL - IPStream services, are required.
[Top]
Can you bond QoS DSL circuits to increase bandwidth?
Yes, the use of MLPPP bonding is available to aggregate the sum of individual access circuits. This service is only available for QoS DSL-DataStream circuits.
Bonded QoS DSL circuits have the significant advantages in that they are available at all ADSL enabled exchanges and have a relatively short provisioning lead time.
[ Top]
If IPStream is provided at contention ratios of 20:1 or 50:1 how can a twentieth of 800kb/s provide a suitable level of service?
IPStream products were originally launched by BT, where end-user performance was defined in terms of "contention ratios". BT has now progressed to a situation where the performance for IPStream Max products is defined in terms of 'end-user experience' rather than "contention ratios".
The BT IPStream Max Handbook states that for the majority of the time that the downstream IP throughput range for DSL Lines rate adapting at a line rate above 2272kb/s up to 8128kb/s will be in the region of 800kb/s-7150kb/s. By choosing to deploy a QoS solution with a maximum downstream capability of 800kb/s NetServices are operating within the limits specified by BT.
[ Top]
What QoS DSL IPStream options are available? What limitations are there?
The data only option is available with a maximum downstream bandwidth of 2Mb/s, two queues are configurable (critical data and best efforts).
The converged option provides a maximum downstream limit of 800kb/s, three queues are available (real-time, critical data and best efforts).
Neither services support Link Fragmentation and Interleaving (LFI) or compressed real-time header compression (cRTP).
Services are subject to line quality and the standard physical limitations associated with DSL technologies.
[ Top]
What sizes of queue can be configurabled?
Three standard options can be configured for the converged (real-time) options: size 50kb/s, 100kb/s and 150kb/s. The critical data queue is fixed at 300kb/s and the remaining bandwidth of 800kb/s is placed in the best efforts queue.
The user experience for each queue is as follows: real-time 1:1 equivalent, critical data 5:1 equivalent, best-efforts 20:1 equivalent.
It should be noted that the bandwidth for real-time queues is configured in segments of 50kb/s rather than 40kb/s. Although the bandwidth consumed by the implementation of the G729 codec is approximately 40kb/s, it is appropriate to ensure that there is additional bandwidth available. This is because low latency queuing is implemented for real-time traffic and if the bandwidth destined for the queue exceeds its configured size the excess bandwidth is discarded resulting in voice quality issues.
For the data-only service there is no real-time queue option . There are four standard options of critical data queue size, 500kb/s, 1Mb/s, 1.5Mb/s and 2Mb/s, the remaining bandwidth to 2Mb/s is placed in the best efforts queue.
NetServcies have the ability to configure real-time queue sizes up to 320kb/s though any opportunities with this requirement are assessed by both pre-sales and network engineering.
[ Top]
Why does the converged option have a reduced downstream speed to the data only option?
The difference in size between these offerings reflects the best efforts nature of the BT IPStream network. Non real time data traffic is more tolerant to bursts of congestion in comparison to real-time traffic.
[Top]
Does the fact that Link Fragmentation and Interleaving is not supported mean that a converged solution will not work?
No. To avoid serialisation delay impacting upon the voice budget, LFI is traditionally applied slow speed access circuits. Large data packets are segmented into smaller pieces and then voice circuits inserted in between them to ensure delay does not occur.
Cisco state the acceptable voice delay budget at 200ms, therefore the impact of serialisation delay must be considered with ADSL connectivity. NetServices only uses ADSL MAX tail access circuits for QoS DSL - IPStream, therefore the upstream achievable bandwidth is approximately 800kb/s.
Therefore with bandwidth available of 800kb/s, and assuming that an IP packet is at the maximum size with an MTU of 1500 bytes. The serialisation delay will be approximately 15ms. This figure is small enough to not impact significantly on the voice delay budget assuming that a 20ms sampling rate is used.
[Top]
QoS DSL Services are only available at a limited number of exchanges.
False, QoS DSL DataStream and IPStream services are available at all BT ADSL enabled exchanges (subject to DSLAM port capacity).
[ Top]