Congestion Control & QoS in Packet Networks

1. ECE544: Communication Networks-II, Spring 2018 D. Raychaudhuri Lecture 8 (QoS) Includes teaching materials from D. Raychaudhuri, L. Peterson

2. Today’s Lecture • Congestion control in best effort networks • Basic principles & mechanisms • FQ, WFQ, congestion feedback, TCP, RED • Quality-of-service (QoS) • Mechanisms (traffic shaping, admission control, reservation, priority queuing) • RSVP Intserv and Diffserv, RIO • Comparison to ATM (CBR, VBR; ABR)

3. Congestion Control & QoS in Packet Networks • Congestion control – reactive methods used in best effort networks • Packet scheduling at network nodes • Feedback congestion control • End-to-end • Hop-by-hop • QoS control – proactive methods used for premium or guaranteed services: • Source traffic shaping & policing at entry points • Priority queuing and packet drop at routers • End-to-end reservation and admission control

4. Network Congestion • All networks have saturating throughput • Reduction in performance beyond max capacity • Need to keep input load below G0 • Also must avoid unstable equilibrium point in overload region Unstable network load Capacity Limit Smax Overload region Traffic margin Thru Congestion control policies Normal operating Point (G0) Stable network load lines with congestion control Offered Traffic (G)

5. Queue Scheduling • A queue scheduler employs 2 strategies: • Scheduling discipline: Which packet to serve (transmit) next • Drop policy: Which packet to drop next (when required)

6. FIFO Queuing • FIFO:first-in-first-out (or FCFS: first-come-first-serve) • Arriving packets get dropped when queue is full regardless of flow or importance - implies drop-tail • Important distinction: • FIFO: scheduling discipline • Drop-tail: drop policy

7. Fair Queuing • Main idea: • maintain a separate queue for each flow currently flowing through router • router services queues in Round-Robin fashion

8. FQ illustration Flow 1 Flow 2 I/P O/P Flow n Variation: Weighted Fair Queuing (WFQ)

9. Some Complications • Packets are of different length • We really need bit-by-bit round-robin (RR) • FQ simulates bit-by-bit RR • Not feasible to interleave bits!

10. Bit-by-bit RR • Single flow: suppose clock ticks when a bit is transmitted. For packet i: • Pi: length, Ai = arrival time, Si: begin transmit time, Fi: finish transmit time. Fi = Si+Pi • Fi = max (Fi-1, Ai) + Pi • Multiple flows: clock ticks when a bit from all active flows is transmitted, that is, the clock advances by one tick when n bits are transmitted (assuming n flows) • calculate Fi for each packet • transmit packet with earliest Fi • RR is only simulated, packet in transmission is not interrupted. • If n flows have data to transmit, each gets 1/nth bandwidth.

11. Bit-by-bit RR Start with A(*,*)=0 (all pkts arrive at T=0) P(1,1) = 2 P(1,2) = 1 P(1,3) = 1 F(1,1) = 1 F(1,2) = 1.5 F(1,3) = 2 P(2,1) = 3 P(2,2) = 2 F(2,1) = 1.5 F(2,2) = 2.5 Flow 1 Flow 2 Pkt 2-2=2 units Pkt 1-3= 1 unit • Fi = max (Fi-1, Ai) + Pi Pkt 1-2= 1 unit Pkt 2-1=3 units Pkt 1-1=2 units Channel clock - 1-1 2-1 1-2 1-3 2-2

12. Weighted Fair Queuing (WFQ) • Weighted Fair Queuing (WFQ): assign a weight to each flow • Assume transmitting wq bits each time the router serves queue q (simulate in packet scheduling) • Control the percentage of the link’s bandwidth that a flow will get • The bandwidth that flow q gets (n active queues sending data): • FQ is a special case of WFQ with a weight of 1 for each queue

13. Congestion detected (via packet loss) Source Rate (bps) Time-out Congestion Control and Congestion Avoidance • TCP’s “blind” approach: • Detect congestion (loss) after it happens and back off on offered rate • Increase load trying to maximize utilization until loss occurs • Alternatively: • We can try to predict congestion and reduce rate before packets start being discarded • This is called congestion avoidance

14. Congestion Control via Router Feedback • Router has unified view of queuing behavior • Routers can distinguish between propagation and persistent queuing delays • Routers can decide on transient congestion, based on workload

15. Solving the Full Queues Problem • Router monitors the load • Drop (or mark) packets before queue becomes full (early drop) • Intuition: notify senders of incipient congestion • Simple example: • If qlen > drop level, drop (or mark) each new packet with a fixed probability p • Does not control misbehaving users

16. Random Early Detection (RED) • Motivation: • High bw-delay flows have large queues to accommodate transient congestion • TCP detects congestion from loss - after queues have built up and increase delay • Aim: • Keep throughput high and delay low • Accommodate bursts

