DCCP Datagram Congestion Control Protocol

Transkript

1 Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München DCCP Datagram Congestion Control Protocol Benjamin Peherstorfer betreut von Andreas Müller Blockseminar Future Internet WS 09/10

2 Inhalt Motivation und Einleitung Problembeschreibung DCCP Datagram Congestion Control Protocol Überblick Kernfunktionalitäten Staukontroll Mechanismen Eigenschaften und Einsatzzwecke Aktuelle Fragestellungen Ausblick und Zusammenfassung DCCP Datagram Congestion Control Protocol 2/20

3 Überblick Zwei dominierende Protokolle auf der Transportschicht TCP: verbindungsorientiert und zuverlässig UDP: verbindungslos und unzuverlässig Anwendungen wie z.b. VoIP verwenden oft UDP Mit UDP übertragene Datenmenge steigt stark an Eine Staukontrolle soll den Staukollaps verhindern Anwendungen und Staukontrolle verfolgen unterschiedliche Ziele Umstieg auf neues Protokoll soll einfach sein UDP Header (links) und TCP Header (rechts) DCCP Datagram Congestion Control Protocol 3/20

4 Einleitung Gründe warum Anwendungen UDP statt TCP verwenden früher (DNS, SNMP) Datenübertragung kann sofort beginnen (kein Startup Delay) Keine Angriffe wie SYN Flooding möglich (Zustandslosigkeit) heute (VoIP, Online Spiele) Daten (z.b. Video Frames) müssen innerhalb eines Zeitfensters beim Empfänger eintreffen, ansonsten sind sie nutzlos (timeliness) Erst beim Senden des Pakets ist Payload verfügbar Eigenschaften von UDP Datenflüssen heute Datenverlust spielt oft keine große Rolle Langlebiger Datenfluss, keine Request Response Verbindungen Große Mengen an Daten werden übertragen (z.b. Videostreaming) Konstante Übertragungsrate erwünscht Staukontrolle ist daher aus zwei Gründen nötig Staukollaps des Internets soll verhindert werden (vgl. TCP) Konstante Übertragungsrate kann nur aufrecht erhalten werden, wenn sich die Teilnehmer selbst beschränken DCCP Datagram Congestion Control Protocol 4/20

5 Anforderungen an die Staukontrolle Anwendung entscheidet beim Senden, welche Daten im Paket stehen char sendbuffer[100]; int status; do { f(sendbuffer); status = send(msockethandle, sendbuffer, 100, 0); } while((status<0)&&(errno == EAGAIN)); Wahlmöglichkeit zwischen verschiedenen Staukontroll Mechanismen Feature Negotiation um zuverlässig Parameter zu vereinbaren Unterstützung von Explicit Congestion Notification (ECN) Geringer Overhead DCCP Datagram Congestion Control Protocol 5/20

6 Wo Staukontrolle ansetzen Staukontrolle in der Anwendung Kann auf Anwendung abgestimmt werden Muss für jede Anwendung neu implementiert werden Unterstützung von ECN problematisch Staukontrolle unterhalb von UDP Man braucht einen Feedback Mechanismus Zwischen IP und UDP einen neuen Header einführen Probleme mit Socket API Staukontrolle auf der Transportschicht Anwendungen müssen wenig an ihrem Code ändern Unterhalb der Transportschicht muss nichts geändert werden DCCP Datagram Congestion Control Protocol 6/20

7 DCCP: Überblick Datagram Congestion Control Protocol (DCCP) im März 2006 in RFC 4340 vorgestellt Modularer Aufbau DCCP Kernfunktionalitäten werden in RFC 4340 beschrieben Staukontroll Mechanismen bauen auf Kernfunktionalitäten auf Datenübertragung mit DCCP Verbindung wird aufgebaut (Parameter ausgetauscht) Acknowledgement Framework informiert Sender über Status der gesendeten Pakete Staukontrolle überwacht mit diesen Informationen den Datentransfer DCCP Datagram Congestion Control Protocol 7/20

