Quality of Service on the Internet

C. Pham DEA DISIC lecture These slides borrow material from various sources which are indicated below each slide when necessary

Slides mostly taken from Shivkumar Kalyanaraman which are mostly based on slides of Ion Stoica, Jim Kurose, Srini Seshan, Srini Keshav Multimedia, real time on the Internet

Arrival Offset Graph

Sampled Audio Playout Playout Buffer must be Point small for interactive applications q Real-time applications q Interactive applications are sensitive to packet delays (telephone) q Non-interactive applications can adapt to a wider range of packet delays (audio, video broadcasts) q Guarantee of maximum delay is useful Time-constrained applications

Document is only useful when it is completely received. This means average packet delay is important, not Document Document maximum packet delay. q Elastic applications q Interactive data transfer (e.g. HTTP, FTP) qSensitive to the average delay, not to the distribution tail q Bulk data transfer (e.g. mail and news delivery) qDelay insensitive q Best effort works well Discussion q What is the problem? q Different applications have different delay, bandwidth, and jitter needs q Some applications are very sensitive to changing network conditions: the packet arrival time distribution is important q Solutions q Make applications adaptive q Build more flexibility into network Why Better-than-Best-Effort (QoS)? q To support a wider range of applications q Real-time, Multimedia, etc q To develop sustainable economic models and new private networking services q Current flat priced models, and best-effort services do not cut it for businesses What do we have now?

Multimedia applications: network audio and video

Impairments: q excessive delay: gaps in rendered audio, video q excessive data loss Quality of Service: What is it?

Multimedia applications: network audio and video

QoS network provides application with level of performance needed for application to function. What is QoS? q “Better performance” as described by a set of parameters or measured by a set of metrics. q Generic parameters: q Bandwidth q Delay, Delay-jitter q Packet loss rate (or loss probability) q Transport/Application-specific parameters: q Timeouts q Percentage of “important” packets lost What is QoS (contd) ? q These parameters can be measured at several granularities: q “micro” flow, aggregate flow, population. q QoS considered “better” if q more parameters can be specified q QoS can be specified at a fine-granularity. q QoS spectrum:

Best Effort Leased Line QoS: why don’t we have it? q QoS a concern since early 1980’s q Look at what’s happened since 1980:huge q Internet Thenow a Internetmillion times is larger! a q applications:transformative WWW, Napster, EBay, success Gopher ! q Why limited progress on QoS? q lots of smart people working on it!

Why is the QoS problem so hard? Why was the WWW so “easy”?

Implemented in hosts, servers at “network edge” WWW WWW q “on top of” existing network server brower q “complexity at network edge” q no changes to network core Why is QoS more difficult? q today’s Internet core provides “best effort” “The different timing service and reliability constraints q network congestion causes delays, loss of real-time communication change the q no timing guarantees requiretherefore new... protocols and q no loss guarantees architecturescore to be q multimedia requires loss, developed”architecture timing constraints met wet-behind-the-ears researcher, 1982.

New architecture needed for network core! Improving QOS in IP Networks q IETF groups are working on proposals to provide better QOS control in IP networks, i.e., going beyond best effort to provide some assurance for QOS q Work in Progress includes RSVP, Differentiated Services, and Integrated Services q Simple model for sharing and congestion studies: Principles for QOS Guarantees q Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. q bursts of FTP can congest the router and cause audio packets to be dropped. q want to give priority to audio over FTP q PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principles for QOS Guarantees (more) q Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above); q PRINCIPLE 2: provide protection (isolation) for one class from other classes q Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges: Principles for QOS Guarantees (more) q 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 q PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible Principles for QOS Guarantees (more) q Cannot support traffic beyond link capacity q PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs Summary How to upgrade the Internet for QoS? q Approach: de-couple end-system evolution from network evolution q End-to-end protocols: RTP, H.323, etc to spur the growth of adaptive multimedia applications q Assume best-effort or better-than-best-effort clouds q Network protocols: IntServ, DiffServ, RSVP, MPLS, COPS … q To support better-than-best-effort capabilities at the network (IP) level CONGESTION CONTROL La congestion de plus près

10 Mbps 1.5 Mbps 100 Mbps q Une congestion peut survenir lorsque trop de paquets sont injectés dans le réseau et prennent des routes similaires. Il y a alors augmentation du temps d'attente et risque perdre des paquets. q Une congestion peut aussi survenir du fait de la différence de puissance de traitement d'un routeur à l'autre. L'agrégation du trafic est une source de congestion importante et difficile à maîtriser dans les réseaux. Congestion: A Close-up View q knee – point after packet knee cliff which loss q throughput increases very slowly q delay increases fast congestion collapse q cliff – point after Throughput which q throughput starts to decrease very fast to Load zero (congestion y la collapse) De q delay approaches infinity q Note (in an M/M/1 queue) q delay = 1/(1 – utilization) Load Congestion Control vs. Congestion Avoidance q Congestion control goal q stay left of cliff q Congestion avoidance goal q stay left of knee q Right of cliff: knee cliff q Congestion collapse

