Multimedia, Quality of Service. Chapter 7: Goals. About video compression. About audio compression. CSE 4213: Computer Networks II

Transcription

1 Multmeda, Qualty of Servce CSE 4213: Computer Networks II Suprakash Datta Multmeda applcatons: network audo and vdeo ( contnuous meda ) Offce: CSEB 3043 Phone: ext Course page: These sldes are adapted from Jm Kurose s sldes. QoS network provdes applcaton wth level of performance needed for applcaton to functon. 3/19/2007 COSC S.Datta 1 3/19/2007 COSC S.Datta 2 Chapter 7: Goals Prncples Classfy multmeda applcatons Identfy the network servces the apps need Makng the est of est effort servce Mechansms for provdng QoS Protocols and Archtectures Specfc protocols for est-effort Archtectures for QoS Multmeda Networkng Applcatons Classes of MM applcatons: 1) Streamng stored audo and vdeo 2) Streamng lve audo and vdeo 3) Real-tme nteractve audo and vdeo Fundamental characterstcs: Typcally delay senstve end-to-end delay delay jtter But loss tolerant: nfrequent losses cause mnor gltches Antthess of data, whch are loss ntolerant ut delay tolerant. Jtter s the varalty of packet delays wthn the same packet stream 3/19/2007 COSC S.Datta 3 3/19/2007 COSC S.Datta 4 Aout audo compresson Aout 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 possle quantzed values Each quantzed value represented y ts 8 ts for 256 values Example: 8,000 samples/sec, 256 quantzed values --> 64,000 ps Recever converts t ack to analog sgnal: some qualty reducton Example rates CD: Mps MP3: 96, 128, 160 kps Internet telephony: kps Vdeo s sequence of mages dsplayed at constant rate e.g. 24 mages/sec Dgtal mage s array of pxels Each pxel represented y ts Redundancy spatal temporal Examples: MPEG 1 (CD-ROM) 1.5 Mps MPEG2 (DVD) 3-6 Mps MPEG4 (often used n Internet, < 1 Mps) Research: Layered (scalale) vdeo adapt layers to avalale andwdth 3/19/2007 COSC S.Datta 5 3/19/2007 COSC S.Datta 6

2 Cumulatve data Streamng Stored Multmeda Streamng Stored Multmeda: What s t? Streamng: meda stored at source transmtted to clent streamng: clent playout egns efore all data has arrved tmng constrant for stll-to-e transmtted data: n tme for playout 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 3/19/2007 COSC S.Datta 7 3/19/2007 COSC S.Datta 8 Streamng Stored Multmeda: Interactvty VCR-lke functonalty: clent can pause, rewnd, FF, push slder ar 10 sec ntal delay OK 1-2 sec untl command effect OK RTSP often used (more later) tmng constrant for stll-to-e transmtted data: n tme for playout Streamng Lve Multmeda Examples: Internet rado talk show Lve sportng event Streamng playack uffer playack can lag tens of seconds after transmsson stll have tmng constrant Interactvty fast forward mpossle rewnd, pause possle! 3/19/2007 COSC S.Datta 9 3/19/2007 COSC S.Datta 10 Interactve, Real-Tme Multmeda Multmeda Over the Internet applcatons: IP telephony, vdeo conference, dstruted nteractve worlds end-end delay requrements: audo: < 150 msec good, < 400 msec OK ncludes applcaton-level (packetzaton) and network delays hgher delays notceale, mpar nteractvty sesson ntalzaton how does callee advertse ts IP address, port numer, encodng algorthms? 3/19/2007 COSC S.Datta 11 TCP/UDP/IP: est-effort servce no guarantees on delay, loss?????? But you sad multmeda apps requres QoS and level of performance to e? effectve!?? Today s Internet multmeda applcatons use applcaton-level technques to mtgate (as est possle) effects of delay, loss 3/19/2007 COSC S.Datta 12??

