Date: Mon, 9 Aug 93 04:30:06 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 #203
To: tcp-group-digest
TCP-Group Digest Mon, 9 Aug 93 Volume 93 : Issue 203
Today's Topics:
encap code and Linux
Kiss (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: Sun, 8 Aug 93 19:32:08 EDT
From: ron@chaos.eng.wayne.edu (Ron Atkinson - N8FOW)
Subject: encap code and Linux
To: tcp-group@ucsd.edu
Has anyone written or ported the ip-ip encap code for Linux yet? I know
about it for 386BSD, but if it's already one it'll save a lot of time.
Would like to replace the NOS system with a Unix system for the packet
<> internet gateway.
Ron N8FOW
------------------------------
Date: Sat, 7 Aug 93 13:15:07 EST
From: Lyman Byrd <lyman@attwat.twuug.com>
Subject: Kiss
To: tcp-group@ucsd.edu
Well yes I think Kiss has some problems. This is the reason why. I suspect
that most already know this but I will go over it anyway. For those who
do not have the luxury of being able to run ip all the time over the radio
paths but have to contend with netrom and nodes and such, take a look at
your ax status when sending a lot of tfc. You will notice that the que will
sometimes climb quite high (>20). When you have a busy freq then it
compounds the problem even more. What happens is the socket expects a reply
from the other station in a given time. This is not always the case and
so the socket sends another packet just like the last one thinking that the
other one did not get through. It also increments the backoff. This is
very good and in one reguard we are very nice to the other folks on the ckt.
I have been able to get around this a little by setting a very long tcp irtt.
Say two or three minutes(please stop snickering). This allows a poor path
to get a reply back before I send out another packet. What happens is that
conditions change and the path becomes very good and now my srtt to this
station is say 5 seconds or so.. after a while I send another msg and the
path has gone to pot again and the real rtt is again back to a minute or
more. Now I start out sending packets and the freq is busy and I can't
get the attention of the nearest point of contact. I am steady sending out
packets every 5 seconds or so but all they are doing is pileing up in the
que and not going anywhere. now the first one finally gets to the other
station and of course it replies and has the same situtation that I have and
their packet que builds up. backoff at some point starts to take over and
reduce the number of DUPLICATE packets but the damage has been done.
The local group started discussing this and wondered what could be done. We
figure if nos would know to bit bucket all duplicate packets until at least
the next point of contact had gotten the first then that would help. Phil
is that what your kiss code does? Is your kiss code in the public domain?
Even ax25 sysops have seen this problem and have had to adjust thier tncs
to get around the problem. I think nos has the right idea in the back off
scheme but it too has it's drawbacks. For instance, when the situtation like
the one descibed above occurs then backoff puts you into a wait of sometimes
as much as an hour before the next retry (using linear timer). A backoff
of three under the right conditions can give you a timer of >500 seconds.
Am I blowing smoke here or do I have the facts correct? For those who
say run ip all the time is like deciding that the interstate highways
are the wrong thing to do but we really should have tunnels connecting
the major cities across the country. You can't get there from here.
My two cents worth. Tks for the bandwidth.
--
Lyman/wa4yse
PBBS: wa4yse@kj4lq.va.usa.noam IP ADDRESS: [44.62.64.80]
INTERNET: lyman@attwat.twuug.com
------------------------------
Date: Sun, 8 Aug 93 23:51:38 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Kiss
To: lyman@attwat.twuug.com
The TCP round trip timing code is about as smart as it can be, given the
need for layering modularity. Note that TCP computes not only the average
round trip time, but also its variance (actually its mean deviation, which
is a good approximation but is much easier to compute). The retransmission
timeout used at any given moment is a function of both these variables -- the
greater the average *OR* the variance, the greater the retransmission timeout.
So if your network has rapidly fluctuating delays, you really shouldn't be
seeing a lot of trigger-happy TCP retransmissions.
Lost TCP segments causing backoffs is another matter. If you have serious
problems with lost AX.25 packets, turn on link level acknowledgements or
fix whatever it is that's causing packets to get lost in the first place.
Lately I've been sketching out a completely new link layer protocol that
combines MACA (see my paper 3 years ago in the ARRL CNC proceedings) with
code-combining FEC. Not only should it be highly effective in dealing with
hidden terminals, it should deal well with intermittent QRM (particularly
radar).
Amateur packet radio desperately needs new physical and link layers. You can't
build castles on quicksand.
Phil
------------------------------
Date: Mon, 09 Aug 93 02:41:24 UTC
From: klarsen@centaur.arl.army.mil
Subject: Kiss
To: karn@qualcomm.com
Hi Phil, have you seen Bill Beech, nj7p and his tnc-3? Bill has been
doing the improved TheNet chips and is acutley aware of netrom's short
comings. I understand his paper is completed and he plans to present
at some forum.
I will dig out the indicated proceedings and read with renewed interest.
I have been interested in an old joy, getting NET attached to the Internet
and my home computer attached to that. Not yet like I want it but close.
------------------------------
End of TCP-Group Digest V93 #203
******************************
******************************