Split TCP: Difference between revisions
(→Fazit) |
|||
Line 32: | Line 32: | ||
==Fazit== |
==Fazit== |
||
Für nähere Informationen ist das sehr interessante Paper von u.a. S. Kopparty zu empfehlen. |
|||
Die Ergebnisse sprechen jedoch für sich. Der Durchsatz hat sich in allen Experimenten um 5% - 30% verbessert und die Fairness hat sich bei Verbindungen ohne Proxies von 0.47 auf 0.17 mit Proxies verbessert (Zur Berechnung der Fairness siehe Paper). SplitTCP hat sich bei einer normalen Link-Ausfall-Wahrscheinlichkeit sogar als recht robust erwiesen, da durch die zusätzlichen Quelle-Ziel-ACKs verlorene Pakete wiederhergestellt werden konnten. |
|||
==Quellen== |
==Quellen== |
Revision as of 14:09, 14 July 2007
Motivation
Steigende Leitungslängen führen zu steigenden Verbindungsabrüchen, durch höhere Wahrscheinlichkeit das sich ein Knoten aus der Reichweite eines Anderen bewegt. Das heisst, kürzere Verbindungen werden bevorteilt. Einerseits durch geringere Wahrscheinlichkeit eines Linkabbruchs, andererseits durch Möglichkeiten ihre Übertragungsgeschwindigkeit zu erhöhen (dadurch das sie zB ihre Übertragungsfenster schneller anpassen können). Weiterhin existiert durch das MAC-Layer der unschöne Effekt das bei zwei hochintensiven Verbindungen die leicht zeitversetzt starten, die erste die Leitung mehr oder weniger blockiert, bis Sie mit Ihrer Übertragung fertig ist. Dies auch bei längeren Verbindungen, da dort wiederum die kürzere von beiden zuerst zum Zuge kommt und ebenfalls den Kanal blockiert.
Die offensichtliche Lösung ist also die langen Verbindungen in mehrere Kurze zu zerteilen.
Überblick
Lange Verbindungen werden also nun in eigene lokale Gebiete geteilt. Dies geschieht indem wir einfach zB alle X Hops einen Knoten zum Proxy machen.Dadurch bilden sich immer zwischen zwei Proxies eine "Zone". Haben wir einmal eine Zone durchquert, brauchen wir, falls etwas passiert nicht mehr den kompletten Weg zurück gehen.
Kommt nun ein Paket bei solch einem Proxy an, wird es zwischengespeichert, ein Lokales Acknowledgement (LACK) an den Sender (letzter Proxy oder Quelle) geschickt und das Paket im Verhältnis zu der Rate der eingehenden LACKs weitergeschickt (an den nächsten Proxy oder das Ziel).
Dabei behält die Quelle jedoch die entsprechenden Pakete im Puffer bis Sie ein entsprechendes ACK vom Ziel bekommt. Damit bleibt die ursprüngliche Funktionalität erhalten.
Durch diese Herangehensweise wird nun quasi erreicht das wir eine Trennung zwischen Überlaufsteuerung und der Punkt-zu-Punkt-Verlässlichkeit erzeugen. Entsprechend dazu führen wir auch gleich zwei Sendefenster ein: das Überlaufsfenster und das PunktZuPunkt-Fenster. Das erstere ändert sich mit eintreffen der LACKs und letzteres mit den eintreffenden ACKs.
Weiterhin wird nun die Erscheinung des MAC-Captuer Effekts verringert. Durch die Teilung können nun immer nur einzelne Bereiche gleichzeitig blockiert sein, aber nicht komplette Leitungen, so dass konkurierende Übertragungen auch zum Zuge kommen.
Experimentelle Ergebnisse
1. Diagramm
- Besonders erwähnenswert ist der Bereich um 50-60s. Der Boost kam daher das ein Knoten aufgrund Mobilität ausfiel. Die Zone von der Quelle bis zum Proxy wurde zwar verlangsamt aber die gepufferten Pakete konnten vom Proxy zum Ziel trotzdem weitergeschickt werden - sogar mit einer erhöhten Rate da es nicht mehr zu Konkurenz mit dem Quelle-Proxyy-Segment kam.
2. und 3. Diagramm
- Hier sieht man die Verbesserung bezüglich des MAC-capture-Effekts. Im ersten Diagramm kann man gut erkennen, dass die zeitlich etwas spätere gestartete Verbindung im Prinzip keinen Durchsatz hat bis die erste Verbindung fertig ist. Im 2. Diagramm hingegen mit Split TCP können beide mit einer relativ gleichen und guten Rate senden.
Fazit
Für nähere Informationen ist das sehr interessante Paper von u.a. S. Kopparty zu empfehlen.
Die Ergebnisse sprechen jedoch für sich. Der Durchsatz hat sich in allen Experimenten um 5% - 30% verbessert und die Fairness hat sich bei Verbindungen ohne Proxies von 0.47 auf 0.17 mit Proxies verbessert (Zur Berechnung der Fairness siehe Paper). SplitTCP hat sich bei einer normalen Link-Ausfall-Wahrscheinlichkeit sogar als recht robust erwiesen, da durch die zusätzlichen Quelle-Ziel-ACKs verlorene Pakete wiederhergestellt werden konnten.