These are good discussions on practicality. For a framework such as OPES
to gain acceptance with the operator community, it must address
practical structural solutions. Capacity limitation of servers (such as
an OPES proxy server) is the primary impetus to introduce load balancers
in a network. Load balancers not only address the linear growth issues
of an operator but also simplify provisioning, management and billing
tasks. In this regard, the flexibility in current OPES framework
definitions is good, any extensions should retain this.
Since Billing servers, generally perform offline processing (not in
line), they may not be seen, placed in the data path. Perhaps, the
configuration below implies that the billing functionality of the server
is in addition to an adaptation processing functionality. Is this
correct?
ContentServer ContentServer ContentServer
| | |
\ | /
\ | /
----------------------------
| Load Balancer |
----------------------------
| | |
| | |
| | |
BillingServer BillingServer BillingServer
| | |
\ | /
\ | /
----------------------------
| Load Balancer |
----------------------------
| | |
| | |
| | |
AdaptServer AdaptServer AdaptServer
| | |
\ | /
\ | /
----------------------------
| Load Balancer |
----------------------------
.....
regards,
krishna
Thanks for your input Geetha. I have found that billing can be a
difficult problem because people expect solutions to fit into their
existing billing model/system, no matter how it might work (it might be
good for some things and a problem for others). So a solution that
accommodates a number of billing approaches would be the best because
it is flexible and will be able to handle in-line billing, pre-paid,
pay-per-use...etc.
Also, I'd like to build an open infrastructure to solve my problem. The
feedback that I have gotten from past opes e-mails leads me to believe
that using the opes framework would be the best way accomplish this
important goal. But is seems the opes framework needs a solution to the
flow participant discovery problem. I emphasis the word discovery. My
thoughts are that once you know the other flow participant you can
always establish out of band communications to do whatever you need.
This seems to be the most flexible approach. Your thoughts?
Regards John
Geetha Manjunath wrote:
On the contrary, I feel the accounting model should be slightly
different in the OPES case:
(a) We should charge the consumer for bytes output from the content
server (we can debate on whether the #bytes is pre-adaptation or not)
PLUS
(b)A pay-per-use model for specific adaptation services used - this
information can be provided to the billing server by the adaptation
server.
Comments?
regards
Geetha
"The Purple Streak, Hilarie Orman" wrote:
If the billing is based on actual bytes delivered to the consumer,
there must be a business relationship between the billing stage
servers and adaptation servers. The relationship will usually allow
the adaptation servers to cache the content and report to the billing
servers about the number of bytes delivered. However, the reporting
is a reverse flow in the client-server model, and that is why it seems
problematical. By convention, the adaptation server might make a
request back to the provider with the number of bytes encoded in the
request, or it might, on occasion, upload a report. The rules
governing this behavior would most naturally be encoded on the
adaptation server, not on the OPES callout server. So, this seems to
me to be an issue for the rules language.
An alternative model would have this byte reporting functionality
handled on the callout server, and it would directly contact
the provider's billing service with reports.
Hilarie