tim@hoptoad.uucp (Tim Maroney) (08/11/86)
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.
This is particularly true since there is nothing in particular to recommend
the socket mechanism from a user interface perspective. The only possible
recommendation would be protocol-independent software, and I think we all
know by now that this simply is not provided. The meanings of the
"standard" primitives differ from protocol to protocol, and it is neccessary
to put in per-protocol cases in switch statements, which is definitely not
protocol independence.
This is even admitted by the way the Internet protocols are implemented.
Generally, a protocol implementer creates a protocol library which calls the
socket mechanism in order to provide protocol services in a straightforward
way. This is no improvement over using special files and ioctl calls, and
in fact can be expected to incur additional context switching overhead as
multiple system calls are used to implement conceptually single protocol
operations.
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.
It seems to me that protocols should be implemented in a freer way, with the
impossibility of protocol independence recognized. An extended system call
mechanism seems the only good solution. Each protocol would offer its own
system calls to user and kernel software. This is essentially the way
sockets work now, albeit in a dishonest manner. People who judge the
quality of a UNIX system by its number of system calls will no doubt scream,
but this is a simplistic and illusory criterion. The socket mechanism
introduces even more complication; not only is it neccessary to know how the
protocol works, but one must find out (in what is usually rather sparse and
sketchy documentation, because it is not clear how to define a whole
protocol suite in a man page, unlike system calls) how the protocol maps
into the socket mechanism, and which functionality has been left out or
resigned to the ultimate admission of failure in sockets, the options
mechanism. The use of new system calls for each protocol would actually
amount to a significant simplification of networking.
The implementation of such a mechanism is of course open to question. I am
partial to using a special trap instruction, passing arguments on the stack
as usual, and passing a module id and routine selector in registers set
before invoking the trap, but there are a number of other alternatives.
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.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
Please stop using disclaimers. I invented them because I had to. Unless
you are in a similar situation of employer harassment, you have no need of
one, and they're darned annoying.sjl@amdahl.UUCP (Steve Langdon) (08/12/86)
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. > [discussion of sockets and socket based implementations removed] > 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. 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. > 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. > [discussions of mechanisms for protocol dependent system calls removed] 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. > 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 have directed followups to net.dcom which appears to be the most suitable group to continue this discussion. -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]
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)
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.]