Subject: RE: OCP Core version head_sid6 available

From: "Martin Stecher" <[email-masked]>
Date: Thu, 5 Jun 2003 10:13:10 +0200

Hi,

thank you very much, Alex, for getting back with the examples.

regarding priority:

different priorities may or may not make sense; we should leave minimum
support for it in the core I guess.

But changing priority on the fly for an existing connection does not
make any sense to me; let's take it out.

Let's take your example: If OPES processor and callout server are
able to support VIP connections and the OPES processor suddenly
receives a request from an important client, it makes only little
sense to change priority of one of maybe 200 open connections.
While the connection is not yet on high priority when the change-
priority-message is sent, there is no guarantee that changing
priority will be handled very soon.
I assume that such an OPES processor will better want to keep one
or more VIP connections open and alive to ensure even higher
quality of that service.

So one (optional) parameter in the connection-start message should
pretty much cover this.

regarding services:

The usage examples do not convince me that changing of services
will be needed but the security example is very important.
Thank you very much.

If a server can do virus filtering plus language translation and
we assume that there are two types of service requests (only
AV filter or both filters), I guess that there will be many
files for either types, so that keeping multiple connections
open, some with service type 1, the others with service type 2,
makes probably more sense than switching single (sub-)services
on the fly. (for example to avoid loading and unloading
of language dictionaries in the callout server)

