Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Fri, 27 Aug 1999 09:09:12 -0400

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

> -----Original Message-----
> From: Rex Coldren [mailto:[email-masked]]
> Sent: Thursday, August 26, 1999 4:35 PM
> To: [email-masked]
> Subject: Re: Transport layer interface
>
>
> Hong,
>    THE reason that we balked on using SCTP as a transport mechanism
> is that, even though it is "mature",  it is not yet a
> standard.  I also note that
> ALF is not a standard and I don't believe that anyone has
> even tried to
> define it as such.  But perhaps you could help me here.   Is
> ALF the subject
> of standardization within any active working group or is it
> an already published
> standards-track RFC?.
>
>    What I am saying is you either include all reasonable
> choices for describing
> transport in the protocol spec or you exclude them.  The
> requirements have
> been clearly stated in the MEGACO requirements document
> already (or if they
> haven't they should have been).  If a particular candidate
> transport cannot meet
> these requirements, then we should not be spending time in
> the protocol spec
> trying to make it do so.  If we allow one exception to this
> rule (e.g.-ALF), we
> should allow them all (e.g.-include SCTP).
>
>    And, yes, I am a proponent of keeping the transport and
> the application cleanly
> separated.  ALF does not do that.  It does the opposite.  It
> should not be a topic
> of the protocol spec, IMHO.  Describing a transport layer
> interface is more
> appropriate in a protocol spec than ALF is.
>
> Rex
>
> Hong Liu wrote:
>
> > Rex,
> >
> > I don't think the issue here is for or against using SCTP
> or other transport
> > mechanism for MEGACOP/H.248. As Tom said in a previous
> email, when SIGTRAN matures,
> > people may find a way of using it. So let's do mix this
> topic with ALF.
> >
> > ALF, stands for APPLICATION level framing. The idea is
> general, but how it can be
> > done depends on each application. You seem to think
> otherwise. Why don't you show
> > us how you can separate ALF completely from MEGACOP/H.248?
> We all will see whether
> > it makes sense.
> >
> > ALF has been proven to work in various applications. In
> particular, it has been
> > shown to work in similar environment as MEGACOP/H.248. I
> think the intent of this
> > thread is on how to provide non-IP transport, not to remove
> or redefine ALF in
> > MEGACOP/H.248.
> >
> > I just hope it is not another attempt to do !####! again.
> Maybe I am too naive to
> > think that we have already passed that part.
> >
> > --Hong
> >
> > Rex Coldren wrote:
> >
> > > Qiaobing,
> > >    I definitely agree with you on this.  That's why the
> arguments about ALF
> > > and the transport layer interface are so baffling.  I've
> thought all along that
> > > ALF is just a mechanism for allowing use of a transport
> layer that doesn't
> > > meet the basic requirements of the application protocol
> (the examples being
> > > UDP and H.248, respectively).  Consequently, I believe
> that ALF should be
> > > something defined outside of the protocol since it
> presumably could be used
> > > for other applications needing the same kinds of support.
>  The argument for
> > > including ALF in the protocol specification is analogous
> to arguing that SCTP
> > > should be part of the protocol specification.  And trust
> me on this one, if I
> > > believed that including this type of thing in a protocol
> spec was acceptable I
> > > sure would be stumping for use of SCTP instead of ALF!
> > >
> > > Rex
> > >
> > > Qiaobing Xie wrote:
> > >
> > > > If it's this easy, people can stop worrying about diffserv :)
> > > >
> > > > In certain sense I do see your point, that if the
> application can take
> > > > over responsibilities from all the "layers", you can
> potentially optimize
> > > > the application behivors. However, this makes things
> unimplementable (is
> > > > this one of the reasons the layered model was
> introduced in the first
> > > > place).
> > > >
> > > > regards,
> > > >
> > > > -Qiaobing
> > > >
> > > > On Aug 26,  7:35am, Brian Rosen wrote:
> > > > > Subject: Re: Transport layer interface
> > > > > This is too easy:
> > > > >
> > > > > 1. E911 - 12 calls are queued in buffers, network is
> busy and a 911 call
> > > > > comes through -- it is put at the head of the line
> > > > >
> > > > > 2. "Olympic" service.  Service provider offers a
> variety of plans, at
> > > > > different costs.  Under congestion, Gold service
> customers get better
> > > > > performance
> > > > >
> > > > > 3. 30 messages are queued, some of them "Adds", some
> subtracts.  A
> > > > > message comes from the MG which is something that
> equates to "out of
> > > > > DSP" resources.  Reorder the messages so subtracts
> are ahead of Adds.
> > > > >
> > > > > The first one may turn out to be a requirement, and
> that may FORCE
> > > > > ALF in EVERY implementation.  YMMV.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Segers [mailto:[email-masked]]
> > > > > > Sent: Thursday, August 26, 1999 3:38 AM
> > > > > > To: Brian Rosen
> > > > > > Cc: [email-masked]
> > > > > > Subject: Re: Transport layer interface
> > > > > >
> > > > > >
> > > > > > All,
> > > > > >
> > > > > > I don't quite understand how ALF will be
> substantially better for
> > > > > > congestion management than a layered approach.  I understand
> > > > > > that if the
> > > > > > the application has control over message buffers, it can
> > > > > > reorder them.
> > > > > > What I'm wondering is whether reordering/canceling MEGACO
> > > > > > messages will
> > > > > > lead to a sufficient reduction in traffic, in the
> presence of media
> > > > > > streams on the same network.  Can someone give an example
> > > > > > where it would
> > > > > > help?
> > > > > >
> > > > > > John
> > > > > > --
> > > > > > John Segers                                  email:
> [email-masked]
> > > > > > Lucent Technologies
>        Room HE 306
> > > > > > Dept. Forward Looking Work
> phone: +31 35 687 4724
> > > > > > P.O. Box 18, 1270 AA  Huizen
> fax: +31 35 687 5954
> > > > > >
> > > > >-- End of excerpt from Brian Rosen
>

---

From: Rex Coldren <[email-masked]>
Date: Fri, 27 Aug 1999 09:00:12 -0700

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

---

From: Hong Liu <[email-masked]>
Date: Fri, 27 Aug 1999 14:18:44 -0400

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.

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?

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.

--Hong

---

From: Rex Coldren <[email-masked]>
Date: Fri, 27 Aug 1999 11:39:04 -0700

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

> believe it has EVERY reason to be in the protocol spec as it is. What else status you

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.

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

---

From: Hong Liu <[email-masked]>
Date: Fri, 27 Aug 1999 15:41:15 -0400

> That's why they're all being discussed in this thread.

I will disregard the flamming and accusation. It is not worth it.
The thread started with discussion on layering, but was redirected towards removing ALF. That is
what I meant by intent. If you want to call it topic, that is fine with me.

> Your opinion is valuable.  But it's just that.  An opinion.  With no status.

I guess it applies to everyone's opinion.

>  And SCTP
> for H.248/MEGACO.  If ALF is there, so should be SCTP.

To set the record straight, I am not against using SCTP. There may be network deployments out
there where using SCTP as the underlying transport makes sense. It is up to the SCTP folks to
define how it can be used.

> But since neither can be

ALF, just like layering, is a design method, not a protocol by itself. Requiring ALF to be a
standard is just as absurd as requiring layering to be a standard. ALF and layering are
incompatible design methods. Forcing ALF into layering is not going to work.

...[snip]

---

From: Chip Sharp <[email-masked]>
Date: Fri, 27 Aug 1999 16:57:43 -0400

Since ALF is part of the application, it needs to be in the same spec as
the application (i.e., megaco).  It will be standardized as part of the
megaco protocol.  I just don't think it would make sense to extract it from
the definition of the protocol.

In spite of having put a lot of time and effort into SCTP, I did not argue
with the proposal in Oslo only to specify ALF and TCP transport.  One
reason is that there is nothing in the protocol precluding the use of SCTP
when it is complete.  Right now, it hasn't finished being defined (although
we are very close :-).  I believe this was the gist of the SCTP reasoning
in Oslo.

