Subject: [NSIS] Allow both signalled and centralised solution

From: Olov Schelen <[email-masked]>
Date: Tue, 26 Feb 2002 11:36:12 +0100

Hi all,

- an advantage with a logically centralised  QoS controller is that the
network operator gets necessary control of what is going on in their
network. In implementation, however, the QoS controller may be
distributed or clustered.
- all solutions, including in-path signalling, need policy control that
is outsourced to policy decision points (PDP). Kombining end-point
signalling (e.g., RSVP) with edge routers that correspond with QoS
controller (using NSIS protocol?) is one way of providing this. A
signalling solution that does not include policy control does not make
sense in most cases.
- another way of operation should be to skip endpoint signalling, and
thereby allow off-path service management units (e.g. SIP proxies, H.323
gatekeepers,  3G radio network controllers etc) or content service units
to reserve resources for their clients. There are also services that are
typically not end-point specific that may prefer this scenario (e.g.,
VPN, coproprate access contracts etc)

Given that both solutions above should be possible i would like to add:
- the signalling overhead is NOT becoming larger by allowing off-path
units to initialise QoS requests. On the contrary, you may save a lot of
signalling over wireless hops since  service gatways (e.g., SIP proxies
or H.323 gatekeepers) already have the necessery information from
ordinary session setup to also make QoS requests.
- with a QoS controller you get much better opportunities to localize
your QoS decisions so that the RTT delay at e.g., hand-over in wireless
access can be avoided. Yes, you get an RTT to the local QoS controller
instead, but this is usually shorter. Hand over-must involve
re-negotiation of radio-resources and then the information for IP QoS
control is already available in a box inside the fixed network and can
be fed to the QoS controller.
- the performance of a QoS controller is NOT a problem. We have an
implementation that shows excellent performance.

I would like to point to one of our technical presentation of a QoS
controller (see next mail). The focus is on concepts and use cases, but
for this discussion I apologize that the product name occurs as well.

/Olov

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

---

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

comments below

-Lasse

> implementation that shows excellent performance.

Bandwidth Broker is suitable solution for backbone networks, but if you have
high cost for
transmission, as in access network, Bandwidth Broker is not an efficient
solution. The simplest solution is to
make a new version of RSVP with better processing performance.

---

From: Olov Schelen <[email-masked]>
Date: Tue, 26 Feb 2002 13:27:24 +0100

Lasse,
I think the overhead of (periodic) signalling along the path would be at least
as large as signalling to a Q0S controller.  Also per-flow e2e signalling will
induce some delay at hand-over, which indicates that reserving aggregates may
give better hand-over performance.  In any solution there are trade-offs
between  signalling overhead, bandwidth allocation, and hand-over performance.
We should not start ruling out any solutions at this point.

With processing overhead in the in-path signalling approach, do you mean that
the per-node processing overhead or link bandwidth efficiency (or both) is a
potential problem with RSVP.? There must be very strong reasons to replace RSVP
and also the charter of this group suggests re-using existing protocols.
/Olov

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 26 Feb 2002 14:27:24 +0100

Olov,

> and also the charter of this group suggests re-using existing protocols.

I think the complexity of dealing with multicast is one of the potential 
problems of RSVPv1. Multicast leads to a lot of overhead in state merging
and partially the reciever-initiated solution. In many scenarios, however, 
multicast is not necessarily required. If we remove the multicast support 
for RSVP, much processing overhead may be reduced. It may look like the 
following:
 - There will be only one FF style for reservation, hence the sender address
   with a port number may be added in the session information; meanwhile 
   the SENDER_TEMPLATE, STYLE and SCOPE objects can be omitted. 
 - There will be no necessity for FLOWSPEC merging (or change) - and later, 
   complexity in the state maintenance - when a session is reserved (or torn 
   down). Path messages are reduced to transmit SENDER_TSPEC (and optional 
   ADSPEC to find the predicted e2e QoS) and Resv messages are still used to 
   reserve resources but no FLOWSPEC merging is required.
 - RSVP aggregation and other extensions will be simplified as a result.
   
We outlined such a possibility, namely RSVPvs in Section 7.2 of
http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00.txt

Regards,
Xiaoming

---

From: "Lars.Westberg" <[email-masked]>
Date: Tue, 26 Feb 2002 14:54:44 +0100

Periodic signalling will require some degree of overprovisioning in the transport..
A sutable solution for
backbone networks.

Regards Lasse