how-to block ads
|
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
| 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. | |
| | | |
|
·
·