Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 1999 09:45:17 -0400

When I read the text, it seemed to me to define the transport
interface for ALL transport mechanisms.

If it is intended to cover only non-IP mechanisms:
        The section should come AFTER the IP transport
        It should be reworded to clearly state that it
                covers non-IP transport only.

I personally think it's wasted words.  We can't make it
part of the spec that you use it (i.e. no conformance test).
ALF for ATM makes as much sense as ALF for UDP (that's clearly
what we would do), so it can't say it's required for non-IP
transport.  The congestion section is much to weak to be
useful.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 10:20 PM
> To: [email-masked]
> Subject: Re: Transport layer interface
>
>
> The reason that this proposal didn't really get discussed in
> Oslo is that
> it is mainly intended for transporting Megaco/H.248 over
> *non-IP* transport
> (e.g., over ATM).  I believe Tom captured the consensus from
> Oslo for *IP*
> transport.
>
> The end result for me was that as long as H.248 maintained
> the results of
> Oslo for IP transport (e.g., ALF and TCP), I didn't really
> care that much
> what we added in SG16 for non-IP transport.
>
> Chip
>
> At 04:42 PM 8/18/99 -0700, Rex Coldren wrote:
> >Tom,
> >    The one thing you would see that indicates that Oslo
> didn't capture
> >consensus is the proposal from Christian Groves and the reaction to
> >it in Berlin.  The discussion went on for a while.
> Unfortunately I don't
> >remember the exact outcome.  Working all night tends to blur things.
> >Perhaps Christian can summarize for us what was agreed or wasn't
> >agreed to at that meeting before we kill the idea on the list.
> >
> >Rex
> >
> >Tom-PT Taylor wrote:
> >
> > > I kind of agree that this one is surplus to requirements.
>  It's main point
> > > would be to provide a hook for transport evolution (e.g.
> to Sigtran), if we
> > > saw that in our future, but we should probably let the
> future take care of
> > > itself.  This was an issue over which we took
> considerable pains at Oslo,
> > > and I haven't seen anything on the list to make me think
> Oslo failed to
> > > capture consensus.
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [SMTP:[email-masked]]
> > > > Sent: Wednesday, August 18, 1999 5:51 PM
> > > > To:   [email-masked]
> > > > Subject:      Transport layer interface
> > > >
> > > > Berlin inserted a concept that was discussed and discarded
> > > > in the IETF process; defining a transport independent interface
> > > > to the transport layer.  The layer defines a set of primitives
> > > > to be used between the protocol implementation and any transport
> > > > layer.  The goal is to maximize interoperability, and to permit
> > > > transport over non-IP networks.
> > > >
> > > > One of the major benefits of ALF is that it allows the
> application
> > > > to make dynamic decisions on sending of messages in the face of
> > > > congestion.  You could, for example, queue a message, discover
> > > > there was congestion, and decide to send
> > > > another message before the enqueued message.  You could even
> > > > decide to not send the message at all.  The application
> > > > may make these decisions.  Layered interfaces that only have
> > > > simple "transfer" primitives cannot provide this kind of
> > > > reaction to congestion.
> > > >
> > > > For that reason, I question an attempt to provide a transport
> > > > independent layer.  The current wording is not sufficient, as
> > > > the comments point out, and there are no submissions that
> > > > would get us to a complete description.
> > > >
> > > > The sections on transport using ALF and transport using TCP
> > > > are, I think, satisfactory without the extra layer.  Any
> > > > additional transports, IP based or not, could be defined in
> > > > subsequent editions, or in separate documents without a layer
> > > > definition.  Since there is not any claimed desire to be able to
> > > > have a literal "plug this protocol code into that
> transport code",
> > > > I don't think we will miss it.
> > > >
> > > >
> > > > What to do?
> > > >
> > > > Brian
> > > > ------------
> > > > Brian Rosen, Principal Engineer
> > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
> > > > (724) 742-6826  mailto:[email-masked]
>
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

---

From: Fernando Cuervo <[email-masked]>
Date: Thu, 19 Aug 1999 13:49:35 -0400

Yeah, let's leave it out.

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         August 18, 1999 5:50 PM
> One of the major benefits of ALF is that it allows the application
> have a literal "plug this protocol code into that transport code",

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 12:37:32 -0400

Christian

Adding a transport can only be done by:
1. Putting out a new edition of the base document, and modifying
the transport section

2. Putting out a new edition of the base document, and adding an
annex

3. Putting out an entirely new document referencing the base
document, and adding capabilities to it.

The layer does not alter this.  It does not make it easier.
It simply provides a framework for describing the changes
required, and, for anything ALF-like, it is WRONG.  It decreases
flexibility, because it proscribes the boundaries.

The layer definition is seriously flawed in that it assumes that
once the message is passed in transfer.request, it is up to
transport to deal with it, and the only reply is
transfer.indication.  That is not true if the application wishes
to reorder messages in the face of congestion, for example.

