I guess an example is better...
If you are running a media session with a friend, let's say RTP over UDP,
and the opes dispatcher (between you two) decides that this media needs
adaptaion because you are on a cell phone.
In this case the callout protocol should (may?) run over UDP. This is a
simple effort in order to guess the best transport protocol to use in the
callout protocol for this specific session.
Is this clearer?
Ps: OPES box meant just a device running the dispatcher. The callout server
is not included in the box.
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Tuesday, March 11, 2003 1:31 PM
To: OPES Group
Subject: RE: Draft Agenda for IETF 56
On Tue, 11 Mar 2003, Reinaldo Penno wrote:
If I remember correctly the decision reached some time ago during a
conference call was that the callout transport protocol would be the
same one used between user<----...OPES box....--->consumer
Reinaldo,
I am confused: Callout protocol is the one OPES dispatcher uses to
talk to the callout server. Why do you have "user", "OPES box", and
"consumer" in your picture if you are talking about the callout protocol?
The callout protocol is used _inside_ the OPES box, not outside it, AFAIK.
Did you mean application protocol instead? If so, would it be accurate to
say that the conference call resulted in a decision to prohibit application
protocol conversion by OPES (e.g., converting HTTP to FTP)?
Please clarify or point to the relevant documents. BTW, were the conference
call minutes posted on the list?
Thank you,
Alex.
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Tuesday, March 11, 2003 12:06 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56
On Mon, 10 Mar 2003, jfcm wrote:
My main question is about the entry and the ending points of the
OPES concept. If it is accepted that not only HTTP but any protocol
is OK, and that alternatively both end points can be user/producer
or that we may have a peer to peer support, it will mean that any
entry/output protocol is OK, including a keyboard/user
file/application etc, towards a screen, a file, etc.
This means there is no pseudo-synchoronous (like in hhtp) obligation
(or as options). This means that we have a general purpose concept
of a filter/transformer system on a flow. Which will standardize
everywhere.
This means that, the filter/transformer relation (callout protocol)
can be anything from realtime to soap. Am I correct?
I doubt we can design a good OPES system that can support adaptation
of anything from highly optimized realtime protocols to
structure-rich, super extensible XML protocols. There will be
tradeoffs that we will have to resolve one way or the other. That is
why it is important to agree on scope and use cases up-front.
Because this means that we will have a good general framework for a
protected/acked balanced protocol able to support one to many or
even many to many relations.
We should strive for that, but IMO we will come short as things get
more specific.
Then the next question will be: will it always be under TCP?
Transport protocol binding wise, TCP is probably not the only option.
We do need a reliable, order-preserving, congestion-aware protocol
though (see protocol requirements draft for details). These features
may already exclude certain realtime optimizations where losing
packets is not only acceptable but desirable in the presence of
unexpected delays or congestion.
An important design question is whether the OPES protocol should allow
multiple transport bindings/encodings or just one.
Alex.