tim@hoptoad.UUCP (08/19/86)
In article <3535@amdahl.UUCP> sjl@amdahl.UUCP (Steve Langdon) writes: >In article <964@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > >> I have done a good deal of work with 4.2bsd networking - my first job at CMU >> was to implement a socket interface for the UNIX SNA done at the Information >> Technology Center. During the course of this work, I came across some >> serious deficiencies in the system. It was almost impossible to fit a >> half-duplex protocol like SNA into the model, and I expect that other >> non-Internet protocols would probably suffer similar difficulties. I was >> forced to add new hooks to the protosw mechanism, for instance. Imposing a >> particular model of networking on all the protocols in the world seems to me >> a highly questionable decision, since no one (ISORMites to the contrary) has >> really formulated a general model of protocols. > >As a card carrying ISORMite I cannot help but take issue with Tim's statements. >His posting shows a basic misunderstanding about the difference between the >protocol used in a layer and the service provided by the layer. The example >he gives is clearly based on different services (ie. half-duplex vs. duplex) >rather than protocol differences. I would be the last person to claim that >the OSI model, service definitions, or protocols are perfect. >However, one of the best things about OSI is the idea of clearly dividing an >abstract service from the protocol(s) which implement it. In this and another recent message (on net.micro.mac), Steve shows his inability to make a point without casting aspersions on the intelligence or character of the person he disagrees with. If he wishes me to take his messages seriously, I hope this will change. In any case, the above paragraph says nothing substantial, and fails to answer my statement concerning the inapplicability of the socket mechanism to SNA. Three of us, two of whom were seasoned SNA hackers, labored for a few months and we were unable to fit SNA into the model without postulating a simulated full-duplex connection formed of two half-duplex connections created by agreeing clients on both ends. All the vague talk in the world about protocols versus services does not answer the inapplicability of the socket mechanism to providing SNA services to application software. >> [discussion of sockets and socket based implementations removed] Why? This omitted section contained most of the substance of my message, and almost the entirety of my demonstration of the poorness of the socket model. Why not omit my whole message? >> The new Bell protocol-independent networking is even worse. You can run >> uucp and cu over Ethernet now. I'd much rather have a poke in the eye with >> a sharp stick. Protocol independence is achieved at the expense of protocol >> functionality, at least as I understood the USENIX papers. > >I have not read the USENIX papers, but I have had many discussions with >Gill McGrath and others at Summit who were responsible for the new >Transport Layer Interface (TLI). I think they did an excellent job of >designing an interface which provides the Transport Service without exposing >protocol implementation details. My objection was based on a misconception that the transport layer interface was the entirety of the system. The stream support should be able to provide all necessary protocol functionality. This doesn't change the fact that I think the transport layer interface is very bad. It defines new protocols, which are the last thing we need, and does so informally, which we should all have been scared away from by uucp. Finally, it is limited to SV.3 to SV.3 connection. >I should add that my praise for this >example does not mean that it is necessary, or desirable, to view all OSI >layer interfaces as software module interfaces. Efficiency will often >require layers to be implemented without an exposed "service" interface. I could not possibly disagree with you more. If you have not provided a software interface for a protocol except one usable by higher-level protocols in the same project, then you have not provided the protocol. If a protocol is designed in such a way that no efficient software interface can be provided, then the protocol has been very poorly designed. >> It seems to me that protocols should be implemented in a freer way, with the >> impossibility of protocol independence recognized. ... > >If you follow this argument to its logical conclusion you would also eliminate >stdio and many of the IO abstractions which are central to the success of Unix. Not at all. There is a great difference between a good model and a bad model. The UNIX file descriptor mechanism is a good model for files and devices of most kinds. The services of nearly all devices can be fit rather cleanly into the model. My point was that just this quality is lacking in the socket mechanism. A bad common model, which sockets are, is more restrictive and awkward than no common model at all. >What is your objection to the mechanism provided by System V Rel 3 streams? >It allows user programs to pass protocol specific information to kernal >resident protocol stream modules or drivers. Use of the TLI is encouraged >where appropriate, but the general case is still covered. This was certainly not stressed in the presentation. I have just reviewed the paper and this appears to be correct. As we all know, streams are a classic elegant Ritchie solution. They also fit my criterion for an extended system call mechanism (as do normal special file ioctls). I believe I was misled by the enthusiams for the transport layer interface at the expense of discussion of the stream interface, but in any case, I withdraw my objection to SV.3 networking support. It does appear to be sufficiently non-restrictive, and also to allow modular protocol development. >> Let's not get bogged down in questions of implementation at first; I would >> like to see discussions of the merits and demerits of these three approaches >> to networking on UNIX, however. > >I may have seemed rather harsh on Tim, but that was not my intent. In fact, >he presented his views in enough detail so that a reasoned response was >possible. Unfortunately, many others who voice opinions do not offer enough >information to allow a specific reply. I'm glad to know a reasoned response was possible; I eagerly await it :-). -- Tim Maroney, Electronic Village Idiot {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa) Bibliolatry is my bizarreness.
guy@sun.uucp (Guy Harris) (08/19/86)
> This doesn't change the fact that I think the transport layer interface > is very bad. It defines new protocols, which are the last thing we need, > and does so informally, which we should all have been scared away from by > uucp. Do you mean new protocols for communication between "service providers" on different machines, or new protocols for communication between protocol layers in a stream? > Finally, it is limited to SV.3 to SV.3 connection. How so? Presumably, a program using the TLI library can do a "t_open" to get a handle on, say, the TCP module, and then do a "t_connect" to connect to a given Internet address and port number. At this point, the descriptor can be used to send data to, and receive data from, the service corresponding to that port number on the host corresponding to that address, regardless of what OS that host is running. Some particular protocol implementations may be poorly done, so that they assume that the other implementation is "just like them", but I don't see how the TLI kernel-level or user-level interface precludes doing it right. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
soren@olamb.UUCP (Soeren Rabbe) (08/25/86)
Without interfering with the discussion on UNIX(R) streams, I would like to give some comments on the part of the discussion covering the OSI Layers. In article <1019@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >In article <3535@amdahl.UUCP> sjl@amdahl.UUCP (Steve Langdon) writes: >>In article <964@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >> . . . >>I should add that my praise for this >>example does not mean that it is necessary, or desirable, to view all OSI >>layer interfaces as software module interfaces. Efficiency will often >>require layers to be implemented without an exposed "service" interface. > >I could not possibly disagree with you more. If you have not provided a >software interface for a protocol except one usable by higher-level >protocols in the same project, then you have not provided the protocol. If >a protocol is designed in such a way that no efficient software interface >can be provided, then the protocol has been very poorly designed. It is my impression that some clearifications can be needed on this point. All "lower-level" protocols are made to be usable *only* for the higher-level protocols, i.e., layered protocols are made to structure the functions of the transmission service, not to exist by them self. What all the protocols in a layered model ends up with is a service provided by the highest lay- er - in OSI the Application Layer. But this does not imply that the service interface must follow a standard or even exist within a system to say that the system follows a given architecture or, if the protocols implemented are "OSI protocols", to say that the system is a Open System. In the OSI Basic Reference Model (ISO International Standard 7498) it is said (Sec. 6.2 Note 2): "2 It is important to note that OSI *per se* does not require interfaces within open systems to be standardized. Moreover, whenever standards for such interfaces are defined, adherence to such international interface standards can in no way be considered as a condition of openness." This is the same as saying that the "openness" of a system is only determined by the protocol interface and not by the internal service interfaces. Then, if the system by itself does not include all layers or it is the intention that users should have the possibility to add there own functions; e.g., special higher layers, it would be very bad design not to provide at least some very well define service inter- faces internal in the system. I hope these points can be helpfull in future discussions on this topic. I have a weak point when the discussions takes the OSI Basic Reference Model and the model introduced by the standard as a "Bibel" without identifying the scope of it [:-)]. N.B.: The opinion expressed hereby is purely on the behalf of the undersigned and have no connection to my membership of the Danish OSI Standard Committee (equals ISO TC97/SC21). -- ---------------------------------------------- Soren Rabbe AmbraSoft A/S, Denmark soren@olamb.UUCP
sjl@amdahl.UUCP (Steve Langdon) (08/29/86)
In article <1019@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) quotes my reply to his original article on this topic. He then writes: > ... > In this and another recent message (on net.micro.mac), Steve shows his > inability to make a point without casting aspersions on the intelligence or > character of the person he disagrees with. If he wishes me to take his > messages seriously, I hope this will change. Tim and I will need to discuss this privately. I have no desire to fight with him on the net. I respect his work, and I may have over-reacted to his habit of expressing his views strongly. I try (but may not always succeed ) to keep my criticisms muted, and react when I think someone is being unfair or giving a one-sided view. Returning to the technical aspects, in response to his description of the difficulties in implementing SNA using sockets, I said: < As a card carrying ISORMite I cannot help but take issue with Tim's statements. < His posting shows a basic misunderstanding about the difference between the < protocol used in a layer and the service provided by the layer. The example < he gives is clearly based on different services (ie. half-duplex vs. duplex) < rather than protocol differences. I would be the last person to claim that < the OSI model, service definitions, or protocols are perfect. < However, one of the best things about OSI is the idea of clearly dividing an < abstract service from the protocol(s) which implement it. Tim's reply was: > In any case, the above paragraph says nothing substantial, and fails to > answer my statement concerning the inapplicability of the socket mechanism > to SNA. Three of us, two of whom were seasoned SNA hackers, labored for a > few months and we were unable to fit SNA into the model without postulating > a simulated full-duplex connection formed of two half-duplex connections > created by agreeing clients on both ends. All the vague talk in the world > about protocols versus services does not answer the inapplicability of the > socket mechanism to providing SNA services to application software. I think that one of the reasons Tim was upset at my reply is that he was (in large part) attacking sockets (see below for evidence). Defending sockets was not relevant to the points that I was trying to make. I still believe that he is confusing the system interface mechanism issues with the problems created by incompatible services. Most of the Arpa protocols use a full-duplex service model; SNA tends to use half-duplex, although it can support full-duplex (I am talking about the SNA session level). > >> [discussion of sockets and socket based implementations removed] > > Why? This omitted section contained most of the substance of my message, > and almost the entirety of my demonstration of the poorness of the socket > model. Why not omit my whole message? I try to avoid long quotes - most people have the original available, and as I said above, I was not agreeing with or disputing your comments about sockets. I then defended the AT&T defined Transport Layer Interface (TLI). Tim's reply was: > My objection was based on a misconception that the transport layer interface > was the entirety of the system. The stream support should be able to > provide all necessary protocol functionality. This doesn't change the fact > that I think the transport layer interface is very bad. It defines new > protocols, which are the last thing we need, and does so informally, which > we should all have been scared away from by uucp. Finally, it is limited to > SV.3 to SV.3 connection. Once again I think this is an example of failing to distinguish between two different things, in this case an interface and a protocol. The TLI does not define a protocol; it defines an interface that closely follows the model provided by the abstract Transport Service definition. Moving on to interfaces. I said: < I should add that my praise for this < example does not mean that it is necessary, or desirable, to view all OSI < layer interfaces as software module interfaces. Efficiency will often < require layers to be implemented without an exposed "service" interface. Tim replied: > I could not possibly disagree with you more. If you have not provided a > software interface for a protocol except one usable by higher-level > protocols in the same project, then you have not provided the protocol. If > a protocol is designed in such a way that no efficient software interface > can be provided, then the protocol has been very poorly designed. I think that my choice of words may have confused the issue. The word "exposed" was intended to mean "generally available" - in other words, usable by a broad class of programs rather than other specialized software in the layer above. The above explanation notwithstanding, I find Tim's claim that this means that "you have not provided the protocol" difficult to understand. Using SNA as an example, VTAM does not provide interfaces to the protocols that implement the Virtual and Explict Routes. Does this mean that they have "not provided the protocol"? The discussion then moves to "protocol independence". Tim said: > It seems to me that protocols should be implemented in a freer way, with the > impossibility of protocol independence recognized. ... I replied: < If you follow this argument to its logical conclusion you would also eliminate < stdio and many of the IO abstractions which are central to the success of Unix His response was: > Not at all. There is a great difference between a good model and a bad > model. The UNIX file descriptor mechanism is a good model for files and > devices of most kinds. The services of nearly all devices can be fit rather > cleanly into the model. My point was that just this quality is lacking in > the socket mechanism. A bad common model, which sockets are, is more > restrictive and awkward than no common model at all. Once again a misunderstanding; I was not discussing sockets. I was using this point to illustrate that the Unix use of the file as an abstract interface is quite similar to the OSI concept of a (protocol independent) service. The discussion then moves to the basic streams interface. I said: < What is your objection to the mechanism provided by System V Rel 3 streams? < It allows user programs to pass protocol specific information to kernal < resident protocol stream modules or drivers. Use of the TLI is encouraged < where appropriate, but the general case is still covered. Tim replied: > This was certainly not stressed in the presentation. I have just reviewed > the paper and this appears to be correct. As we all know, streams are a > classic elegant Ritchie solution. They also fit my criterion for an extended > system call mechanism (as do normal special file ioctls). I believe I was > misled by the enthusiams for the transport layer interface at the expense of > discussion of the stream interface, but in any case, I withdraw my objection > to SV.3 networking support. It does appear to be sufficiently > non-restrictive, and also to allow modular protocol development. I am glad that we have finally found an issue about which we agree. Once again I stress my interest in a constructive debate. I am sorry my last posting failed to avoid animosity, but I hope this one will not cause further offense. -- Steve Langdon ...!{decwrl,sun,hplabs,ihnp4,cbosgd}!amdahl!sjl +1 408 746 6970 [I speak for myself not others.]