Subject: QOS parameters for the service model

From: Mahesan Nandikesan <[email-masked]>
Date: Thu, 7 Oct 1999 12:30:11 -0400 (EDT)

We are working on a couple of Internet Drafts to accommodate the
IEEE PIN resource and service models in the GSMP framework.
We have a few questions about the QOS parameters in the GSMP
service model framework. 

  1. The QOS parameter set in the capability set appears to be
     fixed - CLR, CTD, CDV, frequency. Wouldn't it be better to
     leave it open (like the traffic parameters)?

  2. The QOS parameter values are selected by the switch for each
     capability set and cannot be specified by the GSMP controller. It
     would be better if both options are allowed. 

Mahesan

---

From: [email-masked]
Date: Fri, 8 Oct 1999 23:53:23 +0300

From: EXT Mahesan Nandikesan [mailto:[email-masked]]
> 
> I think there is a misunderstanding.

yes.

> I did not mean that the qos be per connection. What I meant
> is that the only allowed qos parameters are CLR, CTD, CVD and 
> frequency.
> For example, if some service model allows average cell 
> transfer delay (as
> opposed to the maximum cell transfer delay) as a parameter, would GSMP
> support it?

if we want to add to the service model a service 
that has its own qos parameters then we add those
qos parameters.

> Moreover, we are not trying to put the resource model inside the
> service model section of GSMP. The IEEE PIN resource model will go
> in the ARM section. It has already been assigned MType 1. It is the
> IEEE PIN service model that will go in the GSMP service model section.
> 
> Finally, I would like to reiterate question #2:
>    

that depends on what you mean by better. more powerful
and more flexible does not always mean better. consider
for example microsoft word: the feature bloat of this
product massively exceeds the needs of the vast majority
users and comes at considerable cost to both maker and 
customer. (in this case it seems to be only the product
marketing that requires all these features.)

gsmp should provide the features it  *needs* to provide 
and remain otherwise as simple as possible. the features
it provides should come at cost that is commensurate with
the value of the feature.

most atm switches' cacs do not provide for on-the-fly 
modification of a class's qos parameters. this is often 
hard coded or a configuration parameter that can ony be 
change on a switch or board reset. in those cases where 
the qos values can be changed on the switch there is 
already an element management interface (e.g. snmp, 
cli...) that provides this capability.

moreover, allowing these parameters to be set is not
simple. we need to deal with value ranges somehow. if
the controller tries to change a value then the 
responses from the switch could be:

 1 - ok.
 2 - i do not allow any qos parameter value modification 
 3 - i do not allow that qos parameter to be modified
 4 - i allow that qos parameter to be modified but i don't
     allow the particular value you asked for.

1 and 2 are easy. 3 then leads to the question, "well then,
which parameters do you allow to be modified?" which we
would need to address also in gsmp. and with 4 the 
controller will want to know what parameter values would 
be tolerated.

and on top of that we need to decide what should be the
right behaviour when the controller asks for a more
stringent qos value that would make the current connection
state illegal. should the request be rejected? should it
be allowed? if so, what do we do to get back to a legal
state.

it's a non-trivial complexity.

in summary, i personally think that the value of this 
feature as low (it would be no use on many switches) 
and it's cost is high.

c u
tom

---

From: [email-masked]
Date: Wed, 13 Oct 1999 18:48:20 +0300

From: EXT [email-masked] (Mahesan Nandikesan)
>
> The only difference between the current gsmp approach and our 
> proposal is

this whole discussion would be a lot easier for 
me if i knew what your proposal was.

> that
> 
> 1. gsmp does not support the addition of more qos parameter 
> types without
>    changing the format of the corresponding message.
> 
> 2. gsmp does not allow the controller to specify the qos parameter
>    values.
> 
> Neither gsmp nor our proposal supports qos change on the fly.
> 
> Detailed comments are given below.
> 
> Mahesan
> 
> 
> >
> This we believe is rather inflexible.

