Einleitungsvortrag zur Diplomarbeit

Transkript

1 Einleitungsvortrag zur Diplomarbeit Entwurf und simulative Bewertung eines Verfahrens zur Übertragung von Multimedia-Strömen über IP mit Ende-zu-Ende-Überlastabwehr Vortragender: Thomas Bachran

2 Aufbau des Vortrags Ergebnisse des Praktikums Aufbau des CORAL-Servers Implementierung zweier ECM-Module Messungen in Mobilfunk-ähnlichen Szenarien Probleme mit der TCP-Emulation Planung der Diplomarbeit Analyse der Praktikums-Ergebnisse Entwurf und Implementierung eines neuen ECM-Moduls Messungen zur Konfiguration von Modul- Parametern Messungen zur Leistungsbewertung des Verfahrens in Mobilfunk-Szenarien

3 Aufbau des CORAL-Servers Warum wurden nicht die alten Implementierungen wiederverwendet? Wesentliche Rahmenparameter zur neuen Konzeption des CORAL- Servers Module des CORAL-Servers Ideen zum Aufbau eines verteilten Servers

4 Aufbau des alten CORAL-Servers CORAL = Communication Protocols for Real-Time Access to Digital Libraries ECM = Endpoint-Congestion-Management

5 Warum ein neuer CORAL-Server? Unterschiedliche Implementierung aus unterschiedlichen Arbeiten Einige Module sind für eine Aufteilung des Servers auf mehrere Rechner ungünstig plaziert Andere Module sind als alleinstehende Module nicht notwendig und lassen sich besser als Teil eines anderen realisieren

6 Rahmenparameter für die Konzeption Inter- und Intra-Stream-Management muß klar getrennt sein für eine Aufteilung des Servers auf mehrere Rechner in einem Netzwerk Austauschbarkeit einzelner Module Erweiterbarkeit des Servers in Bezug auf neue Medientypen, neue ECM-, Layeringund QoS-Verfahren Einsetzbarkeit der Module in einem Realund einem ns2-simulations-szenario Vergleichbarkeit von Messungen

7 Module des CORAL-Servers Intra-Stream-Management Layering- Qos-Info Controls ECM Transport Media- Stream Feedback Application Streams Media-Stream RTCP RTP Server-Application Qos-Info ECM-Feedback Level-Info Media-Infos QoS- Management BW-Broker Border-Router Inter-Stream-Management Internet Client Client

8 Aufbau eines verteilten Servers (1) Daten liegen auf CORAL-Server- Komponente X CORAL- Main-Server Komponente irgendeine CORAL-Client- Komponente Video-Anfrage Internet Aufforderung: "Sende Daten" Daten werden gesendet - ggf. mehrere Ströme! CORAL-Server- Komponente X

9 Aufbau eines verteilten Servers (2) Internet Eine Hauptkomponente Hauptkomponente Serverkomponente Clientkomponente nimmt Verbindungsanfragen von Clients an erfährt von dem Trennen einer Verbindung durch eine Serverkomponente führt Abrechung für die übertragenen Mediendaten durch authentifiziert,

10 Aufbau eines verteilten Servers (3) Eine Serverkomponente baut auf Anweisung der Hauptkomponente eine Verbindung zum Client auf informiert bei Verbindungsabbruch die Hauptkomponente sendet Mediendaten an Clients Ein Client stellt die Anfrage nach Mediendaten an die Hauptkomponente beendet ggf. die Verbindung zur Server- Komponente Empfängt Mediendaten von Server- Komponente(n)

11 Implementierung zweier ECM-Module Jeder Datenverkehr erfolgt durch ein ECM-Modul DiffServ-Klassen AF und EF werden direkt an das Transportmodul weitergeleitet Für Best-Effort-Daten wird das Endpoint- Congestion-Management verwendet Zwei unterschiedliche Verfahren sind implementiert worden Ein Sender-Basiertes TCP-Emulationsverfahren ähnlich TFRC Ein Empfänger-Basiertes TCP- Emulationsverfahren ähnlich TEAR

