Subject: Re: Transport layer interface

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 27 Aug 1999 15:51:34 -0400

Rex, I'm sorry, but we have definitive consensus that the protocol supports
ALF.  By definition that means that the handling of transport issues is part
of the application.  At my request, the ALF alternative was documented in a
separate section from the layered alternative to make it easier for
implementors to choose the material that applies to them.  The one thing we
may not have done yet (I have to check) is ensure that our definition of
requirements for ALF includes appropriate backoff behaviour in the presence
of congestion.

Now, this thread started when Brian objected to including a general
transport layer model in the document.  Again by definition, such a layer
model is inconsistent with ALF.  Hence if it is present it should be in the
non-ALF section of the document.  I have already ruled that for transport of
H.248 over non-IP protocols, SG 16 rather than Megaco is the authority and
are free to present their specifications in the way they see fit.  People
who want to argue this should argue it at the SG 16 meetings, not on this
list.

Finally, I, like you, would very much like to see SCTP as a transport
alternative for our protocol.  It is shaping up nicely as something that
could meet our needs, even though support of Megaco is not explicitly on the
agenda.  However, given that it isn't here yet, I'd say this isn't the time
to try to add it.

> -----Original Message-----
> From: Rex Coldren [SMTP:[email-masked]]
> Sent: Friday, August 27, 1999 2:39 PM
> To:   [email-masked]
> Subject:      Re: Transport layer interface
>
> Hong Liu wrote:
>
> > Brian,
> >
> > I think Rex is entitled to have his opinion on this subject. But I don't
> think the intent
> > of this thread is to remove ALF from the protocol spec.
>
> OK, if you want to thwart this discussion with a technicality...
> Threads don't have intents.  They have topics.  As I have stated twice,
> exluding SCTP and
> the transport layering while including ALF is inconsistent behaviour that
> we need to correct.
> That's why they're all being discussed in this thread.
>
> > ALF is already there, and was shown to work in similar context as
> MEGACOP/ H.248. I
> > believe it has EVERY reason to be in the protocol spec as it is. What
> else status you
> > want than this?
>
> Your opinion is valuable.  But it's just that.  An opinion.  With no
> status.  And SCTP
> has been shown to work in a similar context as the transport requirements
> that we have
> for H.248/MEGACO.  If ALF is there, so should be SCTP.  But since neither
> can be
> referred to as standards, I recommend moving discussions of how to use
> them to H.248
> informative appendices.  TCP is the only standard that meets our
> requirements at this point.
> It can be normative.
>
> >
> > I don't think there was a consensus in Berlin to remove ALF. So there is
> no point in
> > revoking what was agreed in Oslo.
>
> I never said that, for sure.  It appears that our paradigm here is that
> what happens in
> meetings has no more weight than what happens on the mailing list or in
> conference
> calls.  That's not a bad thing, especially if we don't allow runaway
> threads to be called
> consensus.
>
> >
> >
> > --Hong
> >
> > Rex Coldren wrote:
> >
> > > Brian,
> > >    Well, clear and decisive conclusions from Santiago and Berlin have
> easily
> > > been reversed so I expect that this one can be too.  ALF has no place
> in the
> > > protocol spec.  It should be required to stand on its own as a
> transport mechanism
> > > just as SCTP has been required to do.  Once ALF reaches the status
> required,
> > > we can reference it from the H.248/MEGACO protocol spec.  So far, I
> believe
> > > ALF is probably far behind SCTP in achieving the status required for
> such
> > > inclusion.  This is the normal way of doing things.
> > >
> > >    Now if you're really desperate to include this kind of thing in the
> protocol spec,
> > > I think you need to bend a little and allow for other not-yet-standard
> concepts to
> > > be included (e.g.-the transport layer interface, SCTP, etc.).
> > >
> > > Rex
> > >
> > > Brian Rosen wrote:
> > >
> > > > It was clearly and decisively concluded in Oslo that there was a
> consensus
> > > > that ALF using UDP should be one of the transport mechanisms.
> Similarly,
> > > > TCP had a strong consensus.  SCTP was discussed, and there was, at
> that
> > > > time, no consensus.
> > > >
> > > > This debate is NOT about which tranports Megaco/H.248 should be
> defined
> > > > for.  It is whether defining an abstract layer to describe the
> interface
> > > > between the protocol and some undefined, future, non-IP transport is
> > > > appropriate.
> > > >
> > > > It has the curious characteristic that it's absence will not be
> missed -
> > > > there are no protocols defined using it, and it's use or non use
> would not
> > > > change externally visible behavior.  In particular, it is missing
> the
> > > > following statement:
> > > > "NOTE: The abstract layer DOES NOT define nor suggest an
> IMPLEMENTATION's
> > > > interface between protocol and transport.  It is strictly a
> convenience for
> > > > describing transports.  Not all transports are, or will be described
> using
> > > > this abstraction."
> > > >
> > > > I'm in the mood for a compromise.  Suppose we take the text, add the
> > > > disclaimer, and move it to an INFORMATIVE annex.
> > > >
> > > > Brian
> > > >

---

From: Rex Coldren <[email-masked]>
Date: Fri, 27 Aug 1999 13:46:10 -0700

Tom-PT Taylor wrote:

> of the application.

...

> agenda.  However, given that it isn't here yet, I'd say this isn't the time

Tom,
I'm not sure what "definitive consensus" means in the light of how many
decisions made at meetings recently have been reversed subsequent to said
meeting.  And I don't think we should be tied to sticking by bad decisions yet,
since the first revision of the standard is not yet approved.  So I'll say it one last
time:
I would like to remove the requirement that ALF shall be in implementations of
H.248.  I can see why someone implementing with TCP or SCTP would not want
to have ALF in their box.  Leaving it as an option is fine with me.  And move it out
of the body of the protocol to an appendix.  When SCTP becomes available we can
add an appendix/annex describing its use with H.248.

Rex

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Aug 1999 09:27:18 +1000

Tom,

You've mentioned a couple of times now that SG16 is the authority for
non-IP transports and are free to present their specifications in a way
they see fit. I'm assuming that the IETF and the SG16 protocol document
will contain the same sections. I'd just like to clarify what  this
actually means to the informational RFC that the IETF will publish?

I still don't subscribe that a layered transport precludes ALF, the
application of course knows best but it communicates with the transport
through an interface.

I also agree that SCTP is something that will be interesting for Megaco.
If its going to be used for other signalling protocols then it seems to
me that there's no point in having multiple reliable transport schema if
one will do 'the lot'.

Cheers, Christian

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Aug 1999 06:20:05 -0700

> application of course knows best but it communicates with the transport

   Are you under the misguided notion that you
cannot create an API for an application layer
transport?

 > me that there's no point in having multiple reliable transport schema if

   SCTP is an alternative for TCP, not ALF.

                Mike

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Aug 1999 21:06:38 +1000

No I'm not misguided, what is an API? its a layering concept that
contains a number of commands for the flow of data which is basically
what is proposed in the non-IP section with primitives. The application
layer can use this. That's why I believe one doesn't rule out the other.

SCTP is a candidate for UDP transport as ALF is.

Christian