Cell Relay Archive

[Eldon Mellaney <eldon@mars.dgrc.crc.ca>]

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

In the context of ATM, the use of priority _may_ interfere with existing
connections: the goal is ensure that higher priority connections are
admitted to the network regardless of what connections exist in the
network at the time that a high priority connection request is made to
the network. Of course, every effort must be made to ensure that the
smallest number of lower priority connections are affected. This will
depend on the approach taken, e.g., connection-level priority and
pre-emption.

As for the interference with existing connections without warning, there
are a few issues to consider. First, in Canada regulations governing
telecommunications specify that no "call bumping" can occur in a public
network, in other words, first come, first serve. This holds until the
capacity in the network has been exhausted. Thus, the occassional
presence of a busy signal on Mother's Day. 

On the other hand, NATO requirements stipulate that priority and
pre-emption is mandatory in their ATM networks. Here, one can substitute
"explicit web site" and "fire station" from previous postings on the
subject of priority in networks (perhaps best dealt with outside this
thread) with "messages from a lower ranking personnel" and "messages
from higher ranking personnel". Clearly, this messages must be treated
differently if the network's resources are exhausted, yet
mission-critical data (in whatever form) must be sent through the
network.

This functionality simply does not exist in IP at the moment. In ATM,
the same holds, although there has been much work done within the
context of the ATM Forum on the matter. Together with the individual who
derived the connection-level priority and pre-emption service for ATM, I
will be making a contribution to the ATM Forum that addresses this very
issue.
Often, however, existing connections must be "dropped" without warning
to satisfy another requirement: minimising the call set-up delay
experienced by the higher priority call to the network.


> > 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 hope this does degenerate into a war of those on the IP side versus
those of the ATM side. I have debated with Alfred in this newsgroup
previously, and have found
him to be above that.

Having said that, yes, James you are right in that in the network it is
possible to lose transmitted information due to buffer overflow (as a
result of an aggregate arrival process with rate Ra > service rate Rs)
in one or
more switches in the network due to instanteous, coincident bursts for
multiple
sources. This is the trade-off that exists with the use of a
packet-switching technology: ATM is not magic. ATM links can be
over-subscribed. The degree to which this is permitted (in order to
achieve statistical-multiplexing gain, a chief advantage over a
circuit-switched network, e.g., PSTN, where it is not possible) is
determined by the various implementations of the CAC algorithms used by
the
various vendors in their various switches. In short, call set-up in ATM
does guarantee a bandwidth resource in the network on an end-to-end
basis with due treatment given the call's QoS requirements, but with the
knowledge that some transmitted information may be lost from
time-to-time due to buffer overflow and some jitter will introduced by
somewhat unpredicable queuing delays (again, due to bursts in the
network, especially coincident ones).

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

I think you would have to agree that improving the loss rate in the
network from 1e-6 to 1e-9 (1e-10 is a commonly accepted BER on optical
links, but the people here in our "Optoelectronics and Photonics"
research group in Network technologies would probably qualify that
statement ... ) is a significant improvement, indeed.
 
> (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.)

An interesting comment regarding analytical models, indeed.
While far from being a queuing theory expert, analytical models have
very distinct
limitations. Having attended the International Teletraffic Congress (ITC
'15) in Washington last year, I saw this first hand. Further, even using
today's best simulation software, one can only obtain _approximate_
solutions using analytical techniques for queuing problems. Queuing
problems are extremely difficult unless very generous assumptions are
made. The work I presented at ITC '15 showed just how careful one must
be when making such assumptions. 

Your statement that, "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" is both
interesting and confusing. 

Do you claim that the delay and delay variance experienced in a tandem
queuing system shows linear behaviour? What assumptions were made
regarding the arrival and service processes? Is the system considered a
tandem MMPP system or simply a tandem M/M/1? Even in a tandem M/M/1
case, I do not think that analytic methods alone will get one very far.
What of this reference to "electrical noise" in the context of data loss
and consequently (link/network?) utilisation? Do the authors attempt to
apply analytical techniques to a system in which loss can occur due to
erred data transmitted in the system? Are finite or infinite buffers
used in the evaluation of the queuing system? 

As an aside, why consider the effects of electrical noise to begin with?
Was the work done in the context of a wireless system, where such
effects are much more pronounced than in an land-link DS-x link?
Considering this additional aspect surely makes the characterisation of
such a queuing system under study more complex, especially using only
analytical technics.

Perhaps you could clarify your claims?

Eldon.

-- 
Eldon J. Mellaney					
Network Systems Research				
Communications Research Centre, Industry Canada		eldon.mellaney@crc.ca
Ottawa, Canada						http://www.crc.ca