re: Is TCP Past It? dwdm2, if you're asking how to tune your TCP parameters to try and increase throughput, I can offer some advice. If you're running windows, you'll either need to add a new TCP_window REG_DWORD to your windows registry, or modify the existing one, this probably depends on the windows version you have, but I think it's in HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Tcpip Parameters
Check on microsoft's site to get the exact details. You can also set MTU size smaller (wouldn't go below 576 though) which may help if suspect you have high segment loss but I think that's set in the interface drivers section of your registry. Don't know about Linux, MAC I'm afraid. Good luck!
The 3Mbps that I got were with a vanilla, untweaked Windows '95.
Maybe you missed what I was saying: that until you reach the limits of BW*RTT window sizes with the enhanced windows option, then TCP as currently extended should be just fine. And even then, you can simply enlarge your windows further with another option.
Good discussion. As it seems to be the case, TCP can go up to 1 Mbps (per Mark's expt.). Tony mentioned he used to get upto 3 Mbps but now lot less. On my cable modem I have seen 200-300 kbps but often it is ~ 100 kbps. Gist: TCP can be optimized to get higher throughput than normally we get.
So one question: what is the maximum one can squeeze out of copper? I don't know much about tweaking TCP parameters. But folks who are guru in this area (you three certainly seem to be), perhaps can carry out an "unsponsored research" and find the optimum settings for maximum throughput for the benifit of all of us (don't keep it secret)!
Nevertheless, as many on this thread and elsewhere pointed out, TCP is going to run into problem to sustain higher speed. So for the next round of higher BW utilization an alternative seems to be unavoidable.
Good discussion. As it seems to be the case, TCP can go up to 1 Mbps (per Mark's expt.). Tony mentioned he used to get upto 3 Mbps but now lot less. On my cable modem I have seen 200-300 kbps but often it is ~ 100 kbps. Gist: TCP can be optimized to get higher throughput than normally we get.
So one question: what is the maximum one can squeeze out of copper? I don't know much about tweaking TCP parameters. But folks who are guru in this area (you three certainly seem to be), perhaps can carry out an "unsponsored research" and find the optimum settings for maximum throughput for the benifit of all of us (don't keep it secret)!
Nevertheless, as many on this thread and elsewhere pointed out, TCP is going to run into problem to sustain higher speed. So for the next round of higher BW utilization an alternative seems to be unavoidable.
>> On my cable modem I have seen 200-300 kbps but often it is ~ 100 kbps. <<
Just increasing your window size will probably get you better performance than current.
>> So one question: what is the maximum one can squeeze out of copper? <<
There is probably a really simple answer to this question, but it escapes me at present ;-)
There is probably some really neat algorithm someone could chuck in here to make your head spin which would give you the exact answer, but let me exercise stupidty and try and answer it a different way ;-)
The first lesson in life is to dispel yourself of the illusion that you have any control over your life - its the same with your TCP session ;-) There are (at least) three major contributors to the throughput you are going to achieve: the configuration of the server sending you stuff (for example the senders socket buffers), your own receive side windows, and the congestion window. You are only in control of two of the three.
You have no control over the send side in the Internet context, so just give up on that one ;-) And BTW, the sender can't configure one setting (socket buffers = 2*BW*delay, and send at 3*BW*delay) that works perfectly for every receiver (without measuring your individual RTT and making per socket adjustments, and of course the RTT wll change over the life of the session,...). If like me you often experience RTTs in the 200ms range (at worst, many times in the 130-170 range) then you should have your receive windows at about 25 Kbytes per 1 Mbps of download speed you have paid for from your provider (if you are using win2k the default is 16 Kbytes) - so you have some control over that. Then there is the congestion window. It is not uncommon on one of my broadband services to see 1% packet loss - which essentially means that every other receive window I am going to be entering slow start (of course depending on speed and MTU size).
So imagine a world where Tony has built you a PC with no performance problems, Tony has supplied the equipment for a network with no queuing delays, no routing transients, and no maintenance downtime, and the operator who purchased Tony's routers wanted to provide you this wonderful performance for $40 a month. Get everyone who sends you stuff to get their socket buffers properly configured, get your receive windows properly configured, and magic - you should be really cooking (relative to link speed minus protocol overhead) at that point.
My bottom line......I was using dial-up from my home for something like 10 years. I pay my $xx @ month, marvel at how networking technology, like computing technology, used to be the toys of the few, and are now becoming the toys of the many, and think to myself this is a pretty good deal.
The good thing about humans is that we are never satisfied (=> innovation/"progress"/growth/ambition/initiative). The bad thing about humans is that we are never satisfied ;-) At some point the pleasure becomes the addiction, we all have to know the difference.
I will probably address this point in a later post over the weekend, but the power of a technology is not always its state of perfection, but its state of interaction, i.e. how many other things are built on its success. Right tool, for the right job.
re: Is TCP Past It?So one question: what is the maximum one can squeeze out of copper? I don't know much about tweaking TCP parameters. But folks who are guru in this area (you three certainly seem to be), perhaps can carry out an "unsponsored research" and find the optimum settings for maximum throughput for the benifit of all of us (don't keep it secret)! ------------------- There are three factors involved:
1) Window size 2) the round-trip time to the destination 3) the amount of loss on the path
The tuning process is to repeatedly do ftp's to a remote destination increasing your TCP window size each time in 1k increments until the file-transfer performance reliably decreases. It should increase with bigger windows up to a point and then usually falls apart. Use a big file. The bigger the better.
During the testing, look (if you can) at retransmission by TCP (indicating lost packets), out of order packets and any strange statistics.
re: Is TCP Past It?ItGÇÖs a wrap GÇô Is TCP Past It
The thread started with GeoffGÇÖs interesting juxtaposition: GÇ£GǪmy view is this: Most users see adequate throughput from TCP applications todayGǪGǪThe ultimate solution to this problem is to replace TCP with something else GÇô TCPv2GÇ¥. Of course that is mangling what Geoff actually said, but seems like what people read.
Due to a technology hitch, a bad link, the entire report was not available for reading, so readers reacted to the intro. The first shot across the bough was jim_smith: GÇ£I suggest we use the word "retune" instead of "revamp", after having acknowledged some improvements can be made in dealing with lost acks and window sizes. Retune or revamp GÇô this was the early tenor of the debate. Sure, TCP can be improved, but lets not create a whole new working group, create a version 2, have every person and their dog throw in their wish list, and then 10 years later come out with something. Or more simply put by Tony Li: GÇ£The sky is NOT falling.GÇ¥
Skeptic followed up with thoughts on the omnipresence of these suggestions, the lack of merit to them, the benefit that could derive from increasing the MTU GÇô a none TCP issue, and the importance of common platforms accepting these changes.
Noting the potential impact, rainbowwarrior stated: GÇ£Sure I'd love to redesign TCP but I can't imagine any problem in the protocol compelling a change that would effect so many appsGÇ¥.
Then there was the issue of how many people are really impacted by these limitations. Snarfulent: GÇ£10Gbps throughput on a single TCP connection carried thousands of miles is a "specialty" application, as is TCP over very high latency links.GÇ¥
Yet another issue is can you separate a single protocol from its interaction with the environment around it: GÇ£All modes of networking are a package of interelated things. It is very hard to dissect and change one aspect, in a radical way, without resultant unintended/unknown consequences.GÇ¥ Tangentially echoed by SkepticGÇÖs comment: GÇ£- If you really have a 10Gbps real-time TCP application, its probably not a good idea for you to be pushing all that data through the public best-effort internet anyway.GÇ¥
Then there is the perception of how TCP might be performing by the way it is implemented - beowulf888: GÇ£BTW: I think the "world wide wait" example in your article has less to do with TCP's inefficencies than HTTP's haphazard way of requesting and sending blocks of data (which could be fixed by pipelining connections).GÇ¥
Am I the only one who sees the problem responded Geoff: GÇ£But the point is that we add a zero onto the end of Ethernet performance every 4 years. What's "speciality" today will be "power user" in 4 years, "mainstream business" in 8 and a "universal requirement" in 12.GÇ¥ At this larger MTU stuff aint necessarily going to make it: GÇ£Imagine large MTU traffic sharing a connection with VoIP!GÇ¥. Sure change the behavior of your TCP stack and fix the problem says Geoff: GÇ£Sure, if you're a Linux hacker.GÇ¥ But what about the joe-average consumer out there (to which Skeptic replied GÇô get the OS vendors to fix the problem, it is not a standards problem); and yeah, lets do incremental optimizations, but: GÇ£I can imagine a similar set of kludges happening to TCP - with a mishmash of implementations co-residing out there for years. What will the performance impact of large window TCPs be on small window TCP streams? Or of big MTUs on small MTU streams?GÇ¥ And before we leave the issue of MTU, a couple of readers piped in with the fact that legacy access speeds is going to hold back this change.
But we donGÇÖt have to use TCP for everything, thatGÇÖs the beauty of this system. We donGÇÖt need some standards body to tell us how to design new solutions for interesting problems. Alchemy: GÇ£Sadly, anyone trying to push serious amounts of payload through the internet is running over UDP and rolling their own transport protocol.GÇ¥ WeGÇÖll just use UDP thank you very much. Of course, if you really want to fix the problem, just throw money at it - mordecai: GÇ£ When you have loss, it's bad. Loss comes from oversubscription. Oversubscription is needed to squeeze dollars out of it. You want better performance? Private network $$$.GÇ¥ Well perhaps not says Geoff: GÇ£If you placed two computers back to back, with their own, private fibre they would see this problem too - provided they exceed the BDP (which is the real point of the discussion).GÇ¥ In response to which we all benefited from a tutorial on the limitations of end system architectures. But packet loss and RTT as the culprits would be reoccurring themes.
The issue of resistance to change was mentioned a couple of times. Sometimes simply in observation of the value people have locked in to this technology, sometimes due to other motivations. But this is the same for all widely implemented technologies. Talking about doing something better rarely causes the change. Actually doing it and making it available is what leads to change (most often).
The overall conundrum/concerns was perhaps best summarized by dcpalter: GÇ£The issues that Geoff raises are real, but only for a small set of users, at least at the current time. TCP provides sub-optimal performance for high bandwidth-delay product links, high bit error rate links, highly asymmetric bandwidth links, and variable delay links. Alternative protocols, including a modified TCP can provide better performance under those conditions, but are not compatible with current applications and depending on the algorithm, can degrade performance under more typical conditions or introduce instability in the network.GÇ¥
In accepting the inevitable, advise on how to best tune links was asked, to which Skeptic replied: GÇ£The tuning process is to repeatedly do ftp's to a remote destination increasing your TCP window size each time in 1k increments until the file-transfer performance reliably decreases. It should increase with bigger windows up to a point and then usually falls apart. Use a big file. The bigger the better. During the testing, look (if you can) at retransmission by TCP (indicating lost packets), out of order packets and any strange statistics.GÇ¥ Mark having previously advised to do what you can but accept that you are not in control of all the variables, and there may be a general optimization you can make.
In summary
-The point assertion that most people will be meaningfully impacted by TCPGÇÖs limitations did not reach consensus. As a result, there seemed to be general consensus that for most peopleGÇÖs purposes, a tweak here and a tweak there should do. Those people with special needs should roll their own. -There was unresolved concern about what would happen to the overall performance of the Internet if TCP did become super efficient, with changes to conventional congestion management practices. What if every user on the net started running like this, what would be the result? -Is this really a problem that is a standards issue, or is it a matter of beating on OS vendors to get their implementations up to snuff? -TCP definitely can be improved, but that doesnGÇÖt mean the sky is falling, or will fall. -Most people could benefit by tuning their existing implementation. There is a simple procedure for a specific application: measure RTT, and make window changes as necessary. But what about the general case, and the general user? This comes back to some smarter/better/more automated implementations. -No flag days please. There is a lot riding on current TCP implementations. A very compelling case needs to be made to throw this away and start again. -TCP cannot be separated from the network itself. A few people noted the impact of loss, packet reordering, or delay on TCPGÇÖs performance, and the performance of any (sliding window) protocol that desires to be its replacement. -There are simple optimizations that can be performed that produce meaningful results. Beyond that, you are sharing an autobahn with a lot of crazy other drivers. Driver beware. -Sometimes pursuing the 80/20 rule is better than taking on the burden, unintended consequences, and complextion of seeking a higher standard. Something that works, evolves, and provides a foundation for others to build on, often succeeds in the market place. As always though, right tool for the right job.
re: Is TCP Past It?Very interesting reality check from someone who does it for a living!. Do you know if there is any concensus amongst the TCP offload engine manufacturers about how much memory they commonly build into their systems and whether they attempt to auto-tune themselves to set up the optimum window and buffer sizes?
re: Is TCP Past It?In the article: http://www.lightreading.com/do... reference is made to an Internet2 "about 2 Gbit/s" network speed record.
The assumption is made that "...it’s quite likely that this test was done with a UDP application, not TCP" and based on this assumption it is further stated that since "it looks as if rewriting applications to use UDP isn’t on the agenda" the solution put forward is "to change TCP altogether".
I would like to point out that although Henry Ford set a land speed record of 91.37 mph with his Ford Arrow across a frozen lake in 1904 and more recently Andy Green broke the sound barrier traveling across an equally unobstructed Desert (averaging 763 mph), I still can't get to work in commuter trafic any faster.
Increasing the horsepower under the hood of my car (or installing jet engines) doesn't benefit me any once I leave my garage. New tires, Teflon grease on the axle, Nitro... nothing seems to help once I get behind a traffic jam.
The assumption that these "Internet2" high speed records were set using UDP, not TCP appears to be in error. According to the internet2 website:
"26 June 2003 Next Generation Internet Protocol Marks Shattered in Internet2 Land Speed Record Competition"
This reference states plainly that "The new records were set... using a standard Linux TCP implementation."
The most demanding application I can think of that the typical home user might require would be streaming mutimedia. As the article points out, the new record for a single steam TCP connection is equivalent to "approximately one feature-length DVD-quality movie every 36 seconds, or more than 3,500 times faster than the typical home broadband connection."
Clearly the fault is not with TCP which simply dumps packets onto the network at a rate that the network can reasonably handle before routers, switches, gateways, end systems or whatever jam up with cross traffic, buffer overruns etc. and start discarding packets. TCP does a fair job of detecting network congestion and makes adjustments accordingly, If it didn't the entire network would come to a quick standstill as the time delays at a congested router grow exponentially once packet loss begins to occur. If TCP did not back off but continued sending packets at full capcity network routers would quickly choke and like in any traffic jam on the highway, internet traffic would come to a standstill.
Contrary to the idea that TCP needs to be replaced, these new speed records seem to prove that with a network equivalent of the Bonneville Salt Flats "Standard" TCP can deliver at speeds "3,500 times faster" than what your typical end system "broadband connection" could utilize.
dwdm2, if you're asking how to tune your TCP parameters to try and increase throughput, I can offer some advice. If you're running windows, you'll either need to add a new TCP_window REG_DWORD to your windows registry, or modify the existing one, this probably depends on the windows version you have, but I think it's in
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
Tcpip
Parameters
Check on microsoft's site to get the exact details. You can also set MTU size smaller (wouldn't go below 576 though) which may help if suspect you have high segment loss but I think that's set in the interface drivers section of your registry. Don't know about Linux, MAC I'm afraid. Good luck!