TCP Performance in Wireless multi-hop Networks - Revision history

141.20.192.171: /* References */

2005-02-03T13:02:31Z

References

← Older revision		Revision as of 13:02, 3 February 2005
Line 284:		Line 284:

	== References ==		== References ==
			<i>
			[1] G. Holland and N. Vaidya, “Analysis of TCP Performance Over Mobile Ad-Hoc Networks”, IEEE/ACM MOBICOM, 1999

			[2] S. Kopparty, S. Krishnamurthy, M. Faloutsos and S. Tripathi, “Split-TCP for Mobile Ad-Hoc Networks”, 2002

			[3] H. Balakrishnan, V.N. Padmanabhan, S. Seshan and R.H. Katz, “A Comparison of Mechanisms for improving TCP Performance over wireless links”, IEEE/ACM Transactions on Networking, 1997

			[4] M. Gerla, K. Tang and R. Bagrodia, “TCP Performance in wireless multi-hop networks”, 1998

			[5] http://www.google.de
			</i>

141.20.192.171: /* Conclusion */

2005-02-03T12:49:49Z

Conclusion

← Older revision		Revision as of 12:49, 3 February 2005
Line 273:		Line 273:

	== Conclusion ==		== Conclusion ==
	TCP drops significantly when node movement causes link failures, because of TCP's inability to recognize the difference between link failure and congestion.~~<br><br>~~		TCP drops significantly when node movement causes link failures, because of TCP's inability to recognize the difference between link failure and congestion.

	The use of ELFN can improve the TCP performance significantly.~~<br><br>~~		The use of ELFN can improve the TCP performance significantly.

	There is a bad interaction between TCP and ARP (BSD-implementation, one-packet queue, no request time-out mechanism), because ARP drops packets regularly or holds them indefinitely while awaiting resolution, so a more advanced ARP needs to be employed.~~<br><br>~~		There is a bad interaction between TCP and ARP (BSD-implementation, one-packet queue, no request time-out mechanism), because ARP drops packets regularly or holds them indefinitely while awaiting resolution, so a more advanced ARP needs to be employed.

	As mentioned the route cache is another big problem, more aggressive cache management protocols are needed therefore.~~<br><br>~~		As mentioned the route cache is another big problem, more aggressive cache management protocols are needed therefore.

	Split-TCP can be seen as good step forward to improve wireless connections.		Split-TCP can be seen as good step forward to improve wireless connections.

141.20.192.171: /* Conclusion */

2005-02-03T12:39:16Z

Conclusion

← Older revision		Revision as of 12:39, 3 February 2005
Line 273:		Line 273:

	== Conclusion ==		== Conclusion ==
			TCP drops significantly when node movement causes link failures, because of TCP's inability to recognize the difference between link failure and congestion.<br><br>

			The use of ELFN can improve the TCP performance significantly.<br><br>

			There is a bad interaction between TCP and ARP (BSD-implementation, one-packet queue, no request time-out mechanism), because ARP drops packets regularly or holds them indefinitely while awaiting resolution, so a more advanced ARP needs to be employed.<br><br>

			As mentioned the route cache is another big problem, more aggressive cache management protocols are needed therefore.<br><br>

			Split-TCP can be seen as good step forward to improve wireless connections.

	== References ==		== References ==

141.20.192.171: /* Split-TCP */

2005-02-03T12:23:52Z

Split-TCP

← Older revision		Revision as of 12:23, 3 February 2005
Line 258:		Line 258:
	</td></tr>		</td></tr>
	</table>		</table>
		⚫	<font size=+1><b>Overall Result:</b></font>
	<table><tr><td>  </td>		<table><tr><td>  </td>
	<td>		<td>
⚫	<font size=+1><b>Overall Result:</b></font>
	<li>Split-TCP is able to deal better with problems of mobility – if one “zone” fails because of a broken link, then it is possible to sustain data transfer on other local segments (where a normal TCP session can be choked)		<li>Split-TCP is able to deal better with problems of mobility – if one “zone” fails because of a broken link, then it is possible to sustain data transfer on other local segments (where a normal TCP session can be choked)
	<li>Thus, Split-TCP takes advantage of the links that are up!		<li>Thus, Split-TCP takes advantage of the links that are up!

141.20.192.171: /* Split-TCP */

2005-02-03T12:23:20Z

Split-TCP

← Older revision		Revision as of 12:23, 3 February 2005
Line 256:		Line 256:
	<li>Correspondingly the transmission window is split into two windows: the congestion window and the end-to-end window, where the congestion window would always be a sub-window of the end-to-end window		<li>Correspondingly the transmission window is split into two windows: the congestion window and the end-to-end window, where the congestion window would always be a sub-window of the end-to-end window
	<li>At each proxy there would be a congestion window which would govern the rate of sending between proxies<br><br>		<li>At each proxy there would be a congestion window which would govern the rate of sending between proxies<br><br>
			</td></tr>
			</table>
			<table><tr><td>  </td>
			<td>
	<font size=+1><b>Overall Result:</b></font>		<font size=+1><b>Overall Result:</b></font>
	<li>Split-TCP is able to deal better with problems of mobility – if one “zone” fails because of a broken link, then it is possible to sustain data transfer on other local segments (where a normal TCP session can be choked)		<li>Split-TCP is able to deal better with problems of mobility – if one “zone” fails because of a broken link, then it is possible to sustain data transfer on other local segments (where a normal TCP session can be choked)

