Split TCP - Revision history

Jaekel: /* Fazit */

2007-07-14T14:13:03Z

Fazit

← Older revision		Revision as of 14:13, 14 July 2007
Line 35:		Line 35:

	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.		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==

	[http://sar.informatik.hu-berlin.de/teaching/2007-s%20Ad-Hoc%20Networks%20(SE)/papers/kopparty02split.pdf kopparty02 (gesichert)]		[http://sar.informatik.hu-berlin.de/teaching/2007-s%20Ad-Hoc%20Networks%20(SE)/papers/kopparty02split.pdf kopparty02 (gesichert)]

Jaekel: /* Quellen */

2007-07-14T14:12:40Z

Quellen

← Older revision		Revision as of 14:12, 14 July 2007
Line 36:		Line 36:
	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.		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.

			[http://sar.informatik.hu-berlin.de/teaching/2007-s%20Ad-Hoc%20Networks%20(SE)/papers/kopparty02split.pdf kopparty02 (gesichert)]
	==Quellen==

Jaekel: /* Fazit */

2007-07-14T14:09:03Z

Fazit

← Older revision		Revision as of 14:09, 14 July 2007
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==

Jaekel: /* Experimentelle Ergebnisse */

2007-07-14T14:02:04Z

Experimentelle Ergebnisse

← Older revision		Revision as of 14:02, 14 July 2007
Line 19:		Line 19:
	: 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.		: 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'''		'''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.
	:
	{\|width="100%" border="1"\|		{\|width="100%" border="1"\|
	\|-		\|-

Jaekel: /* Experimentelle Ergebnisse */

2007-07-14T13:59:11Z

Experimentelle Ergebnisse

← Older revision		Revision as of 13:59, 14 July 2007
Line 16:		Line 16:

	==Experimentelle Ergebnisse==		==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'''
			:
	{\|width="100%" border="1"\|		{\|width="100%" border="1"\|
	\|-		\|-
	\|~~width~~="~~50%~~"\|		\|colspan="2"\|
	[[Image:diff.png\|thumb\|300px\|Variation of total packets received of a typical connection with time in a mobile ad hoc network]]		[[Image:diff.png\|thumb\|300px\|center\|Variation of total packets received of a typical connection with time in a mobile ad hoc network]]
		⚫	\|-
	\|width="50%"\|		\|width="50%"\|
	[[Image:2conn.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Regular]]		[[Image:2conn.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Regular]]
			\|width="50%"\|
⚫	\|-
		⚫	[[Image:2connb.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Split TCP]]
	\|colspan="2"\|
⚫	[[Image:2connb.png\|thumb\|300px~~\|center~~\|Individual throughputs of competing TCP sessions: Split TCP]]
	\|}		\|}

Jaekel: /* Experimentelle Ergebnisse */

2007-07-14T13:47:41Z

Experimentelle Ergebnisse

← Older revision		Revision as of 13:47, 14 July 2007
Line 16:		Line 16:

	==Experimentelle Ergebnisse==		==Experimentelle Ergebnisse==
			{\|width="100%" border="1"\|
			\|-
			\|width="50%"\|
	[[Image:diff.png\|thumb\|300px\|Variation of total packets received of a typical connection with time in a mobile ad hoc network]]		[[Image:diff.png\|thumb\|300px\|Variation of total packets received of a typical connection with time in a mobile ad hoc network]]
			\|width="50%"\|
	[[Image:2conn.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Regular]]		[[Image:2conn.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Regular]]
			\|-
⚫	[[Image:2connb.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Split TCP]]
			\|colspan="2"\|
		⚫	[[Image:2connb.png\|thumb\|300px\|center\|Individual throughputs of competing TCP sessions: Split TCP]]
			\|}

	==Fazit==		==Fazit==

Jaekel: /* Experimentelle Ergebnisse */

2007-07-14T13:43:42Z

Experimentelle Ergebnisse

← Older revision		Revision as of 13:43, 14 July 2007
Line 16:		Line 16:

	==Experimentelle Ergebnisse==		==Experimentelle Ergebnisse==
			[[Image:diff.png\|thumb\|300px\|Variation of total packets received of a typical connection with time in a mobile ad hoc network]]
			[[Image:2conn.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Regular]]
			[[Image:2connb.png\|thumb\|300px\|Individual throughputs of competing TCP sessions: Split TCP]]

	==Fazit==		==Fazit==
	==Quellen==		==Quellen==

Jaekel: /* Überblick */

2007-07-14T13:38:38Z

Überblick

← Older revision		Revision as of 13:38, 14 July 2007
Line 12:		Line 12:

	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.		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==		==Experimentelle Ergebnisse==

Jaekel: /* Überblick */

2007-07-14T13:32:44Z

Überblick

← Older revision		Revision as of 13:32, 14 July 2007
Line 10:		Line 10:

	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.		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.

	==Experimentelle Ergebnisse==		==Experimentelle Ergebnisse==

Jaekel: /* Überblick */

2007-07-14T13:27:21Z

Überblick

← Older revision		Revision as of 13:27, 14 July 2007
Line 8:		Line 8:

	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).		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.

	==Experimentelle Ergebnisse==		==Experimentelle Ergebnisse==