We are not at a point where we could decide if, for
example, using ALF techniques on AAL5 is appropriate.
I think it is, you think it isn't.  Regardless, it
could be, and therefore, I think it would be unwise to specify
a boundary that cannot describe the existing (UDP/ALF),
nor any possible similar techniques.

If we get wording we are happy with for TCP, the delta from
that to any ordered reliable transport is trivial.
I conclude the layer buys us precious little even if you are
correct about ALF and other network types.

We certainly have flexibility from both ITU and IETF in
document structuring.  I don't think the layer is appropriate
for either, even considering customary ITU practice. I'm not
a fan of placeholders.  Protocols evolve over time, and it
is uncommon to have them evolve in directions the originators
thought would happen.  The placeholder is a note that you
didn't finish something you thought wasn't important to
finish.  Whether it remains unimportant, you can't predict.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, August 20, 1999 3:20 AM
> So we agree different signalling transport technologies should be
> supported.
>
> I certainly see that this would be described in another document or
> annex of H.248. I want H.248 described in such a away that we
> don't have
> to change the base specification every time I add another transport
> technology. This is adding flexibility.
>
> By layering you add flexibility. By not tightly coupling the actual
> protocol and its transport it allows you work on either.
> Layering is not
> defining an IMPLEMENTATION it is actually allowing the opposite. By
> having primitives which are just a logical representation of something
> you can implementation these in a number of ways. By saying you use a
> transfer.primitive it is a logical function but by saying 'keep
> transactions in memory' for TCP it is an implementation issue. In fact
> it is the ALF and TCP sections which are telling me how to do my
> IMPLEMENTATION which you've already agreed is BAD.
>
> Defining ALF for AAL1,AAL2, AAL5, ATM etc is something I
> don't think we
> want to do now and as you said 'IF' it might not be something we do at
> all.
>
> I think by leaving the sections as they are it shows a wider audience
> that we have considered the issue and that there is a place holder for
> future development. This is a common practise in ITU recommendations.
>
> I'm also gathering that due to the nature of the agreement between ITU
> and the IETF that there'll be some flexibility in documentaion.
>
> Cheeers, Christian
>
>
>
>
> Brian Rosen wrote:
> >
> > I work for a company that is pretty well involved with ATM.
> > We have customers who would like to run MGCP directly on
> > ATM, not IP over ATM.  While there are no actual proposals,
> > if we were to write one, it would almost certainly be ALF
> > over ATM AAL5.  In particular, any effort we put into
> > intelligent handling of congestion by letting the application
> > get in on the decisions of what to send and when to send it
> > is 90% applicable to an ATM transport, and we would be
> > foolish to handle the circumstances another way.  If we
> > desire to use something like SSCOP providing reliable,
> > ordered delivery, then the transport would look very much
> > like the TCP transport defined in the draft.
> >
> > It may be that some want to deliver MEGACO over an AAL2 subchannel.
> > Fine, and although congestion using AAL2 (assuming that for
> > other reasons the AAL2 QoS is something like rt-VBR) is not the
> > same, the transport mechanism will very, very likely look like
> > ALF if there is no other layer, or like TCP, if something like
> > SSCOP were used.
> >
> > There would clearly need to be some kind of document that
> > described ATM transport of H.248.  That document might originate
> > in the ATM Forum, and subsequently be made part of H.248,
> > or it might be done wholly within ITU.  Regardless, it will
> > very likely end up being an annex to the main document,
> > just like Annex C of H.323.
> >
> > While the wording of the annex would clearly be different if
> > the layer wording stayed in the main document, there is NO
> > functional difference with or without it, primarily
> > because the layer is not visible outside either the MG or the
> > MGC.  The entire layer exercise is defining the IMPLEMENTATION
> > of the protocol, which is usually considered not to be a good
> > idea in a protocol document.
> >
> > There are lots and lots of instances in the ITU and in the
> > IETF that add things like another transport mechanism to a
> > protocol by either editing the base document, adding an annex,
> > or writing a new spec referencing the old spec with the
> > changes required to achieve the goal.  The only thing the
> > layer does is make this process a little less like surgery.
> > What you lose is application flexibility.
> >
> > Defining a layer between protocol and transport does not
> > make defining a non-IP transport any more or any less work,
> > does not alter the observable results, and does not affect
> > the feasibility, document organization etc.!
> >
> > And, I'll point out again, that if we did standardize ALF
> > over ATM AAL5 (or AAL2 for that matter), then the layer
> > mechanism as proposed is entirely inadequate.
> >
> > Brian
> >
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Thursday, August 19, 1999 3:36 AM
> > > G'Day all,
> > > Seeing my name was mentioned several times I guess I better
> > > speak up on
> > > this issue. There were a number of points:
> > >
> > > 1. A contribution was made to be able to use H.248 across non-IP
> > > transport technologies
> > > 2. The rational is that if you have a gateway with ATM, AAL2
> > > etc you may
> > > not want an IP signalling transpport.
> > > 3. The layered approach was introduced as a way of doing this.
> > > 4. I recognise that IP is the current and primary means
> of deploying
> > > H.248 I wanted to document H.248 a way that allows
> continued developed
> > > of the protocol without having to delay it whilst adding seperate
> > > transport technologies.
> > > 5. We wanted the H.248/Megaco specification NOT to be
> tied to an IP
> > > transport technology that is why we proposed the changes to
> > > the document
> > > structure to allow the actual protocol (procedures &
> symantics) to be
> > > separated from the transport issues.
> > > 6. ALF is tied to IP and is not suitable to other transport
> > > technologies
> > > this I think is reflected in the specification
> > > 7. I think it was agreed in the Berlin meeting (the italics
> > > section) of
> > > the document that ALF and TCP transport sections should be
> > > re-written to
> > > make them sound like a protocol document rather than a
> > > educational peice
> > > of writing. We suggested some headings.
> > > 8. We made no attempt to change the technical parts of
> the ALF and TCP
> > > sections the changes we proposed were to aid clarity.
> > > 9. I was not at the Oslo meeting however I understand
> that there was
> > > still discussion of the transport issues after this meeting as the
> > > outcome was not clear.
> > > 10. If we don't do this then another device control
> protocol will be
> > > defined for ATM based MGs and we'll end up with the
> situation where we
> > > have 2 procedurally and symantically different media
> gateway control
> > > protocols. This will cost. Its better to have to have the
> > > same protocol.
> > >
> > > Therefore I feel strongly that the sections regarding
> non-IP transport
> > > should remain.
> > > Hopefully I've captured most of the points from this thread.
> > >
> > > Cheers, Christian
> > >
> > >
> > > Brian Rosen wrote:
> > > >
> > > > I'll point out again that the layer is not appropriate for
> > > > ALF under non IP transport.  So it would have to be
> something like:
> > > >
> > > > "The following section illustrates a possible way to define
> > > the interface
> > > > between the protocol implementation and a non-IP
> > > > transport where Application Level Framing does not need to
> > > > interact with the order messages are actually sent.  This
> > > > section is informative and implementations need not follow it"
> > > >
> > > > Given that, it has no business taking up space in the document.
> > > >
> > > > Brian
> > > >
> > > > > From: Hong Liu [mailto:[email-masked]]
> > > > > Sent: Thursday, August 19, 1999 10:26 AM
> > > > > Rex,
> > > > > I think what Tom meant by "consensus" was from all the
> > > > > participants in the Oslo
> > > > > meeting. In that sense, it was a consensus from that meeting.
> > > > > Of course,
> > > > > Christian Grove was not in that meeting, and his contribution
> > > > > in Berlin reflects
> > > > > a different opinion in this topic.
> > > > >
> > > > > I remember that the transport issue was indeed discussed in
> > > > > Berlin around 4:00am.
> > > > > Instead of debating the pros and cons then, the group decided
> > > > > to just put the
> > > > > text in for further discussion on the list. In other words,
> > > > > the intent was not to
> > > > > reflect any agreement reached in Berlin, rather it was to
> > > > > capture the issue.
> > > > > Maybe Nancy or John can comment on this.
> > > > >
> > > > > Chip made the point a number of times in the meeting that the
> > > > > proposed sublayer,
> > > > > if added, shall be put in a separate session for "non-IP"
> > > > > transport. I think this
> > > > > is a reasonable proposal for compromise. It seems to me that
> > > > > this is also what
> > > > > the many people think from the emails I read along
> this thread.
> > > > >
> > > > > --Hong
> > > > >
> > > > > Rex Coldren wrote:
> > > > >
> > > > > > Tom,

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Aug 1999 09:52:33 -0500

