6.0 CRITICAL ASSESSMENT OF THE EXISTENT QOS TECHNOLOGIES

6.1 Over-provisioning

Over-provisioning hardly guarantees compliance with many pre-defined QoS parameters, especially since not every router along the path treats time-sensitive applications IP packets as well as best effort applications in a similar manner. Some routers may simply not prioritize real time application data on the queues, and owing to the lack of mechanisms such as congestion control and flow control in TCP-based applications that are nearly arbitrarily and completely disrupt competing packet flows and UDP applications can easily flood the network resources, Chiu, Huang, Lo, Hwang, & Shieh (2003). Effectively, the TCP-based applications are suppressed as well as other competing applications. The dynamicity of any IP traffic is founded on the high-variance of QoS parameters and this can never be met through the over-provisioning of resources. Owing to the fact that multimedia traffic comprises the vast majority of internet traffic, coupled by the fact that video, voice, audio and other real time traffic is what comprises high priority traffic, over-provisioning eliminates the need for complex technologies to handle a minority of data flows at limited times, Martinez, Apostolopoulos, Alfaro, Sanchez, & Duato (2010). Intricate systems struggle with capacity issues and increments in capacity of a single link results in the reduction in the capacity of a different link. The eases in traffic can only result in further bottlenecks in other links, which makes over-provisioning an effective solution in the elimination of all bottlenecks.

 Over-provisioning is a simple solution, which however presents a technical challenges regarding load sharing among parallel-operating components. The massive costs associated for the resources that are under-utilized remains the most important disadvantage, coupled by the practicality of this option in the management of congestion management as well as assurance of quality for both video and other traffic over the internet, Chiu, Huang, Lo, Hwang, & Shieh (2003). Effectively, over-provisioning is a short term solution that is poorly scalable and inefficient in terms of costs. Instead of over-provisioning, quality of service technologies are the only way of assuring the quality and efficiency of video traffic over the internet, IXIA (2011).

The inefficiency of simple over-provisioning is both in absolute as well as because of the high variances in the network traffic. Networks are usually designed to accommodate all traffic even at the highest peak times, while traffic management technologies including DiffServ being employed to maintain quality and avert possible collapse by barring out least priority traffic during peaks, Martinez, Apostolopoulos, Alfaro, Sanchez, & Duato (2010). In addition, the design of Transmission control platform, which is the internets most primary protocol, makes it impossible to define what peak traffic is. TCP protocols progressively require greater network resources with the decrease in the rate of losses, which in turn leads to different connections utilizing as much resources as is necessary up until the transmissions are exhausted. QoS technologies allow the quality of the transmitted data to remain high through transient spikes in the network resources utilizations, Dar & Latif (2010). Given the fact that it is impossible to sufficiently over-provision resources for such times without massively increasing the cost inefficiency of the architecture, these technologies are indispensable in not only maintaining quality, but perhaps most critically, in ensuring the overall efficiency of transmission of traffic over the internet, Ergin, Gruteser, Luo, Raychaudhuri & Liu (2008).

6.2 IntServ and DiffServ

Whenever the additional capacity is exhausted under over-provisioning or any other technology, delays are inevitable. Delays are a major consideration in the delivery of quality-of-service for video, voice and other real time traffic, which in turn necessitates that they are routed along paths that ensure the least possible delays. Multiple QoS technologies discussed in this paper allow for the prioritization of internet traffic through the discrimination between real time and other forms of traffic, Martinez, Apostolopoulos, Alfaro, Sanchez, & Duato (2010). IntServ and DiffServ represent efforts by the IETF to offer separate architectures for the network layer, which assign varying priorities to different data flows. IntServ provides for fine granular and arbitrary requirements for QoS parameters. IntServ is heavily reliant on the resource reservation protocols in the signaling as well as reservation of the required QoS for each individual flows over a network. Flows are defined as separate, unidirectional data streams between one or more applications that can be uniquely identified by use of 5 tuple. Up to two separate types of services may be requested through the RSVP if only all the network resources along the transmission path support RSVP, Hentschel, Reinder, & Yiirgwei (2002).

