SUBJECT D22)

SUBJECT D22-1) Question: BISUP does not define a corresponding IE or parameter for QoS IE. For systems adopting only ITU-T series standards there is no problem. However, for systems adopting other implementation specs., like ATM Forum UNI v3.1, problems can arise. ATM Forum UNI v3.1 defines 5 kinds of QoS classes (0~4). When SETUP messages (UNI) are translated into IAM messages (NNI), the information will be lost.

Answer: When interworking between two types of networks (ATM Forum UNI 3.x based and ITU based), some information is usually lost. In this case, the loss is not as significant because there are no universal semantics to QoS class 1-4. Only QoS class 0 is universally defined as "unspecified" which basically implies that no qos is associated with the connection. The specified qos classes 1-4 are network specified i.e. each network provider can assign his own semantics to each class. In this situation, interworking even between two ATMF UNI 3.x networks that use different semantics for specified qos classes, will require proprietary translation techniques. Therefore, the use of qos classes 1-4 is not widespread.

SUBJECT D22-2) Question: Different sources of the same type like VBR may have distinct QoS. Is 5 kinds of QoS class enough to calssify all QoS?

Answer: The use of qos classes is being deprecated. Unfortunately, the parameterized qos did not make it to UNI 4.0, but it will appear in an addendum soon.

SUBJECT D22-3) Question: If a user claims the QoS class is one of VBR services but it provides the PCR parameter only, does CAC treat it as a CBR service or not?

Answer: Currently, qos classes 1-4 are not specified. Not only that, but the bearer capability is seldom used to determine traffic type. It is the ATM traffic descriptor IE that generally determines traffic type. Nevertheless, the UNI spec specifies some allowable combinations of bearer capability and traffic descriptor (see table F-1, UNI 3.1). For example, the user may specify bearer class X with traffic type VBR and timing indication set to none (this would specify non-real time VBR) and may only specify PCR for CLP=0 and CLP=0+1. This is a legal combination. How the switch CAC allocates resources for such a connection is not specified.

SUBJECT D22-4) Question: Do we need fairness between CBR/VBR and the ABR service classes? I've grasped the feeling that first the guaranteed QoS traffic class i.e. CBRs and VBRs are to be serviced and iff no cells are found belonging to these classes, ABR class traffic is to be serviced. But if this is the case, then ABR class may feel starved of servicing and hence lead to excessive delays, degradation in QoS and can lead to excessive traffic submission because of retransmission of packets at higher layers. I don't know whether my assumptions are right or wrong, please clarify.

Answer: There are in fact two assumptions that relate to this scenario, they are the Call Admission Control (CAC) policy that established the connections, be they CBR, VBR, whatever, in the first place, and the policing algorithm at the network (or switch ingress).

The cells traveling in the CBR QoS class were designated as CBR at connection setup time because either the application would not operate satisfactorily otherwise (e.g., high quality voice traffic, circuit emulation, ...) or because the user is willing to pay for the consistently low latency and low cell loss, even for his IP traffic. The resources (bandwidth, or link cell slots, if you like) are allocated at call setup. The "owner" of the link has the responsibility to ensure that new CBR calls are not setup if they would impact the performance of other equally high priority calls. To make this work, CBR calls must always run at the designated, agreed-upon rate, otherwise, they are not CBR! The second assumption, policing, may be used to check that no source is exceeding its contract, although within a given network this may not be necessary, practically speaking.

VBR calls are set up about the same way, with the same CAC policies governing whether to accept new calls, except that a certain tolerance around the nominal cell rate is accepted to accomodate somewhat bursty sources. Again, either the application won't work if the bandwidth contract is not met, or the user will not be getting the service he paid for.

So, the answer is no, we don't really want to promote ABR cells up into the CBR/VBR queues, because the goal cannot be fairness across traffic classes if anyone is to get what they paid for in the higher classes. Consider a sort-of real-world example: if you are using voice-over-ATM across some future carrier ATM network, and you actually paid a premium (the usual voice rates) for the call, you don't really care how many people on the carrier's Internet service (which by the way runs over the same ATM switches) are trying to reach the WWW hot site of the week, or how much delay they suffer. If we used this "promote delayed ABR cells to higher queues" scheme, then the quality of the voice call goes south in proportion to the popularity of that hot site.

The key concept is that trying to deal with fairness only at the cell scheduling level, without considering CAC and policing, leads to undesireable network behaviours.

Note, however, that fairness amoung multiple VC's running ABR is of considerable interest. Weighted Fair Queuing is one scheme proposed to offer some minimum level of service even to lower priorities among a group of different traffic classes, but the weights are likely to be still a function of CAC so that the service levels can be guranteed to the top priorities.

[ Back to Index | FAQ Index | Cell Relay Retreat ]

Maintained by Cell Relay Retreat
Last Changed 24 November 2002