MULTIMEDIA NETWORKING

Transcription

1 MULTIMEDIA NETWORKING AND QOS PROVISION A note on the use of these ppt slides: The notes used in this course are substantially based on powerpoint slides developed and copyrighted by J.F. Kurose and K.W. Ross, 2007

2 Multimedia and Quality of Service: What is it? multimedia applications: network audio and video ( continuous media ) QoS network provides application with level of performance needed for application to function.

3 MM Networking Applications Classes of MM applications: 1) stored streaming 2) live streaming 3) interactive, real-time Jitter is the variability of packet delays within the same packet stream Fundamental characteristics: typically delay sensitive end-to-end delay delay jitter loss tolerant: infrequent losses cause minor glitches antithesis of data, which are loss intolerant but delay tolerant.

4 Streaming Stored Multimedia Stored streaming: r r r media stored at source transmitted to client streaming: client playout begins before all data has arrived r timing constraint for still-to-be transmitted data: g in time for playout

5 Streaming Stored Multimedia: What is it? 1. video recorded 2. video sent network delay 3. video received, played out at client time streaming: at this time, client playing out early part of video, while server still sending later part of video

6 Streaming Live Multimedia Examples: Internet radio talk show live sporting event Streaming (as with streaming stored multimedia) playback buffer playback can lag tens of seconds after transmission still have timing constraint Interactivity fast forward impossible rewind, pause possible!

7 Real-Time Interactive Multimedia Applications: IP telephony, video conference, distributed interactive worlds End-end delay requirements: audio: < 150 msec good, < 400 msec OK includes application-level (packetization) and network delays higher delays noticeable, impair interactivity Session initialization how does callee advertise its IP address, port number, encoding algorithms?

8 Multimedia Over Today s Internet TCP/UDP/IP: best-effort service no guarantees on delay, loss??????? But you said multimedia apps requires QoS and level of performance to be? effective!??? Today s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss

9 How should the Internet Evolve to Better Support Multimedia? Integrated services philosophy: fundamental changes in Internet so that t apps can reserve end-toend bandwidth requires new, complex software in hosts & routers Laissez-faire no major changes more bandwidth when needed content t distribution, ib ti applicationlayer multicast Differentiated services philosophy: fewer changes to Internet infrastructure, t yet provide 1st and 2nd class service application layer What s your opinion?

10 Internet Quality of Service Principles for QoS Traffic Policing and Scheduling Policies Lucky Buckets, Weighted Fair Queueing, Internet QoS Architectures and beyond InterServ Architecture DiffServ Architecture

11 Improving QOS in IP Networks Thus far: making the best of best effort Future?: next generation Internet with QoS guarantees RSVP: signaling for resource reservations Differentiated Services: differential guarantees Integrated Services: firm guarantees i l d l f simple model for sharing and congestion studies:

12 Principles for QoS Guarantees Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. bursts of FTP can congest the router and cause audio packets to be dropped. want to give priority to audio over FTP PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly e.g. MPLS, Diffserv, RSVP

13 Principles for QoS Guarantees (cont) Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above); PRINCIPLE 2: provide protection (isolation) for one class from other classes Require Policing i Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges: e.g. leaky bucket, WFQ

14 Principles for QoS Guarantees (more) 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 PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible 14

15 Principles for QoS Guarantees (more) Cannot support traffic beyond link capacity PRINCIPLE 4: Need a Signaling or Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs

16 Four Pillars of QoS

17 Internet Quality of Service Principles for QoS Traffic Policing and Scheduling Policies Lucky Buckets, Weighted Fair Queueing, Internet QoS Architectures and beyond InterServ Architecture DiffServ Architecture

18 Traffic Policing Mechanisms Three criteria: (Long term) Average Rate (100 packets per sec or 6000 packets per min??), crucial aspect is the interval length Peak Rate: e.g., 6000 pkts per minute Avg and 1500 pkts per sec Peak (Max.) Burst Size: Max. number of pkts sent consecutively, ie over a short period of time 18

