[e2e] Layering vs. modularization
touch at ISI.EDU
Thu May 15 19:33:14 PDT 2008
David P. Reed wrote:
> 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.
It presumes only that there is a total ordering. Such ordering can
include branches and variations - only that any particular path has a
> 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.
That's no more true for protocols than for structured programming.
Changes within a layer are hidden from others; changes that traverse
layers need to be accommodated only by at least the next layer. The
extent of that impact depends on the nature of the change.
> And "splitting a function across multiple layers" runs a huge risk.
It depends on how functions are split. Retransmission, e.g., can happen
within fragments at a link layer (ARQ), and within segments at a
transport layer, and both can - and arguably should - co-exist.
> 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".
It seems like you're convincing yourself that it's hard to redefine a
stack to retain a service; that may or may not be true. It may be
easier, though, to redefine a stack by reassembling components to
provide different services.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080515/7747b4a1/signature.bin
More information about the end2end-interest