[e2e] Layering vs. modularization

[David P. Reed]

The following argument that you make by dragging in "fate sharing" 
suggests that your mental model is not about layering at all.  You are 
discussing dynamic behaviors, and layering has NOTHING to do with 
dynamics of packet transport, and more than modularity in a programming 
language has anything to do with the speed of a CPU's various ALU and 
memory operations.

Joe Touch wrote:
> Hi, George (et al.),
>
> George Michaelson wrote:
>>
>> On 16/05/2008, at 8:20 AM, David P. Reed wrote:
>>>
>>> b) Explain protocol encapsulation  (sending IPv6 datagrams within 
>>> UDP VPN packets over a TCP based overlay network implemented in 
>>> userspace stacks on machines that offload part of the VPN 
>>> implementation to a peer within a bluetooth subnet) as a form of 
>>> layering?   It seems to me that encapsulation is akin to allowing 
>>> recursion in one's language.   Languages that allow recursion are 
>>> unlike FORTRAN 77, which is "layered".
>>
>> recursion requires that first-class data constructs in the language 
>> be respected, so stack frame boundaries, globals etc are meaningful.
>>
>> encapsulation doesn't require this
>
> Strictly, recursion and encapsulation assume that the inner/lower 
> layer respects the boundary. It doesn't have to unless there are 
> enforcement mechanisms - that's the difference between strict and 
> non-strict languages.
>
> Encapsulation strictness is enforceable - just encrypt the payload.
>
>> stateful packet inspectors *might* need a re-write, but that aside, I 
>> don't see  how anything other than a bug would make the outer V6 
>> active units need to read the inner V4 payload, or vice versa
>
> Outer V6 would read inner V4 to support path 'fate sharing', i.e., 
> when doing multipath routing it's useful to ensure that 'flows' 
> traverse similar paths, and in this case the V4 address could be the 
> best cue to a flow.
>
> Joe
>