1. 1 Multimedia Networking: Beyond Best-Effort Internet

2. 2 Outline  Providing QoS in the Internet r Scheduling and policing mechanisms r Integrated services r Differentiated services

3. 3 QoS in IP Networks Thus far: “making the best of best effort” Future: next-generation Internet with QoS guarantees m Differentiated Services: differential guarantees m Integrated Services: firm guarantees r Example: guarantees an audio application 1Mbps; the remaining to 0.5Mbps to Web transfer

4. 4 Principles for QoS Guarantees packet classification: router can distinguish between different classes

5. 5 Principles for QoS Guarantees r prevents applications from misbehaving (e.g., multimedia app. sends higher than declared rate) scheduling and policing: provide protection (isolation)

6. 6 Principles for QoS Guarantees r Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn’t use its allocation high utilization: while providing isolation, it is desirable to use resources as efficiently as possible

7. 7 Principles for QoS Guarantees r Basic fact of life: cannot support traffic demands beyond link capacity call admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs

8. 8 Summary of QoS Principles

9. 9 Outline r Providing QOS in the Internet  Scheduling and policing mechanisms r Integrated services r Differentiated services

10. 10 Traffic Specification Three common-used criteria: r (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) m crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! r Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate r (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

11. 11 Traffic Specification Token Bucket: limit input to specified Burst Size and Average Rate. r bucket can hold b tokens r tokens generated at rate r token/sec unless bucket full r over interval of length t: number of packets admitted less than or equal to (r t + b).

12. 12 A More General Version of Token Bucket r A flow is characterized by three parameters (r, b, p) m b – token depth m r – average rate m p bps (peak rate, e.g., link capacity) r bps b bits ≤ p bps regulator time b slope p slope r arrival curve The traffic of a flow at the source is regulated by a token bucket: A bit is transmitted only when there is an available token Arrival curve – maximum amount of bits transmitted during time period of length t

13. 13 How is Traffic Specification Used r Part of service agreement, for admission control r For policing, scheduling then can be easier

14. 14 Scheduling Mechanisms r scheduling: choose next packet to send on link r FIFO (first in first out) scheduling: send in order of arrival to queue m discard policy: if packet arrives to full queue: who to discard? tail drop: drop arriving packet priority: drop/remove on priority basis random: drop/remove randomly

15. 15 Scheduling Policies: more Priority scheduling: transmit highest priority queued packet r multiple classes, with different priorities m class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..

16. 16 Scheduling Policies: still more round robin scheduling: r multiple classes r cyclically scan class queues, serving one from each class (if available)

17. 17 Scheduling Policies: still more Weighted Fair Queuing: r generalized Round Robin r each class gets weighted amount of service in each cycle For implementations, see backup slides on Virtual Clock.

18. 18 Delay Guarantees r token bucket, WFQ combine to guarantee upper bound on delay, i.e., QoS guarantee! WFQ token rate, r bucket size, b assigned flow rate, R D = b/R max arriving traffic

19. 19 Service Curve: Arrival and Departure Processes Network Element R in R out R in (t) = arrival process = amount of data arriving up to time t R out (t) = departure process = amount of data departing up to time t bits t delay buffer

20. 20 Traffic Envelope (Arrival Curve)  Maximum amount of traffic that a flow can send during an interval of time t slope = max average rate b(t) = envelope slope = peak rate t “burstness constraint”

21. 21 Service Curve  Assume a flow that is idle at time s and it is backlogged during the interval ( s, t )  Service curve: the minimum service received by the flow during the interval ( s, t )

22. 22 Big Picture t t slope = C t R in (t) service curve bits R out (t) arrival curve

23. 23 Delay and Buffer Bounds t S (t) = service curve Arrival curve Maximum delay Maximum buffer bits

24. 24 Service Curve-based Earliest Deadline (SCED) r Packet deadline – time at which the packet would be served assuming that the flow receives no more than its service curve r Serve packets in the increasing order of their deadlines r Properties  If sum of all service curves ≤ C*t  All packets will meet their deadlines modulo the transmission time of the packet of maximum length, i.e., L max /C bits deadline of 4-th packet 1 2 3 4 t

25. 25 Linear Service Curves: Example t bits t t arrival curves t bits tt service curves arrival process deadline computation Video FTP t Audio packets have to wait after ftp packets

26. 26 Non-Linear Service Curves: Example t bits t t Arrival curves t bits tt Service curves Arrival process Deadline computation t Video FTP Audio packets transmitted as soon as they arrive

27. 27 Outline r Providing QOS in the Internet r Scheduling and policing mechanisms  Integrated services r Differentiated services

28. 28 IETF IntServ Services r Architecture for providing QoS guarantees in IP networks for individual application sessions r Assumptions m use a common infrastructure for both real-time and non-real-time communications m resource must be explicitly managed in order to meet the requirements of real-time applications resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s

29. 29 Intserv QoS: Service Models [rfc2211, rfc 2212] Guaranteed service: r worst case traffic arrival: leaky-bucket-policed source r simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] Controlled load service: r "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element." WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic Controlled link sharing: r Sharing link among different classes

