[e2e] Layering vs. modularization
ggm at apnic.net
Thu May 15 18:15:21 PDT 2008
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
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..
More information about the end2end-interest