12 Das Sender-Basierte-ECM-Modul (1) arbeitet wie TFRC mit der Senderaten- Formel zur TCP-Emulation von Padhye Einezelne Werte für die Parameter werden über RTP / RTCP bestimmt Einsatz von Sender- und Empfänger-Reports Aktualisierung durch Empfänger-Reports Empfänger-Reports werden als Reaktion auf Sender-Reports geschickt Sender-Reports werden alle 0.5 Sekunden verschickt

13 Das Sender-Basierte-ECM-Modul (2) RTT-Wert Bestimmung eines RTT-Wertes RTT = LSR DLSR t(empfang Receiver-Report) Bestimmung eines geglätteten RTT-Wertes (SRTT) SRTT = a * SRTT + (1 - a) * RTT (a = 7/8) Basis-Timeout-Wert T 0 T 0 = 4 * SRTT Anzahl der bestätigten Pakete pro Ack b = 2

14 Das Sender-Basierte-ECM-Modul (3) Fehlerrate p FractionLost von RTCP-Receiver-Report Anteil der verloren Pakete seit dem letzten Report Sample-Wert für Fehlerrate (LRSample) LRSample = Geglättete Fehlerrate SLR (entspricht p) SLR = a*slr + (1-a)*LRSample (a = 31/32) Ratenberechnung 1 (1 FractionLost) Pakete/ SRTT Pakete/ SRTT Bestimmung eines Wertes calcrate nach Padhye- Formel Glättung nach EWMA-Verfahren rate = a*rate + (1-a)*calcRate

15 Das Empfänger-Basierte-ECM-Modul (1) Arbeitet wie das TEAR-Verfahren mit der Emulation eines TCP-CWNDs auf Empfänger- Seite Daten werden über RTP/RTCP übertragen Die Bestimmung der RTT bzw. der SRTT erfolgt genauso wie beim Sender-basierten Modul Schicken der SRTT an Empfänger Berechnung der Senderate durch CWND/SRTT Glättung der Senderate durch eine Historie Schicken der Senderate an den Sender

16 Das Empfänger-Basierte-ECM-Modul (2) No Loss 1 neues Paket empfangen seqno > expectedseqno Alle Reordered -Pakete empfangen Loss-Event Gap 3 Dup-ACKs empfangen Fehlererkennung erfolgt in einem LossDetector- Modul ein LossEvent (entspricht TriDupAck) wird anhand des Automaten erkannt ein Timeout-Event tritt auf, falls eine Sequenznummern-Lücke entstanden ist, die Größer ist als ein CWND Ereignisse nicht ganz wie bei TCP!

17 Das Empfänger-Basierte-ECM-Modul (3) Berechnung des CWND anhand eines Automaten der auf Loss und Timeout Ereignisse der Fehlererkennung reagiert der versucht Slowstart und Congestion Avoidance nachzubilden Verwendung eines EWMA-geglätteten SASS- Wertes (Senders Averages Segment Size) anstatt eines SMSS-Wertes (Senders Maximum Segment Size) Berechnung erfolgt Runden-orientiert Eine Runde dauert so lange bis eine Datenmenge der Grösse CWND empfangen wurde

18 Das Empfänger-Basierte-ECM-Modul (4) Slow-Start cwnd < ssthresh Congestion- Avoidance 1 Paket empfangen Loss-Event 1 Paket empfangen Slow-Start- Ready Timeout- Event Timeout- Event Loss-Event Congestion- Avoidance- Ready Nach 1 RTT Nach 1 RTT Timeout Fast-Recovery

19 Das Empfänger-Basierte-ECM-Modul (5) Glättung der Senderate durch eine Historie der Länge L = 128 Gewichtung der ersten 64 mit 1 der restlichen 64 linear abfallend von 1 bis 0 Es werden in den Zuständen Slowstart und Congestion Avoidance bis zu 16 Runden in einen Historienwert zusammengefasst Treten Fehler auf, so wird ein neuer Historienwert angefangen

20 Messzenarien Allgemeiner Aufbau 10 Mbit-Referenz-Szenario TCP-Referenz-Szenario GPRS-ähnliche Szenarien UMTS-ähnliche Szenarien

21 Allgemeiner Aufbau RED-Queue 10Mbit /10ms Sender 1 MS Engpass (Funkverbindung) GGSN 10Mbit / 10ms Sender 2 Ziel: Verhalten zweier konkurrierender Ströme (ECM und TCP) auf einem Mobilfunk-Engpass RED Queue soll für unabhängige Paketverwürfe sorgen

