Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use.

Hasonló előadás


Az előadások a következő témára: "Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use."— Előadás másolata:

1 Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!)  If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved Multmedia Networking 7-1

2 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-2

3 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-3

4 Multimedia: audio Multmedia Networking 7-4  Rögzített gyakorisággal mintavételezett analóg audio jel  telephone: 8,000 samples/sec  CD music: 44,100 samples/sec  Minden mintát kvantizálunk, azaz kerekítünk  pl., 2 8 =256 lehetséges kvantizált érték  Minden kvantizált értéket bitekkel ábrázolunk, pl., 8 bittel 256 értéket time audio signal amplitude analóg jel Az analóg érték kvantizált értéke Quantizatizálási hiba Mintavételezési ráta (N sample/sec)

5 Multimedia: audio Multmedia Networking 7-5  példa: 8,000 minta/sec, 256 quantizált érték: 64,000 bps  A vevő visszaalakítja a biteket analóg jellé:  Minőség romlás Néhány példa  CD: Mbps  MP3: 96, 128, 160 kbps  Internet telephony: 5.3 kbps and up time audio signal amplitude analóg jel Az analóg érték kvantizált értéke Quantizatizálási hiba Mintavételezési ráta (N sample/sec)

6  video: képsorozat lejátszása állandó sebességgel  pl. 24 kép/sec  Digitális kép: pixel tömb  Az egyes pixeleket bitekkel ábrázoljuk  kódolás: redundanciát használunk a képeken belül és azok között a kódolt képhez használt bitek számának csökkentésére  térbeli (képen belül)  időbeli (képről képre) Multmedia Networking 7-6 Multimedia: video ……………………...… spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N) ……………………...… frame i frame i+1 temporal coding example: instead of sending complete frame at i+1, send only differences from frame i

7 Multmedia Networking 7-7 Multimedia: video ……………………...… spatial coding example: instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N) ……………………...… frame i frame i+1 temporal coding example: instead of sending complete frame at i+1, send only differences from frame i  CBR: (constant bit rate): video encoding rate fixed  VBR: (variable bit rate): video encoding rate changes as amount of spatial, temporal coding changes  examples:  MPEG 1 (CD-ROM) 1.5 Mbps  MPEG2 (DVD) 3-6 Mbps  MPEG4 (often used in Internet, < 1 Mbps)

8 Multimedia networking: 3 alkalmazás típus Multmedia Networking 7-8  streaming, stored audio, video  streaming: a lejátszás az egész fájl letöltése előtt elindítható  stored (at server): a lejátszási sebességnél gyorsabban is adhatjuk az audio/video anyagot (feltételezi a kliens oldali pufferelést)  e.g., YouTube, Netflix, Hulu  conversational voice/video over IP  Az ember-ember közötti társalgási jelleg korlátozza az elviselhető késleltetést  e.g., Skype  streaming live audio, video  pl., sportesemény, videokonferencia

9 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-9

10 Streaming stored video: 1.video recorded (e.g., 30 frames/sec) 2. video sent Cumulative data streaming: a kliens már a video elejét játssza, amíg a szerver a video későbbi részét küldi network delay (fixed in this example) time Multmedia Networking video received, played out at client (30 frames/sec)

11 Streaming stored video: kihívások  Folytonos lejátszási kényszer: ha elkezdődött a lejátszás, annak meg kell felelni az eredeti időzítésnek  … de a hálózati késés nem állandó (jitter), ezért kliens-oldali pufferelésre van szükség a lejátszási követelmények kielégítésére  Egyéb kihívások:  felhasználói interaktivitás: pause, fast-forward, rewind, jump through video  video csomagok elveszhetnek, duplázódhatnak Multmedia Networking 7-11

12 constant bit rate video transmission Cumulative data time variable network delay client video reception constant bit rate video playout at client client playout delay buffered video  Kliens oldali pufferelés és lejátszási késleltetés: kiegyenlíti a hálózati késleltetést és annak csúszását Multmedia Networking 7-12 Streaming stored video: újratöltve

13 Kliens oldali pufferelés, lejátszás Multmedia Networking 7-13 Változó töltési sebesség, x(t) client application buffer, size B Lejátszási sebesség, e.g., CBR r buffer fill level, Q(t) video server client

