[e2e] time for a presentation layer?

[Scott Michel]

On Mon, Jun 18, 2001 at 02:33:49PM -0700, Eric A. Hall wrote:
> > 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.

All discussions start with some proposistion. In this case, I think we're
discussing the merits of a presentation layer (the proposition.) I think
it was something you proposed for discussion.

But enough of beating semantics, because it'll quickly start looking
like an IETF WG list or a legal convention... :-)

I also agree with David Reed's assessment, if I hadn't been clear
enough already.

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

In some cases, yes, this is the desireable approach. In other cases,
perhaps not. It's just an use case to consider. But continuing into
the weeds, perhaps the adaptations required should be done by the
transit peers themselves or across path segments and not just hop-by-hop
or from source peer to destination peer?

Much depends on what the application wants to do and I think we've
identified a spectrum of presentation issues.

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

Vide supra.

Also, as a side thought, what about negotiated "switching labels"
(I hate the buzzword, but it seems to fit) to avoid forwarding
lookups at each peer? That incurs state along the path through the
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.

Not necessarily. Mark Yarvis and Peter Reiher at UCLA have been doing
a considerable amount of work on a system called Conductor that does
in-transit adaptations which contradict these assumptions. Link-by-link
or hop-by-hop planning often misses better adaptation plans that span
across multiple peer segments. Peter Reiher also has a project called
PANDA with similar goals (http://fmg.cs.ucla.edu/panda/).

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

No, I'm not really buying that argument. There is connection setup and
teardown, seperate from application session state which I don't think
can necessarily be generalized. Presentation probably can be generalized
into a useful set of library components with specific network
representations (although that's already done if you use Sun's XDR.)

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

Depends on where you implement the handshake as to how expensive the
development cycle is, and worse, given the bazaar (or bizarre?) nature
of open source, the number of competing implementations of the same
wheel. But I do tend to agree with you that it might be useful, I'm
just not sure that "transport protocol" is the right term.

> Repeat, this is not a proposal.

:-) :-)


-scooter