02/10/2008. Chapter 7 Multimedia Networking. Chapter 7 outline. Chapter 7: goals. MM Networking Applications. Streaming Stored Multimedia

Transcription

1 Chapter 7 Multmeda Networkng Multmeda and Qualty of Servce: What s t? multmeda applcatons: network audo and vdeo ( contnuous meda ) A note on the use of these ppt sldes: We re makng these sldes freely avalable to all (faculty, students, readers). They re n PowerPont form so you can add, modfy, and delete sldes (ncludng ths one) and slde content to sut your needs. They obvously represent a lot of work on our part. In return for use, we only ask the followng: If you use these sldes (e.g., n a class) n substantally unaltered form, that you menton ther source (after all, we d lke people to use our book!) If you post any sldes n substantally unaltered form on a www ste, that you note that they are adapted from (or perhaps dentcal to) our sldes, and note our copyrght of ths materal. Thanks and enjoy! JFK / KWR All materal copyrght J.F Kurose and K.W. Ross, All Rghts Reserved Computer Networkng: A Top Down Approach 4 th edton. Jm Kurose, Keth Ross Addson-Wesley, July : Multmeda Networkng 7-1 QoS network provdes applcaton wth level of performance needed for applcaton to functon. 7: Multmeda Networkng 7-2 Chapter 7: goals Chapter 7 outlne Prncples classfy multmeda applcatons dentfy network servces applcatons need makng the best of best effort servce Protocols and Archtectures specfc protocols for best-effort mechansms for provdng QoS archtectures for QoS 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees 7: Multmeda Networkng 7-3 7: Multmeda Networkng 7-4 MM Networkng Applcatons Classes of MM applcatons: 1) stored streamng 2) lve streamng 3) nteractve, real-tme Jtter s the varablty of packet delays wthn the same packet stream Fundamental characterstcs: typcally delay senstve end-to-end delay delay jtter loss tolerant: t: nfrequent losses cause mnor gltches antthess of data, whch are loss ntolerant but delay tolerant. 7: Multmeda Networkng 7-5 Streamng Stored Multmeda Stored streamng: meda stored at source transmtted to clent streamng: clent playout begns before all data has arrved tmng constrant for stll-to-be transmtted data: n tme for playout 7: Multmeda Networkng 7-6 1

2 Streamng Stored Multmeda: What s t? Streamng Stored Multmeda: Interactvty 1. vdeo recorded 2. vdeo sent network delay 3. vdeo receved, played out at clent tme streamng: at ths tme, clent playng out early part of vdeo, whle server stll sendng later part of vdeo VCR-lke functonalty: clent can pause, rewnd, FF, push slder bar 10 sec ntal delay OK 1-2 sec untl command effect OK tmng constrant for stll-to-be transmtted data: n tme for playout 7: Multmeda Networkng 7-7 7: Multmeda Networkng 7-8 Streamng Lve Multmeda Examples: Internet rado talk show lve sportng event Streamng (as wth streamng stored multmeda) playback buffer playback can lag tens of seconds after transmsson stll have tmng constrant Interactvty fast forward mpossble rewnd, pause possble! 7: Multmeda Networkng 7-9 Real-Tme Interactve Multmeda applcatons: IP telephony, vdeo conference, dstrbuted nteractve worlds end-end delay requrements: audo: < 150 msec good, < 400 msec OK ncludes applcaton-level (packetzaton) and network delays hgher delays notceable, mpar nteractvty sesson ntalzaton how does callee advertse ts IP address, port number, encodng algorthms? 7: Multmeda Networkng 7-10 Multmeda Over Today s Internet How should the Internet evolve to better support multmeda? TCP/UDP/IP: best-effort servce no guarantees on delay, loss?????? But you sad multmeda apps requres? QoS and level l of performance to be?? effectve!?? Today s Internet multmeda applcatons use applcaton-level technques to mtgate (as best possble) effects of delay, loss Integrated servces phlosophy: fundamental changes n Internet so that apps can reserve end-to-end bandwdth requres new, complex software n hosts & routers Lassez-fare no major changes more bandwdth when needed content dstrbuton, applcaton-layer multcast applcaton layer Dfferentated servces phlosophy: fewer changes to Internet nfrastructure, yet provde 1st and 2nd class servce What s your opnon? 7: Multmeda Networkng : Multmeda Networkng