14 Kliens oldali pufferelés lejátszáskor Multmedia Networking 7-14 variable fill rate, x(t) client application buffer, size B playout rate, e.g., CBR r buffer fill level, Q(t) video server client 1. Kezdetben töltjük a puffert, amíg megkezdődik a lejátszás 2. t p pillanatban kezdődik a lejátszás 3. A puffer betöltöttségi szintje aszerint változik, ahogyan az x(t) töltési sebesség változik (az r lejátszási sebesség állandó)

15 Lejátszási pufferelés: az (x) a töltési,(r) a lejátszási sebesség:  x < r: a puffer kiürülhet (a video lejátszás lefagyását okozhatja, amíg a puffer ismét feltöltődik)  x > r: a puffer nem ürül ki, feltéve, hogy a lejátszási késleltetés elég nagy, hogy elfedje x(t) ingadozását  A kezdeti késleltetés kompromisszuma: a puffer „éhezése” kevésbé valószínű nagyobb késleltetés esetén, de a felhasználó később kezdheti nézni Multmedia Networking 7-15 variable fill rate, x(t) client application buffer, size B playout rate, e.g., CBR r buffer fill level, Q(t) video server Kliens oldali pufferelés lejátszáskor

16 Streaming multimedia: UDP  A szerver a kiszolgáló számára kényelmes ütemben küldi a csomagokat  gyakran: küldési ráta = encoding ráta = állandó  A küldési ráta kritikus lehet a torlódási szint számára  rövid (2-5 seconds) lejátszási késleltetés a hálózati csúszkálás (network jitter) eltávolítására  Hiba felismerés: alkalmazási szintű  RTP [RFC 2326]: többféle multimedia payload  UDPt esetleg nem engedi át a tűzfal Multmedia Networking 7-16

17 Streaming multimedia: HTTP  multimedia fájlt HTTP GET paranccsal kapunk  Küldés a lehető legnagyobb sebességgel TCP alatt  A küldési sebesség fluktuál a TCP torlódásvezérlése és az újraküldések miatt (sorrend helyes szállítás)  Nagyobb lejátszási késleltetés: sima TCP szállítási ráta  HTTP/TCP könnyebben átmegy a tűzfalakon Multmedia Networking 7-17 variable rate, x(t) TCP send buffer video file TCP receive buffer application playout buffer server client

18 Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  szerver:  A video különböző felbontású változatokban tárolódik (multiple chunks)  A tárolt változatok különböző rátával továbbítódnak  manifest file: a változatok URL-je különböző  kliens:  Periodikusan méri a szerver-kliens közötti sávszélességet  A manifest fájl alapján kéri valamelyik változatot Az adott sávszélesség esetére a legnagyobb elérhető változatot választja Különböző időpontokban különböző kódolási rátákat használhat (az elérhető sávszélességtől függően) Multmedia Networking 7-18

19 Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  “intelligence” at client: a kliens mondja meg  mikor kér másik változatot (így puffer éhezés vagy túlcsordulás nem fordulhat elő)  Milyen kódolási rátát kér (magasabb minőséget amikor nagyobb a sávszélesség)  hol kéri a változatot (a klienshez „közelebbi” vagy nagyobb sebességű változatot is kérhet) Multmedia Networking 7-19

20 Content distribution networks  kihívás: hogyan terítsük (a pár millió videóból kiválasztott) tartalmat pár ezer egyidejű felhasználó számára?  option 1: egy nagy “mega-server”  single point of failure  point of network congestion  long path to distant clients  multiple copies of video sent over outgoing link ….egyszerűen: ez a megoldás nem skálázható Multmedia Networking 7-20

21 Content distribution networks  kihívás: hogyan terítsük (a pár millió videóból kiválasztott) tartalmat pár ezer egyidejű felhasználó számára?  option 2: tároljunk (és szolgáltassunk) másolatokat földrajzilag elosztott helyeken (CDN)  enter deep: tegyük a CDN szervereket mélyen a hozzáférési hálózatokba A felhasználókhoz közel used by Akamai, 1700 locations  bring home: kisebb számú (10’s) nagyobb klasztert hozzáférési hálózatokhoz közel, de nem benne used by Limelight Multmedia Networking 7-21

