NNSquad - Network Neutrality Squad
[ NNSquad ] Re: QoS vs. Neutrality -- the crux of the matter -- why the attraction and where's the network?
Thank you. This looks very interesting. The study was done in 2001, however and a large backbone then didn't have nearly the amount of traffic or the amount of multimedia as one would today. Even with that one caveat, it certainly higilights the possibility for "life without QOS" though, so it looks like I stand corrected. I can't help but wonder though, even if we can do it should we? QOS and neutrality certainly aren't mortal enemies, that fight lies elsewhere (IMHO). Thanks again for the info.
While I would agree with your sentiment that QoS is simply a tool to be used by network engineers (or misused by others) I would strongly disagree with your assertion that QoSis at all necessary in a large backbone. The study referenced below was made on thelargest (at the time) backbone in the world. The backbone used no QoS and the studyreveals cross-country performance with average jitter of 50 microseconds. This studywas conducted while the backbone carried live traffic. The conclusion of the study wasthat this "best-effort" network could support circuit emulation.http://www.nanog.org/meetings/nanog22/abstracts.php?pt=OTk2Jm5hbm9nMjI=&nm=nanog22
jyAnd yes, I work for a carrier, no longer the one in the study.I fail to see where this is an assumption. If a mechanic were posting telling you oil was necessary for a car no one would argue with him. Does anyone on this list currently work for a carrier? If so please correct me if I'm wrong. I never said I was an expert but I've been doing this for a while. I never said that the evil things that can be done with QOS are all necessary, just that some of the basic services on the internet rely on it. If you start advocating that all ISP's must give up diffserv QOS you will only look ignorant and uninformed. I was just trying to add value to a list that I've been reading for some time now. I still maintain that QOS is not the enemy, just another knob that can be exploited by the greedy.
On Thu, Sep 2, 2010 at 5:43 PM, Bob Frankston <Bob19-0501@bobf.frankston.com> wrote:The question is why do we assume QoS is necessary. We see this in Keegan’s response which assumes QoS as if the need were obvious.
We see this in statements such as “As an IP engineer by trade I can say that you cannot have a large network without some manner of QOS.” And “it's not wise to treat them all the same”. If QoS doesn’t compensate for the lack of bandwidth and if we have enough bandwidth we don’t need it why the attraction.
I do need to clarify two misunderstandings here. One is that I am not advocating TCP for real time even if it may seem to work.
The other is my use of Akamai as an example. I wanted to emphasize that many services that people think of as network functions are not necessarily in the network. Imagine a new product “Akamai Home” which caches content in your home router or even your PC. We’d have no problem. If you and your neighbors share a cache or a company rents space and places a server near your home then that’s not really a network function.
If a company like Cisco decides to spend a large amount of money buying dark fiber for its own network so it can offer video services should we prohibit it? As long as it does not gain monopoly control over the capacity of the infrastructure there is no problem. Same for Google buying dark fiber or laying its own.
The problem today is that such de facto monopoly control does exist because today’s carriers all have the same business model which is selling transport as a service and we don’t have the option of competitors provide enough capacity to reduce the value of the carriers networks. It amounts to a cartel though IANAL.
My contention is that were we to have a public infrastructure rather than just networking as a service it wouldn’t make economic sense to buy private dark fiber for the vast majority of applications including video conferences. But I don’t have to prove it if we can let the market process work. Perhaps Google would still need its own capacity ahead of the market but that’s fine.
I argue that the failure to embrace diff-serv is a market-process. We cannot map the end user value into public network services once we have just bits. The fact that today’s business model keeps transport expensive makes owning private networks seem economical. The real test comes when we have a business model that isn’t dependent upon scarcity of public (or common) capacity. The same goes for Akamai’s business model which benefits from scarcity of capacity.
**
From: Keegan Holley [mailto:keegan.holley@sungard.com]
Sent: Thursday, September 02, 2010 16:29
To: Bob Frankston
Cc: Lauren Weinstein; nnsquad@nnsquad.org; David J. J Farber; Christian Huitema; Mike Liebhold; Dave Crocker; Richard Shockey
Subject: Re: [ NNSquad ] QoS vs. Neutrality -- the crux of the matter
QOS is a touchy subject for a forum like this. As an IP engineer by trade I can say that you cannot have a large network without some manner of QOS. Does this make service and participant neutrality impossible? No, that would be a business decision. I was simply trying to explain diffserv QOS and it's place in networking.
Instead of implicitly assuming that we know what QoS is we can go for amarket-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 -----