Comments on: Net Neutrality is the enemy of VoIP and gaming http://www.digitalsociety.org/2009/10/net-neutrality-is-the-enemy-of-voip-and-gaming/ Pro-Culture, Pro-Commerce Wed, 10 Mar 2010 16:34:38 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: CableTechTalk » Blog Archive » A Reminder of What “Net Neutrality” Is Really About http://www.digitalsociety.org/2009/10/net-neutrality-is-the-enemy-of-voip-and-gaming/comment-page-1/#comment-1619 CableTechTalk » Blog Archive » A Reminder of What “Net Neutrality” Is Really About Fri, 13 Nov 2009 14:16:41 +0000 http://www.digitalsociety.org/?p=1133#comment-1619 [...] [...] [...] [...]

]]> By: Mike http://www.digitalsociety.org/2009/10/net-neutrality-is-the-enemy-of-voip-and-gaming/comment-page-1/#comment-1460 Mike Tue, 03 Nov 2009 09:45:32 +0000 http://www.digitalsociety.org/?p=1133#comment-1460 I believe there is a need to pull back a step and ensure the data transport characteristics of the connectivity we are purchasing is fully described. This includes the planning rules for service we are buying. Peak hour bandwidth allocations and the underlying loss and delay charactisterics at various load levels. Identifying the load level where loss and delay characteritics become unpredictable is critical. Even the strict adherents of end to end philosophy need to know how hard they can load their connectivity before it starts to fail. Fundamentally the labelling ought to identify what our connectivity was engineered to achieve. None does. Once this level of transparency is available, we can move on to how users choose to use their bandwidth and available quality by deciding what services to consume. It is possible to slice and dice the available bandwidth and quality amongst your applications in a dynamic way to deliver assured outcomes. It is matter who does it, how easy is it to do, and how easy to change, when your trying new SIp devices or applications. Your suggestion of standardising budgets (bandwidth and quality)for applications is pragmatic for affordable packages, but irritating and limiting if you wish to switch a VOIP supplier or change your conferencing or VPN around. Even for affordable packages and I am thinking poor families, as the kids grow, the mix and source of educational content changes or you elderly relatives need support remotely, it is even more important that the limited bandwidth and quality is not tied to a particular service set, but can be changed. This conversation has some way to go as it is only when we get full transparcny of the data transport, can we know its full potential. I believe there is a need to pull back a step and ensure the data transport characteristics of the connectivity we are purchasing is fully described. This includes the planning rules for service we are buying. Peak hour bandwidth allocations and the underlying loss and delay charactisterics at various load levels. Identifying the load level where loss and delay characteritics become unpredictable is critical. Even the strict adherents of end to end philosophy need to know how hard they can load their connectivity before it starts to fail.

Fundamentally the labelling ought to identify what our connectivity was engineered to achieve. None does. Once this level of transparency is available, we can move on to how users choose to use their bandwidth and available quality by deciding what services to consume.

It is possible to slice and dice the available bandwidth and quality amongst your applications in a dynamic way to deliver assured outcomes. It is matter who does it, how easy is it to do, and how easy to change, when your trying new SIp devices or applications.

Your suggestion of standardising budgets (bandwidth and quality)for applications is pragmatic for affordable packages, but irritating and limiting if you wish to switch a VOIP supplier or change your conferencing or VPN around. Even for affordable packages and I am thinking poor families, as the kids grow, the mix and source of educational content changes or you elderly relatives need support remotely, it is even more important that the limited bandwidth and quality is not tied to a particular service set, but can be changed.

This conversation has some way to go as it is only when we get full transparcny of the data transport, can we know its full potential.

]]>