Slashdot Mirror
Fast TCP To Increase Speed Of File Transfers?
Wrighter writes "There's a new story at Yahoo about a new version of TCP called Fast TCP that might help increase the speed of file transfers. Sounds like it basically estimates the maximum efficient speed of your network, and then goes for it, dumping a lot of time-consuming error checking." There's also an article at the New Scientist with some additional information.
Faster pr0n!!!!
Let's see. Transmission without error-checking is called UDP, isn't it?
Yeah, that pesky error checking will get you every time....
This would be badass when combined with BitTorrent!
THERE IS NO DATA. THERE IS O
SmartTCP. It sounds like equipment is constantly tweaking the connection for the optimum through put.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Why not just number all packets between two hosts and if the recipient doesn't recieve a packet it requests that particular packet to be resent? I see problems with man in the middle attacks but is there any other reason?
just wondering
This is interesting, but is it realiable? I'd rather take rsync any day even if it happens to be slower, as long as it's sturdier.
I remember back in my BBS days what a big deal zmodem was when it started getting used all over the place. As I recall, it changed the block size that you would receive dynamically based on line quality.
So when you sent a block of 2k and got no errors, the frame size increased to 4k...8k... etc etc... Sounds like a similar approach.
Case
P.S. That was a long time ago in a FidoNet far far away, so my terms may be off.
Back in the "modern BBS" days, post-Xmodem, you had 3 real choices in file transfer. You had Zmodem, the traditional standard, which used 1K blocks and ZedZap which had 8K blocks, and both had error correction. But then, you also had Ymodem-G, which used 1K blocks, but relied on modem/hardware error correction. The result was the savings of a few bytes per second, which, back then, added up rather quickly.
"Caltech is already in talks with Microsoft and Disney about using it for video on demand," the magazine added. "Hey! Let's take a technology that's potentially revolutionary, and give it to Microsoft!" Yay for Caltech!
speed or accuracy..either one...
Isn't estimating the effective bandwidth of the link exactly what tcp window is all about?
I read the article and did not understand what do thay add that is better then the standerd tcp enhancements of selective ack and big window sizes.
clue anyone?
As of Postgres v6.2, time travel is no longer supported.
might as well just use TFTP over UDP.
Do you even lift?
These aren't the 'roids you're looking for.
I'm sorry, but without further technical details, this sounds like the sort of technical mumbo-jumbo that snake-oil salesmen were peddling back in the dot-com era.
See this earlier Slashdot story.
Dude... It's Yahoo. You can't /. Yahoo.
Who needs erro>*H~@}&)aA=cking anyway?
That's not a soda... it's a caffeine delivery device!
You people are giving me a headache. There is no mention about the removal of error checking. Actually, the article is lite on any technical details, but you can divine what they are doing well enough. Basically, it seems they keep tweaking mtu rwin, ect until they get the best connection they can.
This isn't revolutionary so much as evolutionary.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Looking at the information on their web page at caltech, the FAST network project is working with alternate TCP window sizing schemes.
Namely, instead of reducing window size in the case of packet loss, window size is changed based on round trip latency. The problem being that reducing the window size in response to loss works well on most networks, but has a serious problem when dealing with very high-bandwidth links.
In such a case, the conventional TCP windowing will shrink greatly in response to even one or two lost packets, which when you are sending a LOT of data, will occur.
The real work (and it seems to be somewhat covered in their web pages) is how to use latency for congestion detection/control, but I haven't read it in enough detail to quite understand this, NOR how this scheme will interact with conventional TCP streams.
Test your net with Netalyzr
Hmm, just think how much faster IIS can get infected with this one!
My sausage tree didn't grow, does that make me a bad mommy?
We already have something like this. It's called "UDP" and it's TCP without error checking. Sounds like they just thought of a different way to do TCP that they feel is faster.
Claims like a movie being downloaded in mere seconds are nonsense though. No matter what method you intend to send a gigabyte file it's still a gigabyte file you can't somehow magically upgrade the quality of broadband with a new protocol.
...will Fast TCP have the Evil Bit?
...support gets added to FreeBSD 4.x ASAP. This sounds like just what my server needs!
"When the researchers tested 10 Fast TCP systems together it boosted the speed to more than 6,000 times the capacity of the ordinary broadband links.
6,000 times? The tests done in labs are usually stripped-down and the results overstated just for statistical pleasure. In the real world, however, such figures are rarely achieved.
or you could also call it ReverseDoS..
or Self-Slashdotting! :-)
Measuring the round-trip time for packets and using this to information to predict the bandwidth delay product is nothing new. This is essentially one of the effects achieved with existing TCP congestion control algorithms such as TCP Tahoe, TCP Vegas and TCP Reno. The article is light on details and doesn't lead me to believe that they've done anything signicantly different from these three. Furthermore, if it *is* doing something different, how can it still obey the existing congestion control algorithms without thrashing? After all, we can all boost the speed of our TCP connections by simply turning off congestion control, as long as nobody else does it either. ;) [UDP's lack of congestion control is precisely why a few streaming video users can clog up an entire pipe for themselves, screwing everyone else who's using it.]
Does that mean TCP has 99.99% (humor me) overhead ?
But seriously, you can probably use large windows to send streams of packets such that a single ack is required for a bunch of them, but it's impossible to achieve 6000x more throughput just by "optimizing" the TCP protocol. Even over Internet (I'm not even talking LANs since there is obviously not that much room for improvement due to the low latency).
It's called congestion collapse and the condition is described by RFC 896 by John Nagle.
Just firing packets into the network willy-nilly is very bad; it's the "tragedy of the commons" all over again...
This protocol figures out ahead of time if it needs to slow down so its always getting acks back instead of waiting for timeouts. Also it avoids the binary backoff time that happens with timeouts.
So in response to many of the previous posts it loses none of the robustness of TCP. In the worst case its as slow as TCP and in the best case it should be equally as fast as TCP. In the average case, however, it shows a huge performance increase. Most of the time on the network is the average case so this is a good thing.
"You can now flame me, I am full of love,"
Looks like this this
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.
We substituted the coffee Slashdot normally drinks with "Sandoz Crystals", Lets see if they notice the difference
... to get a good name for this technology.
With Microsoft's, it would be ActiveTCP.
With Intel's, it would be HyperTCP.
And so on, and so forth.
people have been saying stuff like this for ages. It always works out nicely in little controlled environments where the protocol is developed, but once they let it out onto larger networks they fail miserably.
Many technologies out there use adaptive techniques to improve whatever characteristics are deemed important. For instance, you have adaptive sigma-delta modulation, or if you haven't heard of that, how about VBR (Variable Bit Rate) mp3s. In the latter, it's sound quality and file size. In this case it happens to be speed. However you put it, the point is that using adaptive techniques to improve the quality is an excellent idea, and one that I'm sure is gonna be applied to many more technologies in the future too. Sounds interesting. Now seeing that IPv6 has been installed ... err wait a minute. IPv6 has yet to be as ubiquitous as we thought it would be. So I'm a bit shy about whether to say that this technology will be available for the masses any day soon. Ah well...C'est la vie.
When the researchers tested 10 Fast TCP systems together it boosted the speed to more than 6,000 times the capacity of the ordinary broadband links.
Does that mean that when absolutely no packets are ever dropped, and the computers are connected directly to each other, etc., that it will be 6000 times faster? This certainly sounds like an absurd number. I wouldn't think that error checking would cause so much of a delay. Does anyone have any comments on whether such a large increase is possible?
A clever version of UDP..
Nothing good about that..
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
mod parent fucking up
6000 times?
so like my 3 mbit cable link suddenly becomes a 18 gigabit link? give me a break
This is part of a whole bunch of TCP and networking related work at CalTech.
I hate to do this to them, but the Caltech Networking Lab site has more info.
From what I see, the improvement here is to use packet delay instead of packet loss for congestion control. They claim this has a bunch of advantages for both speed and quality.
Here is a Google cached copy of their paper from March 2003.
If only I were using Fast TCP, this could have been first post!
As near as I can tell from the popular articles, and the web page referenced in the New Scientist article, "Fast TCP" is not a new protocol, but rather better congestion control for standard TCP. I'm not a network guru by any means, so please take the comments below with a grain of salt.
Currently, TCP implementations use a standard trick to play nice with small router queues. Using precise timing would be better. I hassled Mike Karels over it about 10-15 years ago, but the consensus at the time was that the hardware wasn't up to it. Now it is. Also, modern routers have gotten clever about queue management, which screws up the trick.
The new proposal is to take advantage of modern HW to measure latencies. Existing TCP could thus be used more efficiently, by allowing larger amounts of data to be outstanding on the network without trashing routers.
It is not widely understood that in 1988 the Internet DOSed itself because of a protocol design issue, and Van Jacobsen got everybody to fix it by a consensus change to the reference implementation of TCP. These articles appear to report (badly) ongoing research into that issue.
to me it sounds like an optimized implementation of existing tech.. something best applied to switches/routers nic drivers etc. ie a firmware update or something. we could all benefit from this, but it will probably be patented and sold to big companies so that they are the only ones who can stream movies :\
bite my glorious golden ass.
But I'll keep my error checking, thanks.
Actually the mention of removing error checking is in the /. article summary.
The problem is people are just reading the summary and assuming that it is actually correct and accurate.
Good points otherwise...
iTCP. Connect. Transfer. Disconnect.
right?
"You never want a serious crisis to go to waste." - Rahm Emanuel
I read about protocol named T/TCP (if I remember correctly the name) which speeded up TCP-handshaking and made some other adjustements to network couple of years ago. Basically TCP and UDP mixture. I've never heard it afterwards so I think it fainted to oblivion (as I think this one does also).
You don't know what you don't know.
ZModem was sweet indeed when it came out. I went from 2400 baud to 14,400 baud using Zmodem and became the cool kid on a very geeky block.
...at digital fountain:
www.digitalfountain.com/products/tf/faqs.cfm
wherein error-checking is replaced by
forward error correction with no ACKs, over UDP.
other terms: erasure codes, tornado codes.
a disadvantage: encapsulated into special head-end hardware, for now.
It will take a little research to find good algorithms, which I presume they've already done, but there's nothing stopping some enterprising soul (who wants his porn faster) from adding this to linux in a couple weeks. So I guess the real question is are they going to try to patent it? And if so, the entire concept (bad) or just their implementation (better)?
In other words, if you don't work for Microsoft or Disney, will you get to see any of the benefit from this or will it be locked up?
Bah, in my days I remember having a 300 baud modem, and being the cool one when I went from ascii captures to a version of xmodem written in basic.
Shouldn't there be a way to tell the streaming server whether you think the audio vs the video part of the stream is more important?
I hate watching streams of press conferences where I couldn't care less how much GWB or Ari move their hands but I'd like to hear the audio more clearly...
Conversely, there are other... erm... applications where video should trump audio.
Maybe they're measuring the round-trip delay, and then sending more data than can fit in the reciver's window, on the assumption that ACKs "should be" in flight. Maybe they also notice when an ACK is overdue, and send a duplicate packet early, rather than wait for the normal timeout or a duplicate ACK of earlier data. If they do that, then the duplicate would come 1 RTT after the original, and the reciever's window would be full of after-loss data (so it would catch up right away.) I suppose they could assume that only one packet would be lost, and send another window-full of data after that, before recieving an ACK. (If that assumption was wrong, then that data would be lost and bandwidth wasted.) ... but that's all just guessing.
I do hope that there is something to this (in spite of the fluff of these articles.) We're kindof stuck in terms of throughput with TCP right now.
The former inequality is reasonably easy to fix -- make bigger windows (and buffers). The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.) It would be great to fix MSS, but lots of hardware won't support more than 1500 bytes, and nobody benifits from this until everybody upgrades, so nobody upgrades. For fast links, RTT is mostly determined by the speed of light.I never understood this.... I had x-modem (sometimes known as Ward Christian protocal) as early as 1983. The only time I resorted to an ascii transfer was when the stuff was text in the first place.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
The "Smart" prefix is overused to the point of being totally meaningless. Hmm...it sounds like my clock automatically updates it's display as time passes....I think I'll call SmartClock.
TCP already does a lot of tweaking to get better throughput. What is your problem with FastTCP? At least "Fast" adds meaning. I guess you could have done worse and suggested "IntelliTCP".
It would be nice to have something akin to the way the zmodem transfer protocol worked that we used back in the BBS days. If I recall correctly it would basically dump the data in large chunks (8k?) and not wait for a success response. Only if it got an error response along with the position indicator, it would then stop, and start resending from the error position. It was much faster than xmodem, ymodem, kermit, or punter protocols. Plus, resume worked great, too!
(Stolen sig) Remember: it's a "Microsoft virus", not an "email virus", a "Microsoft worm", not a "computer worm
Wow, looks familiar: http://slashdot.org/comments.pl?sid=66418&cid=6120 065
without further technical details, this sounds like the sort of technical mumbo-jumbo that snake-oil salesmen were peddling back in the dot-com era.
The New Scientist makes it quite clear on how the Fast TCP is done, if you know anything about how TCP works (and how the window size halves in the event of packet losses)
shame on a relatively low-ID user making such trollish comments...
There have been times even in this day and age that I have resorted to the use of z-modem because ftp resume just didn't work right. But it's not like you can't use Zmodem over TCP/IP, it's just not very practical. Just for laughs I should try zmodem vs ftp transfers from my linux box just for laughs, i'd be somewhat curious how well they work over a 100mbit connection. Z-modem's error correction would likely to be most redundent, but hey it's worth a shot just for nostalga sake.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
It's actually derived from TCP Vegas with modifications.
Test your net with Netalyzr
data link layer technology, like Ethernet, already has error checking built into it's frames, so why is there a need for another error checking at the higher transport layer?
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
The speed, er... rather the window size is changed according to a rigid design, and ideas like this in the past have failed because once everyone is doing them, they stability of the network decreases. Mind you this is distinctly different that "removing error checking" because it is basically taking two steps forward instead of one step at a time. If you leap ahead two steps, and fail you simply step back one (which is still one step forward). The packets are still resent on the TCP leaving the application to not worry about data quality. Looking at packet captures of ftp traffic show that ftp is an aggressive consumer of bandwidth, and that ramping up or down near the beginning or end of the TCP session is were the greatest amount of *inefficiency* is found. So the idea is to make tcp more aggressive near the ramp-up/down stages of the connection. The idea also being to remove some of the agonizingly redundant error checking in favor of self-throttling optimistic educated guessing. Fast TCP simply wants to do the dirty work ahead of time instead of gradually discovering the safe speed limit. Fast TCP will bump into glass bandwith ceiling at mach 10, instead of 10 Mph, quicly recovering by resending the big chucks at a fraction of the window size previously sent. So it could also be described as willig to find the threashold quickly in echange for knowing the boundrys instead of wasting precious time ramping up. Traditional TCP hates data loss to the point that is "drives slow in a parking lot" attempting to never have a colision, whne the protocal itself is well designed to recover from such an event already.
It isn't a lie if you belive it.
T/TCP is different. T/TCP includes data in the SYN packet, so your SYN packet would also have "GET foo.html ...". Most TCPs send an empty SYN packet, wait for a SYN+ACK reply, then send the first data packet. It is not a mixture with UDP.
"High Bandwidth TCP" seems like a better name than "Fast TCP" to me.
God knows there's too damn much of that "error checking" stuff in computing today...
I haven't heard of this "Evil Bit" yet... could you tell me a little about it? Maybe it is worth a slashdot story?
See caltech's press release on FAST for an article that actually makes sense.
Also, could someone please explain to me why boringly predictable stereotypical slashdot feedback is being modded up?
"Whoa! Faster pr0n!"
"Imagine a beowolf cluster of these!"
-Insert completely unrelated Microsoft bashing post here-
-Insert completely unrelated technobabble from some geek posting out of their ass (without reading the article first)-
News for nerds. Stuff that matters. Discussion that doesn't.
The article pointed out an interesting variant of TCP for improving transfer performance. However, the conditions they were using are the equivalent of trying to break the land speed record on a salt lake that's as smooth as a billiard-table and hard as cement.
In other words: it's not very realistic, nor appropriate for most internet usage with shitty connections. It would be like trying to use a 600mph dragster (this protocol) on a dirt trail up the side of a mountain (a 56k modem). Even at a highway speed of 80mph (with regular broadband), you don't need anything much faster than a regular vehicle - and anything specialised is liable to give you problems.
Having said that, there's no reason not to mess with your broadband connection (tweak the MTU, TCP window, etc) to see if you can eek more performance out of your existing protocols. There is an excellent broadband tweaking guide that's well worth reading and did help my Windows box. YMMV.
pick all four please.
As I see it (hard to say because the article wasn't exactly technical), here is how it's going to work:
Slow TCP:
Packet 1
------->
Ack 1
<------
Packet 2
------->
Ack 2
<------
Let's say for example that each transmission take 1/10th of a second, the transmission for n packets takes n*2/10th of a second.
With fast TCP, you will have:
Packet 1
------->
Packet 2
------->
Ack 1
<------
Ack 2
<------
Since your PC doesn't wait for the Ack 1 before sending packet 2, Ack1 and Packet2 are transmitted at the same time.
Here to transmit n packets, it'll take (n+1)/10th of a second.
Still very far from the 6000 ratio they are talking about in the article, but that part was probably just FUD.
To get back to the point: In order to finish your download you have to have recieved ALL the Ack packets, so nothing changes compared to good old TCP. The thing is that you use the full-duplex capacity of your card...
Write boring code, not shiny code!
If this protocol is specifically designed for high speed connections, It would not help my 56Kbit dial-up connection :(
Would it be used for users of traditional broadband connections?
Could Linux assimilate this new protocol?
Don't make your problems my problems!
Perhaps this could finally lead to the possibility of having a FPS (First Person Shooter) use TCP instead of UDP. If the latency issue can be adequitly addressed, it may be possible to have a sufficient transfer rate (and latency) to have a game use TCP packets as a means of client to server communication. This would greatly help with packet loss.
As a developer, I am interested in seeing the many potential _legal_ applications, although I definatly wouldn't mind faster filesharing.
Contact Me (got tired of viruses emailing me).
The TCP Vegas paper has good references to these earlier works, primarily that of Jain and also that of Wang and Crawford.
The relevant papers are:
"TCP Vegas: End to End Congestion Avoidance on a Global Internet." Lawrence S. Brakmo and Larry L. Peterson
"A delay-based approach for congestion avoidance in interconnected heterogeneous computer networks." R. Jain
"A new congestion control scheme: Slow start and search (Tri-S)." Z. Wang and J. Crowcroft
Totally ridiculous. That's the kind of crap you can expect from a totally clueless reporter. The sentence is ambiguous and in the end, it doesn't really say anything.
For some reason, he felt the need to mention that 10 systems were tested "together" without saying how.
It says that FastTCP can boost the speed past the "capacity" of ordinary broadband links. I don't know how you can get performance that exceeds the capacity (which I take to mean the theoretical limit). On the other hand, it isn't really clear if they even used "ordinary broadband links". For all we know, they could have been testing on a local GigE network (or on localhost!).
If he's trying to say that FastTCP gets 6,000 times the throughput of TCP, then this implies that TCP can be at most using 1/6,001 of the theoretical maximum. I'm guessing that they're advertising some corner case (or the reporter is retarded, which is probably just as likely).
FastTCP just seems like a better predictor of the delay/capacity properties of a connection. The New Scientist article says in one place that they were able to achieve a 4x increase in transmission speed between Geneva and California, which is impressive, but it's probably under strange conditions. The graph in their paper shows that FastTCP utilizes the link about twice as well as regular TCP when you get to 10Gbit links. The "reporter" must have done some serious mangling to get the number 6,000.
you bet, pal!
Second, it's intended for use for single big flows on gigabit networks with long latency. You have to be pumping a few hundred megabits per second on a single TCP connection over a link with 100ms latency before it really pays off. It won't do a thing for your DSL connection. It won't do a thing for your LAN. It won't do a thing for a site with a thousand TCP connections on a gigabit pipe.
Third, unlike some previously hokey attempts to modify TCP, this one has what looks, at first glance, like sound theory behind it. There's a stability criterion for window size adjustment. That's a major step forward.
(I first addressed these issues in RFC 896 and RFC 970, back in 1984-1985. Those are the RFCs that first addressed how a TCP should behave so as not to overload the network, and what to do if it misbehaves. So I know something about this.)
It sounds like they are working on a replacement for the Nagle algorithm. Nagle works well on clean connections, even if badly tuned slow-start gets annoying when you have gigabit connection and it still takes a minute to ramp up to full speed on an ISO download. Where "fast tcp" would really help is on a dirty connection. I had to connect to a supercomputer a few years ago over a 100Mbps link that corrupted or lost 30% of all packets and I had to use my own streaming on top of UDP to avoid getting hammered by shrinking windows (I still needed congestion control.) On this type of connection I'd expect their "fast tcp" might give a 10x speedup. On a normal non-noisy and relatively slow DSL connection, like I have at home, I'd be surprised by a 10% speedup.
In other words the story is all wrong, but what they are doing is actually worthwhile. You sometimes have noisy networks, especially when they are wireless or in an industrial environment. The big long haul telecoms lines are better off doing error correction on line, but in the last mile you never really know the noise characteristics so this should be handled better on the TCP level. I would probably do something like FEC with the number of recoverable errors per packet and per lost packet per logical block, tuned to the error characteristics of the network. Then call it TCP2 and release an RFC and some BSD licensed source code.. (I thought of doing this as part of building an ISP friendly P2P protocol but decided I didn't have the time..) Their solution has the advantage that it works just great with regular old TCP implementations.
They represent TCP totally wrong. Not only that, they describe the whole network infrastructure wrong.
:(
No wonder I have trouble explaining how the network works to my sister, or even to my mother who happens to have his masters in tech. (Albeit in mechanical engineering)
Let's see.
"The sending computer transmits a pack, waits for a signal from the recipient that acknowledges its safe arrival, and then sends the next packet"
No honey, thats why we have the buffers. So you could receive packets out of sequence and wait for the middle ones to arrive. This is why we have 32-bit seq and ack fields in the tcp header just after the src and dst ports. seq tells the packets order in the queue. Ack tells the seq ofthe next packet (from other peer) so we can use random increments to prevent spoofing of packets. Or make it harder atleast.
But that's out of the scope of this rant.
If no receipt comes back, the sender transmits the same packet at half the speed of the previous one, and repeats the process, getting slower each time, until it succeeds.
Umm, No. I'm not 100% sure but I think the network devices are dump thingies that talk to each other on predefined carriage frequencies. Thus, you can't really "slow down" the speed to increase possibility to get the packet through. And certainly this has nothing to do with TCP. Resending of failed packets is a Good Thing (TM). They are just sent again untill they reach their destination or the "I give up"-treshold has been reached.
"The difference (in Fast TCP) is in the software and hardware on the sending computer, which continually measures the time it takes for sent packets to arrive and how long acknowledgements take to come back"
This is the only difference? Wow! Shit. We are definetely going to get faster speeds by adding overhead with this calculation.
Now, I'm through with my rant.
I really really would like to see an actual white paper how this works. There has to be more to this. By the sound of just these articles, it seems to me that someone was paid to develop new, faster protocol that would magically be backward compliant with TCP. Finally the persons couldn't come up with anything smart but gobbled together something that might sound plausible.
Of course you can get "more than 6000 times the capacity of ordinary broadband links" by using your very own dedicated parallel LAN links. You just need fast enough computer to handle the TCP stack. You would also need some fricking fast BUS's on you computer to make any use of this bandwith. Remember, the hard drives, mem chips and other storages aren't exactly 'infinite' in speed either.
If the demo consisted only of two computers exchanging data, there would be no need to estimate the speeds as it would be very unlikely to get packet collisions because of disturbance from other network devices. Also, again, that has nothing to do with TCP-stack. Again, this useless speed calculation is just more overhead.
And now I'm rambling.
Shit, why can't i just stop.
I'm angry, that's why
I hope someone would answer me with insight of what am I overlooking. This looks so useless to me.
Bot Assisted Blogging
I don't know why they don't just get nVidia to design it. That way the sending machine will only send the packets it thinks you're actually going to be able to see instead of the entire datastream.
nTCP = instant speed increase.
Heh, I saw this article on Yahoo, and was immediately concerned. Stupid reporters cut out way too much information, and make the people on wee dialup systems think that they'll get the moon.
Anyway, I think this is primarily interesting for people on really fast connections (ranging in hundreds of megabits per second up to gigabits) with relatively large latencies (tens/hundreds of milliseconds as on a transcontinental link rather than nanoseconds/milliseconds like on a LAN), but I'm sure the research will have some effect on LANs and even the standard broadband connection. Impact on dialup and other not-quite-broadband connections would likely be miniscule.
One main issue with TCP is that it uses a "slow start" algorithm, which other people have mentioned. Real TCP stacks probably tweak the algorithm quite a bit, but from the description in Computer Networks (3rd edition, 1996) by Andrew Tannenbaum, TCP packets start off with a small "window"--how much data can be in transit at a time. The window grows exponentially as packets are transmitted and acknowledgements received until a pre-set threshold is reached, and then the window starts growing more slowly (Tannenbaum's example grows exponentially to 32kB at first, then by 1kB per transmitted packet).
If a packet is lost, the process starts over and the threshold is set to half the window size you had before the dropped packet (I imagine many systems reduce the window size by lesser amounts). Now, this particular algorithm can cause quite a bit of nastiness. It's possible the window size will never get very large. This isn't a really huge problem on low-latency links like in a LAN where you get acknowledgements really quickly, but a hyperfast transcontinental link could be reduced to mere kilobits per second even if the percentage of dropped packets is fairly low.
Additionally, this slow start algorithm will eventually force you to restart at a smaller window size. Given enough data, you'll eventually saturate the link and lose a packet, so until the window grows enough again, there will be considerable unused bandwidth. Good TCP stacks would attempt to guess the available link speed and stop growing the window at a certain point.
Smart system administrators can tweak kernel variables to make systems behave better (preventing the window from getting too small, having larger initial thresholds, for instance), but it looks like a lot of work on Fast TCP and related projects is related to making this a more automatic process and growing/reducing the transmit window size in a more intelligent manner.
I posted this in April. I guess they just don't like me.
2003-04-10 04:53:48 F.A.S.T Protocol Allows DVD to be Send in 5 Second (articles,news) (rejected)
Error checking hasn't been removed from TCP; we've removed it from Slashdot story summaries instead, speeding up the posting by nearly 6000x.
--
Linux-Universe
Freedom Is Universal
Linux-Universe
Congestion control based on roundtrip times is old news but is uncommon AFAIK. What really happens is direct feedback from routers along a transmission's path. This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now. The problem with scaling this or any of the other common TCP implementations to high speed/high delay links is the reaction to detected congestion. "Normal" TCP aggressively scales back its send window (send rate) when it detects congestion, usually chopping it in half. The window/rate then grows linearly until something goes wrong again. This results in alot of lost throughput in high-speed networks especially if the amount of "real" congestion is low. The FAST group is working on a new TCP implementation that doesn't react so aggressively to congestion. This is great for those high-speed/low-congestion networks we all wish really existed but is not something you want to use on the always-backed-up Internet. Would probably make things worse.
Novell had even greater problems with WAN latencies due to having an effective window size of 1 for most connections.
They solved this with something they called Packet Burst, with depended upon very careful, high-resolution timing, of all replies from the client.
They also used the same timers to insert controlled amounts of gap time between each transmitted packet, if that was needed.
The net effect was that they could get very close to maximum throughput, for the current combination of source, destination and current network load.
Terje
"almost all programming can be viewed as an exercise in caching"
Actually instead of variable retry to overcome errors. How about variable error-correction? Error-free lines (clean) get little to no error-correction (hence more information payload) and error-loaded lines (dirty), get all the error-correction they need. The ratio of ACK/NACK could be used to judge the line quality.
If you could download a 700MB movie in a few seconds, how would your typical 7200 rpm hdd handle the load?
I did'nt bother with the silly artical. I just knew I'd see better coverage and insight by skipping to the posts. I was right.
TCP is extremely bursty - it pumps all the packets it can as fast as it can over the network as soon as the window opens. Then it waits for replies to all the packets. What typically happens is the burst from the NIC overloads the local router causing numerous dropped packets. This gives the imporession to the sending machine that the network is overloaded and results in a ~90% reduction in bandwidth utilization.
The change is to include a timer that allows the NIC to space the initial burst over the entire window. This prevents the overloading at the router and permits the NIC to reach near its theoretical maximum bandwidth.
In tests involving one router, the results were an order of magnitude increase in bandwith utilization. I'd be interested in seeing their test setup to see how they got such dramatic improvements. Normally TCP/IP is not that ineffecient - even with its extreme burstiness.
The number you have dialed is imaginary, please rotate your phone 90 degrees and try again.
This would not be the first time that Caltech has taken an innovation and turned it into a big time money maker. DNA Sequencing made a lot of money for Caltech, though not without some controversies.
I would SWEAR people were talking about this 5-7 years ago. I even remember some company was going to release a switch or router based on this concept. Now if only I could back up my assertion with a link...
Damn it...so we are going to get another congestion control mechanism? Let's see reno, new reno, vegas... I know, let's call this one "mustang ranch"! And of course the idiots on the IAB will approve yet another RFC... When's the next IETF meeting? I'm gonna go raise some hell...
Quality drop every where.
First car's, then computers and now guess what ?
TCP.
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
How about variable error-correction?
That's what I meant. You also need retransmission for when you have unexpectedly high error rates. For transfering files you would want a relatively low level of error correction since higher latency is a good trade for greater bandwidth. For a live streaming video p2p-cast you want a much higher level of error correction.
Hmm, I've heard that Microsoft does something like this when Internet Explorer attempts to connect to IIS servers, making the IE/IIS combination appear to work really fast, but that might just be a rumor.
All these protocols were there to get the greatest speed on your 2400... 9600 baud modema (and i am sure there are people here who used slower modems)
But you forgot the mention the speeds of the protocols:
Ymodem-G was the fastest. (if you got an errorless link)
Zmodem followed close withing a few %.
Ymodem was a bit slower, but by the time people got Y modem Zmodem was already popular
Xmodem was much slower(20-30%), but everyone supported it.
I still use zmodem now and then if i am too lazy to startup an ftp transfer.
The report says that this new implementation can actually speed up the delivery of the content a whooping 6000 times FASTER !
If that's true, then what we are having today is actually 6000 times _slower_ that what could have been.
And in the p0rn saga, heheh
Muchas Gracias, Señor Edward Snowden !
Normally, when you're sending stuff from point A to point B, there is a lot of buffering on the way. At the point where you lose a packet, you've overflown a buffer somewhere. Halving your throughput at that point is probably a good idea - you may be backing off your data transmission a lot right now, but there should be plenty of data sitting in buffers out there that needs to be cleared anyway.
If you only back off a little bit, what happens is you just go overrun that same buffer again, and just send out a lot of data on your end that's just getting dumped halfway out.
Think of it like dumping bags of sugar into a big funnel. You start by dumping in a quarter bag per second, then a half bag per second, then 3/4ths bag per second, then a bag a second, then 1.25 bags per second, then 1.5 bags per second...
At which point you notice that the funnel is full and sugar is overflowing it. At this point, does it make more sense to go back to dumping 1.25 bags per second, or 3/4 bags per second? (Hint: It's 3/4ths.)
By the time you've lost a packet from overflowing a buffer, you definitely want to back off more than a little. The rate you're filling the buffers is likely at least an order of magnitude higher than the rate you're emptying it, so it only makes sense to back off by at least an order of magnitude.
paintball
I stand by my claim that the New Scientist article sounds like snake oil. It's a misleading article, pure and simple.
But, now that I've read some of the documents from the Caltech site, and I think I understand the claims, the research is fairly interesting, at least in the world of "ultrascale" networking. Of course, I'm just an unfrozen caveman engineer, and that world confuses and frightens me, so my understanding might be slightly off. Here goes anyways.
As I understand it, the authors are saying that current TCP congestion avoidance algorithms break down on very high speed, long-haul networks. They mention looking forward to 100Gbps and higher speeds for "ultrascale" supercomputing. They have papers analyzing TCP Vegas (which was designed in 1994) and show that for the networks they're looking at, Vegas "does not scale to this regime". Specifically, they examine throughput stability of Vegas, and show that with these ultrascale networks, performance can end up bouncing between the two states of "balls-to-the-wall" fast and molasses slow. (They do not actually use the phrase "ball-to-the-wall"; that's my addition.) Network performance doesn't reach equilibrium, and your average throughput is quite ugly. In this context, the "cars starting and stopping" analogy starts to make sense.
This is a fairly different "regime" than I'm used to; then again, I'm an unfrozen caveman engineer, and the fastest neworks I've dealth with are 10Gbps LANs, and not high speed WANs. It appears that network performance on such networks can be surprisingly bad, at least, it's surprising to me. (And heck, there's a world of conditions under which Vegas is a great TCP congestion control algorithm, and the network delivers fair bandwidth to everyone. They even link to plenty of papers which analyze, simulate, and measure conditions where current algorithms work just fine.)
They're really looking forward to where the network finally starts to reach pathological extremes, and this all breaks down, which is different than conditions I (and most readers of the New Scientist article) would have seen.
Their first solution, by the way, is a slightly modified algorithm called "stabilized Vegas". They prove that this algorithm avoids the oscilating behavior, and thus avoids the low throughput situation that results. Neat.
Let me summarize my summary: original article bad, sounds like a scam. Actual research interesting, but applies to network speeds and conditions that are forward-looking, and probably don't directly apply to Mr. Bob Homeuser for quite a while. Fire bad.
It comes with Solaris right now. You can also get it for Linux. Why?
It's useful when the ssh client has it built in because you get pretty much the same speed and the ability to download between clients.
By the way, I know about two zmodem-enabled ssh clients:
1) SecureCRT - nonfree/Windows only.
2) Zssh - open-source, cross-platform.
The actual applications which initiate the transfer are called "rz" and "sz."
Mod me down and I will become more powerful than you can possibly imagine!
The whole point of their paper was that TCP breaks down when the bandwidth-delay product gets really high, because of the high number of packets "in flight" per control iteration, and because of the comparatively high (per-rtt) probability that non-congestion-induced packet losses will occur. So yeah, they are using a high-bandwidth, high-latency line with relatively few flows, but because that's the situation they're working on, not because it's a rigged test. I think the New Scientist article did a bad job in making it clear that this is about how to take advantage of obscene amounts of bandwidth, not how to squeeze performance out of more meager links.
If you look at the applications they're interested in, namely multi-terrabyte scientific data set tranfers, UDP wouldn't be an ideal choice because they need the reliability features of TCP as well as the congestion control. Also, I'd expect this to achieve similar throughput to (well-behaved) UDP streaming protocols, because they have similar origins. FAST TCP and modern congestion-controlled UDP applications both used rate-based congestion control, largely based on the ideas introduced in TCP Vegas..
Now really, which TCP implementation is used the most these days? You never hear about this. Like, do Windows, Macs, and UNIXes all use Reno or something? Or some Tahoe and some Vegas? The reason I'm asking is that Vegas seems fine, but needs to have some extra parameters defined (the alpha, beta and gamma thingies for congestion avoidance using RTT calculations). But under some circumstances the Vegas implementation just *sucks*: using what seems to be normal choices of these parameters you can easily get a stuck congestion window (when the delta is between alpha and beta IIRC) and only 10 percent of the throughput of a Reno implementation. Even though I haven't been able to fully overcome this in the simulator, I can imagine it might provide problems and need for fine-tuning in real-life stacks. Therefore, which one are realistically in use and which aren't?
Microsoft was rumored to have implemented a non-synching TCP stack in early versions of IE in order to reduce delays. In fact, I couldn't tell you they don't still use it.
Yes, it's faster if you ignore the safety interlocks, but when it goes bad, it goes really bad, because the rest of the system was designed with the presumption that the safety interlocks are on so *they* can run balls-out. They depend on that carefully modelled reigning-in of their inherent instability.
So this new method, it could end up being far slower in many cases. Like typing on a manual typewriter is faster than writing by hand, but if you try to type too fast you slow way down always untangling the keys.
The last sentence of both news articles suggests that this broadband-optimized TCP system could be used by corporations like Disney to provide video-on-demand. (If they're talking to Microsoft, on the other hand, the result will just be a modification to the TCP/IP stack in Windows(r), which doesn't care at all what kind of data it's transmitting)
That's just wrong, at least according to the ways media companies have traditionally desired their materials to be broadcast over the internet. They typically use streaming protocols, which not only gives the user one-click startup, but also makes it non-trivial to keep a local copy of the file (enhancing the corporation's feeling of control).
However, a well-designed streaming protocol won't use TCP at all. TCP hides many characteristics of the network from the application software, and to stream properly it needs to know as much as possible. One example of why TCP is bad for streaming: in streaming, you try to keep advancing time at a constant rate. Once 156 seconds of playing have elapsed, you want to be showing video from exactly 156 seconds into the source file. If at 155 seconds some packets were dropped, you should just skip over them and continue onward. TCP, however, will always try to retransmit any lost packets, even if that means they'll arrive too late to do any good. TCP has no knowledge that packets may expire after a fixed time, but a custom-built UDP protocol can be aware of that constraint.
(Here's a reference on preferring UDP in video streaming)
On the other hand, maybe a corporation will realize that properly controlled non-streaming playback can provide a better end-user experience (guaranteeing, for example, that once playing starts, network failures will never interrupt it). In that case, they might either try to push Microsoft to integrate this faster TCP/IP into Windows(r), or more interestingly, implement it themselves in customized player software.
It's possible to implement a protocol equivalent to TCP on top of UDP, with only a tiny constant amount of overhead. So a programmer for realplayer, quicktime, or mplayer might be able to add the techniques from this research to his own code, even without support in the operating system.
A server that streams media data does not need to "try to keep advancing time at a constant rate".
Media formats include timing information as part of the specification, and operate independently of transport technology. The only thing you need to worry about is supplying data at a sufficient rate. Modern streaming technologies incorporate the use of prebuffering and strong compression to overcome this.
So at 156 seconds into a media-viewing session, you want to be streaming data from much further in the file to the client application.
The dangers of knowledge trigger emotional distress in human beings.
And the bandwidth-hungry entertainment industry is also looking at Fast TCP. Caltech is already in talks with Microsoft and Disney about using it for video on demand.
No wonder their services suck bigtime!
The story will be available on /. next week.
You are being MICROattacked, from various angles, in a SOFT manner.
How does this fast TCP compare to Debian's excellent apt-get system?
What is this bullshit ? "If no receipt comes back, the sender transmits the same packet at half the speed of the previous one, and repeats the process, getting slower each time, until it succeeds. " There is nothing like this in tcp ! If the packet needs to be re sent it will be sent excatly the same way... IP networks are etherogeneous by definition ! a hardware equimpment passing IP packets to his neightbourg who will then forward it most probably at a different speed to his neightbourh until it reach its destination... If I use my modem at home I will talk at 56K to the provider it's own equipment will talk to each other at great speeds probably around 1G then he will be linked to he's own provider by a 100Mb link and then will cross the atlantic without me or my pc having a clue at what speed... And this was said in the two articles... I hope that this is due to the incompetent journalist...
TCP does not provide its own underflow buffer. I'm sure modern implementations provide an overflow buffer to make sure it doesn't overwhelm the physical transport layer, but it is not the kind of buffer an application needs to ensure the seamless delivery of streaming content. Does any implementation of TCP allow for the aggregation of an arbitrary amount of data before handing it off to the application? No. That would be counter productive.
Also, RTSP is a protocol-independent stream control mechanism. The RFC clearly states that all application data is transmitted out-of-band in another protocol. It is only a "transmission control" protocol (not to be confused with TCP, of course) and allows for the transport-independent control of data streaming to and from different sources on the net.
In other words, it's not used to make sure the content itself gets from one place to another reliably (or unreliably). In fact, the RFC also provides support to specify a lower-transport protocol for (out-of-band) streams, either UDP or TCP. This would presumably would allow for both reliable and unreliable transmission of data, depending on your specific application.
So in conclusion, reinventing TCP with UDP is a dumb idea and is not what RTSP aims to do. It probably plays a vital role in controlling the behavior of things such as VoIP phones. In such applications, when latency is negligible, buffers are not practical, and a reliable transport mechanism is assumed, then no, a buffer is not necessary or practical, but these assumptions do not apply to the internet-at-large in the least. If you want reliable data on the internet, you use TCP. Period.
The dangers of knowledge trigger emotional distress in human beings.
just do a quick google.
o ring/bulk/ tcpstacks/fast.html
1 .p df - is a recent tech article that explains neat stuff like the fluff papers do.
1 .p df
l ac .pdf
i'll go ahead and skip to the article that page that matters:
http://www-iepm.slac.stanford.edu/monit
here you can see side-by-side tests between Fast TCP and Reno TCP. and you can see that over low latency networks (RTT 100ms) that Reno TCP is more than 5 times faster than 'Fast' TCP. that's right kids - this protocol is designed for use on ultra-wide (by our reckoning) bandwidth pipes with -high-latency-. using a smaller pipe, or having lower latency is against the assumptions of this protocol and does not net the same types of gains.
oh, and the '6000 times faster' comment is a comparison of the speed FastTCP achieves on internet2's pipes vs. consumer broadband.
Apples and orangutans.
for posterity:
http://netlab.caltech.edu/pub/papers/fast-03040
http://netlab.caltech.edu/pub/papers/fast-03040
is a presentation out of caltech from january 2002 covering the problem again.
http://netlab.caltech.edu/FAST/sc2002/sc02cit-s
here they cover a comparison between linux tcp and fast tcp. they also cover the effects of just jacking up the MTU (keep in mind this is on internet2's fat pipes.)
// "Can't clowns and pirates just -try- to get along?"
appropriate link here:
r ts /task1/20021001-Low.pdf
.... 'Than [dialup] Modem'
/ 03 18_030318_internet.html
http://icfamon.dl.ac.uk/papers/DataTAG-WP2/repo
and i'm retarted so i misread 'june' as 'jan'.
and nat'l geographic beat the '6000x faster!' article to the punch by stating that FastTCP is '153,000x Faster'
http://news.nationalgeographic.com/news/2003/03
// "Can't clowns and pirates just -try- to get along?"
Nah, the only reason to do an ASCII transfer was to sneakily convert the ASCII art from the Apple BBS to ATASCII for my Atari 800.
I have an idead! Fast TCP transfers with no error checking... And we'll call it UDP.
Karma: The shiznight, mostly because I am the Drizzle.
Something suits tend to do when they find out about some kind of new high-tech gadget that improves performance, they say "wow, imagine what we could save with that!"
After reading several posts, I know this is probably not the panacea that we all expect. Still, taking the article at face value for a moment and assuming it would amount to 6000x... would it be possible for ISPs to say "hey, we could just throttle down the bandwidth on our lines with this new protocol and save mad cash!" ?
Remember, geeks won't get this tech first. Suits will.
i'm amazed that i survived - an airbag saved my life.
finally include the Evil Bit?
Escape Pod Films: Sketch Comedy and Web Series
dumping a lot of time-consuming error checking
Sounds like a slashdot editor
I believe this is HSTCP.
For more info, you can also take a look at:
Web100 and Net100.
It basically amounts to improving the AIMD algorithm and changing the way slow start works as well. Also, whoever said it before that this will not help your DSL connection is correct. It is meant to help high speed long RTT paths. And it does so -- quite well.
I actually heard this on the ABC radio news whilst driving to work this morning.
Unfortunately they managed to summarise it in the most bogus form possible, and I quote (roughly)
"Existing Internet links could run six thousand times as fast!".
Even New Scientist, normally a beacon of good science journalism, is really dumbing it down to the noise level.
The analogy they gave is most ironic -
... as my car sat, motionless, on the congested freeway ...
But isn't error correction supposed to be a function of the link-layer? TCP/IP has error detection with checksums (forget if it's in IP or TCP), but these aren't always used. Even if they did, on most networks, errors are due to collisions, and thus the entire packet is lost, not just a few bytes mid-stream.
In wireless, I'd advocate something like this, but again, only at the link-layer which means it's going to be highly medium specific.
-Michael
Still, nothing can be quite as fast as ymodem-g
If I ever become a rapper, I have dibs on the name "YModem G"
Back in those days, I setup a interactive session, PC to the companies Vax/VMS system, dialing in, then back out again.
Zmodem worked over the link, where none of the other protocols did. It was horribly laggy, escaped characters, etc.
It was designed to handle a packet switched (x.25, tymenet, telenet) network in the path.
Seems to me that the overhead required to estimate your speed would make small downloads slower. Since 99% of our downloads (web pages, images, etc.) are relatively small, wouldn't this be worse??
For large downloads, however, it seems there could be some definite advantages.
as long as no one else uses it.
However, when it comes to transferring data files, I'd personally be happy sticking with the slower old version of TCP. Who would like to have a file 600 gigs in size that potentially has errors in it, and cannot be trusted? It really has problems when your calculating mountains of data to estimate future stock values, or something else requiring massive amounts of accurate data. An error here or there may not matter, but then again, it may, and you can't tell if there are errors in it or not.
9 23 4&mode=thread
Now, this may help with streaming content, such as perhaps streaming on demand high quality video. This may help in the future with an on demand video system much like Pay-Per-View, but over the internet. Though, lets not forget that Snail Mail is still beating out the Internet.
http://slashdot.org/article.pl?sid=02/09/23/171
Every few years, someone discovers an amazing way to hugely improve the performance of TCP, which works great under test conditions, and fails miserably in the lab. File it with perpetual motion.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
a) Its not a rummor. /. sometime ago
b) Its RFC compliant.
c) There was a lot of fuzz here on
A friend of mine posted this article to a private mailing list yesterday. I had the following to say.
Come on, don't buy into the media's interpretation of things. I am not saying the research is bogus, just the article makes things sound different then things are. If a physical wire operates at 1.5MHz serial, there is no way to transmit more than 1.5Mbit/s over that link. Obviously anyone who attempts to sell you software that does so is pulling your chain. That said, Fast TCP is about four times faster than Linux's TCP stack on a 1Gbit/s link (how many people do you know that have one of those). That is because most existing TCP stacks do not perform well at high speeds over long distances, because the demand hasn't been there yet.
Now with that said, different TCP's do make a big difference because of TCP's built in congestion control. The basic idea of congestion control is that a computer shouldn't send data faster than the routers along the path can handle. There are formal proofs that also show that TCP's congestion control guarentees that all TCP connections (using the same implementation and equal round trip times) are given equal priority. The basic idea is to pull back the transmit rate when a packet is dropped.
If all the Internet used UDP, which doesn't have congestion control, our routers would be more overwhelmed than they currently are and everything would slow down.
One can improve one's performance by pulling back less or by taking more than one's fair share.
The statement that all the Internet uses the TCP developed in the 1970's (called TCP Tahoe) is very much false. Most of the Internet runs TCP Reno (1990) now days which includes Jacobson's modification of TCP Tahoe (1988) and added fast recovery and fast retransmit. A number of improvements to that have been discussed in TCP/IP Illustrated by Stevens (1994) and in RFC 2581.
A newer version called TCP Vegas (1995) has been proposed which speeds up performance dramatically and provides a more consistent transmission rate. TCP Vegas hasn't really caught on yet. Fast TCP is a competitor to TCP Vegas.
If you are still reading at this point I will give a more thorough explanation. Whenever a recipient receives a packet it sends an ACK to the sender with the packet it is expecting next.
When TCP starts out it starts in a mode called "slow start." It starts off with a window size of 1, meaning it sends one packet and then waits for the ACK. In slow start mode it increases the window size by one each time an ACK is received until a packet is dropped. So next round it transmits 2, then 4, then 8, until it hits the threshold (Stevens[1994] suggests 65Kbytes). Once it hits the threshold it enters "collision avoidance" mode and increases the window size by one each round (each ACK by 1/window size).
If a sender transmits packets and does not receive any ACKs by the time the timeout for the first packet occurs it pulls back all the way to a windows size of one and drops the threshold in half in both TCP Tahoe and Reno. After going back to one, they start "slow start" again growing the window size exponentially. The difference lies when one packet is dropped but the next few packets are received in a timely manner. In this situation the receiver will send back what is called a triple-ACK all stating it is expecting the missing packet. When a triple-ACK is received TCP Tahoe behaves the same as a timeout (window size to one, threshold in half, slow start), while TCP Reno cuts both the window and the threshold in half, then enters collision avoidance mode.
TCP Vegas works totally differently. It measures round trip time and keeps track of the difference between expected and actual round trip time. If the difference is more than a certain amount it adjusts the window size in the appropriate direction. This method even detects router congestion before the routers start dropping packets in some cases. TCP Vegas also retransmits at a double-ACK
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
Nero BurningTCP. Hey, I like that one.
I agree. I think that using the word "fast" in the name of any computer technology is an inevitable fallacy, as it will eventually cease to be true.
and how will this work in v6?
that all the other streams are going to back-off during collisions. TCP normally backs off when a packet is lost because it assumes that the router buffer is full. It seems like if *everyone* used FastTCP, and no one backed off, it would simply DOS routers all over the Internet. Basically, a router buffer fills up, but everyone keeps sending at an astronomical rate, leading to 100% packet loss. Eventually it would back down far enough that the buffer would open up again, but only briefly, and the process would repeat. TCP was designed to be fair, not a bully algorithm. This thing goes in and violates that fairness principle, by being a bully while everyone else plays nicely. TCP works for the benefit of everyone, by having a universal understanding that unless everyone plays nicely, everyone loses. Hopefully this won't catch on...
Sure it does. I'm thinking around 10000 seconds.
-- this is not a
This really devastates the credibility of CalTech
as an institution. It seems clear that some group
at CalTech pumped this to the media, to the point
where a categorically deceptive series of fluff
pieces entered the news stream.
Compare this to the "cold fusion" debacle in '89:
Pons and Fleischman reported valid, and eventually
reproducible results without hype, but the media
pumped it with speculation. Pons and Fleischman,
excellent, highly competent and productive stars in
their field, were essentially tainted by no fault
of their own, and run out of town on a rail.
It's galling.
-I like my women like I like my tea: green-
You mean as the "fast" in FFT, and the "quick" in quicksort?
Software and algorithms don't generally get faster and better... not in the same way as computer hardware.
Of course there's no one saying it can't be made even faster, but it's not as big a fallacy as you might think.
HS/Link for life! Although Ymodem-G was my first love.. damn I remember using Xmodem.. who came up with all these names anyway? Kermit anyone?
...unfortunately no one can be told what The Mat^H^H^HGoatse is...they must experience it for themselves...
Why would you need to be root in order to upload files?
I would never do that. I'd rather use either a temporary location and mv the files afterwards or temporarily change the owner or group of the destination directory.
Anyone know the story about why all those TCP variants are named after Nevada cities? It's interesting, and I find it cool (I live in Nevada ;).
Just because it CAN be done, doesn't mean it should!
Been there, done that.
Or you could read the actual research paper and notice that Slashdot and the article are both full of shit.
the challenge is to make this 'better tcp' to co-exist with other versions of tcp currently deployed on Internet, like Tahoe and NewReno.The key point is the notion of 'fairness'. The way TCP (at least the currently deployed versions) are designed is to cooperate (in a sense) as to provide the equal share of bandwidth to competing flows. That's one of the reasons why it is so difficult to introduce TCP-like protocol with radically new design. I believe one of the reasons TCP Vegas (which has a good potential) does not get deployed on a wide scale is that it is not entirely clear how the mix of Tahoe, NewReno and Vegas would perform in terms of fair share.
... I wouldn't call it a 'breakthrough' though.
however from what i've been reading on caltech site, it appears that one of the usages of this protocol would be to download very large file on dedicated pipe (like movie on demand). From movie server to the user through private connection. This makes sense. You can streamline lots of things. OPtimize protocol for a fat pipe. Whatever
Several years ago as part of a research project at Novell we implemented something very similar (but with some additional enhancements). It automatically adjusted itself to maximise throughput on whatever end-to-end conditions it ran over, in real time.
On 100Mb Ethernet we were getting 85-99 Mb/sec depending on other traffic on the wire.
We tried it on a Hughes satellite link and got 498k/sec throughput on a 512k link. TCP got about 127k/sec on the same link.
I'm actually getting a sick feeling knowing Novell never productised it. (But they did patent it).
Sorry, don't RTFA. Neither reporter had a clue what they were writing about.
I don't see a good explanation of TCP Vegas here (as I understand it) and I think it would be relevant, as it sounds like they're doing little new.
TCP Vegas is not additive increase multiplicative decrease (ie rate halving on packet loss) as ordinary TCP is, but additive decrease. It is based on monitoring round-trip-times with the crucial observation that if router queues are getting full (due to congestion) then packets queue for longer and increase the RTT. Thus, when delay seems to be increasing, Vegas gently decreases rate, producing a smoothed graph over time rather than a sawtooth.
It requires very precise timing, made possible by relatively recent Intel chips with cycle counters.
Letsee.. adaptive packet rate, dynamicly resized transmit windows, acks as probes...
Haven't these people ever heard of ZModem?
-mazor
Do it. I'll use it. :)
The main reason I can see that the other idea is still useful is when you don't have control of the server. If you can put your own binaries on the server (which happens much more frequently), you can still install rz and sz in your home directory, but you can't usually keep an scp server unless they've already got one running. So there are more times when this may be useable than an scp-enabled ssh app.
Mod me down and I will become more powerful than you can possibly imagine!
One of the reasons is that TCP has a congestion control mechanism (it will back off if the sender doesn't get all acknowledgement back), but with such a high bandwidth-delay product, the congestion control mechanism is triggered, even when the routers are not dropping any traffic. It is currently unclear what the exact reason for this is (I've heard possible reasons from the sender floading the receiver to the random early packet dropping that most modern routers do). Scientists are looking into this right now. Problem is the sheer complexity of TCP Reno (The TCP implementation as you are using right now).
Of course, UDP can be used: that is much more aggresive then TCP, and can fill 98% of the available bandwidth, but has no congestion control, and can easily bring down a whole university network to it's knees if applied improperly. So a whole range of new TCP-alternatives is emerging, FastTCP one of them.
Currently, the Global Grid Forum (GGF), a standardization organisation is evaluating all these TCP-alternatives. You can check their most current results at: http://www.evl.uic.edu/eric/atp/ (Note that this is very much a work in progress!)