[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more on bandwidth
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/>