3 Cumulatve data How should the Internet evolve to etter support multmeda? Integrated servces phlosophy: Fundamental changes n Internet so that apps can reserve end-to-end andwdth Requres new, complex software n hosts & routers Lassez-fare no major changes more andwdth when needed content dstruton, applcaton-layer multcast Dfferentated servces phlosophy: Fewer changes to Internet nfrastructure, yet provde 1st and 2nd class servce. What s your opnon? applcaton layer 3/19/2007 COSC S.Datta 13 Streamng Stored Multmeda Applcaton-level streamng technques for makng the est out of est effort servce: clent sde ufferng use of UDP versus TCP multple encodngs of multmeda Meda Player jtter removal decompresson error concealment graphcal user nterface w/ controls for nteractvty 3/19/2007 COSC S.Datta 14 Internet multmeda: smplest approach Internet multmeda: streamng approach audo or vdeo stored n fle fles transferred as HTTP oject receved n entrety at clent then passed to player audo, vdeo not streamed: no, ppelnng, long delays untl playout! 3/19/2007 COSC S.Datta 15 rowser GETs metafle rowser launches player, passng metafle player contacts server server streams audo/vdeo to player 3/19/2007 COSC S.Datta 16 Streamng from a streamng server Streamng Multmeda: Clent Bufferng constant t rate vdeo transmsson varale network delay clent vdeo recepton uffered vdeo constant t rate vdeo playout at clent Ths archtecture allows for non-http protocol etween server and meda player Can also use UDP nstead of TCP. clent playout delay Clent-sde ufferng, playout delay compensate for network-added delay, delay jtter tme 3/19/2007 COSC S.Datta 17 3/19/2007 COSC S.Datta 18

4 Streamng Multmeda: Clent Bufferng varale fll rate, x(t) uffered vdeo constant dran rate, d Clent-sde ufferng, playout delay compensate for network-added delay, delay jtter Streamng Multmeda: UDP or TCP? UDP server sends at rate approprate for clent (olvous to network congeston!) often send rate = encodng rate = constant rate then, fll rate = constant rate - packet loss short playout delay (2-5 seconds) to compensate for network delay jtter error recover: tme permttng TCP send at maxmum possle 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 3/19/2007 COSC S.Datta 19 3/19/2007 COSC S.Datta 20 Streamng Multmeda: clent rate(s) 1.5 Mps encodng 28.8 Kps encodng Q: how to handle dfferent clent receve rate capaltes? 28.8 Kps dalup 100Mps Ethernet A: server stores, transmts multple copes of vdeo, encoded at dfferent rates 3/19/2007 COSC S.Datta 21 User Control of Streamng Meda: RTSP HTTP Does not target multmeda content No commands for fast forward, etc. RTSP: RFC 2326 Clent-server applcaton layer protocol. For user to control dsplay: rewnd, fast forward, pause, resume, repostonng, etc What t doesn t do: does not defne how audo/vdeo s encapsulated for streamng over network does not restrct how streamed meda s transported; t can e transported over UDP or TCP does not specfy how the meda player uffers audo/vdeo 3/19/2007 COSC S.Datta 22 RTSP: out of and control RTSP Example FTP uses an out-of-and control channel: A fle s transferred over one TCP connecton. Control nformaton (drectory changes, fle deleton, fle renamng, etc.) s sent over a separate TCP connecton. The out-of-and and n-and channels use dfferent port numers. RTSP messages are also sent out-of-and: RTSP control messages use dfferent port numers than the meda stream: out-ofand. Port 554 The meda stream s consdered n-and. Scenaro: metafle communcated to we rowser rowser launches player player sets up an RTSP control connecton, data connecton to streamng server 3/19/2007 COSC S.Datta 23 3/19/2007 COSC S.Datta 24

5 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"> <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> 3/19/2007 COSC S.Datta 25 3/19/2007 COSC S.Datta 26 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 Real-tme nteractve applcatons PC-2-PC phone nstant messagng servces are provdng ths PC-2-phone Dalpad Net2phone vdeoconference wth Wecams Gong to now look at a PC-2-PC Internet phone example n detal C: TEARDOWN rtsp://audo.example.com/twster/audo.en/lof RTSP/1.0 Sesson: 4231 S: OK 3/19/2007 COSC S.Datta 27 3/19/2007 COSC S.Datta 28 Interactve Multmeda: Internet Phone Introduce Internet Phone y way of an example speaker s audo: alternatng talk spurts, slent perods. 64 kps durng talk spurt pkts generated only durng talk spurts 20 msec chunks at 8 Kytes/sec: 160 ytes 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. Internet Phone: Packet Loss and Delay network loss: IP datagram lost due to network congeston (router uffer overflow) delay loss: IP datagram arrves too late for playout at recever delays: processng, queueng n network; endsystem (sender, recever) delays typcal maxmum tolerale delay: 400 ms loss tolerance: dependng on voce encodng, losses concealed, packet loss rates etween 1% and 10% can e tolerated. 3/19/2007 COSC S.Datta 29 3/19/2007 COSC S.Datta 30

