the point is that a functional decompiositon is NOT layering
there are niceexamples of this in the RMT building block work- there are reasons
you want reliability, flow cotnrol, congestion avoidance, sequenceing, but they are
not all composable in a trivial fashion in any order, and it is usually a bad idea to
compose similar funcitons twice - experiecces include many e.gs over the last few
decades: two control loops in a feedback system are
worse than one for most values of the control parameters - experiences with TCP on
IP over X25, ATM etc show that; two layers of relaibility work badly - e.g.s abound
in TCP over IP over GPRS and others- it is possible with many months of PhD student
time to get it neatr to right, but very hard and usually pointless ; two functions
providing sequencing is kind of obviously pointless etc etc - BUT, it is reasoanble
on a case by case basis to priovide some of these functions at DIFFEREWNT plaecs
along a _path_ -a path is a spatial organisation of functions in a distributed
system, composed togewether with channels and aint the same as layering either...
reflection and oo components applied to such s/w systems organisation seems like
a promising approach to modelling them...
In message <[EMAIL PROTECTED]>, Mahadevan Iyer typed:
>>
>>
>>Jon Crowcroft wrote:
>>
>>> In message <v04220802b77bde136984@[10.83.97.216]>, Steve Deering typed:
>>>
>>> >>We used to use "gateway" instead of "router" (and a few still do), and
>>>
>>> i lik the fact that if you type getaway by mistake you get what people
>>> are trying to do when they are routed ...
>>>
>>> i also like the fact that MOST fancy things we do in traffic treatment
>>> (firewall, diff/int serv, header compression, checksum) ignore this
>>> layering rubbish idea and look at the whole packet and the whole state
>>> of the systems where you need to......
>>
>>I always thought peeking into other layer headers to make better decisions
>>doesn't always destroy layering. It's when the implementation gets tied to a
>>specific other-layer technology, or it *writes* into other layer headers, or
>>performs 'designated' other-layer functions, that layering is destroyed.
>>
>>Say, a diff serv implementation that tries to figure out what kind of lower
>>layer protocol is present and if it succeeds in doing so, uses the lower layer
>>information to make forwarding decisions, is not really destroying layering,
>>is it.
>>I can still deploy this diff serv implementation readily over all kinds of
>>lower layer 'technologies' or standards, because it is not tied to any
>>specific such technology. If it can recognise the lower layer technology, it
>>uses that extra lower layer information to try improve performance, otherwise
>>it just performs default operations. So for example, I can still easily
>>transfer such an implementation from a wired-ethernet to some wireless
>>standard without any rework. Now, isn't *that* kind of layering good? Or am I
>>missing something.
>>
>>
>>
>>
>>
>>
>>
>>
cheers
jon
