IP QoS and Differentiated IP Services for Research and Development Community

8/8/2019 IP QoS and Differentiated IP Services for Research and Development Community

http://slidepdf.com/reader/full/ip-qos-and-differentiated-ip-services-for-research-and-development-community 1/16

1

Technology Project Abstract

“IP QoS and Differentiated IP Services for Research andDevelopment Community”

By: Emery James Baker MS, MBA

December 15, 2009



2

Table of Contents

ContentsDecember 15, 2009 ................................................................................................................................................................. 1

Introduction ............................................................................................................................................................................ 3

IP QoS for Research and Development Community. ............................................................................ 3

Business Issue ......................................................................................................................................................................... 3

Technology Overview .............................................................................................................................................................. 5

PHB Development ........................................................................................................................................................... 5

Classification & Packet Marking ................................................................................................................ 7Rate Limiting ............................................................................................................................................. 8Queuing (LLQ) ........................................................................................................................................... 9Drop Mechanisms - WRED ...................................................................................................................... 10End to End QoS ....................................................................................................................................... 11

Pharmaceutical Application .................................................................................................................................................. 11

Risks ........................................................................................................................................................ 11Cost Impacts. ........................................................................................................................................... 11

Implantation & Deployment Planning .................................................................................................... 12

QoS Service Project Plan ........................................................................................................................ 12New Equipment Procurement Schedule ........................................................................................................................ 13

Optimize the Delivery Schedule ................................................................................................................................... 13

Manage Cash Flow ........................................................................................................................................................ 13

Establish Delivery Schedules ........................................................................................................................................ 13

Site Preparation & Deployment Overview for QoS ................................................................................ 14Site Close-out ................................................................................................................................................................ 14

Standard Requirements Specification ........................................................................................................................... 14

Planning a Technology Deployment ............................................................................................................................. 14

Define Installation Strategy .......................................................................................................................................... 14

Define Testing Strategy ................................................................................................................................................ 14

Define Work Plan and Schedule ................................................................................................................................... 14

Define a QoS Contingency Plan ............................................................................................................. 14

Purpose .......................................................................................................................................................................... 14

Define Alternatives ....................................................................................................................................................... 15

Define Procedures ......................................................................................................................................................... 15

Appendices ............................................................................................................................................................................ 16

References ............................................................................................................................................................................ 16



3

Introduction

IP QoS for Research and Development Community.Today’s pharmaceutical research divisions are more diverse in local than years gone by. Pharmaceutical companies aremaking use of more and more enabling technologies in order to maximize the value of dollars spent on high tech withinthe research community. A great deal of pressure is placed on IT infrastructure developers are to spend less and provideequivalent service to the researchers.

In the ideology of “Do more with less” several technologies exist to stretch infrastructure to the limit among them are:

Caching technologies for data that can be suspended reducing loads on underlying communications networks Grid Technology that helps share computing resources across many diverse systems QoS for providing the right level of performance to each category of application, perhaps more important than

the previous two

Business IssueWhy is QoS of such importance in the research and development community? Simple, wide area networks are shared.Like it or not vital research data that may be large and time sensitive shares the same infrastructure as the commonbusiness application such as email or web browsing on the Pharmaceutical company network. Obviously not all data iscreated equal under the corporate networks inspection and only one technology can prioritize data so the companynetwork can perform at its best, IP QOS.

In general, Quality of Service (QoS) refers to the ability of a network to provide better service to selected network trafficover various underlying technologies such as frame relay, ATM, Ethernet, SONET, and IP-routed networks. QoScapabilities are fundamental components of an intelligent network. The industry is transitioning from a lesssophisticated physical infrastructure to a more intelligent infrastructure. A major component of that intelligence is theability of the network to provide different classes of services based on application and user requirements. QoS are themeans to providing that differentiation.

The QoS infrastructure provides better service by: supporting dedicated bandwidth allocation, improving performancecharacteristics, avoiding and managing network congestion, shaping traffic, and setting traffic priorities across thenetwork.

There are various ways to provide QoS guarantees:

By over-engineering and over-provisioning (continues to be expensive for many years to come) By segregating traffic By differentiating various traffic on the network



4

The first two methods are traditional methods of assuring QoS. Both methods need careful planning, and may notnecessarily eliminate all performance problems. The last method requires an adaptive network infrastructure. In thepages that follow we will examine the tools and techniques required to enable large scale diversified research.