17. Random Early Detection (RED) • Detect incipient congestion, allow bursts • Keep power (throughput/delay) high • keep average queue size low • assume hosts respond to lost packets • Avoid window synchronization • randomly mark packets, instead of dropping • Avoid bias against bursty traffic • Some protection against ill-behaved users

18. RED Algorithm • Maintain running average of queue length • If avg < minth do nothing • Low queuing, send packets through • If avg > maxth, drop all packets • Protection from misbehaving sources • Else randomly drop (or mark) some packets in a manner proportional to queue length • Notify sources of incipient congestion

19. P(drop) 1.0 MaxP Avg length minthresh maxthresh RED Operation • If AvgLen <= MinThreshold • Queue the packet • If MinThreshold < Avglen < MaxThreshold • Calculate probability P • Drop the arriving packets with probability P • If Avglen >= MaxThreshold • Drop the arriving packet • AveLen = (1-W) x AveLen + W x SampleLen Max threshold Min threshold Average queue length • Count:# of newly arriving packets that have been queued (not dropped) while AvgLen has been between the two thresholds • Count increases, P increases • Make drop more evenly distributed (Avoid bias against bursty traffic)

20. 0 4 8 16 19 31 TOS Length V ersion HLen Ident Flags Offset TTL Protocol Checksum SourceAddr DestinationAddr Pad Options (variable) (variable) Data Explicit Congestion Control • Router can signal the congestion by marking packets instead of dropping using RED • Set the ECN bit (bit 7 of the IP TOS field) in IP header • The destination copies the ECN bit into the ACK sent back to the source • The source TCP responds to the ECN bit set in the same way as a packet drop • ToS field => now used for DiffServ and ECN • Bits 0-5: Differentiated Services Code Point (DSCP) • Bit 6: ECN-capable • Bit 7: ECN

21. Quality of Service Outline Realtime Applications Integrated Services Differentiated Services

22. Sampler , Microphone Buffer , A D D A converter Speaker Realtime Applications • Require “deliver on time” assurances • must come from inside the network • Example application (audio) • sample voice once every 125us • each sample has a playback time • packets experience variable delay in network • add constant factor to playback time: playback point • Use initial buffering delay to compensate jitter, but result in longer end-to-end delay

23. Playback Buffer Packet arrival Packet generation Playback Sequence number Buffer Network delay T ime

24. Example Distribution of Delays 90% 97% 98% 99% 3 2 Packets (%) 1 50 100 150 200 Delay (milliseconds)

25. Application requirements & Services Classes • Different application requirements • Elastic: no restrict delay requirements, traditional data • Real-time: delay bound, jitter, loss • Loss: intolerant or tolerant to some loss • Delay: adaptive (e.g. lengthening/shortening the silence between words, playing back video a little slower, etc) or not adaptive • Data rate: adaptive (e.g. reduce video quality by compressing video more) or not adaptive • Different application requirements=>different service classes (not only best effort anymore) • A network that can provide these different levels of service is said to support QoS • Integrated service: fine-grained approach, provide QoS to individual applications or flows • Allow individual application flows to specify their needs to the routers using an explicit signaling mechanism (RSVP) • Scalability is an issue • Differentiated Service: coarse-grained approach, provide QoS to several classes of data or aggregated traffic • Assign packets into a small number of classes that receive differentiated treatment in the routers

26. Taxonomy of applications Applications Real-Time Elastic Loss, delay tolerant Intolerant Interactive Asynchronous adaptive Non-adaptive Rate adaptive Non-adaptive Interactive-bulk Delay adaptive Rate adaptive

27. Components of Integrated Services architecture • Flowspec: information of the flow traffic characteristics and its service • Reservations (includes reservation signaling protocol) • Admission control based on flow description and current load • Scheduling to meet the reservation • Traffic shaping at edges to fit reservation • Traffic policing to mark or drop non-conforming traffic • Some application adaptation

28. Types of guarantees • Absolute bound on delay and jitter • Absolute bound on delay only • Statistical bound on delay • No quantitative delay bound but admission control and preferential treatment • None

29. Internet service classes proposed by IETF • Guaranteed service • firm bounds on e2e delays and bandwidth • Controlled load • “a QoS closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded” • Use a queuing mechanism such as WFQ to isolate the controlled load traffic from other traffic • Admission control to limit the total amount of controlled load traffic • Best effort

30. Overview of mechanisms • Flow specification (flowspec) • type of service we require • Admission control • can the network provide the requested service? • Resource reservation protocol • RSVP • Packet scheduling

31. Flowspecs • Tspec: describes the flow’s traffic characteristics • Rspec: describes the service requested from the network

