ECE544: Communication Networks-II, Spring 2010

1. ECE544: Communication Networks-II, Spring 2010 D. Raychaudhuri Lecture 7 Includes teaching materials from 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: • Which packet to serve (transmit) next • 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 • 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 • calculate Fi for each packet • transmit packet with lowest Fi

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 Source 1 Source 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 2 3 4 5 Outbound Link 1 unit/sec

12. Congestion Avoidance • TCP approach: • Detect congestion 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 loss occurs • This is called congestion avoidance

13. Congestion Control via Feedback to Source • TCP’s “blind” approach: • Detect congestion after it happens and back off on offered rate • Increase load trying to maximize utilization until loss occurs Congestion detected (via packet loss) Additive increase Multiplicative decrease Source Rate (bps) Pkt loss cleared Time-out

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 • Drop packets before queue becomes full (early drop) • Intuition: notify senders of incipient congestion • Example: early random drop (ERD): • If qlen > drop level, drop each new packet with 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 • 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 packet • Protection from misbehaving sources • Else mark packet in a manner proportional to queue length • Notify sources of incipient congestion

19. RED Operation Min thresh Max thresh Average queue length P(drop) 1.0 MaxP Avg length minthresh maxthresh

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

21. 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

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

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

24. Components of Integrated Services architecture • Reservations (includes reservation protocol) • Admission control based on flow description and current load • Scheduling to follow through on reservation • Traffic shaping at edges to fit reservation • Some application adaptation

25. 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

26. 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” • Best effort

27. 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

28. 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

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

30. 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

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

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

33. 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

34. Admission control • When new flow, look at Rspec and Tspec and decide whether to admit or reject • Not policing

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

36. 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

37. 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)

38. 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

39. PATH messages • PATH messages carry sender’s Tspec • 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

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

41. Soft State • 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

42. 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

43. Packet classifying and scheduling • Each arriving packet must be: • classified: associated with the application reservation • fields: 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

44. 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 • only subset of speakers (filters) • mixers and translators

45. 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

46. 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

47. 7 6 5 4 3 2 1 0 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier Virtual Path Identifier Virtual ChannelIdentifier Payload Type Identifier Virtual Channel Identifier CLP Header ErrorCheck Payload(48 bytes) Traffic Management • Problem: Providing quality of service • How should ATM network resources be allocated to ensure good performance including preventing congestion, e.g., how many virtual channels should be assigned to a particular transmission link? • Solution: Traffic Management • Specify the traffic "contract" on each virtual channel/path • Route (including rejecting setup request) each virtual channel/path along a path with adequate resources (Admission Control) • Mark (via Cell Loss Priority bit) for loss all cells that violate the contract (Traffic Policing)

48. 7 6 5 4 3 2 1 0 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier Virtual Path Identifier Virtual ChannelIdentifier Payload Type Identifier Virtual Channel Identifier CLP Header ErrorCheck Payload(48 bytes) Generic Cell Rate Algorithm I for each cell arrival • For a sequence of cell arrival times, {tk}, determines which cells conform to the traffic contract • A counter scheme based on two parameters denoted GCRA(I,L) • Increment parameter: I • affects cell rate • Limit parameter: L • affects cell bursts • “Leaky bucket” • A cell that would cause the bucket to overflow is non-conforming L + I One unit leak per unit of time

49. 7 6 5 4 3 2 1 0 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier Virtual Path Identifier Virtual ChannelIdentifier Payload Type Identifier Virtual Channel Identifier CLP Header ErrorCheck Payload(48 bytes) Smooth Traffic GCRA(1.5, .5) Cell Cell NoCell Cell Cell 2 2 2 2 2 1 1 1 1 1 t- t+ t- t+ t- t+ t- t+ t- t+ Bucket fill just before and just after cell transmit time time

50. 7 6 5 4 3 2 1 0 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier Virtual Path Identifier Virtual ChannelIdentifier Payload Type Identifier Virtual Channel Identifier CLP Header ErrorCheck Payload(48 bytes) 5 5 5 5 5 Bursty Traffic GCRA(4.5, 7) Cell Cell Cell NoCell NoCell 10 10 10 10 10 t- t+ t- t+ t- t+ t- t+ t- t+ Bucket fill just before and just after cell transmit time