Figure 1 - Sources of DelayThe obvious questions that must be asked when trying to understand the need for IP Q oS capabilities, is “what is wrongwith today’s IP service quality and what needs to be fixed ?” The answer to the first part of this question is financial

constraint . The answer to the second part is a bit more involved.

What network designers are trying to fix is the inherent uncertainty associated with the introduction of bandwidthconsuming applications, and whether service quality/network performance can be sustained into the future (especiallygiven much more highly constrained capital markets). There are many forces that are driving Research & Developmentnetworks with IP QoS capabilities, but one of the principal ones is fear. Network designers and enterprise managementfear that, for whatever reason, the high performance that they realize today will erode in the future, and they are

correct. Business Management is looking for “insurance policies” that can help them sustain the businesses that theyare building through virtually anything that the future holds.

All IT Management, especially Drug Research & Development IT departments have seen the flow of capital dollars dry uprecently. This has slowed the deployment of new network capacity in the enterprise. The Research & Developmentbusiness leadership wants to know what IT development is going to do to protect their investment in both HighPerformance Computing environments as well as wide area network infrastructure when they hit the “capacity ceiling”(illustrated in the figure below).

That is, if demand continues to grow and investment in capacity does not re-accelerate then service performance willsuffer when existing network resources are pushed past their engineered load for the single “best effort” grade of

service seen in many Pharmaceutical networks today.



5

Time

C a p a c i t y / D e m a n d

Today

D e m a n d C a

p a c i t y

Figure 2 - Demand over Time

The answer to this dilemma is IP Quality of Service capabilities. What these capabilities allow Pharmaceutical company

IT management to do is define and support multiple grades of service, so that applications that are most interested inhigh performance can be classified for premium service with associated Service Level guarantees.

These QoS mechanisms allow designers to deal with the potential “capacity ceiling” when and if it occurs. It do es this byallowing engineers to define the priority of traffic so that when congestion occurs, the higher priority traffic can beserved first. Additionally, since the designers will engineer network capacity to support the different grades of servicebeing offered, QoS enabled applications will also experience more predictable performance. Performance that over-time we will guarantee with path-level 1 Service Level Agreements (SLA’s). These QoS capabilities, once deployed, areexpected to give large-scale network designers the kind of assurances that they are looking for to justify both their near-term and long-term investments.

Technology Overview

PHB Development IP QoS is the stacking of small technological controls within each piece of network equipment. The stacking of functionsproduces a “Per Hop Behavior ” which essentially the way one piece of network gear treats data. If the PHB’s alignthroughout the network then a single type of conversation will experience a level of performance that a Service LevelAgreement can be written to. QOS is nothing more than predictable behavior for applications data.



6

Figure 3 - Application Performance Model

PHB’s are the vendor specific implementations of the following individual tools:

Classification – RT, H, L, BE Marking and Remarking - DSCP Queuing – LLQ, CBWFQ Rate Limiting – CAR, Soft Policing Drop Mechanisms - WRED

Figure 4 - QoS Mechanics



7

Network Hardware performance is a key issue to the development of effective PHB’s. In each device implementation of QoS the actual, forwarding performance of the device is the true measure of “Quality of Service”. As the technologiesmature the basic algorithmic functions required to allow the higher level decisions are finding their way into thehardware, thus allowing very high performance of QoS features at high data rates.

QoS was originally targeted for the slower equipment in Enterprise level implementations. This was due to thecongestion issue that the slower speed networks often encored. This technology employed at the magnitude of a largeEnterprise Backbone and its relatively high data rates was not originally planned by the manufacturers. Low Speedcongestion relief technologies implemented at High Speed data rates does not necessarily yield High Speed results.

Classification & Packet MarkingIn an enterprise network the first device that accepts the application data will often mark or verify the marking of the IPpacket. Devices are to be provisioned with QoS to ensure the service levels that have been chosen by the designer on aport-by-port basis, a network, and are based on settings within the IP TOS header For the purpose of discussion thiswriting will address DSCP (Diffserv code points) for markings because it is the most common method and for examplepurposes identify four service classes although many more can be defined depending on design requirements.

Figure 5 - Packet Marking

