Subject: [NSIS] Comments on draft-buchli-nsis-req-00

From: "Hepworth, Eleanor" <[email-masked]>
Date: Fri, 1 Mar 2002 09:45:44 -0000

Hi Danny, Sven

Couple of comments on draft-buchli-nsis-req-00.txt. I'm glad you seem to have found the QI/QC concepts useful;)

Firstly, some more general comments.  I think the discussions in this draft are valuable, and raise some interesting questions related to the scope of the NSIS WG. It is important to clarify the scope of NSIS as regards what functionality is part of the NSIS problem space.

In your draft, you have identified a number of protocol interactions that it may be worth generalising a bit to cover a few other situations where I think the issues you raise in the draft are still true.

Host<->QI.
As I understand it, this protocol interface triggers the generation of an NSIS signalling message at the QI.  I think this is analogous to having the QI present on the host and receiving triggers from the application.  Certainly the same issues apply:  what information is provided to the QI, and how is this used to generate the NSIS message.  I agree that we need to study the information passed across this interface but think, as you do, that otherwise it is out of scope of NSIS.  

QC<->NMS and QI<->AG
I would regard both the protocol interfaces as part of the interaction with the local QoS provisioning mechanism.  The first, because how the pipes are actually setup, or indeed if they are used is part of the provisioning mechanism used within the domain, and the second because policing methods etc. tend to be dependent on the QoS provisioning method anyway.  Issues concerning this interaction with the QoS provisioning function include: who maintains the resource usage information and carries out admission control (i.e. does the QC manage all this information, or does it interrogate the QoS provisioning mechanism for this information), how is monitoring information passed to the QC etc. (A lot of these issues are discussed in section 4.2 of draft-hancock-nsis-framework-00, we'd be interested to know if you agree with our assumptions about scope).

You also identify some stages required in resource allocation, reservation setup, which I think have similarities to those identified in draft-hancock-.., e.g. the exchange of SLS information and the creation of the traffic pipes could take place as part of the 'Peer Agent Discovery' process.  Do you think this division of the signalling into stages is a requirement on the protocol structure, or just useful for discussing it?

Secondly, a couple of more specific comments regarding some of your requirements.

6.1 Signalling requirements

2) The time to set up a QoS connection should be constrained to one or a few round trip times.
Would this requirement be better as a part of a set of evaluation criteria for analysing protocol options?  While it is a desirable feature of the NSIS solution, can we really require a hard limit as part of the protocol.

3) Support of priority
What do you envisage the scope of this information being?  How do we determine the priority for a flow, is it per-user or something to do with inter-domain relationships?  If it is per-user, is it relevant end-to-end or only locally?  Are there any interactions with AAA functions to do with authorisation information?

6) The protocol should be independent of the core transport technology as opposed to the access part where the transport and QoS are technology specific.
I agree with this first part (that the protocol should be independent of the transport technology), but I'm not sure the second bit should be part of the requirement.  We're not using NSIS signalling between the host and the QI so the second part of the requirement is not on the NSIS protocol. This goes back to the discussion mentioned above as to whether you consider the QI to be in the host or not.

8) Multicast consideration should not impact the protocol complexity for unicast flows.
I don't think NSIS has yet reached a consensus on support for multicast, so I would be interested to know how important you think this requirement is. We considered it a design goal to 'do unicast first and think about multicast later'.

9) Effective support of unidirectional reservations
You've included comments on support for bidirectional reservations. I agree with your concerns, and I think this requirement might need to be phrased in a more restrictive way.  In our framework draft, the options for supporting bidirectional reservations are discussed and it seems in general that we need to decompose this requirement further, i.e. are we discussing bidirectional signalling or bidirectional data paths (if we can make this distinction), and especially are we discussing end-to-end bidirectional reservations, or allowing them on a more per Qx/Qx link basis as a local optimisation?

10) Mobility aspects should have no impact on the NSIS protocol.
This might be quite hard to achieve, and there are also situations where the signalling could be optimised for mobility, see draft-chaskar-mobileip-qos-01 for example.

11) Optimization for interactive multimedia services.
What does optimised mean in practice?  It is clearly important to consider this when thinking about requirements, but do we want to consider only one type of service?

