ietf
[Top] [All Lists]

Re: [Hist Trivia] IP Protocol Layers

2001-07-20 02:20:02


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(_dot_)4E69C856(_at_)ece(_dot_)uci(_dot_)edu>, Mahadevan 
Iyer typed:



Jon Crowcroft wrote:

In message <v04220802b77bde136984(_at_)[10(_dot_)83(_dot_)97(_dot_)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