6 Cumulatve data constant t rate transmsson Delay Jtter varale network delay (jtter) clent playout delay clent recepton uffered data constant t rate playout at clent Consder the end-to-end delays of two consecutve packets: dfference can e more or less than 20 msec tme 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 for q: large q: less packet loss small q: etter nteractve experence 3/19/2007 COSC S.Datta 31 3/19/2007 COSC S.Datta 32 packets Fxed Playout Delay Sender generates packets every 20 msec durng talk spurt. Frst packet receved at tme r Frst playout schedule: egns at p Second playout schedule: egns at p packets generated packets receved loss playout schedule p - r playout schedule p' - r r p p' 3/19/2007 COSC S.Datta 33 tme Adaptve Playout Delay Goal: mnmze playout delay, keepng late loss rate low Approach: adaptve playout delay adjustment: Estmate network delay, adjust playout delay at egnnng 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 y recever p = the tme packet s playedat recever r t = network delay for th packet d = estmate of averagenetwork 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). 3/19/2007 COSC S.Datta 34 Adaptve Playout Delay - 2 Also useful to estmate the average devaton of the delay, v : v = ( 1 u) v 1 + u r t d The estmates d and v are calculated for every receved packet, although they are only used at the egnnng of a talk spurt. For frst packet n talk spurt, playout tme s: p = t + d + Kv Adaptve Playout Delay - 3 Q: How does recever determne whether packet s frst n a talkspurt? If no loss, recever looks at successve tmestamps. dfference of successve stamps > 20 msec -->talk spurt egns. Wth loss possle, recever must look at oth tme stamps and sequence numers. dfference of successve stamps > 20 msec and sequence numers wthout gaps --> talk spurt egns. where K s a postve constant. Remanng packets n talkspurt are played out perodcally 3/19/2007 COSC S.Datta 35 3/19/2007 COSC S.Datta 36

7 Recovery from packet loss forward error correcton (FEC): smple scheme for every group of n chunks create a redundant chunk y exclusve OR-ng the n orgnal chunks send out n+1 chunks, ncreasng the andwdth y factor 1/n. can reconstruct the orgnal n chunks f there s at most one lost chunk from the n+1 chunks Playout delay needs to e fxed to the tme to receve all n+1 packets Tradeoff: ncrease n, less andwdth waste ncrease n, longer playout delay ncrease n, hgher proalty that 2 or more chunks wll e lost Recovery from packet loss - 2 2nd FEC scheme pggyack lower qualty stream send lower resoluton audo stream as the redundant nformaton e.g., nomnal stream PCM at 64 kps and redundant stream GSM at 13 kps. Whenever there s non-consecutve loss, the recever can conceal the loss. Can also append (n-1)st and (n-2)nd lowt rate chunk 3/19/2007 COSC S.Datta 37 3/19/2007 COSC S.Datta 38 Recovery from packet loss - 3 Summary: Internet Multmeda: ag of trcks Interleavng chunks are roken up nto smaller unts for example, 4 5 msec unts per chunk Packet contans small unts from dfferent chunks f packet s lost, stll have most of every chunk has no redundancy overhead ut adds to playout delay 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 andwdth to avalale clentto-server path andwdth chose among pre-encoded stream rates dynamc server encodng rate error recovery (on top of UDP) FEC, nterleavng retransmssons, tme permttng conceal errors: repeat neary data 3/19/2007 COSC S.Datta 39 3/19/2007 COSC S.Datta 40 Next 7.4 Protocols for Real-Tme Interactve Applcatons RTP,RTCP,SIP Real-Tme Protocol (RTP) RTP specfes a packet structure for packets carryng audo and vdeo data RFC RTP packet provdes payload type dentfcaton packet sequence numerng tmestampng RTP runs n the end systems. RTP packets are encapsulated n UDP segments Interoperalty: If two Internet phone applcatons run RTP, then they may e ale to work together 3/19/2007 COSC S.Datta 41 3/19/2007 COSC S.Datta 42