30. 30 Reference Architecture Admission Control Data In Data Out Control Plane Data Plane Scheduler Routing Messages RSVP messages Classifier RSVP Route Lookup Forwarding Table Per Flow QoS Table

31. 31 Classifier Buffer management Scheduler flow 1 flow 2 flow n … Per-flow State A Closer Look at the Data Path

32. 32 Intserv: QoS Guarantee Scenario r Resource reservation m call setup, signaling (RSVP) m traffic, QoS declaration m per-element admission control m QoS-sensitive scheduling (e.g., WFQ) request/ reply

33. 33 RSVP Protocol A flow needs performance guarantee must : r declare its QoS requirement m R-spec: defines the QoS being requested r characterize traffic it will send into network m T-spec: defines traffic characteristics r signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) m RSVP

34. 34 RSVP: Soft-state Receiver-initiated End-to-End Reservation r Sender periodically sends PATH messages to receiver R, each router updates the PATH message by increasing hop count and adding its propagation delay r When receiver R gets the PATH message, it knows m Traffic characteristics (tspec): (r,b,R) m Number of hops, propagation delay introduced by the routers r Receiver R sends back this information + required worst-case delay in RESV r Each router along path provides a per-hop delay guarantee and forwards RESV with updated info m In the simplest case, the routers can just split the delay m State timed out if not refreshed R1 R2 R3 S S R R (b,r,R,0,0) (b,r,R,2,D-D 3 ) (b,r,R,1,D- D 3 -D 2 ) (b,r,R,0,0) (b,r,R,3,D) delay budget PATH RESV (b,r,R,1,d 1 ) (b,r,R,2,d 1 +d 2 ) (b,r,R,3,d 1 +d 2 +d 3 )

35. 35 Implementing IntServ: Big Picture r Use WFQ to implement controlled link sharing among different organizations r WFQ provides guaranteed service r Controlled-load and best-effort flows are separated by priority WFQ guaranteed flow n priority 10% 30% controlled flows best effort flows WFQ guaranteed flow 1 CS department gets 50%

36. 36 Outline r Providing QOS in the Internet r Scheduling and policing mechanisms r Integrated services  Differentiated services

37. 37 IETF Differentiated Services Concerns with Intserv: r Scalability: signaling, maintaining per-flow router state difficult with large number of flows r Flexible Service Models: Intserv has only two classes. Also want “qualitative” service classes m “behaves like a wire” m relative service distinction: Platinum, Gold, Silver Diffserv approach: r simple functions in network core, relatively complex functions at edge routers (or hosts) r Don’t define service classes, provide functional components to build service classes

38. 38 DiffServ Architecture Edge router: - per-flow traffic management - marks packets as in-profile and out-profile Core router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profile packets - Assured Forwarding scheduling... r b marking

39. 39 Edge-router Packet Marking r class-based marking: packets of different classes marked differently r intra-class marking: conforming portion of flow marked differently than non-conforming one r profile: pre-negotiated rate A, bucket size B r packet marking at edge based on per-flow profile Possible usage of marking: User packets Rate A B

40. 40 Classification and Conditioning r Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 r 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive r 2 bits are currently unused

41. 41 Classification and Conditioning may be desirable to limit traffic injection rate of some class: r user declares traffic profile (eg, rate, burst size) r traffic metered, shaped if non-conforming

42. 42 Forwarding (PHB) r PHB result in a different observable (measurable) forwarding performance behavior r PHB does not specify what mechanisms to use to ensure required PHB performance behavior r Examples: m Class A gets x% of outgoing link bandwidth over time intervals of a specified length m Class A packets leave first before packets from class B

43. 43 Forwarding (PHB) PHBs being developed: r Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate m logical link with a minimum guaranteed rate r Assured Forwarding: 4 classes of traffic m each guaranteed minimum amount of bandwidth m each with three drop preference partitions

44. 44 Backup Slides

