Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!texbell!bellcore!jupiter!karn
From: karn@jupiter..bellcore.com (Phil R. Karn)
Newsgroups: comp.dcom.lans
Subject: Re: What services does X.25 provide?
Keywords: x.25, services, login, e-mail, file transfer, IPC
Message-ID: <17953@bellcore.bellcore.com>
Date: 19 Oct 89 00:40:35 GMT
References: <796@maxim.erbe.se> <3279@wasatch.utah.edu> <522@wet.UUCP> <6624@pdn.paradyne.com> <23189@cos.com> <1989Oct10.210812.13144@agate.berkeley.edu> <17899@bellcore.bellcore.com> <6669@pdn.paradyne.com>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 85

>This rabid, OSI-bashing statement aside, the answer to the question
>is that TP4 over X.25 is a relatively poor performer for the resources
>consumed (ie, protocol overhead in both layers for ACKing data units).  
>TP2 over X.25 is at least more efficient.

In other words, my original statement is still true, namely that ISO
doesn't really consider universal interoperability to be particularly
important despite all their hype to the contrary. Or at least it's not
as important to them as what Michael Padlipsky once called their "bit
saving fetish" regarding header overhead.

I think the ARPA Internet approach, with interoperability of paramount
concern, has proven by its tremendous popularity that people consider
the convenience of a single, universal, transparent Internetwork service
to be well worth whatever extra header overhead it requires. Personally,
I think the header overhead issue is a red herring. Bulk data transfers
can always reduce header overhead to an arbitrarily small value by just
increasing the data packet size. In fact I once computed that the total
overhead of a TCP/IP file transfer using the Internet default MSS of 576
bytes is actually less than an unprotected X.25 transfer using the very
common X.25 network default packet size limit of 128 bytes. (Yes, I know
you're supposed to be able to increase the X.25 packet sizes, but if
header overhead was so vitally important, don't you think they would
have made the defaults larger?)

Header overhead in TCP/IP is significant only for small, interactive
packets over slow and expensive links. But Van Jacobsen's recent
point-to-point header compression work (described in the SLIP session at
Interop) has shown that you need not sacrifice the universality or the
robustness of the TCP/IP approach to attain good performance over slow
links. He's got the typical Telnet data packet down to 5 bytes or so. 
All it took was one smart person working on the problem.

Performance across X.25 is an issue only because of the European PTTs'
hammerlock on data communications. If they'd privatize and deregulate
their markets, and in particular if they'd sell leased lines at
reasonable prices to resellers and private network operators so they
could build more modern computer networks like we have in the US, I
think you'd see the concern disappear. Why else would the US be going
for TP4 while Europe goes for TP0? The laws of physics and mathematics
are the same on the two continents; the differences are in the laws
governing competition in telecommunications.

>I agree that OSI isn't perfect, and Layer 4 in particular is unlovely,
>but to ascribe the *real* motivation behind OSI as above is pure
nonsense.

Yeah, I probably violated my own rule of "never attribute to malice that
which can be adequately explained by stupidity". But one still wonders,
given so many blatantly misleading claims from the OSI camp.

I should say here that I'm definitely not "rabidly" opposed to the
entire OSI effort. Once in a while, an idea appears in OSI that might
actually be worth trying. And if somebody can demonstrate through actual
experiment (not a paper study) that a particular OSI service is actually
"better" (in some widely agreed sense, be it functionality, performance,
or implementability) than an existing Internet service, then I'd agree
that we should use it. Heck, I'm a big supporter of the metric system
because it's clearly better than what we now use.

The problem is that, by and large, this just isn't the case with OSI,
especially in the lower and middle layers (transport on down). A forced
"transition to OSI" here will yield NO MEANINGFUL ADVANTAGES WHATSOEVER
over TCP/IP in terms of performance, interoperability or services. But
it WILL be very expensive, disruptive and confusing to an awful lot of
people, especially those trusting neophytes who have bought the OSI
salesman's pitch hook, line and sinker.

Perhaps the best approach is the one being taken by Marshall Rose's
ISODE package, which concentrates on the ISO applications while using
the existing TCP/IP infrastructure. If there's ANY advantage AT ALL in
going to OSI, it'll be in the applications -- although this is far from
proven. Nevertheless, they're worth experimenting with, just in case. I
can say that an awful lot of excess baggage is going to have to go
before the OSI applications could ever become usable standards.

But if you're going to tell me I have to "go OSI" and toss out a
perfectly good Internet just because the Government says so, and not
because of an legitimate reason, then I think I can be excused if I get
a little upset. The last time the US Government scrapped a perfectly
good existing technology in favor of a heavily hyped universal
replacement, we couldn't launch anything into space for over a year. And
we're still recovering from THAT fiasco.

Phil