congestion collapse Throughput

Load Le contrôle de congestion: principes q Réactif q lorsque la congestion est détectée, informer les noeuds en amont et en aval, q puis, marquer des paquets, rejeter des paquets, traiter les paquets prioritaires. q Préventif q diffusion périodique d'informations d'états (taille des buffers) q contrôle continue de la source (Leacky Bucket, Token Bucket...), q contrôle de flux, contrôle d'admission. q De bout en bout q pas de retour du réseau q la congestion est estimée grâce à l'observation des pertes et des délais de bout-en-bout q Assisté par le réseau q bit d'annonce de congestion (SNA, DECbit, TCP/ECN, FR, ATM) Le contrôle de flux, pour le récepteur q Fenêtrage q l'émetteur utilise une fenêtre d'anticipation dans laquelle il va pouvoir envoyer une certaine quantité de données sans acquittements q la taille de cette fenêtre peut être choisie par le récepteur à la phase de connexion q si l'émetteur respecte les règles, le récepteur ne sera pas surchargé.

Cela ne garantit pas que le contrôle de flux sera efficace pour le réseau (voir figure suivante). Problème d’un réseau trop faible Le contrôle de flux pour le réseau q Ex: principe du contrôle de congestion dans TCP q chaque émetteur maintient une deuxième fenêtre de congestion pour le réseau, q la quantité d'information qu'il est autorisé à transmettre par anticipation est le minimum des 2 fenêtres q initialement, la fenêtre de congestion est mise à K octets, l'émetteur envoie les données et arme un temporisateur, q si les données sont acquittées avant l'expiration du temporisateur, on augmente K, et ainsi de suite jusqu'à (i) l'expiration d'un temporisateur ou, (ii) la taille de la fenêtre du récepteur a été atteinte. q C'est le principe du "slow start" Slow Start q La fenêtre de cwnd = 1 segment 1

congestion ACK for segment 1 augmente en fait cwnd = 2 segment 2 segment 3 très rapidement! ACK for segments 2 + 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7

ACK for segments 4+5+6+7 cwnd = 8 Le contrôle de congestion dans TCP

q seuil initial a 64K, on augmente K exponentiellement avant et linéairement après (congestion avoidance), q si perte, divise le seuil par 2, et on recommence avec K=1 Utilisation du Round Trip Time

One RTT 0R 1

One pkt time

1R 1 2 3 2R 2 3 4 6 5 7 4 5 6 7 3R 8 10 12 14 9 11 13 15 Slow Start Sequence Plot

. . .

Sequence No La fenêtre de congestion double à chaque aller/retour

Time TCP Reno (Jacobson 1990) window

time SS CA

SS: Slow Start CA: Congestion Avoidance Fast retransmission/fast recovery TCP Vegas (Brakmo & Peterson 1994) window

time SS CA q Converges, no retransmission q … provided buffer is large enough Queuing Disciplines

q Each router must implement some queuing discipline q Queuing allocates bandwidth and buffer space: q Bandwidth: which packet to serve next (scheduling) q Buffer space: which packet to drop next (buff mgmt) q Queuing also affects latency Traffic Traffic Sources Classes Class A Class B Class C Drop Scheduling Buffer Management Typical Internet Queuing q FIFO + drop-tail q Simplest choice q Used widely in the Internet q FIFO (first-in-first-out) q Implies single class of traffic q Drop-tail q Arriving packets get dropped when queue is full regardless of flow or importance q Important distinction: q FIFO: scheduling discipline q Drop-tail: drop (buffer management) policy FIFO + Drop-tail Problems q FIFO Issues: In a FIFO discipline, the service seen by a flow is convoluted with the arrivals of packets from all other flows! q No isolation between flows: full burden on e2e control q No policing: send more packets ‡ get more service q Drop-tail issues: q Routers are forced to have have large queues to maintain high utilizations q Larger buffers => larger steady state queues/delays q Synchronization: end hosts react to same events because packets tend to be lost in bursts q Lock-out: a side effect of burstiness and synchronization is that a few flows can monopolize queue space Design Objectives q Keep throughput high and delay low (i.e. knee) q Accommodate bursts q Queue size should reflect ability to accept bursts rather than steady-state queuing q Improve TCP performance with minimal hardware changes Queue Management Ideas q Synchronization, lock-out: q Random drop: drop a randomly chosen packet q Drop front: drop packet from head of queue q High steady-state queuing vs burstiness: q Early drop: Drop packets before queue full q Do not drop packets “too early” because queue may reflect only burstiness and not true overload q Misbehaving vs Fragile flows: q Drop packets proportional to queue occupancy of flow q Try to protect fragile flows from packet loss (eg: color them or classify them on the fly) q Drop packets vs Mark packets: q Dropping packets interacts w/ reliability mechanisms q Mark packets: need to trust end-systems to respond! Packet Drop Dimensions