32. Traffic Shaping • Traffic shaping: control traffic in order to conform to the traffic contract by delaying packets to meet certain criteria. • To optimize or guarantee performance (lower latency, higher usable bandwidth) • commonly applied at the network edges to control traffic entering the network, but can also be applied by the traffic source or in the network • Token bucket • tokens are placed in bucket at rate r • if bucket fills, tokens are discarded • sending a packet of size P uses P tokens • if bucket has P tokens, packet sent at max rate, • else must wait for tokens to accumulate

33. Traffic Policing • Traffic policing: router monitors the flow traffic for conformity with a traffic contract • Drop or tag the packets not conforming to the TSpec that used to make the reservation • to enforce compliance with that contract • Token bucket • tokens are placed in bucket at rate r • if bucket fills, tokens are discarded • When a packet of p bytes arrives, p tokens are removed from the bucket, and the packet is sent to the network. • If fewer than p tokens are available, no tokens are removed from the bucket, and the packet is considered to be non-conformant. • Drop or mark the non-conformant packets

34. Token bucket filter • Described by 2 parameters: • token rate r: rate of tokens placed in the bucket • bucket depth B: capacity of the bucket • Operation: • tokens are placed in bucket at rate r • if bucket fills, tokens are discarded • sending a packet of size P uses P tokens • if bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

35. Token bucket operation tokens tokens tokens overflow Packet Packet Not enough tokens - wait for tokens to accumulate Enough tokens packet goes through, tokens removed

36. TB characteristics • On the long run, rate is limited to r • On the short run, a burst of size B can be sent at peak data rate • Amount of traffic entering at interval T is bounded by: • traffic = B + r*T • Information useful to admission algorithm

37. Token bucket specs Flow A: r = 1 Mbps, B=1 byte BW Flow B Flow B: r = 1 Mbps, B=1MB 2 1 Flow A 1 2 3 Time

38. Admission control • When new flow request arrives, look at Rspec and Tspec and decide whether to admit or reject • Can it provide the desired service requested by the flow, given the currently available resources without causing any previously admitted flow to receive worse service that agreed? • Not policing

39. Reservation protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

40. RSVP • Used on connectionless networks • Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted • Aims to support multicast as effectively as unicast flows - mcast apps good candidates for real-time, and are heterogeneous • Receiver-oriented approach

41. Basic message types • PATH message • RESV message • CONFIRMATION message • generated only upon request • unicast to receiver when RESV reaches node with established state • TEARDOWN message • ERROR message (if path or RESV fails)

42. Making a reservation • Receivers make reservation • Before making a reservation, receiver must know: • type of traffic sender will send (Tspec) • path the sender’s packets will follow • Both can be accomplished by sending PATH messages by the sender

43. PATH messages • PATH messages carry sender’s Tspec and sent from the sender to the receiver • Record the path from the sender to the receiver in the PATH message • Receivers send RESV messages that follow reverse path and setup reservations • If reservation cannot be made, user gets an error

44. PATH and RESV messages Sender 1 PATH R Sender 2 RESV (merged) PATH RESV R R receiver 1 R RESV receiver 2

45. Soft State • Allow increasing or decreasing the level of resource reservation • Adapt to link or router failure and topology changes • Routing protocol makes routing changes, RSVP adjusts reservation state • In absence of route or membership changes, periodic PATH and RESV msgs refresh established reservation state • When change, new PATH msgs follow new path, new RESV msgs set reservation • Non-refreshed state times out automatically

46. Router handling of RESV messages • 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 msg upstream

47. Packet classifying and scheduling • Each arriving packet must be: • classified: associated with the application reservation • Examining up to five fields in the packet: source + destination address, protocol number, source + destination port • scheduled: managed in the queue so that it receives the requested service • implementation not specified in the service model

48. RSVP and multicast • Reservations from multiple receivers for a single sender are merged together at branching points • Reservations for multiple senders may not be added up: • audio conference, not many talk at same time • Different reservation styles: • Reserve resources for all speakers • Reserve resources for any n speakers • Reserve resources for speakers A and B only

49. RSVP versus ATM (Q.2931) • RSVP • receiver generates reservation • soft state (refresh/timeout) • separate from route establishment • QoS can change dynamically • receiver heterogeneity • ATM • sender generates connection request • hard state (explicit delete) • concurrent with route establishment • QoS is static for life of connection • uniform QoS to all receivers

50. ATM Service Categories • CBR • Constant Bit Rate • Continuous flow of data with tight bounds on delay and delay variation • rt-VBR • Real-Time Variable Bit Rate • Variable bandwidth with tight bounds on delay and delay variation • nrt-VBR • Non-Real-Time Variable Bit Rate • Variable bandwidth with tight bound on cell loss • UBR • Unspecified Bit Rate • No guarantees (i.e., best effort delivery) • ABR • Available Bit Rate • Flow control on source with tight bound on cell loss