Subject: [NSIS] Modularity and grouping QoS requirements

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 27 Feb 2002 11:37:14 +0100

Dear John and Marcus

One of the outcomes of the NSIS meeting in Salt Lake City was 
to start working on defining QoS requirements based on scenario cases.

Furthermore, we all agreed that modularity is very important;
During that meeting many people agreed that after the QoS requirements 
are defined, then they will be grouped according to network  
interfaces (e.g., UNI (access), NNI (backbone));

A reasonable way of doing the above, is in my opinion the following:
* First define the scenario cases;
* Second using these scenario cases, define which QoS requirements will have 
   to be satisfied on each network interface, and on each network node type, e.g.,
   host, access router, interior router, border router, edge router, proxy, bandwidth broker, ...
* Third the outcome of this separation of QoS requirements it will result in 
  an efficient grouping of the QoS requirements.

After the QOS requirements grouping is done, then we could define a QoS model.
This QoS model could have entities such as a QoS initiator and a QoS controller.

The problem I have with the NSIS WG requirements draft is that these sequence of
doing things is very much opposite to the sequence mentioned above. In the NSIS WG
requirements draft the following sequence of actions is followed:
* First a QoS model and its QoS model entities are defined. At this stage, these 
  QoS model entities, e.g., QoS initiator and QoS controller, are not representing 
   network entities.
 * Second, the QoS requirements are grouped according to these QoS  model entities 
   and not grouped according to any network interface or any network node type!
* Third, the QoS model entites are assigned to specific network node types. In my opinion 
  this  step is difficult to be accomplished and for some scenarios is impossible to be done.

Best regards,
Georgios

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

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 27 Feb 2002 15:03:35 +0100

Georgios,

I am open to the consensus of the WG. Just some remarks inline.

--On Wednesday, February 27, 2002 11:37 AM +0100 "Georgios Karagiannis 

> interfaces (e.g., UNI (access), NNI (backbone));

Here you have at least 4 types (UNI with home network, UNI with foreign 
network, NNI within same administrative domain, NNI across admin domains.

> * First define the scenario cases;
Agreed

> * Second using these scenario cases, define which QoS requirements will
> have     to be satisfied on each network interface, and on each network
> node type, e.g.,    host, access router, interior router, border router,
> edge router, proxy, bandwidth broker, ...

We can still do it my concern is that we have then with N scenarios (N 
currently 5 to be more) and M interfaces (M as mentioned above =4) and L 
node types (L=7 in your proposal)

This implies NxMxL entities we have to define requirements for. And this I 
am definitly not willing to do.

> Third the outcome of this
> separation of QoS requirements it will result in    an efficient grouping
> of the QoS requirements.

We can discuss the grouping (I was just to lazy to change it so far)

> After the QOS requirements grouping is done, then we could define a QoS
> model. This QoS model could have entities such as a QoS initiator and a
> QoS controller.

Yes, that is what the framework document does.

>
> The problem I have with the NSIS WG requirements draft is that these
> sequence of doing things is very much opposite to the sequence mentioned
> above. In the NSIS WG requirements draft the following sequence of
> actions is followed:

> First a QoS model and its QoS model entities are
> defined. At this stage, these    QoS model entities, e.g., QoS initiator
> and QoS controller, are not representing     network entities.

This is the second step in the draft and it is ment to reduce the node 
types.

I understand that some people have problems to see the value of it, others 
very much appreciated the more abstract way of thinking. I would say it is 
50:50 so far.

And some even think we should get more abstract

>  * Second, the QoS requirements are grouped according to these QoS  model
> entities     and not grouped according to any network interface or any
> network node type!

No they are grouped into topics like security, flow definition, 
architectural, etc. The grouping actually as nothing to do with the model

>*Third, the QoS model entites are assigned to
> specific network node types. In my opinion    this  step is difficult to
> be accomplished and for some scenarios is impossible to be done.

You might be right, but we have done it so far. Currently I do not see it 
as too difficult, but I might be wrong.

Marcus
> Georgios

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus