Subject: Re: [Hist Trivia] IP Protocol Layers

From: Danny Cohen <[email-masked]>
Date: Wed, 18 Jul 2001 09:24:40 -0700 (PDT)

Keith,

You asked "so did the vocabulary end up being the most 
           important contribution of OSI to networking?"
           
You got it!!!  

See "The ISO Reference Model and Other Protocol Architectures"
By Danny Cohen and Jon Postel, IFIP'83, Sept-1983, pp. 29-34.

                                                    Danny

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 18 Jul 2001 10:24:47 -0700

> By Danny Cohen and Jon Postel, IFIP'83, Sept-1983, pp. 29-34.

To quote from that esteemed paper:

    Note the striking similarity between these statements:

        - in 1978, ISO invented the ISORM; this made computer communication
        much easier

        - in 1777, Lavoisier invented oxygent; this made breathing much
        easier.

'nuff said.

/mtr

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jul 2001 15:00:45 -0400

Well I think my point is that the OSI terminology really has turned out
to be surprisingly useful.  Even though we don't tend to need quite as 
many layers as they anticipated, it has helped the community tremendously
to have a widely shared understanding of those layers, their names,
and their relationship to each other.

And if the terminology really is the most important contribution of OSI -
I think that this is amusing, ironic, and instructive all at the same time.
It's amusing and ironic because of the huge amount of effort that went to
developing and promoting OSI.  It's instructive because it demonstrates
that even something as simple as a well-thought-out taxonomy can be 
really beneficial.

Keith

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 18 Jul 2001 12:07:52 -0700

> that even something as simple as a well-thought-out taxonomy can be

keith - i think you're pretty close to damning with faint praise here, and
you don't realize it. in high earth orbit, i can certainly agree that the
high-level terminology was useful. in terms of any practical perspective
though, the terminology is meaningless without an architecture, and the OSI
architecture isn't all that helpful.

for example, one of my favorite OSI acronyms is "IONL", which stands for the
internal organization of the network layer. ISO actually produced a standard
on this. why? well, because in the OSI architecture, you had to accomodate
both CL and CO network (sub)layers. this is simply not workable or even
rationale.

so, if the statement is that the OSI architecture was so general that it
could accomodate every possible existing and future architecture, i guess
i'd agree, but before doing so, i'd ask what's the point?

/mtr

ps: many of us still use "router" instead of "intermediate-system" and
"host" instead of "end-system", so i guess i have to question just how
useful all that OSI stuff really was. (other than giving me the opportunity
to write several books ten years ago poking fun at it...)

---

From: Steve Deering <[email-masked]>
Date: Wed, 18 Jul 2001 17:50:59 -0700

At 12:07 PM -0700 7/18/01, Marshall T. Rose wrote:
>useful all that OSI stuff really was.

We used to use "gateway" instead of "router" (and a few still do), and
I always thought the change to the "router" term was due to some sort
of OSI political correctness.  If not OSI, who gets credit for imposing
the "router" jargon on the IP world?  Was it the DEC folks (mostly Radia?)?

Steve

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 19 Jul 2001 10:18:48 +0100

>>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......creating articifical monitor
security/concurrency boundary crossings in component software was a
terrible thing, and many modern OSs have got a long way away from
it....

on reflection (pun intended):
layering is a clothing methodology for people who live in fractal climates
not a design pattern for correct or efficient communications
systems....
 cheers

   jon
p.s. NCP in england is National Car Parks.

---

From: Owain Vaughan <[email-masked]>
Date: Thu, 19 Jul 2001 11:22:41 +0100

> p.s. NCP in england is National Car Parks.

That's a coincidence because in Britain NCP is National Car Parks too!

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 19 Jul 2001 08:28:35 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Steve Deering
> Sent: Wednesday, July 18, 2001 8:51 PM
> To: Marshall T. Rose
> Cc: Keith Moore; Danny Cohen; [email-masked]; 
> [email-masked]; [email-masked]; Marshall Rose
> Subject: Re: [Hist Trivia] IP Protocol Layers
> 
> 
> We used to use "gateway" instead of "router" (and a few still 
> do), and I always thought the change to the "router" term was 
> due to some sort of OSI political correctness.  If not OSI, 
> who gets credit for imposing the "router" jargon on the IP 
> world?  Was it the DEC folks (mostly Radia?)?
>
My memory is fuzzy, but I believe I deserve at least some of the blame.
Around 1980-81, I designed the "DECnet-SNA Gateway" and argued that the
term "gateway" ought to apply to something that converted one protocol
to another, rather than something which forwarded packets between
machines using the same protocol. I do know we used the term "router"
for DECnet layer 3 stuff as early as 1981. I don't think any OSI
political correctness was involved, since they used the somewhat more
formal and convoluted term "intermediate system", and DEC didn't go over
to the dark side until around 1984-5.

