Published on


Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 13PIT101 Multimedia Communication & Networks UNIT - III Dr.A.Kathirvel Professor & Head/IT - VCEW
  2. 2. UNIT - III Best Effort service model – Scheduling and Dropping policies – Network Performance Parameters – Quality of Service and metrics – WFQ and its variants – Random Early Detection – QoS aware Routing – Admission Control – Resource Reservation – RSVP - Traffic Shaping Algorithms – Caching – Laissez Faire Approach - Possible Architectures – An Overview of QoS Architectures
  3. 3. Quality of Service • MM systems consist of set of services • To provide generic MM services, services get parameterized with so called Quality of Service • Examples of QoS parameters: – QoS for Audio service: • Sample rate – 8000 samples/second • Sample resolution – 8 bits per sample – QoS for network service: • Throughput – 100 Mbps • Connection setup time – 50 ms
  4. 4. QoS (cont.) • QoS concept comes from networking service and was introduced for specification how good the offered network services are • Services are performed on different objects – Media sources – Media sinks – Connections • QoS specification characterizes the service objects
  5. 5. Layered Model for QoS
  6. 6. Application QoS Parameters
  7. 7. System QoS Parameters
  8. 8. Network QoS Parameters
  9. 9. QoS Classes • Guaranteed Service Class – QoS guarantees are provided based on deterministic and statistical QoS parameters • Predictive Service Class – QoS parameter values are estimated and based on the past behavior of the service • Best Effort Service Class – There are no guarantees or only partial guarantees are provided
  10. 10. QoS Classes (cont.) QoS Class determines: (a) reliability of offered QoS, (b) utilization of resources
  11. 11. Deterministic QoS Parameters • Single Value: QoS1 – average (QoSave), contractual value, threshold value, target value • Pair Value: <QoS1, QoS2> with QoS1 – required value; QoS2 – desired value Example: <QoSavg,QoSpeak>; <QoSmin, QoSmax>
  12. 12. Deterministic QoS Parameter Values • Triple of Values <QoS1, QoS2, QoS3> – QoS1 – best value – QoS2 – average value – QoS3 – worst value • Example: – <QoSpeak, QoSavg, QoSmin>, where QoS is network bandwidth
  13. 13. Guaranteed QoS • We need to provide 100% guarantees for QoS values (hard guarantees) or very close to 100% (soft guarantees) • Current QoS calculation and resource allocation are based on: 1. Hard upper bounds for imposed workloads 2. Worst case assumptions about system behavior 1. Advantages: QoS guarantees are satisfied even in the worst case case (high reliability in guarantees) 2. Disadvantage: Over-reservation of resources, hence needless rejection of requests
  14. 14. Predictive QoS Parameters • We utilize QoS values (QoS1, ..QoSi) and compute average – QoSbound step at K>i is QoSK = 1/i*∑jQoSj • We utilize QoS values (QoS1, , QoSi) and compute maximum value – QoSK = max j=1,…i (QoSj) • We utilize QoS values (QoS1, , QoSi) and compute minimum value – QoSK = min j=1,…i (QoSj)
  15. 15. Best Effort QoS • No QoS bounds or possible very weak QoS bounds • Advantages: resource capacities can be statistically multiplexed, hence more processing requests can be granted • Disadvantages: QoS may be temporally violated
  16. 16. Quality-aware Service Model • Quality-aware Autonomous Single Service – Consists of a set of functions – Accepts input data with QoS level QoSin • QoSin=[q1in,..qnin] – Generates output data with QoS level QoSout • QoSout=[q1out,..qnout] • Example: Video player service – Input QoS: [Recorded Video Frame Rate, Recorded Frame Size, Recorded Pixel Precision] – QoSin=[30fps, 640x480 pixels, 24 bits per pixel] – Output QoS: [Playback Video Frame Rate, Playback Frame Size, Playback Pixel Precision] – QoSout=[20fps, 320x240pixels, 24bits per pixel]
  17. 17. Quality-aware Service Model • Quality-aware Composite Service – Consists of set of autonomous services that are connected into a directed acyclic graph, called service graph – Is correct if the inter-service satisfied the following relation: • QoSout of Service K ‘satisfies ‘QoSin of Service M iff • qKjout = qMlin for qMlin being single QoS value • qKjout is in qMlin for qMlin being a range of QoS value • Example: – Video-on-demand service, consists of two services: retrieval service and playback service • Output quality of the retrieval service needs to correspond to input quality of playback service, or at least falls into the range of input quality of playback service
  18. 18. Scheduling And Policing Mechanisms • • scheduling: choose next packet to send on link; allocate link capacity and output queue buffers to each connection (or connections aggregated into classes) FIFO (first in first out) scheduling: send in order of arrival to queue – 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
  19. 19. Need for a Scheduling Discipline • Why do we need a non-trivial scheduling discipline? • Per-connection delay, bandwidth, and loss are determined by the scheduling discipline – The NE can allocate different mean delays to different connections by its choice of service order – it can allocate different bandwidths to connections by serving at least a certain number of packets from a particular connection in a given time interval – Finally, it can allocate different loss rates to connections by giving them more or fewer buffers
  20. 20. FIFO Scheduling • Disadvantage with strict FIFO scheduling is that the scheduler cannot differentiate among connections -- it cannot explicitly allocate some connections lower mean delays than others • A more sophisticated scheduling discipline can achieve this objective (but at a cost) • The conservation law – “the sum of the mean queueing delays received by the set of multiplexed connections, weighted by their fair share of the link’s load, is independent of the scheduling discipline”
  21. 21. Requirements • A scheduling discipline must satisfy four requirements: – Ease of implementation -- pick a packet every few microsecs; a scheduler that takes O(1) and not O(N) time – Fairness and Protection (for best-effort connections) -- FIFO does not offer any protection because a misbehaving connection can increase the mean delay of all other connections. Round-robin scheduling? – Performance bounds -- deterministic or statistical; common performance parameters: bandwidth, delay (worst-case, average), delay-jitter, loss – Ease and efficiency of admission control -- to decide given the current set of connections and the descriptor for a new connection, whether it is possible to meet the new connection’s performance bounds without jeopardizing the performance of existing connections
  22. 22. Designing a scheduling discipline • Four principal degrees of freedom: – the number of priority levels – whether each level is work-conserving or non-work-conserving – the degree of aggregation of connections within a level – service order within a level • Each feature comes at some cost – for a small LAN switch -- a single priority FCFS scheduler or at most 2-priority scheduler may be sufficient – for a heavily loaded wide-area public switch with possibly noncooperative users, a more sophisticated scheduling discipline may be required.
  23. 23. Work conserving and non-work conserving disciplines • A work-conserving scheduler is idle only when there is no packet awaiting service • A non-work-conserving scheduler may be idle even if it has packets to serve – makes the traffic arriving at downstream switches more predictable – reduces buffer size necessary at output queues and the delay jitter experienced by a connection – allows the switch to send a packet only when the packet is eligible – for example, if the (k+1)th packet on connection A becomes eligible for service only i seconds after the service of the kth packet, the downstream swicth receives packets on A no faster than one every i secs.
  24. 24. Eligibility times • By choosing eligibility times carefully, the output from a switch can be mode more predictable (so that bursts won’t build up in the n/w) • Two approaches: rate-jitter and delay-jitter • rate-jitter: peak rate guarantee for a connection – E(1) = A(1); E(k+1) = max(E(k) + Xmin, A(k+1)) where Xmin is the time taken to serve a fixed-sized packet at peak rate) • delay-jitter: at every switch, the input arrival pattern is fully reconstructed – E(0,k) = A (0,k); E(i+1, k) = E(i,k) + D + L where D is the delay bound at the previous switch and L is the largest possible delay on the link between switch i and i+1
  25. 25. Pros and Cons • Reduces delay jitter: Con -- we can remove jitter at endpoints with an elasticity buffer; Pro--reduces buffers(expensive) at the switches • Increases mean delay, problem?: pro--for playback applications, which delay packets until the delay-jitter bound, increasing mean delay does not affect the perceived performance • Wasted bandwidth, problem?: pro--It can serve best-effort packets when there are no eligible packets to serve • Needs accurate source descriptors -- no rebuttal from the non-work conserving camp
  26. 26. Priority Scheduling transmit highest priority queued packet • multiple classes, with different priorities – class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..
  27. 27. Priority Scheduling • The scheduler serves a packet from priority level k only if there are no packets awaiting service in levels k+1, k+2, …, n • at least 3 levels of priority in an integrated services network? • Starvation? Appropriate admission control and policing to restrict service rates from all but the lowest priority level • Simple implementation
  28. 28. Round Robin Scheduling • multiple classes • cyclically scan class queues, serving one from each class (if available) • provides protection against misbehaving sources (also guarantees a minimum bandwidth to every connection)
  29. 29. Max-Min Fair Share • Fair Resource allocation to best-effort connections? • Fair share allocates a user with a “small” demand what it wants, and evenly distributes unused resources to the “big” users. • Maximize the minimum share of a source whose demand is not fully satisfied. – Resources are allocated in order of increasing demand – no source gets a resource share larger than its demand – sources with unsatisfied demand s get an equal share of resource • A Generalized Processor Sharing (GPS) server will implement max-min fair share
  30. 30. Weighted Fair Queueing • generalized Round Robin (offers differential service to each connection/class) • each class gets weighted amount of service in each cycle
  31. 31. Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three common-used criteria: • (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) – crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! • Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate • (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)
  32. 32. IETF Differentiated Services Concerns with Intserv: • Scalability: signaling, maintaining per-flow router state difficult with large number of flows • Flexible Service Models: Intserv has only two classes. Also want “qualitative” service classes – “behaves like a wire” – relative service distinction: Platinum, Gold, Silver Diffserv approach: • simple functions in network core, relatively complex functions at edge routers (or hosts) • Don’t define service classes, provide functional components to build service classes #32
  33. 33. Diffserv Architecture Edge router: - per-flow traffic management r - marks packets as in-profile and outprofile b Core router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profile packets QoS #33 marking scheduling . . .
  34. 34. Edge-router Packet Marking • profile: pre-negotiated rate A, and token bucket size B packet marking at edge based on per-flow profile • Rate A B User packets Possible usage of marking: • • QoS class-based marking: packets of different classes marked differently intra-class marking: conforming portion of flow marked differently than non-conforming one #34
  35. 35. Classification and Conditioning • Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 • 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive • 2 bits are currently unused QoS #35
  36. 36. Classification and Conditioning • It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if non-conforming QoS #36
  37. 37. Forwarding (PHB) • Per Hop Behavior (PHB) result in a different observable (measurable) forwarding performance behavior • PHB does not specify what mechanisms to use to ensure required PHB performance behavior • Examples: – Class A gets x% of outgoing link bandwidth over time intervals of a specified length – Class A packets leave first before packets from class B QoS #37
  38. 38. Forwarding (PHB) PHBs being developed: • Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate – logical link with a minimum guaranteed rate • Premium service – DSCP = 101110 (46) • Assured Forwarding: 4 classes of traffic – each guaranteed minimum amount of bandwidth – each with three drop preference partitions • Gold, silver, bronze QoS #38
  39. 39. DiffServ Routers DiffServ Edge Router Classifier DiffServ Core Router Marker Select PHB Meter PHB PHB PHB PHB Extract DSCP QoS Local conditions Packet treatment #39 Policer
  40. 40. IntServ vs. DiffServ IntServ network DiffServ network "Call blocking" approach QoS "Prioritization" approach #40
  41. 41. Comparison of Intserv & Diffserv Architectures Intserv Granularity of service differentiation State in routers(e.g. scheduling, buffer management) Traffic Classification Basis Type of service differentiation Individual Flow Admission Control Required Signaling Protocol Required(RSVP) Diffserv Per Flow Aggregate of flows Per Aggregate Several header fields DS Field Deterministic or statistical guarantees Absolute or relative assurance Required for absolute differentiation Not required for relative schemes QoS #41
  42. 42. Comparison of Intserv & Diffserv Architectures Intserv Coordination for service differentiation Scope of Service Differentiation Scalabilty Network Accounting Network Management Interdomain deployment Diffserv End-to-End Local (Per-Hop) A Unicast or Multicast Anywhere in a path Network or in specific paths Limited by the number Limited by the of flows number of classes of service Based on flow Based on class characteristics and QoS usage requirement Similar to Circuit Similar to existing Switching networks IP networks Multilateral Bilateral Agreements Agreements QoS #42
  43. 43. Traffic Regulators • Leaky bucket controllers • Token bucket controllers
  44. 44. Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate. • bucket can hold b tokens • tokens generated at rate r token/sec unless bucket full • over interval of length t: number of packets admitted less than or equal to (r t + b).
  45. 45. Policing Mechanisms (more) • token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! arriving traffic token rate, r bucket size, b per-flow rate, R WFQ D = b/R max
  46. 46. 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 req’s • admit/deny new call setup requests: Question: can newly arriving flow be admitted with performance guarantees while not violating QoS guarantees made to already admitted flows?
  47. 47. Intserv: QoS guarantee scenario • Resource reservation – call setup, signaling (RSVP) – traffic, QoS declaration – per-element admission control request/ reply  QoS-sensitive scheduling (e.g., WFQ)
  48. 48. RSVP • • • • Multipoint Multicast connections Soft state Receiver initiated reservations identifies a session using a combination of dest. Address, transport-layer protocol type, dest. Port number • each RSVP operation applies only to packets of a particular session • not a routing protocol; merely used to reserve resources along the existing route set up by whichever underlying routing protocol
  49. 49. RSVP Messages • Path message originating from the traffic sender – to install reverse routing state in each router along the path – to provide recceivers with information about the characteristics of the sender traffic and end-to-end path so that they can make appropriate reservation requests • Resv message originating from the receivers – to carry reservation requests to the routers along the distribution tree between receivers and senders • PathTear, ResvTear, ResvErr, PathErr
  50. 50. PATH Message • Phop: the address of the last RSVP-capable node to forward this path message. • Sender template: filter specification identifying the sender • Sender Tspec: defines sender traffic characteristics • Optional Adspec: info about the end-to-end path used by the receivers to compute the level of resources that must be reserved
  51. 51. RESV Message • Rspec: reservation specification comprising the value R of bandwidth to be reserved in each router, and a slack term about end-to-end delay • reservation style, FF, WF, SE • Filterspec to identify the senders • Flowspec comprising the Rspec and traffic specification (set equal to Sender Tspec) • optional ResvConf
  52. 52. Call Admission Arriving session must : • declare its QOS requirement – R-spec: defines the QOS being requested • characterize traffic it will send into network – T-spec: defines traffic characteristics • signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) – RSVP
  53. 53. Intserv QoS: Service models [rfc2211, rfc 2212] Controlled load service: Guaranteed service: • • worst case traffic arrival: leaky-bucketpoliced source simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] arriving traffic  "a quality of service closely token rate, r bucket size, b per-flow rate, R WFQ D = b/R max approximating the QoS that same flow would receive from an unloaded network element."
  54. 54. Multimedia in Networks Fundamental characteristics: • Typically delay sensitive delay. • But loss tolerant: infrequent losses cause minor glitches that can be concealed. • Antithesis of data (programs, banking info, etc.), which are loss intolerant but delay tolerant. • Multimedia is also called “continuous media” Classes of MM applications: • Streaming stored audio and video • Streaming live audio and video • Real-time interactive video
  55. 55. Multimedia in networks (2) Streaming stored MM • Clients request audio/video files from servers and pipeline reception over the network and display • Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.) • Delay: from client request until display start can be 1 to 10 seconds Unidirectional Real-Time: • similar to existing TV and radio stations, but delivery over the Internet • Non-interactive, just listen/view Interactive Real-Time : • Phone or video conference • More stringent delay requirement than Streaming & Unidirectional because of real-time nature • Video: < 150 msec acceptable • Audio: < 150 msec good, <400 msec acceptable
  56. 56. Multimedia in networks (3): challenges • TCP/UDP/IP suite provides besteffort, no guarantees on delay or delay variation. – Streaming apps with initial delay of 5-10 seconds are now commonplace, but performance deteriorates if links are congested (transoceanic) – Real-Time Interactive apps have rigid requirements for packet delay and jitter. – Jitter is the variability of packet delays within the same packet stream. • Design for multimedia apps would be easier if there were some 1st and 2nd class services. – But in the public Internet, all packets receive equal service. – Packets containing real-time interactive audio and video stand in line, like everyone else. • There have been, and continue to be, efforts to provide differentiated service.
  57. 57. Multimedia in networks (4): making the best of best effort To mitigate impact of “best-effort” Internet, we can: • Use UDP to avoid TCP and its slow-start phase… • Buffer content at client and control playback to remedy jitter • We can timestamp packets, so that receiver knows when the packets should be played back. • Adapt compression level to available bandwidth • We can send redundant packets to mitigate the effects of packet loss.  We will discuss all these “tricks”.
  58. 58. How should the Internet evolve to better support multimedia? Integrated services philosophy: • Change Internet protocols so that applications can reserve end-toend bandwidth – Need to deploy protocol that reserves bandwidth – Must modify scheduling policies in routers to honor reservations – Application must provide the network with a description of its traffic, and must further abide to this description. • Requires new, complex software in hosts & routers Differentiated services philosophy: • Fewer changes to Internet infrastructure, yet provide 1st and 2nd class service. • Datagrams are marked. • User pays more to send/receive 1st class packets. • ISPs pay more to backbones to send/receive 1st class packets.
  59. 59. How should the Internet evolve to better support multimedia? (cont.) Laissez-faire philosophy • No reservations, no datagram marking • As demand increases, provision more bandwidth • Place stored content at edge of network: – ISPs & backbones add caches – Content providers put content in CDN nodes – P2P: choose nearby peer with content Virtual private networks (VPNs) • Reserve permanent blocks of bandwidth for enterprises. • Routers distinguish VPN traffic using IP addresses • Routers use special scheduling policies to provide reserved bandwidth.
  60. 60. QoS Architectures Host B Application Top-to-Bottom QoS Host A Application Presentation Presentation Session Session Transport Transport RSVP Network Network DiffServ Data Link Data Link SBM Physical Physical SBM RSVP DiffServ and MPLS End-to-End QoS RSVP QoS-enabled Application QoS API
  61. 61. Protocol Comparison QoS most Net App Description x Provisioned resources end-to-end (leased lines) x x RSVP Guaranteed (provides feedback to application) x x RSVP Controlled Load (provides feedback to application) x MPLS (Multi-Protocol Label Switching) x x DiffServ applied at network ingress appropriate to RSVP service level for that flow x x DiffServ or SBM applied on per-flow basis by source application x x least DiffServ applied at network core ingress Fair queuing applied by network elements (e.g. WFQ, RED) Best effort service
  62. 62. Multicast Environments • RSVP – Heterogeneous receivership makes reservation merging a difficult task • DiffServ – Its relative simplicity makes it a better fit for multicast support • MPLS – Work is underway, no standards have emerged yet • SBM – Explicit support for multicast
  63. 63. Conclusions • Complexity at the edges – simple network core – Limit RSVP’s use on the backbone – Instead use the DiffServ • DiffServ is a perfect complement for RSVP • ToDo : – Performance attributes for each class still missing – Interworking solution for mapping IP CoS to ATM QoS
  64. 64. Queries