oh! i guess i still don't understand.

but i would argue with this sentence anyway: flexibility 
is not intrinsically a good thing. it usually comes with 
some cost in complexity. whatever flexibility you want
has to be _required_ by something that the wg things gsmp
ought to support. but i don't know what flexibility 
exactly you want or what it might be for, so i can't
evaluate this proposal.

> We are not suggesting the the qos parameters be changed on the fly.

<sigh> i wish i knew what you are proposing. all i
get to go on are very terse questions that, going
on experience, always lead me down the wrong path.

> The set of qos parameter types that the switch allows the controller
> to specify can be  given in a bit mask, as explained in my previous
> email.
> 
> We don't think it is necessary to worry about qos parameter values
> being rejected by the switch, since the switch can always support any
> stringent qos using a cac based on peak rate allocation.

this implies: 1, that the switch can change its
cac algorithm of the fly and 2, that it can meet 
the delay requirements, which depends on its
hardware, something that can't always be controlled
by software. this feature has a high cost in 
complexity and i have know knowledge of any
applications that require it.

> Therefore, item 4 described above does not arise, in our 
> opinion. Item 3
> is covered by the bit masks.

the bit mast approach also has structural impact on
the switch's cac algorithm with significant cost.

> This again refers to on-the-fly qos change, which we do not
> require.

ok. had i known what your proposal involves i could have
saved myself the time typing this comment. the same can be
said about nearly all of what i have typed on this thread.

this is frustrating. i am so utterly without context 
that i cannot conduct a sensible conversation. i cannot 
be expected to think about what you are proposing without 
knowing what you are proposing. the discussion is 
wasting my time and probably confusing a lot of the good 
folk reading this thread on the list. i'm sorry, but 
until you describe your proposal in a way that i can 
understand, i shall not comment any further.

tom

---

From: Mahesan Nandikesan <[email-masked]>
Date: Mon, 18 Oct 1999 08:38:06 -0400 (EDT)

Let me also re-state the bit-mask proposal. I will  respond to Hans's
email in my next email.

Suppose that we have a 32-bit mask for qos parameter types. (In my
previous email I chose 8 bits as an example, but 32 would be more
appropriate). This permits upto 32 types of qos parameters to be
encoded. For example,

Bit  0:        CTD
Bit  1:        CDV
Bit  2:        CLR
Bit  3:        Frequency
Bit  4:        Average cell transfer delay
Bit  5:        Average gap loss
Bits 6 - 31:   Reserved for future extensions

Each qos parameter is given a code equal to its bit possition in the
mask. For example, Max CTD is given code 0, and CLR is given code 2.

The Capability Set Record of the Service Configuration Message could
be changed as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cap. Set ID  |   Reserved    |       Traffic Controls        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   QOS Parameter Bit Mask                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      First QOS Parameter                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Second QOS Parameter                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                            ...                                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      n-th QOS Parameter                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

QOS Parameter Bit Mask:

       Mask giving which qos parameters are supported in this
       capability set. If a bit is set to 1 then the corresponding
       qos parameter is supported. Otherwise, that qos parameter is
       not supported.

First QOS Parameter:

      Suppose that bit m1 is 1 and all bits in positions lower than m1
      are all zero. "First QOS parameter" specifies the value of
      qos parameter whose code is m1.

Second QOS Parameter:

      Suppose that bit m2 is 1 and all bits in positions lower than m2,
      except m1, are all zero. "Second QOS Parameter" specifies the value
      of the qos parameter whose code is m2.

n-th QOS Parameter:

      Similar to the above.

Thus, the number of qos parameters whose values are specified in the
above structure is equal to the number of bits that are 1 in the bit-mask.

All qos parameters have been given 32 bits for representing their values.
I think this is large enough, but not excessively large either. 
Since the Service Configuration Message is issued only during switch
initialization, a relatively large message should not pose a problem.

Mahesan