SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : The *NEW* Frank Coluccio Technology Forum

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Peter Ecclesine who wrote (12655)12/29/2005 9:38:28 AM
From: ftth  Read Replies (2) of 46821
 
re: "...that ISPs should not block access to lawful Internet content"

This misses the scope of the problem. An ISP doesn't need to BLOCK 3rd-party content, applications, or services to make it less that useful, and ultimately kill it off. They only need to degrade it, randomly, undetectably, and unprovable of intent.

Covert degradation isn't exactly a tall order, since you can't distinguish "intent to do harm" from a "best-effort" IP underlying service (not without some special "spy" packets anyway). The packet hand-waving hocus-pocus all happens within their walled garden, behind the curtain. It all looks like "normal best effort" from outside the box.

And we aren't talking ISP's as a general category. The only ISP's with clear business incentive to degrade 3rd party "stuff" are the VIMBO's (vertically-integrated monopoly bottleneck operators). Oh, but they say they wouldn't do that, wink wink.

As long as the broadband platform capabilities remain ambiguous, there is no enforceable-traceable way to legislate this neutrality. Best-effort is "whatever you feel like," and that is not a foundation for predictable, bounded platform performance that a set of rules can be written around.

The pipe needs guaranteed minimums, and guaranteed indiscriminate access to a platform having those bounds. A neutrality violation is a violation of the guaranteed minimums OF THE PIPE. Lawmakers shouldn't set those standards, industry should. Lawmakers should only impose a deadline that industry come up with such standards, and if they don't meet the deadline, the "penalty" is that lawmakers WILL set those standards.

Just look to electrical appliances and electrical pipes as the template.

Consumers know they get 60Hz within some frequency bounds, 115VAC within some bounds, and some total amps at the electrical service entrance. They subdivide the total amps as they see fit. They know they can't put a 20A 220V arc welder in a 15A 115V socket. They know they can't run a DC battery powered flashlight from the AC socket. They know this not because they understand electricity...they know it because there are standards so the plugs don't fit, or the circuit breakers trip. It's perfectly plausible to translate this to the virtual world of networks.

And the manufacturers of electrical applicances know they can make appliances that can work for every consumer. It's up to the consumer to plug it in the right socket and to be sure they don't exceed the pipe.

With today's broadband, we have big-time ambiguity. Manufacturers cannot assume consumers have some baseline capability, and consumers cannot assume they have some compatible pipe. That's not a recipe for a thriving broadband ecosystem. It's a recipe to maintain the central control on ambiguity, for the overwhelming benefit of the vertically-integrated pipe controller. The rest of the ecosystem is at their mercy, forever. They CANNOT innovate freely.

In the electricity realm, it all works as harmoniously as one could ever hope, because there are nationwide, ubiquitous standards for THE PLATFORM. If you want to participate as a consumer or manufacture, you have to adhere to the platform definitions and capabilities.

Net neutrality legislation should simply frame the problem so that "unambiguous platformization" will happen. It shouldn't try to create order out of current state of chaos.

Just my 2 cents worth...
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext