Transcription
4/28/10Chapter 7Multimedia NetworkingA note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers).They’re in PowerPoint form so you can add, modify, and delete slides(including this one) and slide content to suit your needs. They obviouslyrepresent a lot of work on our part. In return for use, we only ask thefollowing: If you use these slides (e.g., in a class) in substantially unaltered form,that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, thatyou note that they are adapted from (or perhaps identical to) our slides, andnote our copyright of this material.Computer Networking: A TopDown Approach5th edition.Jim Kurose, Keith RossAddison-Wesley, April 2009.Thanks and enjoy! JFK / KWRAll material copyright 1996-2009J.F Kurose and K.W. Ross, All Rights Reserved7: Multimedia Networking7-1Multimedia and Quality of Service: What is it?multimedia applications:network audio and video(“continuous media”)QoSnetwork providesapplication with level ofperformance needed forapplication to function.7: Multimedia Networking7-21
4/28/10Chapter 7: goalsPrinciples classify multimedia applications identify network services applications need making the best of best effort serviceProtocols and Architectures specific protocols for best-effort mechanisms for providing QoS architectures for QoS7: Multimedia Networking7-3Chapter 7 outline7.1 multimedia networkingapplications7.2 streaming stored audioand video7.3 making the best out ofbest effort service7.4 protocols for real-timeinteractive applications7.5 providing multipleclasses of service7.6 providing QoSguaranteesRTP,RTCP,SIP7: Multimedia Networking7-42
4/28/10MM Networking ApplicationsClasses of MM applications:1) stored streaming2) live streaming3) interactive, real-timeFundamentalcharacteristics: typically delay sensitive end-to-end delaydelay jitter loss tolerant: infrequentJitter is the variabilityof packet delays withinthe same packet streamlosses cause minorglitches antithesis of data, whichare loss intolerant butdelay tolerant.7: Multimedia Networking7-5Streaming Stored MultimediaStored streaming: media stored at source transmitted to client streaming: client playout beginsbefore all data has arrived timing constraint for still-to-betransmitted data: in time for playout7: Multimedia Networking7-63
4/28/10Cumulative dataStreaming Stored Multimedia:What is it?1. videorecorded2. videosentnetworkdelay3. video received,played out at clienttimestreaming: at this time, clientplaying out early part of video,while server still sending laterpart of video7: Multimedia Networking7-7Streaming Stored Multimedia: Interactivity VCR-like functionality: client canpause, rewind, FF, push slider bar 10 sec initial delay OK 1-2 sec until command effect OK timing constraint for still-to-betransmitted data: in time for playout7: Multimedia Networking7-84
4/28/10Streaming Live MultimediaExamples: Internet radio talk show live sporting eventStreaming (as with streaming stored multimedia) playback buffer playback can lag tens of seconds aftertransmission still have timing constraintInteractivity fast forward impossible rewind, pause possible!7: Multimedia Networking7-9Real-Time Interactive Multimedia applications: IP telephony,video conference, distributedinteractive worlds end-end delay requirements: audio: 150 msec good, 400 msec OK includes application-level (packetization) and networkdelays higher delays noticeable, impair interactivity session initialization howdoes callee advertise its IP address, portnumber, encoding algorithms?7: Multimedia Networking7-105
4/28/10Multimedia Over Today’s InternetTCP/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 applicationsuse application-level techniques to mitigate(as best possible) effects of delay, loss7: Multimedia Networking7-11How should the Internet evolve to bettersupport multimedia?Integrated services philosophy: fundamental changes inInternet so that apps canreserve end-to-endbandwidth requires new, complexsoftware in hosts & routersLaissez-faire no major changes more bandwidth whenneeded content distribution,application-layer multicast application layerDifferentiated servicesphilosophy: fewer changes to Internetinfrastructure, yetprovide 1st and 2nd classserviceWhat’s your opinion?7: Multimedia Networking7-126
4/28/10A few words about audio compression analog signal sampledat constant rate telephone: 8,000samples/secCD music: 44,100samples/sec each sample quantized,i.e., rounded e.g., 28 256 possiblequantized values each quantized valuerepresented by bits 8 bits for 256 values example: 8,000samples/sec, 256quantized values -- 64,000 bps receiver converts bitsback to analog signal: some quality reductionExample rates CD: 1.411 Mbps MP3: 96, 128, 160 kbps Internet telephony:5.3 kbps and up7: Multimedia Networking7-13A few words about video compression video: sequence ofimages displayed atconstant rate e.g. 24 images/sec digital image: array ofpixels each pixel representedby bits redundancy spatial (within image) temporal (from one imageto next)Examples: MPEG 1 (CD-ROM) 1.5Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (often used inInternet, 1 Mbps)Research: layered (scalable) video adapt layers to availablebandwidth7: Multimedia Networking7-147
4/28/10Streaming Stored Multimediaapplication-level streamingtechniques for makingthe best out of besteffort service: client-side buffering use of UDP versus TCP multiple encodings ofmultimediaMedia Player jitter removal decompression error concealment graphical user interfacew/ controls forinteractivity7: Multimedia Networking7-15constant bitrate videotransmissionvariablenetworkdelayclient videoreceptionconstant bitrate videoplayout at clientbufferedvideoCumulative dataStreaming Multimedia: Client Bufferingtimeclient playoutdelay client-side buffering, playout delay compensatefor network-added delay, delay jitter7: Multimedia Networking7-168
4/28/10Streaming Multimedia: Client Bufferingconstantdrainrate, dvariable fillrate, x(t)bufferedvideo client-side buffering, playout delay compensatefor network-added delay, delay jitter7: Multimedia Networking7-17Streaming Multimedia: UDP or TCP?UDP server sends at rate appropriate for client (oblivious tonetwork congestion !) often send rate encoding rate constant rate then, fill rate constant rate - packet loss short playout delay (2-5 seconds) to remove network jitter error recover: time permittingTCP send at maximum possible rate under TCP fill rate fluctuates due to TCP congestion control larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls7: Multimedia Networking7-189
4/28/10Streaming Multimedia: client rate(s)1.5 Mbps encoding28.8 Kbps encodingQ: how to handle different client receive ratecapabilities? 28.8 Kbps dialup 100 Mbps EthernetA: server stores, transmits multiple copiesof video, encoded at different rates7: Multimedia Networking7-19Real-time interactive applications PC-2-PC phone Skype PC-2-phone Dialpad Net2phoneGoing to now look ata PC-2-PC Internetphone example indetail Skype videoconference withwebcams Skype Polycom7: Multimedia Networking7-2010
4/28/10Interactive Multimedia: Internet PhoneIntroduce Internet Phone by way of an example speaker’s audio: alternating talk spurts, silentperiods. 64kbps during talk spurt pktsgenerated only during talk spurts 20msec chunks at 8 Kbytes/sec: 160 bytesdata application-layer header added to each chunk. chunk header encapsulated into UDP segment. application sends UDP segment into socket every20 msec during talkspurt7: Multimedia Networking7-21Internet Phone: Packet Loss and Delay network loss: IP datagram lost due to networkcongestion (router buffer overflow) delay loss: IP datagram arrives too late forplayout at receiver delays: processing, queueing in network; end-system (sender, receiver) delays typical maximum tolerable delay: 400 ms loss tolerance: depending on voice encoding, lossesconcealed, packet loss rates between 1% and 10%can be tolerated.7: Multimedia Networking7-2211
4/28/10constant entreceptionconstant bitrate playoutat clientbuffereddataCumulative dataDelay Jittertimeclient playoutdelay consider end-to-end delays of two consecutivepackets: difference can be more or less than 20msec (transmission time difference)7: Multimedia Networking7-23Internet Phone: Fixed Playout Delay receiver attempts to playout each chunk exactly qmsecs after chunk was generated. chunk has time stamp t: play out chunk at t q . chunk arrives after t q: data arrives too latefor playout, data “lost” tradeoff in choosing q: large q: less packet loss small q: better interactive experience7: Multimedia Networking7-2412
4/28/10Fixed Playout Delay sender generates packets every 20 msec during talk spurt. first packet received at time r first playout schedule: begins at p second playout schedule: begins at p’7: Multimedia Networking7-25Adaptive Playout Delay (1) Goal: minimize playout delay, keeping late loss rate low Approach: adaptive playout delay adjustment: estimate network delay, adjust playout delay at beginning ofeach talk spurt.silent periods compressed and elongated.chunks still played out every 20 msec during talk spurt.dynamic estimate of average delay at receiver:where u is a fixed constant (e.g., u .01).7: Multimedia Networking7-2613
4/28/10Adaptive playout delay (2) alsouseful to estimate average deviation of delay, vi :di , vi calculated for every received packet(but used only at start of talk spurt estimates forfirst packet in talk spurt, playout time is:where K is positive constant remainingpackets in talkspurt are played out periodically7: Multimedia Networking7-27Adaptive Playout (3)Q: How does receiver determine whether packet isfirst in a talkspurt? if no loss, receiver looks at successive timestamps. difference of successive stamps 20 msec -- talk spurtbegins. with loss possible, receiver must look at both timestamps and sequence numbers. difference of successive stamps 20 msec and sequencenumbers without gaps -- talk spurt begins.7: Multimedia Networking7-2814
4/28/10Recovery from packet loss (1)Forward Error Correction playout delay: enough(FEC): simple schemetime to receive all n 1 for every group of npacketschunks create redundant tradeoff:chunk by exclusive OR increase n, less-ing n original chunksbandwidth waste send out n 1 chunks, increase n, longerincreasing bandwidth byplayout delayfactor 1/n. increase n, higher can reconstruct original nprobability that 2 orchunks if at most onemore chunks will belost chunk from n 1lostchunks7: Multimedia Networking7-29Recovery from packet loss (2)2nd FEC scheme “piggyback lowerquality stream” send lower resolutionaudio stream asredundant information e.g., nominalstream PCM at 64 kbpsand redundant streamGSM at 13 kbps. wheneverthere is non-consecutive loss,receiver can conceal the loss. can also append (n-1)st and (n-2)nd low-bit ratechunk7: Multimedia Networking7-3015
4/28/10Recovery from packet loss (3)Interleaving chunks divided into smallerunits for example, four 5 msecunits per chunk packet contains small unitsfrom different chunks if packet lost, still have mostof every chunk no redundancy overhead, butincreases playout delay7: Multimedia Networking7-31Content distribution networks (CDNs)Content replication challenging to stream largefiles (e.g., video) from singleorigin server in real time solution: replicate content athundreds of serversthroughout Internet content downloaded to CDNservers ahead of time placing content “close” touser avoids impairments(loss, delay) of sendingcontent over long paths CDN server typically inedge/access networkorigin serverin North AmericaCDN distribution nodeCDN serverin S. America CDN serverin EuropeCDN serverin Asia7: Multimedia Networking7-3216
4/28/10Content distribution networks (CDNs)Content replication CDN (e.g., Akamai)customer is the contentprovider (e.g., CNN) CDN replicatescustomers’ content inCDN servers. when provider updatescontent, CDN updatesserversorigin serverin North AmericaCDN distribution nodeCDN serverin S. America CDN serverin EuropeCDN serverin Asia7: Multimedia NetworkingCDN example7-33HTTP request forwww.foo.com/sports/sports.htmlorigin server12client3DNS query for www.cdn.comCDN’s authoritativeDNS serverHTTP request forwww.cdn.com/www.foo.com/sports/ruth.gifCDN server near clientorigin server (www.foo.com) distributes HTML orts/ruth.gifhttp://www.cdn.com/www.foo.comCDN company (cdn.com) distributes gif files uses its authoritativeDNS server to routeredirect requests7: Multimedia Networking7-3417
4/28/10Summary: Internet Multimedia: bag of tricks use UDP to avoid TCP congestion control (delays)for time-sensitive traffic client-side adaptive playout delay: to compensatefor delay server side matches stream bandwidth to availableclient-to-server path bandwidth chose among pre-encoded stream ratesdynamic server encoding rate error recovery (on top of UDP) FEC, interleaving, error concealment retransmissions, time permitting CDN: bring content closer to clients7: Multimedia Networking7-35Real-Time Protocol (RTP) RTP specifies packetstructure for packetscarrying audio, videodata RFC 3550 RTP packet provides payload typeidentification packet sequencenumbering time stamping RTP runs in end systems RTP packetsencapsulated in UDPsegments interoperability: if twoInternet phoneapplications run RTP,then they may be ableto work together7: Multimedia Networking7-3618
4/28/10RTP runs on top of UDPRTP libraries provide transport-layer interfacethat extends UDP: port numbers, IP addresses payload type identification packet sequence numbering time-stamping7: Multimedia Networking7-37RTP Example consider sending 64kbps PCM-encodedvoice over RTP. application collectsencoded data inchunks, e.g., every 20msec 160 bytes in achunk. audio chunk RTPheader form RTPpacket, which isencapsulated in UDPsegment RTP header indicatestype of audio encodingin each packet sender can changeencoding duringconference. RTP header alsocontains sequencenumbers, timestamps.7: Multimedia Networking7-3819
4/28/10RTP and QoS RTP does not provide any mechanism to ensuretimely data delivery or other QoS guarantees. RTP encapsulation is only seen at end systems(not) by intermediate routers. routers providing best-effort service, makingno special effort to ensure that RTP packetsarrive at destination in timely matter.7: Multimedia Networking7-39RTP HeaderPayload Type (7 bits): Indicates type of encoding currently beingused. If sender changes encoding in middle of conference, senderinforms receiver via payload type field. Payload type 0: PCM mu-law, 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC, 2.4 kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 videoSequence Number (16 bits): Increments by one for each RTP packetsent, and may be used to detect packet loss and to restore packetsequence.7: Multimedia Networking7-4020
4/28/10RTP Header (2) Timestamp field (32 bytes long): sampling instantof first byte in this RTP data packet for audio, timestamp clock typically increments by onefor each sampling period (for example, each 125 usecsfor 8 KHz sampling clock)if application generates chunks of 160 encoded samples,then timestamp increases by 160 for each RTP packetwhen source is active. Timestamp clock continues toincrease at constant rate when source is inactive.SSRC field (32 bits long): identifies source of t RTPstream. Each stream in RTP session should have distinctSSRC.7: Multimedia Networking7-41Real-Time Control Protocol (RTCP) works in conjunctionwith RTP. each participant in RTPsession periodicallytransmits RTCP controlpackets to all otherparticipants. each RTCP packetcontains sender and/orreceiver reports report statistics useful toapplication: # packetssent, # packets lost,interarrival jitter, etc. feedback can be usedto controlperformance sender may modify itstransmissions based onfeedback7: Multimedia Networking7-4221
4/28/10RTCP PacketsReceiver report packets: fraction of packetslost, last sequencenumber, averageinterarrival jitterSender report packets: SSRC of RTP stream,current time, numberof packets sent,number of bytes sentSource descriptionpackets: e-mail address ofsender, sender'sname, SSRC ofassociated RTPstream provide mappingbetween the SSRCand the user/hostname7: Multimedia Networking7-43SIP: Session Initiation Protocol [RFC 3261]SIP long-term vision: all telephone calls, video conference calls takeplace over Internet people are identified by names or e-mailaddresses, rather than by phone numbers you can reach callee, no matter where calleeroams, no matter what IP device callee iscurrently using7: Multimedia Networking7-4422
4/28/10SIP Services Setting up a call, SIPprovides mechanisms . for caller to letcallee know shewants to establish acall so caller, callee canagree on media type,encoding to end call determine current IPaddress of callee: maps mnemonicidentifier to current IPaddress call management: add new media streamsduring call change encoding duringcall invite others transfer, hold calls7: Multimedia Networking7-45Setting up a call to known IP address Alice’sSIP invitemessage indicates herport number, IP address,encoding she prefers toreceive (PCM ulaw) Bob’s200 OK messageindicates his port number,IP address, preferredencoding (GSM) SIPmessages can besent over TCP or UDP;here sent over RTP/UDP. defaultis 5060.SIP port number7: Multimedia Networking7-4623
4/28/10Setting up a call (more) codec negotiation: supposeBob doesn’thave PCM ulawencoder. Bob will instead replywith 606 NotAcceptable Reply,listing his encodersAlice can then sendnew INVITEmessage, advertisingdifferent encoder rejecting a call Bobcan reject withreplies “busy,”“gone,” “paymentrequired,”“forbidden” media can be sent overRTP or some otherprotocol7: Multimedia Networking7-47Example of SIP messageINVITE sip:bob@domain.com SIP/2.0Via: SIP/2.0/UDP 167.180.112.24From: sip:alice@hereway.comTo: sip:bob@domain.comCall-ID: a2e3a@pigeon.hereway.comContent-Type: application/sdpContent-Length: 885c IN IP4 167.180.112.24m audio 38060 RTP/AVP 0Notes: HTTP message syntax sdp session description protocol Call-ID is unique for every call. Herewe don’t knowBob’s IP address.Intermediate SIPservers needed. Alicesends, receivesSIP messages usingSIP default port 506 Alicespecifies in Via:header that SIP clientsends, receives SIPmessages over UDP7: Multimedia Networking7-4824
4/28/10Name translation and user locataion caller wants to callcallee, but only hascallee’s name or e-mailaddress. need to get IP addressof callee’s currenthost: user moves aroundDHCP protocoluser has different IPdevices (PC, PDA, cardevice) result can be based on: time of day (work, home) caller (don’t want boss tocall you at home) status of callee (calls sentto voicemail when callee isalready talking tosomeone)Service provided by SIPservers: SIP registrar server SIP proxy server7: Multimedia Networking7-49SIP Registrar when Bob starts SIP client, client sends SIPREGISTER message to Bob’s registrar server(similar function needed by Instant Messaging)Register Message:REGISTER sip:domain.com SIP/2.0Via: SIP/2.0/UDP 193.64.210.89From: sip:bob@domain.comTo: sip:bob@domain.comExpires: 36007: Multimedia Networking7-5025
4/28/10SIP Proxy Alice sends invite message to her proxy server contains address sip:bob@domain.com proxy responsible for routing SIP messages tocallee possibly through multiple proxies. callee sends response back through the same setof proxies. proxy returns SIP response message to Alice contains Bob’s IP address proxy analogous to local DNS server7: Multimedia Networking7-51ExampleCaller jim@umass.eduwith places acall to keith@upenn.edu(1) Jim sends INVITEmessage to umass SIPproxy. (2) Proxy forwardsrequest to upennregistrar server.(3) upenn server returnsredirect response,indicating that it shouldtry keith@eurecom.fr(4) umass proxy sends INVITE to eurecom registrar. (5) eurecomregistrar forwards INVITE to 197.87.54.21, which is running keith’s SIPclient. (6-8) SIP response sent back (9) media sent directlybetween clients.Note: also a SIP ack message, which is not shown.7: Multimedia Networking7-5226
4/28/10Providing Multiple Classes of Service thus far: making the best of best effort service one-sizefits all service model alternative: multiple classes of service partition traffic into classes network treats different classes of trafficdifferently (analogy: VIP service vs regular service) granularity:differential service0111among multipleclasses, not amongindividualconnections history: ToS bits7: Multimedia Networking7-53Multiple classes of service: scenarioH1H2R1R1 outputinterfacequeueH3R21.5 Mbps linkH47: Multimedia Networking7-5427
4/28/10Scenario 1: mixed FTP and audio Example: 1Mbps IP phone, FTP share 1.5 Mbps link. bursts of FTP can congest router, cause audio loss want to give priority to audio over FTPR1R2Principle 1packet marking needed for router to distinguishbetween different classes; and new router policyto treat packets accordingly7: Multimedia Networking7-55Principles for QOS Guarantees (more) what if applications misbehave (audio sends higherthan declared rate) policing: force source adherence to bandwidth allocations marking and policing at network edge: similar to ATM UNI (User Network Interface)1 MbpsphoneR1R21.5 Mbps linkpacket marking and policingPrinciple 2provide protection (isolation) for one class from others7: Multimedia Networking7-5628
4/28/10Principles for QOS Guarantees (more)fixed (non-sharable) bandwidth to flow:inefficient use of bandwidth if flows doesn’t useits allocation Allocating1 MbpsphoneR11 Mbps logical linkR21.5 Mbps link0.5 Mbps logical linkPrinciple 3While providing isolation, it is desirable to useresources as efficiently as possible7: Multimedia Networking7-57Scheduling And Policing Mechanisms scheduling: choose next packet to send on link FIFO (first in first out) scheduling: send in order ofarrival to queue real-world example?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 randomly7: Multimedia Networking7-5829
4/28/10Scheduling Policies: morePriority scheduling: transmit highest priority queuedpacket multiple classes, with different priorities class may depend on marking or other header info, e.g. IPsource/dest, port numbers, etc.Real world example?7: Multimedia Networking7-59Scheduling Policies: still moreround robin scheduling: multiple classes cyclically scan class queues, serving one from eachclass (if available) real world example?7: Multimedia Networking7-6030
4/28/10Scheduling Policies: still moreWeighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in eachcycle real-world example?7: Multimedia Networking7-61Policing MechanismsGoal: limit traffic to not exceed declared parametersThree common-used criteria: (Long term) Average Rate: how many pkts can be sentper unit time (in the long run) crucial question: what is the interval length: 100 packets persec or 6000 packets per min have same average!Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500ppm peak rate (Max.) Burst Size: max. number of pkts sentconsecutively (with no intervening idle) 7: Multimedia Networking7-6231
4/28/10Policing MechanismsToken Bucket: limit input to specified Burst Size andAverage Rate. bucket can hold b tokens tokens generated at rater token/sec unless bucketfull over interval of length t: number of packetsadmitted less than or equal to (r t b).7: Multimedia Networking7-63Policing Mechanisms (more) token bucket, WFQ combine to provide guaranteedupper bound on delay, i.e., QoS guarantee!arrivingtraffictoken rate, rbucket size, bWFQper-flowrate, RD b/Rmax7: Multimedia Networking7-6432
4/28/10Principles for QOS Guarantees (more) Basic fact of life: can not support traffic demandsbeyond link capacity1 MbpsphoneR1R21.5 Mbps link1 MbpsphonePrinciple 4Call Admission: flow declares its needs, network mayblock call (e.g., busy signal) if it cannot meet needs7: Multimedia Networking7-65QoS guarantee scenario Resource reservation call setup, signaling (RSVP) traffic, QoS declaration per-element admission controlrequest/reply QoS-sensitivescheduling (e.g.,WFQ)7: Multimedia Networking7-6633
4/28/10Call AdmissionArriving 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) RSVP7: Multimedia Networking7-67Intserv QoS: Service models [rfc2211, rfc 2212]Guaranteed service:Controlled load service: worst case traffic arrival: "a quality of service closelyleaky-bucket-policed sourceapproximating the QoS thatsame flow would receivefrom an unloaded networkelement." simple (mathematicallyprovable) bound on delay[Parekh 1992, Cruz 1988]arrivingtraffictoken rate, rbucket size, bWFQper-flowrate, RD b/Rmax7: Multimedia Networking7-6834
4/28/10Chapter 7: SummaryPrinciples classify multimedia applications identify network services applications need making the best of best effort serviceProtocols and Architectures specific protocols for best-effort mechanisms for providing QoS architectures for QoS multipleclasses of service QoS guarantees, admission control7: Multimedia Networking7-6935
Protocols and Architectures specific protocols for best-effort mechanisms for providing QoS architectures for QoS 7: Multimedia Networking 7-4 Chapter 7 outline 7.1 multimedia networking applications 7.2 streaming stored audio and video 7.3 making the best out of best effort service 7.4 protocols for real-time interactive applications RTP,RTCP,SIP
