Subject: Usage/ Applicability question

From: "Krishna Ramadas" <[email-masked]>
Date: Tue, 23 Dec 2003 15:47:20 -0800

I work for a wireless appliance company and we have been looking at the
drafts produced by this working committee. I am interested in utilizing
the framework created by OPES for implementing distributed solutions.
While the drafts appear to lead me to a potential framework, I am not
sure about a couple of points. Perhaps, someone can help guide me on two
topics
 
Background
------------------
Our solution consists of distributed platforms that carry HTTP content
and process the traffic along the path. The first box processes traffic
from a "producer" and hands it over to a second box which performs
additional processing before it is handed off to a "consumer". Box-1 and
box-2 are OPES processors, to use the terminology applied in the drafts.
The first box is a load balancer/content switch gateway. The second box
is a wireless content optimizer. In this solution, the load
balancer/content switch gateway is the primary "collector" of billing
information, and the content optimizer provides "corrections" to the
billing record based on the amount of traffic that is
compressed/optimized.
 
Usage Question
We would like HTTP billing records to be collected for HTTP sessions. We
would like the two boxes to exchange billing update information, based
upon HTTP transactions within the session. We would like to utilize OCP
to control the process of record exchange between the two boxes. There
is no call-out/dispatcher relationship between the two boxes. From my
interpretation of the use case scenario, I need a dispatcher/call-out
relationship to apply the procedure specified in the drafts: Is this a
true assumption? 
 
Will/Can a use case extension be made for solution such as the one that
I have described above? We are trying to use OCP between two OPES
processors. We plan to support in-line tracing, but HTTP adaptation will
be handled independently by the OPES entities (box-1 and box-2) along
the way. The OPES entities will only exchanging control records related
to usage and billing on a per session-transaction basis. The OPES
entities would also, independently, apply Policy specifications.
 
Can OPC be applied to a situation where traffic adaptation is not
controlled by the OPC protocol, but only the usage records are exchanged
over the OPC protocol? Can OPC be used only to signal sessions and
transactions so that usage records can be associated with them?
 
Thanks
Krishna Ramadas
Venturi Wireless Networks

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 23 Dec 2003 22:48:31 -0700 (MST)

On Tue, 23 Dec 2003, Krishna Ramadas wrote:

> I work for a wireless appliance company and we have been looking at
> the drafts produced by this working committee. I am interested in
> utilizing the framework created by OPES for implementing distributed
> solutions.

First of all, thank you for sharing details about your use case and
asking for our opinions.

> We would like HTTP billing records to be collected for HTTP
> sessions. We would like the two boxes to exchange billing update
> information, based upon HTTP transactions within the session. We
> would like to utilize OCP to control the process of record exchange
> between the two boxes.

Since you are saying (below) that the process does not involve
exchanging HTTP messages (just metadata about them), OCP is just a
candidate protocol to do the job. It will work, but I would try to
find a better fit before making the final selection.

> There is no call-out/dispatcher relationship between the two boxes.
> From my interpretation of the use case scenario, I need a
> dispatcher/call-out relationship to apply the procedure specified in
> the drafts: Is this a true assumption?

The primary purpose of OCP is to exchange application messages and
their meta information between two agents. The callout/dispatcher
relationship is mostly undefined and has little effect on OCP Core
design. Some OCP Core optimizations assume that the processor (agent1)
receives original application data from the previous application hop
and will eventually forward adapted application data to the next
application hop, after/while talking to the callout server (agent2).

It is OK, in principle, for agent2 to be an OPES processor as well. If
no application data is exchanged, then some OCP Core optimizations
will not be used. Thus, you might be able to find a smaller/simpler
than OCP protocol that will do the job.

> Will/Can a use case extension be made for solution such as the one
> that I have described above? We are trying to use OCP between two
> OPES processors.

Interesting! Personally, I think that what you are trying to do should
be within OPES scope, even if the OPES Architecture document is too
rigid to imply that. IMO, any application message adaptation by an
intermediary is within OPES scope (with some use cases being less/more
"interesting" or "trivial" than others).

Again, OCP may or may not be the best protocol to use.

> We plan to support in-line tracing, but HTTP adaptation will be
> handled independently by the OPES entities (box-1 and box-2) along
> the way. The OPES entities will only exchanging control records
> related to usage and billing on a per session-transaction basis. The
> OPES entities would also, independently, apply Policy
> specifications.

Understood.

> controlled by the OPC protocol, but only the usage records are
> exchanged over the OPC protocol?

OCP should work in such an environment but is not designed for it. The
question is whether you would be better off with a different protocol.

Are you looking at OCP simply because it is a part of the OPES
framework, or do you like some of the OCP properties? Have you
considered using other existing or custom-made protocols?

> Can OPC be used only to signal sessions and transactions so that
> usage records can be associated with them?

Yes, I believe so. You will need to define an OCP profile for that, of
course (just like HTTP Adaptations draft defines a profile for
adapting HTTP messages with OCP).

Please keep us posted on your progress in finding the right protocol
for your needs.

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 30 Dec 2003 13:45:04 +0100

Alex,
I apologize because the business we talked about and I expected to fund an 
OPES development has been hampered by an intermediary who wanted to black 
mail it. It is now stabilizing but without the initial funding I expected. 
All this disconnected me totally from the work in this group.

Now, I work on contingency plans to develop OPES. As you know I am 
interested in DNS security and value added. I started rising the concern 
about the impact of DNS failures for companies, users, nations. This 
concerns takes off well. Also, I wish to find solutions where I can certify 
who reached what - for access gateway, certified mail, DNS updates, spam 
filtering, etc..

I follow three directions in parallel targeting large customers working on 
their common industrialization of free softwares (a started organization of 
large and committed organizations)- but to say large says slow.

1. to try to get a legal obligation in here to have a DNS contingency plan 
to get a DNS insurance. We have right now a vote on the Internet law and I 
proposed it. We start also dialoguing with the insurances association. The 
idea is to call for a stand-alone DNS+ system. Nothing fancy but something 
approved by insurances.

2. to develop a dedicated secure and stable hardware. The idea right now is 
an OpenBSD version stripped off everything we do not need for a 
named/Apache/postfix system + network and security control tools.  The idea 
behind the hardware is to stabilize solutions, to deliver binaries only and 
to get an insurance company/legal stamp on it. A manufacturer is supporting.

3. to build a software architecture as an OPES filter and an OPES processor 
- probably 8 machines in a team (two for backup)
    - two to carry http, smtp and dns filtering
    - two to carry DNS+ services (named and rerouting)
    - two to carry security checking
    - two controllers (or external softwares)

Kind of services:
- changing the dns request for a reroute, for vernacular name support (from 
jeanfrançois.fra to jefsey.com), or for critical situations
- changing the LHS of mails to permit sending/receiving mails with 
vernacular addresses to/from ASCII addresses
- verifying the origin of the call and the reached site, through external 
multi channel checking
- introducing access menus in a relation
- gateway access
- weemail support (a project of mine documented in French at 
http://weemail.org using standard smtp to send value added pointers rather 
than texts - with a totally different approach for spammers and compatible 
with existing e-mail).

I would be extremely interested in comments from everyone interested.
jfc