22 CDN: “simple” content access scenario Multmedia Networking 7-22 Bob (client) requests video /6Y7B23V  video stored in CDN at 23V netcinema.com KingCDN.com 1 1. Bob gets URL for for video from netcinema.com web page 2 2. resolve via Bob’s local DNS netcinema’s authorative DNS 3 3. netcinema’s DNS returns URL 23V 4 4&5. Resolve via KingCDN’s authoritative DNS, which returns IP address of KIingCDN server with video 5 6. request video from KINGCDN server, streamed via HTTP KingCDN authoritative DNS

23 CDN cluster selection strategy  kihívás: hogyan válasszon a CDN DNS “jó” CDN node-ot a kliens számára a folyam letöltésére  Válasszon a klienshez földrajzilag közel levő CDN node-ot  Válassza a legkisebb késleltetésű (vagy legkisebb ugrásszámú) CDN node-ot (CDN node-ok periodikusan pingelik az ISP-ket, az eredményt elküldik a CDN DNS-nek)  IP anycast  alternatíva: döntsön a kliens – a kliens kap egy listát a CDN szerverekről  A kliens „ping”-et, a „legjobbat” választja  Netflix approach Multmedia Networking 7-23

24 Case study: Netflix  30% downstream US traffic in 2011  owns very little infrastructure, uses 3 rd party services:  own registration, payment servers  Amazon (3 rd party) cloud services: Netflix uploads studio master to Amazon cloud create multiple version of movie (different endodings) in cloud upload versions from cloud to CDNs Cloud hosts Netflix web pages for user browsing  three 3 rd party CDNs host/stream Netflix content: Akamai, Limelight, Level-3 Multmedia Networking 7-24

25 Case study: Netflix Multmedia Networking Bob manages Netflix account Netflix registration, accounting servers Amazon cloud Akamai CDN Limelight CDN Level-3 CDN 2 2. Bob browses Netflix video 3 3. Manifest file returned for requested video 4. DASH streaming upload copies of multiple versions of video to CDNs

26 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-26

27 Voice-over-IP (VoIP) Multmedia Networking 7-27  VoIP végponti késleltetés elvárása: meg kell őrizni a „társalgási” jelleget  A nagy késleltetések észrevehetők, rontják az interaktivitást  < 150 msec: jó  > 400 msec rossz  Tartalmazza az alkalmazás szintű (csomag készítés, lejátszás), hálózati késleltetést is  session initialization: hogyan tegye közzé a hívó az IP címet, port számot, encoding algoritmust?  value-added services: call forwarding, screening, recording  emergency services: 911

28 VoIP jellemzői  speaker ’ s audio: váltakozó beszéd és szünet időszakok.  64 kbps beszéd időszakokban  Csomag előállítás csak a beszéd időszakokban  20 msec időszakok 8 Kbytes/sec esetén: 160 bájt adat  Minden csomag (chunk) alkalmazási rétegbeli fejzetet kap  chunk+header, UDP vagy TCP szegmensbe csomagolva  20 msec időközönként küld az alkalmazás csomagot a socket-nek beszéd közben Multmedia Networking 7-28

29 VoIP: csomag vesztés, késés  network loss: az IP datagram hálózati torlódás miatt elvész (router buffer overflow)  delay loss: az IP datagram a lejátszáshoz túl későn érkezik meg  delays: processing, queueing in network; end-system (sender, receiver) delays  typical maximum tolerable delay: 400 ms  loss tolerance: a kódolás típusától is függ, 1% és10% csomagvesztés még elviselhető Multmedia Networking 7-29

30 constant bit rate transmission Cumulative data time variable network delay (jitter) client reception constant bit rate playout at client client playout delay buffered data Delay jitter  Végponti késleltetés két egymást követő csomag esetén: a különbség lehet nagyobb, mint 20 msec (a küldési időkülönbség) Multmedia Networking 7-30

31 VoIP: rögzített lejátszási késleltetés  A vevő megpróbálja az előállítás után pontosan q msecs múlva lejátszani a hang csomagot.  A csomag időbélyege t: lejátszás t+q  Ha a csomag t+q után érkezik: a lejátszáshoz már késő, az adat „elveszett”  kompromisszum q megválasztásában:  nagy q: kisebb csomag vesztés  kis q: jobb interaktivitás Multmedia Networking 7-31

