Subject: RE: [NSIS] Two kinds of requirements

From: [email-masked]
Date: Wed, 16 Jan 2002 11:59:38 -0000

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, [email-masked] wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2002 08:31:21 -0800 (PST)

So, I'm really dumb here. Can somebody enumerate
the *specific* things that are broken with RSVP?
Before we run off designing new protocols, it
would be nice to know a) what things the current
protocols have problems with and b) whether the
current protocols are fatally flawed in the face
of those problems.

I know some in (a). I don't think they meet (b).

	Mike