I have a simple answer to that.  Non-IP transport is outside the IETF's
scope.  It's up to SG 16 whether they want this material in, so long as they
respect our ethic in favour of assured interoperability.

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Tuesday, August 24, 1999 6:14 PM
> To:   'Christian Groves'; [email-masked]
> Cc:   Taylor, Tom-PT [CAR:B901-I:EXCH]
> Subject:      RE: Transport layer interface
>
> I'd like to have the group consensus on the issue of whether the
> version 1 document should have a transport interface layer defined for
> non-IP transports that don't include ALF.
>
> If the group decides that such a feature is useful at this time, then
> we should discuss how best to word it so that it is not confused with
> IP transport or non-IP transport using ALF techniques.
>
> I believe that given the constraints, the layer is dubious, and will be
> very
> confusing to readers because there are no transports standardized in this
> version that use it, and several that don't.
> If the entire section were deleted, there is no change to any
> implementation.  I'd say that was a pretty good argument to leave it out,
> but I'm just one voice.
>
> Tom, time for a show of hands?
>
> > Sent: Sunday, August 22, 1999 8:53 PM
> > G'Day Brian,
> > As a way of moving forward according to your comments below I propose:
> > - 6.6.1 Stays pretty much as is. I still think it needs to be stated
> >   that actual protocol remains seperate from the transport.
> >   Remove 'primitive interface' comment from diagram
> >   Change that non-IP flows are described through primitive interface.
> >   The non-IP section should be for reliable and unreliable transports
> > - 6.6.2 move into 6.6.3 Use of H.248 in non-IP transport networks
> > - 6.6.3 move after 6.6.4 Use of H.248 in IP transport networks
> >
> > Cheers, Christian
> >
> > Brian Rosen wrote:
> > >
> > > Paraphrasing the way the document is (supposed to be) structured:
> > >
> > > 1. We present the interface between the protocol and the
> > > underlying transport.
> > >
> > > 2. We present the UDP/ALF transport, which doesn't use the
> > > interface because the interface doesn't work for UDP/ALF
> > >
> > > 3. We present TCP as a delta to UDP/ALF because we didn't
> > > want to change the IP versions
> > >
> > > We need to get through the discussion of if there is a layer.
> > > If there isn't, I know what to do.  If there is, I'm going
> > to move it after
> > > UDP & TCP, and qualify the heck out of it to
> > > be a placeholder solely for reliable ordered non-IP transports.
> > >
> > > I'm painfully aware that the IP transport section was rushed.
> > > It is, however, largely cribbed from MGCP.  There are dozens of MGCP
> > > implementations, and there have been several
> > interoperability demonstrations
> > > based on this text.  You can't claim it's bad.  Anything
> > can be improved.
> > > I'm absolutely willing to improve it, but I know that what
> > is there works.
> > > I'm very reluctant to completely rewrite it.  I'm okay with
> > moving sections
> > > around, changing headers, adding explanations, etc.
> > >
> > > Brian
> > >
> > > PS: I'm sorry Christian if this seems like an attack on your
> > > efforts in the wee hours of the morning in Germany, but I think
> > > that the ITU version of this was fairly rushed coming out of
> > > the Berlin meeting. Given the time frame I think you did a good
> > > job.
> > >
> > > > Sent: Friday, August 20, 1999 3:47 AM
> > > > It was proposed to add the non-IP section because the
> > other sections
> > > > were tied to IP transports. I didn't want to change the IP
> > > > sections for
> > > > this.
> > > >
> > > > It was proposed that the IP transport section be
> > re-written because of
> > > > many places where the text was superflous. Headings were
> > > > suggested as I
> > > > thought that it is more logically and easier to follow
> > with headings
> > > > such as:
> > > > - procedures for sending a message,
> > > > - procedures for receiving a message,
> > > > - congestion handling
> > > > The heading 'Providing the At-Most-Once functionality'
> > doesn't really
> > > > allude to what's happening.
> > > >
> > > > Below is an extract of the some of the issues which should
> > > > the transport
> > > > dependance and superflous text:
> > > > 6.6.4.1.5
> > > > Is it necessary to say what a properly configured system is?
> > > > What is a classic algorithm?
> > > > We request? does it do it or not?
> > > > Does ATM have a DNS?
> > > > The timers are based on IP networks.
> > > > Does ATM run IPSEC?
> > > > 6.6.4.1.6
> > > > This property tends to maximise < superflous
> > > > Can use following rules < is that a should, shall, may ?
> > > > 6.6.4.1.7
> > > > Media Gateway Controllers are typically dimensioned .........
> > > > <Is this telling me what an implementation is? Do we
> > really need this
> > > > section given the different applications an MC or MG will face>
> > > >
> > > > Cheers, Christian
> > > >
> > > > PS: I'm sorry Brian if this seems like an attack on your
> > > > editorship but
> > > > I think that the IETF version of this was fairly rushed
> > > > coming into the
> > > > Berlin meeting. Given the time frame I think you did a good job.
> > > >
> > > >
> > > > Chip Sharp wrote:
> > > > >
> > > > > At 05:36 PM 8/19/99 +1000, Christian Groves wrote:
> > > > > >G'Day all,
> > > > > >
> > > > > >Seeing my name was mentioned several times I guess I
> > > > better speak up on
> > > > > >2. The rational is that if you have a gateway with ATM,
> > > > AAL2 etc you may
> > > > > I believe that we agreed in Berlin that this could be done.
> > > >  It is a matter
> > > > > of defining the transport mechanism.
> > > > >
> > > > > >4. I recognise that IP is the current and primary means of
> > > > deploying
> > > > > >transport technology that is why we proposed the changes
> > > > to the document
> > > > > While abstracting the transport out of the document will
> > > > make it more
> > > > > general, I believe that it is more usable to have transport
> > > > sections in the
> > > > > document.  However, I'm not going to push the point for non-IP
> > > > > transport.  Others may be more concerned with non-IP
> > > > transport than I am.
> > > > >
> > > > > >6. ALF is tied to IP and is not suitable to other
> > > > transport technologies
> > > > > I believe ALF will work over most transports.  In fact,
> > much of the
> > > > > transport section will have to be incorporated into any new
> > > > transport
> > > > > section, including non-IP transport.  The main problem
> > in defining a
> > > > > general model is that there is no sensible way to abstract
> > > > ALF out of the
> > > > > application.
> > > > >
> > > > > >7. I think it was agreed in the Berlin meeting (the
> > > > italics section) of
> > > > > My memory of the agreement in the Berlin meeting was that
> > > > the IP transport
> > > > > sections would remain as is.  I'm not sure about anyone
> > else at the
> > > > > meeting, but I agreed to the added text (not the italics)
> > > > only on the
> > > > > condition that the IP transport remain as is.
> > > > >
> > > > > If the IP transport text needs to be cleaned up, then I
> > > > agree we should do it.
> > > > > I don't think it is necessarily bad to have educational
> > > > information in a
> > > > > standard.
> > > > >
> > > > > >8. We made no attempt to change the technical parts of the
> > > > ALF and TCP
> > > > > >9. I was not at the Oslo meeting however I understand that
> > > > there was
> > > > > This is not necessarily true.  IP runs fine over ATM and
> > > > H.248 over IP can
> > > > > be used to control ATM-based MGs.  The question is whether
> > > > or not H.248 can
> > > > > run over non-IP transport.  I don't think there is an
> > > > objection to SG16
> > > > > defining a way of running H.248 over a non-IP transport.
> > > > >
> > > > > I think the main issue is the general modeling text added in
> > > > > Berlin.  Perhaps other people who want to run H.248 over
> > > > non-IP could
> > > > > provide some input.
> > > > >
> > > > > > > "The following section illustrates a possible way to
> > > > define the interface

