ps@diab.UUCP (06/03/87)
We are looking for a software package that implements the OSI-model protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) in whole or parts. The software need not be a commercial product, or even completely functional. If suitable, it will be a base for further development. It is a requirement that the software could become the property of this company (no licensing), on a non-exclusive basis with no restrictions on it's future use or distribution. Any hints are appreciated. Thanks in advance. -- Per-Erik Sundberg, Diab Data AB SNAIL: Box 2029, S-183 02 Taby, Sweden ANALOG: +46 8-7680660 UUCP: seismo!mcvax!enea!diab!ps
mac@idacrd.UUCP (06/04/87)
in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says: > Xref: idacrd comp.dcom.lans:459 comp.protocols.misc:22 comp.sources.wanted:1227 > > > > We are looking for a software package that implements the OSI-model > protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) > in whole or parts. The software need not be a commercial product, or > even completely functional. If suitable, it will be a base for further > development. It is a requirement that the software could become the property > of this company (no licensing), on a non-exclusive basis with no restrictions > on it's future use or distribution. > > Any hints are appreciated. Thanks in advance. > AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha Chuckle chuckle etc. Bob
dpz@aramis.rutgers.edu.UUCP (06/04/87)
>From: mac@idacrd.UUCP (Bob McGwier) >>We are looking for a software package that implements the OSI-model >>protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) > AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha > > Chuckle chuckle etc. Pretty friggin obnoxious. Go play with your toys, unless you have an intelligent answer for him. dpz -- David P. Zimmerman rutgers!dpz dpz@rutgers.edu
steckel@alliant.UUCP (06/05/87)
Anyone contemplating using OSI protocols should read Padlipsky's comments in the tcp-ip mailgroup (comp.dcom.tcp-ip I think). He exposes far better than I can the fundamental flaws in network protocols prescribed by PTTs (national postal/telegraph/telephone monopolies) or other monolithic entities. He has also published a book on the subject - suitable for making implementors cry and standards committee members break out in flames. (Sorry, I can't remember the title but I could find out if enough interest) OSI doesn't tell you how to make a network. It only tells you how to (supposedly) connect to a (supposedly perfect) network. All OSI protocols fall extremely short on error handling. Even X.25, the closest to usable of all the OSI protocols, has had several revisions because of this problem and it's a low level! Read Padlipsky and weep (or break into hysterical laughter!). geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp)
jmg@cernvax.UUCP (jmg) (06/05/87)
In article <233@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes: >in article <223@diab.UUCP>, ps@diab.UUCP (Per-Erik Sundberg) says: >> We are looking for a software package that implements the OSI-model >> protocol levels 3(internet), 4(transport class 0,2,4), and 5(session) etc. >> Any hints are appreciated. Thanks in advance. > >AHHHAAAA Ahhhaaa hahahahahaha ahhhhh hahahahahaha ahhh hahahaha > >Chuckle chuckle etc. > >Bob > May I say that this is the sort of inane reply which drives me wild. It has no information in it, other than an implied snide comment. Personally, I would prefer that Mr. McGwier thinks for a few microseconds before issuing such a reply. As it happens:- 1. I already sent off four names to the original sender, and there are certainly more. 2. We are currently running (and interworking with) three different ISO TP4 implementations (on Vax, 68000 and IBM PC). 3. The sender is not English mother tongue (although he speaks it probably rather better than most readers speak his language), and so is possibly upset by the answer.
nrh@chuck.bellcore.com.UUCP (06/06/87)
In article <526@alliant.UUCP> steckel@alliant.UUCP (Geoff Steckel) writes: >Anyone contemplating using OSI protocols should read Padlipsky's comments >in the tcp-ip mailgroup (comp.dcom.tcp-ip I think). He exposes far better >than I can the fundamental flaws in network protocols prescribed by PTTs >(national postal/telegraph/telephone monopolies) or other monolithic entities. >He has also published a book on the subject - suitable for making implementors >cry and standards committee members break out in flames. (Sorry, I can't >remember the title but I could find out if enough interest) >... >Read Padlipsky and weep (or break into hysterical laughter!). > geoff steckel (steckel@alliant.uucp, gwes@wjh12.uucp) Padilipsky's book is called "The Elements of Networking Style", and is published by Prentice-Hall.
fair@ucbarpa.Berkeley.EDU.UUCP (06/07/87)
Followup-To: I wish to echo the recommendation of Michael Padlipsky's book, which is The Elements of Networking Style and other Essays & Animadversions on the Art of Intercomputer Networking Michael A. Padlipsky published by Prentice-Hall, 1985 ISBN 0-13-268111-0 01 It is most frustrating to only be able to sit idly by while most of the computer industry gives lip service to ISO vaporware, while a superior, second generation protocol suite goes mostly ignored (unless the customers have the sense to ask for it): DoD IP/TCP. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
mel1@houxa.UUCP (06/07/87)
In article <19265@ucbvax.BERKELEY.EDU>, fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: > It is most frustrating to only be able to sit idly by while most of the > computer industry gives lip service to ISO vaporware, while a superior, > second generation protocol suite goes mostly ignored (unless the > customers have the sense to ask for it): DoD IP/TCP. I am new to the field of networking and am getting very confused. I see lots of utility in the TCP/IP offerings and uses. I was a user of the ARPANET for many many years (without the slightest knowledge about what was providing such great services). I use an Ethernet in our lab that connects dozens of systems from different venders and opertaing systems. Both work very reliably, relatively fast, and duck simple to use. What does ISO offer that TCP/IP doesn't? Is it significantly faster? I can't think of any other measure that needs improving. Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? Mel Haas , odyssey!mel
dyer@spdcc.COM (Steve Dyer) (06/07/87)
It's unfortunate that Padlipsky, in naming his collection of essays "The Elements of Networking Style", seems to have eschewed all the recommendations of its namesake, "The Elements of Style" by Strunk and White. Although there is some very good technical content in the book, it is buried beneath a rambling, self-indulgent conversational style which is very hard to read and follow. Padlipsky makes a lot of his deliberate decision to avoid "seriousness" in a technical book, but that doesn't mean that it has to represent the worst of an engineer's first drafts. I wonder, too, how accessible much of the material is to newcomers--many of the essays dive immediately into the details of NCP, the protocol suite used on the ARPAnet before the introduction of TCP/IP. When I was reading it, I was glad that I had worked at BBN during the NCP/TCP transition where I had to support both protocol suites--I had some context to work with. This isn't to detract from its uniqueness -- it's practically the only book of its kind, written from the point of view of one of the original ARPA designers. But it helps if you read it as a kind of "oral history" transcribed verbatim and manage to get past its idiosyncratic style. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,halleys}!spdcc!dyer
sas@pyramid.UUCP (06/07/87)
In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >What does ISO offer that TCP/IP doesn't? Is it significantly faster? >I can't think of any other measure that needs improving. The following is my opinion: The ISO stack, in its current state, offers significantly less functionality than TCP/IP. In particular, the virtual terminal protocol is not yet completed. What ISO does propose to offer (when completed) is: (1) More heterogeneity via a more "complete" series of options to the basic functions. (2) A solidification of the layering approach to communications protocols which would provide more intermingling of various services within a class of functionality without modification to the higher layers. E.g., the ability to run a lean transport on top of a connection-oriented service (X.25) versus a more substantial transport on top of connectionless services (802.3). (3) A suite of protocols not developed by the "bomb-crazed" American military. Not that I want to bring politics into the picture but, like it or not, we're talking *international* standards. The Europeans are very sensitive about the protocols which run over the PTT networks. Anyone whose gone through the ordeal of an X.25 certification can attest to this. An international standard not controlled by any one country (in fact one in which each country can select the options (see (2)) it prefers) would seem to be an ideal solution. > >Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? More opinion: I'm not sure I'd classify what appears to be taking place as a war. It seems to be more of a necessary sanity check on what's been produced by the standards bodies. I'm all for standards and computers that talk to each other. However, I'd like this to happen in a reasonably fast and (from the host-standpoint) efficient manner. Beyond the discussion over incompleteness of the standards, there is a question of performance of ISO implementations. One of the more visible groups raising these questions is the FDDI group. If you'll recall, FDDI is a 100 Mbit/sec token bus standard being developed by a subcomittee of ANSI. An important question is what happens when I suddenly improbe my bandwidth (in this case, an order of magnitude) but my software only allows me to use a small portion. In favor of ISO are the European PTTs and academic networks, the MAP/TOP group, NBS and Corporation for Open Systems (COS), and the US Government via the GOSIP spec. It also appears that the ARPAnet may migrate to ISO in an undetermined timeframe. > > Mel Haas , odyssey!mel sas ---- Scott Schoenthal Pyramid Technology Corp. pyramid!sas Mountain View, California
sas@pyramid.UUCP (06/08/87)
In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > [ ... ] If you'll recall, FDDI is a 100 Mbit/sec token bus ^^^ Ugh! My mind said "ring" but my fingers typed "bus". My apologies for any confusion. sas
ast@cs.vu.nl (Andy Tanenbaum) (06/09/87)
In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >What does ISO offer that TCP/IP doesn't? Is it significantly faster? >I can't think of any other measure that needs improving. > >Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? The ISO OSI model is an attempt to provide a framework for networking from the physical bit transport to the applications. The model itself does not contain protocols at all, although ISO has standardized some protocols and services for the various layers. TCP and IP are two specific protocols for layers 4 and 3, respectively, and as such can be used to fill two of the slots in the OSI reference model. Other protocols are needed for the other layers. Virtually everyone now agrees that the OSI model is a good way to look at networking. The war is about which protocols which be used in which layer. TCP is clearly one candidate for the transport protocol, but most companies in the U.S., and virtually all companies outside the U.S. are committed to supporting the ISO OSI transport protocol and the ISO protocols in layers 5 through 7 too. (1-3 are much fuzzier, what with IEEE 802 etc.) There has been a lot of generalized disgust with OSI expressed here and elsewhere. I would be very interested in hearing specific comments about 1. What is wrong with the OSI model itself. 2. What is wrong with the specific protocols ISO has adopted. Comments like: you can't go out and buy it off the shelf right now don't count. If the standards people waited until every company had already had a running network product, they would all be different and there would be no standard at all. The only way to achieve standardization in this area is to agree on the standards before every company invests a lot of money doing it some nonstandard way. Thus it is not surprising that the standards are here before all the implementations. Nevertheless, there are certainly plenty of valid criticisms of the model and the protocols (e.g., the session layer is pointless, the presentation layer is practically empty, they forgot about encryption altogether etc.). I would like to see a discussion of this subject, preferably by people who know what they are talking about. Andy Tanenbaum (ast@cs.vu.nl)
lamaster@pioneer.arpa (Hugh LaMaster) (06/09/87)
In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <492@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >> >>Is there a war going on? TCP/IP vs ISO? Who is on which side? Why? > > >There has been a lot of generalized disgust with OSI expressed here and >elsewhere. I would be very interested in hearing specific comments about > 1. What is wrong with the OSI model itself. > 2. What is wrong with the specific protocols ISO has adopted. > >Andy Tanenbaum (ast@cs.vu.nl) 1) I would like to move this discussion to comp.protocols.iso 2) Unfortunately, the standards making bodies have appeared to those of us on the outside to be dominated by two groups; the first group are European telecomm monopolies who are indifferent to or actively hostile to internetworking (e.g. Arpanet, milnet, nsfnet, many regional networks) between LANs because it will reduce the tariffs they collect (they are right about that); and, second, Certain U.S. Vendors who individually and collectively have a financial interest in pretending to be interoperable while actually trying to make it difficult for their customers to integrate multiple vendors into a single network (they like captive customer bases of course, what monopoly wouldn't?). 3) It is not an issue that not everything is implemented yet by all vendors; it is an issue that absolutely essential protocols are not yet defined. Until there is a network virtual terminal specification, for example, the rest of ISO is of limited utility. You have to have the minimal set of specs first before you can reasonably judge the protocols. How can you be an "ISO booster" before you have a complete protocol set to boost? How can you expect an internet user to accept the ISO protocols before internetwork address resolution and routing are even defined? (Let alone published where the public can see them.) 4) The religious overtones from the ISO camp are also disturbing. I don't remember anyone ever laying religious stuff on me for the arpa protocols. TCP/IP etc. spread from arpanet to the general user community because they worked, and provided the facilities that people wanted. It was that simple, and that hard. The ISO camp is trying to replace TCP/IP not with an improvement in performance, reliability, features, or ease of integration. Instead, some its proponents have resorted to forced baptisms. Before the things we are supposed to believe in are even defined. It worries me. 5) Because the ISO camp didn't bother to stop and consider the needs of the LAN and internet communities, they have only recently begun to work on LAN and internet features. Real improvements over tcp/ip, such as new features like multiple gateway dynamic routing and path load balancing, and real (layer by layer) security, have not been worked on at all. Is it possible to retrofit real security into ISO at this point? If it is, will it be possible to change iso substantially, or will it be cast into concrete, warts and all? 6) Therefore, I am afraid there are two warring camps at this point. The TCP/IP camp is looking for better service, and the iso camp has its (somewhat hidden) agenda which is quite different. This is not to say that anyone working on defining or implementing iso is a bad person. Some of the nicest people are. The solution, from my perspective, is for the iso camp to mature sufficiently that technical considerations override the (current) political considerations. In the meantime, I hope that some mechanism by which user and small vendor input into iso can be developed. Why isn't there anything like the RFC mechanism for iso? Perhaps comp.protocols.iso should spin off rfc.protocols.iso (moderated, of course) and the results forwarded to the standards bodies. 7) Finally, this is not a flame on all the hardworking people who have tried to make the iso protocol suite more suitable for LANs and internets. I don't know who most of you are, but I know sitting on standards committees is tough work. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
lamaster@pioneer.arpa (Hugh LaMaster) (06/10/87)
In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: (Paraphrase: "ISO offers the following:") > > (3) A suite of protocols not developed by the "bomb-crazed" > American military. Not that I want to bring politics > into the picture but, like it or not, we're talking > *international* standards. The Europeans are very > sensitive about the protocols which run over the > PTT networks. Anyone whose gone through the ordeal of This "argument" I thought was a joke, at first. "You have got to be kidding." The sad truth is that I have actually heard ISO proponents use it. Did you know that modern canning was invented for Napoleon's army (to invade other countries, where supplies and logistics were a problem) and was used primarily for military food supplies for its first sixty years or so? So I guess we shuldn't use canned food. If there are any pacifists reading this, I might suggest that "swords into plowshares" might be a better approach. Use the protocols for peaceful purposes. My sources tell me that, unfortunately, "they" are much more worried about "uncontrolled" traffic which flows outside "their" networks. It is just hard to talk about this "problem" in public, so other arguments must be used. Sounds like material for talk.politics to me. Add a healthy dose of "Not invented here" (NOBODY has a monopoly on NIH), plus some unscrupulous computer vendors ("We have ISO, see, seven layers") and you have a mess for the technical grunts to straighten out. Too bad; it didn't have to be this way. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
kre@munnari.UUCP (06/10/87)
In article <1724@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > 1) I would like to move this discussion to comp.protocols.iso Be careful here, comp.protocols.iso is an internet group (a cheap way of transporting the mailing list over the internet), it doesn't reach out into most of usenet. It probably should. Since usenet is all about networking, and iso is standardising exactly that, this is one topic that all usenet should be able to see. > Until there is a network virtual terminal specification, for example, > the rest of ISO is of limited utility. You're right, that one is lagging behind (and started late), probably largely because X.29 (as revolting as it is) was seen as serving adequately enough (which it doesn't outside the x.25 world). > The solution, from my perspective, is for the iso camp to mature > sufficiently that technical considerations override the (current) political > considerations. No, this is all backwards, strange as it may seem. The whole purpose of standardisation is for political considerations to override the technical ones. And no, I'm not being cynical. The absolute essential for a standard is for everyone to agree with it, and getting everyone to agree means lots of compromises. (Just consider Sun with NeWS and X). There's absolutely no hope of a technically perfect standard, especially not in any area where there's any dispute about what is perfect. This isn't to say that the standards bodies don't aim to formulate a standard as technically good as they can, but that *must* come second to getting the necessary agreements, from the whole world. > Why isn't there anything like the RFC mechanism for iso? There is: they're the working papers, draft standards, etc. What they're not is free. Nor are they even cheap. However you can easily obtain copies (contact ANSI in the US). The documentation isn't free, as this is how ISO largely finances its activities .. ie: selling those bits of paper largely pays for the secretarial work that goes into creating them (most of the cost of the technical work is contributed by the members of the working groups, or their employers, but I believe that some of this comes from ISO funds as well). Robert Elz
fwb@siemens.UUCP (Frederic W. Brehm) (06/10/87)
[I removed comp.protocols.iso because postnews could not find the group!] In article <1726@ames.UUCP> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >In article <2923@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > >(Paraphrase: "ISO offers the following:") > >> (3) A suite of protocols not developed by the "bomb-crazed" >> American military. ... > >This "argument" I thought was a joke, at first. "You have got to be kidding." >The sad truth is that I have actually heard ISO proponents use it. ... I have heard it used (but without the "bomb-crazed" phrase) by TCP/IP opponents who would use ANYTHING, no matter how terrible, as long as it is not TCP/IP. I don't understand this attitude. TCP/IP is a useful suite of protocols readily available for many machines from many vendors with good support. I hope that the ISO suite of protocols matures soon so that I can buy the functionality I need without fighting political wars. Fred ---------------------------------------------------------------------------- Frederic W. Brehm Siemens Research and Technology Laboratories 105 College Road East Princeton, NJ 08540 (609) 734-3336 uucp: ihnp4!princeton!siemens!fwb or astrovax!siemens!fwb CSNet: fwb@siemens.siemens-rtl.com
mel1@houxa.UUCP (06/11/87)
Thanks to all who supplied comments to my questions on OSI vs TCP/IP. Unfortunately, none supplied answers. When I refered to OSI vs TCP/IP, I was just using those labels for the whole class of communications capability, not just the OSI reference model vs the TCP/IP layers of the DOD network. Several replys presented the theme that large corporations and government agencys "supported", "endorsed", or "were committed to" the OSI/ISO standards. I don't know what that means. In most cases the organizations mentioned market products or install systems that provide similar functions using quite different protocols. Am I off base in believing that those actions represent just the opposite of support, endorsement, and commitment? Several replys mentioned a variety of different protocols for some of the ISO layers. How does that fit the concept of a "standard"? Is this 1984 "double speak"? I am just a user of already deployed interconnected networks that use a truly fantastic variety of computer systems, hardware, and connection media all based on TCP/IP (with rcp, rsh, rlogin, ftp, telnet at the top for most UNIX users; and goodness knows what on the bottom to actually connect in). Isn't this whole stack already a standard (with an existance proof)? What is the replacement for all this? What does the replacement offer as an inducement to switch? The TCP/IP people have a very active newsgroup discussing technical details of the protocol. I don't understand any of it, but find it quite amazing that there is still growth, discussion, and willingness to learn and change so many years into the life of the product. Or, is this just an indication that the wonders I see are held together with bailing wire and string? Does ISO/OSI have such an activity? Mel Haas , odyssey!mel
sas@pyramid.UUCP (Scott Schoenthal) (06/11/87)
In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >There has been a lot of generalized disgust with OSI expressed here and >elsewhere. I would be very interested in hearing specific comments about > 1. What is wrong with the OSI model itself. > 2. What is wrong with the specific protocols ISO has adopted. > > [ ... ] > >Nevertheless, there are certainly plenty of valid criticisms of the model and >the protocols (e.g., the session layer is pointless, the presentation layer >is practically empty, they forgot about encryption altogether etc.). I would >like to see a discussion of this subject, preferably by people who know what >they are talking about. > >Andy Tanenbaum (ast@cs.vu.nl) I believe that Andy knows what he is talking about and I would certainly be interested if he would expand on the criticisms he mentions in his posting. While I did refer in an earlier posting to the political aspects of adoption of an international standard (the phrase '"bomb-crazed" American military' was an impetuous addition which I now regret), I believe that we should consider here (or hopefully in a comp.protocols.iso) mainly the technical issues of the ISO/OSI model and protocol definition and implementation. Hopefully, this could include MAP/TOP specific protocols (e.g., Directory Services, Network Management) and relevant CCITT protocols (e.g., X.400) as well. sas ---- Scott Schoenthal Pyramid Technology Corp. pyramid!sas Mountain View, California
karn@faline.UUCP (06/13/87)
In article <1204@botter.cs.vu.nl>, ast@botter.UUCP writes: > Virtually everyone now agrees that the OSI model is a good way to look at > networking. The war is about which protocols which be used in which layer. About the only thing virtually everybody agrees on is that hierarchical layering is usually a good idea in a computer communication network. The ISO Reference Model (not so fondly called "eyesore-emm" by Padlipsky) is only one of several possible hierarchical models, and a rather outdated one at that. Among the major flaws of the ISO Reference Model are: 1. A fixed number (7) of layers. In a real network there may well be more or less than 7 layers. The important thing is the relative position of a protocol in the hierarchy and the function it performs, not the fixed "level x" designator it might have. Jon Postel and Danny Cohen wrote a paper a few years ago in which they examined some real networking systems and showed that either a) N = N + 1 (for any value of N), OR b) the notion of "seven and only seven layers" is fundamentally flawed. 2. It completely ignores internetworking. This is related to point #1, since in a real internetwork you may very well have two or more network layers in a "stack", e.g., a subnet layer underneath an internet layer. (Some people do split ISO Layer 3 into Layer 3A, the Subnet layer, and Layer 3B, the Internet layer.) The fact that the model still doesn't formally recognize the very real existence of and need for internetworking says something about the motivations of those who influence the ISO. 3. Overly redundant layer functionality. My pet peeve is the use of the term "reliable" in the link layer description, implying that the primary burden for reliable delivery of information rests here instead of the transport layer where it belongs. No other concept has contributed so much to needless complexity, inflated costs and lousy performance than the stubborn notion that each and every layer must "guarantee" reliability, usually through the use of an overhead-laden connection- oriented protocol. A decade ago this mentality brought you X.25. Now it has resurfaced in an even more astonishingly byzantine creation, "IEEE 802.1 Connection- Oriented Logical Link Control" (basically X.25 over Ethernet, believe it or not). For more on the general subject of end-to-end vs low level reliability mechanisms, see "End-to-end Arguments in System Design" by Jerome Saltzer of MIT. 4. While important concepts are ignored, another layer exists whose function is questionable at best: the Session layer. I've yet to figure out just what it's supposed to do, and why a separate layer is needed to do it. 5. While not a fault of the ISO RM per se, some of its overly zealous followers (whom Padlipsky also not-so-fondly refers to as ISORMites, pronounced "eyesore mites") tout it as *the* way a network *must* be built. Even the originators of the ISORM never intended it as anything other than as a general guide to *naming* the pieces of *existing* networks. For example, I've had people tell me that I can't have a "network" without a separate Session layer, even though TCP and UDP have perfectly adequate port numbering and "well known socket" mechanisms. When I ask why, they say "ISO says so". In addition to the faults of the underlying reference model, the ISO/OSI "protocol suite" has a host of faults of its own. First and foremost among them is the fetish for connection-oriented protocols. Only recently did a connectionless transport protocol get added, despite the widespread use of UDP in the ARPA Internet for things like network databases and distributed file systems. On the other hand, there are a FIVE different and mutually incompatible protocols all providing a connection-oriented transport service (TP-0 thru TP-4). If the ISO was *really* serious about "open systems interconnection", they would pick ONE connection-oriented transport protocol (TP-4, the most general one). They claim you don't need all that reliability if you're running on a PTT network, but of course the real reason is that they're scared to death of internetworking. There's no way a PTT is going to allow it to happen unimpeded. Yes, eventually you may be able to pick a "subset" of the ISO stack that answers the needs of the internetworking world. But if you do, you end up with something that is similar to, but (deliberately) incompatible with TCP/IP. So why bother? In summary, if you think open systems interconnection is a good idea, I agree. That's why I and so many others use TCP/IP. I have nothing against migrating to an international standard if it is provably superior to what we have (e.g., the metric system vs the English system) but this is *not* the case with OSI in its present form. I also dislike the "bomb crazed military", but I also see no reason not to take their technology and beat it into plowshares. In fact, it gives me a real feeling of satisfaction to take military technology and pervert and subvert it to peaceful uses! Phil
samlb@well.UUCP (06/14/87)
It occurs to me that the reason for including the concepts "Session" and "Connection" in the ISO/OSI model is precisely because PPTs are accustomed to charging by the (name your time unit) for a connection between two points. (i.e. DM0,45/minute from Frankfurt-am Main to Bad Nirgensplatz, Bavaria) It is easier to machine titanium than to try to change bureaucratic ideas (sic) of "the way the world really is -- and should be"! -- Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale! 34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282 UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb; Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassett
martillo@bloom-beacon.UUCP (06/15/87)
Just a note on X and NeWS. NeWS is a postscript based graphics system for high resolution graphics devices which can be used to provide windows. X is a window system which has some graphics primitives. They are not comparable as alternate standards in view of the underlying mechanism or design or philosophy. The question is whether window systems should be implemented on top of graphics systems or whether graphics systems should be built on graphics systems. It maybe partially a religious issue (but I suspect not because virtualizing a raster device on top of a raster device makes sense to me while virtualizing a raster device on top of a graphics system on top of a raster device seems to introduce an extralevel of complexity) but Adobe has announced that it will implement postscript on top of X.
karn@faline.UUCP (06/15/87)
> It occurs to me that the reason for including the concepts "Session" > and "Connection" in the ISO/OSI model is precisely because PPTs are accustomed > to charging by the (name your time unit) for a connection between two points. > (i.e. DM0,45/minute from Frankfurt-am Main to Bad Nirgensplatz, Bavaria) > It is easier to machine titanium than to try to change bureaucratic > ideas (sic) of "the way the world really is -- and should be"! I often say that the reason the PTTs are so anti-datagram is because without connections, there's no way to charge for connect time. I used to think I was joking; not any more. Phil
ken@rochester.UUCP (06/16/87)
|I often say that the reason the PTTs are so anti-datagram is because |without connections, there's no way to charge for connect time. I used to |think I was joking; not any more. Not all PTTs are so anti-change. Several years ago Telecom Australia announced Austpac, a datagram service to be charged by the octet. Don't know if it took off though. Analog to digital converters and digital switching technology offer unification of voice and data handling. A generation of managers used to SxS or crossbar technology may resent digital. Then again upgrading to digital while maintaining compatibility is not an easy job. Ken
ast@botter.UUCP (06/17/87)
In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: >I believe that Andy knows what he is talking about and I would certainly >be interested if he would expand on the criticisms he mentions in his posting. Ok. For one thing, I think the session layer is ridiculous. All it really does is keep track of whose turn it is to talk and do some checkpointing. I think most applications know whose turn it is to talk. If I am addressing an editor on a remote machine, we really don't need a whole layer to keep track of whether I am allowed to type or it is the editor's turn to say something. In the British proposal to ISO years ago, there was no session layer. I think they were right. The session layer was probably included because IBM had one, and people must have assumed that if IBM did it, it must be a good idea. I am not convinced that there are enough applications that use the session layer to make it worth having. The ARPANET model does not have any session layer and I have never heard of anyone saying he needed it. The presentation layer. It is practically empty now. All that seems to be left is ASN.1 and ASN.2, which are several hundred pages of mumbo jumbo for the purpose of telling which order the bytes are in (VAX, Intel = little endian) vs. (68000, IBM 370 = big endian). This seems overkill to me. Encryption. ISO seems to be totally unable to get its act together. Other than unambiguous statements that encryption does not belong in the session layer or physical layer, it seems that all others are possible, although lately I have been hearing noises that maybe presentation is "in" again. I think spreading it out all over the place is a disaster. Logically I think it belongs in presentation--it deals with "meaning" in some sense. In any event, the current situation is a disaster. Andy Tanenbaum (ast@cs.vu..nl)
karn@faline.UUCP (06/18/87)
In article <1214@botter.cs.vu.nl>, ast@botter.UUCP writes: > Encryption. ISO seems to be totally unable to get its act together. Other > than unambiguous statements that encryption does not belong in the session > layer or physical layer, it seems that all others are possible, although > lately I have been hearing noises that maybe presentation is "in" again. > I think spreading it out all over the place is a disaster. Logically I > think it belongs in presentation--it deals with "meaning" in some sense. > In any event, the current situation is a disaster. I think there are some good reasons for encrypting at more than one layer. End-to-end encryption is the most effective way to keep a message's contents private, especially if you want to use any available network (e.g., a PDN), since nothing in the network need be trusted. There is probably something to be said for encrypting anything that the network doesn't absolutely have to have to do its job, so you might as well encrypt the transport header as well. In other words, encrypt on an end-to-end basis on the interface between L3 and L4. However, end-to-end encryption doesn't protect you against traffic volume analysis by someone outside the network monitoring its links, so encryption on a per-link layer is still necessary. The only remaining threat then becomes traffic analysis from within the network itself. This is virtually impossible to prevent since the network must have readable addresses in order to do its job; about the only thing you can do is generate lots of garbage traffic to random destinations to spoil their statistics -- IF you happen to have money to burn (i.e., work for NSA). You could go further and build a hierarchy of networks with encryption in each. For example, you could build a TCP/IP Internet where the gateways use X.25 public networks (possibly having internal encryption) to pass encrypted IP datagrams which themselves contain end-to-end encrypted TCP data segments. A dishonest subnet could then only analyze a fraction of the total Internet traffic, and those observations would be much less precise because of the (hidden) multiplexing and routing changes going on at the IP layer. It is entirely possible that one of the unstated reasons for DoD's insistence on datagrams is to allow "gratuitous rerouting" (i.e., route changing not necessitated by link failures or congestion). This would be yet another technique to foil traffic analysis attempts at the lower layers. So redundant encryption still makes sense, so that the lower the layer, the less trusted its components have to be. Phil
aweinste@Diamond.BBN.COM (Anders Weinstein) (06/18/87)
I thought that the OSI Session layer was derived from the CCITT Teletex protocol (S or T.62). I believe most of the OSI Session-layer operations are just Teletex session functions couched in more abstract terms, ie. "activities" correspond to Teletex "documents", OSI synch points correspond to pages, etc. Not that this makes it a good idea or anything...
howard@cos.UUCP (06/19/87)
In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > >I believe that Andy knows what he is talking about and I would certainly > >be interested if he would expand on the criticisms he mentions in his posting. > Encryption. ISO seems to be totally unable to get its act together. Other > than unambiguous statements that encryption does not belong in the session > layer or physical layer, it seems that all others are possible, although > lately I have been hearing noises that maybe presentation is "in" again. > I think spreading it out all over the place is a disaster. Logically I > think it belongs in presentation--it deals with "meaning" in some sense. > In any event, the current situation is a disaster. > The reason encryption can be defined in multiple layers is that encryption is used for different purposes in different layers. The usual view of encryption is that it is intended for protecting information from viewing by unauthorized readers. This is not always true; disclosure of contents in, for example, many financial applications is no major threat, but real problems could be caused by replaying legitimate information. It can be appropriate to encrypt the message number part of a credit authorization message. Protection from duplication/replay, sender authentication, avoidance of repudiation of reception (e.g., registered letters), all are reasons to encrypt in the application layer. Transport-layer encryption protects message contents on an end-to-end basis. If encryption is done at the transport or presentation layers, however, message headers must be in clear (or a different cryptosystem) so that the network and data link layers can extract information needed to route messages. In some applications, such as tactical military systems, it can be important to protect against traffic analysis: gaining information by knowing how much traffic, at what times, are being sent from one endpoint to another. To protect against traffic analysis, the link level must be encrypted or physically protected. Again, this is only needed if traffic analysis is a concern, or, if for administrative reasons, it's easier to distribute encryption keys on a link-by-link rather than end-to-end basis.
nguyen@amd.UUCP (06/20/87)
In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <3002@pyramid.UUCP> sas@pyramid.UUCP (Scott Schoenthal) writes: > >I believe that Andy knows what he is talking about and I would certainly > >be interested if he would expand on the criticisms he mentions in his posting. > > Ok. For one thing, I think the session layer is ridiculous. All it really ... I don't think this comment is neccessarily constructive. It is too early to remove the session layer altogether from the ISO's OSI. The development for most upper layers protocols has not proved maturity for everyone to accept as standards and NO ONE really know what all layers have to be in the future. There are ton of different applications which can exist in all kinds of networks. Who knows?... I would rather have a null layer to by pass so I can reconfigure the adjacent interfaces when the 'null' is no longer necessarily empty later. Some one proved that the session layer is not null (such as IBM) must have a very good reason for it! As we all know that most network layer implementation are null!!!. This doesn't seem to hurt any body. Quinn Nguyen
kre@munnari.UUCP (06/20/87)
In article <638@faline.bellcore.com>, karn@faline.UUCP writes: > Among the major flaws of the ISO Reference Model are: > > 1. A fixed number (7) of layers. These are just conceptual layers, and they don't (and aren't mean to) include layers in application processes. You can recursively redefine any of those layers as much as you like for whatever purposes are appropriate (eg: level 2 on lans has llc and mac, but its all still level 2 .. point to point). > 2. It completely ignores internetworking. This is rubbish. > They claim you don't need all that reliability [TP4] if you're running on a > PTT network, but of course the real reason is that they're scared to > death of internetworking. There's no way a PTT is going to allow it to > happen unimpeded. I think your arguments about PTT fears need a little examination. Most of the world's PTT's don't need standards to control the world's networking (this is outside the US). In most countries the PTT's have a legal monopoly, they don't need this kind of extra second hand pseudo-protection. I have no love for PTT's and their regulations, however before discounting all their arguments, its worth placing yourself in their position for a while. Let's indulge in a little whimsy. Imagine yourself offered the job of director general (or whatever its called) of the arpanet (and nsfnet, span, csnet, etc for fun). You're naturally overjoyed, as quite apart from the 6 (or perhaps 7) figure salary, you're finally going to be able to stamp out all this OSI nonsense on the arpanet, and get things finally back on the straight and narrow of TCP/IP. So far, so good, everything's running smoothly, until one day there's a rash of "hacker" breakins at military institutions doing weapons research, and evidence is that this comes from the educational (research) side of the net .. the part you are in control of. Big stink in the press, congressmen up in arms, the lot. Of course, no-one suggests that OSI would have been any better (that's not my point). But, finally someone raises a question... the US goverment (the taxpayer) is paying for these hackers to wreak havoc on the US national security, Why? This must be stopped at once. In one of those amazing happenings in the US congress and Senate a bill is passed, and receives Presidential assent, all within a day. It denies any goverment funding to the networks. Not only direct funding, but indirect funding through research grants, contracts, etc, and denies tax deductions for gifts to any organizations that use any of the gift for networking purposes. Congress is really mad! Now, you have something of a problem. Here you are in charge of this network that has no money, and the bills are starting to come due. How are you going to solve this problem? You can try and get people to donate funds out of the goodness of their hearts, but somehow I doubt that is going to work. You're likely to have to reach the position where you have to actually charge real money to the people who use your networks. You're more or less in the position of the PTT's in the rest of the world, you're running a business, and you have to at least break even, if not make a profit, or your network collapses. It might be instructive to explain how, with the current internet setup, and using the standard IP based protocols (which of course you have the authority to change if you want) you are going to make all this work. Nb: I mean the whole internet here, including all those sites that have slip, and csnet x.25, links to the lucky few on net 10. > I have nothing > against migrating to an international standard if it is provably > superior to what we have (e.g., the metric system vs the English system) > but this is *not* the case with OSI in its present form. You're right, OSI is not ready for use yet, it needs some more work (though many of the individual protocols are perfectly ok). But asking for it to be provably superior is asking too much. It might never achieve that in the sense you mean. What it will be is demonstrably more widely available. That is, one day you will be able to connect to us (in Australia) using OSI. Chances are you never will be using TCP. Which is strange, as we run TCP now, so do you. Neither of us runs OSI... (But the US government won't allow us to connect to you using TCP, we would have to get some special dispensation to allow packets from outside the US onto the arpanet, and that's simply not worth bothering with). We could set up some direct TCP link (possibly over an X.25 carrier..., it would certainly be over some PTT carrier, as that's all that's available) but then you would have to take special precautions to make sure none of our packets escape. What great internetworking! Remember that continually bemoaning the lack of readiness of the ISO protocols does nothing to help them get completed. You'd be better assisting ISO, I know that you have lots of TCP knowledge, you must have plenty of experience that would be quite valuable, and perhaps you could be helping to prevent some of the mistakes that you see ISO making, instead of just complaining about them. kre ps: Phil .. mail to you on the backbone list is being addressed to bellcore!bellcore.com!karn (or something similar) and is making bellcore's mailer dump core (SIGSEGV), you might want to look into that.
kre@munnari.UUCP (06/20/87)
In article <354@sol.ARPA>, ken@rochester.arpa (Ken Yap) writes: > Several years ago Telecom Australia > announced Austpac, a datagram service to be charged by the octet. Don't > know if it took off though. Not like that it didn't .. Austpac exists, but charges the same way essentially all other X.25 networks do, by segment (1 .. 64 octets) and by time. Incidentally, the x.25 nets that charge by segments (and time) are generally much cheaper than the odd one that charges by octets, as long as you're rational in your use of the resources .. if you send 1 character packets, you lose big, but so you should, those things (on any network) are very wasteful of resources. kre
samlb@well.UUCP (Samuel B. Bassett) (06/21/87)
Harrumpf! The process of achieving _reliable_ communication over a network is difficult enough. _Secure_ communication is a whole order of magnitude more work, and should be left to the spooks -- when they _really_ need it, they will provide it on their own lines, and in their own formats. As I understand it, the purpose of the various layers should be to insure that a proper package is wrapped around the "data" that each layer receives from the next 'higher' layer, so that the (otherwise unexamined) contents of the data get where they are expected to go, and can be interpreted correctly when they get there. The contents of the data at each stage can be 'plaintext' or 'cryptext' -- the protocol handler should not care one way or the other. Let's not complexify the situation out beyond the state of the art! -- Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale! 34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282 UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb; Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassett
howard@COS.COM (Howard C. Berkowitz) (06/23/87)
In article <933@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes: > In article <8613@amdahl.amdahl.com> chuck@amdahl.UUCP (Charles Simmons) writes: > >In article <920@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: > >>IEEE 802.2 and ISO level 2 puzzle me as well. These are protocols for > >>the communications subnet and I don't quite understand why IEEE and > >>ISO are trying to define communications subnet protocols for all time. > >>Shouldn't communications subnet protocols be medium-dependent? > > >Actually, if you look closely at 802.2, you'll notice that the IEEE > >defines an interface within the datalink layer. 802.2 defines > >the logical link control layer, and is, and should be, medium-independent. > >Underneath the logical link control layer there exists a medium > >access control layer which is, naturally, highly medium-dependent. > > No, this is incorrect because the supposedly medium-independent part > of the level 2 (logical link control) is basically a member of the > X.25 level 2 like family of protocols. These protocols make or > enforce some very specific assumptions about the medium and how you do > networking. They assume you really want to establish a perfect > virtual wire at level 2 on a relatively noisy telephone-line-like > medium and that you either never do internetting or will do so at the > cost of some very complicated flow control procedures. They also > assume you will not have transmit windows at higher protocol layers. > NO to the No! There are several classes of Level 2 LLC (Logical Link Control; IEEE 8802/2). Type I is connectionless and does not ^^^^^^^^^^^^^^ ^^^ try to provide a "perfect virtual wire;" it is significantly different from the LAP-B HDLC-style link protocols used for the X.25 family, LLC Type I has been adopted as the media-independent part of LAN-environment Layer 2 by the NBS OSI Implementors' Workshop (for 802.3 CSMA/CD and 802.4 Token Bus Media Access Control), by the MAP/TOP User Group for 802.3 and 802.4, and by the Corporation for Open Systems (for 802.3, 802.4, and 802.5 Token Ring). By contrast, COS adopted ISO 7776 as the link control layer for X.25 WAN applications, another example of how practical OSI protocol stacks do not require only one protocol at each layer. > > This family of protocols was developed for the PTTs which have a very > specific type of medium and have some very specific constraints on the > type of services they can provide and on the type of services which > they want to provide. The PTTs consider remote terminal sessions and > file transfer to constitute the full range of data communications for > computers. In the worldwide environment, the view of PTT's cannot be ignored. The challenge is interfacing the LAN and WAN environment in the real world, which has political, regulatory, and economic constraints as well as technical ones. PTT's doing packet work are apt to be more amenable to data concerns than "old-line" telephone operating companies, who believe real men do it in 4 kilohertz analog channels implemented on twisted pair. There is hope, however. A few months ago, I presented COS' current activities to ANSI Committee T1, which is the main telecommunications standards body for the U.S. I reminded them that about three years previously, I had been on the T1 task force concerned with developing the workplan for performance/quality of service standards. At that meeting, an old time telephony standards man took me to task about not really understanding how it all worked; that I was up in the theoretical stratosphere of X.25. At the T1 meeting recently, I found that same old-timer in the bar, complaining how his customers "didn't understand what their software told them; that they simply didn't understand retransmission algorithms in X.25." I pointed out that in three years, our telephony pioneer had moved from below Layer 0 of the OSI Reference Model into Layer 2. I predicted that in 1993, he would be a UNIX hacker developing OSI applications, and we OSI people would have moved into another dimension. (Further discussion on last point to rec.sf-lovers, please. Comments that OSI people already are in another dimension will be routed, using IP if you like, to /dev/null.). -- -- howard(Howard C. Berkowitz) @cos.com {seismo!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [ofc] (703) 998-5017 [home] DISCLAIMER: I explicitly identify COS official positions.
ast@cs.vu.nl (Andy Tanenbaum) (06/24/87)
In article <4122@amd.UUCP> nguyen@amd.UUCP (Quinn Nguyen) writes: >In article <1214@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >> I think the session layer is ridiculous. > > Quinn then goes on to say: >Some one [who] proved that the session layer is >not null (such as IBM) must have a very good reason for it! This is the kind of thinking that led to OSI in the first place. The committee observed. 1. IBM has a 7 layer network architecture. 2. IBM is big and powerful and successful Ergo, if we have a 7 layer network architecture we will become big and powerful and sucessful. Nonsense. It is not desirable to create a giant, ponderous beast that lusts after megabytes the way the cookie monster goes after cookies. St. Exupery said: Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away. Look at the success of RISC machines. Computer architects have learned that what one does NOT need is an unwieldy instruction set that no compiler can produce code for. Adding more instructions and modes and stuff on the off chance that someone will someday need it is foolish. The idea of having a session layer for those few applications that can't keep track of whose turn it is to talk is equally silly. Let them do it as part of the application. I think network architectures (and everything else in the world) should be made as simple as possible, consistent with their intended goal. I think OSI needs to go on a crash diet. Null session layers aren't the way to go. The structural complexity is still there, even if it is dormant for the moment. Andy Tanenbaum