Subject: Re: Transport layer interface

From: Qiaobing Xie <[email-masked]>
Date: Thu, 26 Aug 1999 11:15:35 -0500

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:
> Subject: Re: Transport layer interface
> 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
>
> > -----Original Message-----
> > From: John Segers [mailto:[email-masked]]
> > Sent: Thursday, August 26, 1999 3:38 AM
> > To: Brian Rosen
> > Cc: [email-masked]
> > Subject: Re: Transport layer interface
> >
> >
> > 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: Rex Coldren <[email-masked]>
Date: Thu, 26 Aug 1999 10:32:22 -0700

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

---

From: Hong Liu <[email-masked]>
Date: Thu, 26 Aug 1999 15:46:06 -0400

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

---

From: Rex Coldren <[email-masked]>
Date: Thu, 26 Aug 1999 13:34:35 -0700

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Aug 1999 16:44:01 -0400

At 01:34 PM 8/26/99 -0700, Rex Coldren wrote:
>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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 26 Aug 1999 16:46:13 -0500

> task to a generic transport interface.
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: Hong Liu <[email-masked]>
Date: Fri, 27 Aug 1999 10:18:03 -0400

Rex,

My comments below.

> of standardization within any active working group or is it an already published

Nobody has said that ALF is a standard. It is unfortunate that ALF is mistaken as such.
As Christian put it, it is a protocol design philosophy, just like layering, though they
are very different.

Again, let's don't bring SCTP into the mix. It is not essential to this debate.

> should allow them all (e.g.-include SCTP).

What requirement? Your arguement just did not follow through. Are you questioning the
value of using UDP+ALF as a transport mechanism? There are numerous applications out
there that have been running successfully using this approach.
Again, I don't want to mix the issue with SCTP.

> appropriate in a protocol spec than ALF is.

There are situations where layering makes sense, and there are situations where ALF makes
sense. MEGACOP/H.248 will be deployed in various contexts that have different transport
characteristics. I just don't buy the ONE SIZE FITS ALL argument.

Yeah, I am still teaching the seven layer model to my students...

--Hong