Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!ukma!husc6!m2c!jjmhome!cpoint!martillo From: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) Newsgroups: comp.protocols.iso Subject: Re: TCP/IP vs. OSI Performance Message-ID: <2201@cpoint.UUCP> Date: 4 Apr 89 01:08:04 GMT References: <529@skep2.ATT.COM> <9882@megaron.arizona.edu> <14957@bellcore.bellcore.com> <9896@megaron.arizona.edu> <9910@megaron.arizona.edu> Reply-To: martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. Lines: 273 In article <9910@megaron.arizona.edu> jms@mis.arizona.edu (Joel M. Snyder) writes: >In article lear@NET.BIO.NET (Eliot Lear) writes: >>An IP address does not imply a >>route. Given an address and nothing more, one cannot determine a >>route. Never-the-less, in order for an Internet to be well connected, >>routing information about an address must be kept, if nowhere else, at >>the entrance points to an internet (in the simplest case). I see >>things from the DARPA Internet point of view. How is routing done >>with ISO IP? >In IP, an address does imply a route. For example, the address of >a hypothetical CPU is 128.196.3.12. This is a class B address, so >the Internet knows that it has to know where 128.196.x.x is, and >the routing is hierarchically dealt with from there. I understood the original routing scheme of the Arpa Internet to be flat-routing between networks. Later, as a need developed for more structure within a local administration (in particular how to handle multiple physical networks within one class B network), subnetting techniques were introduced kludge to permit multiple physical networks within one administrative networks. I guess this is hierarchical in that routing is handled first among networks and then is handled within networks. Still this was not part of the original design, and subnetting is hardly obligatory. If some network authority wanted to develop their own non-hierarchical system, nothing stops them which seems utterly reasonable because I want complete and total control over how packets are routed within my network and for security I don't want anyone outside of my network to have any idea how I might be doing it. >If I move that CPU to some other campus, the address must change, because >the address implies a route (note that the NAME doesn't have to >change; just the address). Which does not seem horrible but is wrong within the domain system in that if I take my portable PC (lower_slobovia) and plug it into an MIT LCS network, its name is lower_slobovia.LCS.MIT.EDU. When I use my network at clearpoint its name is lower_slobovia.RESEARCH.CLEARPOINT.COM while at my home office its name is lower_slobovia.AOR.COM. By the way, I expect to have so many portable PCs within the next year or so that the only real solution is dynamic assignment of IP addresses, so that I would expect the addresses of the machines to change everytime I turn them on. I really have no idea what Snyder is worrying about here. >More subtly, given a campus 128.196.x.x, where there are multiple >routes from that campus to the "world," the IP addressing/routing >schemes require that one manually insert any routing information >which isn't "fewest hops" in nature, and even then, the autonomous >system aspect of IP doesn't necessarily allow that minimal information >to flow from a campus to some other site. As an example, again, >given that Arizona is connected to Purdue, Utah, and JVNC, it is >pretty obvious that Purdue knows not to go through either Utah or >JVNC to get to Arizona. However, the next stop from Purdue, let's >say Indiana (hypothetically), has to manually be taught the Internet >topology, and can't learn the best way to get from here to there. So the gateways at Indiana don't talk EGP and they don't listen to ICMP redirects. That seems to be their problem not the addressing scheme of IP. >In any case, it's the addressing scheme which restricts the >routing scheme. Now Snyder seems to be implying that the absense of routing information and not the implied routing in the IP address is the problem? >Some regional networks (like NSFNET) use a scheme where the entire >topology of the network is learned by routers. Now I am really puzzled. I could be wrong but I thought NSFNET was a high-speed replacement for the ARPANET in which clusters of RTPCs connected by 16Mbs token rings acted as packet-switches and replaced IMPs (PSNs) and where the 56Kbs leased lines were replaced by T1 lines so that there are issues of routing here between communications subnet switches but this is orthogonal to internetwork routing and should be totally transparent to hosts connected to the ARPA Internet of which NSFNET is one piece. > This is OK as long >as you have enough memory to keep your entire topology in core, AND >as long as you're willing to not allow any granularity of routing >beyond that which IP addresses give you. I thought the PCRT clusters kept topology of interswitch connectivity in memory and each cluster knew what hosts were directly connected to it but that they did not necessarily know the whole network topology. >In both instances, the simplifying assumption which makes the >Internet work (and it's a miracle that it does) is that IP addresses >imply hierarchical routing. I thought the simplifying assumption was that gateways only worry about routing between networks. Since this reduces the routing problem by several orders of magnitude in difficulty it is no miracle at all that this works. Is there a networking system out there which works better? >(I reference Paul Tsuchiya's work "Landmark Routing" for an excellent >solution to this and my own expansion on Paul's work, "Traveler Routing") >Finally, to answer your question, ISO IP doesn't imply routing; the >OSI model divides the network layer into a variety of sublayers, and >routing and IP are completely separate. The framework for OSI-style >routing has been created, but the actual protocols and algorithms >are still a matter for discussion. I think you are saying that ISO IP addresses don't identify to which network within a catenet a host is connected. I can think of some security reasons for this but lack of identification might actually create some security holes. But the bottom line is the IP means internetwork protocol and some where in the sublayers the ISO IP address has to be converted to an (network, host id) identifier (i.e. internetwork address) so all you have really done is interpose yet another layer of CPU cycle burning software in any network communications problem. This seems to be a useless partitioning of the problem into an internetwork datagram piece and an internetwork addressing piece. >Joel Snyder >U Arizona MIS Dep't In any case the ISO CLNP is not obligatory this discussion is all relatively academic (as well as the discussion of fragmentation). The major characteristic of an internetwork protocol is that it must be obligatory. ISO IP is not. UK GOSIP excludes the use of ISO IP so that if I am at BTR-USA and trying to connect from my machine (conformant to US GOSIP) to a machine at BTR-UK via OSI, I won't be able to succeed. But if both machines implement TCP/IP and my company has ARPA Internet connectivity I have no problem. Of course, my company spent less than $1000 per machine for the TCP/IP implementation while it spent somewhere between $50,000 and $500,000 per machine for the OSI implementation. Seems like a big waste of money. This is even more distressing because now state governments as well as the federal are mandating next-to-useless OSI implementations for new machines. Well, I pay for that major give away to companies like Unisys, and I don't like supporting this sort of welfare. In a period of economic retrenchment there are a lot better uses for that federal money which comes from the US taxpayer. Anyway, I updated the FTAM section of my document and here it is if you are interested: B. FTAM is Dangerous The "greater richness" of FTAM, specified in ISO/DIS 8571/1,2,3,4 (Information Processing Systems -- Open Systems Interconnection -- File Transfer, Access and Management -- Part 1: General Introduction, Part 2: The Virtual Filestore Definition, Part 3: The File Service Definition and Part 4: The File Protocol Specification) seems to lie in the ability to transmit single records and in the ability to restart aborted file transfer sessions through the use of obligatory checkpointing (ISO/DIS 8571/1 C.2.1 & C.2.4). Transmission of single records seems fairly useless in the general case since operating systems like Unix and DOS do not base their file systems on records while the records of file systems like those of Primos and VMS have no relationship whatsoever to one another. The obligatory ability to restart aborted simple file transfers, which actually is available in the FTP specification as an option for block or compressed file transfers, is more dangerous than helpful. If the transfer were aborted in an OSI network, it could have been aborted because one or both of the end hosts died or because some piece of the network died. If the network died, a checkpointed file transfer can probably be restarted. If a host died on the other hand, it may have gradually gone insane and the checkpoints may be useless. The checkpoints could only be guaranteed if end hosts have special self- diagnosing hardware (which is expensive). In the absence of special hardware and ways of determining exactly why a file transfer aborted, the file transfer must be restarted from the beginning. Even with the greater richness of FTAM, it is not clear to me that a file could be transferred by FTAM from IBM PC A to a Prime Series 50 to IBM PC B in such a way that the file on PC A and on PC B could be guaranteed to be identical because of the 16-bit word orientation of the Prime file system. Including single record or partial file transfer in the remote transfer utility seems is a good example of bad partitioning of the problem. This capability really belongs in a separate network file system or remote transaction processing system. A network file system should be separate from the remote file transfer system or remote transaction processing because the major issues in fault recovery, security, performance, data encoding translation, object location and object interpretation are different in major ways for each of the thee cases. Applying ISO/DIS 8571/1 to remote file service for a diskless workstation will be interesting to say the least. Section D.4 specifically 19 states "[s]ince the LAN communications are not liable to error, the recovery procedures are not needed." The document actually considers the case of the client workstation failing but ignores failures of the file server. Since the virtual filestore has state, probably all the client systems become completely "hosed." The goal of the virtual file store itself, as defined by ISO in ISO/DIS 8571/2, is unclear, probably constricting and probably performance limiting because of the way objects are typed within the virtual file store. A Unix device is a file within the Unix computational model. Even if a remote device file made sense within the ISO virtual filestore, it is totally unclear what might happen when a process on some client machine writes on a device file in the virtual file store. If the process writes the console device which is instantiated in the remote file system, should the data appear on the local console or on the remote console? If the endpoint machine is a diskless Unix workstation, the data better appear on the local workstation, but such a necessity raises serious naming and location issues, which seem intractable within the framework of FTAM, in the mapping of objects in the virtual file store to objects in real file stores or real file systems. The issue of diskless workstations is simply inadequately handled in the FTAM documents, and really belongs in a separate set of standards. Unless the class of diskless workstations is extremely restricted, a remote file system without a remote paging or swapping system, which are often remote file system or remote disk system issues, is fairly useless. The main problem with the virtual filestore is that it is not a remote file system. In a genuine resource sharing environment, a Unix machine should be able to serve as a remote file server for a VMS machine, and a Unix machine should be able to serve as remote file server for a VMS machine. A fairly simple, robust, stateless protocol which used a general handle into a data stream would be the proper approach, A VMS application might wish to access some record in a file which appears in a structured record- oriented VMS file. The remote file system client module running on the VMS system would translate this into an appropriate request for data which the server on the Unix machine would get from the unstructured Unix file. When a Unix application wishes to access a data contained in a data file actually residing on a VMS server, the Unix application would view this file as a sequence of fixed or variable length records contained in an apparently unstructured Unix file even though the actual VMS file is a structured record oriented file. The Unix client code would send an 20 appropriate request, which the VMS remote file server would extract as a record from the VMS file system and transmit as a stream of bytes to the client Unix machine. With the fairly strong file typing employed in the OSI virtual file store, such client-server relationships would not be possible unless the remote file system were implemented with the virtual filestore as the virtual server machine. But such a remote file system architecture does not simplify the problem at all because the software must still be implemented to make files from real file systems available to the virtual filestore. FTAM only adds one more layer of performance-killing software complexity. The virtual filestore would also add a similar superfluous software layer to remote transaction processing while hindering the efficient implementation of data integrity, data security, data access and transaction ordering procedures specific to remote transaction processing problem. Trying to lump the remote transaction processing system with simple file transfer and network file systems at best threatens the performance and data integrity of the distributed system whether the system is executing a simple file transfer, providing a remote file system or processing remote transactions.