19 Leaky/Token Bucket Mechanism Leaky/Token Bucket mechanism, provides a means for limiting input to specified Burst Size and Average Rate Leaky: when token bucket full, tokens lost

20 Dual Leaky/Token Bucket Limiting input to specified Burst Size σ Average Rate ρ and Peak Rate R one with buffer: token rate r and buffer size b another with no buffer: token rate p in practice: needs to be packetized - buffer of max. packet size M r tokens/sec b p tokens/sec M packets min

21 Packet Scheduling Scheduling: choosing the next packet for transmission on a link can be done following a number of policies Pre-emptive vs. non-preemptive: non-preemptive: packet currently being transmitted will not be terminated -- - assumed in most scheduling algorithms Work-conserving vs. non-work-conserving work-conserving: whenever there are packets queued, scheduler will schedule a packet for transmission non-work-conserving: transmission may be idle even there may be packets queued

22 Scheduling Policy: FIFO FIFO: in order of arrival to the queue; packets that arrive to a full buffer are either discarded, or a discard policy is used to determine which packet to discard among the arrival and those already queued Simplest scheduling policy, default policy

23 Scheduling Policy: Priority Queueing Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, e.g. IP source or destination, TCP Port numbers, etc. Transmit a packet from the highest priority class with a nonempty queue Preemptive and non-preemptive versions

24 Scheduling Policy: Round Robin Round Robin: scan class queues serving one from each class that has a non-empty queue Extension: weighted round robin

25 Scheduling Policy: WFQ Weighted Fair Queuing (WFQ): is a generalized Round Robin no concept of round, no fixed order of serving queues based on fluid model : if queue e assigned a weight w i, and is served ed with (a minimum) rate w i C when backlogged (non-empty) C link capacity, w i =1 if all queues backlogged, each queue served at rate of w i C; otherwise, spare capacity proportionally allocated to each backlogged queue (thus the name fair queueing!)

26 Internet Quality of Service Principles for QoS Traffic Policing and Scheduling Policies Lucky Buckets, Weighted Fair Queueing, Internet QoS Architectures and beyond InterServ Architecture DiffServ Architecture

27 IETF Integrated Services Architecture for providing QOS guarantees in IP networks for individual application sessions Resource reservation: routers maintain state info (a la VC) of allocated resources, QoS requests Admit/deny new call setup requests: Question: can newly arriving flow be admitted with Performance guarantees while not violated QoS guarantees made to already admitted ittd flows?

28 Components of Integrated Services 1. Type of commitment What does the network promise? 2. Packet scheduling How does the network meet promises? 3. Service interface How does the application describe what it wants? 4. Establishing the guarantee How is the promise communicated to/from the network How is admission of new applications controlled?

29 1. Type of Commitment t What kind of promises/services should network offer? Depends on the characteristics of the applications that will use the network.

30 Playback Applications Sample signal packetize transmit buffer playback Fits most multimedia applications Performance concern: Jitter variation in end-to-end delay Delay = fixed + variable = (propagation + packetization) + queuing Solution: Playback point delay introduced d by buffer to hide network jitter

31 Characteristics of Playback Applications In general lower delay is preferable Doesn t matter when packet arrives as long as it is before playback point Network guarantees (e.g., bound on jitter) would make it easier to set playback point Applications can tolerate some loss

32 Applications Variations Rigid and adaptive applications Rigid: set fixed playback point Adaptive: adapt playback point Gamble that network conditions will be the same as in the past Are prepared to deal with errors in their estimate t Will have an earlier playback point than rigid applications Tolerant and intolerant applications Tolerance to brief interruptions in service Four combinations

33 Applications Variations Really only two classes of applications Intolerant and rigid Tolerant and adaptive Other combinations make little sense Intolerant and adaptive - Cannot adapt without interruption Tolerant and rigid - Missed opportunity to improve delay So what service classes should the network offer?

