Cell Relay Archive

[Koen Peeters <koen@ciminko.be>]

James Carlson wrote:
> 
> albert.e.manfredi@boeing.com writes:
> > QoS per IP's prioritized queues: You go to the airport in Chicago and you want
> > to go to Nairobi, on standby (no reservations). The attendant at the counter
> > will get you on the first plane heading east, probably to New York. Then you
> > have to go from there. If you are willing to pay more, maybe you can have a
> > better chance of getting to Nairobi quickly by paying for 1st Class standby?
> > (I've not seen this, but I suppose it's possible.) Essentially, this is a hop
> > by hop proposition, with the same tension in your gut at each hop. You might
> > pick the wrong first hop, and have to spend the night in New York. All depends
> > on factors you have _no_ control over.
> 
> Almost correct, except, of course that most packets have very few
> emotions, and so the toll on the packet is only the percentage chance
> of being delayed or dropped at each hop, and except for the fact that,
> where the choice of routes matters, IP allows for explicit routing.
> 

It's not the route that matters in most cases. Being on time does matter
however, particularly if you are a voice packet (without emotions).

> Additionally, there are mechanisms to approximate the global
> scheduling required to solve the New York layover problem using a
> distributed mechanism (cf OSPF-OMP).  Frankly, I think these tricks
> are likely to be a waste of time, since the probability of the event
> is terribly low.
> 
> In any event, even with reservation, you still have no control over
> the actual outcome.  If priority is used, then new connections can
> interfere with existing connections without warning.  If priority is
> not used, then priority inversions certainly exist in the system.  You
> can't have it both ways.
> 

Aha ! again a big difference between QoS and Priority.
QoS guarantees you will get to your destination once you get an OK to
go.

Let's look at the airport again. Airline A can not give me a guaranteed
reservation up to my destination. This still gives me the option of
checking with airline B for an alternative.

Airline C uses no QoS but uses Priority. They can guarantee me to the
next hop. If the president suddenly decides he wants to go on holiday, I
might stil get stuck in the airport.

> > QoS per ATM: You go to the airport in Chaicago and you want to go to Nairobi.
> > The attendant at the counter will look at all end-to-end options available in
> > the immediate future from Chicago to Nairobi and will make you a ticket that
> > "guarantees" a complete trip. No gut tension at each hop (well, in principle
> > anyway), and you know exactly when you'll be arriving.
> 
> The game played by ATM isn't nearly as simple as that.  If I have a
> reservation and if all other links stay within contract, there's still
> no absolute guarantee on my transit.  Not every link necessarily has
> sufficient buffering and bandwidth for an instantaneous burst near or
> over contract, and most implementations can get choked with CLP cells
> just as much as any IP router employing QoS techniques.
> 

I suggest you read the labtest results on following link :
 
http://www.data.com/lab_tests/atm_stress_test.html

Read carefully and you will find most tested implementations in march
1995 could do what you claim they can't do. 
Most implementations have even become better since !
 
> And, again, the price here is that the airline reservation system
> needs a *huge* database to track the flow of passengers.  If we
> attempt to scale from, say, 1000 passengers per day to 1000000, some
> very bad things will happen to both our reservation system and our
> calculations of loading.
> 
> I'll go along with the statement that it's vaguely better, but not
> much more.  If it reduces probability of loss from, say, 1e-6 to 1e-9,
> is it a worthwhile thing to do?
> 

In a congested network it reduces the probability of loss from, say,
1e-1 to 1e-9,
but that is obviously not a worthwhile thing to archieve.

> (After staring at queuing theory based analytic models of many of
> these systems for a while, I've noticed that they're all essentially
> the same -- the system is linear with respect to delay and variance
> and has data loss due only to electrical noise until about 80%
> utilization.  Above that point, delay, variance, and loss all explode,
> and no fancy scheduling fixes the problem.)
> 

Again : queuing alone as used IP doesn't give you quality.
CAC (Connection Admission Control) and Policing ar just as important to
QoS.

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

-- 
 +--------------------------------------------------------------------+
 | Koen Peeters                || E-mail: koen@ciminko.be             |
 | CIMINKO NV                  || http://ciminko.be/                  |
 | Catherinalaan 37            || Tel. : +32 16 441933                |
 | 3110 ROTSELAAR              || GSM  : +32 95 501933                |
 | Belgium                     || Fax  : +32 16 441007                |
 +--------------------------------------------------------------------+