---

From: Brian Rosen <[email-masked]>
Date: Sat, 28 Aug 1999 17:32:50 -0400

> 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?
Just the layering text.
This leaves ALF & TCP in the main body.
If, in the future, non-IP transports are defined:
        If they use the layer, they can reference the annex for
                descriptions of the primitives.  Since the primitives
                are NOT part of the protocol, these sections can be
                normative
        If they don't use the layer, they can look like the existing
                sections

Non-IP transports could be defined in the body of the protocol in some
future rev, as annexes, or as separate documents.

> Brian's note probably needs to be reworded
> somewhat.  Also
> note that in ITU recommendations, notes are not normative.
If it's an informative annex, it can be an informative note!
I'll be happy with any suggestions to reword the note.
What area needs to be addressed?

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Sun, 29 Aug 1999 18:05:29 -0400

If I get persistent opposition that wasn't at the meeting, I'll have
evidence that the consensus suggested by the hum at the meeting is not
holding on the list.  In the meantime, I'll recall to you that the sequence
of hum-votes was as follows:
 -- TCP alone: modest support
 -- ALF alone: well, one supporter has a very loud hum.  A reasonable number
of people gave him accompaniment.
 -- both TCP and ALF: definitely the loudest hum, and solid enough to appear
to constitute a consensus.

