1. ECE544: Communication Networks-II, Spring 2006 D. Raychaudhuri & Max Ott Lecture 7 Includes teaching materials from L. Peterson

2. Today’s Lecture Quality-of-service (QoS) in IP and ATM

3. Today’s Lecture Quality-of-service (QoS) in IP and ATM

4. Congestion Control Mechanisms to prevent overload on the network and hence maintain QoS –End-to-end flow control (e.g. TCP) –Hop-by-hop flow control (e.g. ECN) –Packet scheduling at each network element

5. Network Congestion All networks have saturating throughput –Reduction in performance beyond max capacity –Need to keep input load below G 0 Overload region Normal operating Point (G 0 ) Capacity Limit S max Offered Traffic (G) Thru Traffic margin Congestion control policies

6. Queue Scheduling A queue scheduler employs 2 strategies: –Which packet to serve (transmit) next –Which packet to drop next (when required)

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

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

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

10. 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!

11. Max-min Fairness Allocate user with “small” demand what it wants, evenly divide unused resources to “big” users Formally: Resources allocated in terms of increasing demand No source gets resource share larger than its demand Sources with unsatisfied demands get equal share of resource

12. Max-min Fairness Example Assume sources 1..n, with resource demands X1..Xn in ascending order. Assume channel capacity C. –Give C/n to X1; if this is more than X1 wants, divide excess (C/n - X1) to other sources: each gets C/n + (C/n - X1)/(n-1) –If this is larger than what X2 wants, repeat process Bit-by-bit RR achieves max-min fairness

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

14. Bit-by-bit RR example F=10 Flow 1 (arriving) Flow 2 transmitting Output F=2 F=5 F=8 Flow 1Flow 2 Output F=10 Cannot preempt packet currently being transmitted

15. Congestion Avoidance We have seen TCP’s approach: –Detect congestion after it happens –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

16. Router Congestion Notification 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

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

18. Other Options Random drop: –Packet arriving when queue is full causes some random packet to be dropped Drop front: –On full queue, drop packet at head of queue Random drop and drop front solve the lock-out problem but not the full- queues problem

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

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

21. RED Algorithm Maintain running average of queue length If avg < min th do nothing –Low queuing, send packets through If avg > max th, drop packet –Protection from misbehaving sources Else mark packet in a manner proportional to queue length –Notify sources of incipient congestion

22. RED Operation Min thresh Max thresh Average queue length minthreshmaxthresh MaxP 1.0 Avg length P(drop)

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

24. 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 Microphone Speaker Sampler, A D converter Buffer, D A

25. Playback Buffer Sequence number Packet generation Network delay Buffer Playback Time Packet arrival

26. Example Distribution of Delays 1 2 3 Packets (%) 90%97%98%99% 15020010050 Delay (milliseconds)

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

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” Best effort

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

31. Statistical multiplexing Share output link among many sources Strong law of large numbers: –Given large set of uncorrelated flows, total BW required nearly constant even if individual flows vary a lot –Intuition: if many flows, then each is small compared to aggregate and bursts come at different times –if correlated, bursts come at same time

32. Self-similarity Problem: self-similarity persists at all levels Burstiness even for aggregates Heavy-tailed distributions at all aggregations

33. Utility curve shapes BW U U U Stay to the right and you are fine for all curves ElasticHard real-time Delay-adaptive

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

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

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

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

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

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

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

41. Parekh bound on delay across net Di = (bucket size/weighted rate allocated) + [(nhops - 1) * MaxPacketLen / weighted rate allocation] +  m=1 to hopi (max packet length / outbound bw at hop) –1st term: delay when running at full speed –2nd term: packetization effects –3rd term: added delay due to packet approx of FQ (goes away as data rate increases)

42. Reservation protocol: RSVP Upper layer protocols and applications IP Link layer modules ICMPIGMPRSVP IP service interface Link layer service interface

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

44. Role of RSVP Rides on top of unicast/multicast routing protocols Carries resource requests all the way through the network At each hop consults admission control and sets up reservation. Informs requester if failure RSVP only carries messages

45. Changing reservation Receiver-oriented approach and soft state make it easy to modify reservation Modification sent with periodic refresh

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

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

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

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

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

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

52. 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, left up to the implementors

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

54. RSVP deployment Authentication and access control Accounting and charging Policy control Future direction? –tightly coupled with the future direction of the Internet service model

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

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

57. 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)76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier Payload Type Identifier

58. Generic Cell Rate Algorithm For a sequence of cell arrival times, {t k }, 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 One unit leak per unit of time I for each cell arrival L + I 76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier Payload Type Identifier

