Beyond Best-Effort Service Advanced Multimedia University of Palestine University of Palestine Eng. Wisam Zaqoot Eng. Wisam Zaqoot November 2010 November 2010 Ref: Computer Networking: A Top Down Approach, 4th ed., Kurose & Ross QoS Principles

Was our bag of tricks enough? We learned in previous lectures how sequence UDP, numbers, timestamps, FEC, CDN, RTP and RTCP can be used by multimedia networking applications to enhance the internet best-effort service. We learned in previous lectures how sequence UDP, numbers, timestamps, FEC, CDN, RTP and RTCP can be used by multimedia networking applications to enhance the internet best-effort service. But are these techniques alone enough to support reliable and robust multimedia applications, like an IP telephony ?? But are these techniques alone enough to support reliable and robust multimedia applications, like an IP telephony ?? No. An application will receive whatever level of performance (e.g., end-end packet delay and loss) that the network is able to provide at that moment. No. An application will receive whatever level of performance (e.g., end-end packet delay and loss) that the network is able to provide at that moment. In addition, the internet today does not allow delay- sensitive multimedia applications to request any special treatment. In addition, the internet today does not allow delay- sensitive multimedia applications to request any special treatment.

Providing Multiple Classes of Service thus far: making the best of best effort service thus far: making the best of best effort service one-size fits all service model one-size fits all service model alternative: multiple classes of service alternative: multiple classes of service partition traffic into classes partition traffic into classes network treats different classes of traffic differently (analogy: VIP service vs regular service) network treats different classes of traffic differently (analogy: VIP service vs regular service) 0111 granularity: differential service among multiple classes, not among individual connections granularity: differential service among multiple classes, not among individual connections history: Type of Service (ToS) bits in IPv4 history: Type of Service (ToS) bits in IPv4 In fact, many alternatives like diffserv, intserv, and rsvp were proposed. In fact, many alternatives like diffserv, intserv, and rsvp were proposed.

Multiple classes of service: scenario R1 R2 H1 H2 H3 H4 1.5 Mbps link R1 output interface queue The basic scenario: two application packet flows originate on hosts H1 and H2 on one LAN and are destined for hosts H3 and H4 on another LAN. The routers on the two LANs are connected by a 1.5 Mbps link. The basic scenario: two application packet flows originate on hosts H1 and H2 on one LAN and are destined for hosts H3 and H4 on another LAN. The routers on the two LANs are connected by a 1.5 Mbps link. We have to focus on the output queue of router R1; it is here that packet delay and packet loss will occur if the aggregate sending rate of the H1 and H2 exceeds 1.5 Mbps. We have to focus on the output queue of router R1; it is here that packet delay and packet loss will occur if the aggregate sending rate of the H1 and H2 exceeds 1.5 Mbps.

Scenario 1: mixed FTP and audio Example: 1Mbps IP phone, FTP share 1.5 Mbps link. Example: 1Mbps IP phone, FTP share 1.5 Mbps link. bursts of FTP can fill the queue, congest router and cause audio loss bursts of FTP can fill the queue, congest router and cause audio loss want to give priority to audio over FTP want to give priority to audio over FTP packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principle 1 R1 R2

Scenario 2: mixed audio and high priority FTP Example: 1Mbps IP phone, FTP share 1.5 Mbps link. Example: 1Mbps IP phone, FTP share 1.5 Mbps link. Suppose FTP user has purchased "platinum service “ While audio user has purchased cheap service packet classification needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principle 1 R1 R2

Scenario 3: A Misbehaving Audio Application and an FTP Transfer what if applications misbehave (audio sends higher than declared rate) what if applications misbehave (audio sends higher than declared rate) policing: force source adherence to bandwidth allocations policing: force source adherence to bandwidth allocations marking and policing at network edge: marking and policing at network edge: similar to ATM UNI (User Network Interface) similar to ATM UNI (User Network Interface) provide protection (isolation) for one class from others, so that one flow is not adversely affected by another misbehaving flow. Principle 2 R1 R2 1.5 Mbps link 1 Mbps phone packet marking and policing

Scenario 3: A Misbehaving Audio Application and an FTP Transfer (cont.) It is possible to "police" traffic flows and a traffic flow must meet certain criteria, for example that the audio flow not exceed a peak rate of 1 Mbps. In the case of a misbehaving application, drop or delay packets that are in violation of the criteria. The marking and policing mechanisms are located at the "edge" of the network, either in the end system, or at an edge router. An alternate approach for providing isolation among traffic flows is for the link-level packet scheduling mechanism to explicitly allocate a fixed amount of link bandwidth to each application flow. i.e. allocate 1Mbps at R1 for audio and 0.5 Mbps allocated for the ftp flow. This is as if there were logical links with capacity 1.0 and 0.5 Mbps.

Scenario 4: Allocating fixed bandwidth to flows Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn ’ t use its allocation Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn ’ t use its allocation While providing isolation, it is desirable to use resources as efficiently as possible Principle 3 R1 R2 1.5 Mbps link 1 Mbps phone 1 Mbps logical link 0.5 Mbps logical link

Scenario 5: Two 1 Mbps Audio Applications over an Overloaded 1.5 Mbps Link two 1 Mbps audio connections transmit their packets over the 1.5 Mbps link. The combined data rate of the two flows (2 Mbps) exceeds the link capacity. If the two applications equally share the bandwidth, each would only receive 0.75 Mbps. This is an unacceptably low quality. there's no need even to transmit any audio packets in the first place.

A call admission process is needed in which flows declare their QoS requirements and are then either admitted to the network (at the required QoS) or blocked from the network (if the required QoS can not be provided by the network). Principle 4