RE: push & pull (Was: Re: comments on draft-adrangi-radius-bandwidth-capability-00.txt)

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

Hi Jari,
Thanks for the discussion. Please see my response below.
BR,
Farid

> I have not formed my opinion yet. Let me explore this a little
> further: if we assume that due to other traffic load in the
> access point, the advertisements vary. For instance, an initial
> advertisement may have said that 50 Mbit/s is available, but
> after getting some other sessions, the access point can now
> offer just 5 Mbit/s for this session. This brings up two
> interesting questions:
> 
>    1. Is the home network's bandwidth decision based
>       on the advertisements?

Yes.

> This seems natural, but
>       are you sure its not a "provide this if you can"
>       scenario?

It could be.  "provide this if you can" is basically the push model.
But, it seems that we still need the pull model if want to interoperate
with Diameter - no?   

> The only case where I'd see the advertisement
>       affecting a real decision would be if the user's
>       decision to buy some additional bandwidth would be
>       affected as well. For instance, the web page where
>       he can buy more bandwidth shows the available
>       bandwidth based on the advertisement. Is this what
>       we want?
> 

No, that wasn't the intent.  I am not sure if this would be doable, from
the current protocol perspective.  That is, an access-accept should
follow the access-request (containing the advertisement) --  in this
case, it seems that you want to send access-request only to indicate the
current bandwidth capability status.


>       (Otherwise accounting will take care of the actually
>       provided service and its cost.)
> 
>    2. Are the Confirmed bandwidths binding? If they
>       are not, the available bandwidth may change
>       5 seconds after the reception of the COA, which
>       appears to make the advertisement pointless.
> 

They are. 

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