From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Fri Feb 15 14:58:56 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Fri, 15 Feb 91 10:27:51 EST for lee Received: from somewhere by elf.wang.com id aa28881; Fri, 15 Feb 91 14:58:54 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA21953; Fri, 15 Feb 91 08:36:50 -0500 Received: by ucsd.edu; id AA14887 sendmail 5.64/UCSD-2.1-sun Fri, 15 Feb 91 04:30:22 -0800 for jbloom Received: by ucsd.edu; id AA14881 sendmail 5.64/UCSD-2.1-sun Fri, 15 Feb 91 04:30:18 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102151230.AA14881@ucsd.edu> Date: Fri, 15 Feb 91 04:30:17 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #42 To: tcp-group-digest@ucsd.edu TCP-Group Digest Fri, 15 Feb 91 Volume 91 : Issue 42 Today's Topics: collision avoidance JA-bits or NNTP server anyone? Network card info Re: G1EMM 113016 program size reduction Send Replies or notes for publication to: . Subscription requests to . 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, 15 Feb 91 05:16:53 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: collision avoidance To: tcp-group@ucsd.edu Sorry I haven't been too talkative lately - I haven't even had a chance to go through the tcp-group mail for the last week yet. I have been active, though, experimenting with some simple ways to reduce channel collisions. This was motivated by frustration in trying to get something approaching the potential performance out of my 56kb/s WA4DSY modems. The modems themselves work fine. I could ping one from the other and lose maybe 5 packets out of 1000. (One run lost no packets at all out of 1000). TCP transfers with mss == window also work quite well. The problem comes when you use TCPs with configurations more typical of the Internet (mss=1460, window=8K). FTPs really bogged down with these settings. A little investigation and thought revealed the following. As slow-start begins, TCP sends only a single packet and waits for an ack. It and the ack get through fine. The returning acknowledgement causes TCP to open its congestion window to two packets, and they go out back-to-back. The receiver returns two acknowledgements, but unfortunately (for various reasons, including disk access delays) they come out with a slight carrier gap between them. The first ack causes the sending tcp to open its window to three packets and begin sending them, frequently colliding with the second ack coming back from the receiver. The sending TCP times out, backs off, and retransmits a single packet (the one missing). It gets through and is acknowledged, but because it had been retransmitted the retransmission timer is left at its backed-off value (this is the "Karn algorithm" at work). TCP proceeds to ramp up the congestion window again, sends two packets, and collisions start again. Unfortunately, the retransmit timer was never given a chance to come back to its "normal" value, so it just keeps on climbing as data collides with returning acks. Last weekend I decided to finally implement the MACA scheme I talked about in my last ARRL conference paper. I first implemented a driver primitive called "mute" that allows me to inhibit the transmitter for some specified interval. (This was easy to implement - it's combined with the p-persistence test. It is exactly as though I set p=0 for some period of time, and then return it to its normal value). The purpose of the mute primitive was of course to implement the MACA requirement that receiving a CTS message inhibits your transmitter for some specified interval unless it is directed at you. While testing this feature I had an idea. The whole purpose of MACA is to keep you off the channel when you know somebody else is about to transmit. In MACA this is done explicitly with the CTS message. But in reality, almost ANY message (data OR ack) is essentially an invitation for the addressed station to send something (data will elicit an ack, and an ack often, but not always, elicits more data). So instead of using explicit RTS/CTS messages, why not just do the following: 1. If you overhear a packet addressed to somebody else, inhibit your transmitter for X milliseconds. 2. If you finish transmitting a series of packets, inhibit your transmitter for X milliseconds. (This is really just a special case of #1, and it wouldn't have to be explicitly stated if we all had full duplex interfaces that could monitor our own packets.) 3. If you receive a packet addressed to you, cancel the previously set transmitter inhibit, if any. I used inhibit intervals of 500 ms with my wa4dsy modems, and the improvement was dramatic. FTPs actually work pretty much as expected, although there is some interaction with the p-persistence algorithm (sometimes the other station defers so long that the first station's inhibit interval expires first). The effect of this algorithm is to get away from the current packet radio paradigm of contending anew for the channel each and every time you key up. As long as two stations keep a dialog going, everyone else will defer to them until they are done (i.e., pause for a while). Then the stations waiting to send traffic contend with each other and a new pair of "winners" are chosen. There has always been a tradeoff between fairness and efficiency in packet radio; it's a fact of life. This algorithm allows us to move from complete fairness (i.e., nobody gets through because of all the collisions ;-)) toward overall efficiency. What I'd like to do now is to make it possible to tweak a "knob" and select some sort of compromise between fairness and efficiency, ie., to keep a pair of stations from hogging the channel indefinitely during a very long file transfer. One way of doing this is to combine the transmit mute/inhibit feature with p-persistence. In effect, I want a time-varying value of p, influence by what you hear on the channel. If I overhear a packet sent to somebody else, I decrease my p value almost (but not all the way) to zero and let it slowly rise again. If I get a packet addressed to me, I increase p to 1 and let it decrease again. In this way, a pair of stations sending packets back and forth will most likely get it again, but there's a small probability (on each packet) of another pair jumping in and taking the channel away. In other words, you can almost "time slice" the channel, with "task switching" done in a distributed, probabilistic fashion. Ideas? Comments? BTW, I have an idea to make TCP a little more tolerant of the problem I discussed earlier, independent of fixes at the link layer. I haven't tried it yet, but my plan is to delay the reopening of the congestion window after a timeout to first allow the retransmit timer to return to its regular value. Phil ------------------------------ Date: Thu, 14 Feb 91 14:06:40 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: JA-bits or NNTP server anyone? To: tcp-group@ucsd.edu (tcp-group) Has anyone done anything with the Usenet-style JA_bits that Bdale made available a few years ago? Have there been any improvements made to the programs (like cleaning up the english, crash proofing, completing functionality)? Or has anyone integrated an NNTP server into NOS to complement the NNTP client? We are interested in getting some "special interest" message broadcasts going within our little IP community to try and stimulate and hold interest in using the TCP/IP system on packet. We don't have any Unix systems available to act as a network NNTP server, and aren't particularly interested in just re-broadcasting the BBS traffic via IP. I ftp'd the JA_bits when Bdale first made them available, and played around with the programs for a while. That original system worked, but it lacked a few things that I think are necessary to get a large group of people using it (like an expire program?). I actually like the idea of the news software being external to NOS. Helps to keep NOS smaller(?), and you really only need to stop and process news a few times a day, depending on the amount of activity. I assume that with the apparent use that the system is getting in Japan, work on the code has continued. Is it available? Just thought I'd ask what other folks might be doing other than propagating the same old BBS bulletins and Usenet messages (I'd love to pass on the latter, but I don't have time to read everything before it goes out). 73 . . . Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com (Tempe, AZ) ------------------------------ Date: Thu, 14 Feb 91 10:44:55 CST From: kurt@cs.tamu.edu (Kurt Freiberger) Subject: Network card info To: tcp-group@ucsd.edu I got a network card handed to me: A TC4035 by Thomas-Conrad Corp. The Clarkson drivers don't list it. Anybody know what kind of beast it is? Got any info on the DIP switches? It's a rather neat card; 16-bit with AUI and TP connectors. Thanks - Kurt % Kurt Freiberger, WB5BBW Dept. of Computer Science, TAMU % % Internet: kurt@cs.tamu.edu | "Try not to become a man of success % % AuralNet: 409/847-8607 | but rather a man of value." % % AMPRNet: wb5bbw@wb5bbw.ampr.org | - Albert Einstein % % Disclaimer: Not an official document of Texas A&M University % ------------------------------ Date: Thu, 14 Feb 91 19:11 CST From: S0JM@ADMIN.HSCH.UTEXAS.EDU Subject: Re: G1EMM 113016 program size reduction To: kelvin@KELVIN.UK22.BULL.COM > I have to say that if you are getting 600kb+ executables, something is > *VERY* wrong with your compilation environment. For a cut-down version > I get a .exe of about 300kb which is reduced to about 160kb by pklite. > I suggest you try compiling up an unmodified copy of my version and > see what that generates on your system. If that works ok, then I suggest > you look very carefully at your modifications. :-) I tried that. I got an executable of 660K, versus 662K for the DG1 version. (I went ahead and #undef'ed PACKET.) Looking at the link map shows that the end of the code is only at 328K, including all data areas. What could take up the extra 332K??! Ouch! I'd guess that it'd work better if the extra cruft wasn't there. How do I go about looking at what's there? ------------------------------ End of TCP-Group Digest ******************************