Einleitung/ Motivation

1

auto

• Ziel ist Multimedia-On-Demand Netzwerk mit True Multimedia-On-Demand Performance
  • Kunden sollen jederzeit beliebige Multimedia Dokumente bestellen und auch gleich abspielen können
• Realisierung basierend auf reiner True-Multimedia-On-Demand Technologie scheitert an Kosten
• Caching Technologie
  • Ermöglicht quasi True Multimedia-On-Demand
    • Caching Strategien trachten danach, Bandbreiten- und Speicherbedarf möglichst niedrig zu halten
    • Caching ist der Schlüssel, um ein True Multimedia-On-Demand Service wirtschaftlich sinnvoll anbieten zu können

2

auto

Kunden sind über einen Breitbandanschluss an ein Multimedia-On-Demand Netzwerk angebunden: Sie können von zu Hause aus mittels Fernbedienung via Set Top Box oder PC zu jeder beliebigen Zeit Spielfilme, aktuelle Nachrichten, Hörspiele, Musikstücke etc bestellen und ohne Verzögerung gleich auch abspielen. Eine Realisierung dieser Vision basierend auf einer reinen True Multimedia-On-Demand Technologie ist von Vornherein zum Scheitern verurteilt: Zu hoch sind die Kosten der erforderlichen Netzwerkbandbreiten, zu teuer die benötigten Speichergeräte. Der Schlüssel für ein rentables True Multimedia-On-Demand Service ist Caching. Diese Lerneinheit bietet einen Überblick über das Thema und zeigt, wie mittels Caching ein quasi True Multimedia-On-Demand Service zu einem Preis geboten werden kann, von dem man annehmen kann, dass er von der zukünftigen Kundschaft allgemein akzeptiert werden wird.

3

auto

Die unterschiedlichen Video-on-Demand Servicetypen werden in der Lerneinheit Einführung und Grundlagen vorgestellt.

Ideales Multimedia-On-Demand Netzwerkmodell

1

Idealfall True Multimedia-On-Demand

• Idealfall ist True Video-On-Demand
  • Nachteil
    • Benötigt als Infrastruktur ein Super-Netzwerk

Fiktives Szenario landesweite True Multimedia-On-Demand Service in den USA

• Annahme
  • Alle Benutzer sollen mit einem eigenen 20Mbps Datenstrom (MPEG-2 für HDTV) bedient werden
  • In Spitzenzeiten muss mit ca. 77 Millionen Requests gerechnet werden
• Anforderung an das Netzwerk
• Daraus resultiert eine Gesamtbandbreite von 1.54 Tbps!
• True Multimedia-On-Demand Netzwerkmodell basierend auf zentralem Superserver
  • Alle Programme liegen auf zentralem Superserver
  • Jeder Request belastet gesamtes Netzwerk
    • Netzwerk wird gigantische Bandbreite abverlangt
  • Technisch machbar, aber erforderliche Bandbreite verursacht unrentable Kosten
• True Multimedia-On-Demand Netzwerkmodell basierend auf dezentrale Speichergeräte
  • Es werden viele Server miteinander vernetzt
  • Auf jedem Server liegen Kopien aller verfügbaren Programme
    • Einzelne Requests belasten nur mehr kleinen Teil des Netzwerks
    • Hoher Bedarf an Speicherplatz
  • Technisch machbar, aber erforderlicher Speicherplatz verursacht unrentable Kosten

Kostenrentabilität eines Multimedia-On-Demand Netzwerkes

• Ergebnis von Befragungen
  • 44% der Befragten sind bereit, für ein Multimedia-On-Demand Service zu bezahlen
  • Nur 14% der Befragten würden einen höheren Preis als den für heutige Netzwerkdienste (Fernsehen, Breitbandinternet...) üblichen akzeptieren
• Schlussfolgerung
  • Kostenminimierung muss bei Konzipierung eines Netzwerkmodells im Vordergrund stehen
  • Kostenminimierung wird erreicht durch Reduktion von
    • Speicherplatzbedarf
    • Bandbreite

