15-441 Computer Networking

15-441 Computer Networking Multimedia

Outline • Multimedia requirements • Streaming • Phone over IP • Recovering from Jitter and Loss • RTP • QoS Requirements • Introduction to Scheduling Policies 11/15/2005

Application Classes • Typically sensitive to delay, but can tolerate packet loss (would cause minor glitches that can be concealed) • Data contains audio and video content (“continuous media”), three classes of applications: • Streaming • Unidirectional Real-Time • Interactive Real-Time 11/15/2005

Application Classes (more) • Streaming • 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 11/15/2005

Application Classes (more) • Unidirectional Real-Time: • similar to existing TV and radio stations, but delivery on the network • Non-interactive, just listen/view • Interactive Real-Time : • Phone conversation or video conference • More stringent delay requirement than Streaming and Unidirectional because of real-time nature • Video: < 150 msec acceptable • Audio: < 150 msec good, <400 msec acceptable 11/15/2005

Challenges • TCP/UDP/IP suite provides best-effort, no guarantees on expectation or variance of packet delay • Streaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested (transoceanic) • Real-Time Interactive requirements on delay and its jitter have been satisfied by over-provisioning (providing plenty of bandwidth), what will happen when the load increases?... 11/15/2005

Challenges (more) • Most router implementations use only First-Come-First-Serve (FCFS) packet processing and transmission scheduling • To mitigate impact of “best-effort” protocols, we can: • Use UDP to avoid TCP and its slow-start phase… • Buffer content at client and control playback to remedy jitter • Adapt compression level to available bandwidth 11/15/2005

Solution Approaches in IP Networks • Just add more bandwidth and enhance caching capabilities (over-provisioning)! • Need major change of the protocols : • Incorporate resource reservation (bandwidth, processing, buffering), and new scheduling policies • Set up service level agreements with applications, monitor and enforce the agreements, charge accordingly • Need moderate changes (“Differentiated Services”): • Use two traffic classes for all packets and differentiate service accordingly • Charge based on class of packets • Network capacity is provided to ensure first class packets incur no significant delay at routers 11/15/2005

Streaming • Important and growing application due to reduction of storage costs, increase in high speed net access from homes, enhancements to caching and introduction of QoS in IP networks • Audio/Video file is segmented and sent over either TCP or UDP, public segmentation protocol: Real-Time Protocol (RTP) 11/15/2005

Streaming • User interactive control is provided, e.g. the public protocol Real Time Streaming Protocol (RTSP) • Helper Application: displays content, which is typically requested via a Web browser; e.g. RealPlayer; typical functions: • Decompression • Jitter removal • Error correction: use redundant packets to be used for reconstruction of original stream • GUI for user control 11/15/2005

Streaming From Web Servers • Audio: in files sent as HTTP objects • Video (interleaved audio and images in one file, or two separate files and client synchronizes the display) sent as HTTP object(s) • A simple architecture is to have the Browser request the object(s) and after their reception pass them to the player for display - No pipelining 11/15/2005

Streaming From Web Server (more) • Alternative: set up connection between server and player, then download • Web browser requests and receives a Meta File (a file describing the object) instead of receiving the file itself; • Browser launches the appropriate Player and passes it the Meta File; • Player sets up a TCP connection with Web Server and downloads the file 11/15/2005

Meta file requests 11/15/2005

Using a Streaming Server • This gets us around HTTP, allows a choice of UDP vs. TCP and the application layer protocol can be better tailored to Streaming; many enhancements options are possible (see next slide) 11/15/2005

