[e2e] Layering vs. modularization
day at std.com
Fri May 16 18:24:12 PDT 2008
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
>>>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
>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
>>>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!
>>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.
More information about the end2end-interest