34 Type of Commitments Guaranteed service For intolerant and rigid applications Fixed guarantee, network meets commitment as long as clients send at match traffic agreement Predicted service For tolerant and adaptive applications Two components If conditions do not change, commit to current service If conditions change, take steps to deliver consistent performance (help apps minimize playback delay) Implicit assumption network kdoes not change much over time Datagram/best effort service

35 Components of Integrated Services 1. Type of commitment What does the network promise? 2. Packet scheduling How does the network meet promises? 3. Service interface How does the application describe what it wants? 4. Establishing the guarantee How is the promise communicated to/from the network How is admission of new applications controlled?

36 Scheduling for Guaranteed Traffic Use token bucket filter to characterize traffic Described by rate r and bucket depth b Use WFQ at the routers Parekh s bound for worst case queuing delay = b/r b = bucket depth r = rate of arrival

37 Parekh Bound on Delay Across Net D i = (bucket size/weighted rate allocated) + [(nhops 1)*MaxPacketLen/weighted rate allocation] + Σ m=1 to hop i (max packet length / outbound bandwidth 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)

38 Token Bucket Filter Tokens enter bucket at rate r Operation: If bucket fills, tokens are discarded Bucket depth b: Sending a packet of size P uses capacity of bucket P tokens If bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate

39 Token Bucket Operation Tokens Tokens Tokens Overflow Packet Enough tokens packet goes through, tokens removed Packet Not enough tokens wait for tokens to accumulate

40 Token Bucket Characteristics In long run, rate is limited to r In 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

41 Predicted Service Goals: Isolation Isolates well-behaved bh dfrom misbehaving bh sources Sharing Mixing i of different sources in a way beneficial i to all Mechanisms: WFQ Great isolation but no sharing FIFO Great sharing but no isolation

42 Predicted Service FIFO jitter increases with the number of hops Use opportunity for sharing across hops FIFO+ At each hop: measure average delay for class at that router For each packet: compute difference of average delay and delay of that packet in queue Add/subtract difference in packet header Packet inserted into queues expected arrival time instead of actual More complex queue management! age e Slightly decreases mean delay and significantly decreases jitter

43 Unified Scheduling Assume three types of traffic: guaranteed, predictive, besteffort Scheduling: use WFQ in routers Each guaranteed flow gets its own queue All predicted service flows and best effort aggregates in single separate queue Predictive traffic classes Multiple FIFO+ queues Worst case delay for classes separated by order of magnitude When high priority needs extra bandwidth steals it from lower class Best effort traffic acts as lowest priority class

44 Service Interfaces Guaranteed Traffic Host specifies rate to network Why not bucket size b? If delay not good, ask for higher rate Predicted d Traffic Specifies (r, b) token bucket parameters Specifies delay D and loss rate L Network assigns priority class Policing i at edges to drop or tag packets Needed to provide isolation why is this not done for guaranteed traffic? WFQ provides this for guaranteed traffic

45 Components of Integrated Services 1. Type of commitment What does the network promise? 2. Packet scheduling How does the network meet promises? 3. Service interface How does the application describe what it wants? 4. Establishing the guarantee How is the promise communicated How is admission of new applications controlled?

46 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 At each hop consults admission control and sets up reservation. Informs requester if failure

47 RSVP Goals Used on connectionless networks Should not replicate routing functionality Should co-exist with route changes Support for multicast Different receivers have different capabilities and want different QOS Changes in group membership should not be expensive Reservations should be aggregate I.e. each receiver in group should not have to reserve Should be able to switch allocated resource to different senders Modular design should be generic signaling protocol Result Receiver-oriented Soft-state

