To add to that, I think that one of the reasons that multicast has never taken off on the public net is that it's a layer 3 solution to a layer 7 problem.
The folks that have a vested interest in seeing it work globally are by definition not the ones with the ability to make it happen.
At an ISP where I previously worked, the stance on multicast was "We bill our customers per bit, and multicast requires additional effort for our engineering team so we can bill our customers for fewer bits. Eh?"
Given the "end-to-end, carrier in the middle" nature of the net, a successful "multi-casted" video delivery mechanism must be one that relies purely on the content source & the destinations. Which is exactly what this is.
This is hilarious. The transport layer can theoretically handle this perfectly well, via UDP multicast.
What's the most popular live video format on the public net right now?
Flash.
There is about 0 support for multicast in flash at this time.
Widespread public multicast has always been a chicken/egg situation. apps don't support it, so customers don't ask for it, so ISPs don't bother with it.
Still very useful in a sandbox type situation where you run the content and the eyeballs, but as a generally available solution it's not going to happen until someone makes it a strongly compelling feature of their killer app.
The unix history tree is really great. I think my favorite bit about it is how the vast majority of it is this huge family tree starting with K&R and branching out all over the place, and then tucked off in the corner is this little isolated line that says "Linux" on it...
...except that the command to change the IP doesn't have the word "mask" in it, so it wouldn't take.
nitpicking? Yes:-). force of habit, since I spend a lot of my time proofreading others' configs...
A similar gotcha that's a lot less obvious is trying to change the management vlan on an older stackable Catalyst switch running IOS (3500XL, etc). The damn thing only supports one vlan interface being up at a time, so you pretty much have to do it from the console or you're dead in the water.
Or, to be more verbose, I think there would be fewer scathing attitudes here if there were fewer dupes & misleading sensationalist headlines resulting from the editor failing to read & comprehend TFA before posting it.
And no, I'm not new here. What continues to amaze me is the incredibly insightful commentary from technical, social, & legal visionaries that continue to post here despite the background noise.
I have a lot of respect for Larry Roberts. The idea of only discarding a single packet per flow on a congested interface in order to slow things down is a good one.
If WRED didn't exist on every production-grade router made in the last 10+ years then there would certainly be a need for this technology. However, I'm not really sure how much benefit the "multi-flow fairness" concept would provide vs. just configuring WRED to discard only payload packets & not TCP control traffic. The tradeoff is the added complexity of the congestion avoidance mechanism having to be flow-aware, which increases cost, time to market, heat & power consumption, etc.
Such a technique combined with microflow policing would come closer to what he describes. In fact one could probably refer to the congestion avoidance technique described in the article as "adaptive microflow policing".
A pretty standard config used with OpenBSD's PF firewall is to prioritize ACKs in both directions so that a line congested in one direction is still useful in the other.
BTW, TCP has already been re-engineered; it's called SCTP. If you've got a custom high-bandwidth point-to-point application where you have complete control over both ends (mostly research stuff at this point), check it out.
A different approach to bandwidth management that is being developed by the major router vendors is the application-aware network. Imagine if the router was smart enough to read a field in an XML stream that indicates that this particular flow requires 64kbps or it should be dropped, it should have 256kbps to work well, and giving it more than 1mbps is not useful and you start to get the idea. That's just the tip of the iceberg.
Anyway, congestion control is useful & necessary, but "quality of service is no substitute for quantity of service"...
Windows XP has been one of the more successful products I've used on a computer, and it's provided me with a platform for nearly a decade of productivity. How is 5 years "nearly a decade"?
Perhaps it has something to do with the city of Boston being unwilling to bend over and take it from Verizon, so Verizon just ignores the whole downtown?
...too bad nobody's connected to it anymore. Once upon a time it was the largest exchange point on the east coast (and possibly the world). Years of crappy performance followed by replacement with a complicated ATM architecture that no one wanted to use ensured that several viablealternatives sprung up in the area, and thus its subsequent rapid decline.
The Amiga proved that in 1985, being able to deliver a better graphical solution than workstations costing tens of thousands more. The key now is to figure out which specifics you can use without driving up the cost nor without compromizing the design ideal of a general purpose computer.
The key now is figuring out what to do with your Amiga now that no one writes applications for it anymore.
Slashdot Mirror
At first I thought you said
"Busting Security Through Obesity!"
So you posted to slashdot on your "productive" day? :-)
Bill Clinton's policies were fine
Including the Communications Decency Act and the Digital Millennium Copyright Act?
& don't forget about Clinton's nuclear power policies!
To add to that, I think that one of the reasons that multicast has never taken off on the public net is that it's a layer 3 solution to a layer 7 problem.
The folks that have a vested interest in seeing it work globally are by definition not the ones with the ability to make it happen.
At an ISP where I previously worked, the stance on multicast was "We bill our customers per bit, and multicast requires additional effort for our engineering team so we can bill our customers for fewer bits. Eh?"
Given the "end-to-end, carrier in the middle" nature of the net, a successful "multi-casted" video delivery mechanism must be one that relies purely on the content source & the destinations. Which is exactly what this is.
See also Zattoo live p2p TV.
This is hilarious. The transport layer can theoretically handle this perfectly well, via UDP multicast.
What's the most popular live video format on the public net right now?
Flash.
There is about 0 support for multicast in flash at this time.
Widespread public multicast has always been a chicken/egg situation. apps don't support it, so customers don't ask for it, so ISPs don't bother with it.
Still very useful in a sandbox type situation where you run the content and the eyeballs, but as a generally available solution it's not going to happen until someone makes it a strongly compelling feature of their killer app.
The OpenBSD project loosing the remainder of their DARPA grant after Theo made public comments about the Iraq war is a really good example of this.
The unix history tree is really great. I think my favorite bit about it is how the vast majority of it is this huge family tree starting with K&R and branching out all over the place, and then tucked off in the corner is this little isolated line that says "Linux" on it...
...except that the command to change the IP doesn't have the word "mask" in it, so it wouldn't take.
:-). force of habit, since I spend a lot of my time proofreading others' configs...
nitpicking? Yes
A similar gotcha that's a lot less obvious is trying to change the management vlan on an older stackable Catalyst switch running IOS (3500XL, etc). The damn thing only supports one vlan interface being up at a time, so you pretty much have to do it from the console or you're dead in the water.
I love it when people know what they're talking about :-)
The Suburban Auto Group already came up with a better idea: Trunk Monkey Emotional Support!
One word: kdawson
Or, to be more verbose, I think there would be fewer scathing attitudes here if there were fewer dupes & misleading sensationalist headlines resulting from the editor failing to read & comprehend TFA before posting it.
And no, I'm not new here. What continues to amaze me is the incredibly insightful commentary from technical, social, & legal visionaries that continue to post here despite the background noise.
It's a space station...
Excellent themable 3D remake of Scorched Earth:
http://www.scorched3d.co.uk/
Meat Fighter!
http://www.meatfighter.com/
And there's always Tux Racer:
http://tuxracer.sourceforge.net/
Research into Ion engines is promising, but every time I see something like this I reminisce about the promises of the nuclear pulse drive.
I'd be interested to see the age spread numbers on this study...
Where is "here"? Online?
Let us not confuse adaptive backoff with queuing :-).
I have a lot of respect for Larry Roberts. The idea of only discarding a single packet per flow on a congested interface in order to slow things down is a good one.
If WRED didn't exist on every production-grade router made in the last 10+ years then there would certainly be a need for this technology. However, I'm not really sure how much benefit the "multi-flow fairness" concept would provide vs. just configuring WRED to discard only payload packets & not TCP control traffic. The tradeoff is the added complexity of the congestion avoidance mechanism having to be flow-aware, which increases cost, time to market, heat & power consumption, etc.
Such a technique combined with microflow policing would come closer to what he describes. In fact one could probably refer to the congestion avoidance technique described in the article as "adaptive microflow policing".
A pretty standard config used with OpenBSD's PF firewall is to prioritize ACKs in both directions so that a line congested in one direction is still useful in the other.
BTW, TCP has already been re-engineered; it's called SCTP. If you've got a custom high-bandwidth point-to-point application where you have complete control over both ends (mostly research stuff at this point), check it out.
A different approach to bandwidth management that is being developed by the major router vendors is the application-aware network. Imagine if the router was smart enough to read a field in an XML stream that indicates that this particular flow requires 64kbps or it should be dropped, it should have 256kbps to work well, and giving it more than 1mbps is not useful and you start to get the idea. That's just the tip of the iceberg.
Anyway, congestion control is useful & necessary, but "quality of service is no substitute for quantity of service"...
If so you could run CUPS on cups... and that'd just be spiffy. But regardless of the OS, I'm sure they'd port Java to it...
Perhaps it has something to do with the city of Boston being unwilling to bend over and take it from Verizon, so Verizon just ignores the whole downtown?
I'm stoked that Sahana - a project to develop a FOSS web-based system for disaster management has been selected again for GSOC. Thanks Goggle!
Zhe Goggles, zhey do noting!
...too bad nobody's connected to it anymore. Once upon a time it was the largest exchange point on the east coast (and possibly the world). Years of crappy performance followed by replacement with a complicated ATM architecture that no one wanted to use ensured that several viable alternatives sprung up in the area, and thus its subsequent rapid decline.
Which is why we use RSync...
The Amiga proved that in 1985, being able to deliver a better graphical solution than workstations costing tens of thousands more. The key now is to
:-)
figure out which specifics you can use without driving up the cost nor without compromizing the design ideal of a general purpose computer.
The key now is figuring out what to do with your Amiga now that no one writes applications for it anymore.
I suggest NetBSD