2

Idealfall True Multimedia-On-Demand

Man betrachte die drei On-Demand Services Pay-Per-View, Near Video-On-Demand und True Video-On-Demand (siehe dazu MM Server: Einführung und Grundlagen). Auf den ersten Blick ist das True Multimedia-On-Demand Service das ideale System. Jeder Benutzer kann zu beliebiger Zeit ein beliebiges Video (oder Audiodokument) anfordern, direkt nach Abschicken des Requests kann er dann auch schon das gewünschte Video oder Audio starten. Während der Wiedergabe werden VCR Befehle problemlos ausgeführt. True Multimedia-On-Demand hat nur einen entscheidenden Haken: Es benötigt als Infrastruktur ein Super-Netzwerk. Da für jeden Request ein eigener Datenstrom vom Netzwerk übertragen werden muss, ergeben sich exorbitant hohe Werte für die erforderliche Netzwerkbandbreite.

Fiktives Szenario landesweite True Multimedia-On-Demand Service in den USA

Um eine Relation für die in der Praxis benötigten Werte eines reinen True Multimedia-On-Demand Service zubekommen, ein fiktives Beispiel. Es soll ein landesweites Netzwerk aufgebaut werden, das alle Benutzer mit individuellen 20Mbps Datenströme (MPEG-2 für HDTV) gleichzeitig beliefern kann. In den Abendstunden muss man mit ca. 77 Millionen Requests rechnen. Daraus ergibt sich eine vom Netzwerk geforderte Gesamtbandbreite von 1.54 Tbps!

True Multimedia-On-Demand Netzwerkmodell basierend auf zentralem Superserver

Man kann einen zentralen Superserver bauen, auf dem alle vom True Multimedia-On-Demand Service gebotenen Programme gespeichert sind. Jeder Kunde interagiert direkt mit dem zentralen Server. Das Netzwerk muss so ausgelegt sein, dass es dem hohen Bedarf an Bandbreite problemlos nachkommen kann. Ein Knackpunkt bei der Realisierung dieses Szenario ist weniger dessen technische Machbarkeit, viel mehr sind es die hohen und vor allem unrentablen Kosten, die der Aufbau und Betrieb eines solchen Supernetzwerkes verursachen würde.

True Multimedia-On-Demand Netzwerkmodell basierend auf dezentrale Speichergeräte

Als Alternative zu einem zentralen Superserver kann man das Netzwerk dezentralisieren: Es werden viele Server miteinander verbunden, wobei auf jedem Server Kopien aller die vom True Multimedia-On-Demand Service gebotene Programme stehen. Jeder Kunde interagiert ausschließlich mit dem ihm geographisch am nächst gelegenen Server. Durch diesen Aufbau werden den Leitungen des Netzwerkes geringere und somit auch kostenrentable Bandbreiten abverlangt. Da von jedem Programm eine Vielzahl von Kopien vorhanden sein muss, hat dieses Modell einen enorm großen Bedarf an Speicherplätzen. Speicherplätze sind wie Netzwerkbandbreiten sehr teuer. So scheitert die Realisierung dieses Netzwerkmodells ebenfalls an den hohen Kosten.

Kostenrentabilität eines Multimedia-On-Demand Netzwerkes

Untersuchungen haben ergeben, dass 44% der Befragten bereit wären, für ein Multimedia-On-Demand Service auch zu bezahlen. Allerdings würden nur 14% davon einen höheren Preis als den für heutige Netzwerkdienste (Fernsehen, Breitbandinternet..) üblichen akzeptieren. Um ein rentables Multimedia-On-Demand Service bieten zu können, muss daher bereits bei der Konzipierung des Netzwerkmodells die Kostenfrage dementsprechend im Vordergrund stehen. Wie obiges Beispiel zeigt, muss es oberstes Ziel sein, benötigte Netzwerkbandbreite und Speicherplatzbedarf möglichst klein zu halten.

