Computerarchitectuur en netwerken. Multimedia in netwerken

Computerarchitectuur en netwerken – 14 – Multimedia in netwerken Lennart Herlaar

20 oktober 2015

Inhoud Multimedia in netwerken Quality of Service Streaming en buffering Protocollen (RTSP, RTP) Scheduling en policing

Lennart Herlaar

Computerarchitectuur en netwerken – 14

1

Multimedia in Netwerken Streamen van audio/video: afspelen gaat net zo snel als verzenden (real-time) en gelĳktĳdig opgeslagen (videotheek): voor- en achteruitspoelen live audio/video: snelheid bĳhouden; vaste vertraging is OK interactief (bĳv. telefoon, videoconferentie): weinig vertraging Multimedia toepassingen: netwerk audio en video (“continue media”)

QoS (Quality of Service) netwerk geeft de toepassing een gewenst niveau van performance/kwaliteit.

Lennart Herlaar


2

Quality of Service Timing vertraging (delay): tĳd tussen verzenden en afspelen moet aan maximum gebonden zĳn vertragingsvariatie (jitter) jitter geeft schok- en jankeffecten wordt veroorzaakt door o.a. propagation delay, queueing, TCP congestion control en error correctie

Bandbreedte moet overeenkomen met te verzenden data evt. data aanpassen aan beschikbare bandbreedte

Pakketverlies data hoeft i.h.a. niet perfect aan te komen kleine verliezen zĳn acceptabel foutcorrectie alleen als er genoeg tĳd is bĳ multimedia is het vaak beter om een pakket verloren te laten gaan dan een hertransmissie te doen

Lennart Herlaar


3

Interactie bĳ streaming van opgeslagen media Stop (pause), start, snelspoelen (als videorecorder) Moet binnen enkele seconden reageren Initiële vertraging mag iets groter zĳn Protocollen: RTP (Real-Time Protocol) voor versturen van de data RTSP (Real-Time Streaming Protocol) voor interactie commando’s

Lennart Herlaar


4

RTSP = ‘afstandsbediening’ Begin met omschrĳving te sturen: XML bestand Daarna besturingscommando’s (PLAY, PAUSE etc.) RTSP gaat via een aparte TCP connectie (out-of-band)

Lennart Herlaar


5

RTSP media omschrĳving Twister <session> <switch> RTSP is een state-full protocol

Lennart Herlaar


6

RTSP commando’s C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session: 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: RTSP/1.0 200 1 OK Session: 4231 Lennart Herlaar


7

Buffering In principe moet verzender even snel aanleveren als afspelen nodig heeft Om variaties in het aanbod op te vangen wordt meestal gebufferd: De cliënt slaat de ontvangen data eerst in een buffer op en speelt het enige seconden later af. Het verzenden kan via UDP – juiste snelheid – error correctie als tĳd over is TCP – flow- en congestion control – error correctie client buffer

aankomstsnelheid = x(t)

uitvoersnelheid =d

van netwerk

naar decompressie en afspelen prefetched video

Lennart Herlaar


8

constant bit rate video transmissie

client video ontvangst

variablele netwerk vertraging

constant bit rate video afspelen bij client

gebufferd video

Cumulatieve data

Buffering

client afspeel vertraging

Lennart Herlaar


tijd

9

Internet telefoon Telefoonspraak heeft 64 kbps nodig (8kBps) Vertraging moet klein zĳn: < 400 msec. Weinig buffering Stiltes hoeven niet verstuurd te worden Data wordt verstuurd in segmenten van 160 bytes per 20 msec (met compressie minder data) vertraging = 20msec + transmissietĳd + propagatietĳd + store-and-forward (queueing!) + buffering Variatie in propagatietĳd veroorzaakt jitter Neem sequence nummer en/of timestamp in pakketten op RTP protocol bovenop UDP voegt deze info toe Pakketten worden op juiste tĳdstip afgespeeld

Lennart Herlaar


10

Jitter wegwerken Iedere 20 msec wordt pakket verzonden Pakketten worden afgespeeld na vaste vertraging p = afspeeltĳd met kleine vertraging, p’ met grotere vertraging packets

loss

packets generated packets received

playout schedule p-r playout schedule p' - r

time r p

Lennart Herlaar

p'


11

Vertraging schatten Als de pakketten een tĳdstempel hebben kunnen we de vertraging van elk pakket berekenen (ti = tĳdstempel, ri = ontvangsttĳd, pi = afspeeltĳd) vertraging = ri − ti Hieruit voortschrĳdend gemiddelde en variantie berekenen di = (1 − u)di−1 + u(ri − ti ) vi = (1 − u)vi−1 + u|ri − ti − di | Voor eerste pakket na stilte: pi = ti + di + Kvi Latere pakketten met de juiste stap. Vergelĳk met RTT berekening bĳ TCP Na iedere stilte kan een nieuwe vertraging gebruikt worden Wat te doen bĳ allereerste pakket? Lennart Herlaar


12

Pakketverlies Pakketverlies kan gecompenseerd worden door extra informatie te sturen Of door verliezen te verdelen Forward Error Correction (FEC) 1: Gebruik een pariteitspakket (= exclusive or): blok 1 blok 2 blok 3 blok 4 blok 5 parity

0 0 1 0 1 0

1 0 1 0 0 0

1 1 0 0 1 1

0 1 0 1 1 1

1 0 0 1 0 0

1 1 0 1 0 1

