1. DMET 602: Networks and Media Lab Amr El Mougy Yasmeen EssamAlaa Tarek

2. Exp 6: Quality of Service

3. Have you ever experienced…  A slow Internet application  Video broadcast occasionally stalling  Poor quality VoIP phone calls  Dropping in VoIP phone calls  ATM or credit card machines are non-responsive

4. Why does this happen?  A slow Internet application (not enough bandwidth)  Video broadcast occasionally stalling (large Jitter)  Poor quality VoIP phone calls (too much Delay)  Dropping in VoIP phone calls (no/bad admission control)  ATM or credit card machines are non-responsive (too much packet loss)

5.  Lack of bandwidth – multiple flows are contesting for a limited amount of bandwidth The bandwidth of an entire path is defined by the bottleneck link The total bandwidth given to a flow may be difficult to calculate due to resource sharing between flows  Too much delay – packets have to traverse many network devices and links that add up to the overall delay Delay has 4 main components: queuing (the one mainly varying), transmission, processing, and propagation  Variable delay – sometimes there is a lot of other traffic which results in more delay (bursty traffic)  Drops – packets have to be dropped when a link is congested Which packet to drop? Depends on the queuing discipline What causes….

6. Quality of Service (QoS)  Is the capability of a network to support the requirements of a traffic flow (usually defined between a sender and a receiver)  Application requirements are typically defined in terms of bandwidth, packet, delay, and jitter ApplicationLoss ToleranceBandwidth demandDelay toleranceJitter tolerance EmailLow High FTPLowLow - MediumHigh Video streamingMedium - highHighMedium - lowLow VoIPHighLow Video conferencingMedium - highHighLow

7.  Elastic applications Wide range of acceptable rates, although faster is better E.g., data transfers such as FTP  Continuous media applications (soft QoS) Lower and upper limit on acceptable performance Sometimes called “tolerant real-time” since they can adapt to the performance of the network  E.g., changing frame rate of video stream  “Network-aware” applications  Hard real-time applications (hard QoS) Require hard limits on performance – “intolerant real-time” E.g., control applications Application Types

8. QoS Principles  Simple model for sharing and congestion studies (“dumb bell topology”):

9.  Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. Bursts of FTP can congest the router and cause audio packets to be dropped. Want to give priority to audio over FTP.  PRINCIPLE 1: Marking (classification) of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly. QoS Principles

10.  Applications misbehave (ex: audio sends packets at a rate higher than 1Mbps assumed above).  PRINCIPLE 2: provide protection (isolation) for one class from other classes.  Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges:

