Performance Architecture

1. Performance Architecture By Dr. Shadi Masadeh 1

2. Performance Architecture • Describes how user, application, device, and (existing) network requirements for performance (capacity, delay, and RMA [reliability, maintainability, and availability]) will be met within the planned network. • The performance architecture is the newest of the component architectures, and it is rapidly evolving to include many new mechanisms to achieve network performance.

3. Performance Architecture • Objectives • We will learn: • What performance means in a network, including descriptions of mechanisms to achieve performance • How to determine the relationships both among these mechanisms and between performance and the other architectural components • How to develop the performance architecture. • Develop goals for performance that will guide the development of this architecture.

4. Performance Architecture • Background • Performance is the set of levels for capacity, delay, and RMA in a network. • Desirable to optimize these levels, to one or more sets of traffic flows, based on groups of users, applications, and/or devices. • Performance architecture: is the set of performance mechanisms to configure, operate, manage, provision, and account for resources in the network that support traffic flows. • Where these mechanisms are applied within the network, and the sets of internal and external relationships between this and other component architectures.

5. Performance Architecture • Background • Importance of developing Performance Architecture: • Determining the performance goals of a network. • Performance may be applied to: • Improve the overall performance of the network (e.g., to improve response times and throughput to all users) • Support a particular group or groups of users or applications, maybe new or planned applications • Control resource allocation for accounting, billing, and/or management purposes

6. Performance Architecture • Background • performance consists of one or more of the following (Figure 8.1): • controlling traffic inputs to the network (admission and rate controls) • adjusting the baseline performance of the network (traffic or capacity engineering) • controlling all or part of the network for delivery of specific services (prioritizing, scheduling, and conditioning traffic flows) • implementing a feedback loop to users, applications, devices, and management to modify controls as necessary.

8. Performance Architecture • Developing Goals for Performance • toward developing performance architecture, we should answer the following questions: • Are performance mechanisms necessary for this network? • What are we trying to solve, add, or differentiate by adding performance mechanisms to this network? • Are performance mechanisms sufficient for this network? • we should already have the information needed to make a decision from the requirements and flow analyses.

9. avoid implementing mechanisms just because they are interesting or new. • For example, it may be tempting to implement QoS mechanisms in a network, even when there are no clear goals or problems to solve. • start simple and work toward a more complex architecture. • Simplicity may be achieved by: • implementing performance mechanisms only in selected areas of the network (e.g, at the access or distribution [server] networks) • By using only one or a few mechanisms • by selecting only those mechanisms that are easy to implement, operate, and maintain.

10. Performance Architecture • Developing Goals for Performance • There should be information in the requirements and flow analyses that can help in determining the need for performance mechanisms in a network; include: • Clearly different sets of network performance requirements, per user, group, application, device, and/or flow • Requirements to bill and account for network service. • When you plan to implement performance mechanisms in a network, you should also determine whether or not your customer is willing to pay the costs for such mechanisms.

11. For example, does your customer have a network staff capable of configuring, operating, and maintaining QoS, SLAs, and policies? • If not, are they willing to pay the cost to acquire such staff, or outsource performance (and some portion of network management)? • Performance is not a capability that is implemented once and then forgotten; it requires continual support. • If your customer is not willing to provide that support, • it is better not to implement such mechanisms.

12. Performance Architecture • Developing Goals for Performance • when performance mechanisms are implemented and not supported, maintained, or kept current, performance in the network can actually degrade to a point where it would be better not to have any performance mechanisms at all. • Some common problems that are addressed by the performance architecture include: • Improving the overall performance of a network • Improving the performance to select users, applications, and/or devices • Changing the network from a cost center to profitability • Merging multiple traffic types over a common network infrastructure • Differentiating (and possibly charging) customers for multiple levels of service

13. Performance Architecture • Performance Mechanisms • Performance mechanisms are: • Quality of Service (QoS) • Resource Control (RC) (prioritization, traffic management, scheduling, and queuing) • Service-Level Agreements (SLA) • Policies. • Subsets of these mechanisms are usually used together to form a comprehensive approach to providing single-tier and multi-tier performance in a network. • These mechanisms provide the means to identify traffic flow types, measure their temporal characteristics, and take various actions to improve performance for individual flows, groups of flows, or for all flows in the network.

14. Performance Architecture • Quality of Service • QoS, is determining, setting, and acting upon priority levels for traffic flows. • QoS is usually associated with • IP QoS (including MPLS), type of service (ToS), and Frame Relay committed information rate (CIR). • IP-based traffic, there are two standard types of QoS (two views of network service): • differentiated services (DiffServ, or DS) • perspective of aggregating traffic flows on a per-hop basis based on traffic behavior • integrated services (IntServ, or IS) • perspective of supporting traffic flows on an individual, end-to-end basis.