The two types of services include the strictly guaranteed service, which offers strong bounds on end-to-end delays and assured bandwidths for all traffics that are according to certain predetermined specifications. Secondly, IntServ provides controlled load services that offer better than best effort as well as low delays in service when the networks have moderate loads. This technology can provide the necessary quality-of-service for all flows over a network as long as RSVP signaling is possible, Bhakta, Chakrabory, Mitra, Sanyal, Chattopadhyay, & Chattopadhyay (2011). IntServ however faces multiple disadvantages. These include the fact that all devices along the packets path, including end systems e.g. personal computers and servers must be completely aware of the RSVP, besides being able of signaling the necessary QoS. In addition, reservation of network resources in every device across the transmission path is soft, which effectively implies that the devices must be refreshed on a regular basis, which adds on the network traffic, while at once increasing the chance that reservations may be time out if packets are lost on refresh, Ferguson & Huston (1998). Maintenance of soft-states in every router coupled by the admission control at all hops and heightened memory needs to support a huge number of resource reservations adds to the intricacy of every network node across the path. A further difficulty arises from the fact that since all routers must maintain the information about the state of reservations across the transmission path, the scalability with potentially millions of lows across the core becomes a huge problem, Bhakta, Chakrabory, Mitra, Sanyal, Chattopadhyay, & Chattopadhyay (2011).

6.3 DiffServ Solves Over-provisioning & IntServ Difficulties

There are other QoS mechanisms introduced by the IETF and the Union for Telecommunications had introduced protocols such as the Asynchronous Transfer Mode Forum as well as the Frame Relay Forum, which helped in the establishment of Layer2 QoS standards. These define a wealth of QoS infrastructures that support traffic contracts; allowing QoS knobs that are adjustable as well as signaling and connection admission controls. Frame relays offer simple and rich mechanisms to allow for committed information rate, frame relay fragmentation and congestion notification, Akyildiza, Anjalia, Chena, de Oliveiraa, & Scoglioa (2003). Service providers offer IP services and Frame-relay/ATM allow resilient QoS frameworks to users. Mapping of layer3 to layer2 QoS is the initial stage that helps the achievement of a viable QoS solution that is independent of particular layer2 technologies. DiffServ and IntServ technologies may be implemented over Frame relay, ATM and other QoS-sensitive transports. Viable end-to-end QoS alternatives must comprise of layer3 and layer2 QoS. In addition, these frameworks are independent of the media, Gheorghe (2006).

DiffServ allows policing as well as traffic classification to occur at the DiffServ domain boundaries, effectively allowing routers on the network to be unaffected by the intricacies of service level and payment agreement enforcements, Hentschel, Reinder, & Yiirgwei (2002). In this manner, DiffServ has an advantage over IntServ, not least because it does not necessitate advance set up, but also because it does not necessitate resource reservations and time-consuming end-to-end negotiations for individual flows. In addition, DiffServ architecture is best suited in mesh mode as compared to IntServ, which implies that DiffServ may be used in the design of routing metrics that does take multiple network delays, Jaffar, Hashim, & Hamzah (2009).

However, the detail of how routers handle the Differentiated Services fields is determined by the configuration, which in turn makes the prediction of end-to-end behavior extremely difficult. Further complications arise in the event flows cross multiple DiffServ domains prior to reaching the destination, because every DiffServ domain presents with similar difficulties in the prediction of end-to-end behavior, which are subsequently multiplied as the data packets go across multiple domains, Wang, Mai, Magnussen, Xuan, & Zhao (2009). Commercially, the inability to predict the flow behavior is a critical flaw, which renders it just as difficult to sell separate classes of end-to-end connections to end service users since a single providers bronze package may be anothers gold package. While DiffServ provides for increased scalability as well as coarse-grained quality-of-service across the network, it remains a complex framework. Unlike IntServ or RSVP, DiffServ technologies necessitate provisioning or the setting up of multiple classes of flows across the network, which needs knowledge of the nature of applications as well as traffic statistics for traffic aggregates, Wang (2001).

The application discovery process and profiling takes a considerable time even with the use of tool such as NBAR application discovery, remote monitoring and protocol analyzers, Ergin, Gruteser, Luo, Raychaudhuri, & Liu (2008). This may be solved through the enforcement of standardized policies on all networks. IP-based QoS marking technologies including DiffServ do not assure quality of service or even specified SLAs. The marking requires that senders indicate that they require packets to be treated in certain ways and hope that they are ultimately treated as such, Ferguson & Huston (1998).

The problems of ensuring per flow QoS associated with IntServ may also be solved with DiffServ, without the additional costs, scalability constraints and complexity. This is achieved through the classification of flows into aggregates, while at once offering adequate QoS for the aggregates. The TCP flows for instance can be grouped into one class to which adequate network resources can be allocated as against making similar allocations for individual flows among millions, Martinez, Apostolopoulos, Alfaro, Sanchez, & Duato (2010). The state maintenance and signaling needs on the network nodes are kept to the minimum.

