RE: minneapolis

[Avi Lior <avi@bridgewatersystems.com>]

Assuming you use the Session-Timeout and Accounting Stops and Interims.
Then the simplest example that demonstrates revenue leakage is:

Subscriber's account starts with X.
Subscriber logs in and gets Session-Timeout <- X.  X is reserved.
Interim messages are sent with reporting usage Y1,Y2 etc..
These are subtracted from X as the session continues.

Then the user logs off and the client would have sent n Interim records and
a Stop record. If the user  re-connects immediately it is possible that only
k of the Interim records and the Stop record has not yet been received.  

Therefore, since we favour the customer (we need to let him in).  We will
set the Serssion-Timeout to X - k*Y.  Thus there would be a possibility of a
revenue leakage of the time reported in(n-k)+Stop.  Typically interim period
would be set to 5 minutes so its likely that we would leak 5 minutes.  Not
that this leakage would only be realized if the subscriber utilized all of
the time alloted in the second session.  This is because eventhough the stop
record arrives late, we will debit the subscriber account. 


The case where there are multiple service instances is prone to leakage (as
above) but presents other issues.  When you have multiple services going
against a single account we usually do this by allocating a portion of the
account to each service instance (we call that a quota).  There is no
mechanism in general RADIUS (prior to CHIBA) to replenish the quota.

You can assign Session-Timeout a portion of X but then the NAS would boot
the user off.  Terminate-Action is not usable since it is sent after the NAS
kicks the user off.

If the Value is set to RADIUS-Request, upon termination of the
      specified service the NAS MAY send a new Access-Request to the
      RADIUS server, including the State attribute if any." 


In WLAN its different.  Farid and I are discussing this issue right now.  As
Farid points out:

From RFC 3580:
"   When sent in an Access-Accept along with a Termination-Action value
   of RADIUS-Request, the Session-Timeout attribute specifies the
   maximum number of seconds of service provided prior to re-
   authentication.  In this case, the Session-Timeout attribute is used
   to load the reAuthPeriod constant within the Reauthentication Timer
   state machine of 802.1X."

In other words, it appears that in WLAN there is a reauthentication
mechanism that we can use to get another quota.

If what is meant by simple prepaid solution is a solution that works with
existing deployements then this is not a simple prepaid solution that works
without changes.  It requires compliancy to 3580.  The prepaid solution we
are writing requires compliancy to TBD.


Hope this clears things up.


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, September 11, 2003 12:03 PM
> To: Avi Lior
> Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list'
> Subject: RE: minneapolis
> 
> 
> > It is possible to do pre-paid w/o new attributes but there 
> is no way 
> > to do it without revenue leakage.  It maybe possible to 
> minimize the 
> > leakage in certain circumstances (for example WLAN).
> 
> Can you explain this further? If the user has a credit of X 
> minutes, then returning a RADIUS Access-Accept with 
> Session-Timeout of X minutes should not result in revenue 
> leakage.  Or are we assuming that the user could be doing 
> other things at the same time (e.g. multiple simultaneous
> connections) so that their credit could expire before then?
> 

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