Fast TCP story update
(old news - 04:00PM Thursday Jun 05 2003)
Ok I don't even have to look at the caltech papers to know that the "fast TCP" story being repeated in the news wires is being misrepresented, or, at least, not understood (by reporters) and therefore by readers. On the face of it, a non technical person reading the news snippets might think someone has found a way to make future broadband connections work at extremely high speeds, as though the problem this 'fast tcp' addresses was the only or main block to high speed service (and high speed video), when in fact, the main block to higher speed broadband than we have now is simple: infrastructure, economics and price. I've updated our mention on 'fast TCP', hopefully my cynicism over it will now show through: here.
|
 
TexasGuy
49 States And Texas
Premium
join:2002-12-02
Houston, TX | So? So? | |
|  | 
justin
Australian
join:1999-05-28
Brooklyn, NY | Re: So? said by TexasGuy  :
So?
and your question is? | |
| | | 
aztecnology
The Autumn wind is a Raider
join:2003-02-12
Murrieta, CA |  Re: So?
| |
| | | 
DSLTech
join:2000-12-30
San Jose, CA | Its not use to try and educate those who don't understand the technicalities of the transport layer.  | |
| | | |
TexasGuy
49 States And Texas
Premium
join:2002-12-02
Houston, TX
| Re: So? said by DSLTech :
Its not use to try and educate those who don't understand the technicalities of the transport layer.
That is it. I'm jumping off the bridge now. If only I had a a book on TCP/IP, then I wouldn't have to make such an extreme step.
--
Who drank has died, who drinks will die. Is he immortal who is sober? | |
| | FFK
join:2003-06-14
| What is the matter with you people?
The Tech docs on this subject clearly state that test were performed using existing equipment accross the internet!
This is short my friends means that there is only a change in the software that controls the TCP stack. As protocols under the GNU of the net are free and do not belong to anyone, where is the extra cost?
I rest my case.
Oh and the chap that wrote the artical these replies are to, you maybe should think about either doing your research more carefuly instead of plagurising other peoples work. | |
| 
UnKown
The Underground Network
join:2002-09-08
Orlando, FL | ok uhh so the only way its going to work faster is if we have the infrastructure to do it faster. ex. we would all have to be on an oc192 line all to ourselves for it too work. | |
| |
justin
Australian
join:1999-05-28
Brooklyn, NY | Re: ok of course.
but the reports on the research neglect to mention that vital point. | |
| | | markopoleo
join:2003-04-02
Bonne Terre, MO | Re: ok Thanks for clearing it up for people.  | |
| | | | | 
lazarus_
join:2002-08-31
Resolute, NU
edited
| Its nice to have those theoretical speeds, but what I want to know is if it say you have 1Mbit normal TCP and 1Mbit over "fast TCP" will it take up the same amount of resources on uBR's or will it take up less? (or maybe more)
If it takes up less resources that means ISP's would be able to use fast TCP to relieve congestion in congested areas w/ out hardware upgrades ;D Maybe they could raise from say the 6Mbits down (thats the fastest account my ISP offers) to 10Mbits down for customers and still have the same network stability! (that would be cool!)
[text was edited by author 2003-06-05 16:21:01] | |
| | |
DSLTech
join:2000-12-30
San Jose, CA
| Re: ok The way TCP works now is not optimal, since it was designed long ago on networks that were rather buggy and full of errors.
These days there are at least 3 points during network movement that a packet/frame/message is verified for errors or missing/out-of-order items.
What I understand of Fast TCP is that the only changes will be made at the Transport layer. What layers do routers, switches, etc work at? Well, Network(below TCP), Data-link (below Network) and wire. No changes will need to be made do these devices, only perhaps some changes to the far end systems at the sockets level or something. Software upgrades to end-systems and servers, and the programs/drivers that interface with them.
I dont see there being a huge upgrade in speed, however. If you take a look at the speed tests on this website, you'll notice a fat amount is "overhead". Instead of using UDP for streaming, we could use Fast TCP, and have a "reliable" transmission. Instead of sacrificing 15 to 30% for overhead, we could utilize that for actual data, and maybe only have 5% overhead.
Remember that all that "overhead" also includes lots of data that your system sends back to the other system to acknowledge receipt. If you have a program like UD Meter, you'll see when you dload a 100MB file, you've SENT them probably 5MB of acks and stuff.. actually i dont know the details on that but it uses your UPload bandwidth. And these days most upload bandwidth is pretty small. | |
| | | | | fgoldstein
join:2003-01-21
Newton Highlands, MA
| This is interesting stuff, but especially because it took them so long! I do recommend the chuvpilo paper; it is only 8 pages and quite readable.
We were doing this type of work back at DEC in the 1980s. DECnet Phase V, defined by 1986, had explicit congestion notification, which was used to tweak the TCP-equivalent protocol (TP4). I managed to get it added as an option in Frame Relay (the FECN bit), but it saw little use, especially because TCP had no way to use it, since IP didn't pass it through. Now we're finally seeing the IETF crowd running simulations very similar to the ones we ran at DEC about 15 years ago! And waddayaknow, they get similar results.
QuickStart, which Amit Jain and Sally Floyd are now proposing, is very similar to Fast Burst Reservation, which was first proposed in the ATM world in 1990 and then again around 1992. A good idea, if I can say so as the first inventor, but it is a little harder to do in a connectionless network like TCP/IP than in ATM. Again, old DEC ideas pop up long after being pooh-poohed as NIH.
Frankly the whold TCP/IP protocol stack is creaky and in need of replacement or major overhaul, but the inertia against that is huge. | |
| | | |
|
|
·
·
Re: TCP Koolaid