Transcript Chapter_7_V6.0_HU

Chapter 7
Multimedia Networking
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.
Computer
Networking: A Top
Down Approach
6th edition
Jim Kurose, Keith Ross
Addison-Wesley
March 2012
Thanks and enjoy! JFK/KWR
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
Multmedia Networking
7-1
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
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
Multimedia: audio

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., 28=256 lehetséges
kvantizált érték
 Minden kvantizált értéket
bitekkel ábrázolunk, pl., 8
bittel 256 értéket
Quantizatizálási
hiba
Az analóg
érték
kvantizált
értéke
audio signal amplitude

analóg
jel
time
Mintavételezési ráta
(N sample/sec)
Multmedia Networking
7-4
Multimedia: audio

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: 1.411 Mbps
MP3: 96, 128, 160 kbps
Internet telephony: 5.3 kbps
and up
Quantizatizálási
hiba
Az analóg
érték
kvantizált
értéke
audio signal amplitude

analóg
jel
time
Mintavételezési ráta
(N sample/sec)
Multmedia Networking
7-5
Multimedia: video



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)
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
temporal coding example:
instead of sending
complete frame at i+1,
send only differences from
frame i
frame i+1
Multmedia Networking
7-6
Multimedia: video



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)
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
temporal coding example:
instead of sending
complete frame at i+1,
send only differences from
frame i
frame i+1
Multmedia Networking
7-7
Multimedia networking: 3 alkalmazás típus



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
Multmedia Networking
7-8
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
Streaming stored video:
1. video
recorded
(e.g., 30
frames/sec)
2. video
sent
network delay
(fixed in this
example)
3. video received,
played out at client
(30 frames/sec) time
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
Multmedia Networking 7-10
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
Streaming stored video: újratöltve
client video
reception
variable
network
delay
constant bit
rate video
playout at client
buffered
video
constant bit
rate video
transmission
time
client playout
delay

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
Kliens oldali pufferelés, lejátszás
buffer fill level,
Q(t)
Változó töltési
sebesség, x(t)
video server
Lejátszási sebesség,
e.g., CBR r
client application
buffer, size B
client
Multmedia Networking 7-13
Kliens oldali pufferelés lejátszáskor
buffer fill level,
Q(t)
playout rate,
e.g., CBR r
variable fill
rate, x(t)
video server
client application
buffer, size B
client
1. Kezdetben töltjük a puffert, amíg megkezdődik
a lejátszás
2. tp 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ó)
Multmedia Networking 7-14
Kliens oldali pufferelés lejátszáskor
buffer fill level,
Q(t)
playout rate,
e.g., CBR r
variable fill
rate, x(t)
video server
client application
buffer, size B
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
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
Streaming multimedia: HTTP


multimedia fájlt HTTP GET paranccsal kapunk
Küldés a lehető legnagyobb sebességgel TCP alatt
variable
rate, x(t)
video
file
TCP send
buffer
server



TCP receive
buffer
application
playout buffer
client
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
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
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
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
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
CDN: “simple” content access scenario
Bob (client) requests video http://netcinema.com/6Y7B23V
 video stored in CDN at http://KingCDN.com/NetC6y&B23V
1. Bob gets URL for for video
http://netcinema.com/6Y7B23V
2. resolve http://netcinema.com/6Y7B23V
from netcinema.com
2 via Bob’s local DNS
web page
1
6. request video from 5
4&5. Resolve
KINGCDN server,
http://KingCDN.com/NetC6y&B23
streamed via HTTP
via KingCDN’s authoritative DNS,
3.
netcinema’s
DNS
returns
URL
netcinema.com
4 which returns IP address of KIingCDN
http://KingCDN.com/NetC6y&B23V
server with video
3
netcinema’s
authorative DNS
KingCDN.com
KingCDN
authoritative DNS
Multmedia Networking 7-22
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
Case study: Netflix


