Πολυµεσικές Επικοινωνίες στο Internet Εφαρµογές πολυµεσικών επικοινωνιών! Εφαρµογές που περιέχουν audo και vdeo! Μεγάλη ευαισθησία στην καθυστέρηση (<100ms)! Μικρή ευαισθησία στην απώλεια! ιαφορετικές απαιτήσεις απο άλλες εφαρµογές " Streamng, user nteractvty! Παραδείγµατα " streamng audo+vdeo: one-to-one, one-tomany (broadcastng, multcastng) " real-tme nteractve audo+vdeo Multmeda - 2 Προβλήµατα! Το Internet παρέχει υπηρεσία best-effort " χωρίς εγγύηση για καθυστέρηση, απώλεια, jtter " δύσκολη η ανάπτυξη εφαρµογών! Streamng stored vdeo+audo: πιο εύκολο! «Πενία τέχνας κατεργάζεται»! Ανάγκη για διαφοροποιηµένες υπηρεσίες " δροµολογητές µε πολλαπλές ουρές, προτεραιότητες Αναβάθµιση του Internet;! Αναβάθµιση του Internet " παραµένει το ίδιο, µε περισσότερο bandwdth " περιορισµένη σηµατοδοσία, δυνατότητα κρατήσεων πόρων, call-admsson control " κατηγοριοποίηση πακέτων στην είσοδο, διαφορετική µεταχείριση µέσα στο δίκτυο Multmeda - 3 Multmeda - 4
Συµπίεση του audo και vdeo! Το Internet έχει περιορισµένους πόρους " περιορισµένη ταχύτητα πρόσβασης " σηµεία συµφόρησης " λύση: συµπίεση της πληροφορίας! Audo: PM (k δείγµατα/s x n bts/δείγµα) " φωνή: 64Kbps, GSM 13Kbps, G.729 8.5Kbps, G.723 6.4,5.3 Kbps " µουσική: D: 1.411 Mbps PM, MPEG layer 3: 128, 112Kbps (MP3)! Vdeo: 24-30 εικόνες/s, χωρικό-χρονικό πλεόνασµα " MPEG-1 (D-ROM, 1.5Mbps), MPEG-2 (DVD, 3-6Mbps), MPEG-4 (object-orented), H.261 (ISDN) Multmeda - 5 ιανοµή αποθηκευµένου audo-vdeo! ιανοµή αποθηκευµένου audo-vdeo " χαµηλό κόστος αποθήκευσης (dsk storage) " υψηλές ταχύτητες πρόσβασης " network cachng " QoS µηχανισµοί " νέες εφαρµογές (TV, )! Streamng: εφαρµογή λειτουργεί ενώ τα δεδοµένα στέλνονται ", RTSP " εφαρµογές-βοηθοί (meda players) αποσυµπίεση, αφαίρεση jtter, διόρθωση λαθών, έλεγχος Multmeda - 6 Audo-vdeo απο Web server! A/V αρχείο σε web server " χρήση HTTP/TP για αναζήτηση-διανοµή-έλεγχο Web browser Meda player Πρόβληµα µεσάζοντος Web server Web browser Meta-fle Meda player HTTP request/response για meta-fle A/V Web server HTTP request/response για αρχείο A/V Meta-fle: περιγράφει τις ιδιότητες του αρχείου A/V TP: πρόβληµα επανεκποµπών Χρήση streamng server! Streamng server: εξειδικευµένος για audo-vdeo " meda player - streamng server: ειδικά πρωτόκολλα " χρήση UDP, RTSP Αρχείο π-π Web browser Meda player HTTP request/response αρχείου περιγραφής-παρουσίασης Web server Ζήτηση-αποστολή αρχείου A/V Streamng server Ελεγχος (RTSP) Multmeda - 7 Multmeda - 8
Επικοινωνία meda player - streamng server! Πολλές δυνατότητες για µετάδοση πληροφορίας από streamng server στον meda player SS Meda player y (t) x(t) UDP TP data Streamng server Ελεγχος (RTSP) out-of-band Meda player buffer vdeo d Αποσυµπίεση και προβολή Multmeda - 9 Εξάλειψη jtter στον δέκτη για audo! Παράδειγµα εφαρµογής: Internet phone " end-to-end delay: <150ms, 150-400ms, >400ms! Εξάλειψη jtter (στον δέκτη) " αρίθµηση πακέτων, χρονικές σφραγίδες, εισαγωγή καθυστέρησης (bufferng)! Στρατηγική σταθερής καθυστέρησης t 160Β 20ms t 1 t = t + 1 20ms buffer r = στιγµή άφιξης πρώτου πακέτου p = στιγµή «παιξίµατος» πρώτου πακέτου Tme slot παιξίµατος πακέτου = τ = r + ( p r) + ( 1) 20ms Multmeda - 10 Εξάλειψη jtter στον δέκτη για audo (συν.) Εξάλειψη jtter στον δέκτη για audo (συν.) Άχρηστο πακέτο Κανένα πακέτο δεν θεωρήθηκε χαµένο! Προσαρµοζόµενη καθυστέρηση d v = ( 1 u) d 1 + u( r t ) = ( 1 u) v 1 + u r t d Εαν το πακέτο είναι η αρχή µιας αλληλουχίας πακέτων, τότε r p delay p' p = t + d + kv Ερώτηση: πόσο µεγάλη να διαλέξουµε την καθυστέρηση στον buffer; Multmeda - 11 Multmeda - 12
ιόρθωση λαθών! ύο τρόποι: forward error correcton, nterleavng! Forward error correcton " κάθε n πακέτα στείλε Packet L Packet + n+1 " κάθε πακέτο περιέχει και µια χαµηλής ποιότητας περιγραφή του προηγούµενου! Interleavng: κάθε λογικό πακέτο µοιράζεται σε πολλά φυσικά πακέτα Τα πρωτόκολλα, H.323 Multmeda - 13! Προσθέτει επικεφαλίδες στα κοµµάτια πληροφορίας που σπάζονται οι ροές του vdeo και του audo " χρονικές σφραγίδες, αρίθµηση " ontrol Protocol: out-of-band πληροφορία στατιστικές, άλλες χρήσιµες πληροφορίες Transport Applcaton UDP IP Data lnk Physcal Applcaton UDP IP Data lnk Physcal Socket nterface Payload type Sequence number (συν.) Tmestamp! Payload type: 128 τύποι φορτίου! Sequence number: 16 bts! Tmestamp: χρόνος δειγµατοληψίας του πρώτου byte " χρήση ρολογιού δειγµατολήπτη Synchronzaton Source Identfer SSR! SSR: αντιστοιχεί στην πηγή του stream " πάνω από ένα streams ανά sesson other Multmeda - 15 Multmeda - 16
ontrol Protocol () recever sender Internet recever Η.323! Πρότυπο για τηλεπικοινωνία audo και vdeo πραγµατικού χρόνου, Internet τηλεφωνία gatekeeper LAN Internet PSTN H.323 end ponts (IP phones, Ps) gateway τηλέφωνα! nfo: αριθµός πακέτων που εστάλησαν, χάθηκαν, χρόνος ρολογιού αποστολέα, κλπ! Πρόβληµα κλιµάκωσης πακέτων από αποδέκτες Multmeda - 17 Multmeda - 18 G.711 G.722 κλπ Η.261 Η.263 κλπ, RAS channel H.225 H.323 (συν.) all sgnallng channel Q.931 all control channel H.245 Internet all sgnallng channel Q.931 all control channel H.245 Μηχανισµοί για παροχή ποιότητας υπηρεσίας UDP IP TP Meda control channel gatekeeper LAN Internet PSTN H.323 end ponts (IP phones, Ps) gateway τηλέφωνα H.323 end pont Meda channel 1 Meda channel 2 Multmeda - 19
Το πρόβληµα του QoS! Το σηµερινό Internet είναι best-effort! Τα,, FE κλπ βοηθούν στην παροχή QoS! Είναι αρκετά; τι λείπει ακόµη;! Ποιά κοµµάτια λείπουν στην αρχιτεκτονική του Internet; " παροχή εγγυήσεων στις εφαρµογές " µικρό κόστος υλοποίησης " σχέση µε χρέωση! Προτάσεις: ntserv, dffserv, rsvp, mpls H1 H2 Σενάρια εφαρµογών µε QoS Router 1 1.5 Mbps Router 2 Βασικές αρχές: Ορισµός ροών: µαρκάρισµα πακέτων σχετική µε εφαρµογές, γενικότερη κατηγοριοποίηση πακέτων σε ροές υνατότητα «αποµόνωσης» ροών (παροχή ελάχιστων πόρων) Μεγιστοποίηση εκµετάλλευσης πόρων ιαδικασία αποδοχής κλήσης µε βάση τις ζητούµενες εγγυήσεις H3 H4 Multmeda - 21 Multmeda - 22 Μηχανισµοί για QoS Μηχανισµοί για QoS (συν.)! Προγραµµατισµός εξυπηρέτησης πακέτων (schedulng)! Frst-In-Frst-Out (FIFO)! Ουρές µε προτεραιότητες (prorty queung)! preempton Ουρά υψηλής προτεραιότητας Lnk l Lnk Ουρές εξόδου πακέτα κατηγοριοποίηση σύνδεσµος Ουρά εξόδου Σύνδεσµος Είσοδος Lnk k Router Lnk j Ουρά χαµηλής προτεραιότητας Multmeda - 23 Multmeda - 24
Μηχανισµοί για QoS (συν.)! Round-Robn, Weghted Far Queung Μηχανισµοί για QoS (συν.)! Αστυνόµευση πηγής: τρύπια δοχεία " πρόβληµα αστυνόµευσης µέσης τιµής w1 r tokens/s κατηγοριοποίηση w2 Είσοδος w3 Ελάχιστο εύρος ζώνης = w w k σύνδεσµος Multmeda - 25 πακέτα Buffer που πακέτα περιµένουν tokens - b aφαιρείται token Μέγιστος αριθµός πακέτων που εισέρχονται στο δίκτυο σε χρόνο t = rt + b πακέτο µπαίνει στο δίκτυο Multmeda - 26 Μηχανισµοί για QoS (συν.) Βασική ιδιότητα: τρύπια δοχεία + weghted far queung = έλεγχος στην µέγιστη καθυστέρηση πακέτων στο δίκτυο r 1 b 1 r n b n ίκτυο... w 1 d max = b w w k IETF Integrated Servces Archtecture! Υποστηρίζει εγγύηση για QoS στο Internet! Μηχανισµοί: " υνατότητα δέσµευσης πόρων στους routers " ηµιουργία σύνδεσης µέσω σηµατοδοσίας για δέσµευση πόρων στην διαδροµή της σύνδεσης (σε κάθε router) = πρωτόκολλο RSVP " Χαρακτηρισµός κυκλοφορίας εφαρµογής (Tspec) και επιθυµητού QoS (Rspec) " ιαδικασία: µέσω σηµατοδοσίας, κάθε router µαθαίνει τα (Tspec, Rspec), και αποφασίζει εάν έχει αρκετούς πόρους all-setup sgnalng (RSVP) w n Οι ροές αλλάζουν χαρακτηριστικά µέσα στο δίκτυο Multmeda - 27 Multmeda - 28
IETF Integrated Servces (συν.)! Guaranteed Servce: " Ντετερµινιστικό άνω φράγµα για καθυστέρηση " περιγραφή κίνησης και QoS µε τρύπια δοχεία! ontrolled-load Servce: " network provdes servce close to that provded by a best-effort network under lghtly loaded condtons " περιγραφή κίνησης µε τρύπια δοχεία! Best-Effort Servce: " χωρίς εγγυήσεις Multmeda - 29 sender IETF Integrated servces (συν.) network Servce nterface = <Tspec, Rspec> Tspec = (r, b), p, M, m recever r b QoS = guaranteed upper bound on delay (Guaranteed Servces) = as n an uncongested best effort network (ontrolled Load) Rspec = mplct QoS specfcaton = mnmum reserved capacty along the path = (R, S) p Multmeda - 30 Guaranteed Servces Flud model, m = 0, M = sender p R R d1 d2 R D = d 1 + d 2 recever RSVP r b b p R Max end-to-end delay = + D p r R = D f p < R f p > R Gven Tspec, Dmax, D, the applcaton fnds R (= Rspec) Gven Tspec and Rspec, the network chooses the buffer requred for zero cell loss Multmeda - 31
Multcastng Multcast group: set of M senders and N recevers Informaton transmtted: set of channels, parttoned among the senders A recever can lsten to any subset of the channels (encodng layers) What control s needed n order to provde such a servce? S1 R1 T1 T2 S2 R2 Generc soluton: buld M N-cast trees, each tree wde enough to carry the channels of the correspondng sender More ssues to be addressed: Recevers wth unknown access + processng Dynamc membershp n the multcast group Resource allocaton should be applcaton specfc Recevers can subscrbe to a subset of the channels RSVP Assumes exstence of multcast routng protocol, A Basc prncples: allow recevers to dynamcally connect to channels (flows) keep track of already reserved resources and reserve more only f needed use concept of soft state mnmze number of protocol messages separate flters from reservaton Types of servce (reservatons): Wldcard-flter reservaton <*,B> -lsten to all, use B Fxed-flter reservaton <{S},{B}> -lsten to channels n {S}, use {B} Shared-Explct style reservaton <{S},B> -lsten to channels n {S}, use B router sesson flow new recever request for red channel => recever ntated reservaton Multmeda - 33 Multmeda - 34 RSVP (συν.) RSVP (συν.) Path message [S1,M, B] Soft state: upstream requests are updated every t; otherwse reservatons are canceled S1 S2 S3 <S1,B> S3,B <S2,B> S1,S2 S3 S1,B <S3,B> S1,B S2,B requested reserved routng! Path messages: παρέχουν την «αντίστροφη» πληροφορία του multcast tree, ελαττώνουν υπερβολικές κρατήσεις πόρων από τους δέκτες! Τύποι κρατήσεων: Resv messages: περιγράφει τις δυνατότητες συγχώνευσης κρατήσεων, και τις ροές στις οποίες ο δέκτης θέλει να εγγραφεί (ροή = µεταδότης)! Shared reservatons: όταν έχουµε µικρή πιθανότητα ταυτόχρονης µετάδοσης Reservaton message [S1, B] [S2, B] Multmeda - 35 Multmeda - 36
Παραδείγµατα RSVP και IntServ S1 S2,S3 A B Router D R1 R2 R3 WF FF SE send A: 4b B: 4b A: S1(4b) B: S2(5b), S3(b) A: S1(3b) B: (S2,S3)(3b) D D reserve 4b 3b S1(4b) S2(5b) S1(3b) S3(b) (S1, S2)(b) D (S1,S2,S3) (3b) 4b 3b 2b S1(4b),S2(5b) S1(3b),S3(b) S1(b) (S1,S2)(b) (S1,S3)(3b) (S2)(2b)! Resource reservaton s per channel n terms of flowspec (e.g., Tspec + Rspec) Sender (1): Path message [S_TSPE, ADSPE] mn{s_tspec, R_Tspec}, Rspec Recever (2): Resv message [FLOWSPE] ADSPE: QoS control capabltes of sender, accumulates path propertes FLOWSPE: Recever s desred QoS control servce+tspec (+Rspec) Multmeda - 37 Multmeda - 38 IETF Dfferentated Servces Archtecture Dfferentated Servces! Goal: offer a range of network servces (levels of performance) " mprove revenues (premum prcng) " compettve dfferentaton! Key concepts: " scalablty " smple model: traffc that enters the network s classfed nto a small number of classes and condtoned at the boundares of the network a class ( behavor aggregate ) s characterzed by a tag ( DS codepont ) a router servces packets accordng to the tags Multmeda - 40
Ingress node IETF DS Archtecture (cont.) DS doman 1 DS doman 2 Egress node DS servce nterface = SLA DS regon: one or more DS domans Scope of servce: one-drectonal traffc, pont-to-multpont, across domans QoS: quanttatve, qualtatve Dynamc and statc SLAs Egress node Multmeda - 41 IETF DS Archtecture (cont. )! Servce Level Agreement (SLA): " Traffc ondtonng Agreement (TA) QoS (qualtatve-quanttatve) traffc profle (leaky bucket parameters p, ( r, b) ) dsposton of excess traffc markng servces shapng servces " Avalablty, relablty " Routng " Encrypton, authentcaton, montorng, audtng " Other responsbltes " Prcng and bllng mechansms Multmeda - 42 IETF DS archtecture (cont.) Router model: set of output lnks, each lnk offers a set of servces Lnk servce = Per Hop Behavor (PHB) A -> PHB1 A = DSmark B -> PHB2 -> PHB3 A IP packet data? swtch PHB1 PHB2 PHB3 Note: dfferentated servce s after routng decson A data to next node IETF DS Archtecture (cont. ) Examples: A prorty queue wth bandwdth reservaton PHB1 Hgh prorty 1 2Mbps? 1 PHB2 Low prorty Output lnk model Multmeda - 43 Multmeda - 44
IETF DS Archtecture (cont. ) IETF DS Archtecture (cont. ) Operatons at ngress nodes condtoner classfer TA1 DS1 lassfed packet Unclassfed traffc TA2 drop Polcy server Already classfed traffc default lassfcaton: based on mark, flow d ondtonng: enforces TA - marks unmarked packets - possble remarkng, dscardng Best-effort Traffc aggregate 1 2 3 4 DScodepont DS1 DS2 DS3 DS4 Important ssues: - how to allocate resources to PHBs - how to defne mplementable PHBs Multmeda - 45 Multmeda - 46