The other example with the different services depending on hours
of a day: I personally do not believe that this will happen
(often) in real-world examples. Either services are very much
reduced to one task (do classification of URLs OR do virus
checking) and so OPES processor handles the results by itself,
may check the time, combine results of different services, or
services are rather complex (offer different modules like URL
classification AND virus checking) and then want to handle the
complete policy by themselves and also include the user profiling,
date-time policies and so on and don't allow the OPES processor
to select the single services.
(I think some of you have a different view on this.)
But still then I think we can better live with opening new
connections with new sets of services rather than switching
services on the fly; makes (programmer's) life just simpler.

What remains is your very important remark about the secrecy
of connection-start parameters. This may be imporant for any
parameter that we add to the core now or will be added later
by a application protocol binding (which is possible, isn't it?).

So, putting it together and taking your proposal:

> To keep things symmetric we can do this:
> 	- no dedicated Connection Services (CSvcs) message
   
yes, and also remove Connection Priority message

> 	- Connection Start (CS) and Transaction Start (TS)
> 	  messages have a Services parameter

Only Connection Start message has a services parameter and
an optional priority message. TS messages have not.

> 	- transport negotiations MAY happen before
> 	  Connection Start (CS) message

Transport negotiations (if any) MUST happen before CS message.

> 
> Would you prefer this? I think I would. The last item may sound
> strange, but I think it is actually the right thing to do because, in
> theory, a single transport connection can carry multiple OCP
> connections and so transport negotiations are one level above OCP
> connections.

I agree.

Thank you.

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 5 Jun 2003 10:21:38 -0600 (MDT)

On Thu, 5 Jun 2003, Martin Stecher wrote:

> regarding services: The usage examples do not convince me that
> changing of services will be needed

I agree that my examples were not very convincing. Let me try to come
up with a few better/different ones:

    An OPES processor is serving a large group of users,
    with diverse filtering needs. Perhaps this is a
    hosting environment with OPES-powered translation
    of hosted pages and other customer-specific services.
    Or maybe this is a CDN-like environment. The OPES
    processor is configured to use a callout server that
    can perform any service required. When the processor
    opens the connection to the server, no single set
    of services would describe its future needs. The
    processor leaves per-connection services empty as
    the default. For each transaction, the processor
    specifies the exact services that apply to that
    transaction, overwriting the default empty set.
    Opening a new transport connection for each
    transaction is not efficient enough in this case.

    An OPES processor performs a well-known list of
    services for all transactions, except there is
    a small group of VIP users that need a different set.
    The processor can allocate a new transport connection
    whenever a request comes from a VIP user, but it would prefer
    to use the existing transport connection since
    a VIP connection is not used often enough to
    keep it persistent.

    A busy callout server shared among many OPES
    processors (they subscribe to and pay for the
    service) does not allow more than one transport
    connection from a single OPES processor (or per
    single subscription so that you can pay for extra
    connections).

To summarize my current understanding, which, I think, reached another
level thanks to your comments:

    0a.Allocation of new services can be expensive so
       it is good to have some facility to load/unload
       a set of services for a group of transactions,
       instead of doing it for every transaction.

    0b.Allocation of transport connections can be
       both very expensive and, in some cases, technically
       or administratively impossible. OCP should not require
       allocation of multiple transport connections for
       semantic reasons. Everything should work over a single
       transport connection. This is an important design
       constraint!

    1. There are cases where transactions
       share the same list of services.

    2. There are cases where transactions
       do not share the same list of services.

    3. Several common lists of services may co-exist.
       For example, common services for images and
       common services for executables.

The above observations lead me to the following solution:

    A "list of services" needs direct OCP Core support.
    We need messages that create and destroy service
    lists. We need a mechanism to refer to an existing
    service list from a transaction-start message.
    Something along these lines:

    service-list-create sid=123 (s1, s2, s3);
      transaction-start xid=56 ... sid=123 ...;
      transaction-start xid=57 ... sid=123 ...;
      transaction-start xid=58 ... sid=123 ...;
      ...
    service-list-create sid=45 (s4, s5);
      transaction-start xid=60 ... sid=45 ...;
      transaction-start xid=59 ... sid=123 ...;
      ...
    service-list-destroy sid=123
      ...
      transaction-start xid=61 ... sid=45 ...;
      ...
    service-list-destroy sid=45;

Note that service-list-create and service-list-destroy messages have
no "scope" other than OCP connection. They are, essentially, a
connection-global variables or objects. This gives us enough
flexibility to cover all cases. Yet, it is a relatively simple and
very efficient scheme.

What do you think? Does this address your concerns? Do you think a
services-for-images and services-for-executables example is
valid/common enough? Do you think that OCP MUST work over a single
transport connection?

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 5 Jun 2003 10:24:36 -0600 (MDT)

On Thu, 5 Jun 2003, Martin Stecher wrote:

> regarding priority: different priorities may or may not make sense;
> we should leave minimum support for it in the core I guess.

Since priority handling is an optional feature that many (most?)
implementations will not support and that does not require any Core
support, it seems that it would be better to leave it out of the Core
and document it as an extension in a separate short draft.

Any other opinions/comments?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 5 Jun 2003 10:41:47 -0600 (MDT)

On Thu, 5 Jun 2003, Martin Stecher wrote:

> What remains is your very important remark about the secrecy of
> connection-start parameters. This may be imporant for any parameter
> that we add to the core now or will be added later by a application
> protocol binding (which is possible, isn't it?).

Yes, it is. In addition to bingings, extensions may add parameters or
new messages as well.

> Transport negotiations (if any) MUST happen before CS message.

That's probably too restrictive because some transports may require
run-time negotiations in addition to startup negotiations. Also,
please note that the other side can reject any insecure transmissions
if it insists on secure communications (causing an interoperability
problem). I believe each negotiable feature must document when it can
or MUST be negotiated.

This also reminds me that the only purpose of an OCP Connection (as
defined in the Core draft) is to specify the default services to be
applied to all transactions within an OCP Connection. The only
relationship between an OCP Connection and transport connection is
that we assume that transport will somehow distinguish OCP connections
from each other (e.g., by allowing only one OCP connection per
transport connection or by using some transport channel IDs). Thus,
the "Connection" word is really misleading and not appropriate. The
reason it exists in the current draft is because the OCP requirements
draft uses it, but we do not have to follow the requirements
terminology as long as we provide intended functionality.

I would like to propose the following:

	1. Remove the concept of OCP Connection. OCP Connection
	   is the same as transport connection.

	   Document that Connection Start (CS) and Connection
	   End (CE) messages refer to OCP transport connection.
	   The Connection Start (CS) message MUST be the first
	   message on the connection. It is nice to have a
	   protocol-specific "Hello" message before any
	   negotiations begin. Connection End (CE) message
	   MUST be sent immediately before closing the
	   transport connection. Its purpose is to allow
	   one side to inform the other why the transport
	   connection is being closed.

	   The current "scope for common services" aspect
	   of OCP Connection should be supported directly,
	   see "handling common callout services" e-mail.

	2. There will be no other connection-specific
	   messages or options, for now.

	3. When documenting TLS negotiations, insist that
	   they start immediately after Connection Start (CS).

Would that work for you?

Thanks,

Alex.