Subject: Transport layer interface

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

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: Chip Sharp <[email-masked]>
Date: Wed, 18 Aug 1999 18:11:46 -0400

I believe the only changes made to the IP transport section are the
addition of the text
"The sending of a message is equivalent to a transfer.request.  The receipt
of a message is equivalent to a transfer.indication."

and the deletion of the Piggybacking section that seemed to be
MGCP-specific and not applicable to megaco.

There is a note in italics in Section 6.6.4 that needs to be removed.

The rest of the modeling and transport stuff was for the non-IP transport
(which is still to be defined).

At the time I didn't think it did much harm although I didn't see the need
for it.  The IP transport works fine without a transport sublayer. Since I
wasn't interested in non-IP transport of H.248 it didn't really matter to
me much.  Of course, we were operating on very little sleep at that time.

If you see something that needs changing please let me know.

Chip

>I don't think we will miss it.

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