11. QoS Principles  Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation.  Resource management avoids the need for bandwidth augmentation (expensive solutions  PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible.

12. QoS Principles  Cannot support traffic beyond link capacity.  PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs.

13. QoS for Networked Applications  Marking (classification): packets are marked in the type of service (TOS) field in IPv4 and traffic class in IPv6 DSCP NameDS Field Value (Dec)IP Precedence (Description) CS000 : Best Effort CS1,AF11-138,10,12,141 :Priority CS2,AF21-2316,18,20,222 :Immediate CS3,AF31-3324,26,28,303 :Flash - mainly used for voice signaling CS4,AF41-4332,34,36,384 :Flash Override CS5,EF40,465 :Critical - mainly used for voice RTP CS6486 :Internetwork Control CS7567 :Network Control

14.  Queuing Disciplines: how network elements (routers, switches) handle packets  Classful queuing: useful if the types of incoming traffic are known. Divides packets into categories, and all the categories share the bandwidth evenly (ex: class-based queuing – CBQ) QoS for Networked Applications

15.  Classless queuing: only reschedule, delay, or drop packets. Can be used within a leaf of CBQ or for traffic shaping

16. QoS for Networked Applications Random Early Detection (RED)

17.  Best-Effort—Best-Effort does not provide QoS, because there is no reordering of packets.  Differentiated Services (DiffServ)—DiffServ, as the name suggests, differentiates between multiple traffic flows. Scalable. Aggregates flows with same requirements No signalling is required to the network. The network recognizes the packets  Integrated Services (IntServ)—IntServ is often referred to as “Hard QoS, ” because it can make strict bandwidth reservations. Needs signaling first. Must be configured on every router along a path. The main drawback of IntServ is its lack of scalability. Specifically, packets are “marked, ” and routers and switches can then make decisions. Bandwidth reservation based on application level. Resource Reservation Protocol (RSVP) is used  Networks use all three models at the same time Internet QoS Service Models

18.  The “Integrated Service Working Group” developed specifications of a number of service classes, designed to meet the needs of some application types (1995-97)  It also defines, how RSVP can be used to make reservations, based on these service classes  Focus on per-flow QoS. Support specific applications such as video streaming. Based on mathematical guarantees.  Many concerns: Complexity Scalability Business model Charging Integrated Services (IntServ)

19. IntServ Components  Type of service model  What does the network promise?  Service interface  How does the application describe what it wants?  Packet scheduling  How does the network meet promises?  Establishing the guarantee  How is the promise communicated to/from the network?  How is admission of new applications controlled?

20.  Network can support traffic streams with different “quality of service”. Best effort Predictive or prioritized services Strong guarantees on the level of service (real-time)  The set of services that is supported on a specific network can be viewed as a service model. Model that can be used to select a service E.g., cost versus performance tradeoffs Network architecture that supports the set of services Considers interactions between services Service Models

21.  Guaranteed service Targets hard real-time applications. User specifies traffic characteristics and a service requirement. Requires admission control at each of the routers. Can mathematically guarantee bandwidth, delay, and jitter.  Controlled load Targets applications that can adapt to network conditions within a certain performance window. User specifies traffic characteristics and bandwidth. Requires admission control at each of the routers. Guarantee not as strong as with the guaranteed service. e.g., measurement-based admission control.  Best effort Service Models

22.  Session must first declare its QoS requirement and characterize the traffic it will send through the network  R-spec: defines the QoS being requested by receiver (e.g., rate r)  T-spec: defines the traffic characteristics of sender (e.g., leaky bucket with rate r and buffer size b).  A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol. Service Interface

23.  Guaranteed service Use token bucket filter to characterize traffic Described by rate r and bucket depth b Use Weighted Fair Queuing (WFQ) at the routers Provides mathematical bounds on queuing delay Packet Scheduling

24.  Resource Reservation is used to identify an application (flow) and signal if there are enough available resources for it  Admission Control is used to determine if the application (flow) can get the requested resources. Can be done locally at a router or offloaded to a central point IntServ Operation

25. Admission Control Routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

26. Resource Reservation Protocol (RSVP)  Rides on top of unicast/multicast routing protocols.  Support is mainly for Multicast. Unicast is considered a special case of multicast  Must be present at sender(s), receiver(s), and routers.  Carries resource requests all the way through the network.  At each hop consults admission control and sets up reservation. Informs requester if failure.  Works best with applications that require low bandwidth and low delay. Ex: VoIP sessions

27.  Used on connectionless networks (referring to connectionless network layers such as IP, not transport layer) Should not replicate routing functionality. Should co-exist with route changes.  Support for multicast Different receivers have different capabilities and want different QOS. Changes in group membership should not be expensive. Reservations should be aggregate – I.e. each receiver in group should not have to reserve. Should be able to switch allocated resource to different senders.  Limit control overhead.  Modular design – should be generic “signaling” protocol.  Result: Receiver-oriented Soft-state RSVP Goals

28.  Receiver initiates reservation by sending a reservation over the sink tree. Assumes multicast tree has been set up previously. Also uses receiver-initiated mechanism. Hooks up with the reserved part of the tree. How far the request has to travel to the source depends on the level of service requested. Uses existing routing protocol, but routers have to store the sink tree (reverse path from forwarding path).  Properties: Scales well: can have parallel independent connect and disconnect actions – single shared resource required. Supports receiver heterogeneity: reservation specifies receiver requirements and capabilities. Receiver-Initiated Reservation

29.  Routers keep state about reservation.  Periodic messages refresh state.  Non-refreshed state times out automatically.  Properties of soft state: Adapts to changes in routes, sources, and receivers. Recovers from failures Cleans up state after receivers drop outs  Philosophy: reservation is an optimization. Soft State Reservation  Alternative: Hard state No periodic refresh messages. State is guaranteed to be there. State is kept till explicit removal. Why could there be a problem?

30.  Make reservations for simplex data streams.  Receiver decides whether to make reservation  PATH/RESV messages sent periodically to refresh soft state.  CONFIRMATION message  Generated only upon request.  Unicast to receiver when RESV reaches node with established state.  TEARDOWN message releases the reservation  ERROR message (if PATH or RESV fails)  One pass: Failed requests return error messages - receiver must try again. No end to end ack for success. RSVP Service Model

31.  PATH messages carry sender’s T-spec. Token bucket parameters  Routers note the direction PATH messages arrived and set up reverse path to sender.  Receivers send RESV messages that follow reverse path and setup reservations.  If reservation cannot be made, user gets an error.  RESV messages carry receiver’s R-spec and forwarded via reverse path of PATH.  They also carry Queuing delay, bandwidth requirements, and source traffic characteristics (from PATH).  RESV also defines filter specification  Which transmissions can use the reserved resources?  Reservation style.  Router performs admission control and reserves resources. PATH/RESV Messages

32.  If new request rejected, send error message.  If admitted:  Install packet filter into forwarding dbase.  Pass flow parameters to scheduler.  Activate packet policing if needed.  Forward RESV message upstream. Router Handling of PATH/RESV

33. Example

34. RSVP Implementation Options  Implement RSVP on all routers (edge + core): Used in small-to-medium size networks In large networks, overhead due to signaling and concurrent reservations increases  performance deteriorates  Implement RSVP on network edges only Network edges is typically where bandwidth bottlenecks exist. The core usually has sufficient bandwidth The edge-to-core routers mark the packets for use by the core The core may use DiffServ or rely on best effort (would still work if non-congested)

35.  Intended to address the following difficulties with Intserv and RSVP;  Scalability: maintaining states by routers in high speed networks is difficult due to the very large number of flows  Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)  Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service Differentiated Services (DiffServ)

