karn@FLASH.BELLCORE.COM (Phil R. Karn) (03/06/87)
Indeed, one wonders if the computer public is at all aware of the fact that
the Internet has been quietly doing what the ISO hawkers are only promising
in big bold trade rag headlines. On the other hand, most vendors have
certainly heard of TCP/IP, considering that most of them already sell it,
so they have less of an excuse.
I think there are other, darker forces at play here. Recent developments
(or, more precisely, the lack of same) in the high definition TV standards
game illustrate what I think is going on in our own field. It seems that
over the past few years, certain Japanese companies have led the way by
developing a complete line of compatible, working, high quality video
components. You can buy their stuff off the shelf right now. At a recent
international standards convention in Europe, the Americans and the
Canadians enthusiastically supported the Japanese standard. After all, it
works and it's available now. "Can't have that", the Europeans replied. "It'd
be too hard to scan-convert back to our existing 625-line 50-Hz formats".
And everybody went home without an international standard.
Really now. And they said it with a straight face. This has to be about the
thinnest technical excuse anyone has ever invented. The *real* reason (and
this was openly stated in a EUROPEAN trade journal editorial) is that the
European manufacturers deeply resent the Japanese head start into the high
definition TV business. There is just no way they are going to approve
anybody else's standard, regardless of how good it is technically or whether
it's good for the users or not. It'd be bad for business.
To the European vendors, I am truly sorry that the Americans got a head
start by inventing TCP/IP and being the first to build big, operational
internetworks in which the common carriers ("PTTs") are only minor
subcomponents. To the American vendors of protocol software, I am truly
sorry that so many public domain implementations of TCP/IP are out there
stealing your sales. To those well-meaning souls in the Federal government
and elsewhere who naively trust vendor groups and standards organizations to
know what's best for your networking needs: take a look at the prices
they're charging for the few ISO packages out there. After you've put your
eyeballs back into your head, kick out the salesman and take a good close
look at just what these slickly advertised protocols will do for you (as
distinguished from your vendor's stock price). Then decide if you want to
throw everything away and start over just so you can use the magic phrase
"ISO compatible" to describe your network.
TCP/IP is uniquely successful among communications standards because it was
one of the very few ever designed by the USERS (who just want to get their
work done as efficiently and as cheaply as possible) instead of the VENDORS
(who want to make as much money as possible, an entirely different goal).
What's good for General Motors may sometimes be good for the country, but in
the protocol standards game it's a different story. Michael Padlipsky was
right on target on this one. Only the most hopelessly naive user succumbs to
the "Illusion of Vendor Support."
These are obviously my own personal opinions only.
Phil KarnNS-DDN@DDN2.UUCP.UUCP (03/09/87)
I am compelled to respond to what I perceive is a rather low opinion of protocol vendors (which would include me, I guess). Granted, it's caveat emptor out there, and the low opinion is deserved IN GENERAL. But there are some vendors who are not money-grubbing capitalists to the extent that customer dissatisfaction is irrelevant. Indeed, all vendors implicitly understand this truth about any marketplace to some degree. The ones who lose sight of the fact that customers buy data flowing between their computers (not software) reap the inevitable consequences. My experience would indicate that a significant number of nodes don't want to employ network protocol experts. They would much rather find a cradle-to-grave network solution (sorry, I couldn't resist) that they can entrust with their data comm requirements. It's easier for managers to beat on one vendor than on one or more employees and one or more vendors. Yes, there is public domain software, but there are learning curves and other hidden costs associated with it, and you still need the hardware. The theory is that more than one vendor springs up to provide these services, each with approximately the same savoir faire and customer commitment. The choices available to the customer cause prices to be competitive. It's lack of alternatives which cause customer gouging. Believe it or not, we do have satisfied customers. And these are obviously my own personal opinions only, too. Dave Craig Network Solutions, Inc.
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (03/10/87)
Phil-- Your comments on "the Europeans" reminded me that I'd never gotten around to commenting on a msg Jon sent some time back containing a quotation to the effect that the trouble with 5,000- member standards committees is that they spend all their time debating whether to have croissants or doughnuts for breakfast. I'm sure you'll agree that the quotation couldn't have been about ISO or CCITT, since they'd have been debating croissants vs. brioches--doughnuts would give the American vendors too big a headstart. cheers, map -------
mckee@MITRE.ARPA.UUCP (03/11/87)
I circulated the note from Phil ("...darker forces at play ...")
among several colleagues here at MITRE-Washington; herewith the
views of Steve Silverman.
--------------------------------------
*** Reply to note of 03/08/87 10:09
From: Steve Silverman
Subject: GOSIP vs TCP/IP
I would like to reply to your note on TCP/IP and its non-acceptance by the
commercial world. First of all, I doubt that there is any connection with
the various television standards other than the prevalence of the NIH
syndrome. This seems to be fairly prevalent in many places including the DOD.
As far as TCP/IP versus ISO, it must be recongnized that there are two ISO
suites being developed. One, the Connection-Based (CB), uses TP over X.25.
The second one, the Connectionless (CL) suite, uses IP between TP and X.25.
The CL suite is a datagram approach in the tradition of the ARPANET. This was
used in the first generation packet networks, but has significant costs
in comparison with the CB approach used by later generation commercial
packet networks. The CL approach means that each packet must contain
a larger header (TCP/IP = 40 bytes) than a CB packet (X.25 = 3 bytes).
The CL approach requires each switch to make a routing decision on each packet
while the CB approach allows transit switches to do a simple table lookup for
following packets.
Each suite has its benefits; the CL approach is better for tactical networks
with very mobile nodes. The CB approach is much more economical for higher
data requirements. The public data networks are almost exclusively CB.
The design work being done today for future networks by the common carrier
network builders is almost exclusively CB based, although the OSI 7 layer
model is being downplayed (really discarded). To some of us, the use of
a CL stationary packet network is equivalent to forcing all military
ground vehicles to be armored and armed. If 495 (our local beltway) were
filled with tanks, it would be a major waste of money.
It is about time, in my opinion, that the military networkers realized that
the commercial data users are not stupid. They demand the same reliability
that the DOD requires. The Reconnect feature of X.25 prevents loss of
user data when a transit node fails. This has been widely deployed for
years. Meanwhile the cost of running the ARPANET is comparable to running
the Telenet public network which carries ten times as many user packets.
The reluctance of some people to embrace TCP/IP is not just based on NIH.
Some of us reject it on technical grounds.
Steve Silverman
*
* Steve
:::GOSIP vs TCP/IP RCERF@A.ISI.EDU.UUCP (03/15/87)
Please ask Steve what he does about X.25 resets in the absence of an end/end reliable protocol such as TCP or TP4? I thought a significant commercial acceptance of TCP was in evidence from the PC and LAN vendors.? Vint
PERRY@VAX.DARPA.MIL (Dennis G. Perry) (03/16/87)
Steve, you made an interesting statement in your note: "The cost of running the Arpanet is comparable to running the Telenet public network which carries ten times as many user packets." Two questions. (1) How much does it cost to run Telenet? I know how much it cost to run the Arpanet. (2) How many packets does Telenet carry? If you will send me those data, I will put both the Arpanet figures and the Telenet figures on the net. If your statements are true, then it will help us in future designs. dennis -------
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (03/16/87)
It's "apples and eggplants" to compare TCP/IP header sizes with X.25's, as a rudimentary knowledge of Layering should show. Rather than be coy and make Marshall Rose or Mike Corrigan do the explaining, I'll accept the risk that Steve Silverman won't believe me and try to save time by pointing out that X.25 is at the "bottom" of L3 whereas IP is at the "top" of L3 and TCP is L4 (and subsumes some of the functionality of L5). Or, as I'd prefer to express it, X.25 is L I, TCP/IP L II. So any inference that going X.25 saves bits is fallacious (unless the argument is that we should go with the CCITT Suite, which isn't OSI and hence isn't what the argument is about). Aside to Dennis Perry: if you want the ARPANET to carry ten times as many packets as it does at the same (subnet) cost, you could always make the maximum packet size be .1 of what it is and come pretty close, especially if you ban character- at-a-time Telnet. (This one might be artichokes and brussels sprouts, actually, given all the possible differentiae--though maybe not, since it's still in essence attempting to compare the incommensurate.) cheers, map -------
PERRY@VAX.DARPA.MIL (Dennis G. Perry) (03/17/87)
Mike, I like artichokes, but cannot stand brussels sprouts. :-) Actually, aside from the packet size question, which is a real variable left out of many of the off the cuff remarks about performance, I would like to know how the Arpanet compares to commercial offerings. My experience is that it fares well (present limited capacity in the net excepted). dennis -------
mckee@MITRE.ARPA.UUCP (03/24/87)
The reply from Steve Silverman to Vint Cerf concerning X.25 resets follows: *** Reply to note of 03/22/87 12:25 From: Steve Silverman Subject: Re: GOSIP vs TCP/IP Re: X.25 reset: If the endpoint processor running one side of the X.25 session fails, then info is lost. The same is true if the processor running TCP or TP -4 fails. Hopefully, the user is notified in either case. Steve. * * Steve
mckee@MITRE.ARPA.UUCP (03/24/87)
The reply from Steve Silverman to Dennis Perry concerning the cost of,
and traffic over, Telenet follows:
*** Reply to note of 03/22/87 12:28
From: Steve Silverman
Subject: Re: GOSIP vs TCP/IP
Response to Dennis Perry:
In 1983 the Telenet public network cost in the neighborhood of 85 -
100 million dollars/year. This included development, PAD support, and
interest on debt.
About a year ago the Telenet public net handled about 1.5 billion
user data packets /month. This does not include layer 3RR packets, which would
be the equivalent of TCP acknowledgments, retransmittals of dropped packets,
or network maintenance (GGP packets).
*
* SteveCERF@A.ISI.EDU.UUCP (03/24/87)
Steve (Silverman), Thanks for the reply on X.25 resets. My experiences with public or private data nets using X.25 is that under congestion conditions, X.25 does NOT recover from the problems causing resets while TCP and other end/end transport protocols often do recover. Consequently, most inter-computer applications use some kind of end/end protocol with retransmission (and, of course duplicate detection) above X.25. I took the earlier comments on X.25 to imply that raw X.25 is sufficient. I would have to say that my experience has been otherwise, except for terminal to host applications in which the user recovers from problems by re-typing his input (which behavior is also appropriate for noisy, unprotected dial-up access to PADs...). Do we have a difference of opinion? Vint
CERF@A.ISI.EDU.UUCP (03/24/87)
Seems to me that the Telenet costs are comparable to ARPANET costs since there is a factor of 10 difference in traffic and costs in both systems. Several years ago, we estimated that the PRICE of telenet service would be something like 3 times higher than the cost of ARPANET service. It would be very interesting to make the comparison again. Vint
karn@FLASH.BELLCORE.COM.UUCP (03/25/87)
This is misleading. In "unlayered virtual circuit" networks, connection state information is kept not only in the end-point switches, but also in every intermediate switch along the path. For example, I understand that each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered VC network. Because of this, a node or link failure ANYWHERE along the connection path causes an X.25 VC reset, not just failures at the end nodes. Only in "layered VC" networks such as the DDN (where datagrams are used internally) can intermediate node and link failures occur without resetting virtual circuits. Since it is my understanding that the DDN is used almost exclusively for passing Internet datagrams around, I never could understand the reason for forcing IP gateways to deal with the gratuitous complexity of X.25. I can only speculate that the reasons were political and not technical. However, I am thankful that we will be able to come up on the ARPANET with HDH instead of X.25. Phil
CERF@A.ISI.EDU.UUCP (03/25/87)
The X.25 interface to DDN was pursued for at least two reasons: First, there are more X.25 interfaces available commercially than 1822 or just pure HDLC. Second, these interfaces can be used on public data nets which gives the potential for commercial back-up in case of emergencies. Vint
haas%utah-gr@UTAH-CS.ARPA.UUCP (03/28/87)
In article <8703250201.AA06443@flash.bellcore.com>, karn@FLASH.BELLCORE.COM (Phil R. Karn) writes: > ... I understand that > each GTE Telenet node speaks X.75 to its neighbors, making it an unlayered > VC network. Because of this, a node or link failure ANYWHERE along the > connection path causes an X.25 VC reset, not just failures at the end nodes. Not entirely correct. The interface protocol X.25 is not affected if an intermediate TCO fails, since the endpoint TCOs will reestablish the VC (if possible) via an alternative route. The hosts will see a VC reset only if one of the two endpoint TCOs fails. Tymnet does the same thing by a similar mechanism. Cheers -- Walt
Steve.Kille@CS.UCL.AC.UK.UUCP (03/30/87)
>From: CERF@edu.isi.a >Subject: Re: GOSIP vs TCP/IP >Date: 15 Mar 1987 01:04-EST >Please ask Steve what he does about X.25 resets in the absence of >an end/end reliable protocol such as TCP or TP4? Well, I'm the wrong Steve, but will comment anyhow! The TCP Implementor's conference has made it very clear to me that the X.25 oriented solutions are very poorly understood in the TCP/IP community. There are two basic ways of handling resets. The first is at the application level, and will certainly be done by those applications which need to handle large quantities of data, and do not wish to incur the cost of retransmission. This can be done by use of CCR (Comit Concurrency + Recovery) for FTAM and JTM (Job Transfer and Manipulation). For X.400, the RTS (Reliable Transfer Service) resumption mechanisms can be used. In many cases, these will be sufficient, and so a very lightweight transport (viz TP0) is sensible to make best utilisation of the X.25. However, for some applications (e.g. Terminal Access) it would be very desirable to have resumption over the same transport connection. Therfore, TP1 (viz error recovery class) is a sensible choice. There is absolutely no need for the heavyweight overkill of TP4. X.25 will keep data in sequence, and prevent data corruption. Steve
CERF@A.ISI.EDU.UUCP (04/02/87)
Steve (Kille), I merely wanted to point out that you need something above the X.25 level to do recovery, if you care, after a reset. Vint
Steve.Kille@CS.UCL.AC.UK.UUCP (04/06/87)
Right. X.25 on its own is not capable of end to end recovery. I was just making clear that this is not a deficiency in X.25, and that in the right combinations it is a sensible building block. Steve