Re: "End-to-end" paper

At 12:24 AM 17-05-2001 -0700, Nathan Myers wrote:
>
>For those of you who have missed it, here
>
>http://www.google.com/search?q=cache:web.mit.edu/Saltzer/www/publications/e
ndtoend/endtoend.pdf+clark+end+to+end&hl=en
>
>is the paper some of us mention, "END-TO-END ARGUMENTS IN SYSTEM DESIGN"
>by Saltzer, Reed, and Clark.
>
>The abstract is:
>
> This paper presents a design principle that helps guide placement of
> functions among the modules of a distributed computer system. The
> principle, called the end-to-end argument, suggests that functions
> placed at low levels of a system may be redundant or of little value
> when compared with the cost of providing them at that low level.
> Examples discussed in the paper include bit error recovery, security
> using encryption, duplicate message suppression, recovery from
> system crashes, and delivery acknowledgement. Low level mechanisms
> to support these functions are justified only as performance
> enhancements.
>
>It was written in 1981 and is undiminished by the subsequent decades.
>

Maybe I don't understand the paper.

The end-to-end argument might be true if taking the monolithic approach. I
find more useful ideas gleaned from the RFCs, TCP/IP and the OSI 7 layer
model: modularity, "useful standard interfaces", "Be liberal in what you
accept, and conservative in what you send" and so on.

Within a module I figure the end to end argument might hold, but the author
keeps talking about networks and networking.

SSL and TCP are useful. The various CRC checks down the IP stack to the
datalink layer have their uses too.

By splitting stuff up at appropriate points, adding or substituting objects
at various layers becomes so much easier. People can download Postgresql
over token ring, Gigabit ethernet, X.25 and so on.

Splitting stuff up does mean that the bits and pieces now do have a certain
responsibility. If those responsibilities involve some redundancies in
error checking or encryption or whatever, so be it, because if done well
people can use those bits and pieces in interesting ways never dreamed of
initially.

For example SSL over TCP over IPSEC over encrypted WAP works (even though
IPSEC is way too complicated :)). There's so much redundancy there, but at
the same time it's not a far fetched scenario - just someone ordering
online on a notebook pc.

But if a low level module never bothered with error
correction/detection/handling or whatever and was optimized for an
application specific purpose, it's harder to use it for other purposes. And
if you do, some chap could post an article to Bugtraq on it, mentioning
exploit, DoS or buffer overflow.

Cheerio,
Link.