The four traffic classes are: Real Time, High, Low, and Best Effort. Each traffic class is classified by the DSCP values.



8

Table 1 - Traffic DSCP Values

Traffic Class DSCP VALUESIN/ OUT OF CONTRACT

Real Time 40 46

High 24 26 25 27 28 29 30 31 48 56

Low 16 18 17 19 20 21 22 23

48 56

Best Effort 0

QoS policies specify different bandwidth allocations for each traffic class to provide a designer with a choice that mayclosely resemble his traffic needs. The network will characterize the data stream from the designer into four classes inour example:

Best Effort Data: The basic service classification will have been remarked with a QoS service marking of 0. Thistraffic type is to be treated as Best Effort IP traffic and should receive no preferential treatment through the IPnetwork. Marking the data with IP DSCP values of zero will ensure that non-critical data does not becomeassociated with low delay traffic that must traverse the IP network with a greater weight

Low: Medium Grade Data is associated with applications that may carry a higher level of importance to the

designer than best effort or Background traffic such as ping or email traffic. Each designer has a different viewof what traffic types are meaningful to that site. Therefore the relevance of one traffic type to another is said tobe a designer specific decision.

High: High Grade Data is defined as mission critical for a designers business. An example of High Grade Datavaries from designer to designer, however the relevance remains the same, without the passage of these datatypes the designer is unable to operate his or her business. High Grade Data traverses the link above all othernon Real Time Data transmissions in that it will have the lowest percentage of drop in relation to Medium andBest effort Data.

Real Time: Traffic marked, as Real Time will contain QoS markings that will indicate preferential treatment to

the IP network architecture. The IP infrastructure refers to this setting as DSCP 46 most often.

Rate LimitingLimits the amount of traffic based on each DSCP values class. Thus enforcing the rate limits that the designer has chosenfor his highest priority traffic.



9

Rate limiting will ensure that the traffic classes will perform within the predefined allocations. Those ip packets thatmay exceed the class limits for more than a reasonable amount of time will be remarked to a lesser class by the ratelimiter not necessarily discarded. This allows for sharing of network bandwidth if it is available.

Figure 6 - Policing Traffic

This concept is referred to as soft policing. Soft policing is a favorable alternative to simply policing (discarding excessdata) in a class. When basic policing is performed traffic that exceeds its allocations for more than a burst cycle is simplydiscarded or dropped without respect of the classification. Soft policing gives the data packet a reasonable chance of delivery, however it may fall victim to drop machismos that are enacted upon the lesser classes that the packet willtraverse later in the end to end transmission lifespan.

Queuing (LLQ)Low Latency Queuing, also known as Priority Queuing – Class Based Weighted Fair Queuing (PQ-CBWFQ) introduces aWeighted Fair Queuing model for Real Time Traffic handling. This feature allows delay sensitive traffic to be servicedbefore any other packets are dequeued. The priority queue is completely drained of packets first, ensuring timelydelivery throughout the network.

After starvation of the PQ or the allocated time slice has been achieved, the rest of the CBWFQ’s are serviced in thesame manner as if the PQ did not exist. In CBWFQ, the weight for a packet belonging to a specific class is derived from

the bandwidth assigned to the class when configured. Therefore, the bandwidth assigned to the packets of a classdetermines the order in which packets are sent. All packets are serviced fairly based on weight.

Figure 7 - Queuing



10

In order to ensure that the bandwidth given to the PQ is not exceeded during times of congestion, the PQ is trafficmetered using a token bucket system. With a token bucket system the control is on a per packet basis, if a token is notavailable the packet is dropped. Unlike Rate Limiting, Traffic Metering is only performed when congestion occurs on thecircuit. The PQ traffic is allowed to free use the bandwidth when no congestion exists.

Drop Mechanisms - WREDWRED (Weighted Random Early Detection) was initially designed to perform selective discards within a traffic class in

order to induce TCP to perform a back off operation before circuits reached maximum capacity. The activity of saturating a circuit and backing down tcp sessions without discard (or the use of WRED) is referred to as “global TCPslow start synchronization ”. Basically this creates a situation where all of the applications slow down transmission for ashort period then ramp up again, recreating the original congestion issue.