> From: Mike Buckley [SMTP:[email-masked]]
> Sent: Sunday, August 29, 1999 12:04 PM
> Brian,
> >ALF isn't up for discussion -- it's in there.
>
>
> I thought the purpose of the mailing lists was to hold a discussion?
>
> Mike
>
>
> ____________________ Begin Original Message
> ___________________________
> Date: Sat Aug 28 16:46:22 -0400 1999
> From: internet!ENG.FORE.COM!brosen (Brian Rosen)
> To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
> Content-Type: Generic-Text
> Content-Length: 3411
>
> Yeah, I understand.
>
> The issue is whether we have this text that describes an interface that
> doesn't exist, for a set of transports that aren't defined.  ALF isn't
> up for discussion -- it's in there.
>
> I offered a compromise - make it an informative annex with an appropriate
> disclaimer.  So far, no takers.
>
> Like many things, nice neat boundaries are very useful teaching devices.
> In practice, you most often get better results when you aren't so
> pristine.
>
> Brian
>
> > Sent: Friday, August 27, 1999 2:19 PM
> > 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
> >
> > 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: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 09:46:48 -0400

Sure, but we have HAD that discussion for a couple of
months between Minneapolis and Oslo, and we determined
consensus in Oslo, as Tom pointed out.

We can clearly go back if there is sufficient
justification, but it doesn't seem that there is.

The layer stuff showed up first in Berlin.  I understand
that I'm somewhat pushing the IETF process on an ITU matter
and I understand it is intended to cover the non-IP case
only.  I'm pushing it primarily because I think it's just
wrong.  I was not able to attend Berlin, or I would have
worked hard to avoid being in this extended debate now.

