Date: Thu, 14 Jan 93 04:30:12 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 #14
To: tcp-group-digest
TCP-Group Digest Thu, 14 Jan 93 Volume 93 : Issue 14
Today's Topics:
AX.25 under Linux
BM
KISS and concatenated TCP ACK packets
PNEWS.COM: NOS news posting
Routing for Australia. (3 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: Wed, 13 Jan 1993 12:35:08 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: AX.25 under Linux
To: tcp-group@ucsd.edu
I tracked down the person who had done an AX.25 driver in the Linux
kernel. He currently has the driver working for TCP/IP only, there is no
direct access to AX.25 without using IP. I haven't gotten a look at his
code yet, hopefully I will soon.
I've been thinking about adding an AX.25 address family and protocols to
the Linux kernel. I'd copy the interface of Phil Karn's AF_AX25
implementation. This might make it possible to break existing KA9Q
clients and servers out into individual processes under Linux.
Bruce Perens
------------------------------
Date: Wed, 13 Jan 93 09:41:58 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: BM
To: tcp-group@ucsd.edu
First of all NN2Z if you are listening - I am either blind or looking
in the wrong place but I do not see a new bm in UCSD's incoming??
I asked this quite awhile back - How do you view mail directories
below /spool/mail in BM. 'n xxx/yyy' does not work.
I usually use BM to view my mail but I guess I could make an area
to the subdir and use the NOS BBS also.
Doug
------------------------------
Date: Wed, 13 Jan 93 15:37:08 -0500
From: grebus@isis1.bxb.dec.com (Gary Grebus)
Subject: KISS and concatenated TCP ACK packets
To: MIKEBW@ids.net, tcp-group@ucsd.edu
>I would STRONGLY discourage anyone from implementing the ACKPRIOR scheme.
>While it looks logical on paper, listening to a channel where it is being
>run will immediately indicate a problem: there is no space for other users
>to get in when two stations are sending data to each other using ACKPRIOR.
>MFJ TNCs default to ACKPRIOR enabled, and they are the bane of packet.
I've never actually seen an exact description of the AX.25 "Priority ACK".
It seems like it should require a node sending data (as opposed
to just an ACK) to contend for the channel normally? And it doesn't
help with links that run using UI-frames.
>The proper solution to sending three TCP ACKs when only the last is
>necessary is to run a NOS timer of about 5 seconds before sending an ACK.
>This is how the netrom code implements ACKs. (At least, this is the way
>it does now since I fixed a bug in the routine that does it.) In other
>words, have an incoming TCP frame start a timer (if none is already in
>progress) that will cause an ACK to be sent. If more TCP frames arrive
>between the starting and expiring of the timer, the ACK will be sent for
>them also, so that the ACK is current as of the expiration of the timer.
That works assuming that the remote end is able to send new data. The
case I've seen is that the local end is unable to successfully send an
ACK, and the remote is retransmitting. Thus the TNC queues multiple
ACKs for the same data. It seems like the round-trip-time calculations
should eventually adjust for this, but its not clear to me if that
actually happens. This situation also implies some sort of fairness problem
with channel access...the remote is able to access the channel more
often (to send data) than the local (to ACK it).
/gary
K8LT
------------------------------
Date: Thu, 14 Jan 1993 00:48:50 +0200
From: Costas Krallis SV1XV <kkrallis@leon.nrcps.ariadne-t.gr>
Subject: PNEWS.COM: NOS news posting
To: tcp-group@ucsd.edu
I created this program today, based mainly on EI9GL's
sources for "bmh". It seems to work OK with WG7J NOS
and after some more testing, clean-up etc I'll upload
it to ucsd.edu, most likely next Sunday.
The program is 27k and compiles with Turbo-C 2.0
73 Costas SV1XV
------------------------------------------------------------------
| Dr. K. Krallis SV1XV * Epsilon Software S.A.
| ------
| Internet: kkrallis@leon.nrcps.ariadne-t.gr
| Packet radio: SV1XV @ SV1IW.ATH.GRC.EU
| AMPRnet: sv1xv@sv1xv.ampr.org [44.154.1.11]
| Snail Mail: P.O.BOX 3066, GR-10210 Athens, GREECE
------------------------------------------------------------------
I'd like to use NOS to introduce the local
packet group to it, but I'm open to suggestions if somthing else is
more appropriate.
Thanks and Cheers
James Dean
jdean@drao.nrc.ca
VE7JWD @ VE7EHS
------------------------------
Date: Wed, 13 Jan 93 10:11 CST
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Subject: Routing for Australia.
To: tcp-group@UCSD.EDU
> Is it possible to have a router defined to handle a subnet of network
> 44?
Not as the Internet routing model is currently defined.
The idea is that a network is solely responsible for routing
frames from its Internet gateway to any machine within the
network. Subnetting is used to make routing within a network
easier, but doesn't help at all with routing from outside the
network.
> The problem for people outside of the US is that all frames from the Internet
> to Amprnet go via mirrorshades at ucsd. This means that the 512Kb link
> between Australia and the US is unneccessarily carying frames over and then
> back (via encap).
Yep, and there's no way around it so long as you stay within net
44 short of routing the frames back to Australia over another
link, such as a radio link.
> I was wondering if it was possible for us to have all 44.136 frames routed
> to a machine like minnie. (This is ignoring the problem of how
> do we get the router information setup in the first place. :-( )
That problem will defeat any such effort, as the protocols the
Internet uses to determine how to route frames for a given
destination between gateways over the backbone only consider net
numbers when making decisionsl; hence, there can be only one net
44 gateway to the rest of the Internet.
...Jay, K5ZC
------------------------------
Date: Wed, 13 Jan 1993 15:37:33 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Routing for Australia.
To: tcp-group@UCSD.EDU
But it might be possible for a regional network to say all of net 44 that
it sees goes to this address, and forget what any other administrative
domain says. Then you would get all net 44 traffic that made it to
the administrative domain boundary (the reverse problem :-)
milton
KB5TKF
<I don't speak for IBM>
------------------------------
Date: Wed, 13 Jan 1993 18:27:19 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Routing for Australia.
To: S0JM@ADMIN.HSC.UTH.TMC.EDU (Jay Maynard)
> That problem will defeat any such effort, as the protocols the
> Internet uses to determine how to route frames for a given
> destination between gateways over the backbone only consider net
> numbers when making decisionsl; hence, there can be only one net
> 44 gateway to the rest of the Internet.
Your information is a little out of date. The current Internet routing
systems understand both subnets and route aggregation. Basically, the new
algorithms consider a 'network' as a IP-addr/mask pair.
Examples of subnets:
net 44.136 becomes 44.136.0.0/255.255.0.0
net 192.75.93.[2-6] becomes 192.75.93.0/255.255.255.148
An example of route subsumtion:
nets 192.75.20, 192.75.21, 192.75.22, 192.75.23 can be advertised using a
single route entry for 192.75.20.20/255.255.252.0
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Thu, 14 Jan 93 09:18:29 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
To: tcp-group@ucsd.edu
Priority packets are easy with UI frames, you just stuff them earlier
down the sending queue for the kiss device.
I've been watching the multiple acks and the rtt doesn't help in many cases
because round trip times seesaw wildly, and worse still the more acks
being mistakenly sent the more acks blocking the channel, the slower
the data arrives, causing more acks
Alan
------------------------------
End of TCP-Group Digest V93 #14
******************************
******************************