Subject: Re: Transport layer interface

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 18 Aug 1999 17:20:31 -0500

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: Rex Coldren <[email-masked]>
Date: Wed, 18 Aug 1999 16:42:49 -0700

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

---

From: Chip Sharp <[email-masked]>
Date: Wed, 18 Aug 1999 22:20:05 -0400

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

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

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

---

From: Hong Liu <[email-masked]>
Date: Thu, 19 Aug 1999 10:26:26 -0400

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Aug 1999 15:15:34 +1000

I believe the requirements for transport <draft-ietf-megaco-reqs-05.txt>
Section 9 are transport agnostic that is it doesn't define IP or non-IP
singalling transport. Therefore both non-IP and IP are valid and fit
within H.248/megaco requirements.

I believe this section also touches on a layered approach. I don't
believe the Oslo meeting looked at non-IP transport when they made their
decisions.

Christian