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

[David Farber <dave () farber net>]

________________________________________
From: Dave Crocker [dcrocker () bbiw net]
Sent: Thursday, June 26, 2008 10:37 AM
To: David Farber
Cc: ip; Waclawsky John-A52165; Tony Lauck; Christian Huitema; Richard Bennett
Subject: Re: [IP] Re:   worth reading --  QOS  Author is Motorola, Chief Software Architect

Guys,


> From: Tony Lauck [tlauck () madriver com]
> Sent: Tuesday, June 24, 2008 2:19 PM
...
> Is it better to provide adequate service by special handling of certain
> "demanding" types of packets or is it better to provide adequate service by
> resource sizing with simple but fair scheduling policies?  There is a trade
> off between devoting resources to developing and implementing QoS mechanisms
> throughout the network and host computer stacks vs. devoting resources to
> provisioning additional capacity.

Yes, these are core questions.

Although subject to its own misunderstanding, the "end to end" principle for the
Internet has provided extremely helpful guidance in trying to answer these
questions for protocol design efforts.  At its base, the principle says to keep
complexity out of the infrastructure and, instead, locate it at the edges.

The misunderstanding comes from applying that guidance mechanically and to the
detriment of particular applications. The Internet is, after all, predicated on
mediated exchange, which means that the mediation stations (routers) have to
represent some amount of functionality and, therefore, complexity.

So, rather, the real rule is to make changes to the core only when there is no
other way to solve a problem.  And my contention -- with some hope folks
appreciate the pun in using that word in this context -- is that some
applications are sufficiently performance sensitive to require infrastructure
support.

However, given that QOS -- or, if you prefer, call it Service Level Agreements
-- is so difficult to make useful in large scale, we also need to have rock
solid justification for requiring it.  The lesson of Internet video and voice,
so far, is that we do not need it nearly as often as one would have expected.

Note that it well might prove adequate to have a hybrid model:  Use a QOS
mechanism for those portions of the path that are constrained, and don't for
those parts that aren't.  For example, edge networks tend to be far more
constrained than do core ones.


> Dave Crocker has made one specific claim regarding transient contention being
>  the difference between "almost never" and "never". This is not an meaningful
>  distinction in the real world, because real systems fail. One is always
> working with probabilities. QoS services with real-time guarantees require
> redundancy coupled with real-time fail over, and this has historically been
> achieved only with high levels of redundancy. High degrees of "almost never"
> can be achieved at high cost. "Never" comes at infinite cost.

Having packets lost or delivered late many times during a single telephone
conversation makes conversation impossible.  Having this problem occur once a
week, for one occurrence, doesn't.  "Almost never" has its own range of
definitions.  As Tony noted, the real question is balance.

My concern in this thread is the apparent assumption that big pipes solve all
problems, when we have plenty of history to show it isn't true.

Most real networks have real constraints.  If 10 people each need 10 packets per
second from a 100 packet per second router, they will all probably get what they
need.  If another user shows up and also needs 10 packets per second, do we make
only that new user unhappy, or do we make everyone?  Imposing a discipline which
constrains who suffers in the face of real constraints requires crossing the
line into some form of QOS.  And since flow management is already in routers, we
are now merely haggling QOS price.  Not principle.


> From: Waclawsky John-A52165 [jgw () motorola com]
> Sent: Tuesday, June 24, 2008 6:39 PM
...
> 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

And mine was there there is a rock solid track record, showing that there is
*never* enough *everywhere*, to guarantee particular performance
characteristics.  Especially not those that are sensitive to packet arrival times.




> From: Richard Bennett [richard () bennett com] Sent: Tuesday, June 24, 2008 4:58
>  PM
...
> One of the great myths of network history is the notion that Bob Metcalfe's
> Ethernet "beat" Token Ring and other QoS-enabling systems.

It is certainly important to distinguish an interface access method from a
transfer mechanism.  Ethernet is often used for the former but not the latter.

With respect to the original adoption of local area networking, alas, the myth
is indeed true.  True Ethernet beat a variety of token contenders. (Oops.
There's that pun again.)

However what is also true is that new technologies have often chosen transfer
disciplines that permit better per-access predictability. I once had to design
IP over ATM over community cable, where that last had neither collision detect
nor carrier sense.  So it only permitted classic Aloha, which has really awful
performance limits. We immediately decided to lay a token access scheme between
the IP and ATM layers.

And that prompts the comment that hardware contention access does not preclude
having a token-based discipline.  In fact, the first LAN technology that was
popular (ARCNet) used software token on top of hardware contention.



> We need QoS on data links where the level of traffic fluctuates wildly
> moment-by-moment

An end-to-end path is more that a set of independent links.  Every resource
along the path is subject to being constrained.  And some resource constraints
are solved better with higher-level -- ie, multi-component -- integrated management.

The KISS rule should definitely be the Prime Directive.  In the early 70s, when
it was explained to me that one quarter of the Irvine Ring's hardware real
estate was devoted to a contention-based scheme for establishing the token
discipline, it certainly did raise the question about why the remaining
three-quarters were essential.

But let's be careful that those KISS S's do not wind up meaning "silly simple".

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