Subject: [NSIS] Interpretation of <Priority> Parameter for QOSM CLS

From: Bernd Schloer <[email-masked]>
Date: Sat, 9 Dec 2006 12:25:20 +0100 (MET)

Hi,

here's a suggestion how to handle the <Priority> parameter. What do you think of it?

Bernd

The following object combinations are defined:

1. <Admission Priority>   Priority Queueing  [Y.1541]

2. <Admission Priority>   Preemption         [RFC 3181]
    <Preemption Priority>                     [3GPP-1]
    <Defending Priority>                      [3GPP-2]
                                              [3GPP-3]

3. <RPH Priority>         q735 = Preemption  [RFC 4412]
                           ets  = Priority Q.
                           wps  = Priority Q.

1. The QOSM CLS has 3 priority queues: Best Effort (0), Normal Priority CLS Traffic (1),
and High Priority CLS Traffic (2). According to <Admission Priority> the corresponding
queue is selected. If no <Priority> parameter is given the default priority is Normal
Priority (1). <Defending Priority> is a default value or 0.

2. If <Admission Priority> is not given, the default priority is Normal Priority (1).
A non-admitted flow with any <Preemption Priority> value can preempt an already admitted
flow with lower priority in ascending order of priority. One single higher priority flow
may replace more than one lower priority flow until the requested amount of <Traffic> is
met. <Preemption Priority> and <Defending Priority> are compared when no flow with lower
priority could be preempted. A flow with higher <Preemption Priority> can preempt an already
admitted flow with lower <Defending Priority>. Once the flow is admitted
<Preemption Priority> becomes irrelevant.

3. [RFC4412] defines a number of namespaces. Each namespace has a finite list of relative
priority values. A mapping of 5-6 <RPH Priority> to 3 <Admission Priority> parameters has
to be done, e.g.

  RPH  A.P.
-----------
   4 -> 0   lowest priority
   3 -> 1
   2 -> 1
   1 -> 2
   0 -> 2   highest priority

A non admitted flow using the namespace q735 can preempt an already admitted flow with lower
priority in ascending order of priority. Requests do not preempt flows of equal order. In this
case the flow is queued. Requests with the lowest priority do not preempt any admitted flow and
are queued as well. One single higher priority flow may replace more than one lower priority flow
until the requested amount of <Traffic> is met. The namespaces ets and wps are queued according
to their priority levels.

The following object combinations don't make sense in my opinion:

<Preemption Priority>, <Defending Priority> and <RPH Priority>:
with or without <Admission Priority> it is not clear who is in charge of preempting
<Preemption Pr.> or <RPH PR.> ?

<Preemption Priority>, <Defending Priority>:
<Admission Priority> is missing -> no queue or lower priority flows can be selected.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis