[e2e] time for a presentation layer?

[Eric A. Hall]

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

First, just to be clear, I'm not proposing anything. Such a layer would
most likely only be useful with a new transport. It could be used with new
apps on the existing transport (as app-requested transport options), but
it would probably be too ugly to be successfully deployed widely, so new
transport is where it makes the most sense.

Anyway, in a store-and-forward environment, each hop should be treated as
e2e. In that context, each hop could negotiate whatever features were
required for the connection. Perhaps a high-speed LAN would choose not to
negotiate compression since it would add e2e latency, while a cellular
network may choose to add compression in the hopes of reducing cumulative
latency (less data, more processing).

> You now have the potential problem of keeping presentation layer
> state at these intermediate/transit peers.

Why? The data that goes over one link would only depend on the
characteristics of that link, not the characteristics of every other link
in the global network.

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

I agree that they are implemented as monoliths, but that is because of
several factors, including the principle fact that the standards specify
them as such. Yet they still exist as functional components. Systems still
have to perform data conversion and whatnot before the data is processed,
for example. In this regard, the layers exist even though they are not
specified or programmed as independent layers. Moreover, there is very
little motivation to change the model in the current environment, given
the simplistic nature of the defacto presentation layer.

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

I'm not suggesting that transport should be stretched upwards, or
conversely that applications should be shrunk. What I am saying is that
the handshake is probably the most efficient place to negotiate the
extensions.

We agree that the session and presentation layers do not exist as
malleable components, and that they are in the grey space between
transport and application, although we disagree somewhat on where exactly
the layers are. If you buy my argument that TCP and UDP already provide
the session layer services (connection setup, teardown, etc) then really
what I am suggesting is that the session-layer negotiation can also
provide presentation-layer negotiation services. Not an extension of the
transport, but a sub-negotiation of the session.

The logic for making it a separate malleable layer is to maximize
application efficiency, particularly in development and deployment. How
difficult is it so add a new service like encryption or compression to a
standardized layer, versus how difficult is it to extend every application
protocol semantics independently? Take your pick: STARTTLS for SMTP, or
code 0x2F (example) requested during handshake. One is difficult,
expensive, slows deployment, and impacts performance, the other is four
bytes passed during the transport handshake.

Repeat, this is not a proposal.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/