[net.dcom] Standards for commercial packet radio

sjl@amdahl.UUCP (Steve Langdon) (08/17/85)

I have a friend who is doing some work that involves the use of packet radio
for commercial wide area networking.  He asked my if I was aware of any
standards (in the ANSI, ISO, etc. sense) for packet radio.  Although I am
involved in communications standards work, I could not think of any groups
working on this subject.  Is there someone on the net who could provide
me with information on work (or the absence thereof) in this area.

Please reply by mail.  If I find out anything that appears to be of broad
interest I will post it.
-- 
Stephen J. Langdon                  ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

karn@petrus.UUCP (Phil R. Karn) (08/18/85)

So far as I'm aware, the only organization doing anything with terrestrial
packet radio besides the amateur radio community is the US Department of
Defense.  (To me, "packet radio" doesn't include one-way data broadcasting
on FM broadcast subcarriers, nor does it include hooking up a modem to your
cellular phone.)

The DoD has spent a considerable amount of effort in developing packet radio
for mobile tactical communications, and at least some of their work has been
published (see the November 1978 Proceedings of the IEEE, p. 1468.)

As you might expect, IP/TCP are the standard network and transport layers in
DoD packet radio networks. The characteristics of a mobile packet radio
network, with its constantly changing topology and frequent node failures,
(due either to a station driving into a radio "hole" or getting blown to
bits by The Enemy) was one of the basic reasons the Internet Protocol is
based on datagrams. The refusal of any of the commercial standards
organizations to consider datagram protocols is what prompted the DoD to
develop their own.

DoD packet radio makes heavy use of spread spectrum, as you might imagine.
Not only does this make transmissions harder to jam or intercept, but it
also alleviates multipath effects common in mobile environments.
See the IEEE article for more details.

Phil

kenward@mdivax1.UUCP (kenward) (08/22/85)

>> So far as I'm aware, the only organization doing anything with terrestrial
>> packet radio besides the amateur radio community is the US Department of
>> Defense.  (To me, "packet radio" doesn't include one-way data broadcasting
>> on FM broadcast subcarriers, nor does it include hooking up a modem to your
>> cellular phone.)

There is an organization entitled the "International Radio Consultative 
Committee" (CCIT), one part of which is concerned with international standards 
for mobile radio communications, including standards for packet radio.
You might have heard of another similar committee, the CCITT.  Indeed, CCIR and 
CCITT have a few joint committees.

Also, there are a few commercial companies using packet data communications protocals over terrestrial radio links, in particular, 

**COMMERCIAL** 

Mobile Data International, Inc., the world leader in mobile data communications.
If your in doubt, look for tl%?MDI mobile data terminal in the squad cars, the 
next time you watch Hill Street, or TJ Hooker.  Or, for that matter, the next 
time you see a New York City Police car or a Federal Express delivery truck to 
name a few).

**ENDCOMMERCIAL**
-- 

Plus ca change, plus c'est la meme chose!

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SNAP! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Gary W. Kenward
Mobile Data International Inc.
Riverside Industrial Park
Richmond, B.C.
Canada  V7A 4Z3

schoff@rpics.UUCP (Martin Lee Schoffstall) (08/24/85)

> The refusal of any of the commercial standards
> organizations to consider datagram protocols is what prompted the DoD to
> develop their own.
> 
Then they realized that they had enemies too and have "built" a
transport protocol (TP4) which lives on top of a datagram network
protocol.  :-)

-- 
marty schoffstall
schoff%rpics.csnet@csnet-relay	ARPA
schoff@rpics			CSNET
seismo!rpics!schoff		UUCP
martin_schoffstall@TROY.NY.USA.NA.EARTH.SOL	UNIVERSENET

RPI
Computer Science Department
Troy, NY  12180
(518) 271-2654

mark@cbosgd.UUCP (Mark Horton) (08/26/85)

In article <166@rpics.UUCP> schoff@rpics.UUCP (Martin Lee Schoffstall) writes:
>> The refusal of any of the commercial standards
>> organizations to consider datagram protocols is what prompted the DoD to
>> develop their own.
>> 
>Then they realized that they had enemies too and have "built" a
>transport protocol (TP4) which lives on top of a datagram network
>protocol.  :-)

