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

[David Farber <dave () farber net>]

________________________________________
From: Waclawsky John-A52165 [jgw () motorola com]
Sent: Tuesday, June 24, 2008 6:39 PM
To: David Farber; ip
Subject: RE: [IP] worth reading --  QOS  Author is Motorola, Chief Software Architect

My intent with the "pipes comment" was not to deflect from the major
points outlined further in my QoS observations note, that QoS is really
very hard. I don't see it as an adequate substitute for capacity (my
experiences were outlined). My intent was to use the "pipes" as way to
express the fact that core network capacity is increasing and there is a
good deal of capacity for various reasons related to design, reliability
etc. because of not only pipe size but other factors (from Moore's law)
such a node processing speed and memory capability, etc. Well run
networks seem to be typically driven by network design objectives, good
capacity planning, ability to support peak loads, etc. for connectivity,
back-up and recovery and reliability etc..

I have found network have 4 kinds of delays: transmission or encoding
delay (measured link by link, which is about putting packets of a
certain size on a link of a certain speed), processing delay (time where
packets wait at a node while it figures out what to do with or where to
switch each packet), propagation delay (speed of light limitation over
distance) and queuing delay (unproductive delay waiting somewhere in the
network for a resource). I have found that network capacity
planning/optimization is a never ending bottleneck resolution process.
Remove one bottleneck and you find the next one.

Certainly fiber offers enormous capacity and drives down one type of
delay (such as encoding delay) causing another to potentially become a
bottleneck focus (processing delay). Capacity from both pipes and nodes
needs to be considered as part of good capacity planning practices and
network design goals to keep traffic out of unproductive queues, which
if packets wait too long will disturb some applications. But, regardless
of where the bottlenecks are, getting all these queues and resources to
operate under some end-to-end QoS scheme seems more than a little
unlikely especially since QoS has been discussed since the dawn of
networking ...and now adding node queues to the mix of things that need
to be QoS managed doesn't appear to simplify the QoS challenges. The QoS
ROI seems highly questionable and QoS brings in other issues, for
example it is another thing to manage or configure incorrectly etc.
(more in my original note) and QoS is NOT an adequate substitute for
capacity in my experience. My 2 cents.

-----Original Message-----
From: David Farber [mailto:dave () farber net]
Sent: Tuesday, June 24, 2008 10:15 AM
To: ip
Subject: [IP] worth reading -- QOS Author is Motorola, Chief Software
Architect


________________________________________
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



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