[e2e] time for a presentation layer?

[Scott Michel]

On Mon, Jun 18, 2001 at 12:23:55PM -0700, Eric A. Hall wrote:
> > Correct me if I'm misinterpreting you, but isn't that already done at
> > the transport layer or are you arguing for a more general purpose foo
> > that implements reliability such as various flavors of FEC?
> 
> I'm suggesting that the argument for strong-v-weak reliability is probably
> an argument for negotiable reliability extensions (which could include FEC
> I suppose) on a per-connection basis.

Most of the time, this is known a priori. Sure, the application
itself may be willing to negotiate with receiver as to what kind
of reliability it is willing to handle and whether the receiver is
willing to support it. Some of these semantics are already built
into the underlying transport. Also, the framework would have to very
carefully define what it does when negotiation fails.

As a general framework, this proposal is fine if you're talking about pure
unicast in a peer to peer situation.  Consider an application where
there exist intermediate peers between a source and remote peer,
where one has store-and-forward semantics in a larger peer network.
You now have the potential problem of keeping presentation layer
state at these intermediate/transit peers. You might also have to
negotiate presentation layer details through all intermediate peers
on the path to a remote peer or decide to do it only from the source
to the first transit peer or ...

For example, many of the applications that I deal with professionally
(as opposed to "studentially") have very strict criteria with
respect to what loss they are willing to tolerate. Consequently,
either the reliability is built into the application itself or
constraints are imposed on the line's BER (often done but a short
sighted solution IMNSHO.)

> I have argued in various places that TCP and UDP provide session-layer
> services as part of their connection-management services. I have also
> argued that the historical character apps use a default limited
> presentation-layer service in the form of common bit-ordering, charset,
> and line termination signals. It would be nice to go beyond that at some
> point down the line.

I'm not sure I can agree with you on this particular point. TCP has
some "session" semantics from the perspective that for a particular
connection you have certain gauruntees on behavior.

In terms of the presentation issues between terminal emulators, it is
just as easily argued that they are merely a matter of protocol that
the application implements. Just because these same issues crop up in
other applications doesn't necessarily justify a presentation layer
because one size often doesn't fit all (which is one reason why UDP
exists.)

> > It might be useful to define a set of functionality that coalesces the
> > various points you enumerate as a general framework for application
> > "presentation" issues. Eventually, it will become reasonably monolithic
> > and then a de-facto layer.
> 
> It would probably only be *really* useful as part of a new transport
> protocol, where the ends negotiated the desired extensions during the
> connection-setup handshake. It could be glued onto existing protocols, but
> it would be fairly ugly. One could imagine an ESMTP extension for
> negotiation compression and the like, and maybe for negotiating numeric
> formats (for the SMTP response codes), but it would be pretty ugly in
> comparison to a codified option exchange provided during the transport
> setup routines.

I'm not sure that a transport protocol is necessarily the right answer
here - TCP and UDP are very sufficient. Transport is just a way for the
app to get its bits from one place to another.

IMHO, the direction this thread should take is what is necessary for
inter-peer communication and talking about ways of subdividing the
application layer to provide useful features like the ones you're
proposing (and adding store-and-forward behavior, which is my topic.)


-scooter