Re: more on bandwidth

[stefaan.de_cnodder@alcatel.be]

Jari, Farid,

My preference would be option 1 (single bandwidth and single burst
size). The NAS tries to provide this bandwidth to the user, but no
more (hence it is min and max at the same time). Later, if there is
a real need for more, an extra bandwidth attribute could be defined
containing the max. However, going for option 3 below immediately
would also be fine for me.

Another concern was that all the attributes *must* be there.
Currently all 4, but I believe that if we would like to have a
solution that can be extended in the future (i.e. adding more
attributes later when there is a real need for it), all attributes
should be optional and only make the presence of attributes a must
when really needed. For instance, it makes no sense to specify a
burst size without bandwidth so if burst size is present also the
bandwidth must be present. This does not apply for 2 bandwidth
parameters: the presence of a min bw does not need a max bw.
Therefore, I also see the encoding of a "dont care" as the attribute
not being present in message.

regards,

Stefaan


Jari Arkko wrote:
> 
> Hi Farid and Stefaan,
> 
> >>1) two bandwidth parameters are defined: min and max. However, when
> >>I look to RFC2697, a traffic conditioner with parameters 2 bandwidth
> >>values and burst size. RFC2698 describes an mechanism with 2
> >>bandwidth parameters and two burst sizes. The MEF (metro ethernet
> >>forum) has further extended these mechanisms. Most NAS
> >>implementations, as far as I know, use a more simpler mechanism: a
> >>single bandwidth with a burst size. So my question: why are there no
> >>burst sizes included in the document? Maybe a burst size does not
> >>mean a lot for the end user but the algorithms used in some NASes do
> >>have to know the burst size.
> >>
> >
> > No specific reasons.  Our initial goal was to support WFA bandwidth
> > profile requirements.  I think burst size would be a useful parameter to
> > add, as the access network needs to support both bursty TCP-based data
> > application as well as constant rate UDP-based applications like VoIP.
> 
> I guess the alternatives are 1) bandwidth + burst, 2) two bandwidths,
> and 3) two bandwidths + burst. Based on earlier discussion on this
> list, I think we want to avoid making the AAA become a fully fledged
> qos mechanism, so I think that implies as simple set of attributes
> as possible. Based on Stefaans comments above I am convinced that
> burst needs to be there. But is the chosen alternative 1 or 3?
> 
> >>2) Similar as Jari's comment: 12 attributes looks too much. Why is
> >>just Kbps not enough? With a 32 bit value field, very high
> >>bandwidths are possible with a fine granularity.
> >>
> >
> >
> > Agreed with Jari's comment.  Will fix it.
> 
> Here we have an alternative also. I was thinking of having
> an octets/s and megawords/s attributes, to match with the
> corresponding accounting attributes. However, perhaps Stefaan
> has pointed to an even simpler approach above. In accounting,
> the sums are cumulative over a longer period, so we need a lot
> of bits. On a bandwidth indicator, maybe just one AVP is
> enough. If its octets/s and 32 bits, that would give you a
> maximum of 32 gigabits/second.
> 
> --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/>

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