RE: QoS attributes

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

Hi Avi,

Most of the QoS sensitive services / applications have their own control
plane and corresponding protocols e.g. SIP, RTSP etc are used for
multimeida sessions and streaming. The QoS / bandwidth requirements etc.
are exchanged through them as part of session setup / modification and
in my opinion it is this control plane that should then be responsible
for informing the QoS enforcement point of the need for a specific QoS /
bandwidth for a specific service session. In many cases the enforcement
point may not actually be informed about it directly and the services
can for example do diffserv / bit coloring. The enforcement point will
however have to ensure that the request from a particular user for QoS
for certain service session does not fall outside the access network
capability or the user's QoS profile provided by the home network.

In the example that you gave, I would be quite surprised if operators
have such tight admission control whereby they can guarantee certain
minimum bandwidth for the last mile on a per user basis. I however think
average bandwidth to certain user can be achieved if the user was
classified for example as gold user who can if needed prioritize its
traffic by bit coloring  and therefore can have higher allowed average
bandwidth. That I believe can be done by just downloading user QoS
profile initially (that for example allows bit coloring from this user
to be honored in the access network) and later allowing applications to
use DSCP (no control protocol needed in this case).

Therefore I still think RADIUS QoS / bandwidth attribute is somewhat
static information to be used to define the overall bounds for a user -
the QoS individual for services has to be within these bounds but RADIUS
is not in the path of negotiating QoS for the services.


Regards

Farooq

-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Wednesday, December 17, 2003 8:36 AM
To: 'Bari, Farooq'; Avi Lior; 'Nelson, David'; 'radiusext@ops.ietf.org'
Subject: RE: QoS attributes


Hi Farooq,

I will give you a real usecase in DSL/Cable systems that we are involved
with.

A user wants to download a movie from a content provider.  The Operator
offers a service whereby the user can extend his bandwidth for a period
of time for a fee.  This is called bandwidth on demand or BOD.  This is
done using two mechanisms: either by pressing a "turbo" button or by
going to a website.  In either case, the system validates that the
subscriber is allowed to request for more bandwidth, if so it then
checks to see what is available (not in scope for RADIUS but there are
ways to do this), and grants the user the bandwidth by sending the
network element a RADIUS CoA message (RFC 3576) instructing the device
to open up the user's pipe.  All of this is done mid-session.

This was an example where the user has initiated the request.  A similar
scenario can happen when the Content Provider can request that the
user's pipe be opened for a period of time.

Finally, there are examples that we are exploring now where a new IP
flow is requested mid session and the QoS has to be negotiated.  RADIUS
is involved because RADIUS know who the subscriber is and what the
subscriber is allowed.  Other elements are involved such as a Policy
Decision Function
(PDF) as well.  Still trying to figure out the details for this one.

But I hope that this gave you an insight that shows that these things
need to be addressed mid session as well as at the start of the session.

> -----Original Message-----
> From: Bari, Farooq [mailto:farooq.bari@attws.com]
> Sent: December 16, 2003 5:05 PM
> To: Avi Lior; Nelson, David; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
> 
> 
> Hi Avi, all
> 
> We need to have some consensus on what is the rationale/use
> of QoS attributes for RADIUS/DIAMETER before moving forward 
> on the topic. It seems that we have more than one perspective 
> on it. I for example see it as static information during an 
> authorized session i.e. QoS information gets exchanged only 
> during session setup where AN informs AAA of its capabilities 
> and AAA server tells the AN of user QoS susbcription. I do 
> not think RADIUS/DIAMETER servers should be involved in 
> provisioning QoS for individual services running in an 
> already authorized session later on.  However Avi's email 
> suggests it is somewhat more dynamic than this. Avi, can you 
> pls clarify if I understood your comments correctly.....
> 
> 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 1:42 PM
> To: 'Nelson, David'; radiusext@ops.ietf.org
> Subject: RE: QoS attributes
> 
> 
> 
> David Nelso wrote:
> 
> > Provisioning detailed, and more importantly, potentially
> dynamic, QoS
> > parameters as authorization information in RADIUS or any other AAA
> > protocol is probably not the right thing to do.  What ought to be 
> > provisioned is a "level of service" indication (e.g. 
> bronze, silver,
> > gold, platinum) that can be used by each NAS to modify the QoS
> > parameter negotiation process for each session.
> 
> It requires that each Hot Spot for example understand what to
> deliver to a Bronze User or a Gold user etc.....
> 
> Like filter id, this just does not scale!
> 
> We need a way to explicitly push attributes down to the NAS.
> Equally important is to make sure that the NAS tell us what 
> it can currently honour. This will alow the home RADIUS to 
> make an appropriate policy decision.
> 
> 
> 
> --
> 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/>