The service providers subsequently determine using the routers along the packets route the nature of the treatment to be accorded to the varied flows. In addition, the problems addressed by DiffServ are inexistent where over-provisioning, Jaffar, Hashim, & Hamzah, (2009). DiffServ is a mechanism that decides to route or deliver at the expense of other packets in the event of resource constraints. DiffServ works by dropping some packets in a selective way and thus increases in traffic causes services that are of low priority to be dropped altogether especially if the normal traffic is close to or in excess of the saturation point. Further increases in the number of traffic result in very poor QoS, Roberts (2001). There are multiple intricate factors that the available bandwidth resources planning difficult. These include the fact that low priority traffic being dropped can be averted if the network resources being provisioned to guarantee the minimum bandwidth to the least priority traffic. Careful planning will help avert losses of priority traffic as well as eliminating the need for traffic prioritization mechanisms such as DiffServ, Ergin, Gruteser, Luo, Raychaudhuri, & Liu (2008).

The technical issues associated with resource reservation as well as accounting for the prioritized traffic for billing purposes remain the most important disadvantages that have prevented large-scale deployment of traffic prioritization architecture. Monitoring and billing of flows remains a challenge, Hentschel, Reinder, & Yiirgwei (2002). The packets per second or bytes per second etc can be used in management information base-based classes with a degree of efficiency, but they are insufficient. It is impossible to prove that 10 million audio/video packets were accorded priority treatment across the network, especially since even customers realize that the quality of their service was less than perfect in some instances.

The loss in granularity is yet another disadvantage associated with DiffServ. QoS assurances are conventionally given at a class level, despite the fact that it is necessary to go down to the flow level to offer the required QoS, Akyildiza, Anjalia, Chena, de Oliveiraa, & Scoglioa (2003). Attempting to do this will result in the emergence of the problems associated with IntServ altogether. While all HTTP traffics can be classified into varied packages, coupled by the assignment of bandwidths respectively, without a per flow approach, it is not possible to guarantee that the entire bandwidth that is allocated is not exhausted by a single flow out of 10 million different flows in the same class. It is equally difficult to make certain that the manufacturing department HTTP flows are accorded greater priority to other departments. Other than this, there are challenges associated with routing too. The most important challenges for both DiffServ and IntServ frameworks is that provisioning as well as signaling does happen independent of the routing process, IXIA (2011). Effectively, it is possible that paths other than the Non-default Interior Gateway Protocol e.g. EIGRP and OSPF or the Exterior Gateway Protocol in the network, which have the requisite resources regardless of whether DiffServ or RSVP fail to find the resources.

6.4 MPLS

The Multi-protocol Label Switching has made tremendous progress in the past decade to become a mainstream deployment in multiple networks across the world. Technical and practical challenges have increased with the rising adoption of the protocol. MPLS comprises a wide range of applications and functionality and thus its implementation includes a considerable level of complexity. The vendors that develop MPLS technologies and client organizations struggle with the fact that MPLS technologies are continually evolve with significant network performance as well as scalability, Liebehetrr, Patek, & Yilmaz (2000). In addition, MPLS is hardly a stand-alone technology rather; it is overlaid on layer2 technologies including ATM or Ethernet that must operate along with control plane protocols. The intricacy of deploying MPLS, especially when it is constantly changing increases with the interaction with other protocols. In a minority of cases, upwards of four protocols can be used, effectively necessitating close coordination as well as validations of the end-to-end systems, Bhakta, Chakrabory, Mitra, Sanyal, Chattopadhyay, & Chattopadhyay (2011). The integration of legacy services as well as the deployment of novel services including VPNs need tunneling that comes with increased set up requirements.

The primary goals for MPLS technology have changed, with the new developments in technology rendering the previous offerings. The moving target due to the dynamic MPLS necessitates that vendors have to decide between the implementation of new features or hold on to old ones, Chakraborty, Sanyal, Chakraborty, Ghosh, Chattopadhyay, & Chattopadhyay (2010). The service providers are saddled with the need to determine the long term viability of a specific MPLS technology depending on their respective ability to handle a given problem. The industry has pretty much been divided into several camps but all are faced with the risk of possible disruptions and possible obsolescence. The ability of MPLS to be interoperability on heterogeneous networks is a critical matter that needs to be addressed if the full advantages of MPLS must be realized. The convergence of networks must capably handle the overheads of prioritized and real time traffic, Cao, Ma, Zhang, Wang, & Zhu (2005). Meshed connections necessitated by VPN deployments easily challenge the scalability constraints of equipment, while at once meeting the management and provisioning requirements.

The drive towards increased adoption of MPLS has been driven by clear advantages that the protocol offers. These include the fact that it increases packet-forwarding performance across a network, especially through the increased flexibility of handling packets. In addition, Multi-protocol Label Switching capably supports quality-of-service for service differentiation, which effectively increases the throughput of both the real time traffic as well as normal traffic. In addition, the very nature of label switching effectively implies that the technologies can be easily scaled up with the growing demand or even the changes in the MPLS technologies. Other advantages derive from the fact that integration with ATM and IP in the network is flawless besides the ability to accommodate interoperable networks, Bhaniramka, Sun, & Jain (2009).

