Subject: Re: Transport layer interface

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 30 Aug 1999 14:37:54 -0500

There is the valid point that Application Layer Framing (ALF) doesn't
reinvent all of the lower layers of the protocol stack (though in principle
it could).  The particular flavour of ALF being documented in H.248 uses UDP
as the next layer down.  You are correct that if someone wants to use a
non-UDP transport the characteristics of that alternative transport would
have to be reviewed and the timers for ALF retuned.

There is no real question of the application manipulating transport queues;
instead, the application controls retransmission policy.  The SCTP design
team recognized this by providing for recall/message timeout at the API but
not the protocol level.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Monday, August 30, 1999 7:09 AM
> To:   [email-masked]
> Subject:      Re: Transport layer interface
>
> Previous emails in this thread have alluded to where the queuing and
> prioritisation is done in applications. The application would know the
> order and priority of commands before it sends it to the transport
> buffer.
>
> Its tough ask of any application to be able to change the
> order of messages in a transport queue which I guess would be sitting
> there for less than a few milliseconds.
> Transports have congestion control so I guess then we would have to
> redefine them for ALF?
> Having an application messing around with transport queues is tightly
> coupling transports and applications. Everytime you port an application
> to a new transport then you have to re-implement ALF and play around
> with the transport stacks.
>
> With layering you let the transports do what they are designed for, let
> the Applications handle errors as they know best. You define the
> information between them ie. primitives/API to let them both evolve
> indepenently.
>
> Christian
>
> Brian Rosen wrote:
> >
> > > I still don't subscribe that a layered transport precludes ALF, the
> > > application of course knows best but it communicates with the
> > > transport
> > > through an interface.
> > >
> > Here is an example:
> > The layer, as proposed, has a "transfer" primitive.
> > It does not have any mechanism that would affect the
> > order of message transmission AFTER the transfer primitive
> > is invoked.  Yet, virtually all known transports have
> > queuing at their interface.  ALF would want to change the
> > order of messages in this queue.
> >
> > If you define the transfer primitive to be "immediate
> > send", so that the application manages the queue entirely,
> > then any mechanism the transport does have for
> > congestion management or error recovery could not operate.
> >
> > Brian

---

From: Randall Stewart <[email-masked]>
Date: Tue, 31 Aug 1999 14:32:27 -0500

See my comments below:

> team recognized this by providing for recall/message timeout at the API but

Has discussed at Santa Clara...

It is quite easy to add a time-to-live and priority in a message
in SCTP at the api interface. But once a TSN (Transport Sequence
Number) is commited and the UDP send is done, it usually
involves more work then is worth (and more congestion adding
messages) to try to recall/stop the message. In fact there
is no way one can truely assure that if you say STOP
that the message still won't get there (once the send is done
i.e. the TSN is commited) that is.

This is why we added(will add in the next draft) the ability in the
API to have the TTL value. There will be some description in
the document as well... but it does not really effect the
bits on the wire...

In fact in reality if a implemenation wanted to have re-ordering
in its SCTP it could be allowed... it would be a rather hairy interface
but there is, nothing from stopping it ... again it does not effect
the bits on the wire...

I do think that the model we elected is a wise one, set a TTL or
even priority and then have the TTL/prioirty kick in when the
delays in transit begin to occur (i.e. congestion). This is really
the only time when you want to start digging around and changing
things ... either there is congestion or the peer is dead...

In the later case nothing you can do matters... in the former case
a simple TTL will remove most of the messages that are no good
and kick them back to the application to either resend or
reprioritize what it wants to do.

I don't see in the absence of congestion that one could effectively
change the queues around... a app would need to make the call to
change it very very fast since if things are working you will
probably see most messages commited to transport in a few
milliseconds...

In my view, having SCTP under the application gives it all the power
of ALF to change things, but also adds the protection of congestion
control.  In fact how does one detect congestion with ALF? How does
one detect recovery from congestion? I bet you will end up adding
congestion control concepts from RFC2581 and in the end, you will look
a awful lot like SCTP or it will become so complicated that you will
not be able to implement it or it will take you a long long time to
get through a interoperability test (has Dave Oran pointed out
earilier).

Having a layer adds a nice clean interface.. there is nothing stopping
plain old ALF from having a layer, and create a nice little interface
to re-arrange transport queues.. . why not. This then could
make both sides happy..

--
Randall R. Stewart
Member Technical Staff
Network Architecture and Technology (NAT)
847-632-7438 fax:847-632-6733