The draft also contains some valuable analyses on the service levels and information/parameters and some associated requirements (especially section 6.2).  How much detail do you think we need to go into  concerning QoS parameters for the requirements stage?

Yours,

Ele Hepworth

---

From: [email-masked]
Date: Fri, 1 Mar 2002 16:02:41 +0100

Hi Eleanor,

Thanks for your feedback on our draft. We are going through the same
process regarding draft-hancock-... and expect to comment next week. In the
mean time, please see additional comments/clarifications inline (Sven>>)

Yours,
Sven.

"Hepworth, Eleanor" <[email-masked]> on 01/03/2002 10:45:44

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Danny   
               GODERIS/BE/ALCATEL@ALCATEL                     
                                                              
  cc:          "[email-masked]'" <[email-masked]>              

  Subject      Comments on draft-buchli-nsis-req-00           
  :                                                           

Hi Danny, Sven

Couple of comments on draft-buchli-nsis-req-00.txt. I'm glad you seem to
have found the QI/QC concepts useful;)

Firstly, some more general comments.  I think the discussions in this draft
are valuable, and raise some interesting questions related to the scope of
the NSIS WG. It is important to clarify the scope of NSIS as regards what
functionality is part of the NSIS problem space.

In your draft, you have identified a number of protocol interactions that
it may be worth generalising a bit to cover a few other situations where I
think the issues you raise in the draft are still true.

Host<->QI.
As I understand it, this protocol interface triggers the generation of an
NSIS signalling message at the QI.  I think this is analogous to having the
QI present on the host and receiving triggers from the application.
Certainly the same issues apply:  what information is provided to the QI,
and how is this used to generate the NSIS message.  I agree that we need to
study the information passed across this interface but think, as you do,
that otherwise it is out of scope of NSIS.

Sven>> We agree with your view that host-QI may not be the primary scope of
NSIS. However, the placement of the QI-QC on the physical infrastructure
may have an impact on the grouping of requirements. We were thinking about
grouping requirements as QI-QC, host-QI (if in scope, ...). This only makes
sense if the placement of the QI-QC is such that we can assume that the
requirements are similar in all cases. When the QI can be at the host or in
the access, this may not be the case. The main problem seems to be that the
placement of the QC is very loose. An idea could be to have QI proxies that
relay the QI info to the QC. Then, the placement of the QC could be more
aligned with the physical infrastructure and the requirements on the
(proxy)QI-QC interface could be relaxed (like no need to support mobility).

QC<->NMS and QI<->AG
I would regard both the protocol interfaces as part of the interaction with
the local QoS provisioning mechanism.  The first, because how the pipes are
actually setup, or indeed if they are used is part of the provisioning
mechanism used within the domain, and the second because policing methods
etc. tend to be dependent on the QoS provisioning method anyway.  Issues
concerning this interaction with the QoS provisioning function include: who
maintains the resource usage information and carries out admission control
(i.e. does the QC manage all this information, or does it interrogate the
QoS provisioning mechanism for this information), how is monitoring
information passed to the QC etc. (A lot of these issues are discussed in
section 4.2 of draft-hancock-nsis-framework-00, we'd be interested to know
if you agree with our assumptions about scope).

Sven>> We agree with several statements made in the section you refer to.
For instance, we believe that 'a generic interface is required to exchange
parameters for various purposes between NSIS agents and QoS provisioning
systems'. We think a resource allocation protocol might indeed be useful
for dynamic negotiation over the QC-provisioning interface. However, since
the QoS provisioning method is a local matter, we thought this protocol, if
it is used, would also be local.

You also identify some stages required in resource allocation, reservation
setup, which I think have similarities to those identified in
draft-hancock-.., e.g. the exchange of SLS information and the creation of
the traffic pipes could take place as part of the 'Peer Agent Discovery'
process.  Do you think this division of the signalling into stages is a
requirement on the protocol structure, or just useful for discussing it?

Sven>> I agree with you that SLS information for the provisioning interface
could be exchanged during neighbour discovery. I think that the discovery
and the signalling process are separate issues though. We think it is
feasible to have preprovisioned resources controlled by each QC that can
handle signalling without having to interact with provisioning.

