Subject: RE: [NSIS] Re: Modularity and grouping QoS requirements

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Wed, 27 Feb 2002 15:50:13 +0100

Hi Marcus,

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

|> 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));
|
|Here you have at least 4 types (UNI with home network, UNI 
|with foreign 
|network, NNI within same administrative domain, NNI across 
|admin domains.

In draft-partain-nsis-requirements-00.txt there are three types
of interfaces identified:
- interior <-> interior interface
- border node <-> border node interface
- host <-> border node interface
Please see the draft for detailed info.

|> A reasonable way of doing the above, is in my opinion the following:
|> * First define the scenario cases;
|Agreed
Great. 

|> * 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.
Understandable. No one is suggesting to have more entities than
the number of typical network nodes known in the Internet
community. 
What, Georgios is suggesting is that the [NSIS] WG derives requirements
from the scenarios and group them into particular interfaces between 
different nodes they apply to.  This is already done in
draft-partain-nsis-requirements-00.txt. 
Based on this, the QoS model entities would be defined later. 

|> 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)
I already mentioned above one possible way to do it :-). 

|> 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.
Exactly. The framework should be a result of scenarios and the 
requirements derived from them. As it is now in the [NSIS] WG 
draft the things are done in a different order. And as we could 
see it the "problem discussion model" has a problem when one wants
to apply it in other scenarios rather than the ones described in 
the [NSIS] WG draft.

|> 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.
Yes, but it does also impact the QoS requirements. 

|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
Right. But, I think the grouping should be done based on the 
agreement in the meeting at Salt Lake City.  

|>*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.
We already heard from Danny that in their scenarios it was not 
an "easy exercise"...
So, could someone (other than the authors) please try to relate 
one of the Scenarios from draft-partain-nsis-requirements-00.txt
with "Problem Discussion Model" from the [NSIS] WG draft such that
we can close the discussion on the generality of the model? That 
would be appreciated very much.

Regards,
Vlora  

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

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 28 Feb 2002 17:47:06 -0800

Vlora and all,

one reason for using the model in draft-nsis rather than the one in
draft-partain is that it allows to define mobility requirements.
For instance, think of a handoff, where the previous access router (PAR)
transfers QoS context to the new access router (NAR).
There is no NAR-PAR interface in draft-partain; however, it is easy
to see that the NAR is a QC (making the CAC decision at least) for
the new path, and PAR a QI.

Another drawback of the 'interface' framework is that QoS signaling is
not necessary limited to interfaces. For instance, to update some 
reservation
after a handoff, you'd need to signal to the crossover router(s), 
wherever it
is. Most likely this crossover router does not correspond to any interface.
Note that draft-nsis either does not provide such framework, but it could
easily (should) be added with a QoS Termination point abstraction. I think
it is a dead end to assume the starting point and the end point of the 
QoS signaling to
be some pre-defined interface. Draft-nsis goes a half step in the right
direction by allowing the starting point to be anywhere and abstracting 
it into
the QI, which is a better starting point.

Cheers,

Cedric.