Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 15:57:10 -0400

Okay, so now we have a different story from what I understood.

You want to MANDATE that EVERY implementation of a non-IP transport have the
layer primitives as defined.  If the
layer changes, implementations must change.
Implementations not conforming to the layer interface would
not be conformant to the protocol.  That is why you want it
to be normative - you really do want to define
implementation.

In a prior message you said:
>....Layering is not
>defining an IMPLEMENTATION it is actually allowing the opposite.
That was what got me to the idea that you advocated an abstraction, not a
conformance requirement.

That makes it easier, I think.  As long as you claimed the
layer was an abstraction for the purpose of making the
definition of transport simple, I think you had support
from people who always think transport is a black hole -
put bits in, they magically appear on the other side.

When you make the layer mandatory to implement, I think
you lose many of these folks.  I'll let them speak for
themselves.

For me, I don't think that conformance to H.248 should be
conditioned on the implementation of any particular
interface between the protocol and it's transport.
That is an implementation decision.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, August 30, 1999 7:10 AM
> To: [email-masked]
> Subject: Re: Transport layer interface
>
>
> A compromise would be easy if one was put forward. I don't see moving
> the choice from : not being in the protocol at all, to: leave
> it in for
> a while before it is removed (ie. informative) is a serious
> compromise.
>
> I believe that both transport descriptions can live together.
> In Berlin
> we had the option to  introduce the layered transport for IP
> solutions.
> I however I think we saw that both solutions can live together. This
> "was" the original intention. Thus again I would like them
> documented in
> the same way.
>
> The primitive interface defines the functionalities that must be
> supported in the interface between the application and transport. In
> this way people are free to implement it how they like as long as they
> provide for the flows described by the primtives. If the layer changed
> completely then the implementation would change because the data flows
> would
> be different. ie. if you change an API people's implementations will
> change. People's applications are free to  drive the transport as they
> see fit, without a certain ALF being mandated.
>
> Its not an observable interface because there's nothing going across a
> wire I believe this is the same as ALF.
>
> If a primitive interface crys out to be Informative then I suggest the
> ITU has a very big task adhead of it to redocument a lot of protocols
> as 'Informative'.
>
> Christian
>
>
>
>
> Brian Rosen wrote:
> >
> > I can see that compromise is not going to be easy.
> >
> > The text is INFORMATIVE because it does not define the
> operation of the
> > protocol.  It tells you how to interpret some
> (non-existent) definition of a
> > transport.  By definition, and your own statements, the
> layer does NOT
> > define implementation -- it is a convenience for describing
> a transport.  It
> > isn't required to be able to define a
> > transport, and it may or may not be used to describe future
> transports - we
> > just don't know.
> >
> > If the layer definition changed completely, no
> implementation would have to
> > change, right?  It's not
> > an observable interface.
> >
> > Gets to the heart of the problem, doesn't it?
> >         It has no purpose in the current edition
> >         It may or may not be used in a future edition
> >         If it is used, it doesn't define behavior, or
> >                 implementation
> > Doesn't that really yell out "informative" (at best) to you?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Sunday, August 29, 1999 7:44 PM
> > > To: [email-masked]
> > > Subject: Re: Transport layer interface
> > >
> > >
> > > 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
> > >
> > > 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
> > > >
> > > > > -----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: Christian Groves <[email-masked]>
Date: Tue, 31 Aug 1999 14:30:53 +1000

Primtives are an abstraction. Primitives are used to define the flows of
data between the Application and transport. The interface between the
Application and the transport must support these flows on data. How you
implement it is up to you and your application. For instance the
transfer.data primitive - it may be as simple as setting a push bit on a
TCP packet. The transfer.data primitive says you have to be able to
support sending data to the transport it doesn't say to set a bit which
is implementation specific.

I think people are intelligent enough on this list to realise that
there's no magic in protocol design.

I'm glad that its accepted that conformance to H.248 on an interface
between the application and transport. Does that mean that the transport
sections for ALF and non-IP transport will both be made into informative
annexes? By mandating ALF its making an implementation decision for
everybody who will use the protocol with IP transport.

Cheers, Christian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Aug 1999 06:18:46 -0700

> everybody who will use the protocol with IP transport.

   In order for ALF to be any sort of useful, it
must be normative; if ALF is implemented, it's not
a mere suggestion of how interested parties ought
to consider implementing it.  The Oslo consensus
was, however, that the MG could pick either ALF or
TCP (or both) and that the MGC must support both.

                Mike