32  a küldő 20 msec időközönként állít elő egy csomagot.  az első csomagot r időnél kapjuk meg  az első lejátszás p időnél kezdődik  a második lejátszás p’ időnél kezdődik Multmedia Networking 5-32 VoIP: rögzített lejátszási késleltetés

33 Adaptive playout delay (1)  cél: kis lejátszási késleltetés, kevés csomag vesztése  módszer: adaptív lejátszási késleltetés adjusztálása:  Hálózati késleltetés megbecslése, a lejátszási késleltetés adjusztálása a beszéd időszakokra  A csend időszakokat összenyomjuk vagy megtoldjuk  A beszéd időszakban 20 msec-onként játsszuk le a csomagokat  A csomag késleltetés adaptív becslése: ( EWMA - exponentially weighted moving average, recall TCP RTT estimate): Multmedia Networking 7-33 d i = (1  )d i-1 +  (r i – t i ) delay estimate after ith packet small constant, e.g. 0.1 time received - time sent (timestamp) measured delay of ith packet

34  hasznos megbecsülni a késleltetés átlagos eltérését, v i :  a d i, v i értékeket minden kapott csomagra kiszámítják, de csak a beszéd periódus elején használják  a beszéd periódusban az első csomag lejátszási ideje: a többi csomagot ehhez képest periodikusan játsszák le Multmedia Networking 5-34 v i = (1  )v i-1 +  |r i – t i – d i | playout-time i = t i + d i + Kv i Adaptive playout delay (2)

35 Q: Hogyan lehet megállapítani, melyik a beszéd periódus (talk spurt) első csomagja?  Ha nincs veszteség, a vevő az időbélyegből dolgozhat  Az időbélyegek különbsége > 20 msec -->talk spurt begins.  Ha vesztés előfordulhat, a vevőnek az időbélyegre és a sorszámra egyaránt kell figyelnie  Az időbélyegek különbsége > 20 msec és a sorszámokban nincs szakadás --> talk spurt begins. Multmedia Networking 7-35 Adaptive playout delay (3)

36 VoiP: Visszaállítás csomagvesztés után (1) Challenge: recover from packet loss given small tolerable delay between original transmission and playout  each ACK/NAK takes ~ one RTT  alternative: Forward Error Correction (FEC)  Küldjünk a hiba javításához elegendő bitet, hogy újraküldés nélkül lehessen javítani simple FEC  Minden n chun-hoz létrehozunk egy renundáns chunk-ot, az n eredeti chunk XOR kapcsolatával  n+1 üzenetdarabot küldünk (a sávszélesség igény +1/n)  Ha csak egy darabka veszett el az n+1-ből, az n darabot visszaállíthatjuk újraküldés nélkül Multmedia Networking 7-36

37 Egy másik FEC megoldás:  “piggyback lower quality stream”  Alacsonyabb felbontású audio stream a küldött redundáns információ  pl., névleges PCM at 64 kbps, redundáns GSM 13 kbps  Nem-folytonos veszteség: a vevő elfedi a veszteséget  Általánosítás: küldhetünk (n-1)-edik és (n-2)edik alacsony bitrátájú csomagot (chunk) Multmedia Networking 7-37 VoiP: Visszaállítás csomagvesztés után (2)

38 interleaving to conceal loss:  Az audia chunk-ot kisebb egységekre osztjuk, pl. négy 5 msec-es egységre a 20 msec-es chunk-ot  A csomag a különböző chunk- okból kisebb egységeket tartalmaz  Ha egy chunk elvész, az eredeti chunk nagyobb része még mindig megvan  Nincs redundáns adatküldés, de a lejátszási késleltetés megnő Multmedia Networking 7-38 VoiP: recovery from packet loss (3)

39 Application Layer2-39 supernode overlay network Voice-over-IP: Skype  Céges tulajdonú alkalmazási rétegbeli protokoll (következtetések „reverse engineering” útján)  encrypted msgs  P2P components: Skype clients (SC)  clients: skype peers connect directly to each other for VoIP call  super nodes (SN): skype peers with special functions  overlay network: among SNs to locate SCs  login server Skype login server supernode (SN )

40 Application Layer2-40 P2P voice-over-IP: skype skype kliens működése: 1. Bejelentkezés a hálózatba, egy SN (IP cím mentéssel) TCP használat 2. logs-in (usename, password) a központi kiszolgálóba 3. A címzett IP címének megszerzése (SN és SN overlay; vagy a többi csomópont) 4. Közvetlen hívás kezdeményezés Skype login server

