Subject: Duplicated functions (was: Current LINK snapshot available)

From: Dan Grossman <[email-masked]>
Date: Mon, 25 Oct 1999 18:05:02 -0400

> >2) > Duplicating these functions at the lower levels is at best
> >   > redundant, and can even be harmful.
> >This is a more extreme view than suggested in "End-to-End Arguments".  Try: 
> >"Duplicating these functions at lower layers should be done only when a 
> >quantifyable performance benefit can be achieved by doing so.  Otherwise, such 
> >duplication is at best redundant, and at worst counterproductive."
> 
> I left in my original wording, but added a statement about performance
> enhancements. This is how it now reads:
> 
> seminal paper "End-to-End Arguments in System Design" [SRC81]. This
> paper argued that many -- if not most -- network functions are best
> implemented on an end-to-end basis, i.e., at the higher protocol
> layers.  Duplicating these functions at the lower levels is usually
> redundant, and can even be harmful. However, certain low level
> functions can sometimes be justified as a performance enhancement.  An
> example would be link layer retransmission on an unusually lossy
> channel, e.g., mobile radio.
> 
I've thought about this over the weekend, and realized that there are often 
good reasons to have duplication, beyond just performance enhancement.

examples:   
-- one could argue that SONET protection switching is redundant with 
intra-domain routing protocols and behaviors, since both will recover from a 
failed link.  However, SONET (in a path switched ring configuration) can 
recover from many kinds of faults in under 30 ms, while OSPF takes on the 
order of 30 seconds to reconverge.  If there is an objective of  99.999% 
network availability, clearly the latter will not do.  So, there's a case to 
be made for duplication of function as an availability enhancement.  

-- One could argue that putting encryption into cable modems and cable modem 
termination systems (aka cable routers) is redundant with IPSec.  However,  
IPSec cannot protect against attacks at the link layer.  Also, since DES 
operates on fixed-size blocks, and the standards for cable data links have 
short headers, it wouldn't make much sense to just encrypt the link headers 
and not the data. There's also the problem that IPSec is not widely deployed, 
in either end-to-end mode or tunnel mode.  Obviously, some degree of 
confidentiality (at least commensurate with point-to-point links) is needed 
even if more encompassing confidentiality is not always present.  Thus, 
there's a case to be made for duplication of function as a security 
enhancement.

There's also a case to be made that sometimes 'belt and suspenders' 
engineering can be justified, particularly if availability or security is an 
issue.  There are even bits of engineering pragmatics having to do with reuse 
and sharing of common links between IP and non-IP traffic that could lead to 
duplication.

In another words, I can see where you're coming from, as far as the occasional 
tendency of link designers to put in bells and whistles where none are needed. 

However, the draft should be less doctrinaire, as in:

...seminal paper "End-to-End Arguments in System Design" [SRC81]. This paper 
argued that many -- if not most -- network functions are best implemented on 
an end-to-end basis, i.e., at the higher protocol layers.  Duplicating these 
functions at the lower levels can be needlessly redundant or harmful. However, 
there are also cases where duplication can be justified by considerations such 
as performance, availability or security.  Examples might include link layer 
retransmission on an unusually lossy channel, e.g., mobile radio, encryption 
of the entire link layer protocol over a shared medium, or  redundant paths at 
the link layer for fault recovery.  Duplication of functions should be done 
only based on an understanding of system level implications, including any 
side-effects on the higher layers.

Obviously, this is too late for draft going into the Washington meeting.  But 
I wanted to capture the thought.

Dan