Subject: RE: Draft Agenda for IETF 56

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 11 Mar 2003 11:01:22 -0800

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:[email-masked]] 
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:[email-masked]]
> 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.
>

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 11 Mar 2003 12:16:12 -0700 (MST)

On Tue, 11 Mar 2003, Reinaldo Penno wrote:

> 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?

Yes, thank you! You are saying that both application protocol and
callout protocol should (may?) use the same transport protocol, right?

This means that either we cannot support application protocols that
use UDP (and other lossy/etc protocols), or we will be violating
current callout protocol requirements (that demand reliable
congestion-aware transport):

3.1 Reliability

   The OPES callout protocol MUST be able to provide ordered reliability
   for the communication between OPES processor and callout server.
   Additionally, the callout protocol SHOULD be able to provide
   unordered reliability.

   In order to satisfy the reliability requirements, the callout
   protocol SHOULD specify that it must be used with a transport
   protocol which provides ordered/unordered reliability at the
   transport-layer, for example TCP [6] or SCTP [7].

3.2 Congestion Avoidance

   The OPES callout protocol MUST ensure that congestion avoidance that
   matches the standard of RFC 2914 [4] is applied on all communication
   between OPES processor and callout server.  For this purpose, the
   callout protocol SHOULD use a congestion-controlled transport-layer
   protocol, presumably either TCP [6] or SCTP [7].

IMO, callout protocol has sufficiently different purpose to deserve
its own transport binding, which MAY be the same as application
transport for some applications, but does not have to be. This
approach would let us support adaptation of application protocols that
do not satisfy OPES transport requirements.

Thank you,

Alex.

---

From: Andre Beck <[email-masked]>
Date: Tue, 11 Mar 2003 14:45:45 -0500

I believe the consensus at the conference call was that we do away with
the transport protocol negotiation mechanism and instead suggest that
the callout transport protocol be selected based on the application
protocol used between data consumer and provider. This does not mean,
however, that the callout protocol and application protocol have to use
the same transport protocol.

Section 3.12:

"The callout protocol MUST NOT negotiate the transport protocol to be
used for callout connections.  The callout protocol MAY, however,
specify that a certain application message protocol (e.g.  HTTP [5],
RTP [8]) requires the use of a certain transport protocol (e.g.  TCP
[6], SCTP [7])."

Reinaldo Penno wrote:
> UDP, and the opes dispatcher (between you two) decides that this media 
> needs adaptaion because you are on a cell phone.
> 
> 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.
> 
>         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.
> 
>