NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ 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>

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
> 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 -----