Date: Sat, 29 Jan 94 04:30:06 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 V94 #26
To: tcp-group-digest
TCP-Group Digest Sat, 29 Jan 94 Volume 94 : Issue 26
Today's Topics:
Circuit Cellar
help
Linux & Radio (2 msgs)
Linux: another question...
RE - mtu,mss,window
TCP MSS and TCP WIN settings
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: 28 Jan 94 11:29:34 EST (Fri)
From: Terry Bell <tbell@n8hsp.nshore.org>
Subject: Circuit Cellar
To: TCP-Group@ucsd.edu
Send email to 'info@circellar.com' for info on how to request files via email.
--
Terry Bell N8HSP
tbell@n8hsp.nshore.org n8hsp@n8hsp.ampr.org 44.70.4.10
------------------------------
Date: Sat, 29 Jan 1994 02:10:14 EST
From: "Eric Todd Budinger" <budinger@titan.ds.gen.nj.us>
Subject: help
To: tcp-group@ucsd.edu
--
Eric T. Budinger Dan's Domain 201-586-1223
budinger@ds.gen.nj.us Ham Central SysOp
ericbud@ritz.mordor.com 1-201-398-4619 (voice)
n2koj@w2xo.pa.usa.na 1-201-205-2134 (digital)
------------------------------
Date: Fri, 28 Jan 94 15:28:07 GMT
From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
Subject: Linux & Radio
To: tcp-group@ucsd.edu
Slackware is probably the best choice - nobody uses the latest gcc much yet
because the libraries and tools dont match and the C++ part of gcc 2.5.x is
a real problem at the moment.
For radio info and Linux
mail linux-activists-request@niksula.hut.fi
X-Mn-Admin: join HAMS
(or it might be HAM)
Hardly anyone uses it
------------------------------
Date: Fri, 28 Jan 1994 17:24:28 -0500
From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
Subject: Linux & Radio
To: tcp-group@ucsd.edu
In your message of Fri, 28 Jan 1994 15:28:07 GMT, you write:
+---------------
| For radio info and Linux
|
| mail linux-activists-request@niksula.hut.fi
| X-Mn-Admin: join HAMS
| (or it might be HAM)
|
| Hardly anyone uses it
+------------->8
Lots of us *read* it; however, it seems that the tcp-group, nos-bbs, and
ka9q-unix mailing lists are used in preference to the Linux-Activists HAMS
channel. (This may be because Mail-Net is so klunky. Someday someone will get
smart and replace it with listserv...) There was a brief flurry of activity a
few months ago that revealed a large number of readers.
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development." ---dmeggins@aix1.uottawa.ca
------------------------------
Date: Fri, 28 Jan 94 14:08:22 MET
From: Pierpaolo Pernici <iw5dhe@IW5DHE.AMPR.ORG>
Subject: Linux: another question...
To: tcp-group@ucsd.edu
Hello fm IW5DHE, Pierpaolo...
Could someone tell me the best-choice between the linux-distributions !?
I thought that Slackware was the best-choice but I've seen that in the
dist-files there isn't the latest version of GCC... ;^)
Is there a mailing-list for Amateurs_with_Linux !? (rgr Wampes, JNOS,
Ping-Pong conversd, etc... etc..)
Shold I install JNOS or Wampes !?
Excuse me for all my questions...
All the best,
Pierpaolo
--
---------- ----------
Pierpaolo Pernici (IW5DHE) == Radio-GW Team - Pisa ==
Surface Address: Internet: iw5dhe@amsat.org
Post Office Box nr.8 AmprNet: iw5dhe@gw.iw5dam.ampr.org
I-56030 S.Pietro Belvedere (PI) Italy AX25-NET: iw5dhe@iw5cmm.#pi.ita.eu
---------- ----------
------------------------------
Date: Fri, 28 Jan 94 12:14:46 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: RE - mtu,mss,window
To: tcp-group@ucsd.edu
Terry,
I am sending this to tcpgroup - your return addresses ans cc's to
were a mile long.
The NOS (JNOS) manual has a section towards the rear that describes in
detail the relationship of these parameters. In summary -
Paclen is used for ax25/netrom connects
MTU is used for TCP/IP connects and is the maximum data (and header)
size that will be sent on an interface.
MSS is a negotiated value between the server/client - it uses the lowest
of the two and cannot be larger than MTU. This however does not mean that
intermediate hops could have lower allowed thruput - this is what the
"dicovery" techniques that Phil and other have been talking about is
suppose to adjust for.
The window is the maximum outstanding data - I.E. data in the pipeline.
Typical values used here are based on our 2400 baud 2 meter circuit.
MTU - 512
MSS - 472
window - 944
paclen 256
Paclen is limited by the maximum that MOST netrom sites can handle.
For NOS to NOS connections this could be made larger - X1x sites
allow a larger paclen - but be careful here as you may run into trouble.
This is a good example of why mss/window and paclen per interface values
make sense. Strictly speaking though you should be able to set your MTU
per interface and set the MSS/window much larger and let it adjust. I.E.
set you mss to the header size less than the maximum MTU on your system.
If using ethernet - you might set
MTU - 1500 on the ethernet port
MTU - 512 on a 2400 baud local port
MTU - 256 on a 1200 baud local port
etc.
and set MSS= 1470, window = 2940
In practice this is suppose to work - I am not sure if there may not
be some problems in NOS.
Phil may want to comment on this as I believe he wrote the description
of it in the manual (way back) and he certainly knows the inter-workings
of it in NOS.
Doug
------------------------------
Date: Fri, 28 Jan 1994 11:38:30 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: TCP MSS and TCP WIN settings
To: goldstein@carafe.tay2.dec.com
>Raj describes that as a classical fallacy, albeit one with much
>political clout. You can't solve congestion with bandwidth, just
>move it. Now the backbone is fat but congestion occurs at the low-
>bandwidth egress points ("on-ramps"). ATM nets will really see this.
Agreed. Another effect of higher bandwidth is to remove the "usual"
indication of congestion - increased delay. Since most of the packet
switches haven't scaled their queue sizes proportionately to their
link speeds, there's relatively little variation in queueing delay
nowadays. Almost all of it is now speed-of-light delay, at least on
the NSFNet backbone. You see little change as load increases until
packets suddenly start dropping. This argues even more strongly for
the DECbit scheme or something like it, since there's less that a TCP
can use to infer that congestion is occurring.
>It's simpler than that. The congestion window is in the receiver,
>not the sender. All you need to do is lower the advertised window
>size, not echo back the bit. That's an advantage of TCP over, say,
Yes, of course. Why didn't I think of that?
>That spare bit just sort of begs to be used for this, doesn't it?
>I think somebody once suggested it at IETF but got nowhere, but then
>I only know that as hearsay and I don't even remember from whom.
It was probably me. I tried to talk this up at the IETF some years
ago, but didn't get a lot of interest for some reason. Maybe this is
something we could implement first in amateur radio, get a lot of
experience with it, and then go to the IETF. You tend to get taken
more seriously if you have more than just an idea, but an actual
demonstration that your ideas work and work well.
Phil
------------------------------
Date: Fri, 28 Jan 1994 06:54:25 -0800 (PST)
From: resmana - petra christian university <resmana@iclnet93.iclnet.org>
To: tcp-group@ucsd.edu
SUBSCRIBE mailing list Resmana
------------------------------
Date: 28 Jan 94 12:56:13 GMT
From: uucp@attmail.com
To: tcp-group@UCSD.EDU
>From UCSD.EDU!owner-tcp-digest Fri Jan 28 04:30:02 PST 1994 remote from internet
Received: by gw1.att.com; Fri Jan 28 07:55:31 EST 1994
Received: from localhost by ucsd.edu; id EAA17272
sendmail 8.6.4/UCSD-2.2-sun
Fri, 28 Jan 1994 04:30:06 -0800 for tcp-digest-list
Received: from localhost by ucsd.edu; id EAA17266
sendmail 8.6.4/UCSD-2.2-sun
Fri, 28 Jan 1994 04:30:04 -0800 for tcp-group-ddist
Message-Id: <199401281230.EAA17266@ucsd.edu>
Date: Fri, 28 Jan 94 04:30:02 PST
From: internet!UCSD.EDU!tcp-group (Advanced Amateur Radio Networking Group)
Errors-To: TCP-Group-Errors@UCSD.EDU
Reply-To: internet!UCSD.EDU!TCP-Group
Precedence: Bulk
Subject: TCP-Group Digest V94 #25
To: internet!UCSD.EDU!tcp-group-digest
TCP-Group Digest Fri, 28 Jan 94 Volume 94 : Issue 25
Today's Topics:
GPIB and packet
jnos gateway
MTU, TCP MSS, TCP WIN
New NET/Mac (hamradio TCP/IP) for the Macintosh
TPC MSS and TCP WIN per port
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: Thu, 27 Jan 94 16:33:29 CST
From: garnier@sol.med.ge.com (Dave Garnier x7-4286)
Subject: GPIB and packet
To: tcp-group@ucsd.edu
*>FYI -
*>
*>The Circuit Cellar BBS has a parallel to GPIB adapter info and SW
*>
*>GPIBLPT.ZIP
*I tried to look for it with archie but could not find any references.
*Could you put it somewhere where I could ftp this file from.
Could some kind soul post the fone number to this group?
Thanks much!
dave garnier
wb9own
ge medical systems, milwaukee
garnier@sol.med.ge.com
------------------------------
Date: Thu, 27 Jan 1994 08:22:14 -0500
From: Gary Skuse <grsk@troi.cc.rochester.edu>
Subject: jnos gateway
To: TCP-Group@UCSD.Edu
I am running jnos on a dos box which is connected to a landline by a serial
port and to our University's extended LAN via an ethernet connection. I
would like to set up a gateway between the two so that I can call in by
telephone and get out over the Internet. I can figure out how to telnet
but I can't ftp. Has anyone done this? I would appreciate any suggestions
anyone has to offer. Eventually I would like to do something similar at home
so that I can access my ethernet network at home via the telephone from
work.
tnx and 73, ka1njl
------------------------------
Date: Thu, 27 Jan 1994 10:31:25 -0800 (PST)
From: uswnvg!tconboy@uunet.UU.NET (Terry A. Conboy)
Subject: MTU, TCP MSS, TCP WIN
To: uunet!ucsd.edu!tcp-group@uunet.UU.NET
It seems that there is a minor confusion about these parameters. My
(probably meager) understanding is that your MTU determines the biggest
datagram that you send (allowing for 40 bytes of TCP/IP overhead) and
that MSS and WIN control what is sent TO you. In other words, if you
are sending mail or files to another host, your MSS and WIN have no
effect on what you send out to them.
I have a PC with a 1200 bps KISS TNC and a 2400 bps SLIP link. I set
the MTU on the TNC to 296 since the radio path is sometimes
marginal to some stations I communicate with. I set the MTU on the SLIP
to 1064 to allow big datagrams to be sent to my computer at work
over a 2400 bps dialup. I set TCP MSS to 1024 and TCP WIN to 2048 to
allow up to 2 datagrams to be outstanding without an ACK.
This works well in practice, since the congestion window (Cwind)
typically gets adjusted down to the MTU-40 of the station at the other
end of the radio link very quickly. So for me, having MSS or WIN per
port isn't very important. However, it does require that the station at
the other end of a radio link be intelligent in setting his MTU on the
radio port.
I've gleaned this from reading the docs, watching lots of traces, and
looking at the 'socket nnn' displays. If there's a flaw in my
reasoning, let me know.
73, Terry
--
Terry Conboy email: tconboy@uswnvg.com
U S WEST NewVector Group packet: n6ry@n7ipb.wa.usa
3350 - 161st Ave SE, MS 571 office: (206) 450-8388
Bellevue, WA 98008 fax: (206) 450-8399
------------------------------
Date: Thu, 27 Jan 1994 10:13:03 +0100
From: adam@igg.tno.nl (Adam van Gaalen PA2AGA)
Subject: New NET/Mac (hamradio TCP/IP) for the Macintosh
To: ham-digital@ucsd.edu, tcp-group@ucsd.edu
The Netherlands, January 25, 1994.
Hello dear reader,
Today I distributed the file NET_Mac2.3.35.sea.hqx...
In this version of NET/Mac I implemented the following:
- New <dayofweek> parameter for 'perform' command
- New: 'reboot_on_bad_date' } These new commands were implemen-
- New: 'sourcewhendone' } ted to make it easier to maintain
- New: 'resetsmtpto' } an unattended slip-telephone-link
- Improved the generation of dynamic aliases
- Some more 'enhancements' for q-and-d AppleTalk-fix
- Some more 'enhancements' for q-and-d fix
This version obsoletes all versions of info-mac/comm/radio-netmac in the
Sumex-Aim archives.
The new NET/Mac has been uploaded to ucsd.edu, to the directory
/hamradio/packet/tcpip/incoming. If it's not there (anymore),
then look at /hamradio/packet/tcpip/mac.
Kind regards,
Adam PA2AGA (e-mail: adam@igg.tno.nl )
( or: pa2aga@igg.tno.nl for letters only, NO BIG files here)
------------------------------
Date: Thu, 27 Jan 94 07:04:23 CST
From: Jack Snodgrass <kf5mg@kf5mg.ampr.org>
Subject: TPC MSS and TCP WIN per port
To: tcp-group mailling list <tcp-group@ucsd.edu>
Someone posted a message or sent me a note saying that they had fixed
JNOS to allow a MSS and WINDOW value to be asinged to each port. I forgot
who it was, but they said that they'd post the changes this week. I'm
anxios to see the code. I've tried setting the MTU on the port to less than
the TCP MSS and I'm not happy with the results. Stuff seems to go smoother
when I just reduce the MSS for the entire system rather than reducing the
MTU for a single port. I see packets being broken up into mtu size pieces
but NOS doesn't seem to re-assemble them and acknowledge them all the time.
I'm not familiar enough with the process to figure out what's wrong, but
I did see the same group of MTU sized packets be sent several times and
never ack'd by the receiving system. Anyway... I'd like to mod the code
to use a MSS and WINDOW based on the port. At least in my enviornment,
stuff does not change from port to port so that should not cause a problem.
Thanks.
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
Dialup - kf5mg@tcet.unt.edu - work (looking for)
------------------------------
End of TCP-Group Digest V94 #25
******************************
------------------------------
End of TCP-Group Digest V94 #26
******************************
******************************