22 Allgemeiner Aufbau Messungen wurden über einen kurzen Zeitraum (10 Minuten) und über einen langen Zeitraum (1 Stunde) gemacht Die Mittelung über Intervalle ist bei kurzen Messungen alle 5 Sekunden und bei langen Messungen alle 30 Sekunden erfolgt

23 10 Mbit-Referenz-Szenario Sender-basiertes ECM Empfänger-basiertes ECM Anderes Szenario: nur Sender- und Empfänger-Knoten 10Mbit Duplex, 10ms Delay grün: ECM-Modul, rot: TCP

24 TCP-Referenz-Szenario Entspricht einem UMTS-ähnlichen Szenario (später beschrieben) 2 TCP-Ströme konkurrieren TCP hat Probleme es kommen einige Timeouts vor (starke Einbrüche der Senderate)!

25 GPRS-ähnliche Szenarien (1) Sender-basiertes ECM Empfänger-basiertes ECM Engpass: 34/10 Kbit/s, 250ms Queue: 250 Pakete grün: ECM-Modul, rot: TCP

26 GPRS-ähnliche Szenarien (2) Senderbasiertes Verfahren erreicht keine Glättung der Rate => unbrauchbar! Höhere Glättung => gleichmäßigere Rate? Ist möglich (siehe Empfänger-Basiertes ECM) Aber: geringe Reaktionsfähigkeit auf Überlast (alte Werte noch von Bedeutung) Aber: Eine lange Startphase von fast einer Stunde ist unbrauchbar Aber: würde auch auf Veränderungen der Lastsituation nicht reagieren! Also: auch unbrauchbar!

27 UMTS-ähnliche Szenarien (1) Sender-basiertes ECM Empfänger-basiertes ECM Engpass: 384/128 Kbit/s, 250ms Queue: 250 Pakete -> Annahme!!! grün: ECM-Modul, rot: TCP Nur leicht besseres Verhalten als GPRS => unbrauchbar!

28 UMTS-ähnliche Szenarien (2) Sender-basiertes ECM Empfänger-basiertes ECM Engpass: 384/128 Kbit/s, 10ms Queue: 10 Pakete grün: ECM-Modul, rot: TCP

29 UMTS-ähnliche Szenarien (3)

30 UMTS-ähnliche Szenarien (4) Bei reduzierter Queue und bei reduziertem Delay ist die Startzeit des Sender-Basierten ECM-Moduls in Ordnung Die Startzeit des Empfänger-Basierten ECM- Moduls lässt sich über die Historienlänge anpassen! es kommt zu einer nahezu konstanten Senderate werden beide ECM-Module deutlich benachteiligt Weitere Messungen haben ergeben: Queue-Länge und Link-Delay sind beide für das Verhalten verantwortlich!

31 Probleme mit der TCP-Emulation Nicht für große Queues geeignet Nicht für große Link-Delays geeignet Glättung der Rate führt zu Verlust der Reaktionsfähigkeit bezüglich Überlastsituationen Längerer Startphase Grad der Fairness zwischen den ECM- Modulen und TCP hängt von der Bandbreite des Links ab

32 Ziele der Diplomarbeit Der Entwurf eines Verfahrens, welches die Probleme der TCP- Emulation in Mobilfunk-Szenarien behebt: Keine TCP-Emulation Schnellere Startphase Bessere Reaktionsfähigkeit evtl. bessere Glättung

33 Einteilung der Diplomarbeit in 4 Phasen Analyse der Praktikums-Ergebnisse Entwurf und Implementierung eines neuen ECM-Moduls Messungen zur Konfiguration von Modul-Parametern Messungen zur Leistungsbewertung des Verfahrens in Mobilfunk- Szenarien

34 Analyse der Praktikums-Ergebnisse (1) Rahmenparameter der Szenarien Link-Delays Link Bandwidth Link Errors Queue (Length, etc.) beeinflussen Beobachtbare Grössen RTT RTT PER PER gehen in Berechnung ein Zu errechnende Werte Senderate