36.  Do fine-grained enforcement only at the edge of the network. Typically slower links at edges E.g., mail sorting in post office  Label packets with a field. E.g., a priority stamp  The core of the network uses only the type field for QoS management. Small number of types with well defined forwarding behavior Can be handled fast  Example: expedited service versus best effort  Evolution rather than revolution DiffServ Motivation

37.  DiffServ defines an architecture and a set of forwarding behaviors. It is up to the service providers to define and implement end-to-end services on top of this architecture. Offers a more flexible service model; different providers can offer different service.  One of the main motivations for DiffServ is scalability. Keep the core of the network simple.  Focus of Diffserv is on supporting QoS for flow aggregates. Although architecture does not preclude more fine-grained guarantees. DiffServ Main Features

38. DiffServ Architecture

39.  Classification: marks packets according to classification rules to be specified.  Metering: checks whether the traffic falls within the negotiated profile.  Marking: marks traffic that falls within profile. Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6. 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive.  Conditioning: delays and then forwards, discards, or remarks other traffic. Edge Router/Host Functions

40. QoS for Networked Applications  Marking (classification): packets are marked in the type of service (TOS) field in IPv4 and traffic class in IPv6 DSCP NameDS Field Value (Dec)IP Precedence (Description) CS000 : Best Effort CS1,AF11-138,10,12,141 :Priority CS2,AF21-2316,18,20,222 :Immediate CS3,AF31-3324,26,28,303 :Flash - mainly used for voice signaling CS4,AF41-4332,34,36,384 :Flash Override CS5,EF40,465 :Critical - mainly used for voice RTP CS6486 :Internetwork Control CS7567 :Network Control

41.  Forwarding: according to “Per-Hop-Behavior” or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB).  BIG ADVANTAGE: No state info to be maintained by routers!  PHB result in a different observable (measurable) forwarding performance behavior.  PHB does not specify what mechanisms to use to ensure required PHB performance behavior.  Examples:  Class A gets x% of outgoing link bandwidth over time intervals of a specified length.  Class A packets leave first before packets from class B. Forwarding (Per-hop-Behavior)

42.  Expedited Forwarding (EF): Guarantees a bandwidth and minimum departure rate Implies isolation: guarantee for the EF traffic should not be influenced by the other traffic classes. Admitted based on peak rate. Non-conformant traffic is dropped or shaped (no access to excess bandwidth)  Assured Forwarding (AF): Guarantees bandwidth and allows access to extra bandwidth AF defines 4 classes with some bandwidth and buffers allocated to them. The intent is that it will be used to implement services that differ relative to each other (e.g., gold, silver,…). Within each class, there are three drop priorities, which affect which packets will get dropped first if there is congestion. Lots of studies on how these classes and drop priorities interact with TCP flow control. Non-conformant traffic is remarked. Forwarding Types