Subject: RE: Draft Agenda for IETF 56

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

Yes, I understand the current requirements, but since HTTP is the protocol
in-scope at the moment and there is a push in the IETF (the chairs/ADs can
correct me if I'm wrong) to use congestion aware protocols, we thought using
SCTP might be a good compromise for those that think TCP is not appropiate.

We had the same debate in another WG that is chossing an transport protocol
and although some people wanted UDP the AD said the protocol must be
congestion aware. Anyway, we can revisit this issue if people think it does
not cater to the needs of OPES deployments.

Regards,

Reinaldo

-----Original Message-----
From: Alex Rousskov [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2003 2:16 PM
To: OPES Group
Subject: RE: Draft Agenda for IETF 56

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.

> -----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 13:05:31 -0700 (MST)

On Tue, 11 Mar 2003, Andre Beck wrote:

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

Great! That's what I would vote for as well.

> 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])."

Sorry for missing that paragraph.

> Yes, I understand the current requirements, but since HTTP is the
> protocol in-scope at the moment and there is a push in the IETF (the
> chairs/ADs can correct me if I'm wrong) to use congestion aware
> protocols, we thought using SCTP might be a good compromise for
> those that think TCP is not appropiate.
>
> We had the same debate in another WG that is chossing an transport
> protocol and although some people wanted UDP the AD said the
> protocol must be congestion aware. Anyway, we can revisit this issue
> if people think it does not cater to the needs of OPES deployments.

I suspect that for many OPES applications it would be perfectly fine
to use TCP for the callout protocol while the application protocol is
using something like UDP. Most OPES transformations are per
application message (e.g., a UDP packet) so we should be fine as long
as the callout protocol includes appropriate per-application-message
timeout mechanisms. The predraft documents already contains some
wording in that direction.

If Reinaldo agrees with Andre's recollection of the conference call,
then there seems to be no conflict regarding support for non-TCP
application transport. This mini-thread started when jfc asked whether
OPES transport must be TCP, and I think my initial response remains
valid.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 11 Mar 2003 23:22:16 -0500

> OPES transport must be TCP, and I think my initial response remains

I can fully second Andre's recollection. During a call of the 
"protocol requirements" sub-team, the author team agreed that

  (a) the callout protocol MUST NOT negotiate the transport protocol
      to be used for callout connections,
  (b) the callout protocol MAY, specify that a certain application
      message protocol (e.g.  HTTP, RTP) requires the use of a certain
      transport protocol (e.g.  TCP, SCTP).

This is fully documented in Section 3.12 of the protocol requirements 
draft.

Key point is that we do *not* have a transport protocol negotiation 
mechanism in the OPES protocol. However, we're also *not* restricted 
to a single transport protocol to be used for all purposes. Point (b) 
above specifies that the transport protocol to be used for the callout 
may depend on the application message protocol used between producer 
and consumer (e.g. HTTP). Note, however, that this is different from 
chosing the transport protocol for the callout based on the 
application itself...

General question now is whethr we feel that coupling the transport 
protocol for the callout to the application message protocol is 
flexible enough, or whether we need more flexibility?

For example, is it OK to assume that whenever the application message 
protocol is A, that the transport protocol for the callout is B. Or is 
there a case to make that for the same message protocol A, we 
sometimes need to use transport protocol B for the callout, and 
sometimes transport protocol C (substitute A, B, and C with your 
favorite protocols :) If so, how is this achieved without protocol 
negotiation?

-Markus

---

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

On Tue, 11 Mar 2003, Markus Hofmann wrote:

> For example, is it OK to assume that whenever the application
> message protocol is A, that the transport protocol for the callout
> is B. Or is there a case to make that for the same message protocol
> A, we sometimes need to use transport protocol B for the callout,
> and sometimes transport protocol C (substitute A, B, and C with your

I was not on that conference call so I may be missing some important
caveats. Said that, it seems to me that we should not care about the
ways transport protocols are selected as long as we do not have to
support true negotiations. In most cases, protocol selection can be
handled by static configurations (with rules if needed), and should be
out of our current scope.

No need to limit the selection/matching rules; just prohibit
in-protocol negotiations. Let implementations decide what is the right
protocol selection method is.

$0.02,

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 12 Mar 2003 11:39:46 +0100

Is there a site dedicated to a good SCTP comprehensive 
presentation/tutorial to learn it quick? thx.jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 08:18:41 -0500

> protocol selection method is.

Yup, feeling was that dynamic transport protocol negotiation adds too 
much complexity and might complicate interoperability. Now, whatever 
method is chosen for transport protocol mapping, it still must ensure 
interoperability, of course.

-Markus