38 Analyse der Praktikums-Ergebnisse (5) Rahmenparameter der Szenarien Link-Delays Link Bandwidth Queue (Length, etc.) beeinflussen Beobachtbare Grössen RTT RTT PER PER gehen in Berechnung ein Zu errechnende Werte Senderate

39 Entwurf eines neuen ECM-Moduls (1) Zwei Phasen Startphase dient der Ermittlung der zur Zeit möglichen Bandbreite (herantasten) zu Beginn kleiner Startwert für die Senderate erhöhen der Senderate in konstanten Zeitabständen Übertragungsphase möglichst konstante Senderate Erhöhen der Senderate nur bei kaum belasteten Netz (Schwellwerte) Möglichkeit die Aggresivität einzustellen Reduzieren bei Überlast (Schwellwerte) Prozentuale Anpassung der Senderate bei Schwellwertüber- bzw. unterschreitung

40 Entwurf eines neuen ECM-Moduls (2) Senderate Feedback- Paket mit RTT und Fehlerrate > 0 erhalten RTT / 2 Fiktiver Verlauf einer Senderate, ab der Überlast entstehen würde Wert vor RTT / 2 wird als Ergebnis der Startphase angenommen peridodischer Empfang von Feedback-Paketen mit RTT-Werten und Paketfehlerraten Beispielszenario für einen möglichen Verlauf der Startphase Zeit

41 Entwurf eines neuen ECM-Moduls (3) RTT Erhöhte Werte können für hohe Pufferfüllungen stehen Niedrige Werte können eine sich senkende Pufferfüllung stehen Neuer RTT-Wert Neuer RTT-Wert ausserhalb der Schwellwertgrenzen geglätteter RTT-Wert Schwellwerte (am geglätteten RTT-Wert orientiert) Schwellwerte (hier fiktive RTTs) Zeit

42 Messungen zur Konfiguration von Modul-Parametern (1) Rahmenparameter der Szenarien Link-Delays Link Bandwidth Queue (Length, etc.) beeinflussen Beobachtbare Grössen gehen in Berechnung ein RTT RTT PER PER Gewichtung??? Zu errechnende Werte Senderate

43 Messungen zur Konfiguration von Modul-Parametern (2) Bestimmung einer günstigen Gewichtung von RTT, PER und deren Abweichungen bei Über- und Unterschreitung der Schwellwerte zur Anpassung der Senderate Wahl der Schwellwerte selber konstanter Schwellwert? Prozentualer Zusammenhang (RTT + 10%)? eventuell funktionaler Zusammenhang zu dem Wert? Berücksichtigung von Anforderungen Gute Glättung Gute Reaktionsfähigkeit Faires Verhalten zu TCP (je nach Aggressivität)

44 Messungen zur Leistungsbewertung In welcher Hinsicht leistungfähig? Ausnutzung der verfügbaren Bandbreite Reaktionsfähigkeit auf Änderungen Glättung der Senderate Beurteilung der Fairness zu TCP Schwerpunkt: Verhalten in Mobilfunk-Szenarien Aber: Auch in LAN und Internetszenarien einsetzbar? Vergleiche mit den beiden ECM-Modulen aus dem Praktikum

45 Zeiteinteilung der Diplomarbeit 2. Phase 4. Phase 1. Phase 3. Phase Schreiben der Diplomarbeit Juni Juli August September Oktober November Dezember Zeitplanung 1.Phase: Analyse der Praktikums-Ergebnisse 2.Phase: Entwurf und Implementierung eines neuen ECM-Moduls 3.Phase: Messungen zur Konfiguration von Modul- Parametern 4.Phase: Messungen zur Leistungsbewertung des Verfahrens in Mobilfunk-Szenarien

46 Zusammenfassung Neu-Konzeption des CORAL-Servers wegen Erweiterungmöglichkeiten auf Mehr-Server-Szenarien TCP-Emulation ist nicht in Mobilfunk- Szenarien einsetzbar Ziel der Diplomarbeit ist die Entwicklung eines ECM-Moduls, welches auf TCP- Emulation verzichtet aber dennoch faires Verhalten zu TCP aufweist Dieses ECM-Modul soll Verbesserungen für Mobilfunk-Szenarien gegenüber der TCP-Emulation bringen