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
richards@ditmela.UUCP (06/12/87)
In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) 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. To the entent that everyone agrees that networking should be performed by layered "entities" communicating with layer protocols and each layer using the services of *a* layer below it and providing services to *a* layer above it, then probably everyone (even Mike Padlipsky!) is in agreement. Of course the OSI Reference Model goes much further than that, eg. it precludes "layer skipping", ie. a layer using the services of a layer not directly below it. Furthermore, IS 7498 SAYS there are SEVEN layers and says roughly what their purposes are. You will have a lot of difficulty getting some people to agree with that. >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.) First, it goes without saying that the OSI reference model achieves very little towards interoperability (how many times have you seen Sales brochures using disgustingly misleading phrases like "our networking complies with the OSI Model"?) Standards are about interoperability. ISO standards exist for protocols up to layer 5, Presentation is about to go to IS status as are a number of Application Layer standards including FTAM. Down at layers 1-3, the IEEE 802 standards are becoming IS8803 and the connectionless network protcocol (equivalent in most senses to IP) is already an international standard. So make no mistake, the standards ARE here and the weight of support for their adoption is enormous. Frankly, the possibility of TCP/IP becoming part of the OSI "suite" is long since past, and before people criticize that, make sure you have examined ISO TP-4 in comparison with TCP. In any case, irrespective of the technical merits of any of the OSI protocols, acceptance of what is standard rather than what is best is unfortunately necessary. This was the view expressed in message <1680@munnari.oz> where kre@munnari.oz (Robert Elz) writes: >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. >There's absolutely no hope of a technically perfect standard, especially >not in any area where there's any dispute about what is perfect. Unfortunate, but so, so true. In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) continues: >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. and also >I would like to see a discussion of this subject, preferably by people >who know what they are talking about. First, I thoroughly agree with the the last statement. We need more discussion and we need it from people who know what they are talking about. Given the FACT that OSI standards will happen, the closer we can go to getting them right the better! Unfortunately there are many contributions on the net and elsewhere (Padlipsky's book is an example) from people who in my view have seen some early OSI stuff, have said "It'll never work" or "What's wrong with Arpanet?" and they haven't even attempted to keep up to date with the latest development in OSI. So let's have input from people who know what the latest standards say. One could write a whole book on the two questions raised above, and indeed day by day, experts all around the world are contributing comments to Standards Committees for consideration in the further development of standards. For the time being, let me summarise what I see as the biggest single problem with the OSI Model: THE ROLE OF THE PRESENTATION LAYER. One problem arises with Message Handling systems (a la X.400 which is currently being standardized by ISO also, and there is a commitment for complete alignment of X.400 and the corresponding ISO standards). X.400 provides for a kind of "sub-layering" in the Application Layer with the higher layer handling particular message types, eg. Inter Personal Messaging (Mail) and the lower layer handling Message Transfer. The reference model says that the encoding ought to be done by the Presentation Layer so the message passed to the Message Transfer Sub-Layer must (at least conceptually) be unencoded. X.400 provides for relaying so that the message may be received by a Message Transfer Agent (MTA) on an intermediate machine (or several) which will forward it on to another MTA, eventually reaching the right machine which where the MTA will pass the message "up" to a User Agent, ie. it will deliver the mail. Now the Presentation Service (quite properly) provides for different parts of the data to be encoded in different ways so that for instance, the Message could be encrypted. But how does the Presentation Layer on the intermediate machine (which we assume for security reasons doesn't have the capability to decrypt the message) unencode the message so it can pass it up to the MTA? Well of course it can't, and indeed the situation couldn't have arisen because the two communicating Presentation Entities would have failed in their attempts to negotiate a common transfer encoding. What is the solution? Well, in my view, the Presentation Layer doesn't belong as a true Layer in the OSI model but should instead be provided as a so-called Application Service Entity (ASE) that can be used by other parts of the application layer as and when they see fit. There is nothing wrong with having another ASE - there are already quite a few of them (Remote Operations, Reliable Transfer, Commitement Concurrency and Recovery just to name three). A Presentation ASE could still negotiate with its peer, but another part of the Application layer, eg. the MTA described above, could choose if and when it wants to use it. This contribution has gone on long enough, but it should also be stated that there are other problems with the positioning of the Presentation Layer that have to do with applications that want to do checkpointing, but because they are dealing with unencoded data, they don't have any concept of data size and thus where checkpoints should be placed. Perhaps we can pursue that problem in another article. Ian Richards.
martillo@bloom-beacon.UUCP (06/15/87)
Personally, I have always found this confusing because I have read the ISO documents and have never seen anything which implies there must be only one protocol at every layer. Further, I thought swap in and swap out of protocol layers should be possible. TCP and IP are tailored to each other but I have seen nothing which implies that TCP could not run over ISO IP or which implies TP4 could not run over IP. In fact there might be reason to tailor a transport protocol for certain classes of protocols. A remote virtual disk server for a PC can certainly get quite hosed when the PC is unexpectedly turned off, why should the host also have to deal with abnormal termination of the transport layer. Perhaps VCs at level 4 are not always a good idea. Unfortunately TP0-TP4 are all VC oriented (I'm not sure) maybe a UDP like level 4 should be defined, in fact maybe remote virtual disk applications are sufficiently unique that a special level 4 should be defined. In any case I don't quite understand why IP and ISO IP can't be coresident in the network. The communications subnet protocol will have some way of indentifying the level 3 protocol to the host level 3 layer software (like the type field in ethernet 2.0 or like ssap/dsap tuples in IEEE 802.2) 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?
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.
kre@munnari.UUCP (06/20/87)
In article <1818@ames.UUCP>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > X.25 (level 3?) will, it seems, be used as an > alternate "level 2.5" protocol. Is 802.2 also considered "level 2.5"? > Is there a draft standard on this yet? What ISO number is it? Here are a bunch of numbers .. IS 8348 Network service definition (this says what you can expect the network layer to do for you, and if you're implementing any network protocol, what services you must provide). IS 8348 AD 1 Network service definition addendum 1, Connectionless-mode transmission (ie: datagrams) DP 8880 Specification of protocols to provice and support the OSI network service part 1: General principles part 2: provision and support of the connection-mode service part 3: provision and support of the connectionless- mode service DIS 8878 Use of X.25 to provide the OSI connection-mode network service (this is what fills in the last .5 to turn the "2.5" layer X.25 into layer 3) DIS 8208 X.25 packet level protocol for data terminal equipment (this is 1984 X.25) DIS 8473 Protocol for providing the connectionless-mode network service (see also also DAD 1, and PDAD 2). DIS 8648 Internal organization of the Network Layer There are other level 3 related protocols (DP 9542, "End system to intermediate system routing exchange protocol for use in conjunction with ISO 8473", and DP 9068, "Provision of the connectionless network service using ISO 8208", are two that might be relevant) ISO 8802/2 (IEEE 802.2) is a link level protocol, as it provides only point to point service (from one host, across a LAN, to another). Contrary to what some others have implied, or even stated as fact, ISO layer 3 is an *internetwork* protocol, with exactly the same function in the overall scheme of things as IP has in the DARPA protocols. In this are you might want to look at DIS 8881-1 "Use of the X.25 packet level protocol in local area networks, Part 1: use with LLC Type 1 procedures" and DIS 8881-2 "... Part 2: use with LLC Type 2 pricedures". While I'm rambling, I should also point out, that most people making noises about IEEE 802.2 (8802/2) are considering only LLC Type 2, which is the thing that looks a little like X.25 (or hdlc). Remeber that LLC Type 1 exists too, which is a protocol about as complex as old form xerox/dec ethernet (and might go unnoticed because its just a couple of pages in the 802.2 book). Robert Elz kre@munnari.oz.au
kre@munnari.UUCP (06/20/87)
In article <2886@oberon.USC.EDU>, blarson@castor.usc.edu (Bob Larson) writes: > Some implementations of x.25 do not realize that no further data will be sent, > so have to time out before the packet is sent. Any X.25 implementation that does that is 100% bogus, and I actually doubt that there are any such implementations. However, X.28 does have this "feature". (This is what you get when you connect to X.25 via a PAD). However, it can be controlled in various ways, most of which, due to completely hopeless PAD implementations, work against one another to kill performance, when a little more intelligence (on the part of the implementor) could make it all work passably well. However, please don't judge X.25 (which is what would be used for any ISO networking) by the failings of X.3/X.28/X.29 which are total trash. Also, if you claim that any standard that allows this behaviour is no good, then you have just condemned TCP. TCP is not bound to deliver any data unless PUSH is set. I could easily implement a TAC (PAD) that never set PUSH (or only set PUSH after a timeout, just to see if any more data is coming...). kre