As I read the intent of the CCITT folks working on OSI (and this is
based on an OMNICOM seminar taught by Hal Folts, so his biases may
be what you're seeing here) they think virtual circuits are wonderful
and that anyone who would do anything with a datagram must be crazy.
As evidence to support this, they point to the fact that in 1980,
X.25 had a datagram facility, but by 1984 nobody had implemented it,
so it was deleted from the 1984 spec.  (It seems to me that there was
no serious demand for datagrams from the common carriers until around
1982 or 1983 when TCP/IP became popular - CSNET would have been the
first real user.)

Most of the interest in TC4 and CLNS seems to be from the people doing
the AUTOFACT stuff - mostly American computer companies.  The Telcos
which make up CCITT have decreed that there will be no wide area
network protocols except X.25, and they are trying to move the LAN
protocols in the connection oriented direction.  (Did you know that
IEEE 802.3 has a connection oriented mode?  Does anyone care?)  They
have gone so far as to get DOD to announce that the preferred interface
to the ARPANET is no longer 1822, it's X.25.  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.

	Mark

karn@petrus.UUCP (Phil R. Karn) (08/26/85)

> As evidence to support this, they point to the fact that in 1980,
> X.25 had a datagram facility, but by 1984 nobody had implemented it,
> so it was deleted from the 1984 spec.

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 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.

And the CCITT bigots claim that TCP/IP has too much "overhead".

Phil

mark@cbosgd.UUCP (Mark Horton) (08/27/85)

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

chris@umcp-cs.UUCP (Chris Torek) (08/27/85)

>... [in] the OSI stuff ...  the total number of bytes of headers is only
>about 30, compared to 60 for combined TCP and IP.

Dunno about ISO/OSI, but it's 40 bytes for a TCP/IP header.  (Ignoring
options, which no one uses anyway, except at setup time.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland

hhs@hou2h.UUCP (H.SHARP) (08/27/85)

I have also heard that DOD (or ARPANET) has made a commitment to
different standards groups (NBS, FTSC, etc.) that it is going to 
migrate toward ISO's layer 4 and away from TCP/IP.  The  FTSC and
NBS came out with a dual release of the ISO's layer 4.  I wonder
if this is actually going to happen.

While on the subject, I have a question.  Has anyone ever run VI on
Unix from a terminal with an X.25 packet switching network between the
terminal and host?  How did it work?  Just curious.

karn@petrus.UUCP (Phil R. Karn) (08/28/85)

> I have also heard that DOD (or ARPANET) has made a commitment to
> different standards groups (NBS, FTSC, etc.) that it is going to 
> migrate toward ISO's layer 4 and away from TCP/IP.  The  FTSC and
> NBS came out with a dual release of the ISO's layer 4.  I wonder
> if this is actually going to happen.

This was the subject of the famous "NRC Report". As I interpret the official
DoD response to the report, they said that they've already got a set of
working protocols that do everything they want. Until ISO becomes a real set
of standards implemented in real products instead of so much paper, there's
no hurry to consider any form of conversion.

> While on the subject, I have a question.  Has anyone ever run VI on
> Unix from a terminal with an X.25 packet switching network between the
> terminal and host?  How did it work?  Just curious.

We can do this on our CSNET/X.25 interface. It works, but slowly, as you'd
expect.

Phil

karn@petrus.UUCP (Phil R. Karn) (08/28/85)

> 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

hhs@hou2h.UUCP (H.SHARP) (08/28/85)

>From: karn@petrus.UUCP (Phil R. Karn)
>Posted: Tue Aug 27 19:44:57 1985

>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.

It is interesting to consider another viewpoint of this matter.
Recommendation X.25 and the ISO standard for X.25 for 1984 
make allowances for packet sizes up to 512 octets (or 1024 octets).
The PDN's are only implementing the smaller packet sizes (128 octets)
because the only demand is for remote access from a dumb terminal
through a PAD.  Maybe if the PDN's had more demand for true
host-to-host resource sharing, they would offer the larger packet
sizes and faster lines.  Any comments from a PDN out there?
 
If a switch can handle a certain number of packets per second, then
increasing the packet size will increase throughput (of course, other
factors come into play, such as need for more buffer space).

george@mnetor.UUCP (George Hart) (08/30/85)

In article <1032@hou2h.UUCP> hhs@hou2h.UUCP (H.SHARP) writes:
>...
>While on the subject, I have a question.  Has anyone ever run VI on
>Unix from a terminal with an X.25 packet switching network between the
>terminal and host?  How did it work?  Just curious.

X.25 pads generally only send packets when they're full, after a
specified timeout or when some significant characters (usually CR and
DEL) are received.  Needless to say, editors like vi don't work very
well (if at all) since, for example, you have to hit carriage return
after every character in command mode.

Pad parameters can be tweaked so that the packet timeout is extremely
short or the packet size is very small (say 1!) but since you are
usually charged by the packet (or kilopackets), this is very expensive.
-- 


Regards,

George Hart, Computer X Canada Ltd.
UUCP: {allegra|decvax|duke|floyd|linus|ihnp4}!utzoo!mnetor!george
BELL: (416)475-8980

martin@sabre.UUCP (Martin Levy) (08/31/85)

Given this statment, and the fact that it is correct.

> They have gone so far as to get DOD to announce that the preferred interface
> to the ARPANET is no longer 1822, it's X.25.

Can someone explain why?, was it just because more people know X.25 than 
1822?. How much of X.25 is used in this link?. Where are the specs?.

martin levy
bellcore.

ml@dlvax2.UUCP ( Martyn Legge ) (09/03/85)

In article <1032@hou2h.UUCP> hhs@hou2h.UUCP (H.SHARP) writes:

>While on the subject, I have a question.  Has anyone ever run VI on
>Unix from a terminal with an X.25 packet switching network between the
>terminal and host?  

I have.

>How did it work?  Just curious.

Appallingly badly!

Martyn Legge (Data Logic)

tcs@usna.UUCP (Terry Slattery <tcs@usna>) (09/04/85)

> They have gone so far as to get DOD to announce that the preferred interface
> to the ARPANET is no longer 1822, it's X.25.

We're just going through a Milnet connection and were told that X.25 was
the desired connection protocol.  We opted for 1822 HDH (1822 protocol
on HDLC) connection since ACC makes the IF11/HDH that does that for
our Unibus machine.  As I understand it, the X.25 is only a point-to-point
link to replace the 1822 point-to-point link.  Since both use HDLC bit
protocol, the only difference is the link level protocol (1822 vs X.25).
I can't comment on the differences in performance of 1822 vs X.25
in this configuration.  Anyone know?
	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@brl-bmd     UUCP: decvax!brl-bmd!usna!tcs

adh@cstvax.UUCP (Adam Hamilton) (09/05/85)

In article <296@dlvax2.UUCP> ml@dlvax2.UUCP ( Martyn Legge ) writes:
>In article <1032@hou2h.UUCP> hhs@hou2h.UUCP (H.SHARP) writes:
>
>>While on the subject, I have a question.  Has anyone ever run VI on
>>Unix from a terminal with an X.25 packet switching network between the
>>terminal and host?  
>
>I have.
>
>>How did it work?  Just curious.
>
>Appallingly badly!
>
>Martyn Legge (Data Logic)

At Edinburgh University, we access machines via X25 all the time.
Performance varies depending on the power at the host end.
My description of running vi is "a bit lumpy", but it really is quite
acceptable (unless you judge by running SPY on a PERQ or SUN)

		Adam Hamilton

(Disclaim, exclaim, reclaim, inflame)

ewiles@netex.UUCP (Ed Wiles) (09/21/85)

>
>While on the subject, I have a question.  Has anyone ever run VI on
>Unix from a terminal with an X.25 packet switching network between the
>terminal and host?  
>
>How did it work?  Just curious.
>

Our company uses X.25 extensively between terminals and hosts, the major
problem seems to be "lumpyness", as another put it.  The characters you
type, and the effect that they have, are seen as: one char, then another,
then a whole gob of them.  As to slowness, like any network, if you
overload it, its going to slow down.

				E. L. Wiles
				Member Tech Staff, NetExpress Inc.