Re: [Hist Trivia] IP Protocol Layers

[Jon Crowcroft <J.Crowcroft at CS.UCL.AC.UK>]

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 <3B572638.4E69C856 at ece.uci.edu>, Mahadevan Iyer typed:

 >>
 >>
 >>Jon Crowcroft wrote:
 >>
 >>> In message <v04220802b77bde136984 at [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