Network Programming. Lecture outline. Lecture goals. multimedia applications: network audio and video ( continuous media )

Transcription

1 Network Programmng Multmeda and Qualty of Servce: What s t? multmeda applcatons: network audo and vdeo ( contnuous meda ) Dr. Thaer Hayajneh Computer Engneerng Department Multmeda Networkng QoS network provdes applcaton wth level of performance needed for applcaton to functon. 1 2 Lecture goals 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 Lecture outlne 1 multmeda networkng applcatons 2 streamng stored audo and vdeo 3 makng the best out of best effort servce 4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 5 provdng multple classes of servce 6 provdng QoS guarantees 3 4

2 MM Networkng Applcatons Classes of MM applcatons: 1) stored streamng 2) lve streamng 3) nteractve, real-tme Fundamental characterstcs: typcally delay senstve end-to-end delay delay jtter loss tolerant: nfrequent nt losses cause mnor gltches antthess of data, whch are loss ntolerant but Jtter s the varablty delay tolerant. of packet delays wthn the same packet stream 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 5 6 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 streamng: at ths tme, clent playng out early part of vdeo, whle server stll sendng later part of vdeo tme 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 8

3 Streamng Lve Multmeda Real-Tme Interactve 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! 9 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? 10 Multmeda Over Today s Internet How should the Internet evolve to better support multmeda? TCP/UDP/IP: best-effort 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 Hard Vs Soft guarantee? 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? 11 12

4 A few words about audo compresson A few words about vdeo compresson analog sgnal sampled example: 8,000 at constant rate samples/sec, 256 telephone: 8,000 quantzed values --> samples/sec 64,000 bps CD musc: 44,100 recever converts bts samples/sec back to analog sgnal: each sample quantzed, some qualty reducton.e., rounded Example rates e.g., 2 8 =256 possble quantzed values CD: Mbps each quantzed value MP3: 96, 128, 160 kbps represented by bts Internet telephony: 8 bts for 256 values 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 Lecture outlne Streamng Stored Multmeda 1 multmeda networkng applcatons 2 streamng stored audo and vdeo 3 makng the best out of best effort servce 4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 5 provdng multple classes of servce 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 15 16

5 Internet multmeda: smplest approach Internet multmeda: streamng approach audo or vdeo stored n fle fles transferred as HTTP object receved n entrety ty at clent then passed to player audo, vdeo not streamed: no, ppelnng, long delays untl playout! browser GETs metafle browser launches player, passng metafle player contacts server server streams audo/vdeo to player Streamng from a streamng server Streamng Multmeda: Clent Bufferng constant t bt rate vdeo transmsson varable network delay clent vdeo recepton buffe ered vd eo 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 19 20

6 Streamng Multmeda: Clent Bufferng varable fll rate, x(t) buffered vdeo constant t 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 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 t A: server stores, transmts multple copes of vdeo, encoded at dfferent rates 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 24

7 RTSP: out of band control RTSP Example FTP uses an out-of- band 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: of RTSP control messages use dfferent port numbers than meda stream: out-of-band. port 554 meda stream s consdered n-band. Scenaro: metafle communcated to web browser browser launches player player sets up an RTSP control connecton, data connecton to streamng server 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 st / /l <track type=audo e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audo.example.com/twster/audo.en/hf"> / / /hf" </swtch> <track type="vdeo/jpeg" src="rtsp://vdeo.example.com/twster/vdeo"> </group> </sesson> 27 28

8 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 Lecture outlne 1 multmeda networkng applcatons 2 streamng stored audo and vdeo 3 makng the best out of best effort servce 4 protocols for real-tme nteractve applcatons RTP,RTCP,SIP 5 provdng multple classes of servce 6 provdng QoS guarantees S: OK Real-tme nteractve applcatons Interactve Multmeda: Internet Phone PC-2-PC phone Skype PC-2-phone Dalpad Net2phone Skype vdeoconference n wth webcams Skype Polycom Gong to now look at a PC-2-PC Internet phone example n detal 31 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 32

9 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 d on voce encodng, losses concealed, packet loss rates between 1% and 10% can be tolerated. 33 Delay Jtter constant t bt rate transmsson varable network delay (jtter) clent playout delay clent recepton buffe ered dat ta 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 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 t 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 35 r p p' 36

10 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 recevng th packet 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 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) Adaptve Playout (3) Recovery from packet loss (1) 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. 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 39 40

11 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., 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 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 42 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 y n edge/access network CDN server n S. Amerca orgn server n North Amerca CDN dstrbuton node CDN server n Europe CDN server n Asa 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 CDN server n S. Amerca orgn server n North Amerca CDN dstrbuton node CDN server n Europe CDN server n Asa 43 44

