Subject: RE: [NSIS] WG requirements draft

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Tue, 26 Feb 2002 10:01:19 +0100

Hi,
 
I think that the NSIS WG should certainly not use this model 
as the basis for the requirements. I believe that initially
the NSIS WG should derive the requirements from typical scenarios/use
cases as it also stated in the [NSIS] WG requirements draft without
any assumptions/relations to any kind of a model. In fact a 
model/framework should be developed based on the derived 
requirements.
I think, the problem with the "discussion model" described in 
Section 4.1, is that it does not seem to be generic enough to 
derive requirements for all the use cases, even though 
introduced for this purpose.
What I mean is that it can not be straightforwardly seen
how this model would apply to typical scenarios/use cases. This 
is due to the fact that the scenarios/use cases described in the
draft are not common as it is considered that there is an
centralized entity for the resource management, i.e. "access 
network manager" ("Scenario 1: Terminal Mobility"), bandwidth 
broker ("Scenario 2: Cellular networks"). Typically this is not the
case since many existing scenarios are using distributed resource 
management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
resource management is provided on a distributed manner by 
many nodes (e.g. RSVP-aware nodes) along the communication path.
Without the assumption of having this centralized resource
management entity it is very difficult to see how this model 
is applied efficiently. For example if there is no such centralized 
entity in the access network such as "access network manager" how
would this model be applied? 
In my understanding  of the model you would need to have on
each node on the communication path a "QoS Initiator" and a 
"QoS controller". This I believe will be a very complex system 
which would deteriorate severely the scalability and performance
of the protocol. This kind of scenario/use case on Terminal 
Mobility, which in my opinion is typical use case, is missing from  
the draft.
As far as I know, centralized resource management is not a goal
of NSIS and it has not been discussed in other individual drafts
submitted to NSIS WG.
So, firstly it looks kind of strange to derive the requirements 
based on a model and also unusual to base them on this specific
model?! 
Furthermore, there are several requirements which are specifically
related to the entities of this model, i.e. QoS
Initiator and QoS controller, such as e.g. requirement on
"Automatic notification on available resources not been granted 
before" (section 5.3.7) where the QoS Initiator would like to 
have notification of resources he requested in the past time... 
To conclude regarding this issue I would appreciate that:
- the NSIS WG derives first the requirements from the scenarios/use
  cases without any assumptions/relations to any kind of a model. 
- the requirements should be based on typical scenarios/use cases
- the requirements should not be dependent on the model entities such
  as "QoS initiator" and the "QoS controller", but should be related to 
  typical scenarios/use cases network entities/nodes, e.g. host, border
  nodes, interior nodes, etc. 
- the requirements should not be constrained to specific resource
  management schemes, i.e. NSIS protocol  should fulfil the QoS 
  requirements independently of the resource management scheme 
  used (centralized or distributed) 

Regards,
Vlora

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

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 26 Feb 2002 12:13:29 +0100

--On Tuesday, February 26, 2002 10:01 AM +0100 "Vlora Rexhepi (ELN)"
> introduced for this purpose.

If you feel that it is not generic enough, could let me know in what 
direction it should be more generic?

> Mobility, which in my opinion is typical use case, is missing from

In todays RSVP you exactly have one QoS controller and initiator on each 
node, and I have not seen somebody claiming this to be wrong so far.

> based on a model and also unusual to base them on this specific

I have no problem to change the model if it is open to cover a broad range 
of scenarios, and several entities need to be named.

>   cases without any assumptions/relations to any kind of a model.

It has proven to be difficult to do this. I would like that it is that easy.

> - the requirements should be based on typical scenarios/use cases

agreed.

>   nodes, interior nodes, etc.

The model with host, border nodes, interior nodes is in my opinion 
restrictive as well. E.g., I don't see how mobilities related scenarios fit 
in, nor how centralized resource management scenarios fit in.

>   used (centralized or distributed)

Completly agree with this.

> Vlora

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

---

From: "Lars.Westberg" <[email-masked]>
Date: Tue, 26 Feb 2002 12:32:56 +0100

Comments regarding mobillity:

> in, nor how centralized resource management scenarios fit in.

The purpose is to get an efficient message processing becase all router do not
need to
process all protocol functionality.
We need modularity of the protocol to get fast reservation setup-time at
handoff.
This can be easily be done if we can divide the requirements on different type
of interfaces/nodes.