worth reading -- QOS Author is Motorola, Chief Software Architect

[David Farber <dave () farber net>]

________________________________________
From: Dave Crocker [dhc2 () dcrocker net]
Sent: Tuesday, June 24, 2008 11:07 AM
To: David Farber
Cc: ip; Waclawsky John-A52165
Subject: Re: [IP] QOS  Author is Motorola, Chief Software Architect

David Farber wrote:
> From: Waclawsky John-A52165 [jgw () motorola com] Sent: Monday, June 23, 2008
> 1:08 AM To: David Farber Subject: RE: [IP] Re:   Net Neutrality: A Radical
> Form of Non-Discrimination by Hal Singer
>
> Hi Dave, Some QoS perspectives that I have learned: First, the main problem.
> QoS really isn't needed when you have big pipes.


This view has gained popularity in recent years and it seems to be based on two
misunderstandings.  The first is that end-to-end performance is dictated by the
size of pipes and the second is that pipes are always large or that we can
guarantee that eventually they all will be large.

Packet switching is more about the switching than the pipes.  The path from a
one random end-system to another has quite a few switching points. This thing
called queuing comes into play when there is transient contention for resources.
This includes contention for use of each pipe along the way, but also contention
in switches and, by the way, contention in either of the end-systems.  (I'm
qualifying with "transient" because sustained contention means that the system
is fundamentally overloaded; queuing can't help there.)

The premise behind the "big pipes" view is that we don't have transient
contention. It's simply not true.

What is true is that there are common scenarios where transient contention is
almost never a problem.  But the difference between "almost never" and "never"
counts for everything in a world seeking reliability.  Especially if you want to
cover a full range of scenarios.

One set of scenarios left out by "big pipe" devotees is a vast portion of the
world with limited resources.  While this obviously includes many remote or
developing environments, it also includes less-capable channels such as mobile
devices.

It should also be noted that there is a tendency for the core of the Internet to
have less contention than access networks at the edge.  We can wave our hands
and say that the edges will eventually catch up, but history suggests otherwise.

A persistent lesson over the history of packet switching is that there is a wide
range of resource capabilities and anything designed to rely on high-end
capabilities disenfranchises participants and systems that are not so privileged.

"QOS" has indeed had a problematic history over the life of packet-switching,
but this seems to be because it is difficult to design in a way that is useful
-- and then deploy it throughout the infrastructure -- rather than because it
isn't needed.

Basic Internet capabilities were designed to maximize use of the channels, but
at the cost of inter-packet arrival variance.  Any application needing to
sustain a specific transmission rate with specific (and low) variance is at
risk, without some underlying design to ensure the necessary performance.

Anyone with experience to the contrary might want to review their sampling
methodology against the full and realistic set of Internet scenarios.


d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net



-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com