[e2e] Layering vs. modularization

[S. Keshav]

This note addresses the recent discussion on layering as a form of  
modularization.

Layering is one particular (but not very good) form of modularization.  
Modularization, as in programming, allows separation of concerns and  
clean interface design. Layering goes well beyond, insisting on (a)   
progressively higher levels of abstraction, i.e. an enforced  
conceptual hierarchy, (b) a progressively larger topological scope  
along this hierarchy, and (c) a single path through the set of  
modules. None of the three is strictly necessary, and, for example in  
the case of wireless networks, is broken.

Jon's message pointed to several previous designs, notably x-kernel,  
that took a different cut. In recent work, (blatant
self-promotion alert) we tried to formalize these approaches in our  
Sigcomm 2007 paper called "An Axiomatic Basis for Communication."

Interestingly, our approach only addressed the data plane. When we  
move to the control plane, as Jon hinted, things get very hard very  
fast.  Essentially, the problem is that of race conditions: the same  
state variable can be touched by different entities in different ways  
(think of routing updates), and so it becomes hard to tell what the  
data plane is going to actually do. In fact, given a sufficiently  
large network, some chunk of the network is always going to be in an  
inconsistent state. So, even eventual-always-convergence becomes hard  
to achieve or prove. Nevertheless, this line of attack does give some  
insights into alternatives to layer-ism.

regards

S. Keshav and Martin Karsten


Jon Crowcroft said:
> all of these (and much other work)
> do not dispense with modularisaton,
> but diverge from the classical layering - often by making use of
> programming language, compiler, type system and flxibility,
> and hardware advances (e.g. support for smarter buffer ownerhip -
> also useful for virtualusation)
> not available to earlier communicastions (or OS) researchers
> (at least not in any level of efficiency one would consider useable) -
>
> more dynamic composition of protocol systems does not imply
> throwing all discipline out the window but does lead to
> more subtle discussion of the modes of interaction between
> components
>
> ...
>
> it is the non-dataplane things that are where all the grot pops out
> and is generally swept under some sort of pretend procedural wrapper
> in many stacks (especially higher level)