Subject: [NSIS] WG requirements draft

From: David Partain <[email-masked]>
Date: Tue, 26 Feb 2002 09:33:48 +0100

Hi all,

After having glanced at the new draft, I want to see whether the
working group is "on board" with the model that this draft uses
for approaching the requirements.  The requirements are based
very heavily on the model which includes the "QoS initiator"
and the "QoS controller" rather than, as I see it, growing
out of the scenarios being used.

I'm rather uncomfortable with the whole QoS initiator/controller
model, since it seems to head right down the path of bandwidth
brokering with centralized "smarts" that make a decision.
While there may be places where this is appropriate, I don't
think we should be building requirements on this model.

I haven't seen the QoS initiator/controller model discussed much
here, and I don't think there's consensus one way or another,
so I'm asking:  Should the WG use this model as the basis for
our requirements?  I certainly have my doubts about that.

Cheers,

dlp

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 26 Feb 2002 08:55:56 -0000

David,

Some notes:
*) The requirements model is not supposed to constrain solutions to any particular approach, it's supposed to provide language in which to discuss the requirements. If you feel that the model favours one approach over another, then we obviously failed in that area. However ...
*) We found that the original (draft-brunner-...) did give the impression (section 4) that QCs were basically bandwidth brokers, mainly because the diagrams showed them operating that way. **That was not the intention** (not my intention, anyway), and the draft-ietf-... adds some text to emphasise that. The QCs could be at every node and QIs at every host, and then you would have classical RSVP. Maybe this is still unclear?
*) It's true on the other hand that we wanted terminology that could be used to describe the BB scenario, and other interesting scenarios (e.g. the 'local SIP server takes charge of QoS signalling' scenario introduced recently, which is just captured by saying that the QI and traffic endpoint might not be in the same place). We certainly wanted to avoid a model that _implicitly_ ruled these scenarios out.
*) Of course, people might still want to restrict the allowed design space to say that things like disjoint QI/endpoint or BBs were not in NSIS scope, which is something that we can discuss. The terminology can then be used to capture that restriction _explicitly_.
*) So if any scenario can be covered by the QI/QC terms, what are they for? We wanted to be able to capture issues about how and where NSIS interacted with non-NSIS things, like where the application interactions took place, and where the interactions with QoS provisioning took place. We also wanted to have hooks to describe what entities had what security relationships with each other (which is also something that has been under-discussed on the mailing list).

We need words for 'the things that take part in NSIS signalling'. But that's all that QI and QC are supposed to be.

Yours,

Robert H.

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: 26 February 2002 08:34
> To: NSIS Mailing List
> Subject: [NSIS] WG requirements draft
> 
> 
> Hi all,
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 26 Feb 2002 09:13:40 -0000

Vlora,

For most of your points, please see my earlier reply to your colleague. Some particular aspects:

*) You would like more scenarios. Me too. People have to provide them.

*) To be most useful, I believe that these scenarios need to be described with some common core terminology to describe the entities taking part in NSIS related signalling. Otherwise, it will be hard to tell from a plain text description what aspect of the scenario is part of the problem we are trying to solve, and what is not.

*) Having said which, I really fail to see how the act of giving the names 'QoS initiator' and 'QoS controller' to these entities leads to "a very complex system which would deteriorate severely the scalability and performance of the protocol" as you put it.

Yours,

Robert H.

> From: Vlora Rexhepi (ELN) [mailto:[email-masked]]
> Sent: 26 February 2002 09:01
> To: [email-masked]'; NSIS Mailing List
> Subject: RE: [NSIS] WG requirements draft
> 
> 
> 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
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 26 Feb 2002 10:21:35 +0100

Hi Robert 

Please see my comments in line!
[RH]> *) The requirements model is not supposed to constrain
[RH]>  solutions to any particular approach, it's supposed to provide 
[RH]> language in which to discuss the requirements. If you feel that 
[RH]> the model favours one approach over another, then we obviously 
[RH]>  failed in that area. However ...

Sorry Robert, but in my opinion this model favours the centralised 
resource management approach.
If such a model would be used in a distributed approach, then it will mean that
there will be a lot of QoS initiators and QoS controllers, that will probably
make the life very complex and the protocol non-scalable and too slow!

