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