Split-tcp: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Split-TCP == |
== 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. |
|||
A protocol concept to improve Data transfer rates over mobile wireless Ad-Hoc networks. "Split-TCP" or "TCP with proxies" was developed at the University of California Riverside and describes the possibility to improve efficiency with more than 2 connections. It reduces the problems of suppression of connectivity and unnecessary efforts in finding new network routes. The protocol is understood as further development of the TCP network protocol. Generally it is a service with proxys installed in the network. |
|||
=== Funktionsweise === |
|||
Proxys: are network nodes, a connecting piece, which receive IP-packets from Source and deliver to the destination. |
|||
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. |
|||
=== current problems of TCP === |
|||
The nodes devide the data bandwidth into unfair pieces. If more than one connection is established at one node, then this connection is preferred, which: |
|||
# established first |
|||
# sends more data packets per second |
|||
# has a shorter way from source. |
|||
The effect is a suppression of the first connection, which is as long suppressed as the second one delivers packets and use the bandwidth. |
|||
| ⚫ | |||
=== How it works === |
|||
The protocol lays down a proxy after a certain number of hops (network nodes). |
|||
# 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 |
|||
| ⚫ | |||
# A packet through a hop is delivered like in a normal TCP-Packet |
|||
# A hop becomes a proxy, when the IP-Packet went through a certain number of hops |
|||
# A proxy is a proxy only for one connection. Even when it delivers IP-packet of a second connection, it behaves like a normal hop simultanously. |
|||
# A proxy sends a local acknowledgement (LACK) to the previous proxy or source. |
|||
# Another Acknowledgement (ACK) is sent from the destination to the source. |
|||
# Even the ACK needs a LACK every proxy. |
|||
[[Image:LACK3_1.GIF]] |
[[Image:LACK3_1.GIF]] |
||
''' |
'''Regeln zum Puffer''' |
||
# Datenpakete, von allen Verbindungen speichern, die noch nicht bestätigt sind. |
|||
# store every data packet of every connection until it is acknowledged with LACK |
|||
# Bestätigungen ACK speichern und dann Kopien der Datenpakete löschen |
|||
# every ACK until delivered. |
|||
# 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. |
|||
It was shown, that an improvement of 10% to 20% data transfer rate is possible. This number varies with different settings and data traffic. |
|||
== Experiment == |
|||
The Split-TCP protocol specially improves connectivity over network with high mobility.The last proxy connected to a fast mobile nod has to handle the situation, not the source far away. |
|||
[[Image:P1vergleich.jpg]] Vergleich mit/ohne Split-TCP |
|||
The fairness between TCP sessions is given by adjusting the bandwidth fastly. |
|||
=== |
=== Referenz === |
||
[1] |
[1] "Departmentof Computer Science and Engineering, University of California, Riverside, Riverside, CA,92521" |
||
Revision as of 21:13, 14 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
- 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
Vergleich mit/ohne Split-TCP
Referenz
[1] "Departmentof Computer Science and Engineering, University of California, Riverside, Riverside, CA,92521"