[RH]> *) We found that the original (draft-brunner-...) did give the 
[RH]> impression (section 4) that QCs were basically bandwidth brokers, 
[RH]> mainly because the diagrams showed them operating that way. **That was 
[RH]> not the intention** (not my intention, anyway), and the draft-ietf-... 
[RH]> adds some text to emphasise that. The QCs could be at every node 
[RH]> and QIs at every host, and then you would have classical RSVP. 
[RH]> Maybe this is still unclear?

I believe that this scenario will become very complex, non-scalable and 
very slow!

[RH]> *) It's true on the other hand that we wanted terminology 
[RH]> that could be used to describe the BB scenario, and other 
[RH]> interesting scenarios (e.g. the 'local SIP server takes charge 
[RH]> of QoS signalling' scenario introduced recently, which is 
[RH]> just captured by saying that the QI and traffic endpoint 
[RH]> might not be in the same place). We certainly wanted to 
[RH]> avoid a model that _implicitly_ [RH]>  ruled these scenarios out.

Yes, but I think that this model rules out common scenarios, for example such the 
ones described in:
http://search.ietf.org/internet-drafts/draft-partain-nsis-requirements-00.txt

[RH]> *) Of course, people might still want to restrict the allowed 
[RH]> design space to say that things like disjoint QI/endpoint or 
[RH]> BBs were not in NSIS scope, which is something that we can 
[RH]> discuss. The terminology can then be used to capture that 
[RH]> restriction _explicitly_.
[RH]> *) So if any scenario can be covered by the QI/QC terms, 
[RH]> what are they for? We wanted to be able to capture issues 
[RH]> about how and where NSIS interacted with non-NSIS things, 
[RH]> like where the application interactions took place, and where 
[RH]> the interactions with QoS provisioning took place. We also 
[RH]> wanted to have hooks to describe what entities had what 
[RH]> security relationships with each other (which is also something 
[RH]> that has been under-discussed on the mailing list).
[RH]> We need words for 'the things that take part in NSIS 
[RH]> signalling'. But that's all that QI and QC are supposed to be.

I think that the best terms that one could use to describe the 
entities used by the NSIS protocol are network entities, such as:
hosts, routers, edge routers, interior routers, proxies, etc.,

best regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: dinsdag 26 februari 2002 9:56
To: [email-masked]'; NSIS Mailing List
Subject: RE: [NSIS] WG requirements draft

David,

Some notes:

Yours,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 26 Feb 2002 09:58:02 -0000

Hi Vlora/Georgios,

On the functionality of QI/QC issue, do you believe that the functionality as defined in the draft is anything more than the minimum possible? In particular
*) do you believe that it is possible to have a QoS signalling exchange without someone interpreting higher layer QoS requests to decide what QoS to request? This is all that the QoS initiator does.
*) do you believe that it makes sense to have QoS signalling being interpreted by an entity which then doesn't apply any provisioning to make sure it is supported? This is all that the QoS controller does. (Actually, we did identify other cases in our framework document draft-hancock-..., where the QC does even less - they're all to do with optional capabilities like hooking into accounting and so on. So in fact, the QC can do as little as you like. Maybe the definition needs a tweak.)

On the 'appropriate terminology' issue, the options you & Georgios suggest actually seem to constrain the possible solutions. It seems to imply that QoS signalling can *only* be handled by [end?] hosts and routers, it distinguishes special types of routers, which may not apply to every scenario (Is my home gateway a host? Does my network provider see it as a router? If it is CPE, is it an edge or interior router?). I think the term 'proxy' is itself so generic that further definition is required. At a minimum, we would have to decorate these terms with 'NSIS-aware' and 'NSIS-unaware' and so on.

On the specific issue of BBs/centralised resource management (which people seem particularly concerned about), it is also not my (personal) field of interest to define algorithms/protocols to support this specific approach. However, I think we do have to at least consider how NSIS interacts with networks using such an approach. Saying that NSIS signalling has to follow the data path and that there is a special type of edge router that proxies this signalling into the BB by some private mechanism is one option (probably a good one), but it strikes me that restricting the terminology so that this is the only solution that can even be described is going some way into the design stage.

Yours,

Robert H.

