Chat with us, powered by LiveChat

Do You Really Need Quality of Service?

Quality of service (QoS) is the overall performance of a telephony or computer network, particularly the performance seen by the users of the network.

Above is the Quality of Service definition from the Wikipedia. Performance metrics can be bandwidth, delay, jitter, pocket loss and so on.

Two Quality Of Service approaches have been defined by the standard organisations. Namely Intserv (Integrated Services) and Diffserv (Differentiated Services).

In this post I will not explain each method or special tools used in each method. Instead, which method makes sense in particular design and which Quality of Service Tools can solve user needs without compromising the network design goals.

Intserv was demanding each and every flow to request a bandwidth from the network and network would reserve the required bandwidth for the user during a conversation. Think this is an on demand circuit switching, each flows of each user would be remembered by the network. This clearly would create a resource problem (CPU, Memory , Bandwidth) on the network thus never widely adopted.

Although with RSVP-TE ( RSVP Traffic Engineering ) particular LSP can ask a bandwidth from the network nodes, and in turn nodes reserve a bandwidth, number of LSP between the Edge nodes of the network is order of magnitude less than individual flows of the users.

The second Quality of Service Approach is Diffserv (Differentiated Services) doesn’t require reservation but instead flows are aggregated and place into the classes. Then each and every node can be controlled by the network operator to treat differently for the aggregated flows.

Obviously it can be scalable compare to the Intserv Quality of Service model.

When you practice Quality of Service, you learn Classification, Marking, Queueing, Policing, Shaping tools.

And you are also told that in order to have best Quality Of Service for the user, you need to deploy it end to end.

But where are those ends ?

The name of the nodes might differ based on business. In Enterprise campus, your access switch is one end and the branch router, datacenter virtual or physical access switches, internet gateways might be the other end.

Or in the Service Provider business, Provider Edge router is one end, other provider edge router,datacenter virtual or physical access, internet gateways, service access devices such as DSLAM, CMTS devices might be other end.

So end to end principle will fail since the end to end domain might be too broad and too much devices to manage.

But definitely some tools make sense in some place in some networks.

For example ” Policing ” in the Service Provider Networks. It can be used for the billing purpose. Provider can drop the excess usage or charge for the premium service.

Policing is deployed together with classification/marking but you don’t need to deploy QoS tools on the other nodes so those classification and marking will be locally make sense. This tool is also used for the Call Admission Control purpose.

Imagine you have 200Mb links and each Telepresence flow requires 45mb traffic. You can place 4 calls onto the link. If 5th call is setup, all other 4 calls suffer as well since packets has to be dropped. ( 45 * 5 – 200 – buffer size)

Another Quality of Service tools is Queueing; and in particular it is used whenever there is an oversubscription. Oversubscription can be between the nodes ( On the links ) or within the nodes.

If the congestion is within the node, queueing in the ingress direction is applied to protect some traffic (maybe real time ) from the Head of Line Blocking in the switching fabric of the node. Or in the egress direction between the nodes to protect selective traffic.

The problem is if there is enough traffic, buffers ( queue ) will get full and eventually all the traffic will be dropped no matter what queueing method ( LLQ, WFQ, CBWFW ) is used.

So if you try to design end to end Quality of Service by enable queueing to cover all possible oversubscription in the network you fail.

When the congestion happens, some flows will just die couple milliseconds after another.

The design tradeoff here is to add more bandwidth vs engineering all possible congestion points. I am not talking only the initial QoS design phase but the complexity brought by the QoS in the design as well.Netwok Operator need to manage, understand,troubleshoot QoS during steady state and in the case of failure as well.

Bandwidth is getting cheaper and cheaper everyday but the complexity of Quality of Service will stay there forever.

Leave a Comment

Your email address will not be published. Required fields are marked *

Powered by WishList Member - Membership Software