RE: more on bandwidth

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hello Stefaan,
Thanks so much for reviewing the draft and providing comments.  Please
see my responses inline.
BR,
Farid

> 
> Hi,
> 
> I have some questions/comments on
> draft-adrangi-radius-bandwidth-capability:
> 
> 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.

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

> 3) Is an access-accept with for instance an ingress bandwidth in
> bits per second and an ingress bandwidth in kilo bits per second
> also valid? I guess only 1 of them may occur or should the values be
> added to have the final bandwidth?

One instance of each bandwidth parameter may occur.  Unless you think it
is useful to have two instances of a bandwidth parameter within
access-accept?

> 
> 4) Since for some NASes, only 1 bandwidth parameter can be
> specified, would it also be useful to specify "don't care" for the
> second bandwidth? In the draft, the 4 bandwidth values must be
> specified to be valid (section 2.2). Should this not be more
> relaxed? 

That's a good point.  We can use a value of zero to indicate "don't
care".  What do you think?

> By the way, I am a little bit confused by the notation
> "0-4" in section 5: does it mean: 0 or 4, or does it mean: 0, 1, 2,
> 3, or 4? section 2.2 seems to imply 0 or 4?
> 

It means 0 or 4.  Good point - will make it clear in section 5.

> 5) typo third line section 2.2.2.1: the HSN (instead of the AN) MAY
> also include other attributes in the COA message.
> 

Yes, good catch!

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