> Sent: 26 February 2002 09:36
> To: NSIS Mailing List
> Hi Robert,
> |*) You would like more scenarios. Me too. People have to 
> provide them.
> I would very much like to have some typical scenarios/use cases. 
> These are missing from the current draft.
> 
> |*) To be most useful, I believe that these scenarios need to 
> |be described with some common core terminology to describe the 
> |entities taking part in NSIS related signalling. Otherwise, it 
> |will be hard to tell from a plain text description what aspect 
> |of the scenario is part of the problem we are trying to solve, 
> |and what is not.
> I think that we should relate the requirements to network entities
> (e.g. host, border node, proxies,etc) and not use abstract concepts
> to do so.
> 
> |*) Having said which, I really fail to see how the act of 
> |giving the names 'QoS initiator' and 'QoS controller' to these 
> |entities leads to "a very complex system which would 
> |deteriorate severely the scalability and performance of the 
> |protocol" as you put it.
> Well it is not about the names it is about the functionality of
> these entities when applied into every node. Just to recall here
> the definition of these two entities as given in the draft:
> "
>    QoS Initiator: this is responsible for generating the QSCs for
>    traffic flow(s) based on user or application requirements and
>    signaling them to the network as well as invoking local QoS
>    provisioning mechanisms.  This can be located in the end 
> system, but
>    may reside elsewhere in network.
> 
>    QoS Controller: this is responsible for interpreting the signaling
>    carrying the user QoS parameters, optionally 
> inserting/modifying the
>    parameters according to local network QoS management policy, and
>    invoking local QoS provisioning mechanisms.
> "
> If you would want this functionality in every node on the 
> communication path it will be a very complex system that will not
> scale and that will perform poorly.
>    
> 
> Regards,
> Vlora
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 26 Feb 2002 11:16:16 +0100

Hello Vlora,

I'd suggest people to create NSIS usage scenarios with whatever terminology they like. In a later stage, NSIS may define a terminology and than re-edit the scenarios accordingly. I don't think that the terminology has much influence on the initial NSIS requirements.
As I further don't believe in the single best NSIS architecture, I dislike the idea of restrictions in creativity on a signaling architecture by now too. IETF always left the decision on the best way to operate a system to the market and I'd prefer to leave it that way. 

>    system, but may reside elsewhere in network.
> 
>    carrying the user QoS parameters, optionally inserting/modifying
>    the parameters according to local network QoS management policy,
>    and invoking local QoS provisioning mechanisms.
> "

The text says that the QoS Initiator could be one (or more) proxies or the end system and the QoS Controller could be a specialised single node (e.g. edge), all nodes or a centralised system or any hybrid solution. If we all feel happier if all possibilities are mentioned explicitely, let's do that. I personally don't have a problem with this text. It covers the solution I prefer as well as the one I don't.

Regards, Rüdiger

---

From: [email-masked]
Date: Tue, 26 Feb 2002 11:25:36 +0100

Hi Hancock, David and all,

Just some reflection on requirements, models, etc

Clearly at the current stage of NSIS WG, it is too early to derive
requirements from one model/framework. However I agree with Hancock that
we should (try to) define the basic functions involved in end-to-end QoS
signaling. From this persperctive, the definition of QoSInitiator and
QoSController as in draft-brunner-... is for me a useful first step. 

Of course, the definitions need further work, and certain
characteristics may be "universal", while other QI/QC features may
depend on their actual place in the end-to-end signaling path. 

Second, the number of "models/frameworks" to dervice requirements. 

What I like in the draft-brunner-... is that depending on the actual
network segment (access, core, etc), or simply the deployed network, the
QoS approach may be different. Clearly different access technologies
have different QoS approaches (e.g. UMTS PDP signaling ,PacketCable
RSVP+ signaling, etc) and this is totally different from e.g. IP
DiffServ.  This may give two "high-level" requirements derived from
observation of today networks:

- First, different QOS approaches may co-exist  and QoS signaling should
allow their interworking. 
- Second, the NSIS approach should allow for a gradual deployment on
existing , mainstream network equipment. Up to know, this high-level
requirement was always one of the basic QoS show-stoppers (see e.g. RFC
2990 for an analysis of IntServ & DiffServ). 