3

auto

Erklärung der drei On-Demand Services Pay-Per-View, Near Video-On-Demand und True Video-On-Demand siehe MM Server: Einführung und Grundlagen)

Hierarchisches Netzwerk

1

Architektur eines hierarchischen Multimedia-On-Demand-Netzwerkes

Mögliches hierarchisches Netzwerk Modell für zukünftige Multimedia-On-Demand Services

2

Architektur eines hierarchischen Multimedia-On-Demand-Netzwerkes

In einem sind sich die Forscher der unterschiedlichsten Kommunikationsunternehmen schon heute einig, nämlich dass ein zukünftiges Multimedia-On-Demand Netzwerkmodell hierarchisch aufgebaut sein wird. Die Abbildung zeigt ein für die Zukunft mögliches Netzwerkmodell. In der Hierarchie an oberster Stelle steht ein Internationales Backbone Netzwerk. Über dieses sind die nationalen Backbone Netzwerke mit dem Multimedia-On-Demand Netzwerkmodell verbunden, die ihrerseits eine Verbindung zu den lokalen Backbone Netzwerken herstellen. Der einzelne Benutzer schließlich hat via Breitbandanschluss, wie er heute schon durch ADSL und Kabelfernsehen realisiert ist, Zugriff auf das Multimedia-On-Demand Netzwerk. In jeder Hierarchieebene sind Server integriert. Je höher die Ebene, desto höher sind die Ansprüche an die Server und desto notwendiger wird der Einsatz von Large Scale Storage Server.

Mögliches hierarchisches Netzwerk Modell für zukünftige Multimedia-On-Demand Services

Caching: Optimierung Bandbreite/Speicherplatz

1

Aufgabe von Caching Strategien

• Schonung von
  • Bandbreite
  • Speicherressourcen
• Caching Strategien entscheiden
  • welchen Daten wo und wie lange gecacht werden

Caching in einem hierarchischem Multimedia-On-Demand-Netzwerk

• Programme werden nach ihrer Aufrufwahrscheinlichkeit klassifiziert und gespeichert
  • Häufig angeforderte Programme
    • Caching - Es werden viele Kopien in untere Hierarchieebene abgelegt
      • Mäßiger Bandbreitebedarf
        • Einzelne Requests belasten nur einen kleinen Teil des Netzwerkes
      • Speicherbedarf ist sehr groß
        • Strategien müssen Speicherstatus regelmäßig aktualisieren
  • Selten angeforderte Programme
    • Es werden nur wenige Kopien in höhere Hierarchieebene gestellt
    • Geringer Speicherbedarf
    • Jeder Request belastet großen Teil des Netzwerkes
      • Da Requesthäufigkeit gering, bleibt auch durchschnittlicher Bandbreitenbedarf in kalkulierbaren Grenzen

2

Aufgabe von Caching Strategien

Zur Reduktion der benötigten Bandbreite und benötigtem Speicherbedarf können die in einem Multimedia-On-Demand Netzwerk zu erwarteten zeit- und ortsabhängigen Eigenschaften der Requests genützt werden. Ähnlich wie bei einem Telefonnetzwerk wird es auch in einem Multimedia-On-Demand Netzwerk Spitzenzeiten geben, an denen der Datentransfer überdurchschnittlich hoch ist. Auffallend dabei ist, dass sich in solchen Spitzenzeiten sehr viele Requests auf eine nur kleine Auswahl von unterschiedlichen Programmen beziehen (siehe dazu Lerneinheit Multimedia Server-Einführung und Grundlagen) . In Hinblick auf Schonung der Bandbreite ist es zweckmäßig, Kopien häufig gewünschter Programme auf verschiedene Server zu stellen, bezüglich optimale Nutzung vorhandener Speicherressourcen ist es notwendig, diese Kopien möglichst schnell wieder zu löschen.

Definition: Caching Strategien

