Übertragung von Streaming Sessions zwischen Multimedia-Gateways

Transkript

1 Übertragung von Streaming Sessions zwischen Multimedia-Gateways Zwischenvortrag Jan Niemann Institut für Betriebssysteme und Rechnerverbund Technische Universität Braunschweig 24. Oktober 2006 Jan Niemann IBR, TU Braunschweig 1

2 Session Transfer Nutzen von Session Transfers Auswahlkriterien Protokoll Jan Niemann IBR, TU Braunschweig 2

3 Multimedia Gateways Multimedia Gateways/ Transcoding Proxies Multimedia Gateways rechnen Multimedia-Ströme um. Vorteile für den mobilen Empfänger : Datenströme werden kleiner, da auf Displaygröße angepasst. Weniger Codecs müssen implementiert werden. Sitzungen nicht nur reine Verbindungsdaten. Informationen über Codierung, Displaygröße, etc. Zwischenergebnisse der Berechnungen. Weitere Daten denkbar, z.b. Statistiken. Jan Niemann IBR, TU Braunschweig 3

4 Session Transfer Session Transfer Prinzipiell: Gateway kann gewechselt werden. Welche Chancen ergeben sich daraus? Nutzen? Auf welcher Grundlage wird ein neuer Gateway ausgewählt? Was muss beim Protokollentwurf berücksichtigt werden? Jan Niemann IBR, TU Braunschweig 4

5 Nutzen - 1 Ein mögliches Szenario: Viele Gateways über das Internet verteilt. Möglichkeit der Auswahl nahegelegener Gateways. Weniger Hops zwischen Gateway und Empfänger. dadurch potenziell weniger Jitter. geringere Latenz erreichbar. Vorraussetzung: Gateways implementieren Leaky-Bucket. Viele Standorte, Viele Gateways. dadurch hohe Kosten. Jan Niemann IBR, TU Braunschweig 5

6 Nutzen - 2 Ein weiteres Szenario: Gateways rund um den Content Server. Nur kleingerechnete Ströme verlassen das Rechenzentrum. Sehr schnelle Session-Transfers möglich. Durch geeignete Verteilung der Berechnungen ist Lastminimierung möglich! Weiterhin denkbar: Session Transfer als Vorarbeit für Gateway Failover? Jan Niemann IBR, TU Braunschweig 6

7 Nutzen - 3 Weitere Chance: Zusammenfassung von Multimedia-Strömen. Aufbau eines Multicast-Netzwerkes über die Proxies. Stichwort: Application Level Multicasting. Vermeidung der Mehrfachübertragung von Daten. Somit Senkung der Netzwerklast. Sehr einfach im vorigen Szenario. Sehr komplex bei im Internet verteilten Gateways. Jan Niemann IBR, TU Braunschweig 7

8 Auswahlkriterien Nach welchen Kriterien kann ein neues Gateway ausgewählt werden? Messungen nicht praktikabel. Geographische Informationen. Netzwerk/Routing-Informationen. Interaktive Auswahl durch Nutzer. Aus Gateway-Sicht einfacher: Zusammenfassen von laufenden Sessions: Minimierung der Berechnungen. Zusammenfassen der Datenströme: Minimierung der Netzlast. benötigt nur Informationen über laufende Sessions. Jan Niemann IBR, TU Braunschweig 8

9 Entwurfskriterien Grundlagen des Entwurfs Ursprünglich nach Two Step Explicit Switch-Schema. Anpassung auf RTSP (Request/Reply). Weiterhin berücksichtigt: Verlässliches Auffinden der Kommunikationspartner. Client-initiierter Transfer. Geringer Qualitätsverlust während des Wechsels. Möglichkeit eines schnellen Wechsels, dafür Qualitätseinbußen während des Wechsels. Jan Niemann IBR, TU Braunschweig 9

10 Ausgangssituation Client Gateway 1 Gateway2 Content Server Jan Niemann IBR, TU Braunschweig 10

11 Ausgangssituation Ausgangssituation Client ist über Gateway 1 mit Content Server verbunden. Jan Niemann IBR, TU Braunschweig 11

12 Client-initiierter Transfer (optional) Client Gateway 1 Gateway2 Content Server Jan Niemann IBR, TU Braunschweig 12

13 Client-initiierter Transfer (optional) Client-initiierter Transfer (optional) optionale Benennung eines bestimmten Gateways. Möglichkeit einen schnellen Transfer zu wählen. Jan Niemann IBR, TU Braunschweig 13

14 Protokollschritt 1 Client Gateway 1 Gateway2 Content Server Jan Niemann IBR, TU Braunschweig 14

15 Protokollschritt 1 Benachrichtigung an Gateway 2 Sämtliche Session-Daten werden übertragen. Spekulation, daß der Session-Transfer klappt. Gateway 2 öffnet Verbindung zum Content Server. Gateway 2 beginnt umgehend mit Transcodierung. Jan Niemann IBR, TU Braunschweig 15

16 Protokollschritt 2 Client Gateway 1 Gateway2 Content Server Jan Niemann IBR, TU Braunschweig 16

17 Protokollschritt 2 Benachrichtigung an Client Client empfängt Verbindungsdaten. Damit Prüfung der Verbindung. Jan Niemann IBR, TU Braunschweig 17

18 Protokollschritt 3 Client Gateway 1 Gateway2 Content Server Jan Niemann IBR, TU Braunschweig 18

19 Protokollschritt 3 Hand-Off Phase n Wiederholungen, Gateway 1 sendet bis s(n) weiter. Wiederholte Möglichkeit für Gateway 2, die Session zu übernehmen. Werte für s und s(n)? zuletzt: Abbau der alten Verbindung. Jan Niemann IBR, TU Braunschweig 19

20 Vielen Dank für Ihre Aufmerksamkeit. Jan Niemann IBR, TU Braunschweig 20