n2dsy@hou2d.UUCP (G.BEATTIE) (04/01/88)
Summary: These are my comments on a message sequence which
I felt was counter productive. I have appended the
offending comments to my response for reference.
Listening to what you want to hear, eh ?
I think it's time to look a bit more at the ambitiousness
of the project and the FACT that they have come to fruition.
The comments shown below seem to be somewhat self-serving.
Might you gentlemen, consider that there are OSI-based
applications out there already, that the DoD is moving to
a (connectionless) form of OSI protocols and that your
talents (and mine) are being wasted by the endless exchanges
in what should now be called the "Propaganda Wars".
The simple facts are that a wide variety of companies have
implemmented OSI protocols and more are being added.
Now that the 1988 versions of the statndards documents are
out in final draft form for ballot, the growth of interest
has exploded.
Please don't tell me how many more implementations of
the DoD protocols are already out there. That is well
known and expected given the 10 year jump in their lifecycle.
Why not spend the energy in cooperating in the evolution of
these protocols to suite that will work for all of us?
Frankly I'm tired of the bickering from "educated"
individuals.
Thanks,
J. Gordon Beattie, Jr.
E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)
The rest of this article is an excerpt from a pair of comments
that are of the type referenced above.
References: <8803261505.AA04812@wb6rqn.UUCP> <2902@korppi.tut.fi>
In article <2902@korppi.tut.fi>, jh@tut.fi (Juha Hein{nen) writes:
> In article <8803261505.AA04812@wb6rqn.UUCP> brian@wb6rqn.UUCP (Brian Lloyd) writes:
> >European attendees. The consensus was that OSI really wasn't happening
> >and that they were all planning to go the TCP/IP route. I guess that
> >the ISO/OSI hard-sell has created a market that only TCP can currently
> >fill.
>
> Pretty much a correct observation. The POLITICAL plan is to go the
> connection oriented (X.25) OSI route that doesn't care about local
> area networks (it only cares about the profits of PTT monopolies). So
> if you want to build a LAN and connect it to another LAN what else
> have you got except TCP/IP?
> --
> Juha Heinanen
> Tampere Univ. of Technology
> Finland
> jh@tut.fi (Internet), tut!jh (UUCP)diamant@hpfclp.HP.COM (John Diamant) (04/05/88)
> The simple facts are that a wide variety of companies have > implemmented OSI protocols and more are being added. > Now that the 1988 versions of the statndards documents are > out in final draft form for ballot, the growth of interest > has exploded. Yes, but why have they moved to implementing OSI protocols? Is it because these protocols are significantly better than TCP/IP and ARPA standards, or is it simply European market pressure? If market pressure, why is that happening? Again, is it because the protocols are better, or just because they weren't developed by the Americans? I'm asking honest questions here, not flaming. I know a fair amount about TCP/IP and not terribly much about OSI, but from the outside, it sounds like an awful lot of reinvention of the wheel. John Diamant SDE UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett-Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
kre@munnari.oz (Robert Elz) (04/09/88)
In article <11240001@hpfclp.HP.COM>, diamant@hpfclp.HP.COM (John Diamant) writes: > Yes, but why have they moved to implementing OSI protocols? Is > it because these protocols are significantly better than TCP/IP and > ARPA standards, or is it simply European market pressure? If market > pressure, why is that happening? Again, is it because the protocols > are better, or just because they weren't developed by the Americans? I have a few uninformed opinions... First, OSI isn't new, I don't have precise details of the dates of either TCP or OSI, but I wouldn't be surprised to learn that OSI (the concept, and model) predates TCP (nb: I said TCP, not IP). When comparing TCP/IP and OSI you have to remember to look at them in all their aspects. If you're simply wanting to move bytes, and don't care much about anything else, then probably both will work. But there's one major feature that TCP lacks, and that's any rational manner of coping with networks where you actually have to pay for usage. I'm not concerned with the mechanics of accounting (billing procedures, etc), or of packet (or byte, and time) counting, I have no doubt that that could be added to IP without any great degree of difficulty. The problem is TCP's overall philosophy, which has been praised again and again recently on this list. That is, that the levels below TCP should not retransmit damaged packets, TCP should do that. Now clearly accounting belongs at the IP level (or perhaps even below it, if you can't see why, then just contemplate alternative protocols above IP for a while). Now if TCP is retransmitting when packets are damaged, retransmitted packets get charged twice. I don't know about you, but I really don't think I'd be all that happy paying to use a network service that was permitted to discard packets at will, yet charge me for sending them. Even if the network service didn't do this, I wouldn't be too thrilled at having packets transmitted through the network, correctly routed to the local LAN at the destination site, and then lost there, for me to have to retransmit them, and pay again (which the network would clearly have to do, or I would simply claim that all my packets after the first were retransmissions). Of course, none of this matters if you're working in an environment where you don't pay for each packet that you send, or each second that you're connected, so its easy to see how the Internet Protocols evolved like they did, but that simply doesn't work well in other environments, and apart from local LAN's, the Internet environment just doesn't exist much in other parts of the world (BITNET and its associates are similar). Its also true that when you're actually being charged for each byte you want to minimise the number you send, so you want packet headers of minimal size (down at least to the level where you're being changed, below that matters less). This is actually less important than it might seem, as the resources used by the network are likely to end up being much the same whether you have a connection oriented network link (small packets, but state information along the way) or connectionless (larger packets, but less to remember in subnet nodes). It might also be true that what appears on the outside to be one is actually the other underneath. In any case, the charge per byte can be adjusted to take this into account, a net that gave a connectionless interface, with larger headers, could just charge a little less for each byte, than a connection oriented net charged, overall things would probably even out. Given a basically totally reliable network level, which is needed for charging, the functions of the transport level can be altered quite a lot, it no longer need do much error checking for most uses (the most critical might request additional checksums, but that's probably going to be rare), making for a much simpler transport layer than TCP (of coursem the network layer is much more complex than IP). NB: it IS NOT necessary for the transport level to do all the checking/retransmit again, any more than it is necessary for applications in the TCP/IP world to do it, once you have reached a level that you define to be "reliable" users of that level are entitled to assume reliablity, just as STMP assumes that TCP will either deliver data accurately, or break the connection and signal an error to SMTP, ISO transport is entitled to assume that CONS (connection oriented network) will deliver the data reliably, or break the connection and signal an error. I doubt that there's really much anti-American bias in this, after all, ISO does include all the unreliable protocols as well, largely because the American's pushed for them to be included. Those protocols are very similar to TCP/IP, though they have the benefit of hindsight, a lot of the minor problems with TCP/IP can be corrected (eg: its clear (now) that 32 bits simply isn't enough for an address intended to encompass the entire world). There are a whole bunch of other charging related issues that TCP/IP has trouble dealing with, including how to accurately charge the right person for data transferred, which means that charging for an FTP fetch of a file needs to be sent to the requestor, which means that (somehow) the charging needs to look inside the IP packets and discover their true nature. That might not be too difficult, though its certainly not clean, but can you say the same about a TFTP transfer? The only way arund this problem would seem to be avoiding charging. While the US DoD, DoE, NSF, etc continue to be willing to fund networking for (essentially) all and sundry in the US, its easy to justify ignoring ISO, and connection oriented protocols. In Australia (that's here) we don't have that luxury, there's no way the Aust Govt is about to fund anything like the arpanet or nsfnet, and so far we haven't had much luck convincing the US Govt agenices that we really are the 52nd (after Canada) state... The alternative of running a bitnet like net, with institutions paying fixed fees (for line rentals, or other similar purposes) might be workable, but its very difficult to come up with a scheme for charging the fees that's fair (so that sites that really make little use don't pay all that much .. ignoring this encourages wastage of resources, where people use the service just because it has been paid for). I have posed a similar question to the following before, which was met with total silence, but would someone like to explain a reasonable, implementable, and fair charging scheme that will work with TCP/IP ? Finally, you actually asked why people are "implementing", rather than "inventing", OSI now. This raises a different issue. I hope I've shown why OSI (or something similar to it) is wanted by many people, and why simply standardising on TCP wouldn't work. That hasn't explained why there aren't more implementations of ISO out in the world already though. Here we get into the "should standards bodies invent new things, or just bless existing products" debate. To me, there look to be too quite different types of standards. First there are standards for things like CD's, telephones, UNIX, ... where someone invented something new, previously un-thought of, and made it available to the rest of the world, who could then say "this is great, lets make one of those". In that area, standardising an existing product is clearly the right thing to do. The other area is where there's a clear need for some product, that doesn't yet exist, which almost anyone can see if they think about it (consider home video several years ago, where commercial systems existed, far too expensive for home use, and all that was needed was some inexpensive format). Here there's a real danger of several independant inventions with little to choose between them, standardising one of those inventions and ignoring the others clearly gives the lucky inventor a big advantage over the others, and will either cause them big losses (all that wasted effort) or to ignore the standard and continue with their previous product, effectively destroying the standard if they succeed. Given that environment, in cases where it can easily be seen that this situation is likely to arise, many potential inventors are likely to simply neglect to invent at all, and just wait for someone else to do it. I believe that networking fits into the latter of those two classes, everyone could see that it was needed, only a few were brave enough to actually try it on their own. Enter ISO, faced with either chosing an existing net from one of the few (and don't kid yourself that TCP would have stood much chance of being "the one", it would more likely have been SNA, or DECNET, or something similar), and I suspect quite rightly deciding to do something a little different from anything on offer, equally disadvantaging everyone. Given that scenario, and the fact that several of the OSI protocols have only recently become really firm enough to implement (and release, even if the vendors were implementing the intermediate draft standards), its not too surprising that the OSI protocols are just being implemented (and released) now. kre