Overview. Motivation. Introduction. Objectives. Introduction (2) We will summarize and discuss:

Transcription

1 Motivation Introduction Requirements of Distributed MM Applications Prof. Wonjun Lee Multimedia and Internet Computing Laboratory (MICL) Department of Computer Science & Engineering Ewha Womans University URL: wjlee Fundamental Issues in QoS Overview QoS Models in Communications Systems Resource Reservation Issues in Communication Systems QoS Adaptive Mechanisms Interaction Models for Internet and ATM QoS Architectures Further Issues (IntServ/DiffServ) Concluding Remarks 1 2 Motivation Introduction Growing need for real-time requirement and QoS guarantees for Distributed Multimedia Applications Computing, communication, and storage resources need to be managed in a coordinated manner NGI should be viewed rather as a system of distributed systems Require End-to-End resource management and flow control systems in a graceful adaptation manner Middleware layer seamlessly connects individual heterogeneous distributed systems Multimedia (MM) Communications has been used by various distributed applications: Video-conferencing Retrieval systems Video-On-Demand (VoD) LANS (e.g., in-house information systems) MANS (e.g., city information systems, campus networks) WANS (e.g., distributed lectures, a.k.a. distance learning) Integrated manipulation is needed: Capturing, processing, communication, presentation and/or storage Continuous Media (CM) data Time-dependent data in MM systems (e.g., audio, video) 3 4 Introduction (2) MM communications deal with Transfer Protocol Services Mechanisms of/for discrete and continuous media in/over digital networks Real-time guarantees in networked MM applications are required these requirements are defined in terms of QoS QoS: Performance requirements of applications/users Set of parameterswhich defines properties of media streams Distributed MM applications need end-to-end QoS Objectives We will summarize and discuss: Requirements of distributed MM applications Challenging and most often found application driven demands, which have impacts on MM communication issues for QoS provisioning, such as Resource reservation Adaptive methods (scaling/filtering/pricing) QoS architecture models Ability of current MM communication systems 5 6 1

2 Requirements of Distributed MM Applications Functional (traffic) requirements Bandwidth e.g., 1.5 Mbits/s for payback of MPEG-1 End-to-end delay e.g., video conferencing < 150 ms Reliability e.g., tight synchronization < 80 ms skew To ensure (audiovisual) data transmission in a timely manner and To provide a constant QoS during run-time of an application, Resource reservation needed Scheduling techniques Multicast (transmission of a single copy of data to multiple receivers) Filtering: dropping data in network due to a lack of bandwidth or compute power -> allow smooth decreasein quality Scaling QoS Provisioning Steps QoS negotiation phase (set-up phase) 1. QoS specification: workload/expected QoS must be specified 2. Admission control (capacity test) 3. QoS calculation 4. Reservation of resource capacities E.g., transmission or processing bandwidth 5. QoS enforcement Enforcement of QoS guarantees By QoS translator, resource scheduler 7 8 QoS Classes QoS Specification (wrt. Transport of CM data) Hard guaranteed QoS Reservation is based on peak requirements Best-effort approach (no-effort) No reservation is made Various weaker QoS Statistical : average case Predictive : predicted assumptions, observation-based 1. Bandwidth: most prominent QoS parameter E.g., in packetization, max/avg packet size, packet rate 2. Delay: maximum delay on an e-to-e transmission 3. Reliability: loss and corruption probability 4. Jitter (delay variance) Varying delays during processing and transmitting CM data Can be smoothed by buffering at the receiver side -> increases e-te delay, though When describing QoS demands, it is useful to specify an interval [required (min), desired (max)] 9 10 Role of Resource Reservation Protocols QoS Models Besides local resource management mechanisms at participating end systems and routers, Reservation protocols are needed to exchange and negotiate QoS requirements between these systems Reservation protocols Perform NO reservation of required resources ONLY vehicles to transform information about resource requirements and to negotiate QoS values between end-systems and intermediate network routers Leave the reservation itself to local resource management modules We will discuss such protocols and their use for e-t-e QoS provision in some more detail A wide-variety of QoS models and architectures Tenet (UCB) ST-2 + [RFC 1819] HeiTS/HeiRAT (IBM ENC, Heidelberg) QoS-A (Lancaster Univ., UK) Integrated Services (IntServ [RFC 1633]) Differentiated Services (DiffServ [RFC 2475])

