Split-tcp: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
Line 2: Line 2:


=== Einführung ===
=== Einführung ===
Ein Konzept mit dem Datenübertragungsraten bei mobilen wireless Ad-Hoc Netzwerken verbessert
Ein Konzept mit dem Datenübertragungsraten bei mobilen wireless Ad-Hoc Netzwerken verbessert werden sollen. "Split-TCP" oder "TCP with proxies" wurde an der Universität von Kalifornien Riverside entwickelt und beschreibt die Möglichkeit mit einem neuen "Split-TCP" Protokoll die Effizienz bei mehreren gleichzeitigen Verbindungen zu verbessern und Problemen wie Verbindungsunterdrückung oder unnötigen Aufwand beim Finden einer neuen Route vorzubeugen besonders bei mobilen Netzwerkknoten. Es versteht sich als Weiterentwicklung von TCP. Grob gesehen funktioniert es so wie bei herkömmlichen Proxys. Das sind Zwischenstationen von denen IP-Pakete weiter zum Empfänger gesendet werden.

werden sollen. "Split-TCP" oder "TCP with proxies" wurde an der Universität von Kalifornien

Riverside entwickelt und beschreibt die Möglichkeit mit einem neuen "Split-TCP" Protokoll die

Effizienz bei mehreren gleichzeitigen Verbindungen zu verbessern und Problemen wie

Verbindungsunterdrückung oder unnötigen Aufwand beim Finden einer neuen Route vorzubeugen

besonders bei mobilen Netzwerkknoten. Es versteht sich als Weiterentwicklung von TCP. Grob

gesehen funktioniert es so wie bei herkömmlichen Proxys. Das sind Zwischenstationen von denen

IP-Pakete weiter zum Empfänger gesendet werden.


=== Funktionsweise ===
=== Funktionsweise ===
Das Protokoll schreibt vor, das nach einer bestimmten Anzahl von Hops (Verbindungsknoten im Ad-Hoc Netzwerk) ein Proxy sich um die Weitergabe des IP-Paketes kümmert. Der Transport Layer hat jetzt zwei getrennte Aufgaben: Stau Kontrolle und End-To-End-Flusskontrolle.
Das Protokoll schreibt vor, das nach einer bestimmten Anzahl von Hops (Verbindungsknoten im

Ad-Hoc Netzwerk) ein Proxy sich um die Weitergabe des IP-Paketes kümmert. Der Transport Layer

hat jetzt zwei getrennte Aufgaben: Stau Kontrolle und End-To-End-Flusskontrolle.


Die Staukontrolle ist Teil der End-to-End-Kontrolle. Die Datenrate muss somit angepasst sein.
Die Staukontrolle ist Teil der End-to-End-Kontrolle. Die Datenrate muss somit angepasst sein.
Line 27: Line 45:
# local congestion window speichert aufgestaute Packete
# local congestion window speichert aufgestaute Packete


Die Bestätigung (ACK) von Quelle zum Ziel ist eine End-2-End Kontrolle, die es so bei dem herkömmlichen TCP auch gibt. LACK Bestätigungen sind für die Stau Kontrolle.
Die Bestätigung (ACK) von Quelle zum Ziel ist eine End-2-End Kontrolle, die es so bei dem

herkömmlichen TCP auch gibt. LACK Bestätigungen sind für die Stau Kontrolle.




=== Probleme von TCP (herkömmlich) ===
=== Probleme von TCP (herkömmlich) ===
link capture effect:
link capture effect:
Die Knoten können die Bandbreite von Verbindungen "unfair" aufteilen. Wenn mehrere Verbindung durch einen Knoten gehen, wird die bevorzugt die:
Die Knoten können die Bandbreite von Verbindungen "unfair" aufteilen. Wenn mehrere Verbindung

durch einen Knoten gehen, wird die bevorzugt die:
* sich zuerst aufgebaut hat
* sich zuerst aufgebaut hat
* mehr Datenpakete durchschickt
* mehr Datenpakete durchschickt
* kürzeren Weg zur Quelle hat
* kürzeren Weg zur Quelle hat
Die Wirkung ist eine Unterdrückung von einer 2. Verbindung, die z.B. quer zur 1. Verbindung läuft. Die 2. Verbindung bleibt solange unterbrochen, bis die 1. weniger Datenpackete durchschickt.
Die Wirkung ist eine Unterdrückung von einer 2. Verbindung, die z.B. quer zur 1. Verbindung

läuft. Die 2. Verbindung bleibt solange unterbrochen, bis die 1. weniger Datenpackete

durchschickt.


=== Ursachen ===
=== Ursachen ===
# Mobilität von Knoten: Einzelne Knoten verlieren (auch für kurze Momente) die Verbindung. Dadurch sind lange TCP Sessions häufiger betroffen.
# Mobilität von Knoten: Einzelne Knoten verlieren (auch für kurze Momente) die Verbindung.

Dadurch sind lange TCP Sessions häufiger betroffen.
# Das MAC-Protokoll erzwingt die unfaire Aufteilung
# Das MAC-Protokoll erzwingt die unfaire Aufteilung


=== Effizienz von Split-TCP ===
=== Effizienz von Split-TCP ===
Es wird ein einer Studie von [1] gezeigt, dass es eine Verbesserung der Performance von rund 10-20 % gibt je nach Auslastung des Netzes und weiteren Faktoren.
Es wird ein einer Studie von [1] gezeigt, dass es eine Verbesserung der Performance von rund

10-20 % gibt je nach Auslastung des Netzes und weiteren Faktoren.


