Date: Wed, 3 Mar 93 04:30:08 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #59
To: tcp-group-digest
TCP-Group Digest Wed, 3 Mar 93 Volume 93 : Issue 59
Today's Topics:
Defining the link bits (3 msgs)
Link Layer replacement
New AX25
physical layer and FEC engineering
RCS 5.6 available for MS-DOS
TIP mail problem/answer??
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 2 Mar 93 15:39:52 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Defining the link bits
To: Steve Sampson <ssampson@sabea-oc.af.mil>, TCP-Group@UCSD.Edu
In atricle by Steve Sampson:
>
> I don't know if I like all that callsign stuff in there. It's basically a
The MAC layer doesn't need to pass large addresses if it can find a way to
hash them down to a smaller size. As long as the layers above don't find out
about it (i.e the MAC layer can convert addresses so that the layers above
still see the correct ones, sort of like ARP).
Warren
------------------------------
Date: Mon, 1 Mar 1993 22:04:58 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Defining the link bits
To: Steve Sampson <ssampson@sabea-oc.af.mil>
> I don't know if I like all that callsign stuff in there.
Certainly not all the time on HF. I agree it's useful mostly to ID.
> I think for speed that 64 bits [in an address] should be sufficient.
Well, we have these internet addresses that are already coordinated,
so why not use them, at least until we run out of numbers?
Certainly you can make a practical packet with binary 64-bit addresses.
That is probably the best space/efficiency balance, and has the virtue
of being very simple.
The only added merit that my proposal offers is that it provides room to
build and experiment with various forms of addressing. Of course,
addressing is an important part of routing, and I think that devising
methods of routing a dynamic amorphous network is an area where Amateur
Radio can contribute to the state of the art.
Bruce
------------------------------
Date: Tue, 2 Mar 1993 05:30:34 -0600 (CST)
From: Chris Cox W0/G4JEC <chrisc@biggus.moron.vware.mn.org>
Subject: Defining the link bits
To: ssampson@sabea-oc.af.mil (Steve Sampson)
Steve Sampson says:
>
> I don't know if I like all that callsign stuff in there. It's basically a
> rider that only has to be sent on initial connect. Why send it over and over?
Just because that is the case in the good ole US of A, don't assume that
it is the case in every other country on Earth.
--
73 Chris Cox W0/G4JEC
chrisc@biggus.g4jec.tcman.ampr.org chrisc@biggus.moron.vware.mn.org
Eleventh Hour Contest Group - North American Chapter; Minneapolis, MN
Twin Cities Metro Area Network node (biggus.g4jec.tcman.ampr.org)
**** And lest they forget: ****
Packet radio fiends really enjoy playing with their bits...
------------------------------
Date: Mon, 1 Mar 1993 21:37:51 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Link Layer replacement
To: Brian Kantor <brian@UCSD.EDU>
On Mon, 1 Mar 1993, Brian Kantor wrote:
> Those packets seem kinda long to me. Remember, people, this isn't a
> cable; very few bits in a row can get through before something hits them.
>
> FEC is well and good, but depending on it to fix more than a few errors
> per packet will demand a high price in bandwidth and complexity. We can
> afford some of that, but let's not make it too 'expensive'.
It's important to address the needs of HF communications. What I understand
so far about them (not much) is:
Fading and noise are much worse.
Channel-sharing by CSMA is not practical.
Bandwidth is very limited.
This is going to make any packet look big. Some things that might help, I
guess:
Always use data compression. Unfortunately, this means your
error correction system has to work very well, or you'll get
nothing but gibberish. By the way, Z-80s can run Lempel-Ziv
compression in real-time, so fitting this in the TNC is practical.
Fragment the link-layer packet into smaller packets at the MAC
layer. That way, pairs of long addresses get replaced by a sequence
number for most packets.
Use trellis-coding like Clover. Now that $250 modems run 14,440
baud on voice-grade phone lines, there's little excuse for amateur
radio to drag behind channel-utilization technologies.
Use spread-spectrum? I don't understand how processing gain works
yet, and how practical this is for HF.
We have some opportunity to lead here, rather than just cloning the phone
company's packet protocol or the shipboard Telex Over Radio system. Let's
hear some ideas, folks!
Bruce KD6OTD
------------------------------
Date: Tue, 2 Mar 1993 13:20:40 +1000
From: makinc@hhcs.gov.au
Subject: New AX25
To: tcp-group@ucsd.edu
Dennis writes;
> How about publishing the IP addresses with your local FCC/DOC. The addresses
> have to be coordinated anyways. Just attach a callsign to them. Does this
> not meet the criteria?
Not really. This "list" would always be out of date and would require
manual intervention by the operator to install the addresses for everyone
talked to.
Not really practical.
Carl.
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-9443
------------------------------
Date: Tue, 2 Mar 93 00:30:39 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: physical layer and FEC engineering
To: S0JM@ADMIN.HSC.UTH.TMC.EDU, goldstein@CARAFE.TAY2.DEC.COM
Jay,
The base computer to do anything serious is a 386SX. Windows and many late
programs will either not run or not run well on anything less. Most if not
all of the TCP packeteers in my area have upgraded to this level. Many to
486's. I have no real sympathy for anyone using less than the above not
even for monetary reasons, as a 386SX-25 MB can now be had for as low as
$100, far lower than what anyone paid for a 286, four years ago, or an 8088
eight years ago. Boy if cars were like that! ... so I paid $16000 for a
car eight years ago and today I can get about 100 times the performance
for $4000 - I think we would be selling lots a cars.
Doug
------------------------------
Date: Mon, 1 Mar 93 17:55:53 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: RCS 5.6 available for MS-DOS
To: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
> > Date: Sat, 27 Feb 93 10:05:47 PST
> > Message-Id: <9302271805.AA18739@suntan.Tandem.com>
>
> I remember someone tried the RCS 5.6 for DOS and had some problems
> with it, one if them being CR CR LF as end of line - Phil's NOS RCS
> files contains CR LF and RCS 5.6 adds one more CR, second Phil used
> names with %v and RCS 5.6 doesn't remove it. Can use RCS 5.6 when
> Phil puts NOS sources in its format - now it isn't compatible.
The bugs associated with RCS 5.6.x beta converting end-of-line
separators incorrectly have been fixed with the recently released 5.6
version. To use RCS 5.6 with the current base NOS RCS files, just
change the three occurrences of 'co { $@ }' to 'co -x%v { $@ }' in the
makefile and it will work fine.
Tony
------------------------------
Date: Tue, 2 Mar 93 01:09:32 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: TIP mail problem/answer??
To: tcp-group@ucsd.edu
First of all I can tell you how to bomb out the tipmail - phone or
terminal connection in short order .... log in on tip, read a long
message with no more prompting - 'xm 0' - by long I mean something
like tcp group digest - 30K or so in one message.
This will dump core to 0 in most cases - or at least doing this a few
times will. What seems to happen here is that the BBS dumps the entire
message and at 2400 baud the tipmail phone connection lags way behind.
The data has to be stored somewhere. I noticed this problem when I was
putting in the xmodem code - I mentioned it on here - I was flushing
on each character rather than at the end of a block and core was going
away in a hurry. This seems to be a very touchy thing in NOS and I
suspect the cause of many problems. Making rahter benign changes seems
to make radical differences. Anyhow my fix as shown below apllies only
to tipmail. It pauses long enough to allow the packets to flow out
evenly. Using this fix the core stays constant with data flowing out
at a steady pace over a long period - in my case at 2400 baud.
This IS NOT a good fix and the problem exists in other places - I.E.
the download ascii (or uunencoded) in tipmail. I don't really know what
a good fix would be (some help here??)
Rather than the mailbox - (tputs) code expanding into a big buffer
waiting for the asy code to output the data (slowly) it should wait
for some smaller buffer to become empty.
Anyhow if anyone wants to plug the immediate problem here is the fix...
Mods to bmutil.c (doreadmsg function)
col = 0;
if(usemore && --lin == 0){
>>>>> if(m->type == TELNET || m->type == TIP_LINK)
c = tkeywait("--More--",0);
else /* For AX.25 and NET/ROM connects - WG7J */
c = mykeywait("More(N=no)? ",m);
lin = m->morerows;
if(c == -1 || c == 'q' || c == 'Q')
break;
if(c == '\n' || c == '\r')
lin = 1;
}
>>>>>> if(m->type == TIP_LINK && !usemore) {
>>>>>> usflush(Curproc->output);
>>>>>> pause((long)(strlen(buf)*3)); /* works for 2400 baud */
>>>>>> }
}
}
iamdone:
/* If this was 'RM' or 'VM',
* free the memory allocated for myargv[] - WG7J
*/
if(m->stype == 'M') {
for(i=1;i<argc;i++)
free(myargv[i]);
}
return 0;
}
Doug
------------------------------
End of TCP-Group Digest V93 #59
******************************
******************************