This may yield two signaling requirements:

- at certain points in the end-to-end signaling path (e.g. at the edge)
one has a "QoS mapping" function. For example, it could be that in UMTS
networks (from terminal to GGSN edge), the QoS signaling and reservation
is still done by the existing UMTS PDP protocol or via session SIP
signaling, then the QoS parameters are captured at the network edge and
the QI-edge generates "NSIS" signaling further downstream.
- An out-of-band NSIS agent could exist in same parts of the network,
because a network provider is not likely to upgrade all its routers for
participating in the QoS Internet. This may yield the requirement that
in-band and out-of-band signaling should be able to interwork.

I think at current stage, we should have no restriction regarding
models, etc but try to identify the two/three key (mainstream)
approaches that are actually in place or proposed today. 

Regards,
Danny

"Hancock, Robert" wrote:
>   ------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

---

From: [email-masked]
Date: Tue, 26 Feb 2002 11:25:24 +0100

Hi Vlora,

Allow me to jump into this discussion. I believe that the QI, QC controller
model at least has the merit of clearly identifying the interfaces that we
are deriving requirements for. When applied to various use cases, it allows
to discover functionality that is common between different entities in the
different use cases. In this way, we are looking for common functionality
which will lead to the core nsis requirements.
I am a bit surprised to see the discussion emphasize on centralised or
distributed resource management. While both obviously should be allowed,
resource management is clearly a local (intra-domain) matter and as such it
should probably be decoupled from the end-to-end issues. For this reason,
we have introduced a two-level approach with preprovisioned bandwidth
pipes, allowing simple admission control and both distributed and
centralised resource management.

Cheers,
Sven.

"Vlora Rexhepi (ELN)" <[email-masked]> on 26/02/2002
10:01:19

  To:          "[email-masked]'"                 
               <[email-masked]>, NSIS Mailing     
               List <[email-masked]>                           
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

  Subject      RE: [NSIS] WG requirements draft               
  :                                                           

Hi,

  as "QoS initiator" and the "QoS controller", but should be related to
  typical scenarios/use cases network entities/nodes, e.g. host, border

Regards,
Vlora

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 26 Feb 2002 11:33:25 +0100

Hi Georgios and Vlora, 

the basic idea of QoS Initiator and QoS Controller is_just_ giving a name to the entity _intitiating_ QoS signaling, and another name to entities _processing_ QoS signalling (we believe their functionality is sufficiently distinct as to give them different names) This is all there is to it!!!!! Doesn't this make perfect sense?

Of course we then tried defining more precisely what QIs and QCs are. In fact we updated the definition somewhat in the framework draft http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00.txt. We are happy to amend it when somebody comes up with something better! (I append the updated definition to this mail)

As opposed to restricting possible scenarios and architectures, the goal is having general, abstract language that integrates as may of them as NSIS deems reasonable! (I.e. the Definition of QI and QC must such that this goal is met)

In a second step, these entities should of course be mapped on "hosts, routers, edge routers, interior routers, proxies, etc.," I think it makes sense to describe the QoS functionality performed by these entities via some common term, rather than identifying and describing individually how each of them acts when it initiates / processes QoS signaling - just because there is lot's of communality! This will make fixing the actual protocol much easier. And stating the requirements too.

_Of course_ it is important to have detailed scenarios describing how QoS signaling works with each of these entities (hosts, routers, edge routers etc). And in fact we see no problem in performing this mapping. Please see the framework draft cited above, in which we worked out different signalling scenarios involving proxies, edge routers, RSVP... and how they can be mapped or integrated in to this common "language".

I fail to see how this will make anything more complicated....

More comments inline.

> From:	Georgios Karagiannis (ELN) [SMTP:[email-masked]]
> Sent:	Tuesday, February 26, 2002 10:22 AM
> To:	'Hancock, Robert'; [email-masked]'; NSIS Mailing List
To re-iterate Robert's point: this terminology does not at all favor centralized bandwith-broker-like approaches. It as easily translates into edge-to-edge signaling or even hop-by-hop signaling (for an illustration see framework draft)

