RE: QoS attributes

["Bari, Farooq" <farooq.bari@attws.com>]

Hi Avi,

My opinion on this issue is that RADIUS or DIAMETER attributes on QoS
should reflect a more static type of QoS information that does not
change during an authorized session like
* the access network capabilities (e.g. does it support 11e or admission
control or if it can provide any, min/max bandwidth guarantees for
session, jitter, latency, delay, packet drop guarantees etc.) 
* user subscribed to QoS e.g. is the user bronze, silver, gold customer
and based on that what QoS should the user be provided.

The dynamic QoS for a particular service that the user decides to use
during an authorized session I believe is not something the RADIUS
should be used for. There are better mechanisms e.g. based on SDP
information in SIP or RTSP based services that should be utilized for
that purpose. 

BR,

Farooq
 

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 9:29 AM
To: 'radiusext@ops.ietf.org'
Subject: QoS attributes


I noticed that we are talking about QoS on the list.

In the current drafts folks are talking about QoS but are only
specifying Bandwidth attributes.  There are other QoS attributes. The
problem is that there are a lot of different QoS attributes and
different flavours as well. The question is which attributes and
flavours should be modelled.

I think we need a RADIUS QoS Draft in general.  I started to write one
and stopped to see what was going on in a couple of other areas. (For
example Diameter and as well, work in 3GPP2 where the interface between
the PDSN and the AAA will be used to query and transport QoS
attributes).

For example, one of the useful things about the CoA is that now I can
change the QoS attributes of a session mid stream.  So it would be
useful to define these attributes (and not just Bandwidth).

Any comments would be greatly appreciated.




> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: 'jari.arkko@piuha.net'; 'radiusext@ops.ietf.org'; Adrangi, Farid
> Subject: RE: Comments on 
> draft-adrangi-radius-extension-for-pwlan-00.txt
> 
> 
> 
> 
> > -----Original Message-----
> Jari wrote:
> 
>   o  I dislike the Sect 2.2 string syntax, as it is hard
>      to make this really work in a consistent manner across
>      vendors and organizations. A standardized bit pattern
>      approach would be better, IMHO. Then again, I'm not sure
>      whether we should really extend RADIUS with a feature
>      capabilities discovery.
> 
> Avi's reply:
> 
> A bit mask maybe a better approach.
> 
> Capability advertizing is important in certain situations
> such a prepaid. We need to be able to ensure that AAA server 
> can make policy decision based on the capabilities that are 
> supported by the NAS.  In prepaid we need to know whether the 
> NAS can actually do that 'counting' and enforce the policy 
> that is required.  If the NAS did not then the AAA can decide 
> on a different tack for providing service to a prepaid 
> client.  For example it can ask the NAS to tunnel the client 
> to another device that can enforce the policy.
> 
> We also need to know whether the NAS supports POD or COA
> (3576) messages. Again this is improtant for prepaid etc....
> 
> Whether or not this is standardized or not it is important
> for the prepaid feature and hence its also part of the prepaid draft.
> 
> --
> to unsubscribe send a message to
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>