[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS attributes
Avi,
I agree with you on there being more than one type of QoS attribute. In
particular, robust support of VoIP, which seems to be taking off in the
market place, demands a way to prioritize and perhaps even reserve
bandwidth. VoIP is very sensitive to dropouts and jitter. The current
state of the art is rather variable voice quality depending on network
load, etc. (There was an interesting discussion of VoIP on PBS Talk of
the Nation recently.) So far this lack of a consistent level of service
is acceptable because VoIP is dirt cheap.
Fixing this is much more than a RADIUS issue, since consistent
technology to prioritize and reserve bandwidth is needed end to end. The
whole things falls apart if even one intermediate device does not
support QoS.
Most of this is out of scope for this discussion, but we could discuss
the RADIUS piece that determines whether a user is *allowed* to use this
hypothetical service.
My $.02,
Ed
Ed Van Horne
Building Broadband Solutions Unit - San Diego
Cisco Systems
10935 Vista Sorrento Parkway
San Diego, CA 92130
858.526.1152
-----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/>