15. Performance Architecture • Quality of Service • IntServ: specifies a fine-grained QoS system • every router in the system implements IntServ, and every application that requires some kind of guarantees has to make an individual reservation. • Resource Reservation Protocol "RSVP“: is the underlying mechanism to signal QoS across the network: • All machines on the network capable of sending QoS data send a PATH message every 30 seconds, which spreads out through the networks. • Those who want to listen to them send a corresponding RESV (short for "Reserve") message which then traces the path backwards to the sender.

16. Performance Architecture • Quality of Service • IntServ: specifies a fine-grained QoS system • DiffServ: coarse-grained control system. • IP packets are marked in the type of service (ToS) byte for IPv4 or in the traffic class byte in IPv6 so that they will receive the corresponding performance at each network device (or hop). • DiffServ defines a set of values for classes of traffic flows • It applies to aggregates of traffic flows (e.g., composite flows), not individual traffic flows.

17. Performance Architecture • Quality of Service • In DiffServ: • IP packets are marked in the type of service (ToS) byte for IPv4 or in the traffic class byte in IPv6 • defines a set of values (termed differentiated services code points, or DSCPs) for classes of traffic flows, to be used by resource control mechanisms. • it applies to aggregates of traffic flows (e.g., composite flows), not individual traffic flows. • By aggregating flows into traffic classes • The main reason for this is for scalability • Storing and maintaining state information become more tenable • Traffic classes for DiffServ: • Best-effort: normal IP packets • Assured Forwarding (AF): assured forwarding can be used for traffic with both delay and capacity requirements (e.g., multimedia or tele∗services) • Expedited Forwarding (EF) : traffic that has delay requirements (e.g., real-time or interactive)

18. Performance Architecture • Quality of Service • In IntServ: • defines values and mechanisms for allocating resources to flows across the end-to-end path of the flow. • placing importance on supporting a flow at every network device in the end-to-end path of that flow. • it requires resources (e.g., memory, processing, bandwidth) for each flow • It requires a mechanism to communicate flow requirements • across network devices (signaling provided by RSVP and MPLS) • RSVP is used to request specific quality of service levels from network devices in the end-to-end path of a traffic flow. • Reserve state information about the requested service. • DiffServ and IntServ can be applied individually or together • If both mechanisms applied together: • In this case DiffServ is first applied and IntServ is then overlaid onto it

19. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • DiffServ and IntServ are used to apply prioritization, traffic management, scheduling, and resource control to traffic flows: • The represent the heart of providing performance in a network • Performance architecture: • may include one or more of these mechanisms, in conjunction with QoS, SLAs, and policies • These mechanisms can be: • implemented in network devices such as routers and switches • applied to the network as stand-alone hardware (traffic management devices)

20. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Prioritization: • The process of determining which user, application, device, flow, or connection gets service ahead of others, or gets a higher level of service. • Necessary since traffics compete for network resources. • limited amount of resources available in any network • who gets resources first • how much resources they get. • Begins during the requirements and flow analysis processes. • Priority levels for users, applications, and devices determined during requirements analysis • Priority levels for traffic flows determined during the flow analysis process • Two high-level views of performance: • Single-tier performance: (may apply across the entire network) • Multi-tier performance: one or more groups of traffic flows, based on groups of users, applications, and/or devices (may apply in select areas, or as an addition to single-tier )

21. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Prioritization: • Multiple levels of performance implies a need to prioritize traffic flows • Prioritization is based on importance and urgency • The basic case of prioritization when all have the same priority level • the case in best-effort networks • When greater than the general case • they will have higher priority levels.

22. Priority level may be: • changed based on urgency • based on: • Protocol type (e.g., TCP versus UDP) • Service, or port number • IP or MAC-layer address • Or by other information embedded within the traffic • maintained in databases and coupled with policies and SLAs • Priority levels are used by network devices: • To determine if traffic flows will be allowed on the network (admission control) • Scheduling of traffic flows onto the network • Conditioning of flows throughout the network.

23. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • Consists of: • Admission control: the ability to refuse access to network resources • Traffic conditioning: a set of mechanisms that modify (increase or decrease) performance to traffic flows • Admission control: • Uses priority levels to change the behavior of network access • In a best-effort network without admission control, access to the network all traffic flows have a (more or less) equal chance to get network resources. • Access is permitted, denied, or sometimes delayed, based on the relative priority of that traffic.