30% downstream US traffic in 2011
owns very little infrastructure, uses 3rd party
services:
 own registration, payment servers
 Amazon (3rd 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 3rd party CDNs host/stream Netflix
content: Akamai, Limelight, Level-3
Multmedia Networking 7-24
Case study: Netflix
Amazon cloud
Netflix registration,
accounting servers
2. Bob browses
Netflix video 2
upload copies of
multiple versions of
video to CDNs
3. Manifest file
returned for
requested video
Akamai CDN
Limelight CDN
3
1
1. Bob manages
Netflix account
4. DASH
streaming
Level-3 CDN
Multmedia Networking 7-25
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
Voice-over-IP (VoIP)

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
Multmedia Networking 7-27
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
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
Delay jitter
variable
network
delay
(jitter)
client playout
delay

client
reception
constant bit
rate playout
at client
buffered
data
constant bit
rate
transmission
time
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
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
VoIP: rögzített lejátszási késleltetés




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
packets
loss
packets
generated
packets
received
playout schedule
p' - r
playout schedule
p-r
time
r
p
p'
Multmedia Networking 5-32
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): di = (1-a)di-1 + a (ri – ti)
delay estimate
after ith packet
small constant,
e.g. 0.1
time received - time sent
(timestamp)
measured delay of ith packet
Multmedia Networking 7-33
Adaptive playout delay (2)

hasznos megbecsülni a késleltetés átlagos eltérését, vi :
vi = (1-b)vi-1 + b |ri – ti – di|
a di, vi é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:
playout-timei = ti + di + Kvi
a többi csomagot ehhez képest periodikusan
játsszák le

Multmedia Networking 5-34
Adaptive playout delay (3)
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
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
VoiP: Visszaállítás csomagvesztés után (2)
Egy másik FEC megoldás:
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
 “piggyback
 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: recovery from packet loss (3)
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ő chunkokbó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
Voice-over-IP: Skype


Céges tulajdonú alkalmazási
rétegbeli protokoll
(következtetések „reverse
engineering” útján)
Skype
 encrypted msgs
login server
P2P components:
 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 clients (SC)
supernode (SN)
supernode
overlay
network
Application Layer 2-39
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
Application Layer 2-40
Skype: a csomópontok átjátszóként

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 SNjéhez
 Bob kapcsolódik SN-hez azon a
már megnyitott kapcsolaton át,
amit Bob korábban megnyitott
saját SN-jéhez
Application Layer 2-41
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
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
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
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
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
RTP header
payload
type
sequence
number
type
time stamp
Synchronization
Source ID
Miscellaneous
fields
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
RTP header
payload
type


sequence
number
type
time stamp
Synchronization
Source ID
Miscellaneous
fields
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
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
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
RTCP: multiple multicast senders
sender
RTP
RTCP
RTCP
RTCP
receivers
 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: 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:


e-mail 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
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
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
SIP: Session Initiation Protocol [RFC 3261]
long-term vision:
 all telephone calls, video conference calls take
place over Internet
 people identified by names or e-mail 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
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
Example: setting up call to known IP address
Bob
Alice
 Alice’s
167.180.112.24
INVITE bob
@193.64.2
10.89
c=IN IP4 16
7.180.112.2
4
m=audio 38
060 RTP/A
VP 0
193.64.210.89
port 5060
port 5060
Bob's
terminal rings
200 OK
.210.89
c=IN IP4 193.64
RTP/AVP 3
3
m=audio 4875
ACK
SIP invite message
indicates her port number, IP
address, encoding she prefers
to receive (PCM mlaw)
Bob’s 200 OK message
indicates his port number, IP
address, preferred encoding
(GSM)

port 5060
m Law audio
SIP messages can be sent
over TCP or UDP; here sent
over RTP/UDP

port 38060
GSM
port 48753
default SIP port number is
5060

time
time
Multmedia Networking 5-57
Setting up a call (more)

codec negotiation:
 suppose Bob doesn’t
have PCM mlaw 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
Example of SIP message
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0
Here we don’t know
Bob’s IP address
 intermediate SIP
servers needed
 Alice sends, receives
SIP messages using SIP
default port 506

 Alice
Notes:
 HTTP message syntax
 sdp = session description protocol
 Call-ID is unique for every call
specifies in
header that SIP client
sends, receives SIP
messages over UDP
Multmedia Networking 7-59
Name translation, user location



caller wants to call
callee, but only has
callee’s name or e-mail
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 voicemail when callee
is already talking to
someone)
Multmedia Networking 7-60
SIP registrar
one function of SIP server: registrar
 when Bob starts SIP client, client sends SIP REGISTER