8 RTP runs on top of UDP RTP Example RTP lrares provde a transport-layer nterface that extend UDP: port numers, IP addresses payload type dentfcaton packet sequence numerng tme-stampng Consder sendng 64 kps PCM-encoded voce over RTP. Applcaton collects the encoded data n chunks, e.g., every 20 msec = 160 ytes n a chunk. The audo chunk along wth the RTP header form the RTP packet, whch s encapsulated nto a UDP segment. RTP header ndcates type of audo encodng n each packet sender can change encodng durng a conference. RTP header also contans sequence numers and tmestamps. 3/19/2007 COSC S.Datta 43 3/19/2007 COSC S.Datta 44 RTP and QoS RTP does not provde any mechansm to ensure tmely delvery of data or provde other qualty of servce guarantees. RTP encapsulaton s only seen at the end systems: t s not seen y ntermedate routers. Routers provdng est-effort servce do not make any specal effort to ensure that RTP packets arrve at the destnaton n a tmely matter. RTP Header Payload Type (7 ts): Indcates type of encodng currently eng used. If sender changes encodng n mddle of conference, sender nforms the recever through ths payload type feld. Payload type 0: PCM mu-law, 64 kps Payload type 3, GSM, 13 kps Payload type 7, LPC, 2.4 kps Payload type 26, Moton JPEG Payload type 31. H.261 Payload type 33, MPEG2 vdeo Sequence Numer (16 ts): Increments y one for each RTP packet sent, and may e used to detect packet loss and to restore packet sequence. 3/19/2007 COSC S.Datta 45 3/19/2007 COSC S.Datta 46 RTP Header - 2 Real-Tme Control Protocol (RTCP) Tmestamp feld (32 ytes long). Reflects the samplng nstant of the frst yte n the RTP data packet. For audo, tmestamp clock typcally ncrements y one for each samplng perod (for example, each 125 usecs for a 8 KHz samplng clock) f applcaton generates chunks of 160 encoded samples, then tmestamp ncreases y 160 for each RTP packet when source s actve. Tmestamp clock contnues to ncrease at constant rate when source s nactve. SSRC feld (32 ts long). Identfes the source of the RTP stream. Each stream n a RTP sesson should have a dstnct SSRC. 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 Statstcs nclude numer of packets sent, numer of packets lost, nterarrval jtter, etc. Feedack can e used to control performance Sender may modfy ts transmssons ased on feedack 3/19/2007 COSC S.Datta 47 3/19/2007 COSC S.Datta 48

9 RTCP - Contnued - For an RTP sesson there s typcally a sngle multcast address; all RTP and RTCP packets elongng to the sesson use the multcast address. - RTP and RTCP packets are dstngushed from each other through the use of dstnct port numers. - To lmt traffc, each partcpant reduces hs RTCP traffc as the numer of conference partcpants ncreases. 3/19/2007 COSC S.Datta 49 RTCP Packets Recever report packets: Source descrpton packets: fracton of packets lost, last e-mal address of sender, sequence numer, average sender's name, SSRC of nterarrval jtter. assocated RTP stream. Sender report packets: Provde mappng etween SSRC of the RTP stream, the SSRC and the the current tme, the user/host name. numer of packets sent, and the numer of ytes sent. 3/19/2007 COSC S.Datta 50 Synchronzaton of Streams RTCP can synchronze dfferent meda streams wthn a RTP sesson. Consder vdeoconferencng app for whch each sender generates one RTP stream for vdeo and one for audo. Tmestamps n RTP packets ted to the vdeo and audo samplng clocks not ted to the wallclock tme Each RTCP sender-report packet contans (for the most recently generated packet n the assocated RTP stream): tmestamp of the RTP packet wall-clock tme for when packet was created. Recevers can use ths assocaton to synchronze the playout of audo and vdeo. 3/19/2007 COSC S.Datta 51 RTCP Bandwdth Scalng RTCP attempts to lmt ts traffc to 5% of the sesson andwdth. Example Suppose one sender, sendng vdeo at a rate of 2 Mps. Then RTCP attempts to lmt ts traffc to 100 Kps. RTCP gves 75% of ths rate to the recevers; remanng 25% to the sender The 75 kps s equally shared among recevers: Wth R recevers, each recever gets to send RTCP traffc at 75/R kps. Sender gets to send RTCP traffc at 25 kps. Partcpant determnes RTCP packet transmsson perod y calculatng avg RTCP packet sze (across the entre sesson) and dvdng y allocated rate. 3/19/2007 COSC S.Datta 52 SIP Sesson Intaton Protocol Comes from IETF SIP long-term vson All telephone calls and vdeo conference calls take place over the Internet People are dentfed y names or e-mal addresses, rather than y phone numers. You can reach the callee, no matter where the callee roams, no matter what IP devce the callee s currently usng. SIP Servces Settng up a call Provdes mechansms for caller to let callee know she wants to estalsh a call Provdes mechansms so that caller and callee can agree on meda type and encodng. Provdes mechansms 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 Invte others Transfer and hold calls 3/19/2007 COSC S.Datta 53 3/19/2007 COSC S.Datta 54

