[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Accounting in peered CDNs: Initial thoughts ....
- To: "'cdn@ops.ietf.org'" <cdn@ops.ietf.org>
- Subject: RE: Accounting in peered CDNs: Initial thoughts ....
- From: Jay Guha <jayg@apogeenet.com>
- Date: Wed, 17 Jan 2001 16:10:13 -0500
- Delivery-date: Wed, 17 Jan 2001 13:11:05 -0800
- Envelope-to: cdn-data@psg.com
Abhi,
Some responses to your accounting thoughts.
> -----Original Message-----
> From: Abhi Deshmukh
> Sent: Wednesday, January 17, 2001 3:10 PM
> To: Jay Guha
> Subject: FW: Accounting in peered CDNs: Initial thoughts ....
>
>
>
>
> -----Original Message-----
> From: Abhi Deshmukh [mailto:Abhi.Deshmukh@apogeenet.com]
> Sent: Monday, January 15, 2001 4:55 PM
> To: cdn@ops.ietf.org
> Subject: Accounting in peered CDNs: Initial thoughts ....
>
>
> 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.
The accounting effort should be scoped to all 'works performed / requested'
between
peering CDN entities. Accounting here is strictly to define,create/generate,
exchange,store,secure these 'work entities' that depict the work
done/requested.
All other concepts such as settlement, payment etc will be tiered-upwards in
due course, but that will be the TermsOfReference (TOR) for another separate
working group. This serves to layer out the functionalities, keep our selves
honest & focused without jumbling up other important issues, and most
importantly allow the business layers to scale (we should not be in the
business of defining revenue value chains, biases, relationships etc)
>
>
> 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.
I recommend that we only define the formfactor of the CDRs ('work entities')
, and the protocol to exchange them between peering entities. It is not our
business to dictate what an entity (CDN) has to do with one of the CDRs once
he has received it. The exchange protocol will most likely have some
statemachine dependencies, but this will only be related to the exchange of
CDRs.
Food-for-thought : when does a 'work entity' become accountable ?
>
> 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 recommend that we do NOT get involved in intra-CDN issues. We
cannot get involved in defining rules & regulation where we have no
authority - this would imply certain architectural requirements,
constraints, & assumption on behalf of the intra-CDN that I believe is none
of our business. We need to abstract out our scope to where we have admin
rights only.
> 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.
Please refer above. Recommend only inter-CDN, NOT Intra-CDN.
>
> 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.
I completely agree - push, pull, poll would be mechanisms that we should
explore.
>
> 6. Work being done in the AAA group including the Diameter
> spec should be
> studied to see if it is applicable.
Diameter & Extensions, IPDR, PacketCableSpec are further efforts that I
think should be
looked at.
My other concern here, is authentication & autorization for 'Inter-CDN
works' ONLY needs to be accomodated somehow.
>
> Your responses, concerns and questions are greatly appreciated.
>
> - Abhi
>