8 DCCP: Pakettypen und Verbindung DCCP unterscheidet 10 verschiedene Pakettypen Jeder Pakettype hat speziellen Header Overhead minimieren Eine Verbindung durchläuft drei Phasen DCCP Datagram Congestion Control Protocol 8/20

9 DCCP: Header Header eines DCCP Pakets besteht aus Generic und Packet Header Generic Header trägt jedes Paket (siehe Abb. unten) Packet Header ist für jeden Pakettyp unterschiedlich und erlaubt das Hinzufügen von zusätzlicher Information wie z.b. die Acknowledgement Nummer Generic Header DCCP Datagram Congestion Control Protocol 9/20

10 DCCP: Sequenznummern Sequenznummern zählen Datagramme (auch ACKs) Dadurch Aushandeln von Parametern während Verbindung möglich Verwendung von kurzen Sequenznummern möglich Statt 48 Bits werden nur 24 Bits gesendet Overhead minimieren Abwehr von Angriffen durch Sequence und Ack. Windows Während Verbindungsausfall gehen viele Pakete verloren DCCP weiß nicht mehr, ob neu ankommendes Paket gültig ist Synchronisation der Verbindung nötig DCCP Datagram Congestion Control Protocol 10/20

11 DCCP: Acknowledgement Framework Acknowledgement Nummer gibt die Sequenznummer des letzten angekommen Pakets an TCPs cumulative acknowledgements bei DCCP nicht sinnvoll Connection history kann nicht mehr anhand der Acknowledgement Nummer abgelesen werden Daher Acknowledgement Framework nötig Acknowledgement Framework Ack Ratio Feature NDP Count Option Data Dropped Option Ack Vector Option DCCP Datagram Congestion Control Protocol 11/20

12 DCCP: Ack Vector Option Gibt den Status der letzten Pakete an Received (00), Received ECN Marked (01), Not Yet Received (11) Aufbau der Ack Vector Option ? Länge SSLLLLLL SSLLLLLL Die Information über ein Paket A wird solange in den Ack Vektoren mitgeschickt, bis ein Paket mit Ack Vektor, welcher Paket A behandelt, vom Gegenüber bestätigt wird Ack Vektor kann widersprüchliche Information beinhalten Bestätigen von Acknowledgements nötig (acks of acks) DCCP Datagram Congestion Control Protocol 12/20

13 DCCP: Feature Negotiation Mechanismus um Parameter zuverlässig auszuhandeln Hinzufügen neuer Parameter einfach Realisierung über vier neue Optionen Change L, Change R, Confirm L, Confirm R Reconciliation Rules Server Priority Liste von Möglichkeiten wird gesendet. Gegenüber wählt eine Möglichkeit davon aus Non Negotiable Es wird ein Wert vereinbart. Ist der Wert gültig, muss er akzeptiert werden. DCCP Datagram Congestion Control Protocol 13/20

14 Staukontroll Mechanismen DCCP ist lediglich ein Framework für verschiedenste Staukontroll Mechanismen Jeder Staukontroll Mechanismus erhält einen congestion control identifier (CCID) Zusammenwirken von DCCP Kernfunktionalitäten und Staukontroll Mechanismus wird über das Staukontroll Profil festgelegt Verfügbare Staukontroll Mechanismen TCP like Congestion Control (CCID 2) TCP friendly Rate Control (CCID 3) TCP friendly Rate Control for Small Packets (CCID 4) DCCP Datagram Congestion Control Protocol 14/20

15 TCP like Congestion Control Versucht TCP Staukontrolle möglichst genau nachzubilden Schnelle Anpassung an neue Bandbreite Abrupte Änderungen der Bandbreite Additive Increase/Multiplicative Decrease (AIMD) Geeignet für Anwendungen wo Pufferung möglich Grober Ablauf In Slow Start Phase wird das Staufenster für jedes eingehende ACK verdoppelt In der Congestion Avoidance Phase wird das Staufenster nur noch linear vergrößert Fast Retransmit und Fast Recovery um Algorithmus zu verbessern Mit der Ack Vector Option kann SACK nachgebildet werden DCCP Datagram Congestion Control Protocol 15/20