3 A few words about audo compresson A few words about vdeo compresson analog sgnal sampled at constant rate telephone: 8,000 samples/sec CD musc: 44,100 samples/sec each sample quantzed,.e., rounded e.g., 2 8 =256 possble quantzed values each quantzed value represented by bts 8 bts for 256 values example: 8,000 samples/sec, 256 quantzed values --> 64,000 bps recever converts bts back to analog sgnal: some qualty reducton Example rates CD: Mbps MP3: 96, 128, 160 kbps Internet telephony: 5.3 kbps and up vdeo: sequence of mages dsplayed at constant rate e.g. 24 mages/sec dgtal mage: array of pxels each pxel represented by bts redundancy spatal (wthn mage) temporal (from one mage to next) Examples: MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (often used n Internet, < 1 Mbps) Research: layered (scalable) vdeo adapt layers to avalable bandwdth 7: Multmeda Networkng : Multmeda Networkng 7-14 Chapter 7 outlne Streamng Stored Multmeda 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees applcaton-level streamng technques for makng the best out of best effort servce: clent-sde bufferng use of UDP versus TCP multple encodngs of multmeda Meda Player jtter removal decompresson error concealment graphcal user nterface w/ controls for nteractvty 7: Multmeda Networkng : Multmeda Networkng 7-16 Internet multmeda: smplest approach Internet multmeda: streamng approach audo or vdeo stored n fle fles transferred as HTTP object receved n entrety at clent then passed to player audo, vdeo not streamed: no, ppelnng, long delays untl playout! 7: Multmeda Networkng 7-17 browser GETs metafle browser launches player, passng metafle player contacts server server streams audo/vdeo to player 7: Multmeda Networkng

4 Streamng from a streamng server Streamng Multmeda: Clent Bufferng constant bt rate vdeo transmsson varable network delay clent vdeo recepton ered eo buffe vd constant bt rate vdeo playout at clent allows for non-http protocol between server, meda player UDP or TCP for step (3), more shortly clent playout delay clent-sde bufferng, playout delay compensate for network-added delay, delay jtter tme 7: Multmeda Networkng : Multmeda Networkng 7-20 Streamng Multmeda: Clent Bufferng varable fll rate, x(t) buffered vdeo constant dran rate, d clent-sde bufferng, playout delay compensate for network-added delay, delay jtter Streamng Multmeda: UDP or TCP? UDP server sends at rate approprate for clent (oblvous to network congeston!) often send rate = encodng rate = constant rate then, fll rate = constant rate - packet loss short playout delay (2-5 seconds) to remove network jtter error recover: tme permttng TCP send at maxmum possble rate under TCP fll rate fluctuates due to TCP congeston control larger playout delay: smooth TCP delvery rate HTTP/TCP passes more easly through frewalls 7: Multmeda Networkng : Multmeda Networkng 7-22 Streamng Multmeda: clent rate(s) User Control of Streamng Meda: RTSP 1.5 Mbps encodng 28.8 Kbps encodng Q: how to handle dfferent clent receve rate capabltes? 28.8 Kbps dalup 100 Mbps Ethernet A: server stores, transmts multple copes of vdeo, encoded at dfferent rates 7: Multmeda Networkng 7-23 HTTP does not target multmeda content no commands for fast forward, etc. RTSP: RFC 2326 clent-server applcaton layer protocol user control: rewnd, fast forward, pause, resume, repostonng, etc What t doesn t do: doesn t defne how audo/vdeo s encapsulated for streamng over network doesn t restrct how streamed meda s transported (UDP or TCP possble) doesn t specfy how meda player buffers audo/vdeo 7: Multmeda Networkng

5 RTSP: out of band control RTSP Example FTP uses an out-ofband control channel: fle transferred over one TCP connecton. control nfo (drectory changes, fle deleton, rename) sent over separate TCP connecton out-of-band, nband channels use dfferent port numbers RTSP messages also sent out-of-band: RTSP control messages use dfferent port numbers than meda stream: out-of-band. port 554 meda stream s consdered n-band. 7: Multmeda Networkng 7-25 Scenaro: metafle communcated to web browser browser launches player player sets up an RTSP control connecton, data connecton n to streamng server r 7: Multmeda Networkng 7-26 Metafle Example RTSP Operaton <ttle>twster</ttle> <sesson> <group language=en lpsync> <swtch> <track type=audo e="pcmu/8000/1" src = "rtsp://audo.example.com/twster/audo.en/lof"> /t t / /l <track type=audo e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audo.example.com/twster/audo.en/hf"> </swtch> <track type="vdeo/jpeg" src="rtsp://vdeo.example.com/twster/vdeo"> </group> </sesson> 7: Multmeda Networkng : Multmeda Networkng 7-28 RTSP Exchange Example C: SETUP rtsp://audo.example.com/twster/audo RTSP/1.0 Transport: rtp/udp; compresson; port=3056; mode=play S: RTSP/ OK Sesson 4231 C: PLAY rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 Range: npt=0- C: PAUSE rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 Range: npt=37 C: TEARDOWN rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 Chapter 7 outlne 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees S: OK 7: Multmeda Networkng : Multmeda Networkng

