[e2e] Layering vs. modularization

[John Day]

At 20:15 -0400 2008/05/16, Martin Karsten wrote:
>John Day wrote:
>>At 20:55 -0400 2008/05/14, S. Keshav wrote:
>>>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.
>>
>>Gee, the only layering I have ever seen that had problems were the 
>>ones done badly, such as with the Internet and OSI.  In my 
>>experience, if you do it right, it actually helps rather than gets 
>>in the way.  Although, I know the first two conditions hold for 
>>properly layered systems and I am not sure I understand the third. 
>>Hmmm, guess I am missing something.  Although, I have to admit I 
>>never quite understood how wireless caused problems.
>
>I guess the problem lies with the exact understanding of "layering", 
>as has been pointed out by several others in this thread. If 
>layering refers to a protocol instance completely hiding all 
>services that are used to provide this instance's service, that 
>seems to be a problem. Layering per se is a different story. For 
>example, naming/addressing across non-cooperative networks seems to 
>always result in a stack of names with different scopes and of 
>course: stack of names == layers.

This is even less understandable. Why would a layer hide all 
services?  A layer should make services visible but hide the 
functions.  A service is by definition what is visible across the 
layer boundary.

>
>However, tightly integrating a certain functionality package with a 
>specific addressing scheme (such as in contemporary "layers") seems 
>to inhibit flexibility unnecessarily.

This sounds to me to have a number of unwarranted assumptions in the axioms.

>>>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.
>>
>>The solution to that then is to not let the network get too large! 
>>Simple.  ;-)
>>
>>Looking at your paper it seems to tend toward the beads-on-a-string 
>>model that the phone companies have always favored. Those never had 
>>very good scaling properties.  It is not clear how differences of 
>>scope are accommodated.  But then differences of scope sort of 
>>requires some sort of layer, doesn't it?  So how does this 
>>architecture facilitate scaling?
>
>It's not an architecture (as in 'implementation blueprint'), but a 
>model with the goal of helping to reason about network 
>architectures. In its current form, it really only covers 
>naming/addressing. The strings that you mention are just 
>representative of the existing stacks of protocol headers, so 
>there's nothing special here. I agree, multiple layers of naming 
>might be the only option to facilitate scaling, but then again, why 
>does a naming layer always have to be bundled with a specific 
>package of other functionality?

That would seem to depend on for what resources scaling was required.

Take care,
John