== Experiment ==
== Experiment ==
Versuchsbedingungen:
[[Image:P1vergleich.jpg]] Vergleich mit/ohne Split-TCP
- 50 Knoten auf 1 km x 1 km Fläche
- zufällige Wegewahl und Geschwindigkeit 0-10 m/s
- 3 bis 5 simultane Verbindungen

eine TCP Verbindung
[[Image:P1vergleich.GIF]] zeigt die Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 50 s gab

es eine kurze Verbindungsunterbrechung beim 2. Knoten. Bei Split-TCP sind die gespeicherten

Pakete vom Proxy und die neuen nach der Unterbrechung sofort übertragen worden.

konkurrierende TCP Verbindungen
[[Image:P2vergleich.GIF]] zeigt Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 250 s gab es

einen "link capture effect". Dadurch wartet die 1. Verbindung auf die 2. Verbingung.




=== Referenz ===
=== Referenz ===
[1] "Departmentof Computer Science and Engineering, University of California, Riverside, Riverside, CA,92521"
[1] "Departmentof Computer Science and Engineering, University of California, Riverside,

Riverside, CA,92521"

Revision as of 15:03, 15 November 2006

Split-TCP

Einführung

Ein Konzept mit dem Datenübertragungsraten bei mobilen wireless Ad-Hoc Netzwerken verbessert

werden sollen. "Split-TCP" oder "TCP with proxies" wurde an der Universität von Kalifornien

Riverside entwickelt und beschreibt die Möglichkeit mit einem neuen "Split-TCP" Protokoll die

Effizienz bei mehreren gleichzeitigen Verbindungen zu verbessern und Problemen wie

Verbindungsunterdrückung oder unnötigen Aufwand beim Finden einer neuen Route vorzubeugen

besonders bei mobilen Netzwerkknoten. Es versteht sich als Weiterentwicklung von TCP. Grob

gesehen funktioniert es so wie bei herkömmlichen Proxys. Das sind Zwischenstationen von denen

IP-Pakete weiter zum Empfänger gesendet werden.

Funktionsweise

Das Protokoll schreibt vor, das nach einer bestimmten Anzahl von Hops (Verbindungsknoten im

Ad-Hoc Netzwerk) ein Proxy sich um die Weitergabe des IP-Paketes kümmert. Der Transport Layer

hat jetzt zwei getrennte Aufgaben: Stau Kontrolle und End-To-End-Flusskontrolle.

Die Staukontrolle ist Teil der End-to-End-Kontrolle. Die Datenrate muss somit angepasst sein.

Die Regeln

  1. Paket wird über normale Hops wie beim TCP Protokoll weitergeleitet.
  2. Ein Hop wird zum Proxy, wenn IP-Paket schon bestimmte Anzahl Hops durchlief
  3. Ein Proxy ist nur für eine Verbindung Proxy, sonst gleichzeitig normaler Knoten (Hop)
  4. Ein Proxy schickt lokale Bestätigung (LACK) zurück an vorhergehenden Proxy oder Quelle.
  5. Der Proxy ist selbst dann für Weitergabe des Datenpaketes verantwortlich
  6. Die lokale Bestätigung (LACK) wird nur zum Nachbarproxy versendet, nicht weiter.
  7. Es wird noch eine Bestätigung (ACK) auf die gleiche Weise vom Ziel zur Quelle zurückversendet
  8. Das nächste Datenpacket wird mit gleicher Datenrate wie ankommendes LACK gesendet

LACK3 1.GIF

Regeln zum Puffer

  1. Datenpakete, von allen Verbindungen speichern, die noch nicht bestätigt sind.
  2. Bestätigungen ACK speichern und dann Kopien der Datenpakete löschen
  3. local congestion window speichert aufgestaute Packete

Die Bestätigung (ACK) von Quelle zum Ziel ist eine End-2-End Kontrolle, die es so bei dem

herkömmlichen TCP auch gibt. LACK Bestätigungen sind für die Stau Kontrolle.


Probleme von TCP (herkömmlich)

link capture effect: Die Knoten können die Bandbreite von Verbindungen "unfair" aufteilen. Wenn mehrere Verbindung

durch einen Knoten gehen, wird die bevorzugt die:

  • sich zuerst aufgebaut hat
  • mehr Datenpakete durchschickt
  • kürzeren Weg zur Quelle hat

Die Wirkung ist eine Unterdrückung von einer 2. Verbindung, die z.B. quer zur 1. Verbindung

läuft. Die 2. Verbindung bleibt solange unterbrochen, bis die 1. weniger Datenpackete

durchschickt.

Ursachen

  1. Mobilität von Knoten: Einzelne Knoten verlieren (auch für kurze Momente) die Verbindung.

Dadurch sind lange TCP Sessions häufiger betroffen.

  1. Das MAC-Protokoll erzwingt die unfaire Aufteilung

Effizienz von Split-TCP

Es wird ein einer Studie von [1] gezeigt, dass es eine Verbesserung der Performance von rund

10-20 % gibt je nach Auslastung des Netzes und weiteren Faktoren.

Experiment

Versuchsbedingungen: - 50 Knoten auf 1 km x 1 km Fläche - zufällige Wegewahl und Geschwindigkeit 0-10 m/s - 3 bis 5 simultane Verbindungen

eine TCP Verbindung File:P1vergleich.GIF zeigt die Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 50 s gab

es eine kurze Verbindungsunterbrechung beim 2. Knoten. Bei Split-TCP sind die gespeicherten

Pakete vom Proxy und die neuen nach der Unterbrechung sofort übertragen worden.

konkurrierende TCP Verbindungen File:P2vergleich.GIF zeigt Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 250 s gab es

einen "link capture effect". Dadurch wartet die 1. Verbindung auf die 2. Verbingung.


Referenz

[1] "Departmentof Computer Science and Engineering, University of California, Riverside,

Riverside, CA,92521"