message to Bob’s registrar server

register message:
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
From: sip:[email protected]
To: sip:[email protected]
Expires: 3600
Multmedia Networking 7-61
SIP proxy


another function of SIP server: proxy
Alice sends invite message to her proxy server
 contains address sip:[email protected]
 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
SIP example: [email protected] calls [email protected]
2. UMass proxy forwards request
to Poly registrar server
2
3
UMass
SIP proxy
1. Jim sends INVITE
8
message to UMass
SIP proxy.
1
128.119.40.186
Poly SIP
registrar
3. Poly server returns redirect response,
indicating that it should try [email protected]
4. Umass proxy forwards request
to Eurecom registrar server
4
7
6-8. SIP response returned to Jim
9
9. Data flows between clients
Eurecom SIP
registrar
5. eurecom
5 registrar
6
forwards INVITE
to 197.87.54.21,
which is running
keith’s SIP
client
197.87.54.21
Multmedia Networking 7-63
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
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
Network support for multimedia
Multmedia Networking 7-66
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
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)


granularity: differential
service among multiple
classes, not among
individual connections
history: ToS bits
0111
Multmedia Networking 7-68
Multiple classes of service: scenario
H1
H2
H3
R1
R1 output
interface
queue
R2
1.5 Mbps link
H4
Multmedia Networking 7-69
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
R1
R2
Principle 1
packet marking needed for router to distinguish
between different classes; and new router policy to
treat packets accordingly
Multmedia Networking 7-70
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
1 Mbps
phone
R1
R2
1.5 Mbps link
packet marking and policing
Principle 2
provide protection (isolation) for one class from others
Multmedia Networking 7-71
Principles for QOS guarantees (more)

allocating fixed (non-sharable) bandwidth to flow:
inefficient use of bandwidth if flows doesn’t use its
allocation
1 Mbps
phone
1 Mbps logical link
R1
R2
1.5 Mbps link
0.5 Mbps logical link
Principle 3
while providing isolation, it is desirable to use
resources as efficiently as possible
Multmedia Networking 7-72
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
packet
arrivals
queue
link
(waiting area) (server)
packet
departures
Multmedia Networking 7-73
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?
high priority queue
(waiting area)
arrivals
departures
classify
low priority queue
(waiting area)
link
(server)
2
5
4
1 3
arrivals
packet
in
service
1
4
2
3
5
departures
1
3
2
4
5
Multmedia Networking 7-74
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?
2
5
4
1 3
arrivals
packet
in
service
1
2
3
4
5
departures
1
3
3
4
5
Multmedia Networking 7-75
Scheduling policies: still more
Weighted Fair Queuing (WFQ):
 generalized Round Robin
 each class gets weighted amount of service in
each cycle
 real-world example?
Multmedia Networking 7-76
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
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
Policing and QoS guarantees

token bucket, WFQ combine to provide
guaranteed upper bound on delay, i.e., QoS
guarantee!
arriving
token rate, r
traffic
bucket size, b
per-flow
rate, R
WFQ
arriving
D = b/R
max
traffic
Multmedia Networking 7-79
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
Diffserv architecture
edge router:

per-flow traffic management

marks packets as in-profile and
out-profile
marking
r
b
scheduling
..
.
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
Multmedia Networking 7-81
Edge-router packet marking
profile: pre-negotiated rate r, bucket size b
 packet marking at edge based on per-flow profile

rate r
b
user packets
possible use of marking:


class-based marking: packets of different classes marked
differently
intra-class marking: conforming portion of flow marked
differently than non-conforming one
Multmedia Networking 5-82
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
DSCP
unused
Multmedia Networking 7-83
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
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
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
Per-connection QOS guarantees

basic fact of life: can not support traffic demands
beyond link capacity
1 Mbps
phone
1 Mbps
phone
R1
R2
1.5 Mbps link
Principle 4
call admission: flow declares its needs, network may
block call (e.g., busy signal) if it cannot meet needs
Multmedia Networking 7-87
QoS guarantee scenario

resource reservation
 call setup, signaling (RSVP)
 traffic, QoS declaration
 per-element admission control
request/
reply
 QoS-sensitive scheduling
(e.g., WFQ)
Multmedia Networking 7-88
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