Cell Relay Archive

[anouch_atm@yahoo.com (anouch)]

Salut Bert,
nice to hear you again.

You are absolutely right, the standards say nothing about the priority
of CBR, rt-VBR, ... these are vendor implementations dependent. But I
don't thing any vendor gives for example ABR a higher priority than
CBR. As far as I know all vendors give the following priority (in
absence of shaping where priority doesn't have real sense) in
decreasing order: CBR, rt-VBR, nrt-VBR, ABR, UBR. This is a fact that
doesn't even need to be specified just like to achieve low delay/CDV,
one should have little queue, and all vendors know that.

So we all agree that prioritisation is just a way to achieve the
performance/QoS needed by each service category. On the other hand,
the bit rate is a traffic characteristic directly related to the
traffic profil. It isn't a QoS objective to achieve. Nevertheless, the
bit rate is needed to reserve bandwidth and to police the traffic. So
in my viewpoint these are two different things that must be treated
independently. One answer to this problem is to be able to first
configure the service category (which gives the right priority
desired) and then set the policing parameter independently. In other
word for a nrt-VBR connection with PCR=SCR, we should first set the
service category to nrt-VBR, and then configure a single leaky bucket
policer to police only at PCR (single rate). This policer would not be
VBR.1, VBR.2 or VBR.3 conforming but rather CBR.1 conforming. As you
see, a nrt-VBR connection with a CBR.1 conforming policer isn't really
a standard service as defined by ATMF.

Just to make my case clear I would compare it to a similar problem
where high bandwidth is sufficient but not necessary to achieve low
delay. An example is voice traffic with very little BW but low delay
requirements. You cant' use a single Fair Queuing algorithm to deal
with a mix of voice and high-BW-data traffic. Otherwise you would
reserve the BW for voice much higher than needed to achieve low delay
which is wastful. The solution is to decouple BW and delay. In
addition to the FQ scheduler, a system of priority queues would deal
with delay requirement.

Finaly as far as profitability is concerned, you are right: if all VBR
VCs are filled up there would be no gain on statistical multiplexing
effect. As Dominic said, in order for a carriers' carrier (dealing
with aggregated traffic) to dissuade ISPs from always asking  for
CBR-like pipes, they should charge much higher for CBR than for other
categories. But this doesn't change the nature of the problem, nor the
business model of the carrier. So, being not able to use the
statistical effect of VBR connections, the profitability of a
carriers' carrier should not be based on statistical multiplexing
gain, but on other factors (?).

Anouch

"Albert Manfredi" <albert.e.manfredi@boeing.com> wrote in message news:<GME6Ay.L67@news.boeing.com>...
> "anouch" <anouch_atm@yahoo.com> wrote:
> 
> > Hi all,
> >
> > CBR is designed for Constant bit rate and VBR for Variable bit
>  rate
> > applications. But beside the bit rate nature of traffic there is
>  also
> > an urgency nature i.e. CBR is more urgent (have high priority)
>  than
> > VBR. So how should one configure a connection with low priority
> > traffic and a constant bit rate?
> 
> Salut, Anouch,
> 
> I think that the relative priority given to CBR, VBR, ABR, and UBR
> queues is something that fits under the category of "vendor
> implementation," no? There's nothing in the signaling standard that
> allows a user to set queue priorities explicitly during setup. This
> seems to be somewhat analogous to IP diffserv, where the
> differentiated services code point (DSCP) does not mandate any
> particular per-hop behavior. That would be an implementation issue,
> which presumably a network administrator could decide, if given the
> option my the switch manufacturer?
> 
> > If you ask an application example, I don't have one, since usualy
>  a
> > constant bit rate service is designed for a real time (thus high
> > priority) traffic. But these characteristics are only for a single
> > application (single connection).
> >
> > When multiplexing a number of low priority VBR connections into a
> > single VC, the burstiness of this multiplexed-VC approches one
> > (PCR/SCR=1). Indeed this is often the case in a carriers' carrier
> > business. A long distance operator often aggregates ISP's traffic
>  into
> > few VCs and deliver them at another point.
> >
> > Regardless of the urgent nature of the traffic we have two
>  choices:
> > A) a CBR VC
> > B) a VBR VC with PCR=SCR and MBS=1
> >
> > So my questions are:
> >
> > 1) Is B) a valid configuration (ATM Forum conforming), since the
> > traffic is no more variable bit rate?
> >
> > 2) Do you know other methods for configuring low priority constant
>  bit
> > rate traffic?
> 
> It seems to me that if you truly get PCR/SCR = 1 in your aggregated
> CBR VC _or_ aggregated VBR VC, then you have in effect filled up the
> pipe. So what statistical multiplexing is feasible anymore? Several
> such VCs would have to be provisioned as if they were each CBR VCs
> anyway, which means that you either add them up, or you accept
> packet loss.
> 
> I don't think there's anything standardized by the ATMF that
> prioritizes between identical CBR VCs or between filled-up VBR VCs?
> Maybe I'm wrong. It's been some time since I looked carefully.
> 
> > It is worth noting that ISPs are used to performance of a
>  dedicated
> > circuit (Leased Line). So when they consider moving to an ATM
>  style
> > connection, they often ask for a CBR guaranteed connection. But
>  the
> > problem for a carriers' carrier is that if all ISPs want CBR, then
>  how
> > the carrier's network can be economically profitable?
> 
> I guess that to be profitable, you can't have the VBR VC end up
> being filled to capacity all the time. That would be my answer. To
> be profitable, you would want few CBR VCs and many non-CBR VCs where
> the PCR >> SCR.
> 
> Bert
> albert.e.manfredi@boeing.com