Subject: [AAA-WG]: Issue 271: comments needed

From: <[email-masked]>
Date: Wed, 27 Feb 2002 09:29:12 +0200

Hi all,

I'd appreciate some comments on this, whether to make the changes or not.

John

Assigned #271
Submitter: Jari Arkko <[email-masked]>
Date: January 3, 2002
Reference: 
Document: BASE-08
Comment type: T
Priority: S 
Section: 8.2
Rationale/Explanation of issue:

Sections 9.4 and 8.2 are in conflict.
The former requires clients to store acct
records during network outage, and the 
latter requires immediate sending.

The specification is also silent on
how the client devices know whether
it should grant access during times
of network outages towards the accounting
server. I can imagine that in some
cases we would like to stop services if
we can't provide real-time accounting,
while in some other cases we would like
to continue.

Furthermore, the state machine in 8.2
(as well as the one that I just posted)
does not specify what to do when things
happen to the session faster than what it
takes for an ack to come back from the server.
For instance, what should we do if the session
is terminated while we are still waiting for
the start ack?

Proposed change:

An AVP similar to the Accounting-Interim-Interval
could be used to control whether access should be
granted or discontinued upon problems in sending
the accounting records.

The state machine must be modified to consider what
to do with session termination and interim record
generation while we are still waiting to send previous
data.

9.8.x. Accounting-Realtime-Required AVP

   The Accounting-Realtime-Required AVP (AVP Code TBD) is of type
   Enumerated and is sent from the Diameter home authorization server to
   the Diameter client. The client uses information in this AVP to
   decide what to do if the sending of accounting records to the
   accounting server has been temporarily prevented due to,
   for instance, a network problem.

      DELIVER_AND_GRANT			1

         The AVP with Value field set to DELIVER_AND_GRANT means
         that the service MUST only be granted as long as there is
         a connection to an accounting server. Note that the set
         of alternative accounting servers are treated as one server
         in this sense. Having to move the accounting record stream to a
         backup server is not a reason to discontinue the service
         to the user.

      GRANT_AND_STORE			2

         The AVP with Value field set to GRANT_AND_STORE means that
         service SHOULD be granted if there is a connection, or as
         long as records can still be stored as described in section
         9.4.

         This is the default behaviour if the AVP isn't included
         in the reply from the authorization server.

      GRANT_AND_LOSE			3

         The AVP with Value field set to GRANT_AND_LOSE means
         that service SHOULD be granted even if the records can
         not be delivered or stored.

8.2. Accounting State Machine

Add the following new entries:

PendingE  Failure to send and buffer     Store      Idle
          space available                Event
                                         Record
                        
PendingE  Failure to send and no buffer             Idle
          space available    
                          
PendingS  Failure to send and buffer     Store      Open
          space available and realtime   Start
          not equal to DELIVER_AND_GRANT Record

PendingS  Failure to send and no buffer             Open
          space available and realtime   
          equal to GRANT_AND_LOSE       
                       
PendingS  Failure to send and no buffer  Disconnect Idle
          space available and realtime   user/dev
          not equal to GRANT_AND_LOSE                                             
                            
PendingI  Failure to send and (buffer     Store     Open
          space available or old record   Interim
          can be overwritten) and         Record
          realtime not equal to
          DELIVER_AND_GRANT  

PendingI  Failure to send and no buffer             Open
          space available and realtime   
          equal to GRANT_AND_LOSE       
                       
PendingI  Failure to send and no buffer  Disconnect Idle
          space available and realtime   user/dev
          not equal to GRANT_AND_LOSE  

PendingD  Failure to send and buffer     Store      Idle
          space available                Stop
                                         Record

PendingD  Failure to send and no buffer             Idle
          space available       

Idle      Records in storage             Send       PendingB
                                         record

PendingB  Successful accounting answer   Delete     Idle
          received                       record

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:18:38 +0200

Hi,

I think some change related to this issue is needed. 

As Jari has stated: 
"..in some cases we would like to stop services if we can't provide real-time accounting, while in some other cases we would like
to continue."

That was also in my mind when I suggested issue 272. There is cases where the accounting records could simply be stored by the client if the accounting server doesn't response even to intial ACR but in some cases the services must be stopped if ACA is not received. That was the reason I proposed new Accounting-Record-Type values 5-8. When these values (5-8) is sent in ACR, the service must be stopped if ACA is not received. 

Any other comments??

br,
JPK 

-----Original Message-----
From: Loughney John (NRC/Helsinki) 
Sent: 27. February 2002 9:29
To: [email-masked]
Subject: [AAA-WG]: Issue 271: comments needed

Hi all,

John

Assigned #271

Proposed change:

      DELIVER_AND_GRANT			1

      GRANT_AND_STORE			2

      GRANT_AND_LOSE			3

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:34:10 +0200

Hi Juha,

> As Jari has stated: 
> "..in some cases we would like to stop services if we can't 
> provide real-time accounting, while in some other cases we would like
> to continue."
> 
> That was also in my mind when I suggested issue 272. There is 
> cases where the accounting records could simply be stored by 
> the client if the accounting server doesn't response even to 
> intial ACR but in some cases the services must be stopped if 
> ACA is not received. That was the reason I proposed new 
> Accounting-Record-Type values 5-8. When these values (5-8) is 
> sent in ACR, the service must be stopped if ACA is not received. 

Do you think that Jari's comments are enough for both issues (271 & 272)?
Or do you have other text?

John