[e2e] Layering vs. modularization

[Joe Touch]

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 
unique order.

> 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.

  > 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".

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.

Joe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080515/7747b4a1/signature.bin