Cell Relay Archive

[George Marshall <george@marshalls.org>]

Robert Blackshaw wrote:
> 
> Geert Goossens <gagoosse@info.vub.ac.be> wrote:
> 
> Snip>
> >>
> >I'm afraid I've answered this question w/o checking the actual
> >documents. I though I remember this being defined this way, but now I
> >can't find it back. Maybe I saw it somewhere else or in a specific
> >implementation, I don't remember.

> Regardless, I wonder did the spec mean that those priorities apply
> across *all* traffic, or just one user's traffic? I imagine that if I have
> both CBR and VBR-rt the CBR gets priority. However, should
> another user's CBR get priority over my VBR-rt even if I do not
> have CBR traffic?

The specs don't really address prioritization, or other actions within a
switch.  They say that if a switch/network accepts a QoS request, then
it is supposed to meet the delay/loss etc requirements for that call,
regardless of how many other connections are setup (again, each one only
accepted if the QoS can be met), and who they 'belong to'.

Now of course, within a switch, what the architect has to work with are
scheduling algorithms (priorization) and buffer allocation. 
Conventional wisdom says that you handle CBR at the highest priority,
because the decision to accept the call was very simple - "do I have the
fixed capacity requested or not" - so you don't have to worry about
variability in the input (you DID police the CBR input, didn't you?). 
VBR-xx, by contrast, involves an acceptance decision with some windage,
to allow making calculated guesses about cumulative bandwidth usage and
over booking the link to make money on it.  So when the traffic arrives,
you also have to allow for the case where the bursts all conspired
against you for a few milliseconds.  If VBR was higher than CBR, or even
the same priority, you run the risk of clobbering the high-paying CBR
tarffic.  Bad move.

Prioritization policies between the various VBR's, UBR, and ABR runs
more to policy than technology.

George Marshall

--
george@marshalls.org