Subject: nasreq Re: Simultaneous Usage Limitation: Same as "On Demand Accounting"?

From: [email-masked] (Patrice Calhoun)
Date: Thu, 18 Nov 1999 16:56:04 -0800

>>> I'd be interested if someone can make a convincing argument
>>> for a simpler way to obtain this capability. 
>
>>My assumption is that maintaining session state information should not
>>be considered as part of the accounting protocol, but part of the 
>>authorization protocol (assuming they are different).
>
>Can we come to closure on what "on-demand accounting" capability
>really means and what is required of the AAA protocol in 
>order to implement it? 
>
>The first step is to describe the scenarios in which on-demand
>accounting is required. My understanding is that this was
>intended to provide services such as simultaneous usage limitation
>which is *very* popular among ISPs. Is "on-demand accounting"
>synonymous with simultaneous usage limitation, or not? 
>
>There are many reasons why the simultaneous usage count can
>be inaccurate. As in accounting, this can be due to packet 
>loss, network partition, device reboot, or server failure. 
>Thus the notion of "reliable" simultaneous usage count goes
>beyond transport. So if we care about simultaneous usage
>limitation this results in a number of requirements. 
>
>The packet loss issue can be adressed via providing transport
>reliability in the "Accounting-STOP" packet. Soft-state in
>the authorization process will also help, as Pat describes.
>If the "Accounting-STOP" cannot be delivered within the
>re-synchronization interval then the sesssion state will 
>be aged out. 
>
>For the box reboot case, you need some kind of "restart"
>indication, transported reliably. When the server receives
>this indication, it will clear all sessions on that box. 

So, let's assume that a client reboots. Who should it notify?
Of course, its first hop server(s), and should they, in turn,
notify all peers? What about those peers, should *they* notify
all of their peers? etc. etc. Then we have to start dealing 
with AAA path loops, etc. 

This can get ugly real fast :(

>
>In the network partition case the clients could
>still be connected but there is no way for the server to
>know this. As soon as the partition ends, you'd want the
>server to become aware of the state of the client. 
>
>Here I think the thing to do is for the server to maintain
>its state until notified of a change by the client. This
>could be a reboot indication, in which case the state is
>cleared. However it also could be Accounting-STOP messages
>delayed by the partition. The maximum time to re-sync after
>the partition ends will be equal to the maximum backed off
>retransmission time. For example, if the retransmission
>algorithm specifies exponential backoff up to a 60 second
>interval, then the maximum re-sync time will be 60 seconds.
>
>The last case is server reboot. In this case, we should assume
>that the server has committed session state to stable storage,
>so that the issue is again how long it takes for the delayed
>Accounting-STOP messages to propagate to it. 

So, if we are considering server state, who keeps the state?
Should the home servers only maintain state for their own
user's, or for users connected to their networks as well?
What about a proxy server, what does it need to keep track of?

See the issue.... complexity :(

PatC
>Note that solving the issues above *does not* appear to require
>an explicit re-sync capability. Neither does it appear to require
>some kind of "aliveness" indicator -- such as defining a "heartbeat"
>message that will be sent from client to server during a minimum
>time interval if no other message is flowing. While absence of
>such "heartbeat" messages can indicative of loss of synchronization, 
>it is not useful in recovering state.