The disadvantages of MPLS include the facts that it necessitates additional layers of QoS in order to be functional and equally crucially, all the routers across the network must be capable of understanding MPLS. If it is impossible to guarantee that routers across the network cannot understand MPLS, then the implementation of the protocol would fail, especially since multiple innovations are bound to change the technology as well as interactions with hardware almost completely. According to Bhaniramka, Sun, & Jain (2009), MPLS represents a strategically crucial, traffic engineering technique, especially because of its potential to offer the best of the functionality that is available from an overlay model in a manner that is integrated without significant cost implications. It reduces the need for router processing, which adds to the speed, while at once providing an adequate amount of security to render IP secure in the same way as Frame Relay in WAN. It reduces the requirement for encryption on the IP networks. Further MPLS allow single converged networks for legacy and new services that create efficient migration paths to IP-based infrastructure. This protocol operates on new infrastructure 100/1000/10G Ethernet and legacy SONET or DS3 as well as ATM and Frame Relay networks, Chakraborty, Sanyal, Chakraborty, Ghosh, Chattopadhyay, & Chattopadhyay (2010).

6.5 Queue Management and Scheduling

It is clear TCP mechanisms for congestion avoidance and scheduling are critical in ensuring that priority flows are not delayed than is necessary to ensure quality, while at once ensuring that they are not dropped. The choice of the specific mechanism to use is dependent on the specific need and available resources, Cao, Ma, Zhang, Wang, & Zhu (2005). They control latency of the application traffic and set priorities of one application against others. These technologies include admission control, traffic policing and However, a greater focus should be targeted towards the reservation of resources in order to do away with the need for dropping packets. Congestion management serves to minimize the disruption of prioritized, real time traffic at the expense of normal traffic, which effectively makes it a stopgap measure as against a lasting solution, Martinez, Apostolopoulos, Alfaro, Sanchez, & Duato (2010). Video and audio traffic online is online is only efficient if it is delivered at the necessary quality, without affecting normal traffic. 

Choosing between traffic shaping and policing have important implications on QoS and efficiency. While these perform a similar role, there are clear similarities and differences that should facilitate the choice between them, Chakraborty, Sanyal, Chakraborty, Ghosh, Chattopadhyay, & Chattopadhyay (2010). To begin with, while the shaping seeks to queue and buffer additional packets above the rates committed, traffic policing drops any additional packets. In addition, traffic shaping increments token refresh rates at the beginning of the time interval while token values are configured bits for every second as compared to policing refreshes tokens as continuous with token values being configured in bytes. The configuration options for traffic shaping include frame relay traffic shape commands that implement frame relay shaping; traffic shape commands that implement generic shaping and shape commands within the modular QoS command line interface, Roberts (2001).

This technology is not applicable on inbound traffic and controls traffic bursts by smoothing the rate of output over eight intervals using the leaky/token bucket technologies. Its advantages include the fact that the technology is less likely to drop packets because additional packets are held in a buffer with retransmissions being generally avoided, Gheorghe (2006). The disadvantages include the introduction of delays when there are heavy queues and do not have optional packet remarking. Traffic policing is applicable on both inbound and outbound traffic, propagates traffic bursts and controls the rates of output by dropping packets that effectively averts delays resulting from queues. The major disadvantage associated with traffic policing include the fact that dropping excess packets, throttling TCP windows size and cutting back the overall rates of output of the traffic streams affected. Excess traffic will render the methodology effectively useless in ensuring effective QoS, Liebehetrr, Patek, & Yilmaz (2000). Effectively, the choice between the two technologies depends on the specific QoS objectives and needs of an organization. However, traffic shaping is gives better QoS, while policing ensures greater robustness in the face of excess traffic.

6.6 Routing, Policy Control and Data Path Mechanisms

The implementation of policy founded routing on networks has multiple advantages, including the fact that service providers as well as other organizations may use policy-based routing to handle traffic from multiple sources across multiple internet connections and policy routers, Bhakta, Chakrabory, Mitra, Sanyal, Chattopadhyay, & Chattopadhyay (2011). In addition, organizations may offer differentiated services QoS through the establishment of the type of service or precedence values within the IP packet headers, rights at the network periphery, while at once leveraging multiple queuing mechanisms to ensure traffic prioritization. There are also massive cost savings through the distribution of interactive and batch traffic among multiple low bandwidth and cheap, lasting paths as well as high-bandwidth.