jpo@cs.nott.ac.uk (Julian Onions) (03/31/89)
Received: from roof.gardenshed.jocks-cabin by patio.macmiggins.stornoway via shoutnet; 21 Jan 89 20:50 SST Received: from patio.macmiggins.stornoway by bonfire.oban.beaconnet via infernonet; 25 Feb 89 15:31 SST Received: from bonfire.oban.beaconnet by cs.nott.ac.uk via cannet; 30 Mar 89 21:43 BST To: jpo@cs.nott.ac.uk From: jock@gardenshed.jocks-cabin Subject: Alternative protocols Date: Fri, 21 Jan 89 20:50 SST Alternatives to OSI =================== by Jock C. St. Martin University of the Outer Hebrides Scotland Following recent discussions concerning the relative merits of OSI and ARPA protocols, I decided to throw my hat into the ring. Furthermore, I believe that the ARPA protocols are not the only contenders with OSI, and that a number of even more "mature" mechanisms exist. I present seven possibilities for consideration. 1. Bean tins and bits of string ------------------------------- The use of bean tins and taut pieces of string has long been recognised as an effective means of communication. In fact, excavations from Anglo-Saxon dwellings in Nottingham show their use (albeit with imported coconuts as opposed to bean tins) in early everyday office situations. Bean tins and string have several advantages over OSI: a. They are fast, light weight and portable. b. They don't require the purchase of expensive computers. c. Complex error correction (based on the "NO - I said ..." principal) d. Uses off the supermarket shelf technology. e. They were not invented by the ISO. They also exhibit a very few trifling limitations: a. Poor support for "packet" switching (however, tin switching may be supported). b. Users often cut themselves on the tins. c. Star network topologies become more complex. d. They don't scale very well. 2. Shouting from the roof tops ------------------------------ Shouting from the rooftops can be an effective method of optimised local area communication. It is based on the well understood CMSA/CD technology but with the notion of priority. Users can insert high priority traffic with the "If I might get a word in edgeways" packet. It is already in widespread use - e.g., the House of Commons, political canvassing and Speakers Corner. Naturally, a roof top is only necessary for high bandwidth traffic. The PTT's would probably assume this role. The average user would be content to shout in the street. Shouting has many advantages over OSI: a. It is not as "complex and obscure". b. Most people understand shouting. c. Broadcasts are easy. d. Its fun. e. It wasn't invented by the ISO OSI has hardly any advantages over shouting: 3. Burning beacons on hill-tops: --------------------------------- Burning beacons on hill-tops have long been used to warn of advancing Armadas and their like. However, the author believes that beacons may have wider applications than just these. In particular, they have the following advantages over OSI: a. No "dangerous checkpointing". b. They keep you warm. c. Not overly complex and obscure. d. A secondary use for the disposal of those nasty ISO people. e. Not cluttered with unnecessary functionality. f. Not invented by the ISO. Disadvantages to OSI: a. Not suitable for the office environment (this may really be an advantage in some circumstances). b. Low bandwidth (may also be an advantage - see 7) c. Error rates can be high. Arsonists, pyromaniacs and "Satanic Verses" burners can generate spoof packets. 4. Semaphore ------------ Semaphore has been in use for many years. So why did ISO not consider this for international internetworking? This is difficult to determine, but is probably due to political motivations rather than any deficiencies in the protocols. Naturally there are a few rough edges to be addressed. Advantages over OSI a. Broadcasts are easily accommodated. b. Widely supported off-the-shelf infra-structure (boy scouts). c. Not invented by ISO Disadvantages over OSI a. Not so useful at night (but a working party on luminous flags is in progress). b. Bandwidth is rather low - but automation should help. 5. Messages in bottles ---------------------- This is a low cost solution to networking. Bottles are easy to obtain and with a little development, this neglected backwater of communications technology could be a real alternative. Advantages over OSI a. High bandwidth data channels already in existence (e.g. the gulf stream, rivers and sewers.) b. Large amounts of data can be placed in the appropriate sized bottles. c. Not invented by ISO. Disadvantages to OSI a. Transit time is unpredictable (but then IP, for instance, does not guarantee any bounded delivery time) 6. The Telephone ---------------- This might be seen as an enhancement of method 2. However, there is a lot to be gained from this approach. The name lookup problem is already solved as are routing issues. Lets face it, communications protocols are ultimately used for communicating between people. So why not just standardise the telephone. Add on services such as broadcast agents (commonly called gossips/operators) are easy to achieve. Advantages over OSI a. Its a mature existing technology. b. Directory services issues, routing and charging are already established. c. It's now available in portable form. d. Not invented by ISO Disadvantages to OSI a. Because it's a mature technology, there aren't so many interesting research areas. b. As a result of 2. there are few exotic conference openings. c. It costs money. 7. Not communicating at all --------------------------- One question I asked myself was "why communicate at all?" On consideration it was realised that not communicating has the following advantages over OSI. a. Low consumption of bandwidth. b. Cheap and easy to manage. c. No one disagrees with you. d. Without the time wasted on communication, other business proceeds much quicker. e. Not invented by the ISO No known disadvantages to OSI. The ARPA protocols. ---------------------- The ARPA protocols deserve consideration along with many of the above mentioned methods of communication. In particular, they have one major advantage over OSI. a. Not invented by the ISO However, despite this overwhelming advantage of the Internet protocol suite, the ISO proponents simply will not give in. In this section I therefore give a few other reasons for the superiority of the Internet suite - as if 1. was not enough. Scalability. The Internet protocols are obviously scalable as has been proved time and time again. All that is required is for the PTT's to take the sensible step of providing a network infra-structure and the rest can be solved. Charging is easily accommodated - the PTT's pick up the bills. Network interface. Many people have commented on how convenient it is to have a network address which fits into a common word size. This is such a advantage that the limitations are really insignificant. If the address space ever gets used up there is an obvious extension mechanism - the waiting list. Session layer. The Internet suite sensibly disregarded session services as superfluous. As has been observed, checkpointing is inherently dangerous as it can lead to loss of network usage and revenue. OSI has been influenced by the Internet community here, and has provided a session service complex enough that most implementations try and ignore it. Presentation layer. Again the Internet triumphs. It is quite clear that for the most part applications only need to exchange data consisting of bytes of 8, 16 and 32 bit quantities. These simple structures can be used as building blocks to construct almost any structure required. If this is not sufficient, there is a simple escape mechanism provided, known in the jargon as a "string encoding". It is quite clear that ASN.1 is just over the top - CHOICE's and OPTIONAL's are for quiche-eating indecisive applications. Application layer. Well the Internet has got this one too. Honestly, it's quite obvious that each application should do its own thing. That's what they're there for. If an application needs remote procedure call interface, or security, or name lookup, then it can do it itself rather than forcing it to use some more general service like ROS or directory services. SUMMARY ------- In summary, I feel that all of the above methods are orders of magnitude better than OSI (which incidently, and by coincidence, wasn't invented here). In particular, I feel that method 7 offers the greatest potential and, with this in mind, WE DO NOT WELCOME ANY FURTHER COMMENTS YOU MIGHT HAVE! Author's note ------------- This article is in no way connected with either Julian Onions or Steve Benford of the University of Nottingham beyond their role as postal agents for the author. -- Julian Onions
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (04/16/89)
Julian-- Although I wouldn't think of violating the author's request not to comment, I do feel a gloss for the cis-Atlantic audience is required: "Bean tin" (English) = "Tin can" (Amerenglish) And for your own interest and amusement, though I wouldn't think of bothering the author with it, we might observe that there is a deep sense in which the OSI protocols share in the advantage of not being invented by ISO. (They were, of course, reinvented--and badly, as witness the fact that the ARPA protocols do indeed offer some "session" and a lot of "presentation" FUNCTIONALITY, they just don't overcomplicate life by instantiating them in rigidly hierarchical layers. But, then, I daresay you knew that, just as you knew who invented Layering and Virtualizing ... and just as you knew that the FTP spec contains a checkpoint-restart facility, even if nobody implements it--the real advantage of ISO being, after all, that they presumably will be able to enlist Interpol as the cadre of the International Protocol Police.) Oh, by the bye, is the University of the Outer Hebrides convenient to Islay? If so, I'd be glad to visit some time, since Islay is where several important facilities in my real field of research interest are (e.g., Lagavulin, Laphroaig, and Port Ellen Maltings), and the day and a half I spent there in '86 wasn't at all an exhaustive research expedition, merely a preliminary dig. cheers, map -------
SCOTTY@UOGUELPH.BITNET (Scotty) (04/19/89)
I lived in Stornoway for 3 years, so I wouldn't really be too surprised to see bonifres burning on the hill! :-)
howard@cos.com (Howard C. Berkowitz) (04/28/89)
Suddenly, I have insight... :-) In article <12486384267.18.PADLIPSKY@A.ISI.EDU>, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes: > > And for your own interest and amusement, though I wouldn't think of > bothering the author with it, we might observe that there is a deep > sense in which the OSI protocols share in the advantage of not being > invented by ISO. (They were, of course, reinvented--and badly, as > witness the fact that the ARPA protocols do indeed offer some "session" > and a lot of "presentation" FUNCTIONALITY, they just don't overcomplicate > life by instantiating them in rigidly hierarchical layers. > Oh, by the bye, is the University of the Outer Hebrides convenient to > Islay? If so, I'd be glad to visit some time, since Islay is where > several important facilities in my real field of research interest are > (e.g., Lagavulin, Laphroaig, and Port Ellen Maltings), and the day and > a half I spent there in '86 wasn't at all an exhaustive research > expedition, merely a preliminary dig. Indeed, conformance testing is quite secondary to these fields; perhaps we can agree on Laphroaig as a common presentation syntax. I am continuing studies into the role of the MacAllen... Now, there may be a fundamental insight here. I see an equivalence relation here between scotch whiskies and network architecture... I assume you feel that a blended scotch overcomplicates whiskey by instantiating its components in arbitrarily hierarchical solutions, which are then mixed without proper definition of the service interface? Is it Session or Presentation you consider the equivalent of grain neutral spirits? -- howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [W] (703) 998-5017 [H] DISCLAIMER: Opinions expressed are not necessarily those of the Corporation for Open Systems, its members, or any standards body.
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (05/01/89)
Clearly, "grain whisky" resembles Session most strongly,
since it, too, is in the wrong place.
cheers, map
P.S. Earnestly suggest you reconsider common presentation notions:
Not only is Lagavulin the best of the Islays, it's even by some
minor miracle (doubtless having to do with neglible adverti[z/s]ing
expenditures) less expensive than Laphroaig--even the 10 y.o.,
much less the 15 y.o. (which in turn is itself much, much better
than the 10, albeit nearly half again as expensive, at least cis-
Atlantically). But for more detailed analysis, perhaps we'd
better take it off to the side, since it's remotely possible
that not everybody on the List wants to know what the second-
best Islay is (even though "best" isn't actually merely my
own considered opinion, but is, in fact, the finding of arduous
research).
-------stev@VAX.FTP.COM (05/01/89)
*Indeed, conformance testing is quite secondary to these fields; perhaps
*we can agree on Laphroaig as a common presentation syntax. I am continuing
*studies into the role of the MacAllen...
*howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard
*(703) 883-2812 [W] (703) 998-5017 [H]
*DISCLAIMER: Opinions expressed are not necessarily those of the Corporation
*for Open Systems, its members, or any standards body.
go with the feeling. the Spider Systems people always have "the frog"
at their hospitality suites. you would be amazed at the constructive
work that gets done when the workers are properly lubricated with
"the frog".howard@cos.com (Howard C. Berkowitz) (05/01/89)
I am often asked by audiences new to OSI, "Why are there seven layers?"
The most accurate answer to this, of course, is "because there are."
[If I wanted to be REALLY accurate, I would comment that seven
layers are an arbitrary decomposition done long before any OSI
implementations; equally good cases could be made for five or
eleven, or other numbers. Would the Bill of Rights be more
or less useful if the same material were covered in nine or
eleven Amendments].
Of course, the real question being asked is, "Do I need to know what
all seven layers do?" Now, if the questioner is a typical MIS
manager or other end user, the answer is "no, only developers really
need to know."
Since this answer makes many people suspicious of Secret Mysteries,
I appeal to their experience. Most MIS managers, while unfamiliar
with the esoteric theology of network architecture, are reasonably
familiar with Sin.
Audiences exhibit reasonably consistent behavior when asked to
consider the Seven Deadly Sins. Approximately 75% of the audience,
asked to consider these sins, immediately thinks of Lust.
This is entirely appropriate to the OSI Reference Model, because
Lust is clearly the Physical Layer. The mechanisms associated
with male and female connectors clearly are instantiations of
Lust architecture.
In general, the rest of the audience (with key exceptions) has
thought of Avarice and Gluttony. These, also, have their OSI
counterparts. If one thinks of Avarice in a business context,
one thinks of The Bottom Line; OSI architects simply put the
Bottom Line on top, and named it Application. One should know
what the Bottom Line is, even when it is on top.
Gluttony deals with Reaching Out and Touching, Ingesting, etc.
These are clearly functions of the Network and Transport
Layers (i.e., Network being associated with the adjacent course
of the meal, while Transport is more concerned with eventual
dessert), and all OSI users need to be nourished.
In any audience, however, there is always one (and usually
only one) who thinks of Sloth.
Sloth is analogous to the Presentation Layer. No one knows
exactly what Sloth is or even how to confess it (bless me, for
I have committed Sloth? or, I have slothed...?). Nevertheless,
it is necessary for theological completeness of the Sin Reference
Model.
In like manner, no one really knows why presentation is there,
other than for theological completeness of the OSI Reference
Model. MIS users may safely ignore it; only implementors in
the parishes need be concerned with it.
--
howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [W] (703) 998-5017 [H]
DISCLAIMER: Opinions expressed are not necessarily those of the Corporation
for Open Systems, its members, or any standards body.PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (05/03/89)
Nice metaphor ... BUT everybody knows why Presentation is there (where
everybody = all Old Network Boys, who, because they understand both Telnet
and how the NVT notion was used in FTP, readily grok doing virtualization/
devirtualization in a modular fashion, even if they don't think it should
be a mandatorily separate layer that mechanizes it [and given things like
the Common ASE, neither, apparently, do some key New Network Kids]). The
real Mystery--mayhap the Sin Against the Holy Spirit (of Layering, i.e.)--
is still Session ... unless the story that "there were some guys left over
who needed a committee" is true, in which case Sloth, Avarice, Gluttony,
and probably others all apply.
cheers, map
-------boomer@athena.mit.edu (Don Alvarez) (05/04/89)
In article <12490838760.31.PADLIPSKY@A.ISI.EDU> PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes: >Nice metaphor ... BUT everybody knows why Presentation is there (where >everybody = all Old Network Boys, who, because they understand both Telnet >and how the NVT notion was used in FTP, readily grok doing virtualization/ >devirtualization in a modular fashion, even if they don't think it should >be a mandatorily separate layer that mechanizes it [and given things like >the Common ASE, neither, apparently, do some key New Network Kids]). Yow! anybody want to diagram that one? (Talk about groking layered virtualization/devirtualization in a modular fashion! Holy parenthesis, batman!)