3 IntServ A general solution for QoS guarantees in the Internet RSVP is used to transport FlowSpec (QoS demands are accumulated in it) that adhere to Intserv rules Two types of descriptions for QoS spec. Tspec (traffic spec.): describes behavior of a flow Rspec (service request spec.): describes service requested under the condition of flow adheres to restrictions of TSpec IntServ Services (1) Guaranteed QoS service (GS) For hard RT restrictions Goal: control maximum e-t-e delay of a packet Policing (compare arriving traffic against Tspeconly at the edge of n/w), using token bucket model b(t) = min (M+p*t, b+r*t) (-> in Rspec) b: burstiness (token bucket capacity or depth) P: peak rate M: max packet size (MTU) r: token arrival rate (sustainable rate) t: interval length In reshaping buffer size, complicated (over-headed) calculation wrt. slack term and error-sum is needed: Magic formula!! IntServ Services (2) QoS in Communication Systems Controlled-load load QoS service (CL) Intention: better than best -effort delivery Must provide accepted data flows with service closely similar to unloaded best-effort service CL service is minimal (no optional capabilities: only a single function) TSpec is identical to that of GS Rspec is not defined Based on the observed fact that most (video conferencing) systems work well on lightly load networks without reservation LANs IP RTP Telecommunications For being used with RSVP, CL models provide a comparison and merging function for traffic and request requirements Rule of Tspec s token bucket parameters: Amount of data <= b+r*t b: burstiness (token bucket capacity or depth) r: token arrival rate (sustainable rate) t: interval length If packets violates this rule: non-conformant QoS Issues in LANs QoS Issues in IP (Network Layer) Widespread Ethernet networks (10 Mbits/s) never guarantee any kind of QoS: due to collisions of CSMA/CD approach Fast Ethernet (100 Mb/s) No QoS guarantees either Isochronous Ethernet (IEEE 802.9) / Demand Priority Ethernet (IEEE ) Can provide QoS, yet market potential and influence are questionable Token Ring Networks (4 Mb/s, 16 Mb/s) / FDDI networks (100 Mb/s) Both are capable to support QoS to some extentby exploiting priority mechanisms (I.e., higher priority sender can acquire token to send a MM frame) TOS (Type-Of-Service) field in IPv4 is typically unused IGMP (Internet Group Management Protocol: RFC 1112) provides multicast groups (maintained by adding/removing IP addresses to /from multicast group) IPv6: Does not contain QoS support by itself But equipped with hooks which can be used by other means to set up reservations Concept of a pseudo-connection, Flow (established by means external to IPv6 by e.g., RSVP) Priority field (used by routers): -> process packets according to urgency