> make the life very complex and the protocol non-scalable and too slow!
Only to the extent that distributed approaches are slow by their very nature... You seem to be concerned introducing QIs and QCs will add lots of extra functionality. Just re-naming something doesnt do this, does it? 

> I believe that this scenario will become very complex, non-scalable and 
	See above.

> [RH]> interesting scenarios (e.g. the 'local SIP server takes charge > 
> [RH]> of QoS signalling' scenario introduced recently, which is > 
	I have to check that one out. It's been on my reading list for since you posted it. Comments later.

> hosts, routers, edge routers, interior routers, proxies, etc.,
	See above. Of course one should do this, too. But also point to their common functionality.

	Best regards, Cornelia

	-------------------------------------------------------------------

	Definition of QI and QC from framework draft:

	   The QoS initiator starts the request for QoS for a user flow.  It 
	   might be located in the end system or within some part of the 
	   network, such as the edge router for an access network, or even an 
	   application layer proxy. The distinguishing feature of the QoS 
	   initiator is that it acts on triggers coming (directly or 
	   indirectly) from the higher layers in the end systems, mapping the 
	   QoS requested by them. It also provides feedback information to the 
	   higher layers which might be used by transport layer rate management 
	   or adaptive applications. 
	    
	   In our model, the QoS initiator is a particular instance of the 
	   generic NSIS agent shown in Figure 1, which will have 
	   *) Triggers from and feedback to upper layer applications 
	   *) Typically, no incoming QoS requests 
	   *) Typically, one outgoing QoS request per application data flow 
	   *) Local QoS provisioning functions for the first hop (for both the 
	   IP and link layers) 
	    
	   Likewise, the QoS controller manages and enforces QoS further along 
	   the path. It might be located in some or all routers, or in a 
	   separate network element, e.g. in a bandwidth broker (note therefore 
	   that QoS controllers are not constrained to lie on the traffic 
	   path). If QoS is to be provisioned on a path segment, there must be 
	   at least one QoS controller to do this (but this would not be needed 
	   for example in overprovisioned QoS subdomains). The QoS controller 
	   does not interact with higher layers, but interacts with the QoS 
	   initiator and possibly more QoS controllers further along the path. 
	    
	   In our model, the QoS controller is another particular instance of 
	   the generic NSIS agent, which will have: 
	   *) Incoming and outgoing QoS requests. Incoming QoS requests are 
	   interworked to outgoing requests. The interworking might consist of 
	   managing additional flows (e.g. aggregation or disaggregation), or 
	   interpreting the QoS requested by the user in terms of the QoS 
	   allowed by some SLA (e.g. on inter-domain links). 
	   *) If the local QoS cannot be provisioned by sending the appropriate 
	   outgoing QoS request, subdomain-specific QoS provisioning signaling 
	   can be invoked. In this case, the provisioning mechanism is opaque 
	   to NSIS and can be locally implementation specific. 
	   *) Accounting and authentication information may be exchanged with 
	   local AAA nodes. The precise protocol used to do this is again 
	   outside the scope of NSIS signaling.

---

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

Hi Marcus and All,

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

As  I already said the typical scenarios/use cases are missing and once 
trying to apply the model to such scenarios it is not straightforward to
do so. Also in my opinion the model is clearly in favour of centralised 
resource  management. Therefore I believe it is not generic enough.
In the introduction of [NSIS] WG draft it is said "Therefore there might 
different requirements on QoS signalling applying to different parts 
of the network", which is very true. So why not use this reasoning
to derive and group the requirements instead? 
This kind of approach is used in draft-partain-nsis-requirements-00.txt.
where the QoS requirements are separated into QoS requirements specific
to a particular interface between different parts of the network.
This way does not suggest any  "constraints" on possible solutions.
Further, my concern is that the "problem discussion model" is more
into suggesting a solution/signalling framework rather than just 
identifying the requirements. 
Also the requirements heavily depend on the "QoS Initiator"
and "QoS Controller".

Some more comments inline:

|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.
True, but if there is a requirement related to QoS Initiator such as for
example " Automatic notification on available resources not been
granted before", how would this work in a single node with distributed
resource management?

|> 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?!
|
|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.
Please have a look at the draft-partain-nsis-requirements-00.txt.