Eine Entscheidung zu treffen, welche Programme (bzw. Teile davon) wann und für wie lange in welchem Cache Speicher zu laden sind, ist Aufgabe der so genannten Caching Strategien. Sie haben zum Ziel, vorhandene Speicherressourcen unter Einhaltung vorgegebener maximaler Netzwerkbandbreiten für eine optimale Netzwerkperformance zu nutzen.

Caching in einem hierarchischem Netzwerk

Häufig gewünschte Programme

Man erspart sich viel an redundanten Datentransfer, wenn Programme mit hoher statistischer Aufrufwahrscheinlichkeit bereits im Vorhinein auf die Speicherressourcen (Memories oder Storage Speicher) der Neighborhood Server geladen werden. Diesen Vorgang bezeichnet man als Caching. Fordern die Kunden nun massenweise diese Programme an, werden sie von ihrem jeweiligen Neighborhood Server bedient, höhere Hierarchienebenen des Netzwerkes bleiben von diesen Requests unberührt. Diese Strategie bewirkt eine enorme Entlastung der Netzbandbreite, erfordert allerdings ein Mehr an Speicherplatz. Wichtig ist daher nun, dass Caching Strategien die Inhalte der Cache Speicher laufend aktualisieren: Sind die momentan in den Cache Speicher abgelegten Programme nicht mehr so gefragt, werden sie durch entsprechend andere Programme ersetzt.

Selten gewünschte Programme

Programme, die weniger angefordert werden, werden auf Speicherressourcen von Servern in entsprechend höheren Hierarchieebenen gestellt. Es wird weniger Speicherplatz gebraucht, dafür erfordert jeder Request eine zusätzliche Belastung des Netzwerkes. Da solche Programme eben statistisch selten angefordert werden, halten sich die zusätzlich erforderten Bandbreiten aber in kalkulierbaren Grenzen. Welche Programme in welcher Hierarchieebene gestellt werden, wird von der jeweiligen Caching Strategie entschieden.

3

Aufgabe von Caching Strategien

Eine detaillierte Beschreibung der Aufgaben von Caching Strategien sind in der Lerneinheit Caching: Ziele und Charakterisierung nachzulesen.

Abrufen und Cachen von Programmen

1

Personal Service Agent (PSA)

• Personal Service Agent (PSA) soll Kunden bei Programmauswahl in Multimedia-On-Demand Netzwerken unterstützen
  • Aufgaben
    • Erstellung eines individuellen Bestellungsprofiles
    • PSA sucht passende Contentprovider
    • PSA listet geeignete Programme auf
    • Liste muss regelmäßig aktualisiert werden

PSA und Caching

• PSA kann mittels Caching Netzwerk entlasten
  • Funktionsweise
    • PSA cacht relevante Programme schon im Vorhinein auf Neighborhood Server
      • Geeigneter Zeitpunkt ist, wenn Netzwerk nur wenig belastet
      • Nachteil
        • Hoher Speicherbedarf
• Abhilfe zur Reduktion des Speicherbedarfs
  • Verschiedene PDAs tauschen sich untereinander aus
    • Es werden Kunden in Gruppen zusammengefasst, die zu ähnlicher Zeit mit gleichem Programm beliefert werden sollen
    • Caching Strategien versuchen nun
      • Möglichst viele Kunden mittels möglichst wenigen zu übertragenden Datenströmen zu bedienen
      • Für jeden Datenstrom möglichst kurz wenig Cache Speicherplatz zu beanspruchen

Beispiel: Kostenoptimierung mittels Caching in einem Ballungsgebiet

Rechnungsbeispiel für Multimedia-On-Demand in einem Ballungsgebiet: a) zentraler Server b) Zentraler und Neighborhoodserver c) Speicherplatz/Netzwerk trade-off

2

Personal Service Agent (PSA)