4 Real-time Transport Protocol RTP [RFC 1889] One of Internet protocols which can be used in conjunction with reservation model at network layer (e.g., on top of UDP) An e-t-e protocol for transport of real-time data Support for synchronization, framing, encryption, timing and source identification Proper for multi-party conferencing Does NOTdefine any kind of QoS itself Does NOTprovide re-ordering or retransmission of lost packets (I.e., no real QoS support) Yet provides a sequence number that enables application to initiate such steps Typically used directly on top of UDP/IP or ST-2; QoS can be guaranteed by the use of RSVP s reservation mechanisms for UDP datagrams Real-time Transport Protocol (2) RTCP (RTP Control Protocol) - RTP s companion (RTP relies on RTCP) to monitor application s QoS - Used to interchange QoS and failure info. between QoS monitor applications in end-systems Telecommunication Systems ATM (Asynchronous Transfer Mode) Wide-area MM communication has generally been based on telecommunication networks (ISDN s) connection-oriented approach with guaranteed throughput and low loss rates ISDN-based long-distance video-conferencing is more common yet than that over computer networks ATM: motivated by merge of computer networks and telecommunication approaches towards MM communication Cell-switched networks Cell-based connection-oriented Standardized by two consortia - ATM Forum - ITU-T Guarantees that cell order is maintained in a connection QoS is conceptually negotiated between three entities Calling party (initiator):requests a connection with a SETUP message (QoS requirements) Network Called party QoS (traffic) Parameters (supported for ATM Connections) ATM Service Categories PCR (Peak Cell Rate) ATM Traffic Management Spec. V max transmission rate within a VC; burst rate (# of cells) UBR (Unspecified Bit Rate) SR (Sustainable Rate) No flow control; PCR is specified at setup A calculation of average allowable, long-term cell transfer rate ABR (Available Bit Rate) MBS (Maximum Burst Size) Best-effortservice CLR (Cell Loss Ratio) nrt-vbr (non-real-time Variable Bit Rate) Max rate of lost application MCTD (Maximum Cell Transfer Delay) Restriction on the sum of all waiting times MCDV (Maximum Cell Delay Variation) Max difference in e-t-e transmission time Etc. For transaction-oriented applications where traffic sporadic and bursty rt-vbr (real-time Variable Bit Rate) Bursty and delay-sensitive (isochronous) for time-critical data CBR (Constant Bit Rate) For real-time uncompressed CM data

5 Resource Reservation Issues Reservation in Communication Systems Pros/Cons of reservation Pros: reliable; better throughput Cons: waste of resources if unused Direction (in which reservation set-up occurs) Sender-oriented approach Receiver-oriented approach Sender is the entity which starts overall setup process in senderoriented as well as receiver-oriented In receiver-oriented, 1 st pass: distributes (path) info. only 2 nd pass: performs actual reservation (from receiver towards sender) ST-2 + (Stream Protocol) Resource ReSerVation Protocol (RSVP) ATM Reservation Stream Protocol (RFC 1819) RSVP Connection-oriented reservation and transmission protocol Sender-oriented, unreliable, multicast protocol (1:n multicast) QoS is negotiated through exchange of FlowSpec between all nodes (sender/router/receiver) Negotiated QoS/Multicast tree can be modified later filtering could be used to provide heterogeneous QoS to different receivers Once broad support in the first half of the nineties A reservation protocol used to transport FlowSpec (that adhere to IntServ rules) between resource managers Reservations are made for flows identified by address information by a flow label in IPv6; or by address information in IPv4 Adds reservation to Internet protocols(ipv6 and IPv4) Relies on those protocols for the exchange of data Keeps soft state (refreshed by reservation updates periodically) Reservations are made in a receiver-oriented style Supports heterogeneous reservations from independent receivers Does NOTprovide data discrimination mechanisms (e.g., I-frames of a MPEG video stream) A hard QoS guarantee is NOT given ATM Reservation Reservations are performed in 2 steps 1. Connection negotiationbetween calling party, targets and network 2. Resource guarantees are managed at each node of network individually CAC (Call Admission Control) is made at each intermediate node in network Decides to permitor refuse the new connection depending on service class (VBR, ABR, CBR, ) UPC (Usage Parameter Control) monitors traffic (checking violations of traffic contract; tagging non-conforming cells) Traffic Shaper controls insertion of cells into network by Generic Cell Rate Algorithm (GCRA) as a continuous-state Leaky Bucket algorithm Adaptive Mechanisms CM streams with VBR due to compression algorithms CBR support causes worst case assumptions, which implies overbooking: unused capacity, high costs Adaptive mechanisms are needed for VBR applications (e.g., conferencing) Scaling Changes the amount of data transferred from origin to target using feedback control loop Raises questions about fairness and balancing between streams Scalability Two aspects Wrt. # of participants in one application Wrt. # of concurrent applications Filtering Intermediate network node changes the amount of transmitted MM information for heterogeneous receivers

6 Further Issues (QoS Driven Routing) Further Issues (ATM vs. IIS) QoS driven routing Needed for efficient establishment of reservations Some of the questions: How much state informationshould be exchanged among routers? How oftenshould this state information be updated? Hard-state, sender-oriented ATM camp PNNI (Private Network-Node Interface) > some QoS routing support Combining QoS routing and receiver-oriented reservations are still under controversial discussions Mapping between ATM and IIS (Internet IntServ Architecture) < ATM > < IIS > ATM service categories <-> IntServ service classes ATM signalling VC routing VPI/VCI Traffic contract Traffic management <-> RSVP <-> Datagram routing <-> Session ID <-> FlowSpec <-> Traffic control Further Issues (Classification of Interaction Approaches) ATM Subordination (A IP A) Partnership (A IP) Internet Subordination (IP A IP) Passive (IP over ATM) IETF ISSLL (IntServ over Specific Link Layers): RSVPoATM+MARS+NHRP ATM Forum: MPOA MARS (Multicast Address Resolution Server) NHRP (Next Hop Resolution Protocol) MPOA ( Multiprotocol over ATM) VTOA (Voice and Telephony over ATM) PNNI (Private Network-node Interface) CIF (Cells in Frames) Active (ATM under IP) IETF MPLS ATM Forum: (I-PNNI), (VTOA) (CIF) Further Issues (Differentiated Services) Due to concerns about the scalability of IIS, IETF DiffServ has been proposed Intention: better than best-effort service over the Internet Highly scalable and relatively simpleintra and Inter domain CoS/QoS control services No QoS state in the core of the network No per-flow state, no per-flow shaping Cf) IntServ: per-flow resource reservation and management Ingress DS node: assures conformance with TCA (Traffic Conditioning Agreement) Each node: selects a PHB (Per Hop Behavior) Egress DS node: perform traffic conditioning to reflect a TCA with the next domain Comparison of Diff Serv and Int Serv Conclusions Diff Serv Aggregated isolation Aggregated guarantee Long-term setup Within a domain Scalable Robust Stateless solution Coarser level of service differentiation Int Serv per-session isolation per-session guarantee per-session setup end-to-end powerful service per-flow basis stateful n/w architecture Support of resource reservation protocol, accompanying admission control and scheduling mechanisms Integration of ATM into the Internet world IntServ provides more powerful service but has serious limitations wrt. network scalability and robustness DiffServ is more scalable, but cannot provide services comparable to IntServ MM communication systems developed so far still have many issues to be tackled