[e2e] Layering vs. modularization

[Joe Touch]

David P. Reed wrote:
> Two challenges to proponents of the thesis that "layering can be done 
> right".
> 
> a) What specific problem in network systems design does a particular 
> layering solve?  

There are a few:
	- spatial localization of scope
	- supporting functional composition (which supports
	things like function reuse, which makes the result
	more accommodating to redesign and or dynamic use)

> Can you quantify the adequacy of solution (without 
> resorting to use of the concept of layering in a circular manner).

Part of it is supporting the modularity of protocol functions and reuse 
of capabilities. Another part is the simplicity of the result. It's like 
the difference between structured programming on a stack machine and 
machine language programming with only global variables.

> And 
> is there an alternative solution to that problem? 

Of course there is; the question is whether other solutions map well to 
the problem, or are unnecessarily inefficient or awkward.

> I'd suggest that if 
> you can't state the problem unambiguously and in a way that admits of 
> alternative approaches, then layering always "works". 

"works" means that layering maps better to how we develop and use 
protocols than non-layered solutions. It's relative; you can always 
shoe-horn a solution.

> It's like saying 
> that evolution creates the optimum result.  It's either vacuous to say 
> that, or worse, it's eugenicism.  As a matter of rhetoric, saying that 
> "layering" works when "done right" is unfalsifiable.   It's a tautology 
> because it's essentially just uninterpreted symbols on the page.

I'll agree that "layering works when it's done right" is a useless 
assertion. I'll contend instead that "layering is easier to get right 
than non-layering".

...
> b) Explain protocol encapsulation  (sending IPv6 datagrams within UDP 
> VPN packets over a TCP based overlay network implemented in userspace 
> stacks on machines that offload part of the VPN implementation to a peer 
> within a bluetooth subnet) as a form of layering?  

See our RNA paper. A reason we developed RNA was to explain the 
contradiction that:

	A- there are "7 layers", each defining a unique set of services
	B- services once believed to be unique to a single layer are
	   getting replicated at various layers
	C- overlays should be consistent with layering

(B) suggests there might be a common template that describes what a 
protocol is, which is instantiated in different ways (a 'stem' protocol)

(C) suggests that the stem protocol would be partly defined by the 
layers above and layers below, i.e., its behavior is relative to the 
services it expects (below) and those it provides (above)

 > It seems to me that
> encapsulation is akin to allowing recursion in one's language.   
> Languages that allow recursion are unlike FORTRAN 77, which is "layered".

Languages that allow recursion can be layered too, ala Pascal. It just 
means that the layers are defined at runtime.

> c) where does "security" go in a functional layering? 

Layering isn't purely functional. That is what, IMO, is wrong with (A) 
in the list above. Functions aren't constrained to a single layer.

> I would argue - 
> everywhere, and nowhere.  Information leaks at all levels of a layered 
> system.   Denial of service is possible at all layers.

DOS at layer K obviously affects layers (>=K), but not layers below 
(<K). That also means that any specific DOS can be defined "at a layer", 
i.e., the lowest layer it affects.

> It seems to me that "layering" is a collective hallucination.

The same was said about structured programming, and unfortunately we've 
somehow ended up in a pseudo-Flatland in which there are only 2-3 levels 
of namespaces and yet we have over-structured our datatypes (C++).

That move was motivated, AFAICT, by low-level programmers who didn't 
appreciate the need for structure until it was too late, and ended up 
adding it in the wrong place (IMO). I hope we don't make the same 
mistake with protocol architectures.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080515/e448def4/signature.bin