16 TCP friendly Rate Control (TFRC) Abrupte Schwankungen der Bandbreite vermeiden Trotzdem faire Aufteilung der Bandbreite (auch mit TCP) Entwickelt für Anwendungen ohne Pufferung (z.b. VoIP) Grundlage ist die TCP Durchsatzgleichung Grober Ablauf Der Empfänger sendet die Loss Event Rate an den Sender Loss Event Rate entspricht Anzahl der verlorenen Pakete durch die Anzahl der gesendeten Pakete in einem gewissen Intervall Dieser setzt diese Rate und weitere Parameter in die Gleichung ein Sender ändert sein Verhalten dem Ergebnis entsprechend DCCP Datagram Congestion Control Protocol 16/20

17 TCP friendly Rate Control for Small Packets Bei VoIP werden viele kleine Pakete verschickt Empfänger braucht immer aktuelle Daten. Sender kann nicht warten bis genug Daten für ein großes Paket vorliegen Codecs liefern für kurze Audioabschnitte nur wenige Bytes an Daten TCP fasst solche kleinen Pakete einfach zusammen Bei vorgegebener Paketverlust Rate erreicht eine TCP Verbindung mit kleinen Segmenten einen geringeren Durchsatz (in Bytes pro Sekunde) als eine Verbindung mit großen Segmenten. Bei DCCP ist die Paketgröße jedoch durch die Anwendung vorgegeben Paketgröße fließt in die TCP Durchsatzgleichung mit ein Daher Verhalten wie TCP Verbindung mit kleinen Segmenten DCCP Datagram Congestion Control Protocol 17/20

18 TCP friendly Rate Control for Small Packets Vergleich von TCP (1460 Byte Segmente), TFRC (14 Byte Segmente, Anwendung sendet max. 12 kbps) und TFRC SP bei vorgegebener Paketverlust Rate. TFRC SP verwendet daher eine andere Paketgröße in der TCP Durchsatzgleichung DCCP Datagram Congestion Control Protocol 18/20

19 Ausblick DCCP noch nicht weit verbreitet Erste Implementierungen für Linux, FreeBSD und NetBSD Firewalls und NAPTs verstehen DCCP noch nicht Anwendungen setzen noch auf eigene Mechanismen (z.b. Skype) Staukontroll Mechanismen haben noch Probleme TFRC SP hat Probleme wenn man Bytes statt Pakete verwirft Um konstante Qualität von Videostreaming zu erreichen, muss sich die Übertragungsrate anpassen Wie mit Datenströmen umgehen, wo sehr schnell zwischen einer Pause und einer (hohen) Datenübertragung gewechselt wird? Wie soll Staukontrolle durchgesetzt werden Router bestrafen unkontrollierten Datenfluss (penalty boxes) DCCP Datagram Congestion Control Protocol 19/20

20 Zusammenfassung Staukontrolle auch für unzuverlässigen Datentransport nötig Vorteile von UDP nicht verlieren (timeliness over reliability) Anwendungen haben unterschiedliche Anforderungen an die Staukontrolle DCCP ist modular aufgebaut Kernfunktionalitäten bieten allgemeinen Feedback Mechanismus Staukontroll Mechanismen bauen darauf auf Hinzufügen von neuen Optionen oder Features ohne große Änderungen möglich DCCP verbindet das Konzept timeliness over reliability mit einer umfangreichen Staukontrolle DCCP Datagram Congestion Control Protocol 20/20

21 Quellen Folie 3: Folie 9: [3] Folie 18: [3] DCCP Datagram Congestion Control Protocol 21/20