141.20.192.171: /* Split-TCP */

2005-02-03T12:21:39Z

Split-TCP

← Older revision		Revision as of 12:21, 3 February 2005
Line 255:		Line 255:
	<li>But the source only purges a packet from buffer on receipt of an ACK		<li>But the source only purges a packet from buffer on receipt of an ACK
	<li>Correspondingly the transmission window is split into two windows: the congestion window and the end-to-end window, where the congestion window would always be a sub-window of the end-to-end window		<li>Correspondingly the transmission window is split into two windows: the congestion window and the end-to-end window, where the congestion window would always be a sub-window of the end-to-end window
	<li>At each proxy there would be a congestion window which would govern the rate of sending between proxies		<li>At each proxy there would be a congestion window which would govern the rate of sending between proxies<br><br>
			<font size=+1><b>Overall Result:</b></font>

			<li>Split-TCP is able to deal better with problems of mobility – if one “zone” fails because of a broken link, then it is possible to sustain data transfer on other local segments (where a normal TCP session can be choked)
			<li>Thus, Split-TCP takes advantage of the links that are up!
			<li>Furthermore Split-TCP does improve the fairness between TCP sessions in a network, because now all sessions are of a short length
			<li>The channel capture effect is less detrimental, because only small regions are captured, not a whole connection
			<li>The total throughput improves with the use of proxies by about 5 to 30%
			<li>The unfairness decreases from 0.8 to 0.2 (1.0 being the maximum unfairness)

	</td></tr>		</td></tr>

141.20.192.171: /* Split-TCP */

2005-02-03T12:17:54Z

Split-TCP

← Older revision		Revision as of 12:17, 3 February 2005
Line 252:		Line 252:
	<li><b>Important point:</b> Congestion seems to be a local phenomenon, whereas reliability is an end-to-end requirement  splitting the transport layer functionalities into these both		<li><b>Important point:</b> Congestion seems to be a local phenomenon, whereas reliability is an end-to-end requirement  splitting the transport layer functionalities into these both

			<li>The source sends at a rate proportional to the rate of arrival of LACKS from the next proxy, the proxies themselves do so too
			<li>But the source only purges a packet from buffer on receipt of an ACK
			<li>Correspondingly the transmission window is split into two windows: the congestion window and the end-to-end window, where the congestion window would always be a sub-window of the end-to-end window
			<li>At each proxy there would be a congestion window which would govern the rate of sending between proxies

141.20.192.171: /* Split-TCP */

2005-02-03T10:59:05Z

Split-TCP

← Older revision		Revision as of 10:59, 3 February 2005
Line 241:		Line 241:

	<li>Examining the effect of splitting long TCP connections into shorter localized segments ("zones")		<li>Examining the effect of splitting long TCP connections into shorter localized segments ("zones")

			<li>Using proxies as interfacing agents between these zones

			<li>A proxy intercepts packets, buffers them, acknowledges their receipt to the source (or the previous proxy) by sending a local acknowledgement (LACK) and takes over the responsibility of delivering the packets further

			<li>Upon the receipt of a LACK (from the next proxy or final destination) a proxy will purge the packet from its buffer

			<li>Hereby the end-to-end acknowledgement of TCP is not changed (since the overhead of ACKS and LACKS is so small that it is said to be acceptable)

			<li><b>Important point:</b> Congestion seems to be a local phenomenon, whereas reliability is an end-to-end requirement  splitting the transport layer functionalities into these both

141.20.192.171: /* Split-TCP */

2005-02-03T09:39:55Z

Split-TCP

← Older revision		Revision as of 09:39, 3 February 2005
Line 235:		Line 235:

	<li>By introducing proxies shorter TCP connections are emulated == a better parallelism in the network is achieved, "unfair" advantages of short connections are minimized		<li>By introducing proxies shorter TCP connections are emulated == a better parallelism in the network is achieved, "unfair" advantages of short connections are minimized

			<li>Long connections are much more likely to freeze because they have more links and since short connections can transmit faster they can dominate shared links

			<li>The 802.11 MAC Protocol centuates the problems:<br>"Channel Capture Effect" (the first connection captures the channel until it has transmitted all its data)

			<li>Examining the effect of splitting long TCP connections into shorter localized segments ("zones")


	</td></tr>		</td></tr>

141.20.192.171: /* Split-TCP */

2005-02-03T09:28:47Z

Split-TCP

@@ Line 226: / Line 226: @@
 == Split-TCP ==
 == Conclusion ==
 == References ==