> Steve
> 
> -
> This message was passed through 
> [email-masked], which is a sublist of 
> [email-masked]. Not all messages are passed. Decisions on what 
> to pass are made solely by Raffaele D'Albenzio.
>

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 19 Jul 2001 10:31:41 -0400

I thought we did it to distinguish the DoD mail gateways.

---

From: Mahadevan Iyer <[email-masked]>
Date: Thu, 19 Jul 2001 11:26:01 -0700

Jon Crowcroft wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jul 2001 14:26:37 -0500

Interestingly enough, when we wrote RFC 1958 "Architectural principles
of the Internet", nobody suggested "layer violation is evil" as a
principle. The arguments against layer violation tend to be pragmatic -
certain types of layer violation (such as "content based routing")
could lead to complex failure modes - others (such as diffserv peeking) 
are probably safe. It certainly shouldn't be a religious principle.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Jul 2001 01:22:09 -0400

> The arguments against layer violation tend to be pragmatic -

as much as I carp about things that violate layers, even I have to agree 
with that.  layer violations are occasionally useful, beneficial, and even 
necessary.  but the criteria for knowing when they're a good idea are 
not widely understood.

Keith

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 20 Jul 2001 09:59:29 +0100

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

 cheers

   jon

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 20 Jul 2001 14:33:36 -0500

End-to-End Transparent Transport of the IPv4 TOS field would seem to be
a fundamental given for IPv4. It is an 8-bit field and what goes in should
come
out on the other end, unchanged. In my opinion, people and companies should
check with the carriers that they connect to, in order to make sure that the
TOS
field is transported unchanged. Assuming it is, then splitting that 8-bit
field into
two symmetric 4-bit fields allows the entire IPv4 Internet Address Space to
be
increased by a factor of x16. All of the major carriers seem to be willing
to go
on record as saying that they DO NOT CHANGE the TOS field. That seems to
be a start, at ending what some would consider to be "layer violations".

http://www1.ietf.org/mail-archive/ietf/Current/msg12713.html
RFC-2001-07-11-000 IPv4+ and Testing of TOS Routing on New.Net Transport

Jim Fleming
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Jul 2001 11:17:00 -0700

> not a design pattern for correct or efficient communications

Another adage:

	model != mechanism

I.e., layering is, IMO at least, a model. Fine for
describing things, but not necessarily a good blueprint
for an implementation.

Joe

---

From: Randy Bush <[email-masked]>
Date: Mon, 23 Jul 2001 12:20:04 -0700

> I.e., layering is, IMO at least, a model. Fine for describing things, but
> not necessarily a good blueprint for an implementation.

compilation systems can be constructed which will procuce efficient inlined
code for nicely modularized (layered) source.  just not for programs which
use type-free pointers and similar analysis-defeating features.

randy

---

From: Mahadevan Iyer <[email-masked]>
Date: Mon, 23 Jul 2001 13:21:09 -0700

> describing things, but not necessarily a good blueprint

A problem well-stated is a problem half-solved.
Good models are often useful in gaining basic insights into a problem..a good
starting point for design before you plunge into the thicket of bewildering
details. (I am not passing any judgements on OSI or layering here :) )

---

From: Greg Minshall <[email-masked]>
Date: Mon, 23 Jul 2001 12:53:04 -0700

gee, i kind of *like* layering, both as a model AND as a mechanism.

maybe i haven't had the requisite head-rearranging performed in too long a 
time, but i have to say i value protocol model AND mechanism correctness over 
some amount of last ounce optimization.

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Jul 2001 13:23:43 -0700

> use type-free pointers and similar analysis-defeating features.

They can also do disastrous things, e.g., creating in-lined chunks
that thrash the instruction cache.

It's not just the layers that need to be spec'd, but the
interfaces between them. Even then all you have is a specification,
not necessarily an appropriate design for an implementation.

Greg Minshall wrote:
> 
> ...i value protocol model AND mechanism correctness over

It's also not just about optimization - sometimes the best way
to think about a concept isn't the best (most flexible, simplest
to code, simplest to debug, ...) way to implement it.

> A problem well-stated is a problem half-solved.

Agreed - half.

Joe

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jul 2001 16:28:07 -0700

Also seems to be a good electric fence - you can cross layers, but very
carefully.

---

From: Randy Bush <[email-masked]>
Date: Mon, 23 Jul 2001 13:53:31 -0700

> Also seems to be a good electric fence - you can cross layers, but very

try reading my message again, the one with >> above.  i was NOT suggesting
crossing layers at all, but in fact, suggesting why one does not need to.

randy