Until finally, they are throttling once you hit 100KB of bandwidth and they can advertise the world's fastest wireless network since no one can use it.
Yes, that is absolutely a realistic scenario, and definitely not alarmist exaggeration. Got a target date you expect this prediction to be falsifiable?
Meanwhile, on planet Earth where I live, the 95% figure has actually gotten bigger, and they're throttling people AFTER they hit 5%, not asymptotically approaching 5 GB.
Google and it's users seem to be doing a pretty good job of utilizing free text to locate documents.
Or, to put it another way, the problem you're expecting each of these government DBAs to routinely solve required a 100 Billion dollar company which makes a point of hiring geniuses in order to tackle.
I don't think "but Google can do it!" is synonymous with "that problem isn't a big deal"
I'll probably end up canceling entirely and go back to waiting for a service to come along that does streaming right.
This is worth emphasizing. This isn't like when Microsoft does something bad and we all praise Apple or Linux. For most of the people complaining that Netflix isn't giving them what they want, there is no other company out there who is.
Know who the closest competitor is, providing unlimited streaming of HD content to your home with a huge selection? Your friendly neighborhood cable company. I'd wager they're charging you quite a bit more than $8/month, and don't let you play everything on demand without extra charges beyond that.
Ahhh, indeed that's what I was afraid of, you still need CSMA with back-off times since the medium (the air) is still open to other transmitters. So essentially the "full duplex" here is just using one frequency for both directions at once, just the "double traffic" summarized by TFA. Thanks for the clarification.
And for what it's worth, I've always heard good things about Microsoft Research. It's when the researched ideas make their way (or fail to make their way) into finished products with price tags on them that the friction arises...
In wired Ethernet topologies, going full duplex yields significantly more than double the throughput, since you no longer have collisions, back-offs, and re-sends. The article doesn't elaborate whether their full-duplex wireless would still be multi-access (think WiFi, with many clients on the same AP and same channels) or if each frequency would be carved out for one client and the base-station (in which case you'd see the same gains you did on wired Ethernet).
M point is that while they cite "allow a doubling of network traffic", the reality is even better than that. Full duplex gets you more than double throughput, as well as improved jitter/latency since you no longer have to randomly re-transmit frames (or randomly wait to transmit, as with WiFi collision avoidance).
If it really costs $13,800 to produce an iPad in a way that doesn't ruin the lives of workers
And by "ruin the lives", you mean improve the lives of those living badly? What do you imagine is the alternative for the poor unfortunate Foxconn worker who Apple employed, if he's not making iPads? Idyllic and prosperous farm life that he was stolen away from by cruel task-masters?
The "trillions for bankers" weren't subsidies, they were loans. Said loans were already paid back, with interest.
The Ethanol subsidies aren't getting paid back, and they aren't all going to "farmers" (unless you count massive Ag companies like Cargill or ConAgra as "farmers"), and they aren't even an effective use of subsidy to fund alternative fuels. The real advocates for bio-fuels will tell you that sugar cane works better than corn, and switchgrass works better than cane.
Corn ethanol subidies were always a gift to the Ag companies, which were extra important due to the early position of Iowa in the presidential primaries.
My understanding is that power usage could be remotely controlled in case of emergency.
And here on Slashdot, we all love giving the government (and utility companies) extra power and control over ourselves, which we trust them only to use responsibly in proper emergencies, right?
When the load is lower (like at night) they turn down generation (stop using goal, gas, oil, etc) at various power plants. As the load rises, they turn those plants back up to meet that load. The fact that the grid isn't "at capacity" doesn't mean you're wasting energy, it means you're saving energy, by not burning as much fuel. The grid itself does have limits too, but not running it at those limits is like driving your truck around without loading it down to 100% of it's carrying capacity. That's not exactly waste.
Now that's not to say that there isn't energy wasted in the grid due to other factors like transmission, but a surplus of "grid capacity" is not the same thing as a surplus (or waste) of power.
And when "Google Kids" fails to filter something you consider inappropriate (either because they don't share your views, or just due to the challenges and limitations of determining and filtering content automatically) then lawsuits and bad press ensues. Bad for the Google brand all around.
In general, Google's strategy seems to be focused on providing tons of really great free, best effort services. If Gmail fails to deliver your email one day, it's not like you can sue. If Google Maps gives you wrong directions, [shrug], use Mapquest. But if Google Kids started showing kids porn/violence/subversive material, I think there would be a fair amount of public outrage.
I've worked as contractor, then consultant, now employee, at different places. Even with my skills and motivation remaining the same, one thing I've noticed as an employee is that the company trusts and believes me less than it does consultants.
With three years of specific knowledge in the design, implementation, and support details of our actual network, I can tell them that solution X won't be a good fit for us and they'll ignore it. An IBM consultant can come in an do a week of interviews, two weeks of reading documentation, and tell them the same exact thing I did, but now they take it very seriously. It's not about skills or experience - four years ago I was that IBM consultant. It's about context.
They're paying me a moderate amount to work on whatever projects my supervisor assigns to me, and they'll keep on paying me that same moderate amount unless I do something really awful. They're paying the consultant(s) a huge amount specifically for the task of investigating this option and delivering a formal recommendation. They can document somewhere that "senior management engaged a highly regarded firm to evaluate the options and said firm provided the attached 75 page recommendation" - as opposed to "one of the guys from the network department told us our idea was dumb." Also, if they're paying $200/hour for advice, they'll take it more seriously than advice they're "getting for free" (obviously salaries aren't free, but there's no marginal dollar cost for additional work)
Similarly, not all employees are created equal, and again context matters. Being in a Profit Center rather than a Cost Center makes a huge difference. In a profit center, they want the best possible perceived quality, since that can translate into increased profits. In a cost center, they basically want people who are good enough not to screw anything up, but there's no point in spending extra on excellence.
Note that I said perceived quality. For both consultants and employees, Perceived Value is more important to your advancement and compensation than Actual Value. This leads to TFA's perception that having actual value doesn't matter, but it's not quite that simple. I still feel better about my job when I know I'm doing it well and providing value to the company, and that's a good thing. But if I don't help my management to see that, and some charismatic underachiever puts all his effort into appearing valuable, I won't be all that shocked when he gets promoted and I don't.
There's no easy rules about unions good/bad or consultants good/bad or working "hard" good/bad, it's the context that matters.
This is true, and furthermore "shaping" is one of the nicer/friendlier methods of managing traffic contention.
The "my plan says 10 Meg I demand 10 Meg!" argument is simply not technically valid. If the ISP has 10G of upstream to a carrier and more than 1,000 customers, it's not physically possible for everyone to run unlimited 10 Mbps all the time. So now that there's a possibility of contention, the good/bad lies in how the provider limits you, not if.
Possibly the worst is usage caps. After transferring X GB of data they either up-charge you or knock your speed way down. You don't want this.
Next is free-for-all. This just means your traffic and everyone else's goes into a buffer, waiting to transmit across the congested link. As the buffer gets full, new packets tail-drop. Better than caps, but not much. Google "bufferbloat" to see some of the problems this creates, but the quick answer is that it's bad for VoIP/streaming and it actually worsens the congestion itself. AQM/WRED can mitigate this a bit, but it still loses valuable information by keeping all traffic undifferentiated.
Then there's policing. This just means that if your traffic exceeds a certain rate (let's say they limit your 10M to 8M) it's dropped immediately. Not as bad as it sounds, but TCP still would rather a packet be delayed for a few msec than dropped and retransmitted.
Lastly is shaping. This attempts to take your input and limit it to a slower output, just like policing, but instead of dropping your packets, now we delay them. If you transmit at 10M, we send your first 8M then wait a second before sending more. TCP windowing adjusts more gracefully and your connection just becomes a working 8M without so much delay and retransmission.
People get irritated at the idea that someone somewhere is doing something to their Internet traffic, but as contention/congestion management goes, this sort of shaping is actually one of the best options.
And why optimize for the common case when you can optimize for "a guy in the SA forums" ?
Re:Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 1
I understand that QoS policies can be written neutral, my concern is that they won't be. Dismissing the actions of ISPs and carriers as "a market problem" doesn't really constitute useful policy. Similarly, ignoring all network hosts who aren't FLOSS apps written after 2011 is also not helpful.
The issues being examined in the bufferbloat discussions are not about whether there is a technically possible solution somewhere in the world (indeed, both ECN and AQM have been around for a while). The issues relate to providing a robust Internet which can be/is administered by a large and diverse group of self-interested organizations in such a way that it productively serves a vastly diverse population of clients. Ignoring the ISPs, carriers, and non-FLOSS users isn't solving the problem, it's ignoring the problem.
Re:Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 1
Indeed, when I referenced "net neutrality", I wasn't referring to the specific implementation by the FCC, but rather the concept itself. The actual language does include an exception for "reasonable network management", but many network neutrality proponents were (I think somewhat rightfully) concerned at the size and flexibility of such a loophole.
Several providers saw their networks being loaded up with bit-torrent, and believed that limiting that specific protocol would constitute "reasonable network management". Naturally, many readers of slashdot disagreed. Also as I mentioned in the previous comment, I believe a triple-play provider could plausibly concoct a "reasonable network management" policy that would favor their own traffic without referencing themselves specifically. Say that Comcast used a different UDP port range for their RTP/VoIP bearer than Vonage did. Or say that to avoid allowing users to overwhelm priority queues, they refused to mark VoIP based on ports, but rather required it be destined for "verified legitimate voice gateways" (ie those administered by or registered formally with the provider, thus preventing Skype direct calls and the like from being priority-queued).
I am of course speculating wildly, but my point is that these unintended consequences are conceivable and that proponents of absolute network neutrality should be aware of the trade-offs with QoS (and vice versa). Also that while "Net Neutrality is supposed to prevent these companies from taking unfair advantage of their position as network providers, not about making them worse network providers", history is littered with laws and corporate policies that were "supposed to" achieve all sorts of laudable goals, but instead lead to unexpected exploitation by self-interested parties. I have no perfect solution in mind; I'm simply trying to call attention to the trade-offs involved and warn of possible unintended consequences.
Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 2
That is indeed part of the solution Jim Gettys suggests - Active Queue Management or Random Early Detect.
The first problem is that a ton of transit systems on the Internet (like indeed a ton of systems everywhere) are effectively running the default behaviors in this respect, with no special tuning. That means FIFO with whatever queue size is available.
The second is that even if all the ISP operators decided to fix this, "QoS stuff" has the potential to run afoul of Network Neutrality. The current thinking is that they shouldn't be discriminating between "bulk/throughput" packets and others. Some would suggest discrimination between traffic types is okay, so long as you don't discriminate between traffic sources (ie prioritize all VoIP, but don't let Comcast give Comcast VoIP preference over Vonage VoIP) but implementation would be tricky - all too easy to implement a "vendor neutral" policy that coincidentally doesn't seem to identify Vonage's traffic quite right.
The simplest and most neutral solution to all this is simply to decrease the buffer size in those big default FIFO queues. Even the bulk/throughput packets won't really suffer from that - TCP is specifically designed to have packets dropped in a timely manner, rather than held in a queue for a long time. One of the problem behaviors that Jim identifies is that if your real RTT to say, a server in California, is 40 msec, but there's 4 seconds worth of delay in the buffers. TCP will send a window full of data (let's say 64K) then wait for a reply for 40, 80, maybe 120 msec. Not getting it, he sends the whole window again. And again. And again. Finally an ACK squeezes through, and the process begins again. Instead of shrinking his transmission size, he does the opposite - he sends big multiples of every packet, making the congestion worse.
So your premise is that doing nothing requires more intelligence than performing a task?
If you read the parent another time or two, you may pick up that the premise is more like "obedience does not imply, or even correlate well with, intelligence".
A very interesting idea, but I think spam shows us that whoever actually developed and implemented such systems would most likely use them to intentionally skew the data towards something they could profit from, rather than adding noise to degrade the data.
How much of your spam is not related to making money off you?
I imagine this massive and convincing network of fake people would suddenly discover that they all love Axe body spray...
Do I need to paste command outputs from the Distro switches in my building which are routing between 96 different VLAN interfaces, all with IP addresses on them? Your statements are accurate for 2924/3548 generation switches, but modern "layer 3 switches" are actually layer 3 switches, capable of routing packets across network boundaries.
If you're referring to the fact that the EARL ASICs on the 6500 supervisors are separate from the MSFC which runs the routing protocols, then that's correct but specific to that platform (and 7600's, which are almost the same hardware). However that's still the routing protocol, not the routing. The PFC lives on the supervisor and contains the Layer 3 forwarding information, thus "routing" those packets (L3 switching really, but you don't seem to believe in L3 switching).
Classic "mls" is also much in the minority, as nearly all of Cisco's "multilayer switching" is done by CEF these days, not requiring a punt to the MSFC or "router" even for the first packet of a flow.
I guess we're gonna have to disagree here. "The" definition is not "the definition", since there's many definitions. If you want to appeal to an authoritative definition here, Wikipedia says...
"The term commonly refers to a network bridge that processes and routes data at the data link layer (layer 2) of the OSI model. Switches that additionally process data at the network layer (layer 3 and above) are often referred to as Layer 3 switches or multilayer switches."
IOS on switches isn't only about consistency (else they wouldn't be rolling out a whole new generation of NX-OS) but rather about adding all the valuable routing and services code they've spent years developing to a wider array of devices.
I can run BGP and OSPF on a 3560 "switch". You can't tell me that's a pure layer 2 device.
Re:Network meltdown due to hub cross-connects
on
Stupid Data Center Tricks
·
· Score: 5, Informative
I'm CCNP, taking my CCIE lab next month, I'll give this a shot.
Yes, the "cow goes moo" level definitions you get are "hub = L1, switch = L2, router = L3" but the reality is more complex. A hub is essentially a multi-port repeater. It just takes data in on one port and spews it out all the others. A switch is a device that uses hardware (not CPU/software) to consult a simple lookup table which tells it which port(s) to forward the data, and does so very fast (if not always wire-speed). Think like the GPU/graphics card in your PC. Something specific super fast. A router is a device that understands network hierarchy/topology (in the case of IP, this is mainly about subnetting, but there are plenty of other routed protocols) and can traverse that hierarchy/topology to determine the next hop towards a destination.
Now, because of the protocol addressing in Ethernet and IP, these lend themselves easily to hub/switch/router = L1/L2/L3, but they're not really defined that way.
These days, most Cisco switches (3560, 3750, 6500, etc) run IOS, the software which can do routing, and which uses CEF. CEF in a nutshell takes the routing table (which would best be represented as a tree) and compiles it into a "FIB", which is essentially a flat lookup-table version of that same (layer 3, IP) table. It also caches a copy of the L2 header that the router needs to forward an L3 packet. The hardware (ASICs) in the switches hold this FIB, and thus allow them to "switch" IP/L3 packets at fast rates and without CPU intervention, thus making them still "switches", even if they run a routing protocol and build a routing table.
Meanwhile, when Cisco refers to a "router" in marketing terms, they're talking about a device with a (relatively) powerful CPU, which can not only perform actual routing, but also usually more CPU-intensive inter-network tasks like Netflow and NBAR.
Except market share is the wrong way to measure it.
Apple's market cap is now bigger than Microsoft's, and profit-wise Nintendo's DS is even bigger than Playstation. They're selling cheaper, lower-powered systems but still doing victory laps with huge grins on their faces while Sony is trying to convince you that Playstation Move isn't just a more-expensive two-years-later version of the Wii.
Honestly, deep down, do you really think that two years from now the iPhone will no longer be dominant, just because Apple wasn't gracious enough about these antenna problems?
As a long-time Doom player... When I run into that badass, with all the ammo I can possibly carry, and I empty ALL of it into that creature, it should die.
And here we see the moving target for "immersion" and why it's so hard to hit. Up above, another commenter complains "if I shoot a guy dead in the face (I'm looking at YOU, EA and MoH series) then they should fricking die" - a large number of bullets doesn't really seem to improve immersion. Meanwhile, if the enemy is a tank - an actual tank, with thick armor - and shooting it with your 9mm pistol doesn't penetrate the armor, then shooting it 137 times shouldn't solve the problem by depleting hit points.
This problem actually stumped me for a while in Crysis. At one point, you're on foot and tasked with destroying some tanks. Nothing I did to them - even rocket launchers, appeared to harm them. I finally resorted to Google. Turns out, I had to shoot them with the rocket launcher... three times. No apparent damage after the first one, but three is the magic number. Shooter veterans - yourself included - are likely nodding along "well duh, some bosses take a bunch of shots." But this makes no more consistent or real-world sense than the indestructible wooden doors.
Slashdot Mirror
Until finally, they are throttling once you hit 100KB of bandwidth and they can advertise the world's fastest wireless network since no one can use it.
Yes, that is absolutely a realistic scenario, and definitely not alarmist exaggeration. Got a target date you expect this prediction to be falsifiable?
Meanwhile, on planet Earth where I live, the 95% figure has actually gotten bigger, and they're throttling people AFTER they hit 5%, not asymptotically approaching 5 GB.
Google and it's users seem to be doing a pretty good job of utilizing free text to locate documents.
Or, to put it another way, the problem you're expecting each of these government DBAs to routinely solve required a 100 Billion dollar company which makes a point of hiring geniuses in order to tackle.
I don't think "but Google can do it!" is synonymous with "that problem isn't a big deal"
Right, I'm not disagreeing with your definition, just pointing out that it doesn't actually exist. I share your dream, but it remains a dream only.
I'll probably end up canceling entirely and go back to waiting for a service to come along that does streaming right.
This is worth emphasizing. This isn't like when Microsoft does something bad and we all praise Apple or Linux. For most of the people complaining that Netflix isn't giving them what they want, there is no other company out there who is.
Know who the closest competitor is, providing unlimited streaming of HD content to your home with a huge selection? Your friendly neighborhood cable company. I'd wager they're charging you quite a bit more than $8/month, and don't let you play everything on demand without extra charges beyond that.
Ahhh, indeed that's what I was afraid of, you still need CSMA with back-off times since the medium (the air) is still open to other transmitters. So essentially the "full duplex" here is just using one frequency for both directions at once, just the "double traffic" summarized by TFA. Thanks for the clarification.
And for what it's worth, I've always heard good things about Microsoft Research. It's when the researched ideas make their way (or fail to make their way) into finished products with price tags on them that the friction arises...
In wired Ethernet topologies, going full duplex yields significantly more than double the throughput, since you no longer have collisions, back-offs, and re-sends. The article doesn't elaborate whether their full-duplex wireless would still be multi-access (think WiFi, with many clients on the same AP and same channels) or if each frequency would be carved out for one client and the base-station (in which case you'd see the same gains you did on wired Ethernet).
M point is that while they cite "allow a doubling of network traffic", the reality is even better than that. Full duplex gets you more than double throughput, as well as improved jitter/latency since you no longer have to randomly re-transmit frames (or randomly wait to transmit, as with WiFi collision avoidance).
If it really costs $13,800 to produce an iPad in a way that doesn't ruin the lives of workers
And by "ruin the lives", you mean improve the lives of those living badly? What do you imagine is the alternative for the poor unfortunate Foxconn worker who Apple employed, if he's not making iPads? Idyllic and prosperous farm life that he was stolen away from by cruel task-masters?
The "trillions for bankers" weren't subsidies, they were loans. Said loans were already paid back, with interest.
The Ethanol subsidies aren't getting paid back, and they aren't all going to "farmers" (unless you count massive Ag companies like Cargill or ConAgra as "farmers"), and they aren't even an effective use of subsidy to fund alternative fuels. The real advocates for bio-fuels will tell you that sugar cane works better than corn, and switchgrass works better than cane.
Corn ethanol subidies were always a gift to the Ag companies, which were extra important due to the early position of Iowa in the presidential primaries.
My understanding is that power usage could be remotely controlled in case of emergency.
And here on Slashdot, we all love giving the government (and utility companies) extra power and control over ourselves, which we trust them only to use responsibly in proper emergencies, right?
When the load is lower (like at night) they turn down generation (stop using goal, gas, oil, etc) at various power plants. As the load rises, they turn those plants back up to meet that load. The fact that the grid isn't "at capacity" doesn't mean you're wasting energy, it means you're saving energy, by not burning as much fuel. The grid itself does have limits too, but not running it at those limits is like driving your truck around without loading it down to 100% of it's carrying capacity. That's not exactly waste.
Now that's not to say that there isn't energy wasted in the grid due to other factors like transmission, but a surplus of "grid capacity" is not the same thing as a surplus (or waste) of power.
And when "Google Kids" fails to filter something you consider inappropriate (either because they don't share your views, or just due to the challenges and limitations of determining and filtering content automatically) then lawsuits and bad press ensues. Bad for the Google brand all around.
In general, Google's strategy seems to be focused on providing tons of really great free, best effort services. If Gmail fails to deliver your email one day, it's not like you can sue. If Google Maps gives you wrong directions, [shrug], use Mapquest. But if Google Kids started showing kids porn/violence/subversive material, I think there would be a fair amount of public outrage.
I've worked as contractor, then consultant, now employee, at different places. Even with my skills and motivation remaining the same, one thing I've noticed as an employee is that the company trusts and believes me less than it does consultants.
With three years of specific knowledge in the design, implementation, and support details of our actual network, I can tell them that solution X won't be a good fit for us and they'll ignore it. An IBM consultant can come in an do a week of interviews, two weeks of reading documentation, and tell them the same exact thing I did, but now they take it very seriously. It's not about skills or experience - four years ago I was that IBM consultant. It's about context.
They're paying me a moderate amount to work on whatever projects my supervisor assigns to me, and they'll keep on paying me that same moderate amount unless I do something really awful. They're paying the consultant(s) a huge amount specifically for the task of investigating this option and delivering a formal recommendation. They can document somewhere that "senior management engaged a highly regarded firm to evaluate the options and said firm provided the attached 75 page recommendation" - as opposed to "one of the guys from the network department told us our idea was dumb." Also, if they're paying $200/hour for advice, they'll take it more seriously than advice they're "getting for free" (obviously salaries aren't free, but there's no marginal dollar cost for additional work)
Similarly, not all employees are created equal, and again context matters. Being in a Profit Center rather than a Cost Center makes a huge difference. In a profit center, they want the best possible perceived quality, since that can translate into increased profits. In a cost center, they basically want people who are good enough not to screw anything up, but there's no point in spending extra on excellence.
Note that I said perceived quality. For both consultants and employees, Perceived Value is more important to your advancement and compensation than Actual Value. This leads to TFA's perception that having actual value doesn't matter, but it's not quite that simple. I still feel better about my job when I know I'm doing it well and providing value to the company, and that's a good thing. But if I don't help my management to see that, and some charismatic underachiever puts all his effort into appearing valuable, I won't be all that shocked when he gets promoted and I don't.
There's no easy rules about unions good/bad or consultants good/bad or working "hard" good/bad, it's the context that matters.
This is true, and furthermore "shaping" is one of the nicer/friendlier methods of managing traffic contention.
The "my plan says 10 Meg I demand 10 Meg!" argument is simply not technically valid. If the ISP has 10G of upstream to a carrier and more than 1,000 customers, it's not physically possible for everyone to run unlimited 10 Mbps all the time. So now that there's a possibility of contention, the good/bad lies in how the provider limits you, not if.
Possibly the worst is usage caps. After transferring X GB of data they either up-charge you or knock your speed way down. You don't want this.
Next is free-for-all. This just means your traffic and everyone else's goes into a buffer, waiting to transmit across the congested link. As the buffer gets full, new packets tail-drop. Better than caps, but not much. Google "bufferbloat" to see some of the problems this creates, but the quick answer is that it's bad for VoIP/streaming and it actually worsens the congestion itself. AQM/WRED can mitigate this a bit, but it still loses valuable information by keeping all traffic undifferentiated.
Then there's policing. This just means that if your traffic exceeds a certain rate (let's say they limit your 10M to 8M) it's dropped immediately. Not as bad as it sounds, but TCP still would rather a packet be delayed for a few msec than dropped and retransmitted.
Lastly is shaping. This attempts to take your input and limit it to a slower output, just like policing, but instead of dropping your packets, now we delay them. If you transmit at 10M, we send your first 8M then wait a second before sending more. TCP windowing adjusts more gracefully and your connection just becomes a working 8M without so much delay and retransmission.
People get irritated at the idea that someone somewhere is doing something to their Internet traffic, but as contention/congestion management goes, this sort of shaping is actually one of the best options.
And why optimize for the common case when you can optimize for "a guy in the SA forums" ?
I understand that QoS policies can be written neutral, my concern is that they won't be. Dismissing the actions of ISPs and carriers as "a market problem" doesn't really constitute useful policy. Similarly, ignoring all network hosts who aren't FLOSS apps written after 2011 is also not helpful.
The issues being examined in the bufferbloat discussions are not about whether there is a technically possible solution somewhere in the world (indeed, both ECN and AQM have been around for a while). The issues relate to providing a robust Internet which can be/is administered by a large and diverse group of self-interested organizations in such a way that it productively serves a vastly diverse population of clients. Ignoring the ISPs, carriers, and non-FLOSS users isn't solving the problem, it's ignoring the problem.
Indeed, when I referenced "net neutrality", I wasn't referring to the specific implementation by the FCC, but rather the concept itself. The actual language does include an exception for "reasonable network management", but many network neutrality proponents were (I think somewhat rightfully) concerned at the size and flexibility of such a loophole.
Several providers saw their networks being loaded up with bit-torrent, and believed that limiting that specific protocol would constitute "reasonable network management". Naturally, many readers of slashdot disagreed. Also as I mentioned in the previous comment, I believe a triple-play provider could plausibly concoct a "reasonable network management" policy that would favor their own traffic without referencing themselves specifically. Say that Comcast used a different UDP port range for their RTP/VoIP bearer than Vonage did. Or say that to avoid allowing users to overwhelm priority queues, they refused to mark VoIP based on ports, but rather required it be destined for "verified legitimate voice gateways" (ie those administered by or registered formally with the provider, thus preventing Skype direct calls and the like from being priority-queued).
I am of course speculating wildly, but my point is that these unintended consequences are conceivable and that proponents of absolute network neutrality should be aware of the trade-offs with QoS (and vice versa). Also that while "Net Neutrality is supposed to prevent these companies from taking unfair advantage of their position as network providers, not about making them worse network providers", history is littered with laws and corporate policies that were "supposed to" achieve all sorts of laudable goals, but instead lead to unexpected exploitation by self-interested parties. I have no perfect solution in mind; I'm simply trying to call attention to the trade-offs involved and warn of possible unintended consequences.
The first problem is that a ton of transit systems on the Internet (like indeed a ton of systems everywhere) are effectively running the default behaviors in this respect, with no special tuning. That means FIFO with whatever queue size is available.
The second is that even if all the ISP operators decided to fix this, "QoS stuff" has the potential to run afoul of Network Neutrality. The current thinking is that they shouldn't be discriminating between "bulk/throughput" packets and others. Some would suggest discrimination between traffic types is okay, so long as you don't discriminate between traffic sources (ie prioritize all VoIP, but don't let Comcast give Comcast VoIP preference over Vonage VoIP) but implementation would be tricky - all too easy to implement a "vendor neutral" policy that coincidentally doesn't seem to identify Vonage's traffic quite right.
The simplest and most neutral solution to all this is simply to decrease the buffer size in those big default FIFO queues. Even the bulk/throughput packets won't really suffer from that - TCP is specifically designed to have packets dropped in a timely manner, rather than held in a queue for a long time. One of the problem behaviors that Jim identifies is that if your real RTT to say, a server in California, is 40 msec, but there's 4 seconds worth of delay in the buffers. TCP will send a window full of data (let's say 64K) then wait for a reply for 40, 80, maybe 120 msec. Not getting it, he sends the whole window again. And again. And again. Finally an ACK squeezes through, and the process begins again. Instead of shrinking his transmission size, he does the opposite - he sends big multiples of every packet, making the congestion worse.
So your premise is that doing nothing requires more intelligence than performing a task?
If you read the parent another time or two, you may pick up that the premise is more like "obedience does not imply, or even correlate well with, intelligence".
A very interesting idea, but I think spam shows us that whoever actually developed and implemented such systems would most likely use them to intentionally skew the data towards something they could profit from, rather than adding noise to degrade the data.
How much of your spam is not related to making money off you?
I imagine this massive and convincing network of fake people would suddenly discover that they all love Axe body spray...
I won't burn too much more time trying to assert how many Cisco engineers I've talked to; I'll stick to the technical stuff.
"Sure, they can run a routing process, but they don't route. They only have an IP address for management" is simply incorrect:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_50_se/configuration/guide/swiprout.html
Do I need to paste command outputs from the Distro switches in my building which are routing between 96 different VLAN interfaces, all with IP addresses on them? Your statements are accurate for 2924/3548 generation switches, but modern "layer 3 switches" are actually layer 3 switches, capable of routing packets across network boundaries.
If you're referring to the fact that the EARL ASICs on the 6500 supervisors are separate from the MSFC which runs the routing protocols, then that's correct but specific to that platform (and 7600's, which are almost the same hardware). However that's still the routing protocol, not the routing. The PFC lives on the supervisor and contains the Layer 3 forwarding information, thus "routing" those packets (L3 switching really, but you don't seem to believe in L3 switching).
Classic "mls" is also much in the minority, as nearly all of Cisco's "multilayer switching" is done by CEF these days, not requiring a punt to the MSFC or "router" even for the first packet of a flow.
"The term commonly refers to a network bridge that processes and routes data at the data link layer (layer 2) of the OSI model. Switches that additionally process data at the network layer (layer 3 and above) are often referred to as Layer 3 switches or multilayer switches."
http://en.wikipedia.org/wiki/Network_switch
IOS on switches isn't only about consistency (else they wouldn't be rolling out a whole new generation of NX-OS) but rather about adding all the valuable routing and services code they've spent years developing to a wider array of devices.
I can run BGP and OSPF on a 3560 "switch". You can't tell me that's a pure layer 2 device.
I'm CCNP, taking my CCIE lab next month, I'll give this a shot.
Yes, the "cow goes moo" level definitions you get are "hub = L1, switch = L2, router = L3" but the reality is more complex.
A hub is essentially a multi-port repeater. It just takes data in on one port and spews it out all the others.
A switch is a device that uses hardware (not CPU/software) to consult a simple lookup table which tells it which port(s) to forward the data, and does so very fast (if not always wire-speed). Think like the GPU/graphics card in your PC. Something specific super fast.
A router is a device that understands network hierarchy/topology (in the case of IP, this is mainly about subnetting, but there are plenty of other routed protocols) and can traverse that hierarchy/topology to determine the next hop towards a destination.
Now, because of the protocol addressing in Ethernet and IP, these lend themselves easily to hub/switch/router = L1/L2/L3, but they're not really defined that way.
These days, most Cisco switches (3560, 3750, 6500, etc) run IOS, the software which can do routing, and which uses CEF. CEF in a nutshell takes the routing table (which would best be represented as a tree) and compiles it into a "FIB", which is essentially a flat lookup-table version of that same (layer 3, IP) table. It also caches a copy of the L2 header that the router needs to forward an L3 packet. The hardware (ASICs) in the switches hold this FIB, and thus allow them to "switch" IP/L3 packets at fast rates and without CPU intervention, thus making them still "switches", even if they run a routing protocol and build a routing table.
Meanwhile, when Cisco refers to a "router" in marketing terms, they're talking about a device with a (relatively) powerful CPU, which can not only perform actual routing, but also usually more CPU-intensive inter-network tasks like Netflow and NBAR.
Well, since nobody reads the articles, just the summaries, that actually seems rather efficient.
Except market share is the wrong way to measure it.
Apple's market cap is now bigger than Microsoft's, and profit-wise Nintendo's DS is even bigger than Playstation. They're selling cheaper, lower-powered systems but still doing victory laps with huge grins on their faces while Sony is trying to convince you that Playstation Move isn't just a more-expensive two-years-later version of the Wii.
Honestly, deep down, do you really think that two years from now the iPhone will no longer be dominant, just because Apple wasn't gracious enough about these antenna problems?
And here we see the moving target for "immersion" and why it's so hard to hit. Up above, another commenter complains "if I shoot a guy dead in the face (I'm looking at YOU, EA and MoH series) then they should fricking die" - a large number of bullets doesn't really seem to improve immersion. Meanwhile, if the enemy is a tank - an actual tank, with thick armor - and shooting it with your 9mm pistol doesn't penetrate the armor, then shooting it 137 times shouldn't solve the problem by depleting hit points.
This problem actually stumped me for a while in Crysis. At one point, you're on foot and tasked with destroying some tanks. Nothing I did to them - even rocket launchers, appeared to harm them. I finally resorted to Google. Turns out, I had to shoot them with the rocket launcher... three times. No apparent damage after the first one, but three is the magic number. Shooter veterans - yourself included - are likely nodding along "well duh, some bosses take a bunch of shots." But this makes no more consistent or real-world sense than the indestructible wooden doors.