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.

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.

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.