[e2e] Layering vs. modularization

[David P. Reed]

Perhaps when you write "layering" you include ANY form of 
modularization, rather than

    a *totally ordered* stack of protocol implementations, where each
    element in the stack merely takes the interface provided by the
    layer below and implements the new layer in terms of the primitives
    exported by the layer below.

The layering concept is a particularly narrow form of structuring.   It 
implies that there is a single correct linear sequence for building up a 
complete functional system.

While it admits a nice sequential proof structure - each layer can be 
proved based on the proof of the layer below - the idea that 
modifiability is simplified is hardly true.   A counterexample:

    if you change/extend the behavior of a layer, you must reimplement 
and re-prove all layers above that layer.  Thus, the deeper the stack, 
the less benefit of modularity.

And "splitting a function across multiple layers" runs a huge risk.   A 
function is typically specified by a small number of specification 
clauses.   One must partition the function specification into multiple 
subproblems (presumably not present in the original spec, because they 
are partial) in order to prove one layer at a time.

That means that the proof strategy depends on "inventing invariants" 
within a function's specification creatively.  This means that when 
functions are added or modified, the invented invariants that are needed 
to split the function across layers have to be "re-invented".

So the idea that modularity gains by totally ordered layers is not at 
all obvious, and the RNA idea sounds like it only makes the matter worse!
Joe Touch wrote:
>
>
> 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
>