Subject: Re: Transport layer interface

From: Qiaobing Xie <[email-masked]>
Date: Tue, 31 Aug 1999 10:55:20 -0500

Tom, maybe in the next meeting, a hum db meter is in order :-)

What mostly concerns me is the congestion control (re-trans timer backoff
is just a piece of it) if ALF is used, as Ian Rytina has pointed out earlier.

So far the discussion on this thread has not paid much attention to this
issue. People've talked alot on how ALF can work for megaco, but not much
on how to show that megaco/ALF will be competing fairly with other Internet
entities for bandwidth, especially in the face of a congestion.

>From my experience with IETF, a clearly defined and proven congestion
management strategy seems a mandate for any protocols to be issued as an
Internet standard. My undertanding (may be wrong) of this rule is to
maintain the integrity of the Internet. However, this concern is
nonexistance in ITU, since ITU assumes that mecago will be used always on
provisioned networks, not on the public Internet, while IETF standards
are only issued for the big "I" internet. This policy conflict btw ITU and
IETF makes me think that ALF, without congestion control, makes more sense
to be standardized in ITU, but not in IETF.

-Qiaobing

On Aug 29,  6:05pm, Tom-PT Taylor wrote:
> Subject: Re: Transport layer interface
> If I get persistent opposition that wasn't at the meeting, I'll have
> evidence that the consensus suggested by the hum at the meeting is not
> holding on the list.  In the meantime, I'll recall to you that the sequence
> of hum-votes was as follows:
>  -- TCP alone: modest support
>  -- ALF alone: well, one supporter has a very loud hum.  A reasonable number
> of people gave him accompaniment.
>  -- both TCP and ALF: definitely the loudest hum, and solid enough to appear
> to constitute a consensus.
>
> > -----Original Message-----
> > From: Mike Buckley [SMTP:[email-masked]]
> > Sent: Sunday, August 29, 1999 12:04 PM
> > To:   [email-masked]
> > Subject:      Re: Transport layer interface
> >
> > Brian,
> >
> > >ALF isn't up for discussion -- it's in there.
> >
> >
> > I thought the purpose of the mailing lists was to hold a discussion?
> >
> > Mike
> >
> >
> > ____________________ Begin Original Message
> > ___________________________
> > Date: Sat Aug 28 16:46:22 -0400 1999
> > From: internet!ENG.FORE.COM!brosen (Brian Rosen)
> > Subject: Re: Transport layer interface
> > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
> > Content-Type: Generic-Text
> > Content-Length: 3411
> >
> > Yeah, I understand.
> >
> > The issue is whether we have this text that describes an interface that
> > doesn't exist, for a set of transports that aren't defined.  ALF isn't
> > up for discussion -- it's in there.
> >
> > I offered a compromise - make it an informative annex with an appropriate
> > disclaimer.  So far, no takers.
> >
> > Like many things, nice neat boundaries are very useful teaching devices.
> > In practice, you most often get better results when you aren't so
> > pristine.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Hong Liu [mailto:[email-masked]]
> > > Sent: Friday, August 27, 1999 2:19 PM
> > > To: [email-masked]
> > > Subject: Re: Transport layer interface
> > >
> > >
> > > Brian,
> > >
> > > I think Rex is entitled to have his opinion on this subject.
> > > But I don't think the intent
> > > of this thread is to remove ALF from the protocol spec.
> > >
> > > ALF is already there, and was shown to work in similar
> > > context as MEGACOP/ H.248. I
> > > believe it has EVERY reason to be in the protocol spec as it
> > > is. What else status you
> > > want than this?
> > >
> > > I don't think there was a consensus in Berlin to remove ALF.
> > > So there is no point in
> > > revoking what was agreed in Oslo.
> > >
> > > --Hong
> > >
> > > Rex Coldren wrote:
> > >
> > > > Brian,
> > > >    Well, clear and decisive conclusions from Santiago and
> > > Berlin have easily
> > > > been reversed so I expect that this one can be too.  ALF
> > > has no place in the
> > > > protocol spec.  It should be required to stand on its own
> > > as a transport mechanism
> > > > just as SCTP has been required to do.  Once ALF reaches the
> > > status required,
> > > > we can reference it from the H.248/MEGACO protocol spec.
> > > So far, I believe
> > > > ALF is probably far behind SCTP in achieving the status
> > > required for such
> > > > inclusion.  This is the normal way of doing things.
> > > >
> > > >    Now if you're really desperate to include this kind of
> > > thing in the protocol spec,
> > > > I think you need to bend a little and allow for other
> > > not-yet-standard concepts to
> > > > be included (e.g.-the transport layer interface, SCTP, etc.).
> > > >
> > > > Rex
> > > >
> > > > Brian Rosen wrote:
> > > >
> > > > > It was clearly and decisively concluded in Oslo that
> > > there was a consensus
> > > > > that ALF using UDP should be one of the transport
> > > mechanisms.  Similarly,
> > > > > TCP had a strong consensus.  SCTP was discussed, and
> > > there was, at that
> > > > > time, no consensus.
> > > > >
> > > > > This debate is NOT about which tranports Megaco/H.248
> > > should be defined
> > > > > for.  It is whether defining an abstract layer to
> > > describe the interface
> > > > > between the protocol and some undefined, future, non-IP
> > > transport is
> > > > > appropriate.
> > > > >
> > > > > It has the curious characteristic that it's absence will
> > > not be missed -
> > > > > there are no protocols defined using it, and it's use or
> > > non use would not
> > > > > change externally visible behavior.  In particular, it is
> > > missing the
> > > > > following statement:
> > > > > "NOTE: The abstract layer DOES NOT define nor suggest an
> > > IMPLEMENTATION's
> > > > > interface between protocol and transport.  It is strictly
> > > a convenience for
> > > > > describing transports.  Not all transports are, or will
> > > be described using
> > > > > this abstraction."
> > > > >
> > > > > I'm in the mood for a compromise.  Suppose we take the
> > > text, add the
> > > > > disclaimer, and move it to an INFORMATIVE annex.
> > > > >
> > > > > Brian
> > > > >
> > >
>-- End of excerpt from Tom-PT Taylor

---

From: Rex Coldren <[email-masked]>
Date: Tue, 31 Aug 1999 13:03:17 -0700

Qiaobing,

The hum db meter is a good idea, but we need to make sure that it is not
mandated that rough consensus means a minimum db level.  We don't want
sparsely attended meetings to keep us from reaching rough consensus ;-)

I can't remember any talk about how the ALF mechanism will conform to
any standards for behaviour on the Internet.  Discussions have been centered
around the capability that ALF provides the application to deal with its own
congestion (e.g.-jump to the front of the queue, avoid waiting for responses,
etc.).  I have been told that ALF techniques have been used in several IETF
standards, but cannot say whether ALF itself behaves or whether the
application protocols that make use of ALF behave.

So, your point is valid.  If we're going to use application-level techniques like
ALF rather than standard transport protocols we'll need to consider things like
congestion management as part of our protocol development.

Rex