|> 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.
|
|It has proven to be difficult to do this. I would like that it 
|is that easy.
|
I have to refer to the draft-partain-nsis-requirements-00.txt again :-).

|> - the requirements should be based on typical scenarios/use cases
|
|agreed.
Great!

|> - 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 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.
If a domain is applying a centralized resource management or 
overprovisioning, NSIS protocol would be applied at the edges of a
domain. 
In case of mobility, the NSIS QoS protocol can be applied between an 
Access Router and a proxy - "Joint point of reservation" that would 
be located in the QoS aware segment that maintains an end-to-end 
reservation, but due to handover it should be able to 
change/modify this reservation. 

|> - 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)
|>
|
|Completly agree with this.
Great!

Regards,
Vlora

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 26 Feb 2002 16:41:06 +0100

Hi Vlora,

> A question related to the definition of QI:
> The QoS Initiator is located in "the end system or within some
> part of the network, such as the edge router for an access 
> network, or even an application layer proxy" and is used to 
> communicate with higher layers. What does this mean for any other
> node, e.g. interior node? Can the QI be part of the interior node?

Why not? The definition doesn't exclude it.

Regards, Rüdiger

---

From: [email-masked]
Date: Wed, 27 Feb 2002 10:07:45 +0100

Hi Larsse,

I agree that the architecture should be flexible to cope with the (main)
different scenarios, especially access/core may involve different
scenarios, models,... It seems to me that part of the confusion is
because we want to write down requirements for a kind of abstract "QoS
signaling interface" while in fact we clearly have in mind some kind of
models/use cases. 

It seems that we could have 2 approaches to tackle the problem.

- One possibility is to try to define generic functional entities (like
QI and QC) and then - afterwards - to see how these entities are
"instantiated" concretely on a certain interface.

- Another possibility is to try to identify the basic scenarios, to
recognise that there are possibly different Qos interfaces (with
different requirements). For example, i clearly see a difference between
access QoS and core QoS (interface host - edge and edge -core). In the
core, we could, as you suggest, identify two approaches (centralised
/distributed) and try to see how then can interwork. 

In the draft we published, we identified different types of interfaces
(especially access/core) and then tried to see how the generic
definitions of QI and QC apply and list the basic requirements for the
QI-to-QC interface (as we see it). I must admit it's not an easy
excercise.

At current stage, both approaches can be tried and we can see how things
convergence: try to have generic defintions of functional entities and
see how they apply to concrete situations (and of course, concrete
scenarios help to define generic functions...)

Regards,
Danny

"Lars.Westberg" wrote:
> 
> Hi, Sven
> We have different needs for different application scenarios. In a backbone
> network a centralized solution is a very good
> idea, especially when we have a possibility for a certain degree of
> overprovisioning.
> However, I think the archtecture has to cope with all different scenarios and
> therefore has to flexible enough
> without limiting the needs for different applications.
> 
> I would propose the we have two different scenarios explicitly in the
> requirements draft:
> One for a Bandwidth Broker case and one for a typical RSVP scenario.
> 
> Regards Lasse
> [email-masked] wrote:
> 
> > Hi Vlora,
> >
> > The idea is to have preprovisioned bandwidth pipes under the control of a
> > local entity (NMS or router) that talks to the QC. The pipes implement a
> > certain QoS (edge-to-edge delay, jitter, ...). The QC then only has very
> > simple AC to do when a request arrives (check whether it fits in the pipe).
> > This makes sense for a number of reasons:
> > - A number of services will require similar QoS
> > - If each flow is treated independently, the QoS may change with new
> > incoming requests
> > - The provisioning action is a local matter: it may be distributed or
> > centralised.
> >
> > Regards,
> > Sven.
> >
> > 11:19:09
> >   To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
> >
> >   cc:
> >
> >
> >
> > Hi Sven,
> > |Allow me to jump into this discussion. I believe that the QI,
> > |QC controller
> > |model at least has the merit of clearly identifying the
> > |interfaces that we
> > |are deriving requirements for. When applied to various use
> > |cases, it allows
> > |to discover functionality that is common between different
> > |entities in the
> > |different use cases. In this way, we are looking for common
> > |functionality
> > |which will lead to the core nsis requirements.
> > As I said the scenarios/use cases described in the draft are
> > not the typical ones and while trying to apply the model to a
> > typical scenario it was not as clear and straightforward to do
> > so. Furthermore it turned out to be quite complex.
> >
> > |I am a bit surprised to see the discussion emphasize on centralised or
> > |distributed resource management. While both obviously should
> > |be allowed,
> > |resource management is clearly a local (intra-domain) matter
> > |and as such it
> > |should probably be decoupled from the end-to-end issues. For
> > |this reason,
> > |we have introduced a two-level approach with preprovisioned bandwidth
> > |pipes, allowing simple admission control and both distributed and
> > |centralised resource management.
> > This is because the model is according to my opinion clearly in favor
> > of the centalised approach.
> > What do you exactly mean by preprovisioned bandwidth pipes?
> > Where are they going to be applied to?
> >
> > Regards,
> > Vlora
> >

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Wed, 27 Feb 2002 11:04:22 +0100