Secondly, a couple of more specific comments regarding some of your
requirements.

2) The time to set up a QoS connection should be constrained to one or a
few round trip times.
Would this requirement be better as a part of a set of evaluation criteria
for analysing protocol options?  While it is a desirable feature of the
NSIS solution, can we really require a hard limit as part of the protocol.

Sven>> Agree. It should be part of the criteria to evaluate different
otherwise requirements-compliant options.

3) Support of priority
What do you envisage the scope of this information being?  How do we
determine the priority for a flow, is it per-user or something to do with
inter-domain relationships?  If it is per-user, is it relevant end-to-end
or only locally?  Are there any interactions with AAA functions to do with
authorisation information?

Sven>> The application we had in mind were emergency calls. They have the
same QoS requirements but clearly have a much higher priority than ordinary
calls. This suggests that priority and QoS are orthogonal issues (which I
believe was also the conclusion that was reached in the context of
DiffServ-TE). It would also seem to suggest that priority has end-to-end
meaning, because you wouldn't want the next network to block the call.
Whether this should be done per-class or per-flow might be open for
discussion.

6) The protocol should be independent of the core transport technology as
opposed to the access part where the transport and QoS are technology
specific.
I agree with this first part (that the protocol should be independent of
the transport technology), but I'm not sure the second bit should be part
of the requirement.  We're not using NSIS signalling between the host and
the QI so the second part of the requirement is not on the NSIS protocol.
This goes back to the discussion mentioned above as to whether you consider
the QI to be in the host or not.

Sven>> This again relates to the access-core discussion. It all depends
where you want to be able to put the QCs and QIs.

8) Multicast consideration should not impact the protocol complexity for
unicast flows.
I don't think NSIS has yet reached a consensus on support for multicast, so
I would be interested to know how important you think this requirement is.
We considered it a design goal to 'do unicast first and think about
multicast later'.

Sven>> We fully agree. I think our statement ('should not impact',
'adversely impact' maybe?) matches yours ('do unicast first').

9) Effective support of unidirectional reservations
You've included comments on support for bidirectional reservations. I agree
with your concerns, and I think this requirement might need to be phrased
in a more restrictive way.  In our framework draft, the options for
supporting bidirectional reservations are discussed and it seems in general
that we need to decompose this requirement further, i.e. are we discussing
bidirectional signalling or bidirectional data paths (if we can make this
distinction), and especially are we discussing end-to-end bidirectional
reservations, or allowing them on a more per Qx/Qx link basis as a local
optimisation?

Sven>> Unless I am wrong, this is the way it is done in UMTS. This could
obviously be allowed. The only problem I see is that if you proxy the
bidirectional reservation to the QC, than this one needs to recognise both
uni- and bi-directional reservations. If we do not make it an explicit
requirement we might be able to keep this complexity out. Another way to
support bidirectional support could be through higher layers (application
layer).

10) Mobility aspects should have no impact on the NSIS protocol.
This might be quite hard to achieve, and there are also situations where
the signalling could be optimised for mobility, see
draft-chaskar-mobileip-qos-01 for example.

Sven>> Again relation to the QI-QC placement. This should probably be the
first thing to clarify a bit further.

11) Optimization for interactive multimedia services.
What does optimised mean in practice?  It is clearly important to consider
this when thinking about requirements, but do we want to consider only one
type of service?

Sven>> This more or less relates to the comment made for 9). Interactive
multimedia services might use the application layer (e.g. for support of
bidirectionality). This could be taken into account by the NSIS protocol.

The draft also contains some valuable analyses on the service levels and
information/parameters and some associated requirements (especially section
6.2).  How much detail do you think we need to go into  concerning QoS
parameters for the requirements stage?

Sven>> We think it might not be unimportant. Although the parameter content
might not be a direct requirement of the signalling protocol, the amount
and update frequency of it might very well impact/limit the available
options. We think the protocol should be very simple. That's why we think
it is important to identify the minimum content that the protocol should
carry. This will set an upper bound on the signaling complexity. Later on,
we can see what additional 'nice to have' stuff can be added.

Yours,

Ele Hepworth

(See attached file: RMRL-Disclaimer.txt)