Subject: RE: [AAA-WG]: CCA: Separation of sent and received bytes in CCA

From: <[email-masked]>
Date: Mon, 6 Oct 2003 11:09:15 +0300

> I don't immediately see how this would make it simpler. We 
> have now a quite general way of requesting, granting and 
> reporting different unit types using a grouped structure, e.g.
>               <Granted-Service-Unit>::=< AVP Header: TBD > 
>                                            { Unit-Type } 
>                                            { Unit-Value } 
>                                            [ Currency-Code ]
>                                            [ Volume-Direction ]

I don't think there is need to grant volume units per direction, I think it
would be quite complex (rather mission impossible) for a server to estimate 
how much a user can receive and how much a user can send.  It is much
simpler to always grant the total amount of data volume a user is allowed
to consume. If e.g. only the downlink cost, then the server would just
deduct the downlink traffic from the user's account. So, I would keep
the GSU AVP as it is in the current draft. Same apply for the
Requested-service-Unit AVP. But it is important to get the details in the report.

One other possible alternative in the report is that, when volume based credit control 
is applied, we always report all the NAS' available information. 
In the Used-Service-Unit AVP we would always include total, Sent-Bytes and Received-Bytes,
and we could use the NASREQ defined accounting AVP. For instance

<Used-Service-Unit>::=< AVP Header: TBD >  
                                       { Unit-Type }  
                                       { Unit-Value } --> this is the total 
                                       [ Currency-Code ]
                                       [ Accounting-Input-Octets ]
                                       [ Accounting-Output-Octets ]

Or we could define two new AVPs (CC-Input-Octets and CC-Output-Octets) if the use of 
the two mentioned NASREQ AVP is not seen appropriate.
We would need to change the definition of unit-type Volume from bytes to Octets.

What do you think?

Marco

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Oct 2003 14:20:09 +0300

> simpler to always grant the total amount of data volume a user is allowed

Hmm... wouldn't the same estimation problems apply to all of the above
cases?

> We would need to change the definition of unit-type Volume from bytes to Octets.

When reporting usage, it seems that the total is a sum of input and output;
in other messages this may not be the case.

Here's how I see the situation: Currently, in RADIUS/DIAMETER we are primarily
reporting i/o byte and packet counts. If I understand correctly, the CCA
extends this by making it possible to also set per-session limits to
various amounts of "service" you are getting. One approach in doing this
would be to follow the existing RADIUS/DIAMETER model, i.e. to provide the
i/o byte/packet counts also in the other direction. But I would agree with
you that it would be insufficient. On the other hand, I wouldn't like to
have total counts in CCA and i/o counts in the other specs. So here's
what we could do:

- Define 6 counters:
   o Input, output, total X
   o Bytes, Packets
- Total counters need not be reported, but can be sent from
   the server as granted limits
- Not sure how to organize these as AVPs, whether to reuse
   old AVPs or make CCA specific AVPs.

--Jari