45. 45 Hard Real Time: Guaranteed Services r Service contract m Network to client: guarantee a deterministic upper bound on delay for each packet in a session m Client to network: the session does not send more than it specifies r Algorithm support m Admission control based on worst-case analysis m Per flow classification/scheduling at routers

46. 46 Soft Real Time: Controlled Load (Predicative) Service r Service contract: m Network to client: similar performance as an unloaded best-effort network m Client to network: the session does not send more than it specifies r Algorithm Support m Admission control based on measurement of aggregates m Scheduling for aggregate possible

47. 47 Generalized Processor Share: Assume we can arbitrarily divide a bit 015210468 511111 r Red session has packets backlogged between time 0 and 10 r Other sessions have packets continuously backlogged flows link Two interpretations: (1) simultaneous transmissions; 2) still round-robin, but we are allowed to transmit w i bits per round for flow I, here w i is extremely small.

48. 48 From GPS to Packet Scheduling r General Processor Share (GPS) is defined in an idealized fluid flow model m multiple queues can be serviced simultaneously m no non-preemption unit r Real systems are packet systems m only one queue is served at a given time m packet transmission will not be preempted r Goal m define packet algorithms that approximate the fluid system m maintain most of the important properties

49. 49 Implementation: Virtual Clock r V(t): virtual clock (or virtual round) r If we serve w i bits per round for a backlogged flow with weight w i, how fast will V(t) progress? where  N ac (t) – number of flows backlogged

50. 50 System Virtual Time in GPS 0412816 1/2 1/8 2*C C

51. 51 Virtual Start and Finish Times  S i k : the virtual time (round) the packet k of flow i would start in a fluid system  F i k : the virtual finish time 0412816 kk-1k+1

52. 52 Virtual Time Implementation of Weighted Fair Queueing If flow i backlogged if session j un-backlogged  a i k – arrival time of packet k of flow i  S i k – virtual starting time of packet k of flow i  F i k – virtual finishing time of packet k of flow i  L i k – length of packet k of flow i

53. 53 RSVP: Per-hop Reservation r Question:  Given (b,r,R) and target per-hop delay d m Determine: Rate allocation r a, and buffer size B a bits b slope r arrival curve d BaBa slope r a

54. 54 Diffserv Architecture r Ingress routers m Keep per flow state, police/shape traffic m Set Differentiated Service Code Point (DSCP) in Diffserv (DS) field (think of it as a general priority scheme) r Core routers m Implement Per Hop Behavior (PHB) for each DSCP m Process packets based on DSCP Ingress Egress Ingress Egress DS-1 DS-2 Edge router Core router

55. 55 Control Path r Each domain is assigned a Bandwidth Broker (BB) m usually, used to perform ingress-egress bandwidth allocation r BB is responsible to perform admission control in the entire domain r BB not easy to implement m require complete knowledge about domain m single point of failure, may be performance bottleneck m designing BB still a research problem

56. 56 Example r Achieve end-to-end bandwidth guarantee BB 1 2 3 5 7 9 sender receiver 8 profile 6 4 r Can be setup ahead of time manually

57. 57 Data Path: Edge Router classifier traffic conditioner scheduler class 1 class 2 Best-effort marked traffic Ingress per aggregate classification (e.g., user) data traffic

58. 58 Edge Router: Example Traffic Conditioning: Metering/Marking r In-profile traffic is marked: m A-bit is set in every packet r Out-of-profile (excess) traffic is unmarked m A-bit is cleared (if it was previously set) in every packet; this traffic treated as best-effort r bps b bits metering in-profile traffic out-of-profile traffic assured traffic user profile (token bucket) set A-bit clear A-bit

59. 59 Edge Router: Example Traffic Conditioning: Metering/Marking/Shaping r In-profile traffic marked: m Set P-bit in each packet r Out-of-profile traffic is delayed, and when buffer overflows it is dropped r bps b bits Metering/ Shaper/ Set P-bit in-profile traffic out-of-profile traffic (delayed and dropped) premium traffic user profile (token bucket)

60. 60 Differentiated Service (DS) Field VersionHLen TOSLength Identification Fragment offset Flags Source address Destination address TTLProtocolHeader checksum 0 48161931 Data IP header r DS field reuses the first 6 bits from the former Type of Service (TOS) byte r The other two bits are proposed to be used by Explicit Congestion Notification (ECN) DS Filed 05 6 7

61. 61 Data Path: Core Router: Example Scheduler r Packets marked with the P-bit (Premium traffic) sent at high priority r Packets marked with the A-bit (Assured traffic) and best-effort traffic sent at low priority P-bit set? A-bit set?RIO yes no yes no high priority or WFQ low priority