48 RSVP Service Model Make reservations for simplex data streams Receiver decides whether to make reservation Control msgs in IP datagrams (proto #46) PATH/RESV sent periodically to refresh soft state One pass: Failed requests return error messages - receiver must try again No e2e ack for success

49 Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

50 PATH Messages PATH messages carry sender s Tspec Token bucket parameters 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

51 RESV Messages Forwarded via reverse path of PATH Queuing delay and bandwidth requirements Source traffic characteristics (from PATH) Filter specification Which transmissions can use the reserved resources Router performs admission control and reserves resources If request rejected, send error message

52 PATH and RESV Messages Sender 1 PATH Sender 2 PATH R RESV (merged) RESV R R Receiver 1 R RESV Receiver 2

53 Routing Changes Routing protocol makes routing changes 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

54 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

55 Basic Architecture Agreements/service provided d within a domain Service Level Agreement (SLA) with ISP Edge routers do traffic conditioning Perform per aggregate shaping and policing Mark packets with a small number of bits; each bit encoding represents a class or subclass Core routers Process packets based on packet marking and defined per hop behavior More scalable than IntServ More scalable than IntServ No per flow state or signaling

56 Per-hop Behaviors (PHBs) Define behavior of individual routers rather than endto-end services; there may be many more services than behaviors Multiple behaviors need more than one bit in the header Six bits from IP TOS field are taken for Diffserv code points (DSCP)

57 Per-hop Behaviors (PHBs) Two PHBs defined d so far Expedited forwarding aka premium service (type P) Possible service: providing a virtual wire Admitted based on peak rate Unused premium goes to best effort Assured forwarding (type A) Possible service: strong assurance for traffic within profile fl and allow source to exceed profile Based on expected capacity usage profiles Traffic unlikely to be dropped if user maintains profile Out-of-profile traffic marked

58 Expedited Forwarding PHB User sends within profile fl and network commits to delivery with requested profile Signaling, admission i control may get more elaborate in future Rate limiting of EF packets at edges only, using token bucket to shape transmission i Simple forwarding: classify packet in one of two queues, use priority it EF packets are forwarded with minimal delay and loss (up to the capacity of the router)

59 Expedited Forwarding Traffic Flow Packets in premium flows have bit set host internal router Premium packet flow restricted to R bytes/sec Unmarked packet flow first hop router edge router edge router

60 Assured Forwarding PHB User and network agree to some traffic profile Edges mark packets up to allowed rate as in-profile or low drop precedence Other packets are marked with one of 2 higher drop precedence values A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value Implemented using RED with In/Out bit

61 Red with In or Out (RIO) Similar to RED, but with two separate probability curves Has two classes, In and Out (of profile) Out class has lower Min thresh h, so packets are dropped from this class first Based on queue length of all packets As avg queue length increases, in packets are also dropped Based on queue length of only in packets

62 RIO Drop Probabilities P (drop in) P (drop out) P max_out P max_ in min_in max_in avg_in min_out max_out avg_total

63 Edge Router Input Functionality Traffic Conditioner 1 Arriving packet Packet classifier Traffic Conditioner N Best effort Forwarding engine Classify packets based on packet header

64 Traffic Conditioning Drop on overflow Packet input Wait for token Set EF bit Packet output No token Packet input Test if token token Set AF in bit Packet output

65 Router Output Processing Two queues: EF packets on higher priority queue Lower priority queue implements RED In or Out scheme (RIO) What DSCP? High-priority Q Packets out If in set incr in_cnt Low-priority Q RIO queue management If in set decr in_ cnt

66 Edge Router Policing Token available? no Clear in bit Arriving Is packet Forwarding packet marked? engine Token available? no Drop packet

67 Comparison Best-Effort Diffserv Intserv Service Connectivity No isolation No guarantees Per aggregation isolation Per aggregation guarantee Per flow isolation Per flow guarantee Service Scope End-to-end Domain End-to-end Complexity No set-up Long term setup Per flow setup Scalability Highly scalable (nodes maintain i only routing state) Scalable (edge routers maintains i per aggregate state; core routers per class state) Not scalable (each router maintains i per flow state)