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 QoS is at all necessary in a large backbone. The study referenced below was made on the largest (at the time) backbone in the world. The backbone used no QoS and the study reveals cross-country performance with average jitter of 50 microseconds. This study was conducted while the backbone carried live traffic. The conclusion of the study was that this "best-effort" network could support circuit emulation.
http://www.nanog.org/meetings/nanog22/abstracts.php?pt=OTk2Jm5hbm9nMjI=&nm=nanog22 jy And yes, I work for a carrier, no longer the one in the study. On 03/09/2010, at 8:08 AM, Keegan Holley <[email protected]> wrote: > 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 <[email protected]> > 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:[email protected]] > Sent: Thursday, September 02, 2010 16:29 > To: Bob Frankston > Cc: Lauren Weinstein; [email protected]; 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 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. > > > > 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: [email protected] > [mailto:[email protected]] On Behalf Of > Lauren Weinstein > Sent: Thursday, September 02, 2010 14:13 > To: [email protected] > Subject: [ NNSquad ] Re net neutrality vs. diff-serv? > > > ----- Forwarded message from Dave Farber <[email protected]> ----- > > Date: Thu, 2 Sep 2010 12:44:13 -0400 > From: Dave Farber <[email protected]> > Subject: [IP] Re net neutrality vs. diff-serv? > Reply-To: [email protected] > To: ip <[email protected]> > 59D1B1B0-B6BC-11DF-B836-BA3EA77419C0: > > > > > > Begin forwarded message: > > > From: Dave CROCKER <[email protected]> > > Date: September 2, 2010 11:21:01 AM EDT > > To: [email protected] > > Cc: ip <[email protected]>, Richard Shockey <[email protected]>, Mike > > Liebhold <[email protected]> > > Subject: Re: [IP] Re net neutrality vs. diff-serv? > > > > > > >>> *From:* Richard Shockey <[email protected] > >>> <mailto:[email protected]>> > > ... > >>> 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 ----- > > > > > >