12 CDN example clent orgn server ( dstrbutes HTML replaces: wth / / t / th orgn server HTTP request for DNS query for CDN s authortatve DNS server HTTP request for CDN server near clent CDN company (cdn.com) com) dstrbutes gf fles uses ts authortatve DNS server to route redrect requests 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 Summary: Internet Multmeda: bag of trcks use UDP to avod TCP congeston control (delays) for tme-senstve t 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 Lecture outlne 1 multmeda networkng applcatons 2 streamng stored audo and vdeo 3 makng the best out of best effort servce 4 protocols for real-tme nteractve applcatons RTP, RTCP, SIP, H provdng multple classes of servce 6 provdng QoS guarantees 47 48

13 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 RTP Example consder sendng 64 kbps PCM-encoded d 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 h 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. 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

14 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 t packet loss and to restore packet sequence. 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 the RTP stream. Each stream n RTP sesson ss should have dstnct t SSRC. 54 Real-Tme Control Protocol (RTCP) RTCP - Contnued 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 56 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 57

15 RTCP Packets Synchronzaton of Streams 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 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 Bandwdth Scalng SIP: Sesson Intaton Protocol [RFC 3261] 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 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 60 61

16 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 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 tme tme 63 Settng up a call (more) Example of SIP message codec negotaton: suppose se Bob doesn esn 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 64 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 65

17 Name translaton and user locataon SIP Regstrar 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 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: 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 s message to Alce contans Bob s IP address proxy analogous to local DNS server 68 Example Caller jm@umass.edu wth places a call to keth@upenn.edu (1) Jm sends INVITE message to umass SIP proxy. (2) Proxy forwards request to upenn regstrar server. (3) upenn server returns redrect response, ndcatng that t should try keth@eurecom.fr SIP proxy umass.edu 2 3 SIP regstrar upenn.edu 4 SIP regstrar eurecom.fr SIP clent SIP clent (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. 69

18 Comparson wth H.323 Lecture outlne 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 H323 has telephony flavor. SIP uses the KISS prncple: Keep t smple stupd. 1 multmeda networkng applcatons 2 streamng stored audo and vdeo 3 makng the best out of best effort servce 4 protocols for real-tme nteractve applcatons RTP, RTCP, SIP 5 provdng multple classes of servce 6 provdng QoS guarantees Provdng Multple Classes of Servce Multple classes of servce: scenaro 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 H2 H1 R1 R1 output nterface queue 1.5 Mbps lnk R2 H4 H

19 Scenaro 1: mxed FTP and audo 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 Prncples for QOS Guarantees (more) what f applcatons msbehave (audo sends hgher than declared d 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 Prncple 1 packet markng needed for router to dstngush between dfferent classes; and new router polcy to treat t packets accordngly Mbps lnk packet markng and polcng Prncple 2 provde protecton (solaton) for one class from others 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 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 77

20 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? 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? 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) 80 81

21 Polcng Mechansms Token Bucket: lmt nput to specfed Burst Sze and Average Rate. Polcng Mechansms (more) token bucket, WFQ combne to provde guaranteed upper bound on delay,.e., QoS guarantee! arrvng traffc token rate, r 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). 82 bucket sze, b per-flow rate, R WFQ D = b/r max 83 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 Dffserv Archtecture Edge router: per-flow traffc management markng r schedulng marks packets as n-profle and out-profle b. Core router: per class traffc management bufferng and schedulng based on markng at edge preference gven to n-profle packets 84 85

22 Edge-router Packet Markng profle: pre-negotated rate A, bucket sze B packet markng at edge based on per-flow profle User packets Rate A B 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 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 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 Forwardng g( (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 88 89

23 Forwardng g( (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 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 Chapter 7 outlne 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 92 Prncples for QOS Guarantees (more) Basc fact of lfe: can not support traffc demands beyond lnk capacty 1 Mbps phone 1 Mbps phone Prncple 4 R1 1.5 Mbps lnk Call Admsson: flow declares ts needs, network may block call (e.g., busy sgnal) f t cannot meet needs R2 93

24 QoS guarantee scenaro Resource reservaton call setup, sgnalng (RSVP) traffc, QoS declaraton per-element admsson control QoS-senstve schedulng (e.g., WFQ) request/ reply 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 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 Controlled load servce: "a qualty of servce closely approxmatng the QoS that same flow would receve from an unloaded network element." 96 D = b/r max 97

25 Sgnalng g n the Internet RSVP Desgn Goals 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] 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 RSVP: overvew of operaton senders, recever jon a multcast group done outsde of RSVP senders need not jon group sender-to-network 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 t t sgnalng path error reservaton error

26 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 102