59. Smooth Traffic CellCell No Cell Bucket fill just before and just after cell transmit time GCRA(1.5,.5) t+t- 1 2 t+t- 1 2 t+t- 1 2 t+t- 1 2 CellCell t+t- 1 2 time76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier Payload Type Identifier

60. Bursty Traffic 5 10 t+t- 5 10 t+t- 5 10 t+t- 5 10 t+t- 5 10 t+t- CellCellCell No Cell Bucket fill just before and just after cell transmit GCRA(4.5, 7) time76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier Payload Type Identifier

61. Bit 3: Used to discriminate data cells from operation, administration, maintenance cells. Bit 2: Used to indicate congestion in data cells (Bit 3 = 0) –Set by Switches –Source and Destination Behavior Defined for Available Bit Rate Flow Control VCC’s Bit 1: Carried transparently end-to-end in data cells –Used by AAL5 Payload Type Identifier 76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier C

62. Source Destination +++ Forward RM* Cells Congestion Indication ++ Rate Indication Rate & Congestion Indication *- Resource Management Backward RM* Cells B ABR Feedback Source sets Actual Cell Rate based on rate & congestion feedbackSource sets Actual Cell Rate based on rate & congestion feedback Payload Type Identifier 76543210 Generic Flow Control Virtual Path Identifier Virtual Channel Identifier CLP Header Error Check Payload (48 bytes) Virtual Channel Identifier

63. Example Source Cell Rate Profile Peak Cell Rate Minimum Cell Rate Actual Cell Rate Time Network Congestion C

64. DiffServ Analogy: –airline service, first class, coach, various restrictions on coach as a function of payment Best-effort expected to make up bulk of traffic, but revenue from first class important to economic base (will pay for more plentiful bandwidth overall) Not motivated by real-time! Motivated by economics and assurances

65. Types of service Premium service: (type P) –admitted based on peak rate –conservative, virtual wire services –unused premium goes to best effort (subsidy!) Assured service: (type A) –based on expected capacity usage profiles –traffic unlikely to be dropped if user maintains profile. Out-of-profile traffic marked

66. Differences with RSVP No need for reservations: just mark packets Packet marking can be done at administrative boundaries before injecting packets into network Significant savings in signaling, much simpler overall

67. Premium service User sends within profile, network commits to delivery with requested profile Simple forwarding: classify packet in one of two queues, use priority Shaping at trust boundaries only, using token bucket Signaling, admission control may get more elaborate, but still not end-to-end

68. Premium traffic flow first hop router internal router border router host border router ISP Company A Unmarked packet flow Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec

69. 2-bit differentiated service Precedence field encodes P & A type packets P packets are queued at higher priority than ordinary best effort A packets treated preferentially wrt dropping probability in the normal queue Leaf and border routers have input and output tasks - other routers just output

70. Leaf router input functionality Clear A & P bits Packet classifier Marker 1 Marker N Forwarding engine Arriving packet Best effort Flow 1 Flow N Markers: service class, rate, permissible burst size

71. Marker function in routers Leaf routers have traffic profiles - they classify packets based on packet header If no profile present, pass as best effort If profile is for A: –mark in-profile packets with A, forward others unmarked If profile is for P: –delay out-of -profile packets to shape into profile

72. Markers to implement two different services Wait for token Set P bit Packet input Packet output Test if token Set A bit token No token Packet input Packet output Drop on overflow

73. Output forwarding 2 queues: P packets on higher priority queue Lower priority queue implements RED “In or Out” scheme (RIO) At border routers profile meters test marked flows: –drop P packets out of profile –unmark A packets

74. Router output interface for two-bit architecture P-bit set? If A-bit set incr A_cnt High-priority Q Low-priority Q If A-bit set decr A_cnt RIO queue management Packets out yes no

75. Border router input interface Profile Meters Arriving packet Is packet marked? Token available? Token available? Clear A-bit Drop packet Forwarding engine A set P set token Not marked no

76. Red with In or Out (RIO) Precursor to Assured Forwarding (AF) PHB Similar to RED, but with two separate probability curves Has two classes, “In” and “Out” (of profile) “Out” class has lower Minthresh, so packets are dropped from this class first As avg queue length increases, “in” packets are dropped

77. RIO drop probabilities MaxP 1.0 Min out Min in Max in Max out P(drop) AvgLen

78. 78 Today’s Homework Peterson & Davie, Chap 4,6 -6.13 -6.32 -6.43 -6.44 -6.45 Download and browse RSVP & DiffServe RFC’s