Um den Prozess der Programmauswahl dem Kunden zu erleichtern, könnte sich in zukünftigen Multimedia-On-Demand Netzwerken ein jedem Client persönlich zugewiesener Personal Service Agent (PSA) sehr bewähren. Der PSA hätte zu allererst die Aufgabe, ein Profil seines Kunden zu erstellen, welches Auskunft über dessen Bestellverhalten gibt. Mit Hilfe dieses Profils such dann der PSA die geeigneten Contentprovider, durchforstet regelmäßig deren Multimedia Datenbanken nach geeignetem Material und erstellt eine dem Kundenprofil entsprechende Programmauswahlliste, die fortwährend aktualisiert wird.

PSA und Caching

Zur Kosten und Ressourcen schonenden Nutzung des Netzwerkes kann nun der PSA die für seinen Kunden interessanten Programme schon im Vorhinein, und zwar zu Zeiten, wo das Netzwerk allgemein nur wenig belastet wird, auf entsprechenden Neighborhood Server cachen. Pferdefuß bei dieser Strategie sind allerdings die für den Kunden anfallenden hohen Speicherplatzkosten. Ein Ausweg aus dieser Misere besteht, indem sich die unterschiedlichen PSAs untereinander austauschen. Es wird untersucht, welche Kunden mit gleichen Programmen zu ähnlichen Zeiten beliefert werden sollen. Aus diesen Ergebnissen erarbeiten die betroffenen PSAs gemeinsam mit dem Contentprovider eine kostenoptimierte Programmübertragung. Dabei wird danach getrachtet, dass möglichst viele Kunden mittels möglichst wenigen zu übertragenden Datenströmen, die ihrerseits möglichst kurz auf nur wenig Speicherplatz gecacht werden, bedient werden.

Beispiel: Kostenoptimierung mittels Caching in einem Ballungsgebiet

Voraussetzungen

Für dieses Beispiel nehmen wir Folgendes als gegeben an:

1. Pro Übertragung des Programms fallen immer die gleichen Kosten an.
2. Speicherplatz wird umso teurer, je länger ein Programm im Cache Speicher liegt. Die Steilheit des Kostenanstieges hängt davon ab, welche Speicherplatzanforderungen das jeweilige Programm stellt.
3. Die Verzögerung zwischen dem Zeitpunkt, zu dem Server das Programm verschickt und dem, an dem Kunde es empfängt, ist vernachlässigbar gegenüber der Gesamtdauer des Programms.

Rechenbeispiel

Ein Programm wird um 1 Uhr nachmittags erstellt und auf dem zentralen Server S1 gespeichert. User 1 will nun gleich um eins das Programm gesendet bekommen. Um 2 Uhr will User 2 das gleiche Programm empfangen und um 11 Uhr abends schließlich User 3. Die Abbildung zeigt nun vergleichsweise die anlaufenden Kosten für zwei Fälle, und zwar einmal ohne, einmal mit Caching.

Zentrales Netzwerk ohne Caching

Abbildung a: Alle User interagieren direkt mit dem zentralen Server. Das Programm muss dreimal vom Server gesendet werden, und zwar um 1 Uhr, 2 Uhr nachmittags und 11Uhr abends. Eine Übertragung des Programms beläuft sich auf 18$, also ergeben sich Gesamtkosten von 54$.

Netzwerk mit Neighborhood Server als Caching Storage

Abbildung b: Hier sind zwischen den Usern und zentralem Server Neighborhoodserver geschaltet. Diese sollten in der Praxis an strategisch wichtigen Punkten, wie großen Wohnanlagen, Bibliotheken von Universitäten etc platziert werden. Die Neighborhoodserver fungieren als temporäre Cachespeicher für Programme, die in dieser Gegend gerne angefordert werden, und vermeiden so, dass für jeden Request eine teure Übertragung vom zentralen Server notwendig ist. In unserem Beispiel sind hier zwei Neighborhoodserver eingezeichnet. Um ein Uhr wird von User 1 das Programm angefordert. Ihm wird es vom zentralen Server S1 geschickt, was Kosten von 18$ entspricht. Der Datenstrom wird nun gleichzeitig in einen der beiden Server gecacht. Fordern nun User 1 und User 2 das Programm an, werden sie vom Neighborhoodserver beliefert. Die Leitung zum Zentralserver wird durch die beiden Requests nicht mehr belastet. In unserem Rechenbeispiel sind alle User über den Server 3 mit dem Netzwerk verbunden, wir haben daher das Programm auf Server 3 gecacht, es fallen somit durch die Requests 2 und 3 keine zusätzlichen Kosten an. Die Gesamtkosten betragen nur mehr 18$ und werden somit gedrittelt.