6 Real-tme nteractve applcatons PC-2-PC phone Skype PC-2-phone Dalpad Net2phone Skype vdeoconference wth webcams Skype Polycom Gong to now look at a PC-2-PC Internet phone example n detal 7: Multmeda Networkng 7-31 Interactve Multmeda: Internet Phone Introduce Internet Phone by way of an example speaker s audo: alternatng talk spurts, slent perods. 64 kbps durng talk spurt pkts generated only durng talk spurts 20 msec chunks at 8 Kbytes/sec: 160 bytes data applcaton-layer header added to each chunk. chunk+header encapsulated nto UDP segment. applcaton sends UDP segment nto socket every 20 msec durng talkspurt 7: Multmeda Networkng 7-32 Internet Phone: Packet Loss and Delay network loss: IP datagram lost due to network congeston (router buffer overflow) delay loss: IP datagram arrves too late for playout at recever delays: processng, queueng n network; end- system (sender, recever) delays typcal maxmum tolerable delay: 400 ms loss tolerance: dependng on voce encodng, losses concealed, packet loss rates between 1% and 10% can be tolerated. 7: Multmeda Networkng 7-33 Delay Jtter constant bt rate transmsson varable network delay (jtter) clent playout delay clent recepton ered ta buffe dat constant bt rate playout at clent consder end-to-end delays of two consecutve packets: dfference can be more or less than 20 msec (transmsson tme dfference) tme 7: Multmeda Networkng 7-34 Internet Phone: Fxed Playout Delay recever attempts to playout each chunk exactly q msecs after chunk was generated. chunk has tme stamp t: play out chunk at t+q. chunk arrves after t+q: data arrves too late for playout, data lost tradeoff n choosng q: large q: less packet loss small q: better nteractve experence Fxed Playout Delay sender generates packets every 20 msec durng talk spurt. frst packet receved at tme r frst playout schedule: begns at p second playout schedule: begns at p packets packets generated packets receved loss playout schedule p' - r playout schedule p - r tme 7: Multmeda Networkng 7-35 r p p' 7: Multmeda Networkng

