The most widely prevalent TCP implementations (which would be TCP Reno/NewReno and TCP SACK) do not directly use RTT as a measure of congestion. However, there have been several TCP versions/alternatives that use packet delay for precisely this purpose, most notably, TCP Vegas, and more recently, Fast TCP from the Caltech folks.
I agree however that this "replacement" for TCP from Rateless looks like some fluffy marketing spiel.
TCP does have problems scaling to high-bandwith + high delay (aka long, fat) networks. But there is no inherent limitation in TCP that would prevent it from operating in the Gbps ranges. With proper tuning, and sufficient cycles to burn, today's TCP stacks can fill Gbps pipes.
Also, the biggest benefit from TCP is not so much about its (in)ability to achieve near-100% link utilization. It's real usefulness is that it plays nice when multiple streams are sharing a link. Imagine a network where each flow tries to muscle out every other and indiscriminately swamps the network with its own packets. Congestion collapse would be the result.
This new protocol from Rateless appears to be suited only for dedicated pipes or for situations where it matters little if other flows are clobbered by the Rateless streams. There are plenty of UDP-based protocols that attempt to offer reliability + high speed. This one does not seem particularly striking.
For recent, serious proposals of reliable L4 protocols, google for FastTCP or XCP.
"Furthermore, the model ignores the sophistication in the TCP acknowledgement model. To avoid constraining throughput, TCP uses "sliding windows" and allows multiple outstanding frames to be transmitted before acknowledgement. In practice, TCP acknowledgements can apply to multiple segments, so this model overstates the impact of higher-layer protocol acknowledgements."
This reduces the "TCP" he uses to a stop-and-wait protocol.
Had something similar happen to my Thinkpad T22. Machine would suddenly "clack-clack", freeze for a few seconds and then recover. Called IBM Support, and got this Tech who gave me the usual "It's a software problem, call Microsoft" line. From previous experiences with Support, I knew that some of the reps were more responsive than others. So i just let it go and called again a few hours later. This time I had the tech actually listen to the clacking sounds over the phone. She got me on EasyServe. And just in time too: the HDD finally croaked after i took backups. Shipped the laptop to IBM on Wed. Got it back with a new hard drive on Friday.
The best part was i got back a 40 Gig disk in place of my old 30 Gig disk!
What really happens is direct feedback from routers along a transmission's path.
Errm, no. In currently deployed versions of TCP, routers *never* send direct feedback. Implicit feedback is obtained (at the sender) by sensing end-to-end packet loss or delay.
This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now.
TCP Vegas uses queueing delay as its congestion control measure. The delay is implicitly fed back to the source via the end-to-end delay experienced.
SCO's German site shut down
on
SCO SCO SCO!
·
· Score: 1
THE SUCCESSFUL injunction taken out by LinuxTag last week over SCO's claim that Unixware intellectual property is infringed has led to the shutdown of the German site.
The injunction, granted in a German court last week, meant that SCO downed its entire site in case parts of it detailing its claims against Linux would bring it into conflict with the law.
LinuxTag took out the injunction after it had asked SCO to substantiate its allegations that the Linux OS contained portions of Unix code.
You can't see that the SCO site isn't there because it's not there anymore.
The RTP-framing in the HDTV at 1.5Gbs transfer you describe indicates that UDP was the transport protocol used. What's new in the 401 Mbps result here is that TCP was used .
Hmm... Andreessen absent in NCSA's mosaic history
on
Andreesen "Grows Up"
·
· Score: 1
the Google Programming Contest. That way you'd at least have some monetary incentive ($10000 prize), and who knows if Google likes your idea, you might get hired.
Slashdot Mirror
The most widely prevalent TCP implementations (which would be TCP Reno/NewReno and TCP SACK) do not directly use RTT as a measure of congestion. However, there have been several TCP versions/alternatives that use packet delay for precisely this purpose, most notably, TCP Vegas, and more recently, Fast TCP from the Caltech folks.
I agree however that this "replacement" for TCP from Rateless looks like some fluffy marketing spiel.
TCP does have problems scaling to high-bandwith + high delay (aka long, fat) networks. But there is no inherent limitation in TCP that would prevent it from operating in the Gbps ranges. With proper tuning, and sufficient cycles to burn, today's TCP stacks can fill Gbps pipes.
Also, the biggest benefit from TCP is not so much about its (in)ability to achieve near-100% link utilization. It's real usefulness is that it plays nice when multiple streams are sharing a link. Imagine a network where each flow tries to muscle out every other and indiscriminately swamps the network with its own packets. Congestion collapse would be the result.
This new protocol from Rateless appears to be suited only for dedicated pipes or for situations where it matters little if other flows are clobbered by the Rateless streams. There are plenty of UDP-based protocols that attempt to offer reliability + high speed. This one does not seem particularly striking.
For recent, serious proposals of reliable L4 protocols, google for FastTCP or XCP.
-thonuzo
"Furthermore, the model ignores the sophistication in the TCP acknowledgement model. To avoid constraining throughput, TCP uses "sliding windows" and allows multiple outstanding frames to be transmitted before acknowledgement. In practice, TCP acknowledgements can apply to multiple segments, so this model overstates the impact of higher-layer protocol acknowledgements."
This reduces the "TCP" he uses to a stop-and-wait protocol.
Had something similar happen to my Thinkpad T22. Machine would suddenly "clack-clack", freeze for a few seconds and then recover. Called IBM Support, and got this Tech who gave me the usual "It's a software problem, call Microsoft" line. From previous experiences with Support, I knew that some of the reps were more responsive than others. So i just let it go and called again a few hours later. This time I had the tech actually listen to the clacking sounds over the phone. She got me on EasyServe. And just in time too: the HDD finally croaked after i took backups. Shipped the laptop to IBM on Wed. Got it back with a new hard drive on Friday. The best part was i got back a 40 Gig disk in place of my old 30 Gig disk!
Funny reading this story on /. this morning. I am driving down to Hutchinson, Kansas on Friday.
Perhaps i should take along a pancake.....
The latest issue of IEEE Spectrum has an interesting article on Why Apple, Sun, and Red Hat must merge.
at Liquid Nitrogen Ice Cream.
Errm, no. In currently deployed versions of TCP, routers *never* send direct feedback. Implicit feedback is obtained (at the sender) by sensing end-to-end packet loss or delay.
This is done in TCP Vegas, which was first proposed in 1994 and I think is fairly common now.
TCP Vegas uses queueing delay as its congestion control measure. The delay is implicitly fed back to the source via the end-to-end delay experienced.
Wednesday 04 June 2003, 10:47
THE SUCCESSFUL injunction taken out by LinuxTag last week over SCO's claim that Unixware intellectual property is infringed has led to the shutdown of the German site. The injunction, granted in a German court last week, meant that SCO downed its entire site in case parts of it detailing its claims against Linux would bring it into conflict with the law.
LinuxTag took out the injunction after it had asked SCO to substantiate its allegations that the Linux OS contained portions of Unix code.
You can't see that the SCO site isn't there because it's not there anymore.
at http://gnuart.onshore.com/.
The RTP-framing in the HDTV at 1.5Gbs transfer you describe indicates that UDP was the transport protocol used. What's new in the 401 Mbps result here is that TCP was used .
No mention of Marc Andreessen in NCSA's Mosaic history.
the Google Programming Contest. That way you'd at least have some monetary incentive ($10000 prize), and who knows if Google likes your idea, you might get hired.