41 Application Layer2-41  probléma: Alice és Bob “NAT” mögött van  A NAT nem engedi külső gazdának, hogy belső géphez kapcsolatot kezdjen  Egy belső gép azonban kezdhet kapcsolatot egy küldőhöz  Megoldás átjátszóval: Alice, Bob fenntart egy nyitott külső kapcsolatot a saját SN-hez  Alice jelzi a SN-nak kapcsoBobhoz  Alice SN-je kapcsolódik Bob SN- jéhez  Bob kapcsolódik SN-hez azon a már megnyitott kapcsolaton át, amit Bob korábban megnyitott saját SN-jéhez Skype: a csomópontok átjátszóként

42 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications: RTP, SIP 7.5 network support for multimedia Multmedia Networking 7-42

43 Real-Time Protocol (RTP)  RTP határozza meg az audió és videó jeleket szállító csomagok formátumát  RFC 3550  RTP lehetőségei  Sállított információ típus azonosítása  Csomag sorszámozás  időbélyegzés  RTP a végfelhasználói rendszereken fut  Az RTP csomagokat UDP kapszulákba csomagolják  együttműködés: ha két VoIP alkalmazás RTP-t futtat, együtt tudnak működni Multmedia Networking 7-43

44 Az RTP az UDP fölött fut Az RTP könyvtárak lényegében szállítási rétegbeli Interfészt jelentenek, amivel kiterjesztik az UDP-t port numbers, IP addresses szállított adattípus azonosítás csomag sorszámozás időbélyegzés Multmedia Networking 5-44

45 RTP példa példa: 64 kbps PCM-kódolt hang RTP-vel  Az alkalmazás csomagokba gyűjti a beszédet, pl., 20 msec = 160 bájt egy csomagban  Az audio chunk + RTP fejzet alkotja az RTP csomagot, ami egy UDP szegmensbe van csomagolva  Az RTP fejzet minden egyes audio csomagban jelzi az audio kódolás típusát  A küldő változtathatja a kódolás típusát a konferencia során  Az RTP fejzet tartalmaz sorszámot és időbélyeget is Multmedia Networking 7-45

46 RTP és QoS  Az RTP semmi mechanizmust sem ad az időbeli szállításra vagy egyéb QoS garanciaára  Az RTP beágyazás csak a végrendszerekben észrevehető (a közbülső routereken nem)  A routerek „best-effort” jellegű szolgáltatást nyújtanak, és semmit sem tesznek annak érdekében, hogy az RTP csomagok időben másként érkezzenek a céljukhoz Multmedia Networking 7-46

47 RTP header payload type (7 bits): az éppen használt kódolási típus. Ebben küld értesítést a küldő a fogadónak, ha kódolást vált Payload type 0: PCM mu-law, 64 kbps Payload type 3: GSM, 13 kbps Payload type 7: LPC, 2.4 kbps Payload type 26: Motion JPEG Payload type 31: H.261 Payload type 33: MPEG2 video sequence # (16 bits): egyesével növekszik minden RTP csomag elküldése után  Észreveszi a csomagvesztést, helyreállítja a sorrendet Multmedia Networking 5-47 payload type sequence number type time stamp Synchronization Source ID Miscellaneous fields

48  timestamp field (32 bits long): az RTP csomag első bájtjának mintavételezési pillanata  Audio esetén az időbélyeg órája mintavételezési periódus után eggyel nő (azaz, 125 usecs időközönként, 8 KHz-es mintavételezési frekvenciánál)  Ha az alkalmazás beszéd peiródusonként160 kódolt mintát állít elő, az időbélyeg minden egyes RTP csomag esetén 160-nal nő, amikor a forrás aktív. Az időbélyegző óra állandó sebességgel jár, amikor a forrás nem aktív.  SSRC field (32 bits long): az RTP stream azonosítója. Egy RTP session minden forrásának saját SSRC azonosítója van Multmedia Networking 7-48 RTP header payload type sequence number type time stamp Synchronization Source ID Miscellaneous fields

49 RTSP/RTP programozás feladatai  build a server that encapsulates stored video frames into RTP packets  grab video frame, add RTP headers, create UDP segments, send segments to UDP socket  include seq numbers and time stamps  client RTP provided for you  also write client side of RTSP  issue play/pause commands  server RTSP provided for you Multmedia Networking 7-49