7 Adaptve Playout Delay (1) Goal: mnmze playout delay, keepng late loss rate low Approach: adaptve playout delay adjustment: estmate network delay, adjust playout delay at begnnng of each talk spurt. slent perods compressed and elongated. chunks stll played out every 20 msec durng talk spurt. t = tmestamp of the th packet r = the tme packet s receved by recever p = the tme packet s played at recever r t = network delay for th packet d = estmate of average network delay after recevngth packet dynamc estmate of average delay at recever: d = ( 1 u) d 1 + u( r t ) where u s a fxed constant (e.g., u =.01). 7: Multmeda Networkng 7-37 Adaptve playout delay (2) also useful to estmate average devaton of delay, v : v 1 u) v + u r t d = ( 1 estmates d, v calculated for every receved packet (but used only at start of talk spurt for frst packet n talk spurt, playout tme s: p = t + d + Kv where K s postve constant remanng packets n talkspurt are played out perodcally 7: Multmeda Networkng 7-38 Adaptve Playout (3) Q: How does recever determne whether packet s frst n a talkspurt? f no loss, recever looks at successve tmestamps. dfference of successve stamps > 20 msec -->talk spurt begns. wth loss possble, recever must look at both tme stamps and sequence numbers. dfference of successve stamps > 20 msec and sequence numbers wthout gaps --> talk spurt begns. Recovery from packet loss (1) Forward Error Correcton (FEC): smple scheme for every group of n chunks create redundant chunk by exclusve OR-ng n orgnal chunks send out n+1 chunks, ncreasng bandwdth by factor 1/n. can reconstruct orgnal n chunks f at most one lost chunk from n+1 chunks playout delay: enough tme to receve all n+1 packets tradeoff: ncrease n, less bandwdth waste ncrease n, longer playout delay ncrease n, hgher probablty that 2 or more chunks wll be lost 7: Multmeda Networkng : Multmeda Networkng 7-40 Recovery from packet loss (2) Recovery from packet loss (3) 2nd FEC scheme pggyback lower qualty stream send lower resoluton audo stream as redundant nformaton e.g., g, nomnal stream PCM at 64 kbps and redundant stream GSM at 13 kbps. whenever there s non-consecutve loss, recever can conceal the loss. can also append (n-1)st and (n-2)nd low-bt rate chunk 7: Multmeda Networkng 7-41 Interleavng chunks dvded nto smaller unts for example, four 5 msec unts per chunk packet contans small unts from dfferent chunks f packet lost, stll have most of every chunk no redundancy overhead, but ncreases playout delay 7: Multmeda Networkng

8 Content dstrbuton networks (CDNs) Content dstrbuton networks (CDNs) Content replcaton challengng to stream large fles (e.g., vdeo) from sngle orgn server n real tme soluton: replcate content at hundreds of servers throughout Internet content downloaded to CDN servers ahead of tme placng content close to user avods mparments (loss, delay) of sendng content over long paths CDN server typcally n edge/access network orgn server n North Amerca CDN dstrbuton node CDN server n S. Amerca CDN server n Europe CDN server n Asa 7: Multmeda Networkng 7-43 Content replcaton CDN (e.g., Akama) customer s the content provder (e.g., CNN) CDN replcates customers content n CDN servers. when provder updates content, CDN updates servers orgn server n North Amerca CDN dstrbuton node CDN server n S. Amerca CDN server n Europe CDN server n Asa 7: Multmeda Networkng 7-44 CDN example clent orgn server ( dstrbutes HTML replaces: wth HTTP request for orgn server DNS query for CDN s authortatve DNS server HTTP request for CDN server near clent CDN company (cdn.com) dstrbutes gf fles uses ts authortatve DNS server to route redrect requests 7: Multmeda Networkng 7-45 More about CDNs routng requests CDN creates a map, ndcatng dstances from leaf ISPs and CDN nodes when query arrves at authortatve DNS server: server determnes ISP from whch query orgnates uses map to determne best CDN server CDN nodes create applcaton-layer overlay network 7: Multmeda Networkng 7-46 Summary: Internet Multmeda: bag of trcks Chapter 7 outlne use UDP to avod TCP congeston control (delays) for tme-senstve traffc clent-sde adaptve playout delay: to compensate for delay server sde matches stream bandwdth to avalable clent-to-server path bandwdth chose among pre-encoded stream rates dynamc server encodng rate error recovery (on top of UDP) FEC, nterleavng, error concealment retransmssons, tme permttng CDN: brng content closer to clents 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP, RTCP, SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees 7: Multmeda Networkng : Multmeda Networkng

9 Real-Tme Protocol (RTP) RTP runs on top of UDP RTP specfes packet structure for packets carryng audo, vdeo data RFC 3550 RTP packet provdes payload type dentfcaton packet sequence numberng tme stampng RTP runs n end systems RTP packets encapsulated n UDP segments nteroperablty: f two Internet phone applcatons run RTP, then they may be able to work together RTP lbrares provde transport-layer nterface that extends UDP: port numbers, IP addresses payload type dentfcaton packet sequence numberng tme-stampng 7: Multmeda Networkng : Multmeda Networkng 7-50 RTP Example consder sendng 64 kbps PCM-encoded voce over RTP. applcaton collects encoded data n chunks, e.g., every 20 msec = 160 bytes n a chunk. audo chunk + RTP header form RTP packet, whch s encapsulated n UDP segment RTP header ndcates type of audo encodng n each packet sender can change encodng durng conference. RTP header also contans sequence numbers, tmestamps. 7: Multmeda Networkng 7-51 RTP and QoS RTP does not provde any mechansm to ensure tmely data delvery or other QoS guarantees. RTP encapsulaton s only seen at end systems (not) by ntermedate routers. routers provdng best-effort servce, makng no specal effort to ensure that RTP packets arrve at destnaton n tmely matter. 7: Multmeda Networkng 7-52 RTP Header RTP Header (2) Payload Type (7 bts): Indcates type of encodng currently beng used. If sender changes encodng n mddle of conference, sender nforms recever va payload type feld. Payload type 0: PCM mu-law, 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC, 2.4 kbps Payload type 26, Moton JPEG Payload type 31. H.261 Payload type 33, MPEG2 vdeo Sequence Number (16 bts): Increments by one for each RTP packet sent, and may be used to detect packet loss and to restore packet sequence. 7: Multmeda Networkng 7-53 Tmestamp feld (32 bytes long): samplng nstant of frst byte n ths RTP data packet for audo, tmestamp clock typcally ncrements by one for each samplng perod (for example, each 125 usecs for 8 KHz samplng clock) f applcaton generates chunks of 160 encoded samples, then tmestamp ncreases by 160 for each RTP packet when source s actve. Tmestamp clock contnues to ncrease at constant rate when source s nactve. SSRC feld (32 bts long): dentfes source of t RTP stream. Each stream n RTP sesson should have dstnct SSRC. 7: Multmeda Networkng

10 RTSP/RTP Programmng Assgnment buld a server that encapsulates stored vdeo frames nto RTP packets grab vdeo frame, add RTP headers, create UDP segments, send segments to UDP socket nclude seq numbers and tme stamps clent RTP provded for you also wrte clent sde of RTSP ssue play/pause commands server RTSP provded for you 7: Multmeda Networkng 7-55 Real-Tme Control Protocol (RTCP) works n conjuncton wth RTP. each partcpant n RTP sesson perodcally transmts RTCP control packets to all other partcpants. each RTCP packet contans sender and/or recever reports report statstcs useful to applcaton: # packets sent, # packets lost, nterarrval jtter, etc. feedback can be used to control performance sender may modfy ts transmssons based on feedback 7: Multmeda Networkng 7-56 RTCP - Contnued RTCP Packets each RTP sesson: typcally a sngle multcast address; all RTP /RTCP packets belongng to sesson use multcast address. RTP, RTCP packets dstngushed from each other va dstnct port numbers. to lmt traffc, each partcpant reduces RTCP traffc as number of conference partcpants ncreases Recever report packets: fracton of packets lost, last sequence number, average nterarrval jtter Sender report packets: SSRC of RTP stream, current tme, number of packets sent, number of bytes sent Source descrpton packets: e-mal address of sender, sender's name, SSRC of assocated RTP stream provde mappng between the SSRC and the user/host name 7: Multmeda Networkng : Multmeda Networkng 7-58 Synchronzaton of Streams RTCP Bandwdth Scalng RTCP can synchronze dfferent meda streams wthn a RTP sesson consder vdeoconferencng app for whch each sender generates one RTP stream for vdeo, one for audo. tmestamps n RTP packets ted to the vdeo, audo samplng clocks not ted to wall-clock tme each RTCP sender-report packet contans (for most recently generated packet n assocated RTP stream): tmestamp of RTP packet wall-clock tme for when packet was created. recevers uses assocaton to synchronze playout of audo, vdeo RTCP attempts to lmt ts traffc to 5% of sesson bandwdth. Example Suppose one sender, sendng vdeo at 2 Mbps. Then RTCP attempts to lmt ts traffc to 100 Kbps. RTCP gves 75% of rate to recevers; remanng 25% to sender 75 kbps s equally shared among recevers: wth R recevers, each recever gets to send RTCP traffc at 75/R kbps. sender gets to send RTCP traffc at 25 kbps. partcpant determnes RTCP packet transmsson perod by calculatng avg RTCP packet sze (across entre sesson) and dvdng by allocated rate 7: Multmeda Networkng : Multmeda Networkng

11 SIP: Sesson Intaton Protocol [RFC 3261] SIP long-term vson: all telephone calls, vdeo conference calls take place over Internet people are dentfed by names or e-mal addresses, rather than by phone numbers you can reach callee, no matter where callee roams, no matter what IP devce callee s currently usng SIP Servces Settng up a call, SIP provdes mechansms.. for caller to let callee know she wants to establsh a call so caller, callee can agree on meda type, encodng to end call determne current IP address of callee: maps mnemonc dentfer to current IP address call management: add new meda streams durng call change encodng durng call nvte others transfer, hold calls 7: Multmeda Networkng : Multmeda Networkng 7-62 Alce Settng up a call to known IP address INVITE bob@ c=in IP m=audo RTP/AVP 0 port 5060 port 5060 port OK c=in IP m=audo RTP/AVP 3 GSM ACK port 5060 µ Law audo port Bob Bob's termnal rngs Alce s SIP nvte message ndcates her port number, IP address, encodng she prefers to receve (PCM ulaw) Bob s 200 OK message ndcates hs port number, IP address, preferred encodng (GSM) SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. default SIP port number s Settng up a call (more) codec negotaton: suppose Bob doesn t have PCM ulaw encoder. Bob wll nstead reply wth 606 Not Acceptable Reply, lstng hs encoders Alce can then send new INVITE message, advertsng dfferent encoder rejectng a call Bob can reject wth reples busy, gone, payment requred, forbdden meda can be sent over RTP or some other protocol tme tme 7: Multmeda Networkng : Multmeda Networkng 7-64 Example of SIP message Name translaton and user locataon INVITE sp:bob@doman.com SIP/2.0 Va: SIP/2.0/UDP From: sp:alce@hereway.com To: sp:bob@doman.com Call-ID: a2e3a@pgeon.hereway.com Content-Type: applcaton/sdp p Content-Length: 885 c=in IP m=audo RTP/AVP 0 Notes: HTTP message syntax sdp = sesson descrpton protocol Call-ID s unque for every call. Here we don t know Bob s IP address. Intermedate SIP servers needed. Alce sends, receves SIP messages usng SIP default port 506 Alce specfes n Va: header that SIP clent sends, receves SIP messages over UDP 7: Multmeda Networkng 7-65 caller wants to call callee, but only has callee s name or e-mal address. need to get IP address of callee s current host: user moves around DHCP protocol user has dfferent IP devces (PC, PDA, car devce) result can be based on: tme of day (work, home) caller (don t want boss to call you at home) status of callee (calls sent to vocemal when callee s already talkng to someone) Servce provded by SIP servers: SIP regstrar server SIP proxy server 7: Multmeda Networkng

12 SIP Regstrar when Bob starts SIP clent, clent sends SIP REGISTER message to Bob s regstrar server (smlar functon needed by Instant Messagng) Regster Message: REGISTER sp:doman.com SIP/2.0 Va: SIP/2.0/UDP From: sp:bob@doman.com To: sp:bob@doman.com Expres: 3600 SIP Proxy Alce sends nvte message to her proxy server contans address sp:bob@doman.com proxy responsble for routng SIP messages to callee possbly through multple proxes. callee sends response back through h the same set of proxes. proxy returns SIP response message to Alce contans Bob s IP address proxy analogous to local DNS server 7: Multmeda Networkng : Multmeda Networkng 7-68 Example Caller jm@umass.edu wth places a call to keth@upenn.edu SIP proxy SIP regstrar upenn.edu SIP regstrar eurecom.fr (1) Jm sends INVITE umass.edu 3 4 message to umass SIP proxy. (2) Proxy forwards request to upenn 8 6 regstrar server. (3) upenn server returns 9 redrect response, SIP clent SIP clent ndcatng that t should try keth@eurecom.fr (4) umass proxy sends INVITE to eurecom regstrar. (5) eurecom regstrar forwards INVITE to , whch s runnng keth s SIP clent. (6-8) SIP response sent back (9) meda sent drectly between clents. Note: also a SIP ack message, whch s not shown. 7: Multmeda Networkng Comparson wth H.323 H.323 s another sgnalng protocol for real-tme, nteractve H.323 s a complete, vertcally ntegrated sute of protocols for multmeda conferencng: sgnalng, regstraton, admsson control, transport, codecs SIP s a sngle component. Works wth RTP, but does not mandate t. Can be combned wth other protocols, servces H.323 comes from the ITU (telephony). SIP comes from IETF: Borrows much of ts concepts from HTTP SIP has Web flavor, whereas H.323 has telephony flavor. SIP uses the KISS prncple: Keep t smple stupd. 7: Multmeda Networkng 7-70 Chapter 7 outlne Provdng Multple Classes of Servce 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP, RTCP, SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees 7: Multmeda Networkng 7-71 thus far: makng the best of best effort servce one-sze fts all servce model alternatve: multple classes of servce partton traffc nto classes network treats dfferent classes of traffc dfferently (analogy: VIP servce vs regular servce) granularty: dfferental servce among multple 0111 classes, not among ndvdual connectons hstory: ToS bts 7: Multmeda Networkng

13 Multple classes of servce: scenaro Scenaro 1: mxed FTP and audo H1 R1 R2 H3 Example: 1Mbps IP phone, FTP share 1.5 Mbps lnk. bursts of FTP can congest router, cause audo loss want to gve prorty to audo over FTP R1 R2 H2 R1 output nterface queue 1.5 Mbps lnk H4 Prncple 1 packet markng needed for router to dstngush between dfferent classes; and new router polcy to treat packets accordngly 7: Multmeda Networkng : Multmeda Networkng 7-74 Prncples for QOS Guarantees (more) what f applcatons msbehave (audo sends hgher than declared rate) polcng: force source adherence to bandwdth allocatons markng and polcng at network edge: smlar to ATM UNI (User Network Interface) 1 Mbps phone R1 R2 1.5 Mbps lnk packet markng and polcng Prncple 2 provde protecton (solaton) for one class from others 7: Multmeda Networkng 7-75 Prncples for QOS Guarantees (more) Allocatng fxed (non-sharable) bandwdth to flow: neffcent use of bandwdth f flows doesn t use ts allocaton 1 Mbps phone Prncple 3 R1 1 Mbps logcal lnk 1.5 Mbps lnk 0.5 Mbps logcal lnk R2 Whle provdng solaton, t s desrable to use resources as effcently as possble 7: Multmeda Networkng 7-76 Schedulng And Polcng Mechansms schedulng: choose next packet to send on lnk FIFO (frst n frst out) schedulng: send n order of arrval to queue real-world example? dscard polcy: f packet arrves to full queue: who to dscard? Tal drop: drop arrvng packet prorty: drop/remove on prorty bass random: drop/remove randomly Schedulng Polces: more Prorty schedulng: transmt hghest prorty queued packet multple classes, wth dfferent prortes class may depend on markng or other header nfo, e.g. IP source/dest, port numbers, etc.. Real world example? 7: Multmeda Networkng : Multmeda Networkng

14 Schedulng Polces: stll more round robn schedulng: multple classes cyclcally scan class queues, servng one from each class (f avalable) real world example? Schedulng Polces: stll more Weghted Far Queung: generalzed Round Robn each class gets weghted amount of servce n each cycle real-world example? 7: Multmeda Networkng : Multmeda Networkng 7-80 Polcng Mechansms Goal: lmt traffc to not exceed declared parameters Three common-used crtera: (Long term) Average Rate: how many pkts can be sent per unt tme (n the long run) crucal queston: what s the nterval length: 100 packets per sec or 6000 packets per mn have same average! Peak Rate: e.g., 6000 pkts per mn. (ppm) avg.; 1500 ppm peak rate (Max.) Burst Sze: max. number of pkts sent consecutvely (wth no ntervenng dle) 7: Multmeda Networkng 7-81 Polcng Mechansms Token Bucket: lmt nput to specfed Burst Sze and Average Rate. bucket can hold b tokens tokens generated at rate r token/sec unless bucket full over nterval of length t: number of packets admtted less than or equal to (r t + b). 7: Multmeda Networkng 7-82 Polcng Mechansms (more) token bucket, WFQ combne to provde guaranteed upper bound on delay,.e., QoS guarantee! arrvng traffc token rate, r bucket sze, b per-flow rate, R WFQ D = b/r max IETF Dfferentated Servces want qualtatve servce classes behaves lke a wre relatve servce dstncton: Platnum, Gold, Slver scalablty: smple functons n network core, relatvely complex functons at edge routers (or hosts) sgnalng, mantanng per-flow router state dffcult wth large number of flows don t defne defne servce classes, provde functonal components to buld servce classes 7: Multmeda Networkng : Multmeda Networkng

15 Dffserv Archtecture Edge router: per-flow traffc management marks packets as n-profle and out-profle b r markng schedulng. Edge-router Packet Markng profle: pre-negotated rate A, bucket sze B packet markng at edge based on per-flow profle Rate A B Core router: per class traffc management bufferng and schedulng based on markng at edge preference gven to n-profle packets User packets Possble usage of markng: class-based markng: packets of dfferent classes marked dfferently ntra-class markng: conformng porton of flow marked dfferently than non-conformng one 7: Multmeda Networkng : Multmeda Networkng 7-86 Classfcaton and Condtonng Packet s marked n the Type of Servce (TOS) n IPv4, and Traffc Class n IPv6 6 bts used for Dfferentated Servce Code Pont (DSCP) and determne PHB that the packet wll receve 2 bts are currently unused Classfcaton and Condtonng may be desrable to lmt traffc njecton rate of some class: user declares traffc profle (e.g., rate, burst sze) traffc metered, shaped f non-conformng 7: Multmeda Networkng : Multmeda Networkng 7-88 Forwardng (PHB) PHB result n a dfferent observable (measurable) forwardng performance behavor PHB does not specfy what mechansms to use to ensure requred PHB performance behavor Examples: Class A gets x% of outgong lnk bandwdth over tme ntervals of a specfed length Class A packets leave frst before packets from class B Forwardng (PHB) PHBs beng developed: Expedted Forwardng: pkt departure rate of a class equals or exceeds specfed rate logcal lnk wth a mnmum guaranteed rate Assured Forwardng: 4 classes of traffc each guaranteed mnmum amount of bandwdth each wth three drop preference parttons 7: Multmeda Networkng : Multmeda Networkng

16 Chapter 7 outlne Chapter 7 outlne 7.1 multmeda networkng applcatons 7.2 streamng stored audo and vdeo 7.3 makng the best out of best effort servce 7.4 protocols for real-tme nteractve applcatons RTP, RTCP, SIP 7.5 provdng multple classes of servce 7.6 provdng QoS guarantees 7.1 Multmeda Networkng Applcatons 7.2 Streamng stored audo and vdeo 7.3 Real-tme Multmeda: Internet Phone study 7.4 Protocols for Real- Tme Interactve Applcatons RTP,RTCP,SIP 7.5 Dstrbutng Multmeda: content dstrbuton networks 7.6 Beyond Best Effort 7.7 Schedulng and Polcng Mechansms 7.8 Integrated Servces and Dfferentated Servces 7.9 RSVP 7: Multmeda Networkng : Multmeda Networkng 7-92 Prncples for QOS Guarantees (more) Basc fact of lfe: can not support traffc demands beyond lnk capacty 1 Mbps phone R1 R2 QoS guarantee scenaro Resource reservaton call setup, sgnalng (RSVP) traffc, QoS declaraton per-element admsson control 1 Mbps phone 1.5 Mbps lnk request/ reply Prncple 4 Call Admsson: flow declares ts needs, network may block call (e.g., busy sgnal) f t cannot meet needs QoS-senstve schedulng (e.g., WFQ) 7: Multmeda Networkng : Multmeda Networkng 7-94 IETF Integrated Servces archtecture for provdng QOS guarantees n IP networks for ndvdual applcaton sessons resource reservaton: routers mantan state nfo (a la VC) of allocated resources, QoS req s admt/deny new call setup requests: Queston: can newly arrvng flow be admtted wth performance guarantees whle not volated QoS guarantees made to already admtted flows? Call Admsson Arrvng sesson must : declare ts QOS requrement R-spec: defnes the QOS beng requested characterze traffc t wll send nto network T-spec: defnes traffc characterstcs sgnalng protocol: needed to carry R-spec and T- spec to routers (where reservaton s requred) RSVP 7: Multmeda Networkng : Multmeda Networkng

17 Intserv QoS: Servce models [rfc2211, rfc 2212] Guaranteed servce: worst case traffc arrval: leaky-bucket-polced source smple (mathematcally provable) bound on delay [Parekh 1992, Cruz 1988] arrvng traffc token rate, r bucket sze, b per-flow rate, R WFQ D = b/r max Controlled load servce: "a qualty of servce closely approxmatng the QoS that same flow would receve from an unloaded network element." 7: Multmeda Networkng 7-97 Sgnalng n the Internet connectonless (stateless) forwardng by IP routers best effort servce + = no network sgnalng protocols n ntal IP desgn New requrement: reserve resources along end-to-end path (end system, routers) for QoS for multmeda applcatons RSVP: Resource Reservaton Protocol [RFC 2205] allow users to communcate requrements to network n robust and effcent way..e., sgnalng! earler Internet Sgnalng protocol: ST-II [RFC 1819] 7: Multmeda Networkng 7-98 RSVP Desgn Goals 1. accommodate heterogeneous recevers (dfferent bandwdth along paths) 2. accommodate dfferent applcatons wth dfferent resource requrements 3. make multcast a frst class servce, wth adaptaton to multcast group membershp m 4. leverage exstng multcast/uncast routng, wth adaptaton to changes n underlyng uncast, multcast routes 5. control protocol overhead to grow (at worst) lnear n # recevers 6. modular desgn for heterogeneous underlyng technologes RSVP: does not specfy how resources are to be reserved rather: a mechansm for communcatng needs determne routes packets wll take that s the job of routng protocols sgnalng decoupled d from routng nteract wth forwardng of packets separaton of control (sgnalng) and data (forwardng) planes 7: Multmeda Networkng : Multmeda Networkng RSVP: overvew of operaton senders, recever jon a multcast group done outsde of RSVP senders need not jon group sender-to-network sgnalng path message: make sender presence known to routers path teardown: delete sender s path state from routers recever-to-network sgnalng reservaton message: reserve resources from sender(s) to recever reservaton teardown: remove recever reservatons network-to-end-system sgnalng path error reservaton error 7: Multmeda Networkng Chapter 7: Summary Prncples classfy multmeda applcatons dentfy network servces applcatons need makng the best of best effort servce Protocols and Archtectures specfc protocols for best-effort mechansms for provdng QoS archtectures for QoS multple classes of servce QoS guarantees, admsson control 7: Multmeda Networkng