[ NNSquad ] Re: QoS vs. Neutrality -- the crux of the matter

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.

This is not neutrality. it also opens up the opportunity for carriers to purposely limit such applications when seen on their networks and then charge services like Akamai for access to their subscribers who now need them more than ever.

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.

The data isn't processed as a stream bits, it is processed as a group of packets. Some are bigger than others, some take more time to process than others, some have different requirements than others. Without going into too many specifics it's not wise to treat them all the same.

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

QOS doesn't compensate for lack of bandwidth, nor does bandwidth compensate for lack of QOS. QOS is about ordering packets to be processed by the equipment and about keeping certain services from rendering others unusable. . Throttling bandwidth usage is also possible with QOS and I agree that this is not necessary for safe operation of the network.

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

You cannot use TCP for realtime services, retransmission, checksumming, windowing and the like do not help with real time services. The other quality factors have to be honored on a per hop basis (IE each router/switch in the network individually), which is diffserv QOS just attached to a different packet header.

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