50 Real-Time Control Protocol (RTCP)  Működése az RTP-hez kötődik  Az RTP session résztvevői periodikusan RTCP vezérlő üzeneteket küldenek egymásnak  Az egyes RTCP csomagok küldő és/vagy fogadó jelentéseket tartalmaznak  A jelentések az alkalmazás számára hasznos statisztikát tartalmaznak: # packets sent, # packets lost, interarrival jitter  A visszajelzés a működést vezérli  A küldő módosíthatja átvitelét a visszacsatolás alapján Multmedia Networking 7-50

51 RTCP: multiple multicast senders  Az egyes RTP viszonylatokban egyetlen multicast címet használnak; a viszonyhoz tartozó RTP /RTCP csomagok multicast címeket használnak  Az RTP, RTCP csomagokat egymástól port számuk különbözteti meg  A forgalom limitálására a részvevők a konferencia részvevők számának növekedésével csökkentik RTCP forgalmukat Multmedia Networking 5-51 RTCP RTP RTCP sender receivers

52 RTCP: csomag típusok receiver report packets:  Az elveszett csomagok aránya, az utolsó sorszám, a csomagok érkezési idejének csúszkálása (jitter) sender report packets:  SSRC of RTP stream, folyó idő, a küldött csomagok száma, a küldött bájtok száma source description packets:  address of sender, sender's name, SSRC of associated RTP stream  provide mapping between the SSRC and the user/host name Multmedia Networking 7-52

53 RTCP: stream synchronization  RTCP szinkronizálni képes különböző, azonos RTP viszonyú RTP folyamokat  e.g., videoconferencing app: each sender generates one RTP stream for video, one for audio.  timestamps in RTP packets tied to the video, audio sampling clocks  not tied to wall-clock time  each RTCP sender-report packet contains (for most recently generated packet in associated RTP stream):  timestamp of RTP packet  wall-clock time for when packet was created  receivers uses association to synchronize playout of audio, video Multmedia Networking 7-53

54 RTCP: bandwidth scaling RTCP attempts to limit its traffic to 5% of session bandwidth example : one sender, sending video at 2 Mbps  RTCP attempts to limit RTCP traffic to 100 Kbps  RTCP gives 75% of rate to receivers; remaining 25% to sender  75 kbps is equally shared among receivers:  with R receivers, each receiver gets to send RTCP traffic at 75/R kbps.  sender gets to send RTCP traffic at 25 kbps.  participant determines RTCP packet transmission period by calculating avg RTCP packet size (across entire session) and dividing by allocated rate Multmedia Networking 7-54

55 SIP: Session Initiation Protocol [RFC 3261] long-term vision:  all telephone calls, video conference calls take place over Internet  people identified by names or addresses, rather than by phone numbers  can reach callee (if callee so desires), no matter where callee roams, no matter what IP device callee is currently using Multmedia Networking 7-55

56 SIP services  SIP provides mechanisms for call setup:  for caller to let callee know she wants to establish a call  so caller, callee can agree on media type, encoding  to end call  determine current IP address of callee:  maps mnemonic identifier to current IP address  call management:  add new media streams during call  change encoding during call  invite others  transfer, hold calls Multmedia Networking 7-56

57 Example: setting up call to known IP address  Alice’s SIP invite message indicates her port number, IP address, encoding she prefers to receive (PCM  law)  Bob’s 200 OK message indicates his port number, IP address, preferred encoding (GSM)  SIP messages can be sent over TCP or UDP; here sent over RTP/UDP  default SIP port number is 5060 Multmedia Networking 5-57

58 Setting up a call (more)  codec negotiation:  suppose Bob doesn’t have PCM  law encoder  Bob will instead reply with 606 Not Acceptable Reply, listing his encoders. Alice can then send new INVITE message, advertising different encoder  rejecting a call  Bob can reject with replies “ busy, ” “ gone, ” “ payment required, ” “ forbidden ”  media can be sent over RTP or some other protocol Multmedia Networking 7-58

