Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 1999 10:47:46 -0400

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 1999 08:15:10 -0700

I've never quite understood where the "transport
independent" folks are coming from here, both in
theory and in practice.

In theory, there are two separate axis:

o stream/datagram
o reliable/unreliable

This is true for every networking protocol that I
know about. It seems to me that the two choices we
made for IP in Oslo cover all 4 combinations:

stream/reliable: TCP model
stream/unreliable: ALF with "push" (or some other
                   mechanism to frame the messages)
datagram/reliable: TCP model
datagram/unreliable: ALF

Given this, it seems to me that even MEGACO over
reliable avian carrier transport could be
accommodated (it is left as an exercise to the
reader as to whether that is stream or datagram).
No matter what the underlying transport is, things
like timers, congestion, etc, etc still need to be
dealt with. Since we choose two different
protocols where those considerations must be
explicitly handled by the protocol itself, and the
other does those things for you, the remaining two
combinations should work as well.

In practice -- at least with something that uses
Berkeley sockets (or any equivalent), the main
difference is how the sockets are set up at
connection time. Things like recvfrom, sendto,
select, etc, etc are basically the same (except
for the sockaddr handling, maybe). The differences
between network types could pretty trivally be
vectorized for further efficiency.

Maybe Christian Groves can give us some help with
a specific example of what he thinks would be
extremely difficult or impossible to accommodate
over another network layer, because I honestly
don't see it. There's very little IP specific
stuff here which is a Good Thing since IP needs to
also handle IPv6 as well as IPv4.

                Mike

---

From: Christian Groves <[email-masked]>
Date: Thu, 19 Aug 1999 17:36:13 +1000

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

---

From: Chip Sharp <[email-masked]>
Date: Thu, 19 Aug 1999 12:18:35 -0400

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

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

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

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

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

> > > > > > I don't think we will miss it.

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

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 19 Aug 1999 18:53:42 +0200

Chip, others,

I guess this is the time when cross-posting to the APC mailing
list becomes a necessity.  Maybe someoen wants to summarize
and cross-post (I don't feel competent enough to do so on my own).

Stephan

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Aug 1999 14:08:12 -0400

>this I think is reflected in the specification

Uh?  Actually, the ALF approach would work just fine on top of AAL5.  This
is probably
the most portable of all approaches, since it only assume a basic datagram
delivery service
from the underlying transport.

Christian Huitema

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 19 Aug 1999 14:27:26 -0700

>general model is that there is no sensible way to abstract ALF out of the

Can you explain this? If MEGACO can work fine over TCP, why can't ALF be
abstracted? I kind of thought that was our main direction.

---

From: Chip Sharp <[email-masked]>
Date: Thu, 19 Aug 1999 18:08:19 -0400

Part of the procedures can be extracted (i.e., don't do the congestion
backoff stuff if running over TCP).
But abstracting it doesn't make sense to me in that it doesn't buy anything.

Chip

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 19 Aug 1999 16:27:30 -0700

It can buy you something if you don't wish to use ALF over a non-IP
transport. But since we don't have any real proposals for that, it's hard
to say now.

But abstraction is always a good thing in these cases since it buys you
flexibility. You don't want to hook layers too tightly together since it
makes it that much harder to swap protocols at a given layer.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Aug 1999 18:39:38 -0700

> abstracted? I kind of thought that was our main direction.

   Er, um, no.

   The A in ALF means "application".

   And it's not a bug, it's a feature.

                Mike

---

From: Christian Groves <[email-masked]>
Date: Fri, 20 Aug 1999 17:47:17 +1000

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.