10 Alce Settng up a call to a known IP address tme INVITE o@ 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 tme Bo's termnal rngs Alce s SIP nvte message ndcates her port numer & IP address. Indcates encodng that Alce prefers to receve (PCM ulaw) Bo s 200 OK message ndcates hs port numer, IP address & preferred encodng (GSM) SIP messages can e sent over TCP or UDP; here sent over RTP/UDP. Default SIP port numer s /19/2007 COSC S.Datta 55 Bo Settng up a call (more) Codec negotaton: Suppose Bo doesn t have PCM ulaw encoder. Bo wll nstead reply wth 606 Not Acceptale Reply and lst encoders he can use. Alce can then send a new INVITE message, advertsng an approprate encoder. Rejectng the call Bo can reject wth reples usy, gone, payment requred, fordden. Meda can e sent over RTP or some other protocol. 3/19/2007 COSC S.Datta 56 Example of SIP message INVITE sp:o@doman.com SIP/2.0 Va: SIP/2.0/UDP From: sp:alce@hereway.com To: sp:o@doman.com Call-ID: a2e3a@pgeon.hereway.com Content-Type: applcaton/sdp 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 Bo s IP address. Intermedate SIP servers wll e necessary. Alce sends and receves SIP messages usng the SIP default port numer 506. Alce specfes n Va: header that SIP clent sends and receves SIP messages over UDP Name translaton and user locaton Caller wants to call callee, ut 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 e ased on: tme of day (work, home) caller (don t want oss to call you at home) status of callee (calls sent to vocemal when callee s already talkng to someone) Servce provded y SIP servers: SIP regstrar server SIP proxy server 3/19/2007 COSC S.Datta 57 3/19/2007 COSC S.Datta 58 SIP Regstrar When Bo starts SIP clent, clent sends SIP REGISTER message to Bo s regstrar server (smlar functon needed y Instant Messagng) Regster Message: REGISTER sp:doman.com SIP/2.0 Va: SIP/2.0/UDP From: sp:o@doman.com To: sp:o@doman.com Expres: 3600 SIP Proxy Alce sends nvte message to her proxy server contans address sp:o@doman.com Proxy responsle for routng SIP messages to callee possly through multple proxes. Callee sends response ack through the same set of proxes. Proxy returns SIP response message to Alce contans Bo s IP address Note: proxy s analogous to local DNS server 3/19/2007 COSC S.Datta 59 3/19/2007 COSC S.Datta 60