Figure 8 - Dropping Under CongestionIn its purest form WRED statistically drops from the heavy TCP bandwidth users more than the lower bandwidth TCPusers. WRED has had its contentions. It can be argued that with an enterprise network the magnitude of most largescale pharmaceutical companies that more than one packet discarded from a micro flow will statistically occur. Withoutmore than one packet discarded TCP will simply perform a “fast retrains” (resending the lost packet very qu ickly) in mostcases and effectively yield no back off results.

The design objective of WRED in the large research network is to allow for intelligent discarding of traffic within classes,when necessary. When the queues are overrun traffic is traditionally dropped in a fashion referred to as tail drop. Withsimple tail drops no attention is placed on the priority of traffic within a class



11

Figure 9 - End to End QoS

End to End QoSIn the R&D network implementation WRED along with rate limiting and CBWFQ can deliver a reasonable QoS lineconditioning. It does this by providing the capability to apply discards to each class using different weights so that thenumber of packets dropped in a higher priority packet is smaller than the one in a lower priority packets within a class.By carefully selecting the weights for WRED, Basic traffic may be dropped before any higher valued packets are dropped.It is the priority preference that allows QoS service class differentiation.

Pharmaceutical Application

RisksAs with any system wide change there are risks to the business. First and foremost are the risks associated with change.Changes to network configurations and new equipment may result in periodic down time and hence loss of businessoperations. This risk is mitigated by testing and preparation. An in depth explanation of testing and deploymentplanning follows. The more time spent addressing these issues the less risk involved.

Installation (planned down time) will be necessary while the transitions to new configuration and specialized hardware.Fortunately for the business QoS application is incrementally advantageous. IT department change windows will beused for the application of the new technology. Not all changes or installations are required within one window;therefore the migration to a performance enhanced network environment can be done in steps. With each installationsuccess the overall performance of time sensitive applications (such as imaging and 3D development applications) willincrease.

Cost Impacts.

QoS is a symmetrical technology and costs fall into three simple categories:

1- Configuration change which usually has little or no additional expense2- Equipment replacement with QoS features, these costs may be rolled into lifecycle expenses



12

3- Service provider fees, MRC that is a result of a service provider implementing controls to ensure performance

Therefore the application of a simple software configuration or a specialized piece of Hardware must have an equal andopposite treatment form the next piece of equipment in-line. In-line alignment is acceptable due to the per hopbehavior of modern day QoS treatments. The application of a QoS treatment on a service provider interface has a costcomponent when a real-time protocol is defined and queued with priority.

This cost must be accounted for if the network makes use of carrier services such as MPLS VPN’s, ATM or Frame Relaycircuits. Simple Private Line circuits are just that, private and QoS may be applied to these point to point circuits withoutadditional costs over the base cost of the equipment.

ManagedCustomer

Router

AccessRouterInbound Traffic

Outbound Traffic

QoS Policy

QoS Policy

MPLSVPN

Figure 10 - Service Provider Edge

The additional cost of QoS policies on the provider interface manifest themselves as MRC’s that vary with both thesubscribed speed of the port as well as the country they are applied within. A worksheet for each installation should bedeveloped that depicts the known site list, equipment type, port speed and QoS supportability. Combined with pricingdata available from sourcing a total cost of operation may be derived.

Implantation & Deployment Planning Deployment planning will be necessary for the smooth integration of Enterprise QoS conditioning into the networks. Asa product of this planning three distinct documents will need to be developed:

QoS Service Project Plan Site Preparation & Deployment Overview for QoS QoS Contingency Plan

QoS Service Project PlanThe following are instructions to all involved parties for the deployment of either Software

Configuration policies and or Hardware. As service deployment works with the network engineer,Transition teams needs to consider the following when planning the deployment of a QoS technologyas well as document the approach within the Service Project Plan:

Site List Procurement schedule, Optimize the delivery schedule, Manage cash flow – customer facing billing



13

Individual Site Remediation Tasks and Costs Site Deployment Schedule

New Equipment Procurement Schedule

Transition teams need to schedule the procurement such that all equipment for an individual siteis in inventory at least one full month before its scheduled deployment to the site. This onemonth buffer is essential to ensure no interruption in the deployment process once equipmentdelivery begins.

To maximize control over the equipment delivery and minimize the overall deploymentscheduling risk, isolate the vendor and the procurement process from the deployment process, forinstance do not base the deployment schedule on the Cisco or other hardware vendor deliveryschedule for new equipment.

