Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.dcom,net.lan
Subject: Re: Re: Standards for commercial packet radio
Message-ID: <501@petrus.UUCP>
Date: Tue, 27-Aug-85 19:44:57 EDT
Article-I.D.: petrus.501
Posted: Tue Aug 27 19:44:57 1985
Date-Received: Wed, 28-Aug-85 10:24:25 EDT
References: <1919@amdahl.UUCP> <472@petrus.UUCP> <166@rpics.UUCP> <1441@cbosgd.UUCP> <481@petrus.UUCP> <1445@cbosgd.UUCP>
Organization: Bell Communications Research, Inc
Lines: 64
Xref: watmath net.dcom:1207 net.lan:992

> I also understand that the current X.25 spec has a feature
> called "fast select"...

Fast select was the Japanese answer to the datagram advocates. The "pure"
datagram facility that was added in 1980 and removed in 1984 was the US
proposal. In the true spirit of bureaucracies everywhere, the CCITT accepted
both.  I don't know for sure which networks implement fast select. As you
might know, the current CSNET IP/X.25 software drops datagrams if a VC isn't
already open to the destination. When I asked the implementors why the
didn't use fast select so as to avoid dropping the initial datagram of a TCP
session, they said that not all networks they had to deal with implemented
them.

It seems to me that a standard that isn't universally implemented isn't a
standard at all...

> That's not what I meant, Phil.  You aren't on the ARPANET, you're on CSNET,
> which is one of the networks in the ARPA Internet.

True, I should have been more precise. You aren't "on" the ARPANET unless
you've got an IMP interface and an address on network 10. But IP-level
connectivity is what really counts, even if it's slow, so as far as our
users are concerned, we're "on" the ARPANET. CSNET/X.25 is one hell of a lot
better than uucp.

> As I understand the situation, people plugging directly into the REAL LIVE
> ARPANET (the one you have to know somebody in the pentagon to get onto)
> are now being told that the preferred interface is no longer 1822, it's
> X.25.  This is what I don't understand.

Me neither, although I've seen the interface specs, so it seems to be for
real.

> >And the CCITT bigots claim that TCP/IP has too much "overhead".
> In all fairness, you're looking at TCP/IP/X.25/9600, which is a silly
> configuration....

But unavoidable if you want to do internetting on a large scale but you don't
have direct access to the ARPANET, and you can't justify leased lines.  At
least until some PDN gets smart and offers a true commercial datagram
service...

Actually, it's interesting to go through the numbers. If you're doing an FTP
over TCP/IP/X.25 on Telenet with reasonable TCP segment sizes (e.g., 1KB)
then I think you'll find that the majority of the line overhead is due to
the so-called "low overhead" X.25 protocol because of its small packet sizes
and its fetish for acknowledgements at every layer. The actual amount
depends on how well the link layer acknowledgement delay timer is tuned.  If
it is tuned badly (and I suspect it is in our case, although I haven't the
foggiest idea how to change it on our interface board), then just hitting a
single key on a terminal connected to a PAD in character-at-a-time mode
(which is how most people operate them) will involve the transmission of
30 bytes of X.25 headers!

True, it's also at least theoretically possible to use larger packet and
window sizes in X.25 but no one seems to know how to do that with the actual
PDN we have to deal with.

I think best way to understand the X.25/CCITT mentality is to understand
that it's just fine for what almost everybody uses it for -- remote access
from a dumb terminal through a PAD. Relatively few people are doing the kind
of true host-to-host resource sharing that is the basis of the Internet.

Phil