Subject: RE: QOS parameters for the service model

From: [email-masked] (Mahesan Nandikesan)
Date: Tue, 12 Oct 1999 15:23:58 -0400 (EDT)

The only difference between the current gsmp approach and our proposal is
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

>
> > 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.
>
>

This we believe is rather inflexible.

> > 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:
> >
> >       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.
>
> 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.

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

>
> 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.

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.

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

>
> 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.
>

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

---

From: Mahesan Nandikesan <[email-masked]>
Date: Fri, 15 Oct 1999 18:11:44 -0400 (EDT)

The previous set of emails deviated from what I intended.  So, let me
rephrase my original two questions and recap Avri's response:

1. The Capability Set Record is given the following structure (page 76
   of the latest spec).

    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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     CLR       |                    CTD                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Frequency    |                    CDV                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This structure contains a fixed set of qos parameters - CLR, CTD,
   Frequency and CDV.
   The question is why not allow the Capability Set Record to be of
   variable length so that additional qos parameters can be placed
   in it?

2. The Service Configuration Message is a "get" message in that it
   tells the GSMP controller the qos parameter values chosen by the
   switch. Why not have an additional "set" message (mainly for
   setting qos parameter values on the switch)?

In my understanding, Avri's response to question #1 was either to
expand the Capability Set Record or provide a mechanism to accommodate
a variable number of qos parameter types. My suggestion was to
have a mechanism using bit masks so that a variable number of
qos parameter types can be used. I think that this does not increase
the complexity in any significant way. Any comments on this suggestion?

For question #2, Avri asked whether we would like to suggest a
mechanism whereby the GSMP controller and the switch can agree on a
set of qos parameter values; but inclusion of such a mechanism would
increase the complexity. I agree. On the other hand I think that the
switch should be able to accept any qos parameter values specified by
the GSMP controller: It can always use a cac based on peak rate
allocation if its normal cac fails to work with those qos parameter
values. Tom suggested that this would involve change of cac on the
fly. Actually, this is not on the fly in the sense that at
initialization-time the switch has to choose between its "normal" cac
and the peak-rate-based cac. Once chosen, the cac is not changed.
Any opions on this?

Mahesan

---

From: "Hans Sj�strand" <[email-masked]>
Date: Sun, 17 Oct 1999 19:13:38 +0100

Hi,

I haven't been around for the whole QoS discussion, but please realize
that there are parallell mechanisms to GSMP, and the best protocool
should be choosen for each task. 

Queue management, CAC configuration and tuning etc. are very complex and
are today handled in mibs, most often quite large and very propriatery
ones. There you have the complete fredom the switch allows. Trying to
get those models squezed into a GSMP record is simply using the wrong
tool. 

Regards
/// Hasse

Mahesan Nandikesan wrote:
[zip]
>    setting qos parameter values on the switch)?
[zip]

---

From: Mahesan Nandikesan <[email-masked]>
Date: Tue, 19 Oct 1999 22:49:26 -0400 (EDT)

The point that I wanted to make is that a GSMP controller should be
able to set qos parameter values on the switch.

The discussion on the CAC was to illustrate one possible
way of how this can be achieved without the need for any negotiation
phase. The switch is free to adopt any other approach.

Mahesan