Subject: [NSIS] requirements issues relating to the QI (was: RE: Definition of QI (was: something else))

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 27 Feb 2002 16:52:39 -0000

Hi Alban, Roland, Rudiger, Vlora, Marcus, NSIS,

I'd like to provide an updated concept for the QI/QC definition to clear this fog. I've yet to see any specific argument that the terminology is not capable of describing the scenarios (in particular, I like Alban's use case analysis), but since the point of the terminology is to provide a consistent language for the scenarios, maybe we can pin it down a bit more.

Once this pinning is done, I'd like to raise some requirements questions (which is what we are actually supposed to be talking about).

The current definitions are:

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

I can't see any ambiguity in how flexibly the QI could be located. In the QC case, the definition leaves it open, and there is discussion is at the start of section 4.2. We could add to the definition:

"The QC could control just the QoS provisioning mechanisms at a single router, in which case it could be an entity located within that router; or it could be remote from that router; and in that remote case it could be controlling the QoS provisioning within a number of routers."

The second question is what entities talk to each other. It has been my assumption that the general model is
QI <--> QC <--> QC <--> QC <- ... -> QC
covering the complete path. Fig. 2 should imply this, although maybe we tried to show something too complex there and so left out the basic case. In any case, the QC can send QoS messages to the 'next hop' QC. So the simplest RSVP case would be to have just a QC at the interior and far end nodes. But this leads to...

***A real requirements/terminology question***
One reason to separate out the QI and QC cases for the requirements discussion was that we felt that a QI had all sorts of important upper layer interactions which were out of the scope of NSIS, in particular that it was the only place where application layer requests were interpreted, it was the entity that had to be authenticated (e.g. because it represented the entity that was going to be authorised and charged). On the other hand, a QC did not have these interactions, and the way it processed NSIS signals (and passed them to other QCs) was entirely defined as part of NSIS. 
In other words, the distinction between QI and QC is part of the definition of NSIS scope.

Question: is this distinction between QI and QC useful? Should the QC behaviour be fully defined by NSIS? (I think this question would start to become critical if people start looking at MIBs and so on.) Basically, we took the view that if there is complex behaviour, it is abstracted out of the QC into a separate application - a good example is where a node initiates an aggregate (cf. Rudi's email), in which case I would say that we don't want to define an NSIS-standard aggregation policy etc. and instead a local management application triggers a QI for the aggregate. It's also in section 5.5.1 of our framework draft - but note, that's a solution case built out of the terminology (if people want to make aggregation policy and so on part of NSIS, we would call this - in the requirements - a standard QoS controller).

There are several other requirements issues related to QIs. In particular:

*** A real requirements question ***
Given the above definition of a QI, can there be more than one QI for a single flow? In other words, can there be several places within a network where someone decides to request QoS based on upper layer considerations (including AAA aspects)? If there is more than one QI, do they need to talk to each other directly? (Our assumption: there is only a single QI for a given flow, which is a restriction, but the scenarios don't currently motivate anything more complex, so far as I can tell).

*** Another requirements question ***
Since we have requirements for both sender and receiver initiated QoS, the implication is that (for a unicast flow), someone has to decide to be the QI (this is different from RSVP, where there is no choice in the matter). At the moment, the requirements basically assume (I think in line with the scenarios) that this is decided by the application layer and the QI just 'gets called'. Again, this is a 'scope of NSIS' question - should NSIS actually include some sort of QI election capability? (Note that by having the term QI rather than just talking about 'hosts' we are able to pose this question quite concretely - at least I find it helpful, even if nobody else does...)

And, 
*** Yet another requirements question ***
Is there any scenario showing a need for any special application-related functionality at the 'far end' (this would be the QR of Roland's email). At the moment, we don't see what this would be - all the NSIS functionality seems to be covered by the QC definition, and at most there is some sort of upwards trigger into the application to say 'flow is setup' (this is also in our framework draft, section 4.1). But, is there a requirement to have some more complex behaviour here, and if so how much of this behaviour is in the scope of NSIS? (And if so, we can define a QR term to be a label for it.)

At the moment, I think there are 'obvious' answers to these questions, but since there is a concern about the capability of the terminology to express them, I thought I'd make them explicit. I'd also be interested in pointers to where other requirements drafts have considered these questions (or made it clear what assumptions were being made).

Yours,

Robert H.

> -----Original Message-----
> From: Vlora Rexhepi (ELN) [mailto:[email-masked]]
> Sent: 27 February 2002 10:55
> To: [email-masked]'; Roland Bless
> Cc: Vlora Rexhepi (ELN); NSIS Mailing List; Marcus Brunner
> Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
> 
> 
> Hi Alban, Roland, Rudiger and All,
> 
> I see that there are differences in interpretation of the model
> as soon as one starts thinking of scenarios other than centralized
> resource management, which is what I tried to bring up on the list. 
> And hope this shows my point that there is a problem with the [NSIS]
> WG draft model once one is thinking of applying it to typical 
> scenarios.
> Personally I think that in centralized resource management scenarios
> the [NSIS] WG draft model fits really well and I certainly am not
> against centralised resource management scenarios. I just believe 
> that it is not a feasible solution in particular scenarios such 
> as e.g. access networks with high transmission costs.
> Further, the real problem is that in the [NSIS] WG draft the 
> requirements are dependent on this model and its entities, i.e.
> QoS Initiator and QoS Controller. I believe this is not right. I 
> would rather prefer to define the requirements based on typical 
> scenarios and without relating them to a model nor to a resource
> management scheme.
> 
> I liked Danny's proposal:
> "
> - 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."
> 
> And I definitely agree with Georgios.
> 
> Regards,
> Vlora
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>