The layer defines an non-existent interface, on an
undefined transport, and it does so in way that does not
map any known transport (what would anything SCTP/TCP/SSCOP
like DO with the congestion indication?), and precludes
useful mechanisms like ALF.  It is premature, and
incorrect to include normative text that doesn't do
anything.  I KNOW that ITU has permitted such things
before, but it is contrary to IETF practice, and is wrong.
Normative text should affect implementations, this does
not.  This debate should occur when a transport that uses
it is proposed, not before.

Brian

> From: [email-masked] [mailto:[email-masked]]
> To: [email-masked]
> Cc: [email-masked]
> In practice, you most often get better results when you
> aren't so pristine.
>
> Brian
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 09:49:09 -0400

It was in the MGCP draft, which figured substantially
into the Minneapolis text.  It was discussed on the list
for an extended time between Minneapolis and Oslo.
IETF does not require that text in the draft be proposed in
an I-D.

Brian

> Sent: Sunday, August 29, 1999 7:27 PM
> I'm trying to understand how ALF came to be in the protocol draft. Can
> someone point me to the draft which proposed this addition to the Oslo
> IETF meeting???
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > ALF is already optional in the MG.  But it has to be
> mandatory in the MGC to
> > guarantee interoperability.
> >
> > Consensus at the meeting was indicative, and the list has
> to confirm it.  So
> > far I have not perceived enough dissent to change my view
> of consensus on
> > this question.
> >
> > > From: Rex Coldren [SMTP:[email-masked]]
> > > Sent: Friday, August 27, 1999 4:46 PM
> > > To:   Taylor, Tom-PT [CAR:B901-I:EXCH]
> > > Cc:   [email-masked]
> > >       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.
> > >
> > > ...
> > >
> > >       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.
> > >
> > > 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: Tom-PT Taylor <[email-masked]>
Date: Mon, 30 Aug 1999 12:03:28 -0400

We have to make sure that it does, and in fact the section "Computing
retransmission timers" provides the necessary information.

> From: Ian Rytina [SMTP:[email-masked]]
> Sent: Monday, August 30, 1999 4:16 AM
> Hi Brian,
> Scott or Vern will correct me if I am wrong, but I remember
> that an important concern of the Transport A-D's during the
> work in Sigtran was that applications of UDP are not
> perceived as having higher priority than TCP applications,
> i.e. they do not flood the network at the expense of
> everything else.
>
> The upshot of this is that SCTP was steered towards specifically
> using the TCP congestion control mechanisms. Is the proposed
> ALF mechanism going to have the same safeguards ?
>
> Regards,
>
> Ian.
>
>
>
> Brian Rosen wrote:
>
> > Randall
> >
> > The attractiveness of ALF is that you can make your product as
> > complex, or as simple, as you want.  As defined, it requires only
> > that you send messages in UDP packets, and you retry based on some
> timers.
> > If you want to simply queue messages and treat the queue as FIFO,
> > that is fine.
> >
> > My implementation may take a more active approach, reordering, or even
> > modifying messages based on the current conditions.  That may allow
> > my product to be distinguished from your product, and yet they are
> > completely interoperable.
> >
> > If you like simple, reliable mechanisms, I recommend TCP to you, but,
> > as Van said at the meeting, we have quite a lot of experience that says
> > you can achieve substantially better performance in loaded networks
> > when you let the application monitor and react to network conditions.
> >
> > Brian
> >
> > > From: Randall Stewart [mailto:[email-masked]]
> > > Sent: Thursday, August 26, 1999 5:46 PM
> > > Christian Huitema wrote:
> > > > At 01:34 PM 8/26/99 -0700, Rex Coldren wrote:
> > > > >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.
> > > >
> > > > ... And for a good reason. ALF is not a standard, it is a design
> > > > philosophy, based on the idea that "network conscious"
> > > applications should
> > > > really have direct access to the network information, not
> > > delegate that
> > > > task to a generic transport interface.
> > > > Christian Huitema
> > > Hmm..
> > >
> > > I think that we could go with this... but why not have the
> > > "network conscious" application fire off IP packets. No need
> > > to bother with UDP... it just adds an extra layer... and maybe if
> > > it is real aware, it could fire out ether-net frames at a even lower
> > > level, and thus not have to put up with any queueing that the lower
> > > layer drivers/streams are putting out.. This way it could get the
> > > aborts/reset/frees to the real head of the line....
> > >
> > > And since most applications are CPU and Memory conscious, how
> > > about the
> > > O/S? Could not a smart application better utilize the memory of the
> > > machine
> > > or the CPU instead of letting the MMU or Scheduler in the O/S
> > > get in the
> > > way?
> > >
> > > Layers are put in for a reason, they simplify the task of writting the
> > > application.
> > > And provide a way to uniformily re-use hard to implement
> > > concepts, such
> > > as
> > > congestion control, fault management, memory management, Bus
> > > arbitration,
> > > scheduling ... et.al...
> > >
> > > It is true that a application can improve or better utilize resources
> > > if it takes complete control of them, however there is a price to pay
> > > for this..... do we want to pay this price is the real question... if
> > > the
> > > answer is yes... then maybe the application area and the
> > > transport area
> > > of the
> > > IETF should be merged together? It becomes the next logical step if we
> > > firmly
> > > believe that ALF is the future...
> > >
> > > I am afraid though that I am to old fashion for this
> > > besides.. all I can
> > > visualize
> > > when someone says "ALF" is a small fat brown dogish looking alien that
> > > was on
> > > a TV show...
> > >
> > > It just does not work for me... :-) maybe we could find a
> > > better name at
> > > least...
> > >
> > > R
> > > --
> > > Randall R. Stewart
> > > Member Technical Staff
> > > Network Architecture and Technology (NAT)
> > > 847-632-7438 fax:847-632-6733
> > >