Rechnungsbeispiel für Multimedia-On-Demand in einem Ballungsgebiet: a) zentraler Server b) Zentraler und Neighborhoodserver c) Speicherplatz/Netzwerk trade-off

Speicherplatz/Netzwerk Trade-off

1

Beispiel: Speicherplatz/ Netzwerk Trade-off in einem Ballungsgebiet

Caching auf Server S2

Caching auf Server S3

Caching auf S2 und S3

Das Programm wird von 1 Uhr bis 11 Uhr abends auf Server 2 gecacht. Zusätzlich wird es von 1 Uhr bis 2 Uhr auf Server 3 gecacht.

2

auto

Bis jetzt haben wir nur die durch das Netzwerk verursachten Kosten in unsere Berechnung mit einbezogen. Für den sinnvollen Einsatz von Caching allerdings sind auch die Kosten der benötigten Speicherplätze zu berücksichtigen. Zur Kostenminimierung werden dann die anlaufenden Netzwerk- mit den Speicherkosten abgewogen. Server haben abhängig von ihren Performancemaßen wie Gleichzeitigkeit, Zugriffswartezeit auch unterschiedliche Kosten. Diese serverspezifischen Speicherkosten können mit $/Stunde angegeben werden.

Beispiel: Speicherplatz/ Netzwerk Trade-off in einem Ballungsgebiet

Wir betrachten wieder ein hierarchisches Netzwerk. In der Abbildung sind die Netzwerkkosten für die einmalige Übertragung eines Programms angegeben. Weiters sieht man für jeden Server dessen Speicherkosten. User 1 bestellt um 1Uhr das Programm, dieses wird ihm von Server 1 gesendet, die Kosten sind auch hier wieder 18$. Während der Übertragung wird das Programm in einen der Neighborhoodserver gecacht. Für den Server 2 als Cachingspeicher spricht, dass er gegenüber Server 3 günstigere Speicherkosten bietet, allerdings fallen für jeden Request zusätzliche Netzwerkosten von 8$ an. Es werden nun drei verschiedene Cachingvarianten in Bezug auf Kosten überprüft. Für die folgende Rechnung beachte man, dass das Programm 10 Stunden (User1 um 1 Uhr, User3 um 11 Uhr) gecacht werden muss.

Caching auf Server S2

Caching auf Server S3

Caching auf S2 und S3

Das Programm wird von 1 Uhr bis 11 Uhr abends auf Server 2 gecacht. Zusätzlich wird es von 1 Uhr bis 2 Uhr auf Server 3 gecacht.

Schlussfolgerung

Obwohl in diesem kleinen Beispiel nur drei Kunden mit einem einzigen Programm beliefert werden, sieht man schon hier, dass unterschiedliche Caching Strategien spürbare Kostenunterschiede verursachen. Effektive Caching Strategien sind daher für eine zufrieden stellende Performance eines Multimedia-On-Demand Netzwerkes von entscheidender Bedeutung.

Akronyme

ADSL - Asymmetric Digital Subscriber Line

HDTV – High Definition Televis i on

MOD – Multimedia on Demand

NVD – Near Video on Demand

PPV - Pay per View

PSA – Personal Service Agent

SONET - Synchronous Optical Network

TB - Terabytes (1024 Gigabytes)

Tbps – Terabit per second (1024 Gigabits per second)

TMOD – True-Multimedia-On-Demand

TVOD – True Video on Demand

VCR – Videocassette Recorder

VOD – Video on Demand