[e2e] time for a presentation layer?

[julian_satran at il.ibm.com]

Eric,

The trouble with transport options is that there so precious few of them
and adding one involves taking care
that nothing gets broken anywhere.
Encapsulating the transport in another header just extends this space.  As
for how deep in the stack you
have to make the information visible you may choose to do it in the
transport just after the encapsulation
if the table approach violates what you sense as "good layering".
Some of the options are anyhow "constant driven" (like the integrity
checks).
In IPV6 it looks like the end-to-end options are a perfect match for this
type of extension.


Regards,
Julo

"Eric A. Hall" <ehall at ehsco.com> on 09-07-2001 16:07:16

Please respond to "Eric A. Hall" <ehall at ehsco.com>

To:   Julian Satran/Haifa/IBM at IBMIL
cc:
Subject:  Re: [e2e] time for a presentation layer?





julian_satran at il.ibm.com wrote:
>
> There are at least to reason why an IP option (even in the disgust of a
> separate protocol header between IP and transport) looks better:
>
>    available for any transport

Is it really needed for UDP? I mean *really* necessary? Do DNS and TFTP
and NTP really need the extension capability? I can see how they would
benefit from it. Certainly things like robust error-detection, compression
and encryption would be nice to have, but for a one-off, unreliable
datagram, is it really necessary?

Moreover, should no-UDP-options penalize the other transports which do
provide option negotiation? It would be nice for those apps to have access
to such a set of services, but isn't the datagram model one in which the
apps are responsible for all of this anyway?

> And several disadvantages:
>
>    Negotiation in-band is difficult to sync (like IKE and IPSec) (not
>    impossible though)
>    Negotiation out-of-band requires (probably) a separate protocol

Also, the applications have to communicate with the network directly,
which is too deep in the stack. They shouldn't be going any deeper than
the transport. The only real way to solve this is to build a control
service, which has its own problems.

Maybe leaving UDP behind is the best approach in the long run.

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