Split-tcp: Difference between revisions
mNo edit summary |
No edit summary |
||
Line 60: | Line 60: | ||
Die Wirkung ist eine Unterdrückung von einer 2. Verbindung, die z.B. quer zur 1. Verbindung |
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 |
läuft. Die 2. Verbindung bleibt solange unterbrochen, bis die 1. weniger Datenpackete durchschickt. |
||
durchschickt. |
|||
=== Ursachen === |
=== Ursachen === |
||
# Mobilität von Knoten: Einzelne Knoten verlieren (auch für kurze Momente) die Verbindung. |
# Mobilität von Knoten: Einzelne Knoten verlieren (auch für kurze Momente) die Verbindung. Dadurch sind lange TCP Sessions häufiger betroffen. |
||
Dadurch sind lange TCP Sessions häufiger betroffen. |
|||
# Das MAC-Protokoll erzwingt die unfaire Aufteilung |
# Das MAC-Protokoll erzwingt die unfaire Aufteilung |
||
Line 94: | Line 90: | ||
{| |
{| |
||
|[[Image:P2vergleich.jpg]] |
|[[Image:P2vergleich.jpg]] |
||
|zeigt Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 250 s gab es einen "link capture |
|zeigt Gesamtzahl empfangener Pakete im Zeitverlauf. Bei 250 s gab es einen "link capture effect". Dadurch wartet die 1. Verbindung auf die 2. Verbingung. |
||
effect". Dadurch wartet die 1. Verbindung auf die 2. Verbingung. |
|||
|} |
|} |
||
== Referenz == |
== Referenz == |
||
* [1] "Departmentof Computer Science and Engineering, University of California, Riverside, |
* [1] "Departmentof Computer Science and Engineering, University of California, Riverside, CA,92521" |
||
CA,92521" |
|||
* [[BerlinRoofNet|Berlin Roof Net]] |
* [[BerlinRoofNet|Berlin Roof Net]] |
Revision as of 17:40, 25 December 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
- Paket wird über normale Hops wie beim TCP Protokoll weitergeleitet.
- Ein Hop wird zum Proxy, wenn IP-Paket schon bestimmte Anzahl Hops durchlief
- Ein Proxy ist nur für eine Verbindung Proxy, sonst gleichzeitig normaler Knoten (Hop)
- Ein Proxy schickt lokale Bestätigung (LACK) zurück an vorhergehenden Proxy oder Quelle.
- Der Proxy ist selbst dann für Weitergabe des Datenpaketes verantwortlich
- Die lokale Bestätigung (LACK) wird nur zum Nachbarproxy versendet, nicht weiter.
- Es wird noch eine Bestätigung (ACK) auf die gleiche Weise vom Ziel zur Quelle zurückversendet
- Das nächste Datenpacket wird mit gleicher Datenrate wie ankommendes LACK gesendet
Regeln zum Puffer
- Datenpakete, von allen Verbindungen speichern, die noch nicht bestätigt sind.
- Bestätigungen ACK speichern und dann Kopien der Datenpakete löschen
- 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
- 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
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
konkurrierende TCP Verbindungen
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, CA,92521"
- Berlin Roof Net