When SCTP is complete and is working, then we can either rev the megaco RFC
to support it, we can add an annex to H.248 (I don't really care if it is
informative or normative <- save this for later. ;-) ), or we can write up
an informational RFC specifying how to run megaco over SCTP.

Normally, I would propose that that discussing transport of H.248 over
non-IP transport is outside the scope of any IETF WG and that SG16 should
define the non-IP transport mechanism.  However, this is a strange case
since we are trying to keep common text between SG16 and megaco.

 From what I have read so far (the term "A lot" is defined as the few
people who are very verbal. A nice Orwellian concept):

*  A lot of people are willing to allow H.248 over TCP.
*  A lot of people are willing to allow H.248 with ALF
*  A lot of people are willing to allow H.248 over non-IP transport (e.g.,
ATM).

While there may be people that prefer one or the other, most seem willing
to live with the existence of all three.  If we can agree on this, then we
can limit the discussion to the layering concept.

What is generating an excessive amount of heat on the list is whether or
not there should be an abstract transport layering.  I believe Christian
might agree it really doesn't affect the bits on the wire.  At the SG16
meeting in Berlin, I reached the same conclusion and agreed on the text as
proposed as long as the IP section remained mostly unchanged.  The
existence of the layering concept allows future transports to be defined
more easily, which was Christian's original intent I believe.

Brian proposed a compromise which I think makes a lot of sense, except it
isn't clear what is proposed for an informative Annex.  Is it the whole
transport section or just the non-IP part or just the modeling/layering
description?  Brian's note probably needs to be reworded somewhat.  Also
note that in ITU recommendations, notes are not normative.

Perhaps Brian could clarify which parts he was proposing to be moved to the
informative Annex?

Chip

P.S.  Do we need to add a lawful intercept transport sublayer? ;-)
Sorry, I couldn't resist merging two of my favorite threads.

> > > > disclaimer, and move it to an INFORMATIVE annex.

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

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

I would like the layering section remain pretty much as is. I've
mentioned before that I'd be happy with moving the primitive interface
to the non-IP section but keep the other text where it is. I definately
do NOT want it moved to an INFORMATIVE annex because it won't be
retained. I see that ALF and transport layering have the same status in
that they are equally valid for transport. Therefore I would like to see
them documented in the same way. If ALF is moved to an informative annex
then i'll be happy doing the same with the non-IP section.

The idea of presenting the sections as they are today in H.248 is that
there is a 'core' protocol. Which exists irregardless of ALF or layered
transport and a transport section which defines different transports.
This is to ensure independence.

The purpose of a mailing list is to discuss issues if people feel that
they want to discuss the applicability of ALF then they should be able
to, if they want to talk about SCTP then they should as times change and
it may be appropriate for consensus.

My original sentiment (which I believe Chip expressed) was that
different transports could exist (in harmony) if the transport was
seperated from the protocol section and that they had an equal footing
in the document. I don't see why one should preclude the others.

Cheers, Christian

---

From: Alf Heidermark <[email-masked]>
Date: Mon, 30 Aug 1999 11:20:37 +0200

Why do we describe transport at all in the protocol. I see H.248 as an
aplication protocol. You only need to specify some kind of primitives to
the transport and that can be done in a signnaling bearer independent
way.