59 Example of SIP message INVITE SIP/2.0 Via: SIP/2.0/UDP From: To: Call-ID: Content-Type: application/sdp Content-Length: 885 c=IN IP m=audio RTP/AVP 0 Notes:  HTTP message syntax  sdp = session description protocol  Call-ID is unique for every call  Here we don’t know Bob’s IP address  intermediate SIP servers needed  Alice sends, receives SIP messages using SIP default port 506  Alice specifies in header that SIP client sends, receives SIP messages over UDP Multmedia Networking 7-59

60 Name translation, user location  caller wants to call callee, but only has callee ’ s name or address.  need to get IP address of callee ’ s current host:  user moves around  DHCP protocol  user has different IP devices (PC, smartphone, car device)  result can be based on:  time of day (work, home)  caller (don ’ t want boss to call you at home)  status of callee (calls sent to voic when callee is already talking to someone) Multmedia Networking 7-60

61 SIP registrar REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: To: Expires: 3600  one function of SIP server: registrar  when Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server register message: Multmedia Networking 7-61

62 SIP proxy  another function of SIP server: proxy  Alice sends invite message to her proxy server  contains address  proxy responsible for routing SIP messages to callee, possibly through multiple proxies  Bob sends response back through same set of SIP proxies  proxy returns Bob’s SIP response message to Alice  contains Bob ’ s IP address  SIP proxy analogous to local DNS server plus TCP setup Multmedia Networking 7-62

63 SIP example: calls Multmedia Networking Jim sends INVITE message to UMass SIP proxy. 2. UMass proxy forwards request to Poly registrar server 2 3. Poly server returns redirect response, indicating that it should try 3 5. eurecom registrar forwards INVITE to , which is running keith’s SIP client Umass proxy forwards request to Eurecom registrar server SIP response returned to Jim 9 9. Data flows between clients UMass SIP proxy Poly SIP registrar Eurecom SIP registrar

64 Comparison with H.323  H.323: another signaling protocol for real-time, interactive multimedia  H.323: complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport, codecs  SIP: single component. Works with RTP, but does not mandate it. Can be combined with other protocols, services  H.323 comes from the ITU (telephony)  SIP comes from IETF: borrows much of its concepts from HTTP  SIP has Web flavor; H.323 has telephony flavor  SIP uses KISS principle: Keep It Simple Stupid Multmedia Networking 7-64

65 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-65

66 Network support for multimedia Multmedia Networking 7-66

67 Dimensioning best effort networks  approach: deploy enough link capacity so that congestion doesn’t occur, multimedia traffic flows without delay or loss  low complexity of network mechanisms (use current “best effort” network)  high bandwidth costs  challenges:  network dimensioning: how much bandwidth is “enough?”  estimating network traffic demand: needed to determine how much bandwidth is “enough” (for that much traffic) Multmedia Networking 7-67

68 Providing multiple classes of service  thus far: making the best of best effort service  one-size fits all service model  alternative: multiple classes of service  partition traffic into classes  network treats different classes of traffic differently (analogy: VIP service versus regular service) 0111  granularity: differential service among multiple classes, not among individual connections  history: ToS bits Multmedia Networking 7-68

69 Multiple classes of service: scenario R1 R2 H1 H2 H3 H4 1.5 Mbps link R1 output interface queue Multmedia Networking 7-69

70 Scenario 1: mixed HTTP and VoIP  example: 1Mbps VoIP, HTTP share 1.5 Mbps link.  HTTP bursts can congest router, cause audio loss  want to give priority to audio over HTTP packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principle 1 R1 R2 Multmedia Networking 7-70

71 Principles for QOS guarantees (more)  what if applications misbehave (VoIP sends higher than declared rate)  policing: force source adherence to bandwidth allocations  marking, policing at network edge provide protection (isolation) for one class from others Principle 2 R1 R2 1.5 Mbps link 1 Mbps phone packet marking and policing Multmedia Networking 7-71

72  allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn ’ t use its allocation while providing isolation, it is desirable to use resources as efficiently as possible Principle 3 R1 R2 1.5 Mbps link 1 Mbps phone 1 Mbps logical link 0.5 Mbps logical link Multmedia Networking 7-72 Principles for QOS guarantees (more)

73 Scheduling and policing mechanisms  scheduling: choose next packet to send on link  FIFO (first in first out) scheduling: send in order of arrival to queue  real-world example?  discard policy: if packet arrives to full queue: who to discard? tail drop: drop arriving packet priority: drop/remove on priority basis random: drop/remove randomly Multmedia Networking 7-73 queue (waiting area) packet arrivals packet departures link (server)

