[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: [aprssig] BBS's versus DIGIPEATERS in space



> Date: Sun, 6 Jun 1999 01:31:40 -0400 (EDT)
> From: Bob Bruninga <bruninga@nadn.navy.mil>
> Subject: [aprssig] BBS's versus DIGIPEATERS in space
> 
> Compared to the fun we are having with communicating with UI frames via 
> MIR in this country, someone just sent me a copy of a MIR pass in Europe.
> What a waste of bandwidth! I analyzed all 350 packets and here are the
> statistics broken down into the successful TEXT packets in 3 categories:
> 
> BBS:   330 packets to transfer 27 useful lines of text = 8%   effeciency
> CNCT:   17 packets to transfer  1 useful line  of text = 6%   effeciency
> UI:      2 packets to transfer  2 useful lines of text = 100% effeciency
> 
> The two UI stations communicated perfectly in 2 packets
> The two CONNECTED stations communicated 1 line only 1 way with 17 packets
> 31 of the 33 stations attempting to connect to the BBS accomplished
>       nothing!  And still spent 280 packets doing it!
> 
> BBS'S ARE NOT THE WAY TO USE PACKET RADIO ON SATELLITES!
> 	[... See original message for original analysis ...]
>  17  STATION-TO-STATION REQ/and RETRIES to convey only ONE LINE!
>        1  message line conveyed
> 
>   2  APRS TYPE Position/STATUS packets conveying station position and
>        status
> 
> CONCLUSION:  If we designed Amateur Satellites to be dumb digipeaters for
> UI frames only, then every successful packet CONTAINS USEFUL INFORMATION.
> In this case there would have been 350 lines of data, not just 29.

Bob,

I believe your analysis and conclusions are, at best, incomplete.

First, let me say that I am not a fan of the AX.25 protocol, traditional
amateur radio BBS implementations, or text-based applications protocols
on low-bit-rate  links.  I believe that the amateur radio community
would be well served by migrating from AX.25 to the IP protocol suite,
(or perhaps variants optimized for low-bit-rate links).  I also believe
that we ought to move beyond the dumb terminal paradigm of transporting
data as ASCII text strings, (and use more channel-efficient binary 
encodings).

Having said that, let me make a few comments about your analysis.

You observed several things, I think:

o	You compared an unacknowledged, broadcast datagram protocol
	with a store-and-forward messaging system.

o	You observed that a store-and-forward messaging system that
	supports only a single user simultaneously has some serious
	limitations.

o	You observed that text-based protocols are not particularly
	channel efficient.

Unacknowledged, broadcast datagram protocols have their place, particularly
for low-data-rate, time-critical, data that don't require any delivery
assurances.  Good examples of an appropriate use of these sorts of 
protocols include the APRS position protocols.

On the other hand, reliable store-and-forward messaging systems also have
their place.  Think for a moment what this e-mail list would be like
if it were implemented using AX.25 UI frames: you could talk only to
the people that were online at the instant you sent your message, you
wouldn't know if anyone received your message, you couldn't reliably send
messages longer that one packet, and so forth.  (I couldn't think of an
analogy to the requirement that both the sender and receiver(s) must
be in the footprint of the satellite, but you probably get the point.)

Certainly, a single-threaded store-and-forward messaging system provides
a target-rich environment.  I assume that with a bit of motivation someone
could create an AX.25 store-and-forward messaging systems that supports
multiple simultaneous users.  This would reduce the number of packets
you saw that were merely polling the space-borne BBS to check if it was
[still] busy.  (I suppose that there is some reasonable upper limit on
the number of simultaneous users that ought to be supported, based on the
length of time the satellite is above the horizon, the average length
of a connection, and so forth, but I haven't done the arithmetic.)

I think that your implicit suggestion that a store-and-forward messaging
system ought to support an interface similar to the TNC host mode is
a good one.  There is little need for sending verbose, redundant, human-
readable prompts, instructions, etc.

As I have said before, I also believe that your implicit observation that
human-readable text strings are inefficient encodings is absolutely correct.
I am also hopeful that a future generation of APRS applications protocols
will support a more efficient binary encoding of information.


Finally, AX.25 UI frames repeated through a satellite are not particularly
good for lots of applications.  For example, sending a text message to a
receiver that is not listening, either because they had other things to
do or because they are not within the satellite footprint, is a complete
waste of channel bandwidth.  In a similar fashion, sending a datagram
without any acknowledgment mechanism implies that the message wasn't
very important to begin with, perhaps because the message will be repeated
(which sounds like a waste of channel bandwidth), perhaps because the
message is time-critical and is worthless after a period of time (which is
what broadcast datagram protocols are good for), or perhaps because the
world won't be any different if the message isn't received (which begs the
question of why the message was even sent).

So, you appeared to have compared an unreliable, broadcast, datagram
protocol with a specific store-and-forward messaging system and concluded
that amateur satellites should support only the forwarding of AX.25 UI
frames.

I don't think so...

-tjs


----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home