Options When Using a Streaming Server • Use UDP, and Server sends at a rate (Compression and 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 TCP; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP 11/15/2005

Real Time Streaming Protocol (RTSP) • For user to control display: rewind, fast forward, pause, resume, etc… • Out-of-band protocol (uses two connections, one for control messages (Port 554) and one for media stream) • RFC 2326 permits use of either TCP or UDP for the control messages connection, sometimes called the RTSP Channel • As before, meta file is communicated to web browser which then launches the Player; Player sets up an RTSP connection for control messages in addition to the connection for the streaming media 11/15/2005

Meta File Example <title>Xena: Warrior Princess</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/xena/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/xena/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> 11/15/2005

RTSP Operation 11/15/2005

RTSP Exchange Example C: SETUP rtsp://audio.example.com/xena/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- (npt = normal play time) C: PAUSE rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK 11/15/2005

Real-Time (Phone) Over IP’s Best-Effort • Internet phone applications generate packets during talk spurts • Bit rate is 8 KBytes, and every 20 msec, the sender forms a packet of 160 Bytes + a header to be discussed below • The coded voice information is encapsulated into a UDP packet and sent out; some packets may be lost; up to 20 % loss is tolerable; using TCP eliminates loss but at a considerable cost: variance in delay; FEC (forward error correction) is sometimes used to fix errors and make up losses 11/15/2005

Real-Time (Phone) Over IP’s Best-Effort • End-to-end delays above 400 msec cannot be tolerated; packets that are that delayed are ignored at the receiver • Delay jitter is handled by using timestamps, sequence numbers, and delaying playout at receivers either a fixed or a variable amount • With fixed playout delay, the delay should be as small as possible without missing too many packets; delay cannot exceed 400 msec 11/15/2005

Internet Phone with Fixed Playout Delay 11/15/2005

Adaptive Playout Delay • Objective is to use a value for p-r that tracks the network delay performance as it varies during a phone call • The playout delay is computed for each talk spurt based on observed average delay and observed deviation from this average delay • Estimated average delay and deviation of average delay are computed in a manner similar to estimates of RTT and deviation in TCP • The beginning of a talk spurt is identified from examining the timestamps in successive and/or sequence numbers of chunks 11/15/2005

Recovery From Packet Loss • Loss is in a broader sense: packet never arrives or arrives later than its scheduled playout time • Since retransmission is inappropriate for Real Time applications, FEC or Interleaving are used to reduce loss impact. • FEC is Forward Error Correction • Simplest FEC scheme adds a redundant chunk 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 11/15/2005

Recovery From Packet Loss • Mixed quality streams are used to include redundant duplicates of chunks; upon loss playout available redundant chunk, albeit a lower quality one • With one redundant low quality chunk per chunk, scheme can recover from single packet losses 11/15/2005

Piggybacking Lower Quality Stream 11/15/2005

Interleaving • Has no redundancy, but can cause delay in playout beyond Real Time requirements • Divide 20 msec of audio data into smaller units of 5 msec each and interleave • Upon loss, have a set of partially filled chunks 11/15/2005

Real-Time Protocol (RTP) • Provides standard packet format for real-time application • Typically runs over UDP • Specifies header fields below • Payload Type: 7 bits, providing 128 possible different types of encoding; eg PCM, MPEG2 video, etc. • Sequence Number: 16 bits; used to detect packet loss 11/15/2005

Real-Time Protocol (RTP) • Timestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network • Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source 11/15/2005

RTP Control Protocol (RTCP) • Protocol specifies report packets exchanged between sources and destinations of multimedia information • Three reports are defined: Receiver reception, Sender, and Source description • Reports contain statistics such as the number of packets sent, number of packets lost, inter-arrival jitter • Used to modify sender transmission rates and for diagnostics purposes 11/15/2005

RTCP Bandwidth Scaling • If each receiver sends RTCP packets to all other receivers, the traffic load resulting can be large • RTCP adjusts the interval between reports based on the number of participating receivers • Typically, limit the RTCP bandwidth to 5% of the session bandwidth, divided between the sender reports (25%) and the receivers reports (75%) 11/15/2005

Improving QoS in IP Networks • IETF groups are working on proposals to provide better QoS control in IP networks, i.e., going beyond best effort to provide some assurance for QoS • Work in Progress includes RSVP, Differentiated Services, and Integrated Services • Simple model for sharing and congestion studies: 11/15/2005

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 11/15/2005

Principles for QoS Guarantees (more) • 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 Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges: e.g. WFQ 11/15/2005

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 11/15/2005

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

Summary 11/15/2005

Scheduling And Policing Mechanisms • Scheduling: choosing the next packet for transmission on a link can be done following a number of policies; • 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 11/15/2005

Scheduling Policies • Priority Queuing: classes have different priorities; 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 with a non-empty queue • Preemptive and non-preemptive versions 11/15/2005

Scheduling Policies (more) • Round Robin: scan class queues serving one from each class that has a non-empty queue 11/15/2005

Scheduling Policies (more) • Weighted Fair Queuing: is a generalized Round Robin in which an attempt is made to provide a class with a differentiated amount of service over a given period of time 11/15/2005

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 p p minute Avg and 1500 p p sec Peak • (Max.) Burst Size: Max. number of packets sent consecutively, ie over a short period of time 11/15/2005

Policing Mechanisms • Token Bucket mechanism, provides a means for limiting input to specified Burst Size and Average Rate. 11/15/2005

Policing Mechanisms (more) • Bucket can hold b tokens; token are generated at a rate of r token/sec unless bucket is full of tokens. • Over an interval of length t, the number of packets that are admitted is less than or equal to (r t + b). • Token bucket and WFQ can be combined to provide upperbound on delay. 11/15/2005

15-441 Computer Networking