Subject: RE: [NSIS] WG requirements draft

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Tue, 26 Feb 2002 15:37:16 +0100

Hi Cornelia, Robert,

|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?
The "problem discussion model" is much more than this as 
the NSIS signalling requirements are depending heavily on 
these entities and it gets complicated when one is thinking 
of typical scenarios/use cases.

|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)
I will have to get back to you later on your framework draft, as I
haven't read it yet. 

|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.
I believe the mapping is going to be a painful process, especially
when trying to satisfy the QoS requirements.

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?

Regards,
Vlora

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

---

From: [email-masked]
Date: Tue, 26 Feb 2002 17:18:38 +0100

Hello Vlora, Marcus, and NSIS,

> node, e.g. interior node? Can the QI be part of the interior node?

Marcus said on the list : "In todays RSVP you exactly have one QoS
controller and initiator on each node".
I understand here that the QoS controller receives signaling, while QoS
initiator sends it. If this is true, I would say that the figure 1 of
the WG draft could modified in order to be inline. Instead of :

            |         |        ...............
            |         |        . QoS Control .
            V         |        . Information .
       +----------------+      ...............     +----------------+
   --->|                |------------------------->|                |->
       |                |      QoS signalling      |                |
       | QoS Initiator  |     (request/query,      | QoS Controller |
       |                |   response/error etc.)   |                |
   <---|                |<-------------------------|                |<-
       +----------------+                          +----------------+
        ^              |                            ^              |

I believe we could have:

            |         |        ...............
            |         |        . QoS Control .
            V         |        . Information .
       +----------------+      ...............     +----------------+
       |                |------------------------->|QoS        /    |->
       |                |      QoS signalling      |Controller/     |
       | QoS Initiator  |     (request/query,      |         /  QoS |
       |                |   response/error etc.)   |        /initi- |
       |                |<-------------------------|       /  -ator |<-
       +----------------+                          +----------------+
        ^              |                            ^              |

Vlora, I think that could answer your question (in case of an RSVP
network). 

To conclude, in order to make things clear, I would propose a small
update of the QoS initiator and controller definition, without changing
its meaning -at least the one I understood-.
I would propose to add at the beginning of the definition for QoS
controller and initiator: "role of an entity responsible for...". The
same entity (an RSVP node) could have both roles.

Best regards,

-- 
Alban Couturier
---------------------------------------------------------------------
Alcatel Research and Innovation
Ets de Marcoussis R&I/ULC
Route de Nozay                      mailto:[email-masked]
F-91461 Marcoussis CEDEX                       tel: +33 1 69 63 11 97
---------------------------------------------------------------------

---

From: Roland Bless <[email-masked]>
Date: Tue, 26 Feb 2002 23:49:50 +0100

Hi all,

I think we can solve this issue by not complicating the role model. 
It is also mentioned in section 4.1 of the nsis-req draft that QoS
Controllers interact with other QoS Controllers (as I understood). 
Therefore, there is signaling between different QCs. I don't think 
that we should complicate the model by explicitly defining every QC 
also as QI, although the QC initiates a further signaling transaction 
with another QC. I also don't think that the terms QC and QI are not 
generic enough to also cover a distributed approach. For a more 
complete model my suggestion (we add also a QoS Responder):

          Domain A             Domain B
        .......................      .......................
        .                     .      .                     .
QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
        .......................      .......................
     a)       b)                  c)                           a)

1.) The QI can be an end system or signaling proxy acting on
    behalf of an end system. 
2.) There can be several QoS Controllers involved in signaling. 
    Some of the QCs may be located within one administrative
    domain (allowing the distributed case where each router or each edge
    router or several BBs are involved within such a domain) whereas 
    others are located within different domains. 
3.) Finally, we should add the QoS Responder (QR) in order to have 
    a "symmetric" model where the corresponding end system can be also 
    involved in signaling (e.g., to let a mobile terminal decide about 
    the priority of requests due to scarce bandwidth). As with the QI 
    the QR could be also a signaling proxy. Alternatively, the QC can 
    act as proxy.

I think that this model covers all the different signaling cases:
a) end <-> edge/network
b) network internal, also covering edge to edge (intra-domain)
c) network <-> network (inter-domain)
and considering the whole signaling scenario by combining
the parts
d) end to end (QI <--> QR indirectly via a)b)c), not at application level)

Won't this fit most use cases?

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

---

From: [email-masked]
Date: Wed, 27 Feb 2002 11:22:37 +0100

Hi Roland and all

> complete model my suggestion (we add also a QoS Responder):

Roland, any model works fine, I don't think the current wg draft is not
generic enough. I remarked there is was a subtle misunderstanding about
QoS initiator and controller definition.(cf Can the QI be part of the
interior node?)

Some people think a QoS controller is a function, and that is your
opinion. You make a model based on that definition, and it is OK for me
(I would add QR should be optionnal because the last QC could decide not
to forward it. This depends of course of the precise definition of QR).
But with this formalism, you can't say that an RSVP node is a QoS
initiator and controler: it is only a QoS controller.

I proposed to say the QoS controller is a role, this allows to say an
RSVP router is a QoS controler, and initiator at the same time. (by the
way, this looks like the PDP and PEP definition in COPS, or the
agent/manager in SNMP. A server can be a PDP, while talking to a router,
and a PEP, while talking to another server.)

I invite the authors of the wg draft to fix this misunderstanding.
Anyway, this has a very little impact (if any) on the work done. 

> > the WG draft could modified in order to be inline. Instead of :

Best regards,
Alban

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Feb 2002 22:46:11 +0100

Hi Alban,

> to forward it. This depends of course of the precise definition of QR).

Yes, this makes perfectly sense, and was the itention of my last point
(QC can act as proxy, so that QR is not necessarily present as host). 
My point was that we should avoid things by explicitly mention all 
possible roles at the same time such as QC/QI.

> initiator and controler: it is only a QoS controller.

Why not? Within the RSVP aggregation scheme an RSVP aggregator will
act as an initiator.
 
> Anyway, this has a very little impact (if any) on the work done. 

Clarification would be nice. In my understanding a QI is the entity that
sends the first request message (e.g. setting the start- and endpoint of
the reservation), whereas a QC just does its local admission control
stuff and forwards this request to the next QC on the path (possibly
some QoS parameters need to be changed before). However, the next QC
should not consider the previous QC as original initiator of the
request. Sure, a QC initiates a new signaling transaction and requests 
a new service invocation, but on behalf of the original initiator. 

In my case this lead to an extrem simple signaling protocol 
specification between two adjacent entities (QI<->QC, QC<->QC
or QC<->QR). However, if one considers the complete signaling
transaction along the complete path from end to end (composed 
of the simple point-to-point signaling transactions), the overall
signaling scenario might get quite complex anyway.

Regards,
 Roland