Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Wed, 25 Aug 1999 17:55:25 -0400

There are two variables:
    IP - non IP
    ALF - non ALF
There are 4 combinations:
    IP ALF
    IP non ALF (e.g. TCP)
    non IP ALF (e.g. Megaco over raw AAL5, which is ordered but not
reliable)
    non IP non ALF (e.g. Megaco over something like SSCOP)

The layer, as defined, is applicable only to one of these scenarios - non
IP, non ALF
The other three scenarios are possible (not implying that ATM ALF, for
example,
is the ONLY way to do Megaco over ATM, but asserting that it makes sense,
and should not be precluded).

Let me expand this latter point.
If I have invested effort in making my MGC capable of responding to
congestion in the network
in clever ways by exploiting ALF techniques, I desire to apply that
capability to any
non-IP network.  In particular, any code that would, for example, reorder
message
transmission in the face of congestion is a very useful capability, and is
applicable to
transports like ATM.  I am not arguing that we should REQUIRE something like
ALF,
but we should allow it (I'd even say encourage it, since it results in more
resilient
implementations).

The document makes clear that a non ALF protocol can be easily described
without
the layer definition.  See the TCP section.  It is clear that any other
transport that
provides ordered, reliable service could look virtually identical to that
text, using
SSCOP, as an example, would be just like using TCP.

There are no non-IP protocols defined in the document.  In EVERY other
instance
of features that MAY appear in the future, the text is terse: For future
study

The layer, as defined, has weaknesses.  It has a naive view of congestion,
for example.
It is very likely that the layer definition would have to be modified for
every non-trivial
transport mechanism.

I claim therefore:
    The layer is applicable to only 1/4 of the design space
    The layer does not apply to any implementations defined
    The layer is not required to get an unambiguous, simple description of a
        protocol that provides ordered reliable delivery
    The layer, as defined, is probably not adequate

So I conclude that it should be removed and replaced with a: For Future
Study

Brian

-----Original Message-----
From: Rex Coldren [mailto:[email-masked]]
Sent: Wednesday, August 25, 1999 4:54 PM
To: [email-masked]
Subject: Re: Transport layer interface

Stephen has put it very well.  I will reiterate his statement because I
agree with it, and then I
will try to summarize where we are at on this thread:
I would support separating the transport from the ALF and non-ALF
discussions, as there are certain reliable signalling transports which do
not require ALF, as such it would be reasonable to not require ALF.
It seems to me that it only makes sense to use ALF if you are trying to use
UDP for transport.
If you are using TCP you would not need ALF.  If using SCTP (someone will,
someday), you
would not need ALF.  If you are using ATM transport it appears you would
also not need it.
It seems like the transport layer interface that Mr. Groves recommends would
not be useful for
the UDP + ALF case, but it might be useful for the others.  The bottom line
is that it appears
that transport (e.g.-UDP, TCP, SCTP, ATM AALwhatever) IS a subject that
should be
discussed independent of ALF and a generic transport interface.  And I see
that all of these
need to be in the specification in some fashion.  Perhaps ALF and the
transport layer interface
are appendix/annex material?
Rex
Stephen Terrill wrote:
Hi Brian,
I am not sure that I understand proposal here.  I believe that it is the
functions which can be supported by the protocol which is interesting, and
the transport of the protocol should be able to be adapted to different
enviroments.  For this reason, I liked the way in which the H.248/Megacop
was developed (by concentrating on the functionality first, and not being
two concerned with the signalling transport).  Now it seems that this work
is being undone by mixing the transport issues with the protocol itself.
I would support separating the transport from the ALF and non-ALF
discussions, as there are certain reliable signalling transports which do
not require ALF, as such it would be reasonable to not require ALF.  Based
on this do I understand that you are suggesting we extend the signalling
transport layer to include the IP transport?
Regards,
..//Steve
Brian Rosen wrote:
> 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?
>
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Sunday, August 22, 1999 8:53 PM
> > To: [email-masked]
> > Subject: Re: Transport layer interface
> >
> >
> > 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.
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:[email-masked]]
> > > > Sent: Friday, August 20, 1999 3:47 AM
> > > > To: [email-masked]
> > > > Subject: Re: Transport layer interface
> > > >
> > > >
> > > > 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
> > > > > >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.
> > > > >
> > > > > I believe that we agreed in Berlin that this could be done.
> > > >  It is a matter
> > > > > of defining the transport mechanism.
> > > > >
> > > > > >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.
> > > > >
> > > > > 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
> > > > > >this I think is reflected in the specification
> > > > >
> > > > > 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
> > > > > >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.
> > > > >
> > > > > 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
> > > > > >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.
> > > > >
> > > > > 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.
> > > > >
> > > > > >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
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Hong Liu [mailto:[email-masked]]
> > > > > > > > Sent: Thursday, August 19, 1999 10:26 AM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: Re: Transport layer interface
> > > > > > > >
> > > > > > > >
> > > > > > > > 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,
> > > > > > > > >    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: John Segers <[email-masked]>
Date: Thu, 26 Aug 1999 09:38:01 +0200

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