11 Caller places a call to keth@upenn.edu Example 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 ack (9) meda sent drectly etween clents. Note: also a SIP ack message, whch s not shown. 3/19/2007 COSC S.Datta 61 2 Comparson wth H.323 H.323 s another sgnalng protocol for real-tme, nteractve multmeda H.323 s a complete, vertcally ntegrated sute of protocols for multmeda conferencng: sgnalng, regstraton, admsson control, transport and codecs. SIP s a sngle component. Works wth RTP, ut does not mandate t. Can e comned wth other protocols and servces. H.323 comes from the ITU (telephony). SIP comes from IETF: Borrows much of ts concepts from HTTP. SIP has a We flavor, whereas H.323 has a telephony flavor. SIP uses the KISS prncple: Keep t smple stupd. 3/19/2007 COSC S.Datta 62 Next: 7.5 Dstrutng Multmeda: content dstruton networks 3/19/2007 COSC S.Datta 63 Content dstruton networks (CDN) 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 dstruton node CDN server n S. Amerca CDN server n Europe CDN server n Asa 3/19/2007 COSC S.Datta 64 Content dstruton networks (CDN) 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 dstruton node CDN server n S. Amerca CDN server n Europe CDN server n Asa CDN example orgn server ( dstrutes HTML replaces: wth Orgn server CDNs authortatve DNS server Neary CDN server HTTP request for DNS query for HTTP request for CDN company (cdn.com) dstrutes gf fles uses ts authortatve DNS server to route redrect requests 3/19/2007 COSC S.Datta 65 3/19/2007 COSC S.Datta 66

12 More aout CDNs Next: routng requests CDN creates a map, ndcatng dstances from leaf ISPs and CDN nodes when query arrves at authortatve DNS server: 7.6 Beyond Best Effort server determnes ISP from whch query orgnates uses map to determne est CDN server CDN nodes create applcaton-layer overlay network 3/19/2007 COSC S.Datta 67 3/19/2007 COSC S.Datta 68 Improvng QOS n IP Networks Thus far: makng the est of est effort Future: next generaton Internet wth QoS guarantees RSVP: sgnalng for resource reservatons Dfferentated Servces: dfferental guarantees Integrated Servces: frm guarantees smple model for sharng and congeston studes: Prncples for QOS Guarantees Example: 1MpsI P phone, FTP share 1.5 Mps lnk. ursts of FTP can congest router, cause audo loss want to gve prorty to audo over FTP Prncple 1 packet markng needed for router to dstngush etween dfferent classes; and new router polcy to treat packets accordngly 3/19/2007 COSC S.Datta 69 3/19/2007 COSC S.Datta 70 Prncples for QOS Guarantees - 2 what f applcatons msehave (audo sends hgher than declared rate) polcng: force source adherence to andwdth allocatons markng and polcng at network edge: smlar to ATM UNI (User Network Interface) Prncples for QOS Guarantees - 3 Allocatng fxed (non-sharale) andwdth to flow: neffcent use of andwdth f flows doesn t use ts allocaton Prncple 2 provde protecton (solaton) for one class from others 3/19/2007 COSC S.Datta 71 Prncple 3 Whle provdng solaton, t s desrale to use resources as effcently as possle 3/19/2007 COSC S.Datta 72

13 Prncples for QOS Guarantees - 4 Summary of QoS Prncples Basc fact of lfe: can not support traffc demands eyond lnk capacty Prncple 4 Call Admsson: flow declares ts needs, network may lock call (e.g., usy sgnal) f t cannot meet needs Let s next look at mechansms for achevng ths. 3/19/2007 COSC S.Datta 73 3/19/2007 COSC S.Datta 74 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 ass random: drop/remove randomly Schedulng Polces: contd 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 numers, etc.. Real world example? 3/19/2007 COSC S.Datta 75 3/19/2007 COSC S.Datta 76 Schedulng Polces: contd Schedulng Polces: contd round ron schedulng: multple classes cyclcally scan class queues, servng one from each class (f avalale) real world example? Weghted Far Queung: generalzed Round Ron each class gets weghted amount of servce n each cycle real-world example? 3/19/2007 COSC S.Datta 77 3/19/2007 COSC S.Datta 78

14 Polcng Mechansms Goal: lmt traffc to not exceed declared parameters Three common-used crtera: (Long term) Average Rate: how many pkts can e 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. numer of pkts sent consecutvely (wth no ntervenng dle) Polcng Mechansms - 2 Token Bucket: lmt nput to specfed Burst Sze and Average Rate. ucket can hold tokens tokens generated at rate r token/sec unless ucket full over nterval of length t: numer of packets admtted less than or equal to (r t + ). 3/19/2007 COSC S.Datta 79 3/19/2007 COSC S.Datta 80 Polcng Mechansms - 3 token ucket, WFQ comne to provde guaranteed upper ound on delay,.e., QoS guarantee! Next: 7.8 Integrated Servces and Dfferentated Servces arrvng traffc token rate, r ucket sze, per-flow rate, R WFQ D = /R max 3/19/2007 COSC S.Datta 81 3/19/2007 COSC S.Datta 82 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: Intserv: QoS guarantee scenaro Resource reservaton call setup, sgnalng (RSVP) traffc, QoS declaraton per-element admsson control Queston: can newly arrvng flow e admtted wth performance guarantees whle not volated QoS guarantees made to already admtted flows? QoS-senstve schedulng (e.g., WFQ) request/ reply 3/19/2007 COSC S.Datta 83 3/19/2007 COSC S.Datta 84

15 Arrvng sesson must : declare ts QOS requrement Call Admsson R-spec: defnes the QOS eng 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 3/19/2007 COSC S.Datta 85 Intserv QoS: Servce models [rfc2211, rfc 2212] Guaranteed servce: worst case traffc arrval: leakyucket-polced source smple (mathematcally provale) ound on delay [Parekh 1992, Cruz 1988] arrvng traffc token rate, r ucket sze, per-flow rate, R WFQ Controlled load servce: "a qualty of servce closely approxmatng the QoS that same flow would receve from an unloaded network element." D = /R max 3/19/2007 COSC S.Datta 86 IETF Dfferentated Servces Concerns wth Intserv: Scalalty: sgnalng, mantanng per-flow router state dffcult wth large numer of flows Flexle Servce Models: Intserv has only two classes. Also want qualtatve servce classes ehaves lke a wre relatve servce dstncton: Platnum, Gold, Slver Dffserv approach: smple functons n network core, relatvely complex functons at edge routers (or hosts) Don t defne defne servce classes, provde functonal components to uld servce classes 3/19/2007 COSC S.Datta 87 Edge router: per-flow traffc management marks packets as n-profle and out-profle Core router: Dffserv Archtecture per class traffc management ufferng and schedulng ased on markng at edge preference gven to n-profle packets Assured Forwardng markng r schedulng 3/19/2007 COSC S.Datta 88. Edge-router Packet Markng profle: pre-negotated rate A, ucket sze B packet markng at edge ased on per-flow profle Rate A B Classfcaton and Condtonng Packet s marked n the Type of Servce (TOS) n IPv4, and Traffc Class n IPv6 6 ts used for Dfferentated Servce Code Pont (DSCP) and determne PHB that the packet wll receve 2 ts are currently unused User packets Possle usage of markng: class-ased markng: packets of dfferent classes marked dfferently ntra-class markng: conformng porton of flow marked dfferently than non-conformng one 3/19/2007 COSC S.Datta 89 3/19/2007 COSC S.Datta 90

16 Classfcaton and Condtonng may e desrale to lmt traffc njecton rate of some class: user declares traffc profle (e.g., rate, urst sze) traffc metered, shaped f non-conformng Forwardng (PHB) PHB result n a dfferent oservale (measurale) forwardng performance ehavor PHB does not specfy what mechansms to use to ensure requred PHB performance ehavor Examples: Class A gets x% of outgong lnk andwdth over tme ntervals of a specfed length Class A packets leave frst efore packets from class B 3/19/2007 COSC S.Datta 91 3/19/2007 COSC S.Datta 92 Forwardng (PHB) PHBs eng 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 andwdth each wth three drop preference parttons Sgnalng n the Internet connectonless (stateless) forwardng y IP routers est 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 roust and effcent way..e., sgnalng! earler Internet Sgnalng protocol: ST-II [RFC 1819] 3/19/2007 COSC S.Datta 93 3/19/2007 COSC S.Datta 94 RSVP Desgn Goals RSVP: does not 1. accommodate heterogeneous recevers (dfferent andwdth along paths) 2. accommodate dfferent applcatons wth dfferent resource requrements 3. make multcast a frst class servce, wth adaptaton to multcast group memershp 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 specfy how resources are to e reserved rather: a mechansm for communcatng needs determne routes packets wll take that s the jo of routng protocols sgnalng decoupled from routng nteract wth forwardng of packets separaton of control (sgnalng) and data (forwardng) planes 3/19/2007 COSC S.Datta 95 3/19/2007 COSC S.Datta 96

17 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 Path msgs: RSVP sender-to-network sgnalng path message contents: address: uncast destnaton, or multcast group flowspec: andwdth requrements spec. flter flag: f yes, record denttes of upstream senders (to allow packets flterng y source) prevous hop: upstream router/host ID refresh tme: tme untl ths nfo tmes out path message: communcates sender nfo, and reversepath-to-sender routng nfo later upstream forwardng of recever reservatons 3/19/2007 COSC S.Datta 97 3/19/2007 COSC S.Datta 98 RSVP: smple audo conference RSVP: uldng up path state,,,, H5 oth senders and recevers multcast group m1 no flterng: packets from any sender forwarded audo rate: only one multcast routng tree possle R1 R2 R3,, H5 all send path messages on (address=m1, Tspec=, flter-spec=no-flter,refresh=100) Suppose sends frst path message n out L6 n L6 out L5 n out R1 L6 R2 R3 L5 H5 H5 3/19/2007 COSC S.Datta 99 3/19/2007 COSC S.Datta 100 RSVP: uldng up path state - 2 next, H5 sends path message, creatng more state n routers RSVP: uldng up path state 3,, H5 send path msgs, completng path state tales n L6 out L6 n L5 L6 out L5 L6 n out n L6 out L6 n L5 L6 out L5 L6 n out R1 L6 R2 R3 L5 R1 L6 R2 R3 L5 H5 H5 3/19/2007 COSC S.Datta 101 3/19/2007 COSC S.Datta 102

18 reservaton msgs: recever-tonetwork sgnalng reservaton message contents: desred andwdth: flter type: no flter: any packets address to multcast group can use reservaton fxed flter: only packets from specfc set of senders can use reservaton dynamc flter: senders who s packets can e forwarded across lnk wll change (y recever choce) over tme. flter spec reservatons flow upstream from recever-to-senders, reservng resources, creatng addtonal, recever-related state at routers RSVP: recever reservaton example 1 wants to receve audo from all other senders reservaton msg flows uptree to sources only reserves enough andwdth for 1 audo stream reservaton s of type no flter any sender can use reserved andwdth R1 L6 R2 R3 L5 H5 3/19/2007 COSC S.Datta 103 3/19/2007 COSC S.Datta 104 RSVP: recever reservaton example 1 reservaton msgs flows uptree to sources routers, hosts reserve andwdth needed on downstream lnks towards RSVP: recever reservaton example 1 next, makes no-flter reservaton for andwdth forwards to R1, R1 forwards to and R2 (?) R2 takes no acton, snce already reserved on L6 n out () L6 L6 n L5 out L5 L6() n out () n L6 out () () L6 n L5 out L5 L6() n out () R1 L6 R2 R3 L5 R1 L6 R2 R3 L5 H5 H5 3/19/2007 COSC S.Datta 105 3/19/2007 COSC S.Datta 106 RSVP: recever reservaton: ssues RSVP: example 2 What f multple senders (e.g.,,, H5) over lnk (e.g., L6)? artrary nterleavng of packets L6 flow polced y leaky ucket: f ++H5 sendng rate exceeds, packet loss wll occur n L6 out () () L6 n L5 out L5 n out L6() R1 L6 R2 R3 L5 (), are only senders send path messages as efore, ndcatng fltered reservaton Routers store upstream senders for each upstream lnk wll want to receve from (only) R1 L6 R2 R3 H5 3/19/2007 COSC S.Datta 107 3/19/2007 COSC S.Datta 108

19 RSVP: example 2 RSVP: example 2, are only senders send path messages as efore, ndcatng fltered reservaton recever sends reservaton message for source at andwdth propagated upstream towards, reservng n out, L6 (-va- ; -va-r2 ) L6(-va- ) (-va-r2 ) n, (-va- ; -va-r3 ) out (-va-r2 ) (-va- ) n, L6 (-va- ;-va-r2()) out L6(-va- ) (-va-r2 ) n, (-va- ; -va-r2 ) out (-va-62 ) (-va- ()) R1 R2 L6 R3 n L6, L6(-va-R3 ) out (-va-r1 ) R1 R2 L6 R3 n L6, L6(-va-R3 ()) out (-va-r1 ) 3/19/2007 COSC S.Datta 109 3/19/2007 COSC S.Datta 110 RSVP: soft-state senders perodcally resend path msgs to refresh (mantan) state recevers perodcally resend resv msgs to refresh (mantan) state path and resv msgs have TTL feld, specfyng refresh nterval RSVP: soft-state suppose (sender) leaves wthout performng teardown eventually state n routers wll tmeout and dsappear! n, L6 (-va- ;-va-r2()) out L6(-va- ) (-va-r2 ) n out, (-va- ; -va-r3 ) (-va-62 ) (-va- ()) n, L6 (-va- ;-va-r2()) out L6(-va- ) (-va-r2 ) n, (-va- ; -va-r3 ) out (-va-62 ) (-va- ()) R2 R1 L6 R3 n L6, L6(-va-R3 ()) out (-va-r1 ) 3/19/2007 COSC S.Datta 111 R2 R1 L6 R3 gone fshng! n L6, L6(-va-R3 ()) out (-va-r1 ) 3/19/2007 COSC S.Datta 112 The many uses of reservaton/path refresh recover from an earler lost refresh message expected tme untl refresh receved must e longer than tmeout nterval! (short tmer nterval desred) Handle recever/sender that goes away wthout teardown Sender/recever state wll tmeout and dsappear Reservaton refreshes wll cause new reservatons to e made to a recever from a sender who has joned snce recevers last reservaton refresh E.g., n prevous example, s only recever, only sender. Path/reservaton messages complete, data flows jons as sender, nothng happens untl refreshes reservaton, causng R3 to forward reservaton to, whch allocates andwdth RSVP: reflectons multcast as a frst class servce recever-orented reservatons use of soft-state 3/19/2007 COSC S.Datta 113 3/19/2007 COSC S.Datta 114

20 Multmeda Networkng: Summary multmeda applcatons and requrements makng the est of today s est effort servce schedulng and polcng mechansms next generaton Internet: Intserv, RSVP, Dffserv What else s eng done? Many, many research projects! Adaptve encodngs, e.g. Multple descrpton codng (MDC) Applcaton to mole networks... Multcast tree constructon usng overlays, technques for handlng flash crowds. My students and I have een workng on mproved algorthms for applcaton layer multcast for streamng lve vdeo. 3/19/2007 COSC S.Datta 115 3/19/2007 COSC S.Datta 116