NNSquad - Network Neutrality Squad
[ NNSquad ] QoS vs. Neutrality -- the crux of the matter
As Dave notes below if we have a network that only know about bits (and packets) then we have inherent neutrality. This is a feature not a bug and goes to the heart of concept of the Internet vs. telecom. If we need operators to second guess what we are doing then we can't have neutrality. At best we can have "fair" sharing of the remaining scarcity. No wonder this is a core issue. Instead of implicitly assuming that we know what QoS is we can go for a market-based approach by recognizing that QoS is not fundamental. We can then have a company like Akamai offer its own kind of quality as an application. If QoS is indeed necessary for some applications then they should have the option of paying for a special network and we should have the option of not paying for it. First we need to get past the notion that QoS is necessary and fundamental. The presumption that QoS is necessary and that service must be baked into the network is the business model of telecom. If we could use raw bits then we'd need a different business model -- infrastructure. QoS is not fundamental. All the technology of QoS is atop a physical system that isn't inherently reliable. We gain reliability at the link layer with error correcting codes, over-provisioning, retries and other tricks. Note you can both over-provision and under-provision as in the case of assuring more-than-enough capacity for a 56Kbps audio path at the physical layer and then throttling it to 56Kbps and denying us the ability to use the rest of the capacity (and further innovation). By exposing the native best efforts capabilities we can discover what is possible. With protocols like TCP we can define our own quality edge-to-edge or can choose UDP and other measures of quality. It's a bit more subtle as I explain in http://rmf.vc/?n=IPPvD (Promises vs. Discovery). Rather than fighting for "network neutrality" we should be fighting for the inherent neutrality of bits and for access to the abundance latent in the physical infrastructure. More on baking in http://rmf.vc/?n=unbaked. -----Original Message----- From: nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org [mailto:nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org] On Behalf Of Lauren Weinstein Sent: Thursday, September 02, 2010 14:13 To: nnsquad@nnsquad.org Subject: [ NNSquad ] Re net neutrality vs. diff-serv? ----- Forwarded message from Dave Farber <dave@farber.net> ----- Date: Thu, 2 Sep 2010 12:44:13 -0400 From: Dave Farber <dave@farber.net> Subject: [IP] Re net neutrality vs. diff-serv? Reply-To: dave@farber.net To: ip <ip@listbox.com> 59D1B1B0-B6BC-11DF-B836-BA3EA77419C0: Begin forwarded message: > From: Dave CROCKER <dcrocker@bbiw.net> > Date: September 2, 2010 11:21:01 AM EDT > To: dave@farber.net > Cc: ip <ip@listbox.com>, Richard Shockey <richard@shockey.us>, Mike > Liebhold <mnl@well.com> > Subject: Re: [IP] Re net neutrality vs. diff-serv? > > >>> *From:* Richard Shockey <richard@shockey.us >>> <mailto:richard@shockey.us>> > ... >>> Mike you pointed out several things that have been obvious to those >>> of us in the Internet Engineering Community for some time. First >>> packet discrimination for various reasons, including congestion >>> control, have been part of the Internet Protocol suite since its inception. > > > Discussion about "neutrality" needs to distinguish between Service Neutrality and Participant Neutrality. > > > Participant Neutrality means that email from or to me gets treated the same as mail from or to you. Equally, web pages I retrieve from Google get treated the same as web pages I retrieve from Yahoo! or from ietf.org. Differential handling is based on IP Address or Domain Name. > > Service Neutrality means that email, web, voip telephone calls, > real-time remote sensor data, and every other type of "application" > get treated equally. Differential handling is based on the IP Protocol > field or the TCP/UDP Port number. Real service neutrality means that > it is not possible for the network infrastructure to support quality > of service guarantees, such as inter-packet arrival times (jitter.) > > The challenge of service neutrality is technical, such as dealing with the potential that preference for one service will destroy the ability to use another service. > > The challenge of participant neutrality is political, since it relates to potentially unfair treatment of different people or organizations. > > An example of Participant Neutrality that can be masked as Service Neutrality is when two organizations have competing application protocols and one is given preference. The preference appears to be based on the protocol but is really concerned with who is operating the service. > > Discussions about net neutrality typically fail to make this basic distinction and therefore typically wind up with people talking past each other or, worse, imposing policies that really do restrict the ability of the Internet to properly support adequate operation of a service. > > Mike's note was clearly and strictly in terms of deployment of service non-neutrality mechanisms. That is, differential handling of protocols. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ------------------------------------------- ----- End forwarded message -----