Structure the procurement and deployment schedules to anticipate that some vendors will havelonger lead times than others. i.e. Hardware vs. Monitoring Vendors. During the planning phasefor the sites that will transform, project management will insure that the appropriate additionalhardware are included as required hardware. The deployment project should be setup with

support from both the PMO and PM organizations from upper management. This jointmanagement will ensure a seamless deployment

Optimize the Delivery Schedule

Design the equipment delivery and installation schedules to coincide with QoS treatmentactivation. For example, plan to begin class based monitoring a site within one week of QoSpolicy applications and hardware deployments.

Manage Cash Flow

If additional onsite work is required (cabling or rack installations) devise a management strategywhich will both expedite vendor payment and correspond to the equipment acceptance proceduresof the customer. Notify the Technical Management & Project Management staff as soon asadditional expenses are known. No unprepared solicitations for funding will be entertained.

Establish Delivery Schedules

Establish delivery schedules for procurement, staging, and installation considering the following:

The monitoring schedule, to ensure that equipment installation and activation does not occurtoo long after the monitoring system is ready

The local site installation strategy, restrictions

The delivery method for the equipment.



14

Site Preparation & Deployment Overview for QoS

A site specific deployment plan is required for service installation. The deployment plan is to bederived from the following topics and written by contracted operational staff. Review of this planby site transformation staff is to be performed prior to scheduling the service installation.

Site Close-out

List the acceptable test criteria for a site to declare success. Verify user applications functionbefore and after site installations.

Standard Requirements Specification

Standard high level requirements for QoS installation may be specified, and then customized forsite specific details.

Planning a Technology Deployment

Review site details and list equipment and configurations that will be altered to implement QoS.

Should no compliant equipment exist on the installation site it will be identified here and eithermitigated or identified as non compliant. Non compliant equipment will not receive QoSconfigurations and will be forwarded to a spreadsheet used to drive future remediation efforts.

Define Installation Strategy

Define the proposed strategy for installation of the QoS technology for the site (i.e. Hardwarebased or a combination).

Define Testing Strategy

Define the strategy for testing the installation. For example, a set of tests may be conducted inthe staging area to test the configuration, and integration testing of processors may occur at theinstallation site.

Define Work Plan and Schedule

For each unique installation, define all activities and tasks necessary for procurement, staging,installation, and testing. For each task identify who is responsible, the effort required, and startand completion dates. Include the responsibilities of site personnel in the work plan.

Define a QoS Contingency Plan

PurposeTo provide a fall-back to cover the possibility that unexpected events cause the installation of thenew Quality Controls (QoS Treatments) to fail, or the new design proves to be unusable afterdeployment. Since deployment of router modifications are to be performed by vendor contractoperations a written contingency plan is to be reviewed by both the operation staff and the endcustomer.



15

Define Alternatives

Determine the potential areas of failure and define alternative approaches to recovery for eacharea. Choose the best alternative for each potential failure area. Ensure that the best alternativedoes not adversely impact some other aspect of deployment. Contingency plans are required toprepare for events such as:

Equipment problems; e.g., reboots, QoS application errors

Network problems; e.g., performance bottlenecks or application errors

A written contingency plan is to be reviewed by both the operation staff and the end customer

Define Procedures

Define procedures, detailing the steps that must be followed to implement the contingency.Detailed procedures consider the following:

The criteria to be used to decide whether to invoke a contingency, the person(s)responsible for making the decision, and the method to communicate the plans to theaffected staff.

Procedures to be used to restore the old network environment,

Communications to affected staff during and after the implementation of the contingency,

Down time to be expected and the manual procedures to be used to continue service tocustomers during the down time.



16

Appendices

Figure 11 - QoS Enabled Application Model

References Greenville A. (2004). Cisco QoS Design & Configuration (Second Edition). Cisco-Press Publishing Tanenbaum A.S. (2001). Computer Networks (Third Edition). Prentice-Hall Publishing

Flanagan M. (2007) Administering Cisco QOS for IP Networks, Syngress Press Nikolay D, Daniela S (2004) Information System for a Pharmaceutical Network. Network World Publishing

IP QoS and Differentiated IP Services for Research and Development Community

Documents

Transcript of IP QoS and Differentiated IP Services for Research and Development Community