Date: Thu, 23 Sep 93 04:30:02 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 #246
To: tcp-group-digest
TCP-Group Digest Thu, 23 Sep 93 Volume 93 : Issue 246
Today's Topics:
backoff bugs (2 msgs)
link level protocol slides
SunOS 4.x AX25 kernel driver
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, 22 Sep 93 16:18:42 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: backoff bugs
To: bsimpson@MorningStar.Com
Bill,
I've thought about your comments on the RTO wraparound when the
backoff gets high. The wraparound occurs at 4+ billion milliseconds,
or about 49.7 days. I therefore suspect you're getting there because
of repeated tcp kicks, not because of actual retransmission timeouts.
Your trick of resetting the backoff to 0 whenever you do a kick should
be enough to avoid this problem in the vast majority of cases. I'll
put that in. I'm very reluctant, however, to set *any* kind of
arbitrary limit (minimum or maximum) on RTO, other than the inherent
one upper imposed by overflow, and the lower one imposed by timer
granularity. In particular, 120 seconds is too short an upper limit;
e.g., it would keep my demand-dialed SLIP link (with 10 minute timout)
up continuously, even if the far end had gone unreachable. And 500 ms
is too long an estimate for many Ethernet paths.
Phil
------------------------------
Date: Thu, 23 Sep 1993 1:09:30 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: backoff bugs
To: karn@qualcomm.com, tcp-group@ucsd.edu
When the source is released, EVERYTHING is a user-configurable option.
While I'm on this subject, here is a big and growing problem related to
this issue. JNOS started this, but it has been picked up in other NOS
variants. Some NOSs unilaterally terminate a TCP circuit after a settable
number of retries. This often shows up when such a system tries to send
SMTP mail over a bad radio path. SMTP circuits are opened and the mail
begins to flow. As it slows down, the backoff counter increments. When
the backoff counter has been incremented enough times, it terminates the
circuit. This leaves the socket at the mail receiver in use foreever
(until manually reset). This is especially serious with SMTP, since the
whole process will repeater over and over each time the "smtp timer"
expires, eventually using up all of the available sockets on the SMTP
receiver host.
I am not sure that timing out TCP circuits is impossible to do in some
intelligent way, but this method is obviously flawed. My thought is to
have a log associated with each TCP session control block that holds
the time of last transmitted or received frame. If the time since last
activity exceeds some threshold, then reset the circuit. This would
help system deal with the JNOS timeout scheme, and would prevent hosts
from timing out and terminating sessions unilaterally.
-- Mike
------------------------------
Date: Thu, 23 Sep 93 00:22:38 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: link level protocol slides
To: tcp-group@ucsd.edu
I've uploaded a postscript file containing the slides I presented last
Saturday at the ARRL SW Division Convention in Ventura CA. The title
was "Toward New Link-Layer Protocols for Amateur Packet Radio". It
dealt primarily with forward error correction (FEC), specifically Fano
decoding of convolutional codes, and how it might be combined with my
earlier MACA scheme into an experimental new link layer protocol for
medium speed VHF/UHF packet radio.
The file is /hamradio/packet/misc/newlink.ps.
Phil
------------------------------
Date: Thu, 23 Sep 93 01:14:20 +0300
From: Costas Krallis SV1XV <kkrallis@leon.nrcps.ariadne-t.gr>
Subject: SunOS 4.x AX25 kernel driver
To: william.dorsey@corp.sun.com
Bill, could you please let me know what excactly you did
about the missing include file "ax.h" ?
If you created it, could you please post it to me?
Otherwise, where can I download it from?
Regards Costas SV1XV (ex G7AHN)
------------------------------------------------------------------
| Dr. K. Krallis, SV1XV * Research Engineer
| Metallurgy Lab., National Technical University of Athens
| ------
| Internet: kkrallis@leon.nrcps.ariadne-t.gr [143.233.2.1]
| Packet radio: sv1xv@sv1uy.ath.grc.eu
| AMPRnet: sv1xv@sv1xv.ampr.org [44.154.1.11]
| Snail Mail: P.O.BOX 3066, GR-10210 Athens, GREECE
------------------------------------------------------------------
------------------------------
Date: Wed, 22 Sep 93 21:04:03 -0700
From: owner-tcp-group
------------------------------
Date: Wed, 22 Sep 93 21:45:51 -0700
From: owner-tcp-group
------------------------------
End of TCP-Group Digest V93 #246
******************************
******************************