Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.dcom,net.lan
Subject: Re: Re: Standards for commercial packet radio
Message-ID: <1445@cbosgd.UUCP>
Date: Mon, 26-Aug-85 21:25:03 EDT
Article-I.D.: cbosgd.1445
Posted: Mon Aug 26 21:25:03 1985
Date-Received: Tue, 27-Aug-85 06:43:56 EDT
References: <1919@amdahl.UUCP> <472@petrus.UUCP> <166@rpics.UUCP> <1441@cbosgd.UUCP> <481@petrus.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 69
Xref: watmath net.dcom:1204 net.lan:990

In article <481@petrus.UUCP> karn@petrus.UUCP (Phil R. Karn) writes:
>Some might consider this a cheap shot, but in my opinion the X.25 datagram
>facility was such a brain-damaged afterthought that it never had a fair
>chance in the first place. Worse, many of the PDNs out there assume at a
>very low level that they're only providing virtual circuit service (e.g.,
>Telenet, TYMNET) so implementing a datagram service would essentially
>require the overhead of setting up and tearing down a virtual circuit on
>each and every datagram.

I am not familiar with the 1980 X.25 datagram, but the stories I've heard
agree with you.  I also understand that the current X.25 spec has a feature
called "fast select" which essentially opens up a virtual circuit (carrying
data with the open request) and immediately closes it down, which might
be reasonably suitable for datagrams.  (At least, it might reduce the
number of round trips to one, I suspect the first ACK will come back anyway.)
Is this really a good thing?  Is anybody implementing it?

>> I have no idea how you are
>> supposed to get through a virtual circuit oriented X.25 bottleneck to
>> send IP packets out over the ARPANET, this must make an interesting story.
>
>We are one of the relative handful of sites running the CSNET IP/X.25
>interface, so I can describe it and our experiences in some detail. RFC-877
>specifies a standard for the transmission of IP datagrams over X.25 virtual
>circuits. Virtual circuits are established whenever there are datagrams to
>send, and timed out after periods of inactivity.  "X.25 bottleneck" is
>highly appropriate; because of the tiny packet size limits and flow control
>windows, it is often necessary to open several parallel virtual circuits to
>the same destination and multiplex datagrams among them, just so the
>bandwidth of our 9600 baud "local loop" can be fully utilized.  Even then,
>we're lucky to get 4800 baud left over for IP after all the redundant X.25
>link level acks, packet level acks and so forth.

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.  As you point out, being
on CSNET is not as good as being directly on the ARPANET, because you have
to use X.25 virtual circuits underneath your IP datagrams.  Obviously this
is silly, but it does have and clear advantage that it works.

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.

>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.  It would be much more reasonable to compare
FTP/TCP/IP/SLIP/9600 with the appropriate virtual circuit oriented 
file transfer, which I suppose might be FTAM/X.409/?/TC3/X.25/HDLC/9600
(I'm not sure of the details or what the session layer protocol is.)
My impression of the OSI stuff was that, while there is high overhead
in setting up and virtual circuits (one at each layer from 2 to 7),
and while each of the 6 layers above the physical adds a header (and
a trailer in HDLC) that the total number of bytes of headers is only
about 30, compared to 60 for combined TCP and IP.  Over low speed networks
like RS232 there might be less overhead for large file transfers.

Of course, there are other factors, like the memory copies that may
be necessary to add 2 bytes of header onto an existing packet at
each layer, and the overhead of actually having a layer look at the
packet.  These could become very important with a high speed LAN,
where the bottleneck is the CPU on each end.  Also, the complexity
of the implementations and the wide choices that different implementors
will have to choose from may make most ISO "Standard" implementations
unable to talk to each other, and even unable to be released as
products until some time after everybody has Ada compilers.

	Mark