Re: Accounting in peered CDNs: Initial thoughts ....

[brad cain <bcain@mediaone.net>]

Abhi Deshmukh wrote:
> 
> A few initial thoughts on accounting in peered CDN systems.
> 
> 1. Accounting information in CDN Peering would be useful for Monitoring
> Applications, Billing applications, Reporting and Auditing apps and other
> apps (like the ones not mentioned in the above list). Accounting information
> includes usage related information and details of other work done. Based on
> the discussions at the BoF, the settlement and payment issues are outside
> the scope of issues being considered.

yes

> 2. Based on the (draft-green-cdnp-gen-arch-02.txt) CDN Peering Architectural
> Overview draft, it is necessary for the Accounting CPGs to have interfaces
> with
>         (A) one or more peered Accounting-CPG,
>         (B) one or more origin accounting system,
>         (C) one or more external billing app, and
>         (D) it's own internal accounting system.

yes, though the important interfaces (at least as far as the
working group) are A and B

> 3. It is possible that the internal accounting system collects information
> from different CDN elements like Surrogates, Request Routing system, etc and
> optionally aggregates them. Should we be talking about intra-CDN accounting
> issues ? I think, we may mention them as needed.

again, i think the working group is explicitly focused on inter-cdn
issues... 
 
> 4. Specifically, inter-CDN accounting issues should be looked at in detail.
> Do Intra-CDN accounting practices influence the accounting CPG ? This needs
> to be investigated.

i would say that intra-cdn accounting systems can be linked
externally by some sort of "accounting gateway"

> 5. Certainly, transport of accounting records between accounting CPGs is an
> important issue. It should be possible to transport different kinds of
> accounting records using the same transport mechanism. There are issues of
> pull, push and latency (near-real-time and batch) while transporting
> accounting records. A candidate transport mechanism must be simple,
> efficient, and be capable of handling multiple details record formats, etc.

and it's likely that multiple transports will be used... my opinion
is that we should standardize the format of information first, then
adding transport is relatively easy as a second step
 
> 6. Work being done in the AAA group including the Diameter spec should be
> studied to see if it is applicable.

absolutely

-brad