Coral Communication Protocols for Real-time

Transkript

1 Coral Communication Protocols for Realtime Access to Digital Libraries Prof. Dr. Peter Martini, Markus Albrecht, Michael Köster Institut für Informatik IV (Rechnernetze Verteilte Systeme) Universität Bonn {martini, sukram, 1. Einleitung Motivation 2. Arbeiten in Phase 1 3. Ausblick auf Phase 2 4. Zusammenfassung 1

2 1. Coral: Überblick Coral = Communication Protocols for RealTime Access to Digital Libraries Coral = Communication Protocols for Realtime Access to Digital Libraries Forschungsthemen Netzwerk Transportprotokolle Applikationsspezifische Protokolle nahe an IPTechnologien (IETF) breite Anwendbarkeit (wie IP) interaktiver Zugriff NetzwerkRessourcenreservierung adaptive MedienSkalierung MediaStreaming Zugriff auf gespeicherte Daten MultimediaDokumente Client/ServerArchitektur Webbasierter Zugriff (im Moment) nicht betrachtet Änderungen im Betriebssystem Design von NetzwerkHardware Accounting File transfer artige Zugriffe Design von Werkzeugen für verteiltes Authoring Bereitstellen von Inhalten BroadcastApplications (TV) 2

3 Digitale Bibliotheken im Internet Die Zugriffsstrukturen auf Digitale Bibliotheken im Internet sind sehr komplex! DLServer (1) Bibliotheksnetzwerk (1) DLServer (2) Bibliotheksnetzwerk (2) LAN Border Eigenschaften: Router Client/ServerSzenario (Server am bibliotheksinternen Netz, Clients irgendwo ) mehrere Netzbetreiber (unterschiedliche Dienste,...) verschiedene Technologien (heterogene Netzarchitektur) verteilte Informationsquellen (transparent für Benutzer) Proxy Server (InformationsCaching) Proxy Server xdsl/isdn/pots Internet Service Provider XOnline ISP YNet xdsl ISDN 3

4 2. Arbeiten in Phase 1 Anforderungsanalysen Anforderungen im Anwendungsbereich Anforderungen an Kommunikationssysteme Design eines Transportsystems Movie on Demand via ATM Progressive 3DObjektströme Bewertung durch Simulation Movie on Demand via ATM RSVPModul für ns2 RSVP im DFNModell Implementierung Anwendung Movie on Demand via ATM Progressive 3DObjektströme (in Kooperation mit AG Seidel/Kobbelt) 4

5 2.1. Anforderungsanalysen Zu Beginn des Projekts sollen durch Analysen die Probleme erkannt der Bedarf ermittelt werden. Was wurde analysiert? Anforderungen an den interaktiven Echtzeitzugriff auf Digitale Bibliotheken Was hat die Analyse ergeben? Die Analyse der Anforderungen im Anwendungsbereich ergab eine Klassifikation von Anwendungen (gemäß ihren Anforderungen) in 3 Klassen: Audio/Video Streaming steigender Komplexitätsgrad 3D Streaming Virtual Reality Aus der Analyse der Anforderungen im Anwendungsbereich wurden technische Anforderungen an Kommunikationssysteme hergeleitet: schnelle Bereitstellung von Netzressourcen (Reservierung) notwendig Anpassung der Reservierung an Last wünschenswert (effizient + kostengünstig) Übertragungsverluste in gewissen Grenzen tolerierbar adaptive Übertragung sinnvoll (Anpassung der Datenrate an aktuell verfügbare/finanzierbare Ressourcen) 5

6 Audio/Video Streaming DLServer Audio/VideoFrames Netzwerk Interaktivität: VCRFunktionalität Interaktiver Zugriff: Start, Stop, Pause, Fast Forward/Rewind Eigenschaften Eigenschaften der der Daten: Daten: einzelner einzelner Audio/VideoStrom Audio/VideoStrom skalierbares skalierbares Video Video Beispiel: Beispiel: MPEG2 MPEG2 (PALQualität, (PALQualität, fps) fps) durchschn. durchschn. FrameGröße: FrameGröße: 16,7 16,7 kbytes kbytes Bitrate: Bitrate: 4 4 Mbit/s Mbit/s VideoSkalierungsmodes: VideoSkalierungsmodes: räumliche, räumliche, zeitliche zeitliche SNRSkalierbarkeit, SNRSkalierbarkeit, Data Data Partitioning Partitioning Forderungen Forderungen an an Transport Transport Netzwerk: Netzwerk: nach nach oben oben beschränkte beschränkte Reaktionszeit Reaktionszeit (bei (bei Interaktion) Interaktion) garantierte garantierte Startverzögerung Startverzögerung garantierte garantierte Verzögerung Verzögerung (delay) (delay) garantierter garantierter Jitter Jitter nach nach Möglichkeit: Möglichkeit: Ressourcenreservierung Ressourcenreservierung im im Netz Netz nach nach Möglichkeit: Möglichkeit: Unterstützung Unterstützung adaptiver adaptiver Übertragung Übertragung nicht nicht aber: aber: zuverlässiger zuverlässiger Transport Transport Beispiel: Movie on Demand 6

7 3D Streaming DLServer Szene, 3DObjeke (Dreiecksnetz, VertexSplits) Netzwerk Interaktiver Zugriff: Start, Stop, Pause, Fast Forward/Rewind Interaktivität: VCR Funktionalität Bewegung durch die Szene (lokal am Client) Eigenschaften Eigenschaften der der Daten: Daten: statische statische 3DSzenenbeschreibung 3DSzenenbeschreibung mehrere mehrere Ströme Ströme mit mit großen großen 3DObjekten: 3DObjekten: skalierbar: skalierbar: progressive progressive Netzrepräsentation Netzrepräsentation 3DObjekt 3DObjekt = = Dreiecksnetz Dreiecksnetz + + VertexSplits VertexSplits Bsp.: Bsp.: 10,000 10, Kbytes Kbytes (unkomprimiert) (unkomprimiert) Bitrate Bitrate (30 (30 fps): fps): Mbit/s Mbit/s Forderungen Forderungen an an Transport Transport Netzwerk: Netzwerk: nach nach oben oben beschränkte beschränkte Reaktionszeit Reaktionszeit (bei (bei Interaktion) Interaktion) garantierte garantierte Startverzögerung Startverzögerung garantierte garantierte Verzögerung Verzögerung (delay) (delay) garantierter garantierter Jitter Jitter heute heute noch: noch: zuverlässiger zuverlässiger Transport Transport Ressourcenreservierung Ressourcenreservierung im im Netz (mindestens für Basisstruktur) Netz (mindestens für Basisstruktur) nach nach Möglichkeit: Möglichkeit: Unterstützung Unterstützung adaptiver adaptiver Übertragung Übertragung Beispiel: Visualisierung von Auto Crash Simulation 7

8 Virtual Reality DLServer Szene (updates), 3DObjekte, 2DObjekte,... Netzwerk Interaktiver Zugriff: SzenenEvents Interaktivität: Bewegung durch die Szene (am Client + Server) Änderung der Szene Szene/ObjektEvents (A/V: VCR) Eigenschaften Eigenschaften der der Daten: Daten: dynamische dynamische 3DSzenenbeschreibung 3DSzenenbeschreibung verschiedene verschiedene Objekttypen, Objekttypen, statisch statisch dynamisch dynamisch geladen: geladen: statische statische 2D, 2D, 3DObjekte 3DObjekte A/V A/V + + 3DStröme 3DStröme kontextabhängige kontextabhängige Strompräferenzen Strompräferenzen (LOD) (LOD) Forderungen Forderungen an an Transport Transport Netzwerk: Netzwerk: nach nach oben oben beschränkte beschränkte Reaktionszeit Reaktionszeit (bei (bei Interaktion) Interaktion) garantierte garantierte Startverzögerung Startverzögerung garantierte garantierte Verzögerung Verzögerung (delay) (delay) garantierter garantierter Jitter Jitter zuverlässiger zuverlässiger unzuverlässiger unzuverlässiger Transport Transport Ressourcenreservierung Ressourcenreservierung im im Netz Netz Unterstützung Unterstützung adaptiver adaptiver Übertragung Übertragung Beispiel: virtuelles Museum (MPEG4kodierter Medienstrom) 8

9 2.2. Interactive Movie on DemandAnwendung über ATM Ziel: Ziel: Effizienter interaktiver Zugriff Zugriff auf auf Digitale Digitale (Video) Bibliotheken (bei (bei minimalen minimalen Kosten) Kosten) Problem: Bisher Bisher eingesetzte Serviceklassen (z.b. (z.b. ATM ATM VBR) VBR) für für Interaktivität nicht nicht geeignet Lösung: Nutzung neuer neuer Serviceklassen (Renegotiation (Renegotiation Services) Services) mit mit optimaler Berechnung von von Neuverhandlungsstellen Aktivitäten im im Projekt: Design Design prototypische Implementierung eines eines Movie Movie on on Demand Transportsystems mit mit SOS SOS (Smoothing (Smoothing and and Optimal Optimal Segmentation) Segmentation) Vergleich von von SOS SOS mit mit anderen Verfahren Bewertung durch durch Simulation Messung 9

10 Zugriffsszenario: Homogenes Bibliotheksnetzwerk Zunächst soll nur das bibliotheksinterne Netzwerk betrachtet werden. Motivation / Beispiel: Die Deutsche Bibliothek in Frankfurt besitzt ein internes ATMNetzwerk. Eigenschaften: Client am BibliotheksLAN angeschlossen homogene Netzwerktechnologie kein Router auf dem Pfad vom DLServer zum lokale Administration 10

11 Anwendungsszenario DLServer ATMBibliotheksnetz Server Server gespeichertes gespeichertes Video Video MPEG MPEG kodiert kodiert UnicastStröme UnicastStröme Client Client Auswahl Auswahl eines eines Videos Videos interaktive interaktive Steuerung Steuerung (VCRFunktionalität) (VCRFunktionalität) Ein kompletter Download vor der Wiedergabe ist nicht sinnvoll aus CopyrightGründen, wegen begrenzter Speicherkapazität am Empfänger, wegen des a priori nicht bekannten Interaktionsschemas. Anforderungen der Anwendung: streamed Video mit kontinuierlicher Wiedergabe (bedingt evtl. einen großen PlaybackPuffer) begrenzte Antwortzeit bei Interaktionen (bedingt einen kleinen PlaybackPuffer) 11

12 Dynamische Bandbreitenreservierung in ATM Welche ATM Serviceklasse ist geeignet für interaktive Videoanwendungen? CBR? VBR? Nicht geeignet, weil (teure) Bandbreite verschwendet wird. Nicht geeignet, weil die Interaktionen des Benutzers nicht beim Verbindungsaufbau absehbar sind. Zwei ATM Serviceklassen wurden als optionale Signalisierungserweiterungen vorgeschlagen: 1. RCBR Service (Renegotiated CBR, ITUT Rec. Q ) 2. RVBR Service (Renegotiated VBR, ITUT Rec. Q ) frame size [cells] RCBR CBR Segment frame number (Video source: Starwars, 166 secs) Die optimalen Neuverhandlungsintervalle werden offline berechnet: m 1 K ( S) = ( k( Si ) r( Si )) + + k( S i= 1 m ) k( Si ) = Bandbreitenkosten für Segment Si r( S ) = Kosten für Neuverhandlung i am Ende des Segments S m = Anzahl Segmente i Preisliste des Netzwerkbetreibers Bei Interaktionen (Fast Forward / Rewind, Pause, etc.) sind die Bandbreitenanforderungen für den neuen Startpunkt exakt bekannt. 12

13 Simulationsergebnisse: RCBR vs. CBR Szenario: LinkBandbreite: 155 Mb/s durchschnittliche Segmentlänge: 13.3 sec Je besser die Glättung des Videostroms ist, desto größer ist die Latenz (beeinflußt Antwortzeit bei Interaktionen). 100 Netzwerkauslastung [%] RCBR: heterogene Videolast RCBR: Video "MTV clips" RCBR: Video "TV talk show" CBR: heterogene Videolast CBR: Video "MTV clips" CBR: Video "TV talk show" 0 0,01 0, Latenz [s] Der RCBR Service bringt eine sehr viel höhere Netzauslastung als der CBR Service. 13

14 Simulationsergebnisse: RCBR vs. VBR Szenario: heterogene Videolast durchschnittliche Segmentlänge: 13.3 sec Je besser die Glättung des Videostroms ist, desto größer ist die Latenz (beeinflußt Antwortzeit bei Interaktionen). 100 Netzwerkauslastung [%] VBR: 155 Mb/s RCBR: 155 Mb/s VBR: 45 Mb/s RCBR: 45 Mb/s 0 0,01 0, Latenz [s] Der RCBR Service bringt eine höhere Netzauslastung als der VBR Service. 14

15 Ausblick: Dynamische Bandbreite im (heterogenen) Intranet Frage: Ist die dynamische Bandbreitenreservierung mit RSVP in IntranetSzenarien anwendbar? (Wenn ja: Wie?) Achtung: Bei RSVP reserviert der Empfänger. DLServer Path Message DLNetz LAN Resv Message RSVP ermöglicht Neuverhandlungen (Soft State Protocol). RSVP Router Campus Backbone RSVP Router Diese Fragestellung soll in Phase 2 untersucht werden. 15

16 2.3. Simulationsumgebung Die Simulationsaktivitäten im Projekt basieren auf dem Network Simulator ns2: ereignisorientierter Simulator zur Leistungsbewertung von Netzwerken entwickelt von USC/ISI, Xerox PARC, LBNL UCB offene Struktur (erweiterbar) Das Simulationsmodul RSVP/ns wurde im Rahmen des V3D2Projekts für Bewertungen von / mit RSVP entworfen vis. front end ns2 traffic models wird inzwischen von zahlreichen Gruppen in Europa, den USA Asien eingesetzt. RSVP/ns TCP/IP Das modulare ns2system soll in Phase 2 um weitere Bausteine erweitert werden. 16

17 2.4. Visualisierung von Geometriedaten Ziel: Ziel: Interaktiver Zugriff Zugriff auf auf 3DDatenströme (Geometriedaten) (Geometriedaten) über über das das Internet Problem: Internet bietet bietet (noch) (noch) keine keine garantierte Dienstgüte, dadurch schwankende verfügbare Bandbreite Lösung: Anpassung der der Übertragung an an die die verfügbaren Netzressourcen Einsatz Einsatz progressiver Verfahren mit mit hierarchischen Daten Daten Aktivitäten im im Projekt: Design Design prototypische Implementierung eines eines progressiven 4D Transportsystems Kooperation mit mit AG AG Seidel/Kobbelt vom vom MPI MPI in in Saarbrücken 17

18 Zugriffsszenario: Single Internet Service Provider Nun wird eine Verbindung vom Bibliotheksnetz in das Internet betrachtet. Motivation / Beispiel: Bibliotheksnetzwerk an XOnline angeschlossen, Client an XOnline angeschlossen Eigenschaften: Border Router auf dem Pfad vom Server zum Client kein Zugriff auf ISPinterne Netzwerkkomponenten Bandbreite ist (sehr?) teuer begrenzt keine EndezuEndeReservierung für Einzelströme 18

19 Anwendungsszenario Progressive Progressive Übertragung Übertragung von von 3DObjektströmen 3DObjektströmen Kooperation Kooperation mit mit Arbeitsgruppe Arbeitsgruppe von von Prof. Prof. Seidel Seidel Dr. Dr. Kobbelt Kobbelt / / MPI MPI Saarbrücken Saarbrücken (Computer (Computer Graphik) Graphik) DLServer 3DSzene, 3DObjektstrom Netzwerk Szenario: Szenario: Visualisierung Visualisierung von von Auto Auto Crash Crash Simulationsergebnissen Visualisierungsdaten Visualisierungsdaten bestehen bestehen aus aus 3DSzene 3DSzene 3DObjektstrom 3DObjektstrom (Dreiecksnetze) (Dreiecksnetze) Großer Großer Bestand Bestand von von Simulationsergebnissen in in Digitaler Digitaler Bibliothek Bibliothek (Download (Download nicht nicht sinnvoll) sinnvoll) Ergebnisse Ergebnisse bieten bieten Daten Daten mit mit hoher hoher räumlicher räumlicher zeitlicher zeitlicher Auflösung Auflösung Adaptation Adaptation hochauflösender hochauflösender Daten Daten auf auf verfügbare verfügbare Ressourcen Ressourcen (Netz (Netz + Client) Client) erforderlich erforderlich Benutzung Benutzung von von Ressourcenreservierung wenn wenn möglich möglich Benutzung Benutzung von von zeitlicher zeitlicher Skalierung Skalierung Benutzung Benutzung von von räumlicher räumlicher Skalierung Skalierung mit mit progressiver progressiver Übertragung Übertragung 19

20 Architektur Single ISP Example: des Prototypen: Visualization Überblick of Simulation Results (3) Server (C++) Client (Java) 3DDaten (hierarchisch) Parser Progressive Übertragung FEC (Phase 2) Java3DViewer GeometrieModul Progressive Übertragung Anwendervorgaben: Framerate bald:%vertexsplits RTPServer RTPClient RTP Payload Typen: Info BasisPunkte BasisDreiecke %VertexSplits UDP/IP RTP RTCP UDP/IP RTCPFeedback zum Sender (u.a.): %Paketverluste Framerate bald: %VertexSplits Erster Erster Prototyp: Prototyp: Übertragung Übertragung einzelner einzelner 3DObjekte 3DObjekte mit mit fester fester 3DSzene 3DSzene Transportprotokoll Transportprotokoll basiert basiert auf auf RTP/RTCP RTP/RTCP Einfacher Einfacher 3D 3D PlaybackPuffer PlaybackPuffer mit mit Basisnetzen Basisnetzen VertexSplits VertexSplits Überlastkontrolle Überlastkontrolle durch durch zeitliche zeitliche räumliche räumliche Skalierung Skalierung der der Dreiecksnetze Dreiecksnetze 20

21 ÜberlastManagement am Client Einzelnes Dreiecksnetz Empfänger QoSFeedback Modul an Server Mesh Modul Viewer (Java3D) 3DDaten vom Server RTP / RTCP Puffer (Basisnetz + VertexSplits) Dreiecksnetz Datenempfang: Datenempfang: Empfange Empfange Basisnetz Basisnetz Empfange Empfange VertexSplits VertexSplits bis bis Anzeigezeitpunkt Anzeigezeitpunkt erreicht erreicht (Zeitstempel) (Zeitstempel) Zeige Zeige Objekt Objekt an an Mögliche Mögliche Probleme: Probleme: Client Client (3DRendering) (3DRendering) zu zu langsam langsam NetzwerkÜberlast NetzwerkÜberlast / / Bandbreitenbeschränkung Bandbreitenbeschränkung Überlast/Flußkontrolle: Überlast/Flußkontrolle: Client: Client: Reduziere Reduziere 3DNetzQualität 3DNetzQualität (implizit) (implizit) Verwerfe Verwerfe ganze ganze Meshes Meshes Sende Sende QoSFeedback QoSFeedback zum zum Server Server Server: Server: Reduziere Reduziere 3DNetzQualitätslevel 3DNetzQualitätslevel (geringere (geringere Anzahl Anzahl VertexSplits) VertexSplits) Reduziere Reduziere Framerate Framerate 21

22 3. Ausblick auf Phase 2 Motivation DLServer ATM Arbeiten in Phase 1: MoD über homogenes ATM Netzwerk Progressive Übertragung hierarchischer Daten über das Internet ISP Weitere Arbeiten in Phase 2 erforderlich! 22

23 Phase 2: Einzelströme im Internet Separate Betrachtung einzelner Echtzeitströme DLServer DLNetz Problem: QoSMinderung durch Paketverluste im Internet Lösung: MedienSkalierung dyn. QoSAnpassung + Fehlertolerante Echtzeitübertragung hierarchischer Daten + Reservierung von Netzressourcen ISP ISP 23

24 Phase 2: Konkurrierende Ströme im Internet Übergeordnete Betrachtung konkurrierender Echtzeitströme DLServer je 3 Mb/s DLNetz 2 Mb/s Problem: aggregierte Reservierung (6 Mb/s) Sendebandbreite größer als reservierte Bandbreite (SLA) ISP Lösung: Stromübergreifendes Congestion Management + Stromübergreifendes QoSManagement 2 Mb/s ISP 2 Mb/s 24

25 Phase 2: Arbeitsprogramm Anforderungsanalysen Anforderungen zukünftiger Anwendungen (z.b. Virtual Reality) RSVP RTP Design eines Transportsystems stromübergreifendes Congestion Management Reservierung im Internet dynamische QoSAnpassung xdsl IntServ VRML QoS IETF MPEG4 ns2 DiffServ Bewertung durch Simulation IntServ/DiffServModule für ns2 implementieren Flußaggregration (mit RSVP) bewerten Implementierung Anwendung Implementierung von Prototypen Mitwirkung an Aktivitäten der IETF Kooperation im SPP V3D2 25

26 4. Zusammenfassung Die Anpassung von Kommunikationsprotokollen an die Anforderungen der Anwendung die Übertragungseigenschaften der Kommunikationsnetzwerke ist Voraussetzung für den interaktiven Echtzeitzugriff auf Digitale Bibliotheken. Reservierungsverfahren progressive Übertragung sind geeignete Methoden zur Realisierung von anwendungsspezifischen Transportsystemen. Das Design eines solchen Transportsystems muß sich an der zukünftigen Entwicklung des Internets orientieren. Dies ist Ziel der Projektphase 2. 26