---

From: "Lehecka, Gary R (SAIC)" <[email-masked]>
Date: Tue, 31 Aug 1999 10:35:23 -0400

Hi,

If I remember correctly,
the way this all came about (at least on the mailing list) was:

1.  IETF MEGACO's Underlying transport had to be an IP STANDARD.
Only qualifying IP STANDARDS are/were:  UDP and TCP
It was acknowledged that the standard could be amended in the future to
support other transports.
(SIGTRAN's current FUTURE candidate is Signaling Control Transfer Protocol -
SCTP - not a STANDARD yet).

2.  In order for MEGACO to work on any transport there needs to be
APPLICATION logic for retransmissions, timers, etc.

Application Layer Framing "ALF" might be more appropriately called datagram
transport "framing".
Maybe there is an equivalent stream transport "framing", buried in the TCP
sections of the draft protocol document.

datagram transport "framing" is REQUIRED no matter which (connectionless)
datagram transport is used.
stream transport "framing" is REQUIRED no matter which (connection-oriented)
stream transport is used.

There has to be a better word than "framing", any suggestions?

For ITU H.248 purposes, layering MIGHT make it easier to mix and match.
For IETF MEGACO purposes, as Brian Rosen has said,
there is no reason to add another layer NOW for something that does not
exist YET,
MEGACO can be amended later if need be.

3.  As had been suggested before,
If you want H.248 to be structured with layering,
author and submit a amended draft document,
rather than everyone arguing on the mailing list and making no progress.

