Date: Tue, 21 Dec 93 04:30:02 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 #329
To: tcp-group-digest
TCP-Group Digest Tue, 21 Dec 93 Volume 93 : Issue 329
Today's Topics:
Dealing with multiple ports...
KA9Q NOS in an OS/2 DOS Box?
Timers (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: Mon, 20 Dec 93 05:36:49 CST
From: kf5mg@kf5mg.ampr.org
Subject: Dealing with multiple ports...
To: tcp-group@ucsd.edu
> This gateway (uugate) now has multiple ports by which a TCP/IP users
> may connect. How does one make sure packets get routed to the correct port?
> Is this something that one would need ARP to handle?
One way to approach this would be to use one sub-net for one port and
one sub-net for the second port. Locally... we have 44.28.0.x users on our
2 mtr port and 44.28.1.x users on our 440 port. The gateway uses a single IP
address for both ports. 440 users use a
route add 44.28.0/24 portname gateway
route add 44.28.1/24 portname
and 2 mtr users do a
route add 44.28.1/24 portname gateway
route add 44.28.0/24 portname
This won't handle a user picking ports randomly. I don't think that anything
will handle a user picking ports at random using the same IP address. For
client users... you could use BOOTP to assign an IP address for the user so
they could talk to the gateway. The address for the bootp user could be a
sub-net and everyone could route the sub-net via the gateway. The client users
could route everything via the gateway and let it figure out what to do with
it.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: Mon, 20 Dec 93 14:27:14 CST
From: Ben Thornton <ben@yosemite.sps.mot.com>
Subject: KA9Q NOS in an OS/2 DOS Box?
To: kf5mg@kf5mg.ampr.org
>
> Is anyone running KA9Q's latest version of NOS in an OS/2 DOS box? JNOS runs
> fine, but NOS keeps crashing the DOS box after a couple of minutes of
> operating. I suspect that it's a problem with the Virtual Screen managment
> code. Has anyone else had this problem. Thanks.
I've been running jn110x15 since it came out in a DOS box under OS/2 2.1GA
with no ill effects...
--ben
--
Ben Thornton Amateur call: WD5HLS
Internet: ben@yosemite.sps.mot.com Motorola, Inc.
------------------------------
Date: Mon, 20 Dec 93 17:16:40 GMT
From: hall@aeesa.navy.mil ("Jon L. Hall")
Subject: Timers
To: tcpgroup@ucsd.edu
Can someone tell me how the retry timers work in NOS? I thought that a tcp
level connection retried initially at an interval defined by the tcp irtt.
After the intitial retry subsequent retries would backoff either linear or
exponentially depending on how the timer was defined. I also thought the the
backoff would progress up to the limit defined by the blimit parameter. Simply
stated I would think a system configured with the following parameters:
tcp timertype linear
tcp irtt 5000
tcp blimit 5
This system should backoff assuming no responses to packets from 5 sec to
10 sec...up to 25 seconds and then hold at 25 seconds. In practice this isn't
what happens and I would like to understand what the scheme is. Sorry I can't
read the sources and figure this out on my own. In addition to HOW this
process is suppose to work, I would like to hear a little about the rational.
Thanks...Jon...KF2EB
Internet...hall@aeesa.navy.mil
Amprnet....kf2eb@kf2eb.ampr.org
------------------------------
Date: Mon, 20 Dec 1993 21:22:24 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Timers
To: hall@aeesa.navy.mil
Well, the *original* code didn't have a backoff limit. The reasoning
is (actually it's a proof, not just conjecture) that unlimited
exponential backoff is necessary to prevent congestion collapse given
an unlimited number of users sharing a common link. Our problem, of
course, is that we don't know when a timeout occurs whether it was due
to congestion (the standard Internet assumption) or a link error (more
likely in ham radio). And even if the number of users may be in fact
finite, you don't know how many there are, therefore you really don't know
where to set the backoff limit. If the number of active users
exceeds your estimate, you collapse again.
My code also keeps a cache of rtt and mdev for each destination that
has been recently spoken to so it can use those parameters instead of
the fixed estimates when starting a new connection. This is handy if
you rapidly open and close a connection to the same host (e.g., with
FTP), as TCP doesn't have to learn the correct parameters all over again
each time.
Phil
------------------------------
End of TCP-Group Digest V93 #329
******************************
******************************