[e2e] Layering vs. modularization

[George Michaelson]

On 16/05/2008, at 10:55 AM, 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.


I think there is a conversation about 'is-ness' here. A router (for  
instance) can quite happily pass encapsulated traffic without looking  
at it. The "me" of the router doesn't have to look at payload. Might  
be slower, but it will work.

A compiler on the other hand, has to know how to manage true in- 
language recursion because the "me" is meaningful for all recursively  
called instances. They might indeed map into discrete cores of CPU  
run, but something has to be able to unwind the stack of nested  
recursive calls. there is a "me" which has to know recursion is being  
used. I would suggest even in the more lax languages this is true.

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

to abuse an analogy, dealing with 'fate sharing' is inventing  
optimisations. For the purposes of this discussion and its  
comparisons, if you compile gcc -O<x> then you get what you paid for.  
If you want to complain about an ICE, you can expect to be asked to  
use lower levels of optimization.

Likewise with any router which wants to be smart about its  
encapsulated payload.

I'm told amusing stories about the MPLS routers which mistook the  
conceptual layerings (for want of a better word) in their internal  
route map, and can cause havoc. Likewise the external debug paths  
which sometimes use the MPLS, and sometimes use independent routing:  
one kind of view says "its not broken" and the other kind doesn't and  
it depends which you are on, to see the problem..

I also think layering is an over-stated concept. Having worked on  
systems which mapped the logical layers strictly into procedural  
boundaries, each independently implemented, I am very
aware of the runtime cost of that strict separation. Equally,  
debugging systems which dive down or use language tricks like macros  
to implement functional elements more effectively is hard.

Explaining to people that your hardware is calculating the TCP  
checksum for you can be quite interesting. I think humans by default  
obey mental models of layers quite a lot in their internal  
conceptualizations, and layer violations are <blink> moments for the  
thinker. OTOH explanations simplifying things is what Terry Pratchett  
calls 'lies to children' in education, and arguments persist about the  
neccessary lies, and when you reveal truth..


-George

>
>
> Joe
>