RE: QoS attributes

[Avi Lior <avi@bridgewatersystems.com>]

> I think that at least the first approach makes sense. You
> Avi have looked into it more deeply, what do you think?
> Can we find a reasonable QoS attribute set without spending
> too much time?

As you say, there are so many and that's why I stopped (for a bit anyway).
Until I get a better lay of the land.  I noticed the Pat had a Diameter
Draft on QoS way back in 98 ( I think).

The easy ones are the bandwidth parameters and once we can agree what
"minimum" means and what "maximum" means we are pretty well off to the races
for services today.

The other ones that we would need are a way to associate a session with a
QoS bundle either by assigning a QoS bundle id which then translates to a
QoS parameters or specifically assigning a QoS bundle.  This is akeen to the
IP filter rules and IP filter rule ids.  A QoS bundle would contain a bunch
of QoS related attributes.  The QoS bundle Id can also be used for billing.

Because there are so many different attributes I was hoping that we come up
with a mechanism that could then be extended.

Not doing something about this will create a situation that I am starting to
see where folks are just going to be creating VSAs and we will never have
interoperability.


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Tuesday, December 16, 2003 4:09 PM
> To: Avi Lior
> Cc: 'radiusext@ops.ietf.org'
> Subject: Re: QoS attributes
> 
> 
> Avi Lior wrote:
> 
> > 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.
> 
> I agree that there are other QoS attributes. In fact, there
> are so many and so different that this may be a problem.
> 
> Define just a limited set of bandwidth qos attributes and
> be satisfied with limited capabilities this offers? Or
> define link layer specific detailed qos attributes, and
> deal with the lack of server-side understanding of new
> link layers and the diversity of the parameters for different 
> links? Or try to come up with a general definition that suits 
> everyone, and probably take a long time to finish? ;-)
> 
> I think that at least the first approach makes sense. You
> Avi have looked into it more deeply, what do you think?
> Can we find a reasonable QoS attribute set without spending
> too much time?
> 
> --Jari
> 

--
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/>