Als één pakket verloren gaat kan het gereconstrueerd worden Bĳ 1 extra pakket per n pakketten is de overhead 1/n Reconstructie kan pas plaatsvinden als het parity pakket binnen is. Lennart Herlaar


13

FEC 2 Voeg extra informatie toe met lagere kwaliteit Deze wordt met het volgende pakket meegestuurd Als een pakket verdwĳnt gebruik dan de extra informatie uit het volgende pakket

Lennart Herlaar


14

Interleaving Bĳ interleaving geen extra informatie maar informatie verspreiden Als er een pakket verloren gaat dan kleine hikjes over grotere tĳd in plaats van een grote hik maar wel meer vertraging

Lennart Herlaar


15

RTP RTP = Real-Time Transport Protocol Wordt normaal bovenop UDP gebruikt Voegt extra headers toe Wordt gebruikt alsof het in de transportlaag zit

Lennart Herlaar


16

RTP header Payload Type

Sequence Number

Timestamp

Synchronisation Source Identifier

Miscellaneous Fields

Payload type = wat voor soort codering Sequence number = volgnummer Timestamp = tĳdstip van de eerste byte Synchronisation Source Identifier = unieke id van een stream

Lennart Herlaar


17

RTCP RTCP = Real-Time Control Protocol Wordt gebruikt om informatie over kwaliteit van de verbinding tussen verzender en ontvanger te versturen Ook voor synchronisatie van verschillende stromen

Lennart Herlaar


18

Quality of Service Alle vorige protocollen waren Best Effort De IP laag doet zĳn best maar kan niets garanderen Je kunt ook niet vragen om betere kwaliteit In de toekomst waarschĳnlĳk betere protocollen nodig RSVP = reserveren van o.a. bandbreedte Differentiated Services gedifferentieerde garanties Integrated Services harde garanties

Lennart Herlaar


19

Voorbeeld 1 Telefoonverbinding (1Mbps) en FTP delen 1.5Mbps verbinding Pakketten van telefoon en FTP moeten verschillend behandeld worden Telefoonverbinding moet gegarandeerde bandbreedte hebben FTP kan genoegen nemen met wat over is

Lennart Herlaar


20

QoS principes Pakketten moeten geclassificeerd worden (Type-of-Service) Verschillende stromen moeten van elkaar geïsoleerd worden Een stroom mag niet meer gebruiken dan ervoor gereserveerd is (anders afknĳpen) Als een stroom minder gebruikt dan mag de resterende capaciteit voor iets anders gebruikt worden Je kunt niet meer bandbreedte gebruiken dan er is: dus van tevoren reserveren (en evt. weigeren)

Lennart Herlaar


21

Priority Queue Gewoonlĳk komen pakketten in router in uitgaande queue Pakketten die haast hebben kunnen hogere prioriteit krĳgen Hogere prioriteitsqueue kan hele bandbreedte ‘kapen’

Lennart Herlaar


22

Priority Queue rood = hoge prioriteit

Lennart Herlaar


23

Round Robin/WFQ Bĳ Round Robin worden pakketten in verschillende categorieën ingedeeld Elke categorie gaat om de beurt (als er iets is)

Lennart Herlaar


24

Round Robin/WFQ Bĳ WFQ (Weighted Fair Queueing) krĳgen verschillende categorieën verschillende gewichten Hogere prioriteiten komen vaker aan de beurt Als w het gewicht van een categorie is en W de som van alle gewichten dan krĳgt die categorie tenminste w /W van de bandbreedte toegewezen

Lennart Herlaar


25

Token Bucket Token Bucket: mechanisme om snelheid van een stroom te regelen (toeritdosering) in het boek staat leaky bucket (lekkende emmer) Idee: een stroom heeft een maximale gemiddelde bandbreedte maar mag tĳdelĳk meer gebruiken (burst) Tĳdens rustige perioden wordt een tegoed (tokens) opgebouwd dat voor een burst gebruikt mag worden

Lennart Herlaar


26

Parameters van bucket Gemiddelde snelheid (pakketten/sec of bytes/sec): wat je over een lange tĳd mag gebruiken. De bucket krĳgt per tĳdsinterval een token, die staat voor een vaste hoeveelheid capaciteit (packets of bytes) Bĳvoorbeeld 1 token = 10000 bytes en 1 token per 10 msec => 1MByte/sec Pieksnelheid: maximale snelheid die je gedurende een korte periode mag gebruiken als je genoeg tokens hebt: bĳvoorbeeld 10MBytes/sec Maximale grootte van zo’n burst wordt bepaald door inhoud bucket

Lennart Herlaar


27

Token bucket + WFQ Als r tokens per seconde arriveren en bucket maximaal b tokens bevat dan kunnen per tĳd t maximaal r · t + b pakketten verzonden worden. Queue: Als burst van b aankomt en uitgaande capaciteit is b R dan maximale wachttĳd = R b Met WFQ: R · w /W

Lennart Herlaar


28

Samenvatting Multimedia toepassingen stellen nieuwe eisen aan het netwerk: Quality of Service om vertraging, jitter, bandbreedte en pakketverlies in de hand te houden

Verschillende protocollen voor het besturen van streaming (RTSP) het sturen van de media (RTP) het opzetten van sessies (SIP, zie boek)

Voor QoS kunnen we gebruik maken van policing (Leaky bucket/token bucket) prioriteiten in routers (Round robin/WFQ)

Lennart Herlaar


29

Computerarchitectuur en netwerken. Multimedia in netwerken

Recommend Documents