74 Scheduling policies: priority priority scheduling: send highest priority queued packet  multiple classes, with different priorities  class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.  real world example? Multmedia Networking 7-74 high priority queue (waiting area) low priority queue (waiting area) arrivals classify departures link (server) arrivals departures packet in service

75 Scheduling policies: still more Round Robin (RR) scheduling:  multiple classes  cyclically scan class queues, sending one complete packet from each class (if available)  real world example? Multmedia Networking arrivals departures packet in service

76 Weighted Fair Queuing (WFQ):  generalized Round Robin  each class gets weighted amount of service in each cycle  real-world example? Multmedia Networking 7-76 Scheduling policies: still more

77 Policing mechanisms goal: limit traffic to not exceed declared parameters Three common-used criteria:  (long term) average rate: how many pkts can be sent per unit time (in the long run)  crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average!  peak rate: e.g., 6000 pkts per min (ppm) avg.; 1500 ppm peak rate  (max.) burst size: max number of pkts sent consecutively (with no intervening idle) Multmedia Networking 7-77

78 Policing mechanisms: implementation token bucket: limit input to specified burst size and average rate  bucket can hold b tokens  tokens generated at rate r token/sec unless bucket full  over interval of length t: number of packets admitted less than or equal to (r t + b) Multmedia Networking 7-78

79 Policing and QoS guarantees  token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic Multmedia Networking 7-79 arriving traffic

80 Differentiated services  want “ qualitative ” service classes  “ behaves like a wire ”  relative service distinction: Platinum, Gold, Silver  scalability: simple functions in network core, relatively complex functions at edge routers (or hosts)  signaling, maintaining per-flow router state difficult with large number of flows  don ’ t define define service classes, provide functional components to build service classes Multmedia Networking 7-80

81 edge router:  per-flow traffic management  marks packets as in-profile and out-profile core router:  per class traffic management  buffering and scheduling based on marking at edge  preference given to in-profile packets over out-of-profile packets Diffserv architecture Multmedia Networking 7-81 r b marking scheduling...

82 Edge-router packet marking  class-based marking: packets of different classes marked differently  intra-class marking: conforming portion of flow marked differently than non-conforming one  profile: pre-negotiated rate r, bucket size b  packet marking at edge based on per-flow profile possible use of marking : user packets rate r b Multmedia Networking 5-82

83 Diffserv packet marking: details  packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6  6 bits used for Differentiated Service Code Point (DSCP)  determine PHB that the packet will receive  2 bits currently unused Multmedia Networking 7-83 DSCP unused

84 Classification, conditioning may be desirable to limit traffic injection rate of some class:  user declares traffic profile (e.g., rate, burst size)  traffic metered, shaped if non-conforming Multmedia Networking 7-84

85 Forwarding Per-hop Behavior (PHB)  PHB result in a different observable (measurable) forwarding performance behavior  PHB does not specify what mechanisms to use to ensure required PHB performance behavior  examples:  class A gets x% of outgoing link bandwidth over time intervals of a specified length  class A packets leave first before packets from class B Multmedia Networking 7-85

86 Forwarding PHB PHBs proposed:  expedited forwarding: pkt departure rate of a class equals or exceeds specified rate  logical link with a minimum guaranteed rate  assured forwarding: 4 classes of traffic  each guaranteed minimum amount of bandwidth  each with three drop preference partitions Multmedia Networking 7-86

87 Per-connection QOS guarantees  basic fact of life: can not support traffic demands beyond link capacity call admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs Principle 4 R1 R2 1.5 Mbps link 1 Mbps phone 1 Mbps phone Multmedia Networking 7-87

88 QoS guarantee scenario  resource reservation  call setup, signaling (RSVP)  traffic, QoS declaration  per-element admission control  QoS-sensitive scheduling (e.g., WFQ) request/ reply Multmedia Networking 7-88

89 Multimedia networking: outline 7.1 multimedia networking applications 7.2 streaming stored video 7.3 voice-over-IP 7.4 protocols for real-time conversational applications 7.5 network support for multimedia Multmedia Networking 7-89


Letölteni ppt "Chapter 7 Multimedia Networking Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use."

Hasonló előadás


Google Hirdetések