Date: Fri, 22 Oct 93 04:30:01 PDT
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 #274
To: tcp-group-digest
TCP-Group Digest Fri, 22 Oct 93 Volume 93 : Issue 274
Today's Topics:
Baycom 4 port USCC card
Digipeaters Dont Work
fragmenting under netrom
NetRom standard
Network Standards (4 msgs)
Packet Radio Standards
Possible FAQ
slip/ppp problems in ka9q nos 930622? (2 msgs)
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: Fri, 22 Oct 93 09:31:55 +0100
From: Alan Cox <iiitac@uk.ac.swansea.pyr>
Subject: Baycom 4 port USCC card
To: tcp-group@ucsd.edu
The club station here has the opportunity to get hold of one of these
beasties and it looks quite nice - its a 4 channel PC card that supports
things like G8BPQ. What we want to know before we go any get one however
is will it support KA9Q, or would KA9Q over G8BPQ somehow be viable (this
is only a 286 with 1Mb of RAM).
Alan
------------------------------
Date: Thu, 21 Oct 93 09:55:58 +0100
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Digipeaters Dont Work
To: tcp-group@ucsd.edu
BZZT: The overhead of losses from tcp over a digipeated link are less
but not 0. On close to reliable links digipeating is great, only as the
quality goes down dramatically does the problem appear - Think about
the difference between 50% of 50% of 50% the packets, and 99% of 99% of 99%!
TCP isn't so bad because it doesn't have to keep stopping sorting itselkf out
and carrying on. A dropped frame means a missed ack which so long as the window
isnt full means the next retransmit is a bit longer and includes the old
data too. In AX.25 it means a long pause RR(P) frames, data retransmits that
need to be pretty much in the right order with long round trip times each
delay because of the way the ax.25 timers work out.
Alan
------------------------------
Date: Thu, 21 Oct 1993 07:51:18 -0400
From: cep4478@ultb.isc.rit.edu (C.E. Piggott )
Subject: fragmenting under netrom
To: tcp-group@ucsd.edu
A friend and I were having a discussion about his IP frames being fragmented
under netrom, and trying to figure out why it was happening. In a lot of
places there are references to a maximum segment size of 216 bytes, to
leave room for the netrom header, etc. in an AX.25 256 byte limited I-frame.
However, this morning he wrote this down for me:
256 - IP header - TCP header - NETROM header = 196
So shouldn't the documentation read "set mss=196 on netrom IP devices" ?
Chris
------------------------------
Date: Thu, 21 Oct 1993 12:38:09 +0100
From: "Fred N. van Kempen" <waltje@hacktic.nl>
Subject: NetRom standard
To: jangus@skyld.tele.com, tcp-group@UCSD.EDU
Jeff comments:
> Hummm, that "callsign" looks familiar, weren't you just involved in an, ahem,
> pissing contest with Gerard recently?
Yup, that's me.
Fred.
--
Fred N. van Kempen "Networking for the Masses !"
HACK-TIC Network Support Desk waltje@hacktic.nl
"I won't use "talk" with people I don't know. Sorry. -arl"
------------------------------
Date: Thu, 21 Oct 93 8:43:02 PDT
From: bmeyer@netcom.com (R. W. Meyer)
Subject: Network Standards
To: TCP-Group@ucsd.edu
The statement was made here a couple days ago that NET/ROM was no longer
being marketed. As a point of order thats not entirely true. I checked
with WA8DED (one of NET/ROMs oringinal authors) and it is still being
produced and marketed by a company called Amatech International (no I never
heard of them before either). I called and got one of their brochures.
They can be reached at:
Mail: 7034 N. Cedar Ave. Suite 102
Fresno, CA 93720
Phone: (209) 292-8438 (voice mail machine)
Telex: 6585541
EasyPlex: PPN 76337,727 (Compuserve)
Kinda doubt they'd be able to throw much light on the standards debate.
-Bob
--
------------------------------
Date: Thu, 21 Oct 93 01:08:02 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Network Standards
To: MIKEBW@ids.net
NET/ROM is actually two protocols -- a connection-oriented transport
protocol operating over a connectionless internet protocol. Not all
that different, in principle, from TCP/IP.
Phil
------------------------------
Date: Thu, 21 Oct 93 09:08:09 +0100
From: Mike Chace <mikec@praxis.co.uk>
Subject: Network Standards
To: MIKEBW@ids.net (Mike Bilow)
>>>>> Regarding Re: Network Standards; MIKEBW@ids.net (Mike Bilow) adds:
Mike> I am not sure I would agree with your characterization of NET/ROM as
Mike> a datagram protocol. In theory, yes, you could send NET/ROM inside
Mike> UI frames, but you don't. Furthermore, every existing
Mike> implementation of NET/ROM would fail to operate with a system which
Mike> embedded NEt/ROM data inside UI frames.
I must say that I like the approach used in the German FlexNet
System. To the user, nodes in the network look like digipeaters
but all traffic is carried on L2 AX.25 with hop-2-hop ack from node
to node. Users can connect to the node and make connects
to remote nodes just like the NET/ROM user interface. They also
have the option of using the node so it appears to them as
a digi, making the connect direct from their end. FlexNet also
has a system for nodes to propagate known paths to each other in much
the same way as the NET/ROM broadcast.
It's fast, simple, low in overhead and is transparent since it's
based completely on L2 AX.25 but just like the other systems, it
suffers from not being in the "Public Domain" which is a shame.
Mike
****
------------------------------
Date: Thu, 21 Oct 1993 14:48:20 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Network Standards
To: karn@qualcomm.com, tcp-group@UCSD.EDU
My comment about NET/ROM being a virtual circuit protocol with all the
overhead of a datagram protocol was something of a joke, really. You
are right to view it as a combined network and transport protocol, of
course. However, while the network protocol is connectionless in theory,
it is strongly bound to the connection-oriented link layer in practice.
This is really all I meant. There are a lot of improvements I can think
of applying to NET/ROM, and isolating the link layer would be the main
one if I had the opportunity to do it.
For example, NEt/ROM assumes that the link layer (AX.25) address is the
same as the network layer address, and therefore has no mechanism to
allow mapping between them. TCP/IP can run on a link layer with any
sort of address if there is a mapping protocol, such as Ethernet with
ARP, or no link address, such as SLIP.
-- Mike
.
------------------------------
Date: Thu, 21 Oct 1993 07:38:08 -0500 (CDT)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Packet Radio Standards
To: TCP-Group@UCSD.EDU
g4klx@g4klx.demon.co.uk says:
> NET/ROM and TCP/IP are both datagram protocols
In common ham use, yes you are correct. Most people I see use TCP/IP *OVER*
Net/Rom. But to be accurate, Net/Rom is a Virtual Circuit protocol, a
connection oriented protocol. If you get Net/Rom to work in the Datagram
mode, it ain't Net/Rom anymore (i.e., won't work with other Net/Roms).
> Does everyone remember how poor digi-peating was?
> Do people remember the bulletin from Tom Clarke W3IWI in 1988 (?) with the
> title similar to "Using more that three digi-peaters doesn't work".
> With TCP/IP over a connectionless Level 2 you have no advantage over
> digi-peating. I can only see use of a connectionless Level 2 being an
> advantage on dedicated frequencies with very few stations active, or on full
> duplex systems.
I'll agree with you that a mass of digipeaters on one frequency doesn't work.
The typical ham use of one central digipeater to bounce packets off of in a
roundtable also fails intermittantly because of collisions, but not quite as
bad as the gomers who use five and six digis. But given enough money, a
network of X-1 routers with seperate input frequencies and output frequencies,
and full blown IP to AX.25 BBS Nodes this argument doesn't hold up. Plus the
fact that by having a clear frequencies allows you to up the packet length to
512 or so on 9600. The Net/Rom would probably run out of memory or still be
trying to decide who it should connect to while the X-1 would already have sent
three packets.
NOS Station O----F1----o----F2----o----F3----O NOS Station
City 1 X-1 X-1 City 2
Anything that uses connection mode AX.25 over range seems to be a pig. One
protocol that seems to be an exception is Texnet. This network operates at
exceptional speed. From OKC to Dallas it is responsive and quick, while the
Rose network covering the same path is about 10 times as slow. I don't know
what it uses for a link protocol, but they are doing everything correct on
that score. The user interface leaves a lot to be desired however. From what
I can tell they do use a common UHF frequency.
---
Steve
------------------------------
Date: Thu, 21 Oct 1993 19:45:31 -0100 (GMT-1:00)
From: andy@mimuw.edu.pl (Andrzej K. Brandt)
Subject: Possible FAQ
To: tcp-group@UCSD.EDU
Hello,
now, I know that these are probably FAQs, but I don't know a better place to
ask, so please don't flame me (at least not too much)
1. Why if attach an asy interface on any version of NET and NOS, including
last by KA9Q, something happens to screen i.e. nothing appears as I type or
as it comes in, but can be seen only after next screen swap. Maybe I'm doing
something wrong?
2. I have recently decided to connect and use a PK-88 that I have. I did
attach asy as described, used param drt 1 and rts 1 so that data is flowing
from the TNC to computer and back (LEDs on TNC confirm that) but when I do
trace I can see after each packet received just garbage and error - corupted
header. What's that?
Someone may wonder why I'm asking these questions now, after using NET for a
while. Reason is simple, till yesterday I allways used it with BayCom modem
and driver or with ethernet cards and never had any of these problems.
--
73 de Andy SP5WCA
/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I
\-------------------+--------+-------------------+-------------------------/
------------------------------
Date: Thu, 21 Oct 1993 15:00:43 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: slip/ppp problems in ka9q nos 930622?
To: karn@qualcomm.com, tcp-group@ucsd.edu
I'll second that about using "LOCKDMA" ("LD") on the QEMM invocation line
being a good idea. However, if you do this, it is then also a good idea
to specify more than the default number of DMA buffers with "DMA=255".
If running DESQview, it is necessary then to DISABLE the "optimize
communications" setting with DVSETUP. Finally, if using QEMM with
Stealth enabled, greater stability might result from running it in
undocumented Mode P instead of Mode M or Mode F ("ST:P"). The DMA
handling will be different depending upon hardware and drivers, and
NOS can also be affected by DMA activity outside of NOS, if any.
Depending upon the DOS version in use, either disabling EMS ("NOEMS")
or forcing Int 21h buffering ("FB:Y") may also be needed.
-- Mike
------------------------------
Date: Thu, 21 Oct 1993 20:26:38 -0400
From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
Subject: slip/ppp problems in ka9q nos 930622?
To: tcp-group@UCSD.EDU
In your message of Thu, 21 Oct 1993 15:00:43 EDT, you write:
+---------------
| undocumented Mode P instead of Mode M or Mode F ("ST:P"). The DMA
+---------------
Quarterdeck claims that one possible side effect of ST:P is that you may end
up needing to low-level format your hard drive... be careful if you try it.
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development." ---dmeggins@aix1.uottawa.ca
------------------------------
End of TCP-Group Digest V93 #274
******************************
******************************