24. Performance Architecture • 8.4.2 Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • Traffic conditioning • Traffic flows are identified and distinguished|: • Classification is the ability to identify traffic flows • looks at various parts of the IP packet • IP addresses, port numbers, protocol types or may look deeper into a packet. • For example, voice over IP (VoIP) signaling flows may be determined by looking for session initiation protocol (SIP) identifiers • Upon identifying traffic flows • Packets may be marked/ tagged with a priority level • Examples: tagging packets with DiffServ Code Points (DSCPs) for best-effort (BE), assured forwarding (AF), and expedited forwarding (EF) priority levels.

25. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • After classification; traffic may be metered to determine their performance levels. • Metering: measuring the temporal performance • traffic rates and burst sizes • Metering: • is a capability provided in network devices (e.g., routers and switches) • can also be applied as a separate network device • For example, a traffic flow may be metered over a period of 1 second. Each second, the peak data rate for that flow is compared with a capacity boundary of 1.5 Mb/s, which was input into the network device from an SLA developed for that traffic flow.

26. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • Metering a traffic flow can determine whether or not a flow is within performance boundaries (Figure 8.4). • Conforming traffic is within performance boundaries • no action is taken • forwarded to the appropriate output queue • Non-conforming traffic is outside of performance boundaries

28. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • Non-conforming: (it is exceeding the specifications of an SLA) • subject to shaping or dropping • Shaping is delaying traffic to change a performance characteristic • Dropping is discarding traffic • Non-conforming traffic may also be marked, with no other action taken • To shape non-conforming traffic: • sent to a shaper queue where delay is added; (changes the performance of that traffic flow) • Consider an SLA for a traffic flow that specifies a peak rate of 1.5 Mb/s. A meter is measuring that traffic flow, and calculates a rate of: • 200 packets/second∗1500 byte packets∗8 bits/byte = 24 MBits/second

29. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Traffic Management • To shape non-conforming traffic: • Consider an SLA for a traffic flow that specifies a peak rate of 1.5 Mb/s. A meter is measuring that traffic flow, and calculates a rate of: • 200 packets/second∗1500 byte packets∗8 bits/byte = 24 MBits/second • This is compared with the SLA specification (1.5 MBits/second) and found to be non-conforming. Subsequent packets are then forwarded to a shaper queue, where they are delayed by an average of 10 ms. As a result, only 100 packets can be transmitted per second, and the rate of that traffic flow becomes: • 100 packets/second∗1500 byte packets∗8 bits/byte = 12 MBits/second • Shaping continues either for a specified period of time or until the traffic flow is again conforming • The most serious action that can be taken on traffic is dropping, or discarding, packets • This is done when a traffic flow is seriously exceeding its performance boundary, or when the network device is congested to the point where dropping packets is necessary. Traffic conditioning functions are shown in Figure 8.5

31. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Scheduling • Scheduling is the mechanism that determines the order in which traffic is processed for transmission. • provided through network management • or as part of the QoS • Scheduling may be: • proprietary (enterprise-specific) • or standards-based use scheduling algorithms: • include weighted fair queuing (WFQ) • class-based queuing (CBQ) • The combination of QoS, prioritization, traffic management, and scheduling can be applied across a network to achieve various performance levels for traffic flows (Figure 8.6)

33. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Queuing • Queuing is storing packets within a network device while they wait for processing. • Locations where packets are stored (queues): • holding packets received from the network • processing for QoS • holding packets for transmission onto the network • There are a number of queuing mechanisms available in network devices. • For example, queue mechanisms may treat all packets in the same way • may randomly select packets for processing • may favor particular packets • the following queuing mechanisms achieve that: • First in first out (FIFO) • Class-based queuing (CBQ) • Weighted fair queuing (WFQ) • Random early detect (RED) • Weighted RED (WRED)

34. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Queuing • First in first out (FIFO) queuing: simplest queuing mechanism available • Packets are stored in a single queue • Packets are transmitted onto the network in the order that they were received (at the input queue). • Class-based queuing (CBQ): • Multiple queues with differing priorities • Priority levels are configurable in the network device and indicate the performance levels required for each traffic type • Packets of each priority level are placed in their respective queues • Higher-priority queues are processed before lower-priority queues • Weighted fair queuing (WFQ) • Assigns priorities (weights) to queues • High-priority traffic flows are processed first, and lower-priority traffic flows share the remaining resources.

35. Performance Architecture • Prioritization, Traffic Management, Scheduling, and Queuing • Queuing • Generally, when a queue becomes full (e.g., during periods of congestion), • packets are dropped either from the beginning of the queue (head) or end of the queue (tail). • In either case, the dropping of these packets is likely to be unfair to one or a few traffic flows. • As a result, random early detect (RED) was developed to randomize the packet dropping process across a queue. • RED will drop packets early (before the queue is actually full) to force traffic flows (i.e., TCP flows) to adjust by reducing their transmission rate. • Weighted RED (WRED) • operates in the same fashion as RED • but supports multiple priority levels (one for each queue) for dropping packets