Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
Thanks for sharing your test results Kevin. Most interesting. I am setting up a small test lab of a couple linux boxes myself to learn more about the various traffic shaping and TCP stack options. Ill post my results here. I am primarily interested in local wireless network performance optimization vs long haul connects at least for now. It would be interesting to see how the numbers change with a windows or linux box on one end and BSD on the other. Also how did you simulate packet loss? Sent via BlackBerry from T-Mobile
On Mon, 7 Apr 2008, charles@thewybles.com wrote:
Thanks for sharing your test results Kevin. Most interesting. I am setting up a small test lab of a couple linux boxes myself to learn more about the various traffic shaping and TCP stack options.
Ill post my results here. I am primarily interested in local wireless network performance optimization vs long haul connects at least for now.
Anyone out there attend this event? The Future of TCP: Train-wreck or Evolution? http://yuba.stanford.edu/trainwreck/agenda.html how did the demos go? - Lucy
It would be interesting to see how the numbers change with a windows or linux box on one end and BSD on the other.
Also how did you simulate packet loss?
Sent via BlackBerry from T-Mobile
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 7, 2008, at 8:36 AM, Lucy Lynch wrote:
Anyone out there attend this event?
The Future of TCP: Train-wreck or Evolution? http://yuba.stanford.edu/trainwreck/agenda.html
how did the demos go?
The researchers demonstrated four things that made sense to me: (1) TCP is not the right transport for carrying video data if what you want is real-time delivery. Carrying stored video (YouTube-style) is fine, but if you're trying to watch TV, you really should be using some other transport such as RTP or DCCP. Same comment holds for sensor traffic, but the astronomers who carry radiotelescope data halfway around the world weren't present. (2) TCP is probably not the right protocol for carrying transaction traffic within a data center. One speculates that SCTP (which has a concept of a stream of TCP-like "transactions" that can be handled out of order and allows for congestion management both within and among transactions) might be a better protocol, and in any event that when thousands of transactions back up in a gigabit Ethernet chip's queue on a host that the host should start noticing that they are experiencing congestion. (3) 802.11 networks experience not only the traditional congestion experienced in wired networks, but channel access congestion (true of shared media in general) and radio interference. In such networks, it may be useful to think about congestion as happening "in a region" as opposed to "at a bottleneck". (4) When it is pointed out that instead of complaining about TCP in cases where it is the wrong protocol it may be more useful to use the transport designed for the purpose, researchers who presumably are expert on matters in the transport layer respond in complete surprise. -----BEGIN PGP SIGNATURE----- iD8DBQFH+klNbjEdbHIsm0MRAlLhAKCDprgXaKYukFG57KRsRS8HyGAUHgCgyRLd SpNahEUbZudgcoc3bMz/Cto= =hnGa -----END PGP SIGNATURE-----
On 7 apr 2008, at 18:18, Fred Baker wrote:
(4) When it is pointed out that instead of complaining about TCP in cases where it is the wrong protocol it may be more useful to use the transport designed for the purpose, researchers who presumably are expert on matters in the transport layer respond in complete surprise.
There is of course the issue of migrating from one transport to another with NATs and firewalls thrown in for good measure, which is worse than migrating to IPv6 in some ways and only significantly better in one (no need to upgrade routers).
participants (4)
-
charles＠thewybles.com -
Fred Baker -
Iljitsch van Beijnum -
Lucy Lynch