ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-26 15:30:33

On Thu, 27 Feb 2003, jfcm wrote:

At 17:57 25/02/03, Alex Rousskov wrote:
For now, it seems like we should add support for emergency (priority)
channels (additional transport connections) as an optional
optimization feature. I will make a corresponding proposal and will
try to generalize the idea so that an OPES server can instruct callout
server to give certain transport connections a priority, to support
QoS features (e.g., application messages from Gold Members should be
processed before all other application messages).

This is a good point. But I would prefer the following wording and
concept used/

1. command pipe (absolute priority) as a pipe 0. Establish the
relation with the service admin in my model.

2. this prevents the confusion of the mata data wording which
includes both command and ancillary information. I would treat
ancillary as standard transactions with the service admin subject to
the general prioritization service if any.

My proposal allows creation of a connection with priority higher than
all other priorities. That connection can be used by OPES dispatcher
and service admin as the "command pipe" that you propose in item #1
above.

It would be up to OPES dispatcher what to send on that "command pipe".
Your implementation, for example, may avoid sending metadata
(auxiliary) messages on the command pipe if desired.

Do you agree that the priority-based scheme I proposed both addresses
your needs and is more general/flexible? Or does it lack some
necessary features?

Thank you,

Alex.