Aggregation Per-connection state Single class

Class-based queuing

Drop position Head Tail

Random location

Early drop Overflow drop Random Early Detection (RED)

Max thresh Min thresh

Average Queue Length P(drop)

1.0

maxP

minth maxth Avg queue length Random Early Detection (RED) q Maintain running average of queue length q Low pass filtering q If avg Q < minth do nothing q Low queuing, send packets through q If avg Q > maxth, drop packet q Protection from misbehaving sources q Else mark (or drop) packet in a manner proportional to queue length & bias to protect against synchronization

q Pb = maxp(avg - minth) / (maxth - minth)

q Further, bias Pb by history of unmarked packets

q Pa = Pb/(1 - count*Pb) RED Issues q Issues: q Breaks synchronization well q Extremely sensitive to parameter settings q Wild queue oscillations upon load changes q Fail to prevent buffer overflow as #sources increases q Does not help fragile flows (eg: small window flows or retransmitted packets) q Does not adequately isolate cooperative flows from non- cooperative flows q Isolation: q Fair queuing achieves isolation using per-flow state q RED penalty box: Monitor history for packet drops, identify flows that use disproportionate bandwidth RED with Multiple Thresholds

Discard “Red”“Red” “Y“Yeellow”llow” “G“Green”reen” Probability PPaacckkeetsts PPaacckkeetsts PPaacckkeetsts 1

Average Queue Length 0 0 “Red” “Yellow” “Green” Full Threshold Threshold Threshold source Juha Heinänen REM Athuraliya & Low 2000 q Main ideas q Decouple congestion & performance measure q “Price” adjusted to match rate and clear buffer q Marking probability exponential in `price’

y t i REM l RED i 1 b a 0.9 b o r 0.8 p 1

g 0.7 n i 0.6 k r a 0.5 m

k 0.4 n i 0.3 L 0.2

0.1

0 0 2 4 6 8 10 12 14 16 18 20 Link congestion measure

Avg queue Comparison of AQM Performance

REM queue = 1.5 pkts DropTail utilization = 92% queue = 94% g = 0.05, a = 0.4, f = 1.15

RED min_th = 10 pkts max_th = 40 pkts max_p = 0.1 QoS ARCHITECTURES Stateless vs. Stateful QoS Solutions q Stateless solutions – routers maintain no fine grained state about traffic

£ scalable, robust

§ weak services q Stateful solutions – routers maintain per-flow state

£ powerful services qguaranteed services + high resource utilization qfine grained differentiation qprotection

§ much less scalable and robust Integrated Services (IntServ) q An architecture for providing QOS guarantees in IP networks for individual application sessions q Relies on resource reservation, and routers need to maintain state information of allocated resources (eg: g) and respond to new Call setup requests Integrated Services Model q Flow specification q Leacky Bucket, Token Bucket q Routing q Admission control q Policy control q Resource reservation q RSVP q Packet scheduling q WFQ, CBQ, RED Integrated Services: Classes q Guaranteed QOS: this class is provided with firm bounds on queuing delay at a router; envisioned for hard real-time applications that are highly sensitive to end-to-end delay expectation and variance q Controlled Load: this class is provided a QOS closely approximating that provided by an unloaded router; envisioned for today’s IP network real-time applications which perform well in an unloaded network Signaling semantics q Classic scheme: sender initiated q SETUP, SETUP_ACK, SETUP_RESPONSE q Admission control q Tentative resource reservation and confirmation q Simplex and duplex setup; no multicast support RSVP for the IntServ approach

q Resource reSerVation Protocol q What is RSVP? q Method for application to specify desired QoS to net q Switch state establishment protocol (signaling) q Multicast friendly, receiver-oriented q Simplex reservations (single direction) q Why run RSVP? q Allows precise allocation of network resources q Guarantees on quality of service q Heterogeneous bandwidth support for multicast q Scalable (?) source Gordon Schaffee Resource Reservation q Senders advertise using PATH message q Receivers reserve using RESV message q Flowspec + filterspec + policy data q Travels upstream in reverse direction of Path message q Merging of reservations q Sender/receiver notified of changes RSVP Functional Diagram

Host Router

RSVPD RSVPD

Routing Application Process Policy Policy Control Control D A T Admissions Admissions A Control Control

Packet Packet DATA Packet Packet DATA Classifier Scheduler Classifier Scheduler Stateful Solution: Guaranteed Services

q Achieve per-flow bandwidth and delay guarantees q Example: guarantee 1MBps and < 100 ms delay to a flow Receiver Sender