Thanks,
Gary Lehecka
[email-masked]
BP  250 - 3671
US  ( 216 )  586 - 3671
> ----------
> From:         Tom-PT Taylor[SMTP:[email-masked]]
> Reply To:     Tom-PT Taylor
> Sent:         Sunday, August 29, 1999 6:05 PM
> To:   [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 1999 16:44:52 -0400

Christian

We seem to be having a problem with English.

If the interface is normative, then every implementation
must follow it exactly as written.  In this case, I would
have to find a place in the code where there was something
that conformed to the transfer primitive, and there must be
something that conformed to the congestion indication.

Suppose my implementation does not have a congestion
indication, with a 0-10 value.  Suppose it returns the
average delay time to get a message through from whatever
I use to request a transfer.

Am I conformant to the current draft?  This question has a
yes/no answer -- I am conformant, or I am not conformant.

If I am conformant, the layer definition does not define
implementation and is informative - the words do not convey
a conformance requirement, they are merely illustrative.

If I am non conformant, the layer definition does define
implementation and is normative - the words state what I
must do in my implementation.

If it is normative, and its use is required to claim
conformance, then I should be able to define a conformance
test for it.  Is that what you advocate?

We clearly need some normative text around transport.
There are aspects that we have decided all implementations
must conform to.  These aspects are externally visible.
For example, requiring that MG implementations not all hit
their MGCs simultaneously if they all happen to restart.

I'm not afraid of having a couple of lines here and there
that are informative (implementations may wish to consider
....), but not a page and a half of text that may or may
not illustrate how some undefined transport might interface
to the protocol.

I clearly understand the distinction between a primitive
and an API.  We aren't arguing that.  I'm also agreeing
that there isn't any magic in protocol design, although
there is an art to describing a protocol in a clear manner
which does not constrain implementations and yet produces many interoperable
implementations.  I would go so far as
to say that most protocol definitions are not clear and
they do unnecessarily constrain implementations.  Trying to
argue that there are lots of bad protocol documents out
there and so we should be as bad is not a very good
argument to me.

Brian

> Sent: Tuesday, August 31, 1999 12:31 AM
> 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
>
>
> Brian Rosen wrote:
> >
> > 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
> >
> > > Sent: Monday, August 30, 1999 7:10 AM
> > > 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
> > > >
> > > > > Sent: Sunday, August 29, 1999 7:44 PM
> > > > > 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
> > > > > > TCP had a strong consensus.  SCTP was discussed, and there
> > > > > was, at that
> > > > > > time, no consensus.
> > > > > >
> > > > > > for.  It is whether defining an abstract layer to describe
> > > > > the interface
> > > > > > interface between protocol and transport.  It is strictly a
> > > > > convenience for
> > > > > > describing transports.  Not all transports are, or will be
> > > > > described using
> > > > > > this abstraction."
> > > > > >
> > > > > > > From: Rex Coldren [mailto:[email-masked]]
> > > > > > > Sent: Thursday, August 26, 1999 4:35 PM
> > > > > > > standard.  I also note that
> > > > > > > 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:
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > > > From: John Segers [mailto:[email-masked]]
> > > > > > > > > > > > Sent: Thursday, August 26, 1999 3:38 AM
> > > > > > > > > > > > To: Brian Rosen
> > > > > > > > > > > > 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: "Drage, Keith" <[email-masked]>
Date: Tue, 31 Aug 1999 16:56:51 +0100

This thread seems to be following a total misunderstanding as to why
primitives exist in protocol definitions in the first place.

Primitives are there as an abstract concept of what the layer above can
initiate / be presented with, and similarly for the layer below. Behaviour
of the protocol implementation is then defined in terms of the primitives
and the PDUs, rather than in terms of the PDUs at the above layer, the below
layer and the PDUs at the layer under definition.

You cannot define a protocol solely in terms of the PDU behaviour at the
protocol layer itself. If you do this, you will get all the right responses
from the remote end, but the remote end will not necessarily do what you
asked it to.

Unless you want to make the primitive interface an open interface, there is
no need to implement the primitives. But because they define the behaviour
of the protocol, they do need to be normative, and therefore in the main
document. What you do need is some accompanying text that then gives the
status of the primitive definitions and the requirements on implementations
to support them. By making them informative, you simply waste the space
where you document them.

Of course, if you have no layering, and merge the transport and the
application completely, then you have no need of primitives, but who wants
something that is totally monolithic in this manner.

Keith Drage
Siemens Communications Limited

> Sent: Monday, August 30, 1999 8:57 PM
> You want to MANDATE that EVERY implementation of a non-IP transport have
> the
> That was what got me to the idea that you advocated an abstraction, not a
> conformance requirement.
>
> > A compromise would be easy if one was put forward. I don't see moving
> > I however I think we saw that both solutions can live together. This
> > 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
> > Its not an observable interface because there's nothing going across a
> > 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 would like the layering section remain pretty much as is. I've
> > > > do NOT want it moved to an INFORMATIVE annex because it won't be
> > > > My original sentiment (which I believe Chip expressed) was that
> > > > different transports could exist (in harmony) if the transport was
> > > > in the document. I don't see why one should preclude the others.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Brian Rosen wrote:
> > > > >
> > > > > > 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?.
> > > > > >
> > > > > > trying to make it do so.  If we allow one exception to this
> > > > > > rule (e.g.-ALF), we
> > > > > > separated.  ALF does not do that.  It does the opposite.  It
> > > > > > should not be a topic
> > > > > > > I don't think the issue here is for or against using SCTP
> > > > > > or other transport
> > > > > > > us how you can separate ALF completely from MEGACOP/H.248?
> > > > > > We all will see whether
> > > > > > > it makes sense.
> > > > > > >
> > > > > > > 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
> > > > > > > >    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
> > > > > > > > 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
> > > > > > > > > > 1. E911 - 12 calls are queued in buffers, network is
> > > > > > busy and a 911 call
> > > > > > > > > > 3. 30 messages are queued, some of them "Adds", some
> > > > > > subtracts.  A
> > > > > > > > > > The first one may turn out to be a requirement, and
> > > > > > that may FORCE
> > > > > > > > > > > lead to a sufficient reduction in traffic, in the
> > > > > > presence of media
> > > > > > > > > > > John Segers                                  email:

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 31 Aug 1999 21:14:24 -0400

Basically the transport layer interface proposal is an attempt to make the
protocol transport-independent in the sense I understand it.  However, I
think it is overkill.  I would suggest that we specify that the protocol is
designed to run over two types of transport.

Type 1: reliable (error-free, loss-free, unduplicated) datagram service,
including congestion control.  TCP augmented by RFC 1006 TPKT is an example
of such a service.  There should be one section of the document defining how
Megaco/H.248 uses reliable datagram service.  I'm wondering whether we
require this transport to also be sequence-preserving.

Type 2: unreliable datagram service, where reliability, sequencing, and
congestion control are the responsibility of the Megaco/H.248 protocol
layer.  This is what people mean by ALF in the present discussion.  There
should be a second section describing the required characteristics of
implementations which use unreliable datagram service.

AFAIK there is no difference on the wire at the Megaco/H.248 level between
the two approaches; the differences are entirely in behaviour at the two
ends.

> Sent: Tuesday, August 31, 1999 4:45 PM