Hi Sven,

I have not read your draft yet, and you might have explained 
this there already...
The idea of QoS pipes seems interesting, but what will be used 
for communication between this local entity and the QC?

Regards,
Vlora

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]
|Sent: Tuesday, February 26, 2002 1:37 PM
|To: Vlora Rexhepi (ELN)
|Cc: [email-masked]
|Subject: RE: [NSIS] WG requirements draft
|
|
|Hi Vlora,
|
|The idea is to have preprovisioned bandwidth pipes under the 
|control of a
|local entity (NMS or router) that talks to the QC. The pipes 
|implement a
|certain QoS (edge-to-edge delay, jitter, ...). The QC then 
|only has very
|simple AC to do when a request arrives (check whether it fits 
|in the pipe).
|This makes sense for a number of reasons:
|- A number of services will require similar QoS
|- If each flow is treated independently, the QoS may change with new
|incoming requests
|- The provisioning action is a local matter: it may be distributed or
|centralised.
|
|Regards,
|Sven.
|
|
|
|
|
|"Vlora Rexhepi (ELN)" <[email-masked]> on 26/02/2002
|11:19:09
|                                                              
|                                                              
|                                                              
|  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
|                                                              
|  cc:                                                         
|                                                              
|                                                              
|                                                              
|  Subject      RE: [NSIS] WG requirements draft               
|  :                                                           
|                                                              
|
|
|
|
|
|Hi Sven,
|
||Allow me to jump into this discussion. I believe that the QI,
||QC controller
||model at least has the merit of clearly identifying the
||interfaces that we
||are deriving requirements for. When applied to various use
||cases, it allows
||to discover functionality that is common between different
||entities in the
||different use cases. In this way, we are looking for common
||functionality
||which will lead to the core nsis requirements.
|As I said the scenarios/use cases described in the draft are
|not the typical ones and while trying to apply the model to a
|typical scenario it was not as clear and straightforward to do
|so. Furthermore it turned out to be quite complex.
|
|
||I am a bit surprised to see the discussion emphasize on centralised or
||distributed resource management. While both obviously should
||be allowed,
||resource management is clearly a local (intra-domain) matter
||and as such it
||should probably be decoupled from the end-to-end issues. For
||this reason,
||we have introduced a two-level approach with preprovisioned bandwidth
||pipes, allowing simple admission control and both distributed and
||centralised resource management.
|This is because the model is according to my opinion clearly in favor
|of the centalised approach.
|What do you exactly mean by preprovisioned bandwidth pipes?
|Where are they going to be applied to?
|
|Regards,
|Vlora
|
|
|

---

From: [email-masked]
Date: Wed, 27 Feb 2002 13:31:03 +0100

Hi Lasse,

I think there can hardly be any objection to list as many scenarios as we
can come up with and investigate what requirements derive from those.
Please also note that we propose to reuse as much as possible the access
QoS technologies in order to avoid duplication of functionality.

Regards,
Sven.

"Lars.Westberg" <[email-masked]> on 26/02/2002 17:18:30

                                                              
  cc:          "Vlora Rexhepi (ELN)"                          
               <[email-masked]>, [email-masked] 

  Subject      Re: [NSIS] WG requirements draft               
  :                                                           

Hi, Sven
However, I think the archtecture has to cope with all different scenarios
and

Regards Lasse