Multimedia_Chuong4_BKHN

Chia sẻ: Nguyen Phuong | Ngày: | Loại File: PDF | Số trang:16

Thêm vào BST

Báo xấu

62
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'multimedia_chuong4_bkhn', kỹ thuật - công nghệ, kĩ thuật viễn thông phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Multimedia_Chuong4_BKHN

Chapter 4: Multimedia Network & Applications Application Classes (2) Overview: Streaming n n Clients request audio/video files from servers and q Part 1: Multimedia requirements – q pipeline reception over the network and display Application classes Interactive: user can control operation (similar to q q Part 2: Streaming applications VCR: pause, resume, fast forward, rewind, etc.) q Part 3: Voice over IP (VoIP) Delay: from client request until display start can q be 1 to 10 seconds q Part 4: Recovery from Packet Loss q Part 5: RTP (Real Time Protocol) q Part 6: Int-serv, Diff-serv, RSVP 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 1 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 3 Part 1. Multimedia requirements– App classes Application Classes (3) Typically sensitive to delay, but can tolerate Unidirectional Real-Time: n n packet loss (would cause minor glitches that similar to existing TV and radio stations, but q delivery on the network can be concealed) Non-interactive, just listen/view q Data contains audio and video content n Interactive Real-Time : (“continuous media”), three classes of n applications: Phone conversation or video conference q More stringent delay requirement than Streaming q Streaming q and Unidirectional because of real-time nature q Unidirectional Real-Time Video: < 150 msec acceptable q q Interactive Real-Time Audio: < 150 msec good,
Challenges Solution Approaches in IP Networks Just add more bandwidth and enhance caching TCP/UDP/IP suite provides best-effort, no n n capabilities (over-provisioning)! guarantees on expectation or variance of packet Need major change of the protocols : delay n Incorporate resource reservation (bandwidth, processing, q Streaming applications delay of 5 to 10 seconds is n buffering), and new scheduling policies typical and has been acceptable, but performance Set up service level agreements with applications, monitor q deteriorate if links are congested (transoceanic) and enforce the agreements, charge accordingly Real- Time Interactive requirements on delay and its Need moderate changes (“Differentiated Services”): n n jitter have been satisfied by over-provisioning Use two traffic classes for all packets and differentiate q service accordingly (providing plenty of bandwidth), what will happen Charge based on class of packets q when the load increases?... Network capacity is provided to ensure first class packets q incur no significant delay at routers 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 5 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 7 Challenges (2) Part 2. Streaming applications Most router implementations use only First- Important and growing application due to n n Come-First-Serve (FCFS) packet processing reduction of storage costs, increase in high and transmission scheduling speed net access from homes, enhancements to caching and introduction of To mitigate impact of “best-effort” protocols, n QoS in IP networks we can: Audio/Video file is segmented and sent over n Use UDP to avoid TCP and its slow-start phase… q either TCP or UDP, public segmentation Buffer content at client and control playback to q protocol: Real-Time Protocol (RTP) remedy jitter Adapt compression level to available bandwidth q 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 6 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 8
Streaming Streaming From Web Server (2) User interactive control is provided, e.g. the Alternative: set up connection between server n n public protocol Real Time Streaming and player, then download Protocol (RTSP) Web browser requests and receives a Meta n Helper Application: displays content, which n File (à a file describing the object) instead of is typically requested via a Web browser; e.g. receiving the file itself; RealPlayer; typical functions: Browser launches the appropriate Player and n Decompression q passes it the Meta File; Jitter removal q Error correction: use redundant packets to be Player sets up a TCP connection with Web q n used for reconstruction of original stream Server and downloads the file GUI for user control q 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 9 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 11 Streaming From Web Servers Meta file requests Audio: in files sent as HTTP n objects Video (interleaved audio and n images in one file, or two separate files and client synchronizes the display) sent as HTTP object(s) A simple architecture is to have n the Browser requests the object(s) and after their reception pass them to the player for display - No pipelining 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 10 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 12
Using a Streaming Server Real Time Streaming Protocol (RTSP) This gets us around HTTP, allows a choice of UDP For user to control display: rewind, fast forward, n n vs. TCP and the application layer protocol can be pause, resume, etc… better tailored to Streaming; many enhancements Out-of-band protocol (uses two connections, one for n options are possible (see next slide) control messages (Port 554) and for media stream) RFC 2326 permits use of either TCP or UDP for the n control messages connection, sometimes called the RTSP Channel As before, meta file is communicated to web n browser which then launches the Player; Player sets up an RTSP connection for control messages in addition to the connection for the streaming media 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 13 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 15 Options When Using a Streaming Server Meta File Example Use UDP, and Server sends at a rate (Compression and n Twister Transmission) appropriate for client; to reduce jitter, Player buffers initially for 2-5 seconds, then starts display Use TCP, and sender sends at maximum possible rate under n 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 14 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 16
RTSP Operation Real-World Streaming Applications What material can be streamed ? n Video/Audio (File or Live source) q Presentation slides q Combinations q Real (No 1) à Most OSes n Server: Helix Universal Server + Helix Producer q Client: Real Player q Microsoft à Windows only n Server: Windows Media Server/Encoder q Client: Windows Media Player q Apple à MacOS/Win32/Some UNIXes n Server: Darwin Server q Client: QuickTime q 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 17 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 19 RTSP Exchange Example Key Points of Part 2 C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Streaming n Transport: rtp/udp; compression; port=3056; mode=PLAY Protocol à RTSP (Real Time Streaming Protocol) q S: RTSP/1.0 200 1 OK Session 4231 Combining with Web Server q C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 18 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 20
Part 3. Voice over IP Internet Phone with Fixed Playout Delay Internet phone applications generate packets during n talk spurts Bit rate is 8 KBytes, and every 20 msec, the sender n forms a packet of 160 Bytes + a header The coded voice information is encapsulated into a n UDP packet and sent out Some packets may be lost à up to 20 % loss is n tolerable Using TCP eliminates loss but cause variance in n delay FEC is sometimes used to fix errors and make up n losses 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 21 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 23 Real-Time (Phone) Over IP’s Best -Effort Adaptive Playout Delay End-to-end delays above 400 msec cannot be The objective is to use a value for p-r that tracks n n tolerated à delayed packets are ignored at the the network delay performance as it varies during a phone call receiver ! The playout delay is computed for each talk n Delay jitter is handled by using n spurt based on observed average delay and timestamps, q observed deviation from this average delay sequence numbers, q Estimated average delay and deviation of average n Delaying playout at receivers either a fixed or a n delay are computed in a manner similar to variable amount estimates of RTT and deviation in TCP With fixed playout delay, the delay should be as n The beginning of a talk spurt is identified from n small as possible without missing too many packets; examining the timestamps in successive and/or delay cannot exceed 400 msec sequence numbers of chunks 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 22 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 24
Key points of Part 3 Recovery From Packet Loss VoIP transmission mechanism - UDP Mixed quality streams are used to include n n redundant duplicates of chunks; upon loss Effects of jitter and delay n playout available redundant chunk, albeit a Fix Playout Delay n lower quality one Adaptive Playout Delay n With one redundant chunk per chunk can n recover from single losses 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 25 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 27 4. Recovery From Packet Loss Piggybacking Lower Quality Stream Loss is in a broader sense: packet never arrives or n arrives later than its scheduled playout time Since retransmission is inappropriate for Real n Time applications, à FEC (Forward Error Correction) or Interleaving are used to reduce loss impact. Simplest FEC scheme adds a redundant chunk n made up of exclusive OR of a group of n chunks; redundancy is 1/n; can reconstruct if at most one lost chunk; playout time schedule assumes a loss per group 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 26 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 28
Interleaving 5. Real-Time Protocol (RTP) Provides standard packet format for real-time Has no redundancy, but can cause delay in playout n n application beyond Real Time requirements Typically runs over UDP Divide 20 msec of audio data into smaller units of 5 n n msec each and interleave Specifies header fields below n Upon loss, have a set of partially filled chunks Payload Type : 7 bits, providing 128 possible different n n types of encoding; eg PCM, MPEG2 video, etc. SequenceNumber: 16 bits; used to detect packet n loss 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 29 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 31 Key points of Part 4 Real-Time Protocol (RTP) Timestamp: 32 bytes; gives the sampling n Recovering mechanisms n instant of the first audio/video byte in the FEC (Forward Error Correction) q packet; used to remove jitter introduced by Piggybacking Lower-Quality Stream q the network Interleaving q Synchronization Source identifier (SSRC): n 32 bits; an id for the source of a stream; assigned randomly by the source 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 30 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 32
RTP Control Protocol (RTCP) Key Points of Part 5 Protocol specifies report packets n RTP n exchanged between sources and destinations of multimedia Payload type q information Sequence number q Three reports are defined: n q Receiver reception, TimeStamp q q Sender, SSRC (Synchronization Source Identifier) q q Source description Reports contain statistics such as: RTCP n n q number of packets sent, Reports q q number of packets lost, Types of reports q inter-arrival jitter q Used to modify sender n transmission rates and for diagnosticspurposes 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 33 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 35 RTCP Bandwidth Scaling 6. Int-Serv, Diff-Serv, RSVP If each receiver sends RTCP packets to all n other receivers, the traffic load resulting can be large RTCP adjusts the interval between reports n based on the number of participating IETF groups are working on proposals to improve QoS receivers n control in IP networks, i.e., going beyond best effort to Typically, limit the RTCP bandwidth to 5% of n provide some assurance for QOS the session bandwidth, divided between the Work in Progress includes RSVP, Differentiated n sender reports (25%) and the receivers Services, and Integrated Services reports (75%) Simple model for sharing and congestion studies n 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 34 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 36
Principles for QOS Guarantees Principles for QOS Guarantees (3) Consider a phone application at 1Mbps and an FTP application n Alternative to Marking and Policing: allocate a set portion sharing a 1.5 Mbps link. n of bandwidth to each application flow; can lead to q Bursts of FTP can congest the router and cause audio packets to be dropped à want to give priority to audio over FTP !! inefficient use of bandwidth if one of the flows does not use its allocation PRINCIPLE 1: Marking of packets is needed for router to n distinguish between different classes; and new router policy PRINCIPLE 3: While providing isolation, it is n to treat packets accordingly desirable to use resources as efficiently as possible 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 37 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 39 Principles for QOS Guarantees (2) Principles for QOS Guarantees (4) Applications misbehave (audio sends packets at a rate higher n Cannot support traffic beyond link capacity n than 1Mbps assumed above); PRINCIPLE 2: provide protection (isolation) for one class n PRINCIPLE 4: Need a Call Admission n from other classes Process; application flow declares its needs, Require Policing Mechanisms to ensure sources adhere to n network may block call if it cannot satisfy the bandwidth requirements; Marking and Policing need to be done needs at the edges: 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 38 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 40
Summary Scheduling Policies Priority Queuing: classes have different priorities; n class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc. Transmit a packet from the highest priority class n with a non-empty queue Preemptive and non-preemptive versions n 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 41 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 43 Scheduling And Policing Mechanisms Scheduling Policies (2) Scheduling: choosing the next packet for n Round Robin: scan class queues serving one n transmission on a link can be done following a from each class that has a non-empty queue number of policies; FIFO: in order of arrival to the queue; packets that n 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 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 42 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 44
Scheduling Policies (3) Policing Mechanisms Weighted Fair Queuing: is a generalized Token Bucket mechanism, provides a means n n Round Robin in which an attempt is made to for limiting input to specified Burst Size and provide a class with a differentiated amount Average Rate. of service over a given period of time 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 45 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 47 Policing Mechanisms Policing Mechanisms (2) Bucket can hold b tokens; Three criteria: n n token are generated at a (Long term) Average Rate (100 packets per q rate of r token/sec unless sec or 6000 packets per min??), crucial bucket is full of tokens. aspect is the interval length Over an interval of length n t, the number of packets q Peak Rate : e.g., 6000 p p minute Avg and that are admitted is less 1500 p p sec Peak than or equal to ( r t + b). q (Max.) Burst Size : Max. number of packets Token bucket and WFQ n sent consecutively, ie over a short period of can be combined to provide upper time bound on delay. 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 46 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 48
Integrated Services Call Admission Call Admission: routers will admit calls based on n their R-spec and T-spec and base on the current resource allocated at the routers to other calls. An architecture for providing QOS guarantees in IP n networks for individual application sessions Relies on resource reservation, and routers need to: n Maintain state info (Virtual Circuit) à maintaining records of q allocated resources and.. Respond to new Call setup requests on that basis q 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 49 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 51 Call Admission Integrated Services: Classes Session must first declare its QOS n Guaranteed QOS: this class is provided with n requirement and characterize the traffic it will firm bounds on queuing delay at a router; send through the network envisioned for hard real-time applications that R-spec: defines the QOS being requested n are highly sensitive to end-to-end delay expectation and variance T-spec: defines the traffic characteristics n Controlled Load: this class is provided a A signaling protocol is needed to carry the R- n n QOS closely approximating that provided by spec and T-spec to the routers where reservation is required à RSVP is a leading an unloaded router; envisioned for today’s IP network real-time applications which perform candidate for such signaling protocol well in an unloaded network 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 50 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 52
Differentiated Services Edge Functions Intended to address the following difficulties with n Intserv and RSVP; Scalability: maintaining states by routers in high n speed networks is difficult sue to the very large number of flows Flexible Service Models: Intserv has only two n classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction At DS-capable host or first DS-capable router n (Platinum, Gold, Silver, …) Classification: edge node marks packets according to n Simplersignaling: (than RSVP) many applications n classification rules to be specified (manually by admin, or by and users may only want to specify a more some TBD protocol) qualitative notion of service Traffic Conditioning: edge node may delay and then n forward or may discard 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 53 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 55 Differentiated Services Core Functions Approach: Forwarding: according to “Per-Hop- n n Behavior” or PHB specified for the particular Only simple functions in the core, and relatively q complex functions at edge routers (or hosts) packet class; such PHB is strictly based on class marking (no other header fields can be Do not define service classes, instead provides q functional components with which service classes used to influence PHB) can be built BIG ADVANTAGE: n No state info to be maintained by routers! 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 54 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 56
Classification and Conditioning Forwarding (PHB) PHB result in a different observable Packet is marked in the Type of Service n n (measurable) forwarding performance (TOS) in IPv4, and Traffic Class in IPv6 behavior 6 bits used for Differentiated Service Code n PHB does not specify what mechanisms to n Point (DSCP) and determine PHB that the use to ensure required PHB performance packet will receive behavior 2 bits are currently unused n Examples: n Class A gets x% of outgoing link bandwidth over q time intervals of a specified length Class A packets leave first before packets from q class B 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 57 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 59 Classification and Conditioning Forwarding (PHB) It may be desirable to limit traffic injection PHBs under consideration: n n rate of some class; user declares traffic Expedited Forwarding (EF): departure rate of q packets from a class equals or exceeds a profile (eg, rate and burst size); traffic is specified rate (logical link with a minimum metered and shaped if non-conforming guaranteed rate) Assured Forwarding (AF): 4 classes, each q guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 58 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 60
Differentiated Services Issues AF and EF are not even in a standard track n yet… research ongoing “Virtual Leased lines” and “Olympic” services n are being discussed Impact of crossing multiple ASs and routers n that are not DS-capable 4 /2/2003 Nguyen Chan Hung– Hanoi University of Technology 61 Key Points of Part 6 QoS: Int-Serv n n RSVP q Scheduling q Diff-Serv n WFQ n Forwarding PHB q Policing: q AF/EF n DSCP Token Bucket n q Int-Serv vs. Diff-Serv n Packet q Terms: n Classifications PHB, etc (see q DSCP/TOS n above) Call Admission q T-Spec/R-Spec n 4/2/2003 Nguyen Chan Hung– Hanoi University of Technology 62