Cell Relay Archive

[James Carlson <carlson@ironbridgenetworks.com>]

albert.e.manfredi@boeing.com writes:
> To solve it, however, and in fact to provide QoS guarantees in any system, you
> _have_ to introduce the concept of cost. One way or another, the negotiation
> for QoS has to include in it a tradeoff: more functionality (which eats up
> network resources) comes at a price. This is one of the problems diff-serv is
> having to address, by the way. QoS without associated cost tradeoffs is just
> plain vapor.

Well, of course, cost has to be factored in for any real network.  Was
someone suggesting otherwise?  The argument here is over whether or
not complex signaling is necessary and whether or not cell-switching,
which, as a trade off between packet switching and circuit switching,
provides clear benefits to anyone.

The classic non-RSVP diff-serv model uses class of service mappings,
not signaled paths.  The model that ISPs are working on now involves
SLAs (service level agreements) that map particular bits of traffic
into particular pre-defined measurable services.  None of this
requires flow reservation.

> One relatively easy but inflexible tradeoff might be bandwidth vs QoS. For
> example, just give the end users two options which mirror what they have
> today, but over the same network. Either you get controlled latency and
> jitter, but at reduced bandwidth, or you get whatever bandwidth is available,
> but with no guarantees. ATM could implement such a scheme pretty easily.

This is called "channelization."  It's not exactly a new idea, and it
has provable queuing problems.

ATM claims to solve problems with latency and jitter, but never
addresses either (1) how complex the solution is relative to the
problem at hand nor (2) other means to solve the problem.  Yes,
latency and jitter do exist.  Any non-channelized system is going to
see these effects.  Whether or not they're really a problem for
well-designed applications is another matter entirely.

(The problem with the concept of high-priority traffic is more easily
illustrated with an analogy.  If I want a guaranteed seat on an
airline, I have to pay extra AND I have to specify where I want to go.
This works for large numbers of people, because we can, at least in
principle, do global scheduling in advance.  If we had a system where
I could say, "here's more money, but I won't tell you where I want to
go until I show up," this would still work as long as there weren't
very many people trying this -- in other words, if the price were high
enough.  The problem with both SVCs in ATM and QoS in IP is that
people are asking not to reveal where they want to travel, and they're
apparently presuming that we can do this for large numbers of
customers.  This just isn't true.  There is no solution to this
problem except channelization, which is, to stretch that analogy,
being able to pay for a Lear jet.)

(Or, another way to look at it:  If everyone hits that porn site at
3AM, QoS goes right out the window.  20Mb of high-priority traffic
just doesn't fit in a 10Mb pipe.  QoS is, at best, a probabilistic
statement.  And as long as we're going with probabilities, we can do
better and simpler than signaling by measuring and overprovisioning.)

-- 
James Carlson, Consulting S/W Engineer  <carlson@ironbridgenetworks.com>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA          42.423N    Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp