The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for June 1989 (295 messages, 166463 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 00:06:55 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP socket ambiguity?

>   To read RFC 793 very literally, it would seem that port <100.100.100.100,42>
> ought to specify a different socket/enpoint than <101.101.101.101,42>. But
> they obviously both refer to "TCP port 42" on the gateway machine....

They are differnt.  TCP connections are identified by the host address and
port on both ends of the connection.  Saying TCP port 42 is meaningless, it
is only valid in the context of the local IP address and the remote address/port
pair.

For example

100.100.100.100,42	101.101.101.101,42
100.100.100.100,42	200.200.200.200,42
200.200.200.200,42	101.101.101.101,42

refer to three seperate TCP connections without ambiguity.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 07:16:50 GMT
From:      casey@bayes.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS bug (long). Was: What is Ethernet type code 8035 hex?


   Chris Jankowski (chris@yarra.oz.au) describes a problem where telnet
sessions ``lock up'' for seconds at a time.  He tracked it down to a very
weird phenomena involving PC-NFS using reverse ARPs for unknown reasons
if PC-NFS was on a class A network.  Fascinating.

  One other source for lock ups that some of you should be aware of when
using PC-NFS is it's lack of silly window avoidance.  Our people have
only seen this crop up as a problem with ftp transfers, but I don't see
any reason it couldn't happen with a telnet session.

  Apparently what happens is that the PC offers a silly window (window is
less than half open).  The remote system which has silly window avoidance
decides to wait for the PC's receive buffers to clear and the PC to offer
a larger window so the remote host doesn't flood the net with a bunch of
smaller packets.  But PC-NFS doesn't update its window, so the transfer
hangs until the remote host gives up waiting for the window update.  The
remote host sends a small packet, PC-NFS sends a window update SEGSIZ/2 <
WINSIZ <= SEGSIZ.  The remote host likes the new window size and
immediately sends more data and PC-NFS sends another silly window ...
Once this pattern sets in for a given transfer, it apparently goes on
forever.

  If anyone is interested I can point them at the person locally who has
been working on this problem.  I haven't kept up with the work, so for
all I know Sun may already have a fix for this.

Casey

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 08:31:00 GMT
From:      rrv@uxc.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers guide to Internet


The Hitchhikers Guide to the Internet can be found:

    uxc.cso.uiuc.edu:/pub/hgi.me	nroff input
    uxc.cso.uiuc.edu:/pub/hgi.txt	formatted ascii text

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 14:15:22 GMT
From:      abstine@sun.soe.clarkson.edu (Arthur Stine)
To:        comp.protocols.tcp-ip
Subject:   Attaching to the Internet

Excuse me if this isn't the right forum for this question, but...

I need to know where a company in the LA area would call/write, etc to go
about getting info to get an Internet connection. Is there an NSF regional
net that serves that area that this company could attach to or ?. Thanks for
any info.

art stine
sr network engineer
clarkson u

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 14:16:47 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE considered harmful?

The user (client) Telnet in the MIT UNIX V6 TCP/IP (one of those
pre-Bezerkely WAN TCP/IP's) would periodically print:

	Host not responding, type ^^q to quit

on the user's terminal when (and only when) it had outstanding data to
send, and could not get it acknowledged.  If you had reason to beleive
it was right, you aborted the connection.  Otherwise, it sat there
retransmitting at a slow rate until connectivity was regained.
Meanwhile, you would go and fix the broken router, and *would not lose
your current session* on the remote host.

Now, if the server Telnet gets into a pickle, it would probably just
abort and die.  That UNIX lacks any way to preserve a login session is
it's problem, MIT AI ITS (on PDP-10's) knew exactly how to preserve
your state when this happened.  Of course, most systems are not in the
habit of generating unsolicited output, so this didn't happen as
often.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu 1 Jun 89 19:20:02-EST
From:      "Rich DeJordy, x295" <RAD@MATH.AMS.COM>
To:        tcp-ip@sri-nic.arpa
Cc:        rad@MATH.AMS.COM
Subject:   HELP

I am having a problem with PONY EXPRESS and version 5.1-1 of VMS. 

The Foreign Protocol Interface keeps dying and killing LOCALSND with it.

I have sent separate mail to Peter Karp, but was hoping maybe someone out
here might have an answer before he gets a chance to get to it?

Anyone else doing this?  It doesn't seem to like /PROTOCOL= on th MAIL.

It gives me an "Illegal String class" error from the STR facility.  (I can
only assume that STR is from the STR$ run time library functions.)

If anyone can help, I'm in a real desperate situation, so please reply
to me directly at RAD@MATH.AMS.COM.  

Thanks for the help!
Rich DeJordy
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 16:58:28 GMT
From:      rk@lexicon.com (Bob Kukura)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Another NCSA telnet question (I rtfm already)

In article <1869@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes:

> Well, ncsa telnet is sure neato, but I am having one real big
> problem. I am unable to transfer certain files from the remote machine
> to my PC. I can send from the PC to the remote machine, and it seems
> that small files will go back, but usually, it says "150 Opening
> connection\n" and then sits there doing nothing. File transfer is
> enabled, and the standalone ftp did the same kind of
> thing. My machine is a 386 with the WD8003; the remote machine is
> a uVaxII with Ultrix 1.2.
> 
> (I just tested the same thing connected to a Unisys 7000 (CCI 6/32) with
> 4.3-tahoe, and it worked. Darn. Well, does this mean that Ultrix is the
> stinker?)
> 
> rob

 We had a problem with very similar symptoms using PC-NFS with Ultrix.
Very small telnet and ftp transfers worked fine, but larger ones
failed.

 Ultrix uses trailer encapsulation, which moves the variable-sized
packet header data to the end of the packet so that the received
packet data is page-aligned can be mapped into the user address space
without having to copy it.  PC-NFS could not handle trailer
encapsulated packets, which Ultrix apparently only generated when
doing transfers larger that about 1.5 K.

 The solution was to edit the -trailers option into the /etc/ifconfig
line in the rc.local file on each Ultrix system to disable trailer
encapsulation.  This is no longer necessary as of Ultrix V3.0, which
negotiates with each host on whether to use trailer encapsulation.
-- 
-Bob Kukura		smart: rk@lexicon.com
			dumb: {husc6,linus,harvard,bbn}!spdcc!lexicon!rk
			phone: (617) 891-6790

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 17:00:12 GMT
From:      woods@ncar.ucar.edu (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump (more info)

In article <1559@cunixc.cc.columbia.edu> micky@cunixc.cc.columbia.edu (Micky Liu) writes:
>
>tcpdump is available in source from ftp.ee.lbl.gov by anonymous ftp,
>but unless you have a Sun-3 with SunOS3.5 it is un-useable.  If you
>have SunOS4.0 you will need to do two things:
>
> 1) Install a kernel fix on Sun-3's (I think Sun-4's are okay).  
>    The if_nit.o file is also at ftp.ee.lbl.gov.
>
> 2) Modify the source to work with Sun's new STREAMS based NIT 
>    interface.

  I got Micky's patches from him, applied them to the source from lbl, grabbed
the nit_if.o module from lbl, rebuilt my kernel, remade tcpdump, and I now
have a version of tcpdump that works on my 3/50 running 4.0.1 (thanks, guys!)
I tried it out on a Sun-4, and it compiles and links fine but produces no
output. I assume that I need a fixed nit_if.o for a Sun-4. Anybody got one?
  The only nuisance is that the makefile for the tcpdump source references
a program called "flex" which is not a part of the Sun OS, so I had to grab
those sources from lbl as well and make that program before I could get
tcpdump to compile. A nuisance, but doable. Flex compiles without any trouble
on both the Sun-3 and Sun-4 (running OS 4.0.1)
  If anybody wants to avoid this procedure, I have the Sun-3 binary available
for anonymous FTP from ncar.ucar.edu (128.117.64.4), as pub/tcpdump.sun3.os4
You will need to remake your kernel with the nit_if.o from lbl before you
will be able to use this binary.

--Greg

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 18:06:26 GMT
From:      leres@ace.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump (more info)

Micky Liu writes:
> 2) The clock resolution on Sun-3's is pretty lame... 1/50 of a
>    second.  If you have dollars for a nice protocol analyzer,
>    go for it!

The Intersil ICM7170 chip Sun used is actually running at 100Hz. I've
modified our SunOS 3.5 kernels to use it directly thus giving 10ms
resolution. (As it turns out, the code that actually decodes the chip
was so inefficient that rewriting it more than made up for the overhead
of reading it twice as often.) If there's sufficient interest, I'll
prepare some diffs.

		Craig

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 18:14:01 GMT
From:      shoat@cs.glasgow.ac.uk (Mr. David Shoat)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Another NCSA telnet question (I rtfm already)


I've been trying out a couple of telnet implementations recently and have had
problems with both. The first is NCSA telnet on a Mac SE with a Kinetics
etherport. The second is the version of telnet supplied with PC-NFS V3.0.
The hosts are microvaxen running Ultrix (V2.0 and V2.3). Everything is on
ethernet with class-a addressing. In both cases, telnet will eventually
hang. This usually happens when running something which uses screen-addressing
in vt100 mode. I haven't had the patience to see if it recovers - it takes
a lot longer than 11 seconds. It looks like Ultrix may be at fault here,
although telnet works fine between the vaxes.

Anyone else had this type of problem?

David Shoat
Department of Medical Cardiology
Glasgow Royal Infirmary.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 19:22:38 GMT
From:      wdh@holos0.UUCP (Weaver D. Hickerson)
To:        comp.sys.ibm.pc.rt,comp.protocols.tcp-ip
Subject:   Need info on printer routing for the RT



	Being somewhat new to the RT and TCP-IP world, I may be asking a very
	obvious and boring question, but if anyone has any answers or
	suggestions, they would be appreciated:

	Say someone has an RT which has connected to it a Micom Interlan
	NTS-100 terminal server (which has an IP address, built in Ethernet,
	and 8 serial ports).  This someone would like to be able to route
	specific lpr requests to one or more printers attached to ports on the
	NTS-100, routing through TCP-IP.  Essentially, what would be involved
	would be intercepting requests to, say "lp07", and making sure that
	anything sent to that printer actually prints out on port 03 of the
	terminal server.

	I apologize for my ignorance, but they want it yesterday and nothing in
	the documentation seems to point in this direction.  Can this be done 
	through simple lpr administration, or would some additional programming 
	be necessary to re-route the files??

	Once again, any info would be appreciated.  Please e-mail responses to
	me and I will post a summary if that seems appropriate.  


	-

	Weaver Hickerson   *  ...!gatech!holos0!wdh  *       (404) 496-1358
    HOLOS Software, Inc., 3469 Lawrenceville Highway, Tucker  GA  30084
-- 
-Weaver Hickerson          
 Holos Software

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 20:26:04 GMT
From:      GEustace@massey.ac.nz (Glen Eustace)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS bug (long). Was: What is Ethernet type code 8035 hex?

The PC-NFS Bug described is identical to a situation we have been
experiencing. Our situation is a little different, we are a Class B
Address (130.123.?.?). The random delays as described happen quite
frequently in our telnet sessions as well. Note,other than the network
class our situations are identical.

The delays vary from 2 or 3 seconds, to longer than 30 secs in some cases.
During the very long delays, I have noticed an 'Excessive Collisions'
msg on the console of the Telnet host, a Pyramid 9815. Yet I have had
'traffic' running on a Sun 386i and it has not shown any significant
network load at all.

I have not put a network analyser to work on the problem, but are
pleased some one has some solid evidence of something wierd happening.

Our users are finding this particular bug very frustrating as my only
solution to date is too tell them, there's nothing I can do.

-----------------------------------------------------------------------
Glen Eustace, Software Mgr, Comp.Cntr, Massey Uni, Palmerston Nth, N.Z.
Janet/Greybook: G.Eustace@nz.ac.massey        Phone: +64 63 69099 x7440
CSnet/ACSnet/Internet: G.Eustace@massey.ac.nz      New Zealand = GMT+12
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 20:30:58 GMT
From:      AFDDN.BEACH@GUNTER-ADAM.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   EGP and C-30s

Anybody got a quick answer to this and I'll owe you a beer.

We're installing cisco MGS gateways at different sites on Milnet and 
occasionally a problem crops up with exchanging EGP updates with the
"new" core buttergates.  Essentially there seems to be an infinite 
cycling up and down between the gateways with the core never sending an 
update.

A brief example of the exchanges follows.  Our gateway is sending updates
and the real interesting part of it is that if the PSN our gateway is
on gets reset, the problem clears up immediately.

I would very much appreciate any hints, suggestions, or detailed technical
explanations.

Darrel B.

Ex***********
 
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3965
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.6.0.103 going from DOWN to UP
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2258
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=192
     Type=UPDATE, Code=0, Status=129 (UP), IntGW=1, ExtGW=0, Net=26.0.0.0
     Network 26.0.0.0 via 26.19.0.222 in 0 hops
     Network 132.61.0.0 via 26.19.0.222 in 0 hops
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2259
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.20.0.16 going from UP to DOWN
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3965
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=398
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.20.0.16 state is DOWN, bad type 2 when down
EGP: 26.6.0.103 going from UP to DOWN
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2259
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=199
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.6.0.103 state is DOWN, bad type 2 when down
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3965
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=3965
     Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=399
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.20.0.16 state is DOWN, bad type 2 when down
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2259
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=2259
     Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=200
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.6.0.103 state is DOWN, bad type 2 when down
EGP: 26.20.0.16 going from DOWN to UP
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3965
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=309
     Type=UPDATE, Code=0, Status=129 (UP), IntGW=1, ExtGW=0, Net=26.0.0.0
     Network 26.0.0.0 via 26.19.0.222 in 0 hops
     Network 132.61.0.0 via 26.19.0.222 in 0 hops
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3966
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.6.0.103 going from DOWN to UP
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2259
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=192
     Type=UPDATE, Code=0, Status=129 (UP), IntGW=1, ExtGW=0, Net=26.0.0.0
     Network 26.0.0.0 via 26.19.0.222 in 0 hops
     Network 132.61.0.0 via 26.19.0.222 in 0 hops
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2260
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.20.0.16 going from UP to DOWN
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3966
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=400
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.20.0.16 state is DOWN, bad type 2 when down
EGP: 26.6.0.103 going from UP to DOWN
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2260
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=201
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.6.0.103 state is DOWN, bad type 2 when down
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3966
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=3966
     Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=401
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.20.0.16 state is DOWN, bad type 2 when down
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2260
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=2260
     Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 26.6.0.103 to 26.19.0.222, version=2, asystem=164, sequence=202
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: 26.6.0.103 state is DOWN, bad type 2 when down
EGP: 26.20.0.16 going from DOWN to UP
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3966
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=309
     Type=UPDATE, Code=0, Status=129 (UP), IntGW=1, ExtGW=0, Net=26.0.0.0
     Network 26.0.0.0 via 26.19.0.222 in 0 hops
     Network 132.61.0.0 via 26.19.0.222 in 0 hops
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3967
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.6.0.103 going from DOWN to UP
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2260
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=192
     Type=UPDATE, Code=0, Status=129 (UP), IntGW=1, ExtGW=0, Net=26.0.0.0
     Network 26.0.0.0 via 26.19.0.222 in 0 hops
     Network 132.61.0.0 via 26.19.0.222 in 0 hops
EGP: from 26.19.0.222 to 26.6.0.103, version=2, asystem=44429, sequence=2261
     Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 26.20.0.16 going from UP to DOWN
EGP: from 26.19.0.222 to 26.20.0.16, version=2, asystem=44429, sequence=3967
     Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 26.20.0.16 to 26.19.0.222, version=2, asystem=164, sequence=402
     Type=POLL, Code=0, Status=1 (UP), Net=26.0.0.0
*****************************

This gones on until the PSN (C-30) is reset, at which point updates from
the core begin coming in.
We've tried using a range of AS numbers, including much lower ones, but
nothing except resetting the PSN seems tp work.
-------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 20:51:23 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SO_KEEPALIVE considered harmful?

Seems to me that much of this discussion is missing the point that an
open TCP connection (especially a telnet session) can tie up expensive
resources on the server; most of the recent discussion has focussed on
the problems of a user who may or may not want to abort a connection on
network or remote host failure.  For example, many timesharing systems
charge based on "connect time", and some even enforce a maximum number
of outstanding sessions.  In such cases it is in the interest of the
user and the system to abort a telnet session if there is reason to
believe that loss of connectivity is not just briefly transient.  One
can obviously do this with a (perhaps user settable) timeout, but are
there other heuristics that might usefully be used as well?

Does anyone have any data on the distribution of time-length of network
partitions?  How, for that matter, might we define a network
partition?  Many events (e.g. the TR card in our NSS going bad) yield
obvious network partitions with well defined lengths.  Others, e.g. a
degraded quality line, may imply very short (a few ms or s) partitions,
which increase the errors and retransmissions and ultimately imply an
unusable TCP connection.  Can we come up with an analytic model that
includes both sorts of failures?

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 89 22:47:28 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Help a writer?


Hi.  I'm doing two stories for a Unix World networking supplement that is
due out later this year (obviously...).  One is on SLIP and the other is
on NSFnet (National Science Foundation).  I'd like to hear from any people
who are using SLIP, and from any users who are either on the NSFnet, or
who have decided not to be on NSFnet.  Please respond either via e-mail
or by posting.  Thanks!
-- 
"Why should I let a loathsome little toad like you touch my breast
when you haven't even read my books!"

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 00:18:52 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Internet Access in Los Angeles


Regional Networks in the Los Angeles area include Los Nettos and CERFnet.

For information about Los Nettos contact:

		Los-Nettos-Request@ISI.EDU
		Ann Westine
		213-822-1511

For information about CERFnet contact:

		armstrongk@SDS.SDSC.EDU
		Karen Armstrong
		619-534-5067

--jon.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 00:20:02 GMT
From:      RAD@MATH.AMS.COM ("Rich DeJordy, x295")
To:        comp.protocols.tcp-ip
Subject:   HELP


I am having a problem with PONY EXPRESS and version 5.1-1 of VMS. 

The Foreign Protocol Interface keeps dying and killing LOCALSND with it.

I have sent separate mail to Peter Karp, but was hoping maybe someone out
here might have an answer before he gets a chance to get to it?

Anyone else doing this?  It doesn't seem to like /PROTOCOL= on th MAIL.

It gives me an "Illegal String class" error from the STR facility.  (I can
only assume that STR is from the STR$ run time library functions.)

If anyone can help, I'm in a real desperate situation, so please reply
to me directly at RAD@MATH.AMS.COM.  

Thanks for the help!
Rich DeJordy
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 02:26:02 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   A Real Telnet Server for MS-DOS

I have a real telnet server for IBM-PCs and clones running MS-DOS.  It is a
version of Phil Karn's TCP/IP networking software (NOS).  The program (tns)
lets you telnet to a PC, asks you for an "account" and password, and
then connects you to the machine.  The telnet server reads the local screen
periodically, and uses ANSI X3.64-1979 escape sequences to update the remote
screen.

It needs work.  I need to duplicate the functionality of programs such
as Carbon Copy, Remote Control, etc.  If this program would be useful
to you, please tell me what would be most useful:
  o Currently it takes 126K.  I can reduce this by a considerable amount,
    but you're never going to be able to run TeX or Ventura Publisher.
    If you have an application in mind that cannot afford to lose 126K,
    then please tell me how much it can afford.  Give me a target to
    shoot for.
  o Currently, I only support ANSI escape sequences.  Is there any demand
    for other displays (recall the existance of Oliver Laumann's "screen",
    that emulates an ANSI terminal using termcap)?
  o Currently, only ASCII keycodes can be sent.  How do I send IBM-PC keycodes?
    Should I pick on an infrequently-used control character and use it as a
    quote, or is there some standard that hides keystroke differences?
  o Currently, only text modes are supported.  How do I support
    graphics modes?  What do I do if the user is not using an IBM-PC?
    What if they have incompatible graphics hardware, i.e. the server
    has an EGA and the client machine an CGA?  What if the program on
    the server writes directly to the graphics hardware (as is
    necessary for the Hercules graphics card)?

Availability:

    Because this Telnet server is a derivative of Phil Karn's code, it is
covered by his copyright.  His code is freely copyable by ham radio amateurs,
and by educational institutions.  All others should contact him for permission.
He's in sri-nic.arpa's whois database.
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
I'm a right-to-lifer -- everyone has a right to earn a living sufficient to
feed himself and his family.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 04:00:12 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering


On a parallel note, what is the effect of address and <other> filtering
on throughput? My personal measure based on light loadings of some
2Mbit ethernet bridges is that ANY address filtering makes throughput 
appreciably slow. -Of course large packet protocols are less affected 
but per-character packet activity is a bummer. I was surprised how visible 
this could be given 10Mbit one side, 2Mbit the other.

	-George

-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 05:04:32 GMT
From:      casey@lll-crg.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Small TTL values evaporate in large networks


  Just as a note, it turns out the Stellar's Stellix version 1.6 also has
this problem.  It sets the TTL field to 10 for ICMP and TCP packets.  I'll
attempt to get a patched kernel and will report on a fix when it's
available.

Casey

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 06:38:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   FTP specmanship?

Is there any interpretation of either RFC 959 or its roughly
corresponding MIL STD which calls for TYPE L 8 to be considered a
required command to be implemented in a user ftp?  How about QUOTE and
DIR?

Likewise, is there anything that says that the user ftp program
should/must be implemented as a user-interactive program?

Sound like *dumb* questions?  You bet.  Incredible as it may seem,
there actually is a vendor's user ftp product without TYPE L 8, QUOTE,
and DIR - just "SEND" and "RECEIVE" and either ASCII or BINARY - all
menu-driven, fill-in-the-blank, and sent off as a batch job!  What I
don't understand is that this vendor apparently would rather implement
a utility to convert our 8-bit binary files, grabbed with TYPE L 32,
than implement TYPE L 8...  So, I'm looking for ammunition...

Although it's too late in this case to point to the Host Requirements
document, I sure hope some clarification statements are included to
preclude such elementary loopholes as these.

--Frank

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Jun 89 16:25:44 -0400
From:      Mike Brescia <brescia@BBN.COM>
To:        AFDDN.BEACH@gunter-adam.af.mil
Cc:        tcp-ip@sri-nic.arpa, brescia@BBN.COM
Subject:   Re: EGP and C-30s
     We're installing cisco MGS gateways at different sites on Milnet and 
     occasionally a problem crops up with exchanging EGP updates with the
     "new" core buttergates.  Essentially there seems to be an infinite 
     cycling up and down between the gateways with the core never sending an 
     update.

     A brief example of the exchanges follows.  Our gateway is sending updates
     and the real interesting part of it is that if the PSN our gateway is
     on gets reset, the problem clears up immediately.

     *******

     This gones on until the PSN (C-30) is reset, at which point updates from
     the core begin coming in.
     ... nothing except resetting the PSN seems tp work.
     -------

Darrel,

This sounds like an X.25 type of problem, involving x.25 window size, x.25
packet size, and resources in the local PSN.  I recall a similar problem where
a system could not get an egp update through when using a packet size of 128
and a window of 2.  Try to get the packet size to 512 or 1024, and the window
size 7 (or at least 4 for 1024 byte packets).  Note that the EGP update is
sent as 3 1004 byte IP fragments (oh, well, the 3rd is shorter, but it's
growing).  The total IP datagram size is around 2800 to 2900 bytes.

Also, make sure you have assurance from Cisco that you have latest revision of
code.

Please send further notes to "gw-fire@bbn.com" if appears to be a core
gateway problem instead of a host-psn interconnect problem.

Regards,
Mike Brescia
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 11:50:28 GMT
From:      martinea@CRC.SKL.DND.CA (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Boards



I am putting together a local area network which consists of PC
compatible computers, both desktop and and laptop computers.  I am
seriously considering LANtastic for a number of reasons including
low cost and low memory usage.   The LAN itself with be Ethernet using
ThinNet coax.    To provide the most flexibility in choosing an Ethernet
board I am looking for boards which support NetBIOS.  For the desktop
computers I have decided on Western Digital WD8003E boards.  I have
run into a problem, however, in choosing a board for the laptop
computers (which at this time are all Toshiba T1200s).  Knowing that
all NetBIOS implementations do not necessarily interoperate I am 
looking for an Ethernet board for the laptop computers that will
interoperate with the Western Digital board at the NetBIOS.  I am
also willing to consider other boards for the desktop units if need be.


Michael P. Martineau
Software Kinetics Ltd.
martinea@crc.skl.dnd.ca (192.5.204.1, 192.12.215.3)
(902)-468-3680

P.S.  Although this question does not directly pertain to  it
is relevant with respect to those boards with support the NetBIOS over
TCP/IP standard.  Thanks for your indulgence.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 14:42:19 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?


*Phil,
*
*As a test-of-concept:  I assume that you have no objection to a TCP
*implementation's being able to do keepalives, under the control of the
*application, where both the fact of keepalives AND their periodicity
*can be specified; and the effect of a timeout is a signal to the
*application, not an abort?
*
*Dave


if an application wants a keep alive mechanism, it should do it
itself, sending  a byte of garbage data, and abusing the sequence
numbers is not the way to go about this . . . . 

and hopefully, the people doing the keepalive mechanism will alow
either end to disable it. if i startup an ftp to run all night
sucking over the latest X distribution, i dont want it being aborted
because a gateway goes down for an hour for PM.



stev knowles
ftp software
stev@ftp.com

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 16:39:34 GMT
From:      george@rex.cs.tulane.edu (Roy George)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   background ftp

Hi there,
I was looking for the source file of bftp- background ftp- which I
believe allows the user to do 'other things' while files are being
ftp'ed over.  Could someone email me the file or tell me where it is
available.
Thanks in advance
Roy George
-- 
*****************************************************************************
* Roy George              | INTERNET & BITNET : george@rex.cs.tulane.edu    *
* Tulane University, LA   | USENET            :{{ames, bionet}!}rex!george  *
*****************************************************************************

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 17:15:21 GMT
From:      rlk@tusun2.knet.utulsa.edu ( Richard L. Kruse II)
To:        comp.protocols.tcp-ip
Subject:   Best TCP/IP package for a VAX 63xx

The university has just finished cutting a deal to purchase a VAX 6320,
and I would like opinions on the *best* TCP/IP implementation to run
on this beast, and why. The current plan is to use Wollongong, but
I'd like to hear from others so I can help us make the best decision
on this.

Please reply by email (time is short). I'll summarize, if anyone is
interrested...

advTHANKSance
Rick Kruse
University of Tulsa

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 17:17:23 GMT
From:      jim@dfmp1.UUCP (Jim Murray)
To:        comp.protocols.tcp-ip,comp.sys.att,comp.unix.questions
Subject:   Help finding slipnet

I work for the Department of Family Medicine at the University of
Wisconsin-Madison.  We are currently connected to the campus network
(and then the world) bu means of a uucp connection from the Math
department.  THis works fine but as we are bringing more and more
doctors onto the system our traffic has increased tremendously.
Due to access problems, it is impossible to run the proper cable to
hook us directly to the campus.

I have been told that if we could find a copy of SLIPNET to run on
our computers that with a dedicated phone line we could  bypass the
uucp connection and hook directly into the campus network.

Being new at this, I have several questions :
	WHere does one obtain SLIPNET?
	DOes it run on AT&T 3b2's running UNIX SYS V
	In general, is this feasible and how do I go about it.

I can receive email both uucp and NSFNET.  My address is

uucp
	uunet!uwvax!schaefer!dfmp1!jim
NSFNET
	dfmp1!jim@schaefer.math.wisc.edu

Any help or info will be greatly appreciated
Jim Murray

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 17:18:41 GMT
From:      FMC@SRI-NIC.ARPA (Fred Curiel)
To:        comp.protocols.tcp-ip
Subject:   ACM Network Roundtable # 4

******************************************************************************
		       WASHINGTON DC SIGCOMM

		Association for Computing Machinery
		     Washington D.C.   Chapter
	             Special Interest Group on
	                Data Communications

			    PRESENTS:
		
		       Network Roundtable # 4
		    Topic : "FIBER OPTIC LANs"

DATE:		  Wednesday, June 28, 1989

TIME:		  1.00 PM to 5:00 PM

PLACE:		  Naval Research Laboratory
		  Building 222 Auditorium
		  Washington D.C. 20375-5000

LUNCH:		  In the same building as the meeting, cafeteria 
		  services will be available starting at 11:30AM.
	
RESERVATIONS:	  RSVP with Bill Yurcik, "yurcik@lcp.nrl.navy.mil" or 
	          (202) 767-3903.  All attendees *MUST* RSVP by COB 
		  June 23rd because names must be left at the guard posts for 
		  entry onto the base.  For security reasons, non-US citizens 
		  and foreign nationals might not be able to attend if special 
		  arrangements are not made in advance.


			         AGENDA

INTRODUCTION  : Greeting/Groundrules


ROUNDTABLE    : A panel of nationally known technical representatatives will
DISCUSSION      present their viewpoint on present technology issues and 
		future projections.  After a short presentation from each 
		representative, prepared questions and open questions from 
		the audience will be entertained.

Panel will consist of the following companies:

Moderator : William Burr, National Institute for Science and Technology
	                  (Formerly NBS)

1:15-2:30
SYSTEMS PANEL : CANSTAR, CODENOLL, FIBERCOM, FIBRONICS, PROTEON, SEICOR


 - - - - - - - - - - - - - - - - Break - - - - - - - - - - - - - - - - - - 


2:45-4:00	
INTEGRATORS PANEL   : ALLIED, AT&T, CODENOLL, FOTEC, MARTIN MARIETTA

Notable Speakers include :   Dr. Albert Bender of FIBERCOM, 
			     Mike Coden of CODENOLL, 
			     Jay Cunningham of SEICOR,
			     Jim Hayes of FOTEC,
			     Hal Spurney of FIBRONICS,

Post-Meeting Discussions continued at a local establishment if desired...
*******************************************************************************

-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 18:23:00 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Here is the HitchHiker!

A lot of folks have been asking for this so:

HERE IT IS!

(What was Zaphod's last name anyway?)


=========================================================================











                     The Hitchhikers Guide to the Internet


                                 25 August 1987



                                    Ed Krol
                             krol@uxc.cso.uiuc.edu


























          This document was produced through funding of the National
          Science Foundation.





          Copyright (C) 1987, by the Board of Trustees of The Univer-
          sity of Illinois.  Permission to duplicate this document, in
          whole or part, is granted provided reference is made to the
          source and this copyright is included in whole copies.


















          This document assumes that one is familiar with the workings
          of a non-connected simple IP network (e.g. a few 4.2 BSD
          systems on an Ethernet not connected to anywhere else).
          Appendix A contains remedial information to get one to this
          point.  Its purpose is to get that person, familiar with a
          simple net, versed in the "oral tradition" of the Internet
          to the point that that net can be connected to the Internet
          with little danger to either.  It is not a tutorial, it con-
          sists of pointers to other places, literature, and hints
          which are not normally documented.  Since the Internet is a
          dynamic environment, changes to this document will be made
          regularly.  The author welcomes comments and suggestions.
          This is especially true of terms for the glossary (defini-
          tions are not necessary).




          In the beginning there was the ARPAnet, a wide area experi-
          mental network connecting hosts and terminal servers
          together.  Procedures were set up to regulate the allocation
          of addresses and to create voluntary standards for the net-
          work.  As local area networks became more pervasive, many
          hosts became gateways to local networks.  A network layer to
          allow the interoperation of these networks was developed and
          called IP (Internet Protocol).  Over time other groups
          created long haul IP based networks (NASA, NSF, states...).
          These nets, too, inter-operate because of IP.  The collec-
          tion of all of these interoperating networks is the Inter-
          net.

          Two groups do much of the research and information work of
          the Internet (ISI and SRI).  ISI (the Informational Sciences
          Institute) does much of the research, standardization, and
          allocation work of the Internet.  SRI International provides
          information services for the Internet.  In fact, after you
          are connected to the Internet most of the information in
          this document can be retrieved from the Network Information
          Center (NIC) run by SRI.



          _ O_ p_ e_ r_ a_ t_ i_ n_ g _ t_ h_ e _ I_ n_ t_ e_ r_ n_ e_ t

          Each network, be it the ARPAnet, NSFnet or a regional net-
          work, has its own operations center.  The ARPAnet is run by
          BBN, Inc. under contract from DARPA.  Their facility is
          called the Network Operations Center or NOC.  Cornell
          University temporarily operates NSFnet (called the Network
          Information Service Center, NISC).  It goes on to the


                                      -2-










          regionals having similar facilities to monitor and keep
          watch over the goings on of their portion of the Internet.
          In addition, they all should have some knowledge of what is
          happening to the Internet in total. If a problem comes up,
          it is suggested that a campus network liaison should contact
          the network operator to which he is directly connected. That
          is, if you are connected to a regional network (which is
          gatewayed to the NSFnet, which is connected to the
          ARPAnet...)  and have a problem, you should contact your
          regional network operations center.



          _ R_ F_ C_ s

          The internal workings of the Internet are defined by a set
          of documents called RFCs (Request for Comments).  The gen-
          eral process for creating an RFC is for someone wanting
          something formalized to write a document describing the
          issue and mailing it to Jon Postel (postel@isi.edu).  He
          acts as a referee for the proposal.  It is then commented
          upon by all those wishing to take part in the discussion
          (electronically of course).  It may go through multiple
          revisions.  Should it be generally accepted as a good idea,
          it will be assigned a number and filed with the RFCs.

          The RFCs can be divided into five groups: required, sug-
          gested, directional, informational and obsolete.  Required
          RFC's (e.g. RFC-791, The Internet Protocol) must be imple-
          mented on any host connected to the Internet.  Suggested
          RFCs are generally implemented by network hosts.  Lack of
          them does not preclude access to the Internet, but may
          impact its usability.  RFC-793 (Transmission Control Proto-
          col) is a suggested RFC.  Directional RFCs were discussed
          and agreed to, but their application has never come into
          wide use.  This may be due to the lack of wide need for the
          specific application (RFC-937 The Post Office Protocol) or
          that, although technically superior, ran against other per-
          vasive approaches (RFC-891 Hello).  It is suggested that
          should the facility be required by a particular site, an
          implementation be done in accordance with the RFC.  This
          insures that, should the idea be one whose time has come,
          the implementation will be in accordance with some standard
          and will be generally usable.  Informational RFCs contain
          factual information about the Internet and its operation
          (RFC-990, Assigned Numbers).  Finally, as the Internet and
          technology have grown, some RFCs have become unnecessary.
          These obsolete RFCs cannot be ignored, however.  Frequently
          when a change is made to some RFC that causes a new one to
          be issued obsoleting others, the new RFC only contains
          explanations and motivations for the change.  Understanding
          the model on which the whole facility is based may involve
          reading the original and subsequent RFCs on the topic.


                                      -3-










          (Appendix B contains a list of what are considered to be the
          major RFCs necessary for understanding the Internet).



          _ T_ h_ e _ N_ e_ t_ w_ o_ r_ k _ I_ n_ f_ o_ r_ m_ a_ t_ i_ o_ n _ C_ e_ n_ t_ e_ r

          The NIC is a facility available to all Internet users which
          provides information to the community.  There are three
          means of NIC contact: network, telephone, and mail.  The
          network accesses are the most prevalent.  Interactive access
          is frequently used to do queries of NIC service overviews,
          look up user and host names, and scan lists of NIC docu-
          ments.  It is available by using

               %telnet sri-nic.arpa

          on a BSD system and following the directions provided by a
          user friendly prompter.  From poking around in the databases
          provided one might decide that a document named
          NETINFO:NUG.DOC (The Users Guide to the ARPAnet) would be
          worth having.  It could be retrieved via an anonymous FTP.
          An anonymous FTP would proceed something like the following.
          (The dialogue may vary slightly depending on the implementa-
          tion of FTP you are using).

               %ftp sri-nic.arpa
               Connected to sri-nic.arpa.
               220 SRI_NIC.ARPA FTP Server Process 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT
               Name (sri-nic.arpa:myname): anonymous
               331 ANONYMOUS user ok, send real ident as password.
               Password: myname
               230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
               ftp> get netinfo:nug.doc
               200 Port 18.144 at host 128.174.5.50 accepted.
               150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
               226 Transfer Completed 157675 (8) bytes transferred
               local: netinfo:nug.doc  remote:netinfo:nug.doc
               157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
               ftp> quit
               221 QUIT command received. Goodbye.

          (Another good initial document to fetch is NETINFO:WHAT-
          THE-NIC-DOES.TXT)!

          Questions of the NIC or problems with services can be asked
          of or reported to using electronic mail.  The following
          addresses can be used:

               NIC@SRI-NIC.ARPA         General user assistance, document requests
               REGISTRAR@SRI-NIC.ARPA   User registration and WHOIS updates
               HOSTMASTER@SRI-NIC.ARPA  Hostname and domain changes and updates
               ACTION@SRI-NIC.ARPA      SRI-NIC computer operations


                                      -4-










                                SUGGESTIONS@SRI-NIC.ARPAComments on NIC publications and services


          For people without network access, or if the number of docu-
          ments is large, many of the NIC documents are available in
          printed form for a small charge.  One frequently ordered
          document for starting sites is a compendium of major RFCs.
          Telephone access is used primarily for questions or problems
          with network access.  (See appendix B for mail/telephone
          contact numbers).



          _ T_ h_ e _ N_ S_ F_ n_ e_ t _ N_ e_ t_ w_ o_ r_ k _ S_ e_ r_ v_ i_ c_ e _ C_ e_ n_ t_ e_ r

          The NSFnet Network Service Center (NNSC) is funded by NSF to
          provide a first level of aid to users of NSFnet should they
          have questions or encounter problems traversing the network.
          It is run by BBN Inc.  Karen Roubicek
          (roubicek@nnsc.nsf.net) is the NNSC user liaison.

          The NNSC, which currently has information and documents
          online and in printed form, plans to distribute news through
          network mailing lists, bulletins, newsletters, and online
          reports.  The NNSC also maintains a database of contact
          points and sources of additional information about NSFnet
          component networks and supercomputer centers.

          Prospective or current users who do not know whom to call
          concerning questions about NSFnet use, should contact the
          NNSC.  The NNSC will answer general questions, and, for
          detailed information relating to specific components of the
          Internet, will help users find the appropriate contact for
          further assistance.  (Appendix B)



          _ M_ a_ i_ l _ R_ e_ f_ l_ e_ c_ t_ o_ r_ s

          The way most people keep up to date on network news is
          through subscription to a number of mail reflectors.  Mail
          reflectors are special electronic mailboxes which, when they
          receive a message, resend it to a list of other mailboxes.
          This in effect creates a discussion group on a particular
          topic.  Each subscriber sees all the mail forwarded by the
          reflector, and if one wants to put his "two cents" in sends
          a message with the comments to the reflector....

          The general format to subscribe to a mail list is to find
          the address reflector and append the string -REQUEST to the
          mailbox name (not the host name).  For example, if you
          wanted to take part in the mailing list for NSFnet reflected
          by NSFNET@NNSC.NSF.NET, one sends a request to


                                      -5-










          NSFNET-REQUEST@NNSC.NSF.NET.  This may be a wonderful
          scheme, but the problem is that you must know the list
          exists in the first place.  It is suggested that, if you are
          interested, you read the mail from one list (like NSFNET)
          and you will probably become familiar with the existence of
          others.  A registration service for mail reflectors is pro-
          vided by the NIC in the files NETINFO:INTEREST-GROUPS-1.TXT,
          NETINFO:INTEREST-GROUPS-2.TXT, and NETINFO:INTEREST-GROUPS-
          3.TXT.

          The NSFNET mail reflector is targeted at those people who
          have a day to day interest in the news of the NSFnet (the
          backbone, regional network, and Internet inter-connection
          site workers).  The messages are reflected by a central
          location and are sent as separate messages to each sub-
          scriber.  This creates hundreds of messages on the wide area
          networks where bandwidth is the scarcest.

          There are two ways in which a campus could spread the news
          and not cause these messages to inundate the wide area net-
          works.  One is to re-reflect the message on the campus.
          That is, set up a reflector on a local machine which for-
          wards the message to a campus distribution list.  The other
          is to create an alias on a campus machine which places the
          messages into a notesfile on the topic.  Campus users who
          want the information could access the notesfile and see the
          messages that have been sent since their last access.  One
          might also elect to have the campus wide area network
          liaison screen the messages in either case and only forward
          those which are considered of merit.  Either of these
          schemes allows one message to be sent to the campus, while
          allowing wide distribution within.



          _ A_ d_ d_ r_ e_ s_ s _ A_ l_ l_ o_ c_ a_ t_ i_ o_ n

          Before a local network can be connected to the Internet it
          must be allocated a unique IP address.  These addresses are
          allocated by ISI.  The allocation process consists of get-
          ting an application form received from ISI.  (Send a message
          to hostmaster@sri-nic.arpa and ask for the template for a
          connected address).  This template is filled out and mailed
          back to hostmaster.  An address is allocated and e-mailed
          back to you.  This can also be done by postal mail (Appendix
          B).

          IP addresses are 32 bits long.  It is usually written as
          four decimal numbers separated by periods (e.g.,
          192.17.5.100).  Each number is the value of an octet of the
          32 bits.  It was seen from the beginning that some networks
          might choose to organize themselves as very flat (one net
          with a lot of nodes) and some might organize hierarchically


                                      -6-










          (many interconnected nets with fewer nodes each and a back-
          bone).  To provide for these cases, addresses were differen-
          tiated into class A, B, and C networks.  This classification
          had to with the interpretation of the octets.  Class A net-
          works have the first octet as a network address and the
          remaining three as a host address on that network.  Class C
          addresses have three octets of network address and one of
          host.  Class B is split two and two.  Therefore, there is an
          address space for a few large nets, a reasonable number of
          medium nets and a large number of small nets.  The top two
          bits in the first octet are coded to tell the address for-
          mat.  All of the class A nets have been allocated.  So one
          has to choose between Class B and Class C when placing an
          order.  (There are also class D (Multicast) and E (Experi-
          mental) formats.  Multicast addresses will likely come into
          greater use in the near future, but are not frequently used
          now).

          In the past sites requiring multiple network addresses
          requested multiple discrete addresses (usually Class C).
          This was done because much of the software available (not-
          ably 4.2BSD) could not deal with subnetted addresses.
          Information on how to reach a particular network (routing
          information) must be stored in Internet gateways and packet
          switches.  Some of these nodes have a limited capability to
          store and exchange routing information (limited to about 300
          networks).  Therefore, it is suggested that any campus
          announce (make known to the Internet) no more than two
          discrete network numbers.

          If a campus expects to be constrained by this, it should
          consider subnetting.  Subnetting (RFC-932) allows one to
          announce one address to the Internet and use a  set of
          addresses on the campus.  Basically, one defines a mask
          which allows the network to differentiate between the net-
          work portion and host portion of the address.  By using a
          different mask on the Internet and the campus, the address
          can be interpreted in multiple ways.  For example, if a
          campus requires two networks internally and has the 32,000
          addresses beginning 128.174.X.X (a Class B address) allo-
          cated to it,  the campus could allocate 128.174.5.X to one
          part of campus and 128.174.10.X to another.  By advertising
          128.174 to the Internet with a subnet mask of FF.FF.00.00,
          the Internet would treat these two addresses as one. Within
          the campus a mask of FF.FF.FF.00 would be used, allowing the
          campus to treat the addresses as separate entities. (In
          reality you don't pass the subnet mask of FF.FF.00.00 to the
          Internet, the octet meaning is implicit in its being a class
          B address).

          A word of warning is necessary.  Not all systems know how to
          do subnetting.  Some 4.2BSD systems require additional
          software.  4.3BSD systems subnet as released.  Other devices


                                      -7-










          and operating systems vary in the problems they have dealing
          with subnets.  Frequently these machines can be used as a
          leaf on a network but not as a gateway within the subnetted
          portion of the network.  As time passes and more systems
          become 4.3BSD based, these problems should disappear.

          There has been some confusion in the past over the format of
          an IP broadcast address.  Some machines used an address of
          all zeros to mean broadcast and some all ones.  This was
          confusing when machines of both type were connected to the
          same network. The broadcast address of all ones has been
          adopted to end the grief.  Some systems (e.g. 4.2 BSD) allow
          one to choose the format of the broadcast address.  If a
          system does allow this choice, care should be taken that the
          all ones format is chosen.  (This is explained in RFC-1009
          and RFC-1010).



          _ I_ n_ t_ e_ r_ n_ e_ t _ P_ r_ o_ b_ l_ e_ m_ s

          There are a number of problems with the Internet.  Solutions
          to the problems range from software changes to long term
          research projects. Some of the major ones are detailed
          below:

          Number of Networks

               When the Internet was designed it was to have about 50
               connected networks.  With the explosion of networking,
               the number is now approaching 300.  The software in a
               group of critical gateways (called the core gateways of
               the ARPAnet) are not able to pass or store much more
               than that number.  In the short term, core reallocation
               and recoding has raised the number slightly.  By the
               summer of '88 the current PDP-11 core gateways will be
               replaced with BBN Butterfly gateways which will solve
               the problem.

          Routing Issues

               Along with sheer mass of the data necessary to route
               packets to a large number of networks, there are many
               problems with the updating, stability, and optimality
               of the routing algorithms.  Much research is being done
               in the area, but the optimal solution to these routing
               problems is still years away.  In most cases the the
               routing we have today works, but sub-optimally and
               sometimes unpredictably.

          Trust Issues




                                      -8-










               Gateways exchange network routing information.
               Currently, most gateways accept on faith that the
               information provided about the state of the network is
               correct.  In the past this was not a big problem since
               most of the gateways belonged to a single administra-
               tive entity (DARPA).  Now with multiple wide area net-
               works under different administrations, a rogue gateway
               somewhere in the net could cripple the Internet.  There
               is design work going on to solve both the problem of a
               gateway doing unreasonable things and providing enough
               information to reasonably route data between multiply
               connected networks (multi-homed networks).

          Capacity & Congestion

               Many portions of the ARPAnet are very congested during
               the busy part of the day.  Additional links are planned
               to alleviate this congestion, but the implementation
               will take a few months.


          These problems and the future direction of the Internet are
          determined by the Internet Architect (Dave Clark of MIT)
          being advised by the Internet Activities Board (IAB).  This
          board is composed of chairmen of a number of committees with
          responsibility for various specialized areas of the Inter-
          net.  The committees composing the IAB and their chairmen
          are:

                  _ C_ o_ m_ m_ i_ t_ t_ e_ e                            _ C_ h_ a_ i_ r
               Autonomous Networks                  Deborah Estrin
               End-to-End Services                  Bob Braden
               Internet Architecture                Dave Mills
               Internet Engineering                 Phil Gross
                    EGP2                            Mike Petry
                    Name Domain Planning            Doug Kingston
                    Gateway Monitoring              Craig Partridge
                    Internic                        Jake Feinler
                    Performance & Congestion ControlRobert Stine
                    NSF Routing                     Chuck Hedrick
                    Misc. MilSup Issues             Mike St. Johns
               Privacy                              Steve Kent
               IRINET Requirements                  Vint Cerf
               Robustness & Survivability           Jim Mathis
               Scientific Requirements              Barry Leiner

          Note that under Internet Engineering, there are a set of
          task forces and chairs to look at short term concerns.  The
          chairs of these task forces are not part of the IAB.



          _ R_ o_ u_ t_ i_ n_ g


                                      -9-










          Routing is the algorithm by which a network directs a packet
          from its source to its destination.  To appreciate the prob-
          lem, watch a small child trying to find a table in a restau-
          rant.  From the adult point of view the structure of the
          dining room is seen and an optimal route easily chosen.  The
          child, however, is presented with a set of paths between
          tables where a good path, let alone the optimal one to the
          goal is not discernible.

          A little more background might be appropriate.  IP gateways
          (more correctly routers) are boxes which have connections to
          multiple networks and pass traffic  between these nets.
          They decide how the packet is to be sent based on the infor-
          mation in the IP header of the packet and the state of the
          network.  Each interface on a router has an unique address
          appropriate to the network to which it is connected.  The
          information in the IP header which is used is primarily the
          destination address.  Other information (e.g. type of ser-
          vice) is largely ignored at this time.  The state of the
          network is determined by the routers passing information
          among themselves.  The distribution of the database (what
          each node knows), the form of the updates, and metrics used
          to measure the value of a connection, are the parameters
          which determine the characteristics of a routing protocol.

          Under some algorithms each node in the network has complete
          knowledge of the state of the network (the adult algorithm).
          This implies the nodes must have larger amounts of local
          storage and enough CPU to search the large tables in a short
          enough time (remember this must be done for each packet).
          Also, routing updates usually contain only changes to the
          existing information (or you spend a large amount of the
          network capacity passing around megabyte routing updates).
          This type of algorithm has several problems.  Since the only
          way the routing information can be passed around is across
          the network and the propagation time is non-trivial, the
          view of the network at each node is a correct historical
          view of the network at varying times in the past.  (The
          adult algorithm, but rather than looking directly at the
          dining area, looking at a photograph of the dining room.
          One is likely to pick the optimal route and find a bus-cart
          has moved in to block the path after the photo was taken).
          These inconsistencies can cause circular routes (called
          routing loops) where once a packet enters it is routed in a
          closed path until its time to live (TTL) field expires and
          it is discarded.

          Other algorithms may know about only a subset of the net-
          work.  To prevent loops in these protocols, they are usually
          used in a hierarchical network.  They know completely about
          their own area, but to leave that area they go to one par-
          ticular place (the default gateway).  Typically these are
          used in smaller networks (campus, regional...).


                                      -10-












          Routing protocols in current use:

          Static (no protocol-table/default routing)

               Don't laugh.  It is probably the most reliable, easiest
               to implement, and least likely to get one into trouble
               for a small network or a leaf on the Internet.  This
               is, also, the only method available on some
               CPU-operating system combinations. If a host is con-
               nected to an Ethernet which has only one gateway off of
               it, one should make that the default gateway for the
               host and do no other routing.  (Of course that gateway
               may pass the reachablity information somehow on the
               other side of itself).

               One word of warning, it is only with extreme caution
               that one should use static routes in the middle of a
               network which is also using dynamic routing.  The
               routers passing dynamic information are sometimes con-
               fused by conflicting dynamic and static routes.  If
               your host is on an ethernet with multiple routers to
               other networks on it and the routers are doing dynamic
               routing among themselves, it is usually better to take
               part in the dynamic routing than to use static routes.

          RIP

               RIP is a routing protocol based on XNS (Xerox Network
               System) adapted for IP networks.  It is used by many
               routers (Proteon, cisco, UB...) and many BSD Unix sys-
               tems.  BSD systems typically run a program called
               _ r_ o_ u_ t_ e_ d to exchange information with other systems run-
               ning RIP.  RIP works best for nets of small diameter
               where the links are of equal speed.  The reason for
               this is that the metric used to determine which path is
               best is the hop-count.  A hop is a traversal across a
               gateway.  So, all machines on the same Ethernet are
               zero hops away.  If a router connects connects two net-
               works directly, a machine on the other side of the
               router is one hop away....  As the routing information
               is passed through a gateway, the gateway adds one to
               the hop counts to keep them consistent across the net-
               work.  The diameter of a network is defined as the
               largest hop-count possible within a network.  Unfor-
               tunately, a hop count of 16 is defined as infinity in
               RIP meaning the link is down. Therefore, RIP will not
               allow hosts separated by more than 15 gateways in the
               RIP space to communicate.

               The other problem with hop-count metrics is that if
               links have different speeds, that difference is not


                                      -11-










               reflected in the hop-count. So a one hop satellite link
               (with a .5 sec delay) at 56kb would be used instead of
               a two hop T1 connection. Congestion can be viewed as a
               decrease in the efficacy of a link. So, as a link gets
               more congested, RIP will still know it is the best
               hop-count route and congest it even more by throwing
               more packets on the queue for that link.

               The protocol is not well documented.  A group of people
               are working on producing an RFC to both define the
               current RIP and to do some extensions to it to allow it
               to better cope with larger networks.  Currently, the
               best documentation for RIP appears to be the code to
               BSD _ r_ o_ u_ t_ e_ d.


          Routed

               The _ r_ o_ u_ t_ e_ d program, which does RIP for 4.2BSD systems,
               has many options. One of the most frequently used is:
               _ r_ o_ u_ t_ e_ d -_ q (quiet mode) which means listen to RIP infor-
               mation but never broadcast it.  This would be used by a
               machine on a network with multiple RIP speaking gate-
               ways.  It allows the host to determine which gateway is
               best (hopwise) to use to reach a distant network.  (Of
               course you might want to have a default gateway to
               prevent having to pass all the addresses known to the
               Internet around with RIP).

               There are two ways to insert static routes into _ r_ o_ u_ t_ e_ d,
               the /_ e_ t_ c/_ g_ a_ t_ e_ w_ a_ y_ s file and the _ r_ o_ u_ t_ e _ a_ d_ d command.
               Static routes are useful if you know how to reach a
               distant network, but you are not receiving that route
               using RIP.  For the most part the _ r_ o_ u_ t_ e _ a_ d_ d command is
               preferable to use.  The reason for this is that the
               command adds the route to that machine's routing table
               but does not export it through RIP.  The /_ e_ t_ c/_ g_ a_ t_ e_ w_ a_ y_ s
               file takes precedence over any routing information
               received through a RIP update.  It is also broadcast as
               fact in RIP updates produced by the host without ques-
               tion, so if a mistake is made in the /_ e_ t_ c/_ g_ a_ t_ e_ w_ a_ y_ s
               file, that mistake will soon permeate the RIP space and
               may bring the network to its knees.

               One of the problems with _ r_ o_ u_ t_ e_ d is that you have very
               little control over what gets broadcast and what
               doesn't.  Many times in larger networks where various
               parts of the network are under different administrative
               controls, you would like to pass on through RIP only
               nets which you receive from RIP and you know are rea-
               sonable.  This prevents people from adding IP addresses
               to the network which may be illegal and you being
               responsible for passing them on to the Internet.  This


                                      -12-










               type of reasonability checks are not available with
               _ r_ o_ u_ t_ e_ d and leave it usable, but inadequate for large
               networks.


          Hello (RFC-891)

               Hello is a routing protocol which was designed and
               implemented in a experimental software router called a
               "Fuzzball" which runs on a PDP-11. It does not have
               wide usage, but is the routing protocol currently used
               on the NSFnet backbone.  The data transferred between
               nodes is similar to RIP (a list of networks and their
               metrics).  The metric, however, is milliseconds of
               delay.  This allows Hello to be used over nets of vari-
               ous link speeds and performs better in congestive
               situations.

               One of the most interesting side effects of Hello based
               networks is their great timekeeping ability.  If you
               consider the problem of measuring delay on a link for
               the metric, you find that it is not an easy thing to
               do.  You cannot measure round trip time since the
               return link may be more congested, of a different
               speed, or even not there.  It is not really feasible
               for each node on the network to have a builtin WWV
               (nationwide radio time standard) receiver.  So, you
               must design an algorithm to pass around time between
               nodes over the network links where the delay in
               transmission can only be approximated.  Hello routers
               do this and in a nationwide network maintain synchron-
               ized time within milliseconds.


          Exterior Gateway Protocol (EGP RFC-904)

               EGP is not strictly a routing protocol, it is a reacha-
               bility protocol. It tells only if nets can be reached
               through a particular gateway, not how good the connec-
               tion is.  It is the standard by which gateways to local
               nets inform the ARPAnet of the nets they can reach.
               There is a metric passed around by EGP but its usage is
               not standardized formally.  Its typical value is value
               is 1 to 8 which are arbitrary goodness of link values
               understood by the internal DDN gateways. The smaller
               the value the better and a value of 8 being unreach-
               able.  A quirk of the protocol prevents distinguishing
               between 1 and 2, 3 and 4..., so the usablity of this as
               a metric is as three values and unreachable.  Within
               NSFnet the values used are 1, 3, and unreachable.  Many
               routers talk EGP so they can be used for ARPAnet gate-
               ways.



                                      -13-












          Gated

               So we have regional and campus networks talking RIP
               among   themselves,  the  NSFnet  backbone  talking
               Hello, and the DDN speaking EGP.

               How do they interoperate?  In the beginning there was
               static routing, assembled into the Fuzzball software
               configured for each site.  The problem with doing
               static routing in the middle of the network is that it
               is broadcast to the Internet whether it is usable or
               not.  Therefore, if a net becomes unreachable and you
               try to get there, dynamic routing will immediately
               issue a net unreachable to you.  Under static routing
               the routers would think the net could be reached and
               would continue trying until the application gave up (in
               2 or more minutes).  Mark Fedor of Cornell
               (fedor@devvax.tn.cornell.edu) attempted to solve these
               problems with a replacement for _ r_ o_ u_ t_ e_ d called _ g_ a_ t_ e_ d.

               _ G_ a_ t_ e_ d talks RIP to RIP speaking hosts, EGP to EGP
               speakers, and Hello to Hello'ers.  These speakers fre-
               quently all live on one Ethernet, but luckily (or
               unluckily) cannot understand each others ruminations.
               In addition, under configuration file control it can
               filter the conversion.  For example, one can produce a
               configuration saying announce RIP nets via Hello only
               if they are specified in a list and are reachable by
               way of a RIP broadcast as well.  This means that if a
               rogue network appears in your local site's RIP space,
               it won't be passed through to the Hello side of the
               world.  There are also configuration options to do
               static routing and name trusted gateways.

               This may sound like the greatest thing since sliced
               bread, but there is a catch called metric conversion.
               You have RIP measuring in hops, Hello measuring in mil-
               liseconds, and EGP using arbitrary small numbers.  The
               big questions is how many hops to a millisecond, how
               many milliseconds in the EGP number 3....  Also,
               remember that infinity (unreachability) is 16 to RIP,
               30000 or so to Hello, and 8 to the DDN with EGP.  Get-
               ting all these metrics to work well together is no
               small feat.  If done incorrectly and you translate an
               RIP of 16 into an EGP of 6, everyone in the ARPAnet
               will still think your gateway can reach the unreachable
               and will send every packet in the world your way.  For
               these reasons, Mark requests that you consult closely
               with him when configuring and using _ g_ a_ t_ e_ d.




                                      -14-










          _ N_ a_ m_ e_ s

          All routing across the network is done by means of the IP
          address associated with a packet. Since humans find it dif-
          ficult to remember addresses like 128.174.5.50, a symbolic
          name register was set up at the NIC where people would say
          "I would like my host to be named 'uiucuxc'".  Machines con-
          nected to the Internet across the nation would connect to
          the NIC in the middle of the night, check modification dates
          on the hosts file, and if modified move it to their local
          machine.  With the advent of workstations and micros,
          changes to the host file would have to be made nightly.  It
          would also be very labor intensive and consume a lot of net-
          work bandwidth. RFC-882 and a number of others describe
          domain name service, a distributed data base system for map-
          ping names into addresses.

          We must look a little more closely into what's in a name.
          First, note that an address specifies a particular connec-
          tion on a specific network.  If the machine moves, the
          address changes.  Second, a machine can have one or more
          names and one or more network addresses (connections) to
          different networks.  Names point to a something which does
          useful work (i.e. the machine) and IP addresses point to an
          interface on that provider.  A name is a purely symbolic
          representation of a list of addresses on the network.  If a
          machine moves to a different network, the addresses will
          change but the name could remain the same.

          Domain names are tree structured names with the root of the
          tree at the right.  For example:

                                uxc.cso.uiuc.edu

          is a machine called 'uxc' (purely arbitrary), within the
          subdomains method of allocation of the U of I) and 'uiuc'
          (the University of Illinois at Urbana), registered with
          'edu' (the set of educational institutions).

          A simplified model of how a name is resolved is that on the
          user's machine there is a resolver.  The resolver knows how
          to contact across the network a root name server. Root
          servers are the base of the tree structured data retrieval
          system.  They know who is responsible for handling first
          level domains (e.g. 'edu').  What root servers to use is an
          installation parameter. From the root server the resolver
          finds out who provides 'edu' service.  It contacts the 'edu'
          name server which supplies it with a list of addresses of
          servers for the subdomains (like 'uiuc').  This action is
          repeated with the subdomain servers until the final sub-
          domain returns a list of addresses of interfaces on the host
          in question.  The user's machine then has its choice of
          which of these addresses to use for communication.


                                      -15-










          A group may apply for its own domain name (like 'uiuc'
          above).  This is done in a manner similar to the IP address
          allocation.  The only requirements are that the requestor
          have two machines reachable from the Internet, which will
          act as name servers for that domain.  Those servers could
          also act as servers for subdomains or other servers could be
          designated as such.  Note that the servers need not be
          located in any particular place, as long as they are reach-
          able for name resolution.  (U of I could ask Michigan State
          to act on its behalf and that would be fine).  The biggest
          problem is that someone must do maintenance on the database.
          If the machine is not convenient, that might not be done in
          a timely fashion.  The other thing to note is that once the
          domain is allocated to an administrative entity, that entity
          can freely allocate subdomains using what ever manner it
          sees fit.

          The Berkeley Internet Name Domain (BIND) Server implements
          the Internet name server for UNIX systems.  The name server
          is a distributed data base system that allows clients to
          name resources and to share that information with other net-
          work hosts.  BIND is integrated with 4.3BSD and is used to
          lookup and store host names, addresses, mail agents, host
          information, and more.  It replaces the /_ e_ t_ c/_ h_ o_ s_ t_ s file for
          host name lookup.  BIND is still an evolving program.  To
          keep up with reports on operational problems, future design
          decisions, etc, join the BIND mailing list by sending a
          request to _ b_ i_ n_ d-_ r_ e_ q_ u_ e_ s_ t@_ u_ c_ b_ a_ r_ p_ a._ B_ e_ r_ k_ e_ l_ e_ y._ E_ D_ U.  BIND can also
          be obtained via anonymous FTP from ucbarpa.berkley.edu.

          There are several advantages in using BIND.  One of the most
          important is that it frees a host from relying on /_ e_ t_ c/_ h_ o_ s_ t_ s
          being up to date and complete.  Within the .uiuc.edu domain,
          only a few hosts are included in the host table distributed
          by SRI.  The remainder are listed locally within the BIND
          tables on uxc.cso.uiuc.edu (the server machine for most of
          the .uiuc.edu domain).  All are equally reachable from any
          other Internet host running BIND.

          BIND can also provide mail forwarding information for inte-
          rior hosts not directly reachable from the Internet.  These
          hosts can either be on non-advertised networks, or not con-
          nected to a network at all, as in the case of UUCP-reachable
          hosts.  More information on BIND is available in the "Name
          Server Operations Guide for BIND" in _ U_ N_ I_ X _ S_ y_ s_ t_ e_ m _ M_ a_ n_ a_ g_ e_ r'_ s
          _ M_ a_ n_ u_ a_ l, 4.3BSD release.

          There are a few special domains on the network, like SRI-
          NIC.ARPA.  The 'arpa' domain is historical, referring to
          hosts registered in the old hosts database at the NIC.
          There are others of the form NNSC.NSF.NET.  These special
          domains are used sparingly and require ample justification.
          They refer to servers under the administrative control of


                                      -16-










          the network rather than any single organization.  This
          allows for the actual server to be moved around the net
          while the user interface to that machine remains constant.
          That is, should BBN relinquish control of the NNSC, the new
          provider would be pointed to by that name.

          In actuality, the domain system is a much more general and
          complex system than has been described.  Resolvers and some
          servers cache information to allow steps in the resolution
          to be skipped.  Information provided by the servers can be
          arbitrary, not merely IP addresses.  This allows the system
          to be used both by non-IP networks and for mail, where it
          may be necessary to give information on intermediate mail
          bridges.


          _ W_ h_ a_ t'_ s _ w_ r_ o_ n_ g _ w_ i_ t_ h _ B_ e_ r_ k_ e_ l_ e_ y _ U_ n_ i_ x

          University of California at Berkeley has been funded by
          DARPA to modify the Unix system in a number of ways.
          Included in these modifications is support for the Internet
          protocols.  In earlier versions (e.g. BSD 4.2) there was
          good support for the basic Internet protocols (TCP, IP,
          SMTP, ARP) which allowed it to perform nicely on IP ether-
          nets and smaller Internets.  There were deficiencies, how-
          ever, when it was connected to complicated networks.  Most
          of these problems have been resolved under the newest
          release (BSD 4.3).  Since it is the springboard from which
          many vendors have launched Unix implementations (either by
          porting the existing code or by using it as a model), many
          implementations (e.g. Ultrix) are still based on BSD 4.2.
          Therefore, many implementations still exist with the BSD 4.2
          problems.  As time goes on, when BSD 4.3 trickles through
          vendors as new release, many of the problems will be
          resolved.  Following is a list of some problem scenarios and
          their handling under each of these releases.

          ICMP redirects

               Under the Internet model, all a system needs to know to
               get anywhere in the Internet is its own address, the
               address of where it wants to go, and how to reach a
               gateway which knows about the Internet.  It doesn't
               have to be the best gateway.  If the system is on a
               network with multiple gateways, and a host sends a
               packet for delivery to a gateway which feels another
               directly connected gateway is more appropriate, the
               gateway sends the sender a message.  This message is an
               ICMP redirect, which politely says "I'll deliver this
               message for you, but you really ought to use that gate-
               way over there to reach this host".  BSD 4.2 ignores
               these messages.  This creates more stress on the gate-
               ways and the local network, since for every packet


                                      -17-










               sent, the gateway sends a packet to the originator.
               BSD 4.3 uses the redirect to update its routing tables,
               will use the route until it times out, then revert to
               the use of the route it thinks is should use.  The
               whole process then repeats, but it is far better than
               one per packet.

          Trailers

               An application (like FTP) sends a string of octets to
               TCP which breaks it into chunks, and adds a TCP header.
               TCP then sends blocks of data to IP which adds its own
               headers and ships the packets over the network.  All
               this prepending of the data with headers causes memory
               moves in both the sending and the receiving machines.
               Someone got the bright idea that if packets were long
               and they stuck the headers on the end (they became
               trailers), the receiving machine could put the packet
               on the beginning of a page boundary and if the trailer
               was OK merely delete it and transfer control of the
               page with no memory moves involved.  The problem is
               that trailers were never standardized and most gateways
               don't know to look for the routing information at the
               end of the block.  When trailers are used, the machine
               typically works fine on the local network (no gateways
               involved) and for short blocks through gateways (on
               which trailers aren't used).  So TELNET and FTP's of
               very short files work just fine and FTP's of long files
               seem to hang.  On BSD 4.2 trailers are a boot option
               and one should make sure they are off when using the
               Internet.  BSD 4.3 negotiates trailers, so it uses them
               on its local net and doesn't use them when going across
               the network.

          Retransmissions

               TCP fires off blocks to its partner at the far end of
               the connection.  If it doesn't receive an acknowledge-
               ment in a reasonable amount of time it retransmits the
               blocks.  The determination of what is reasonable is
               done by TCP's retransmission algorithm.  There is no
               correct algorithm but some are better than others,
               where better is measured by the number of retransmis-
               sions done unnecessarily.  BSD 4.2 had a retransmission
               algorithm which retransmitted quickly and often.  This
               is exactly what you would want if you had a bunch of
               machines on an ethernet (a low delay network of large
               bandwidth).  If you have a network of relatively longer
               delay and scarce bandwidth (e.g. 56kb lines), it tends
               to retransmit too aggressively.  Therefore, it makes
               the networks and gateways pass more traffic than is
               really necessary for a given conversation.  Retransmis-
               sion algorithms do adapt to the delay of the network


                                      -18-










               after a few packets, but 4.2's adapts slowly in delay
               situations.  BSD 4.3 does a lot better and tries to do
               the best for both worlds.  It fires off a few
               retransmissions really quickly assuming it is on a low
               delay network, and then backs off very quickly.  It
               also allows the delay to be about 4 minutes before it
               gives up and declares the connection broken.
















































                                      -19-













                                     Appendix A
                         References to Remedial Information


               Quaterman and Hoskins, "Notable Computer Networks",
               _ C_ o_ m_ m_ u_ n_ i_ c_ a_ t_ i_ o_ n_ s _ o_ f _ t_ h_ e _ A_ C_ M, Vol 29, #10, pp. 932-971
               (October, 1986).

               Tannenbaum, Andrew S., _ C_ o_ m_ p_ u_ t_ e_ r _ N_ e_ t_ w_ o_ r_ k_ s, Prentice
               Hall, 1981.

               Hedrick, Chuck, _ I_ n_ t_ r_ o_ d_ u_ c_ t_ i_ o_ n _ t_ o _ t_ h_ e _ I_ n_ t_ e_ r_ n_ e_ t _ P_ r_ o_ t_ o_ c_ o_ l_ s,
               Anonymous FTP from topaz.rutgers.edu, directory
               pub/tcp-ip-docs, file tcp-ip-intro.doc.






































                                      -20-













                                     Appendix B
                                 List of Major RFCs


                    RFC-768        User Datagram Protocol (UDP)
                    RFC-791        Internet Protocol (IP)
                    RFC-792        Internet Control Message Protocol (ICMP)
                    RFC-793        Transmission Control Protocol (TCP)
                    RFC-821        Simple Mail Transfer Protocol (SMTP)
                    RFC-822        Standard for the Format of ARPA Internet Text Messages
                    RFC-854        Telnet Protocol
                    RFC-917 *      Internet Subnets
                    RFC-919 *      Broadcasting Internet Datagrams
                    RFC-922 *      Broadcasting Internet Datagrams in the Presence of Subnets
                    RFC-940 *      Toward an Internet Standard Scheme for Subnetting
                    RFC-947 *      Multi-network Broadcasting within the Internet
                    RFC-950 *      Internet Standard Subnetting Procedure
                    RFC-959        File Transfer Protocol (FTP)
                    RFC-966 *      Host Groups: A Multicast Extension to the Internet Protocol
                    RFC-988 *      Host Extensions for IP Multicasting
                    RFC-997 *      Internet Numbers
                    RFC-1010 *     Assigned Numbers
                    RFC-1011 *     Official ARPA-Internet Protocols

               RFC's marked with the asterisk (*) are not included in
               the 1985 DDN Protocol Handbook.

               Note: This list is a portion of a list of RFC's by
               topic retrieved from the NIC under NETINFO:RFC-SETS.TXT
               (anonymous FTP of course).

               The following list is not necessary for connection to
               the Internet, but is useful in understanding the domain
               system, mail system, and gateways:

                    RFC-882        Domain Names - Concepts and Facilities
                    RFC-883        Domain Names - Implementation
                    RFC-973        Domain System Changes and Observations
                    RFC-974        Mail Routing and the Domain System
                    RFC-1009       Requirements for Internet Gateways












                                      -21-













                                     Appendix C
                       Contact Points for Network Information


          Network Information Center (NIC)

               DDN Network Information Center
               SRI International, Room EJ291
               333 Ravenswood Avenue
               Menlo Park, CA 94025
               (800) 235-3155 or (415) 859-3695
               NIC@SRI-NIC.ARPA


          NSF Network Service Center (NNSC)

               NNSC
               BBN Laboratories Inc.
               10 Moulton St.
               Cambridge, MA 02238
               (617) 497-3400
               NNSC@NNSC.NSF.NET






























                                      -22-













                                    Glossary


          core gateway   The innermost gateways of the ARPAnet.  These
                         gateways have a total picture of the reacha-
                         bility to all networks known to the ARPAnet
                         with EGP.  They then redistribute reachabil-
                         ity information to all those gateways speak-
                         ing EGP.  It is from them your EGP agent
                         (there is one acting for you somewhere if you
                         can reach the ARPAnet) finds out it can reach
                         all the nets on the ARPAnet. Which is then
                         passed to you via Hello, gated, RIP....

          count to infinityThe symptom of a routing problem where
                         routing information is passed in a circular
                         manner through multiple gateways.  Each gate-
                         way increments the metric appropriately and
                         passes it on.  As the metric is passed around
                         the loop, it increments to ever increasing
                         values til it reaches the maximum for the
                         routing protocol being used, which typically
                         denotes a link outage.

          hold down      When a router discovers a path in the network
                         has gone down announcing that that path is
                         down for a minimum amount of time (usually at
                         least two minutes).  This allows for the pro-
                         pagation of the routing information across
                         the network and prevents the formation of
                         routing loops.

          split horizon  When a router (or group of routers working in
                         consort) accept routing information from mul-
                         tiple external networks, but do not pass on
                         information learned from one external network
                         to any others.  This is an attempt to prevent
                         bogus routes to a network from being pro-
                         pagated because of gossip or counting to
                         infinity.












                                      -23-




-- 
Steve Scott            UUCP: {killer|texbell}!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 18:45:10 GMT
From:      dinah@shell.com (Dinah Anderson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Host Naming Conventions

My management is looking into the pros and cons of having naming 
conventions for IP hosts. Like xysuna, xysunb, etc., where xy is a site
id. This is just an example. I can think of quite a few reasons for not
doing this (we currently have server groups with themes of some kind which
seems to be the way a lot of companies and universities are handling this.)

My question is can any one out there provide me with reasons for or against
host naming conventions. I can think of several, but don't want to present
my biases before receiving some ideas from you folks. Thanks a lot!
Dinah Anderson 
Shell Oil Company, Information Center (713) 795-3287
..!{sun,psuvax,bcm,rice}!shell!dinah

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 19:14:52 GMT
From:      zdwcv@dcatla.UUCP (Wm. C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Looking for FTPable Jacobson/Karels code


There was reference here to an archive containing work done by 
Van Jacobson and Mike Karels to speed up TCP/IP implementations.
Naturally, now that I need this code, 
I can't find the reference. Would someone who knows were this
lives please mail me a pointer?? 

Thanks in advance
Bill VerSteeg

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 19:17:15 GMT
From:      stan@ANES.UCLA.EDU (Stan Stead)
To:        comp.protocols.tcp-ip
Subject:   NFS for the mac

Could someone please mail to me possible sources for NFS for a MAC II,
and suggestions for ethernet cards.  Thanks in advance.

Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL:	(213) 206-6238
ARPA:	ucla-an!stan@ee.UCLA.EDU
BITNET:	ucla-an!stan@EE
UUCP:	{randvax | ucla-cs}\
			    !ucla-an!stan
UUCP:	{att|decvax}!hermix/

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 20:25:44 GMT
From:      brescia@BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP and C-30s


     We're installing cisco MGS gateways at different sites on Milnet and 
     occasionally a problem crops up with exchanging EGP updates with the
     "new" core buttergates.  Essentially there seems to be an infinite 
     cycling up and down between the gateways with the core never sending an 
     update.

     A brief example of the exchanges follows.  Our gateway is sending updates
     and the real interesting part of it is that if the PSN our gateway is
     on gets reset, the problem clears up immediately.

     *******

     This gones on until the PSN (C-30) is reset, at which point updates from
     the core begin coming in.
     ... nothing except resetting the PSN seems tp work.
     -------

Darrel,

This sounds like an X.25 type of problem, involving x.25 window size, x.25
packet size, and resources in the local PSN.  I recall a similar problem where
a system could not get an egp update through when using a packet size of 128
and a window of 2.  Try to get the packet size to 512 or 1024, and the window
size 7 (or at least 4 for 1024 byte packets).  Note that the EGP update is
sent as 3 1004 byte IP fragments (oh, well, the 3rd is shorter, but it's
growing).  The total IP datagram size is around 2800 to 2900 bytes.

Also, make sure you have assurance from Cisco that you have latest revision of
code.

Please send further notes to "gw-fire@bbn.com" if appears to be a core
gateway problem instead of a host-psn interconnect problem.

Regards,
Mike Brescia

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 21:20:23 GMT
From:      news@tut.cis.ohio-state.edu (news)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: A Real Telnet Server for MS-DOS

to several "server" PC's.  These PC's could be attached to a Meridian CD
Jukebox on a Novel network.  They would be front ends to the Jukebox; Users
would then telnet into these boxes and run the search program that comes
with the particular CD they chose.  If Telnet was not used we would have
to front end the PC's with a terminal server and come into them thru there
COM1 port.  The PC would have to be running a supped up version of CTTY.
From: karl-d@cheops.cis.ohio-state.edu (Doug Karl)
Path: cheops.cis.ohio-state.edu!karl-d

This idea is a cludge and I was repulsed by it at first but don't have any
other good ideas.  The problem is that CD's and CD software are runs on MSDOS
and each CD has it's own unique search program.  Whatever we do we have to
allow EVERYONE to use the CD service.  Hence the idea of a system that
you could Telnet/VT100 into.  There are many other issues related to this
system but we could get into that later if anyone desires to.

TO ANSWER YOUR QUESTION:  The Telnet server should be very small, less than
80K would be nice.  If it mearly traped the BIOS and DOS screen calls and
send the ansi to the telnet output stream that may work with many CD's ????
Also whatever key mappings you use it should be tailerable; someone always
has a better idea.

Doug Karl
Computer Specialist
Instruction and Research Computer Center
Ohio State University

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 89 22:14:15 GMT
From:      alex@xicom.UUCP (Alex Laney)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V


	RPC is a standard part of NFS, no? I recall (faintly) somewhere that
Interactive advertised this as part of their NFS product.

	I have a copy of their Host-based TCP-IP, and the RPC3.9 source code.
My experience is that with modification of the headers, I could get it to
compile, but it would crap-out at run-time. This was a few months ago, so I
don't recall the exact error. I will be trying again soon, however.


Alex Laney, Xicom Technologies.

uunet!mitel!sce!xicom!alex (not alex@xicom.uucp)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 00:23:00 GMT
From:      wargaski@accuvax.nwu.edu (Rob Wargaski)
To:        comp.protocols.tcp-ip
Subject:   Re: Here is the HitchHiker!

In article <190@camdev.UUCP> sscott@camdev.UUCP (Steve Scott) writes:
.
.
.
>(What was Zaphod's last name anyway?)
&c.

Beeblebrox!

					Rob Wargaski
---------------------------------------------------------------------------
Rob Wargaski			    |	This is stupid. -- Vila
Inet:  wargaski@accuvax.nwu.edu	    |	When did that ever stop us. -- Avon
UUCP:  ...gargoyle!nucsrl!wargaski  |	. . . #include <disclaimer.h> . . .

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 05:08:19 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Keep alives....

Ok, so we don't do keep-alives at the TCP level.  This is the best reason
I've heard for a session protocol.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 20:09:39 GMT
From:      mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   (response to message of Tue, 30 May 89 11:59:13 EDT)

I think the pro-keepalive people were expressly stating that an ICMP error
should not shoot down a connection.  I hate Unix's behavior in doing this --
it kills several perfectly good connections/day on me every working day --
and I patched my Unix workstation not to do it.  But it doesn't help if the
guy I am talking to is still doing it.

All we want is a mechanism to tickle a TCP reset iff the other end has already
punted the connection.  In a sense, this is not a keepalive as much as it's a
clean up if already dead.

TCP should do this.  And, by doing this, it may prevent people from
implementing the kinds of keepalive and timeout mechanisms that we *all* hate.

-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 21:02:49 GMT
From:      umbaugh@hcx (Dr David L. Umbaugh)
To:        comp.protocols.tcp-ip
Subject:   Best TCP/IP package for a VAX 63xx

I would also be interested in the answer to this question.  We expect
to be replacing our current vms and Unix systems with a microvax 3900
ULTRIX system.  What OS will you run on the 6320?
L. David Umbaugh (Dave)
CSE Dept. Univ. Texas at Arlington
internet:  umbaugh@hcx.arl.utexas.edu     phonenet:  cs_umbaugh@uta.edu
CSNET:  cs_umbaugh%uta.edu@relay.cs.net   BITNET:  B652LDU@UTARLG
snail-mail: P.O.Box 19015, Arlington, TX  76019
telephone: (817) 273-3628

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 21:45:10 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: (response to message of Tue, 30 May 89 11:59:13 EDT)

If I'm not mistaken, its not the 4BSD UNIX TCP/IP code that dumps the connection
when an ICMP host/network unreacahble arrives, but the application.  The
network code will deliver the appropriate error (EHOSTUNREACH or ENETUNREACH)
the next time the connection is referenced. Typically, the application sees
this "unexpected" error and bails out.  

louie

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 89 22:28:07 GMT
From:      lonewolf@canisius.UUCP (Joe Wolf)
To:        comp.dcom.lans,comp.protocols.tcp-ip,misc.wanted
Subject:   Ethernet LAN Analyzers


I am interested in getting information on tools available that will analyze
traffic on an Ethernet LAN.  It would be nice if these were not protocol
specific.  I would also like some opinions on what to look for in a good
network/protocol analyzer.

In general I would like to get a good feel for what is available in the area
of tools for ethernet network analysis, both in terms of actual packages and
features that make up a good analyzer.  Any help would be greatly appreciated.

Please reply by email only, no need to bother the whole world with such
a trivial matter.  If I get a good response I will post a summary.

Thank you in advance.

  Joe Wolf

-- 
USMAIL: Joseph M. Wolf	        131 Hanwell Place          Depew, NY 14043
UUCP  : ...!{decvax|watmath|allegra|rocksvax}!sunybcs!canisius!lonewolf
CSNET : @canisius.edu:lonewolf@klaatu.cs.canisius.edu
BITNET: WOLF@CANISIUS

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 14:43:58 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Input solicited for Network Effectiveness Guidelines

I am writing a document about how to optimize the effectiveness of
network usage, primarily for users of MILNET.  Below is a highly
condensed list of items I already plan to mention.  Suggestions for
additional topics, points to bring out, misconceptions to (try to)
correct, etc., are welcomed.  Surely some of you experts out there have
been in the position of trying to explain some of these issues to
people who are not protocol gurus and never will be; your insights will
be helpful.  Please mail comments and suggestions to me directly unless
there's some reason for posting it to the world.  The document I am
writing will probably be publicly released eventually (around the end
of the year, I suppose).  Thanks in advance for all contributions...

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-------

[The eventual reader will be a semi-independent system manager, planner,
buyer, or smart user of some type of computer participating in a wide
area network which speaks mostly TCP/IP and charges per packet.  They
may or may not access that WAN through a LAN which may be of any size
or type, and the users of these computers may be local or remote with
potentially any type of equipment.  The readers are sufficiently
(un)sophisticated that terms like TCP/IP, TELNET, FTP, network mail,
connections, protocol, etc., are familiar but only understood in a
rather fuzzy way.  This document is intended to explain both general
principles and concrete actions that they might take to enable them to
do whatever it is they are trying to do with minimal costs for packets
on the long-haul network.]

Guiding Principles: $ cost depends on number of packets sent through
long-haul network.  Your LAN is probably free, as long as you stay on
it and don't try to exceed its capacity.  Don't send the same data
between the same points more than once.  Consolidate data into a
smaller number of large packets when feasible.  Convert long-haul usage
to short-haul usage (access local resources instead of distant ones) if
possible.

Mail: Probably the most widely used application.  Tends to be reasonably
efficient due to its inherent design.  Some software gives you ways to
do things a little better.  Mailers tend to have retry timers, often with
adjustable rates.  Fewer tries is cheaper but takes longer to get the mail
there.  Local mail exploders for massive distributions save a few packets
(or in some cases, lots) and are nice to have for other reasons.  In some
cases you may want a tree of exploders.  SMTP mailers are cheaper to run
if they will send more than one message on a single TCP connection.  Also,
they can deliver all copies for a single host in one transmission.

Domain Names:  You usually have a choice of host table or domain
servers.  Domain servers are better, at least if you tune them right.
FTPing host tables is probably wasteful in many ways.  DNS has less
density in terms of info per packet but most people don't want that
much data anyway.  With correct tuning, the DNS should be cheaper to
run in virtually all cases.  You should try to contrive things so that
a small number of hosts cache a lot of domain info, and you query those
hosts via some free resource (LAN).  If you need so much data from a
zone that DNS costs more than host table, you should probably set up a
local server, which gets the packet count back down since zone transfer
is probably even better than FTP, given the compaction.  Sensible
choice of what zones to serve where is important.

File transfer: Files wanted by lots of people should be cached locally in
some known server so only one copy needs to be moved through the
pay-per-packet backbone.  Restart capability in FTP could save, especially
for people who frequently move huge files around.  Compressed mode in FTP
would be good.  Compression with separate software can be very good
sometimes, but there is a tradeoff with CPU.  FTP in background or batch
may be cheaper due to fewer retransmits and due to lower prices for off-peak
packets.  The system administrator might want to log file transfers to
find out what files are redundantly transferred ( -> caching).  This might
be nice for security audit too.

TELNET: Line mode is cheaper than character mode.  Local echoing is
cheaper than remote echoing.  Application/user requirements have to be
considered too (characterwise interaction is worth its cost in some
situations).  TACs (and other terminal server devices) have some
settable parameters which will affect the packetizing (may foul up
interactive applications but may win for upload, etc.)  Extensive
editing to modest sized files may be cheaper to download/edit/upload
than to edit on a remote host.  Initial data entry on a PC rather than
a remote host may be smart.

Custom Applications: How you code tends to affect the packetizing,
which affects the cost.  Decide if you are doing interactive,
query/response or batch type processing and design accordingly.  Mail
can be used as an interface to some query/response applications - send
specially formatted message to a server mailbox, get back a message
with the answer.  With custom programming on all hosts involved, the
same thing can be done in real time (WHOIS).  Minimize SEND calls from
your code unless you have a TCP which is clever about repacketizing and
won't send lots of tiny packets.

Other User Facilities: Batch, UNIX "at", etc., may give you a handle on
getting transfers done at off-peak time when rates are less.  It is also
possible to build this into an application (user selects immediate or
overnight operation).

TCP/IP General: Avoid RX's, use Jacobson TCP's, especially if you go
through gateways or bogged paths much.  Learn how to see how much RXing
your system is doing, and if it's much, find out why, you may be paying
for them.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Jun 89 22:39:28 -0400
From:      Jeffrey C Honig <jch@chumley.TN.Cornell.EDU>
To:        tcp-ip@sri-nic.ARPA
Cc:        cunixc!micky@columbia.edu (Micky Liu)
Subject:   Re: tcpdump (more info)
> tcpdump is available in source from ftp.ee.lbl.gov by anonymous ftp,
> but unless you have a Sun-3 with SunOS3.5 it is un-useable.  If you
> have SunOS4.0 you will need to do two things:

>  1) Install a kernel fix on Sun-3's (I think Sun-4's are okay).  
>     The if_nit.o file is also at ftp.ee.lbl.gov.

>  2) Modify the source to work with Sun's new STREAMS based NIT 
>     interface.

> So now, if you have done step one, I will gladly send you my diffs
> since I have already done step two.  I cannot set up anonymous ftp
> service, but I will mail my diffs until somebody is nice enough to
> archive them...

The above mentioned patch is available for anonymous FTP from
devvax.tn.cornell.edu as pub/tcpdump.sunos4.patch.

Jeff
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 17:07:20 GMT
From:      doug@ICASE.EDU (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   IP forwarding on Suns

Does anyone know what the Sun default (OS3.5) is for forwarding IP packets
when one with a different net address is received? Assume the Sun only has
one e-net connection. (Right, it's not a gateway, but the 'foreign-net'
packets are there, and I can't get rid of them.)

Thanks in advance

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 864-2172
FTS: 928-2172
doug@icase.edu

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 19:00:48 GMT
From:      djm@microsys.UUCP (dave malik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Running Vega VGA+WD8003+SU-PC/IP

In article <10828@orstcs.CS.ORST.EDU>, harish@guille.ece.orst.edu (Harish Pillay) writes:
>     I am trying to install a WD8003E net card on a Wyse286 AT to run 
>     Stanford University's PC/IP version 3.0.  So far it hasn't been a 
>     complete success.

We had similar problems with SCO TCP/IP until we noted that the release
notes said that some machines weren't happy with certain IO addresses.
Somthing about startup routines getting confused and thinking thay are 
talking to Serial IO boards. Maybe this helps ?

Dave Malik              MicroUnix Australia (Perth, WA office) +619 474 1184

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 22:22:54 GMT
From:      mfidelma@bbn.com (Miles R. Fidelman)
To:        comp.protocols.tcp-ip
Subject:   distributed systems over messaging networks


Hi Folks,

Has anyone come across any work on building distributed systems that
work across messaging networks? Particularly work that addresses the
issues of maintaining concurrency in the presence of very long
inter-node delays?

Please reply by email.

Thanks much,

Miles Fidelman

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 22:28:25 GMT
From:      mckenney@distek4.uucp (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: Keep alives....

In article <8906040508.AA20495@uunet.uu.net> mo@prisma.UUCP (Mike O'Dell) writes:
>Ok, so we don't do keep-alives at the TCP level.  This is the best reason
>I've heard for a session protocol.

Correct me if I am wrong, but if the transport layer cannot determine a
good keepalive ``timeout'' from the RTT and window-size information available
to it, then a session layer hasn't a ghost of a chance of coming up with
anything reasonable.

Has anyone tried to derive keepalive timeouts from RTT and window information?
For a simple example, one might set the timeout to (3000*RTT).  This would
yield a timeout of about 25 minutes for typical NSFnet RTTs (about half a
second).  On low-baudrate lines, the longer packet transmission times would
force the RTT higher (a 1200-baud line requires two-thirds of a second
to turn a minimum-size TCP packet around).

					Thanx, Paul

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 89 23:30:25 GMT
From:      jeff@hpctdkz.HP.COM (Jeff Hughes)
To:        comp.protocols.tcp-ip
Subject:   UDP vs TCP

I am trying to determine where the TCP port list and the UDP port list
differ. Obviously, certain protocols such as TELNET and FTP do not run
on top of UDP.                      

RFC1010 gives a list of assigned port numbers and states "To the extent
possible, these same port assignments are used with the UDP." Can someone
direct me to an official UDP list? Are any of the port numbers given in
RFC1010 redefined for UDP or is it simply that UDP does not use some of
the assigned port numbers?

                            
Any help would be appreciated.

                          jeff (hpctdkz.hp.com)

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 02:18:56 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   tcpdump diffs for SunOS4.0


Jeffrey C. Honig (jch@sonne.tn.cornell.edu) has kindly offered to make my
diffs available for anonymous ftp on devvax.tn.cornell.edu.  For all those
people who I haven't replied to, please look on this machine soon...  And
my apologies to those whose letters I haven't replied to.

Please remember that a kernel fix is needed for the new NIT.  nit_if.o must 
be replaced or else all of the snapshots in each chunk will be identical.
This will make it appear as if there are multiple identical ethernet packets.

Good Luck All and Thanx Jeff!

Micky Liu

  arpa: micky@cunixc.cc.columbia.edu
  uucp: ...!rutgers!columbia!cunixc!micky
bitnet: malua@cuvmc

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 03:43:00 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering

In article <326@brolga.cc.uq.oz> ggm@brolga.cc.uq.oz (George Michaelson) writes:
>
>On a parallel note, what is the effect of address and <other> filtering
>on throughput? My personal measure based on light loadings of some
>2Mbit ethernet bridges is that ANY address filtering makes throughput 
>appreciably slow. 

	some bridges really do support "full ethernet throughput".
	(define that term if you can!).  shall i plug our product?
	performance analysis of bridges is nontrivial -- but it is quite
	possible to get nearly 10 Mbps throughput through a lanbridge.

-Of course large packet protocols are less affected 
>but per-character packet activity is a bummer. I was surprised how visible 
>this could be given 10Mbit one side, 2Mbit the other.
	
	if you are interested in long distance ethernet extension,
	please give me an email.  also, if you have any ideas about
	how (why) to use a 20 Mile logical ethernet to connect Internet
	sites, drop me another email!  technically, two of our (Chipcom's)
	Marathon Bridges could run much further than 26.2 miles, if 
	anyone builds a broadband plant that long...  volunteers?


steve elias, chipcom corporation

..................
-- 
 ...... Steve Elias (eli@spdcc.com);(6178591389); {}
 { Apple: keep your lawyers off of our computers! }

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 06:15:53 GMT
From:      harish@guille.ece.orst.edu (Harish Pillay)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NetBIOS specification in RFC

In Douglas Comer's TCP/IP book, he mentions "that Internet engineers have
developed a standard that specifies how NetBIOS operations can be supported
in an Internet environment." Also, "the work, already adopted as an Internet
standard, specifies the semantics for each NetBIOS operation by explaining
how the operation maps onto the Internet protocols and address scheme."
(page 258 last paragraph).

Question:  Where is it actually defined?  Is it a RFC?  If so, what 
           number is it?  I searched RFC 1000, but no mention of it 
	   was made.  Maybe I'm not greping the right string.

Apologies if this has already been discussed.  E-mail replies please.

Thank you.

---------------------------------------------------------------------------
Harish Pillay                               Internet: harish@ece.orst.edu
Electrical and Computer Engineering         UUCP: uunet!ece.orst.edu!harish
Corvallis, Oregon 97331                     MaBell:   503-758-1389 (home)
United States of America                              503-754-2554 (office)
========     'Give a man a fish, and he'll starve for life,        ========
========  Show him how to fish, and he'll feed himself for life.'  ========
---------------------------------------------------------------------------

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 06:25:15 GMT
From:      jparnas@larouch.UUCP (Jacob Parnas)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Van Jacobson's version of SLIP with header compression...

Last usenix, telebit was using Van Jacobson's version of SLIP in their
terminal server.  At the Telebit BOF, the word was that this code would
be publically accessible in a few weeks (that was in Feb, 1989).  
Does any one know where to get a copy of this code?

Thanks for your help, 

--------------------------------------------------------------------------------
| Jacob M. Parnas                      | DISCLAIMER: The above message is from |
| IBM Thomas J. Watson Research Center | me and is not from my employer.  IBM  |
| Arpanet: jparnas@ibm.com             | might completely disagree with me.    |
| Bitnet: jparnas@yktvmx.bitnet        \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635       |
--------------------------------------------------------------------------------

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 10:44:56 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump for SunOS4.0?



 >The latest copy of the tcpdump program from LBL (README file
 >dated Oct 21, 1988) does not work under SunOS4.0 (as clearly
 >stated in the README file).  Has anyone written a 4.0 NIT
 >interface for tcpdump (or in some other way gotten it to
 >work with 4.0)?  

Larry	,

 i have a limping OS4.0 tcpdump, that someone could take and run with

it should be anon ftp-able from 
cs.ucl.ac.uk
(or purple.cs.ucl.uk, 128.16.6.4)
in src/tcpdump.tar.Z
(compressed, tar format)

BUGS
it contains certain bugs that are of my making but the
OS4 NIT usage code should be a starter :-)

WARNINGS
It can crash your Sun 

 jon

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 12:51:54 GMT
From:      dinah@shell.UUCP (Dinah Anderson)
To:        comp.protocols.tcp-ip
Subject:   FTP and clear text account/password

There is some concern here about the fact that ftp passes the account
name and password in clear ASCII text and anyone with a PC and/or
LANalyzer of time type can capture this information.

One proposal has been to implement a public key encryption scheme
that would require modification of ftp on all systems involved to
support. I have some concerns with this which include:

1) My understanding is that the ftp RFC specifies that the userid/password
   is passed in clear text. This implementation would violate the RFC.

2) We would loose our interoperability and flexibility to go with different
   UNIX platforms. (All platforms would have to have this ftp change in
   order to interoperate.)

3) PC's and LANalyzers will still be able to capture and replay packets.
   (even if the public passwords have expiration dates, they probably
   won't be long enough to prevent this.)

4) This scheme would probably work ok on "standalones" like VMS vaxen and
   mainframes, but in a distributed networking environment, I think such
   a solution MUST support yellow pages (or equivalent mechanisms.) I would
   also want it to be transparent to the user.

My questions to you all are:

1) How are other sites handling this (ignoring physically security of
   the network itself - which I realize is key to having a secure network.)?

2) How does a third party authentication scheme interoperate with "non-players".
  In other words, if we decided to implement kerberos on our unix workstations,
  can we provide some level of security to our non-unix systems in terms
  of protecting the information (userid/passwords) on the non-unix systems.

Thanks in advance!

 


Dinah Anderson 
Shell Oil Company, Information Center (713) 795-3287
..!{sun,psuvax,bcm,rice}!shell!dinah

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Jun 89 11:44:56 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        bierma@nprdc.navy.mil
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: tcpdump for SunOS4.0?


 >The latest copy of the tcpdump program from LBL (README file
 >dated Oct 21, 1988) does not work under SunOS4.0 (as clearly
 >stated in the README file).  Has anyone written a 4.0 NIT
 >interface for tcpdump (or in some other way gotten it to
 >work with 4.0)?  

Larry	,

 i have a limping OS4.0 tcpdump, that someone could take and run with

it should be anon ftp-able from 
cs.ucl.ac.uk
(or purple.cs.ucl.uk, 128.16.6.4)
in src/tcpdump.tar.Z
(compressed, tar format)

BUGS
it contains certain bugs that are of my making but the
OS4 NIT usage code should be a starter :-)

WARNINGS
It can crash your Sun 

 jon

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 15:53:00 GMT
From:      @rice.edu:JACOBSON@LSUVAX.LSU.EDU ("Michael_Jacobson, Networks Manager, L.S.U.")
To:        comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering

Finally a problem simple enough that i know the answer.
The problem appears in DEC bridges that have v2.0 of the rom software. There is
a new set of roms that fix the problem. Unfortunately the FCO for this rom
change is still not out so your field service rep will have to special order the

ROMs. We have 19 brdiges here and our filed service rep can only order 3 sets of

ROMS at a time. It is taking a while to get them replaced. If you have RBMS I
can send you a com file I got at DECUS that will go out and check to see what
bridges have the problem and then send you a mail message and/or send the
commands to clear the bridges (you set a flag in the comfile as to the action
you want taken.)


                                        Hope this helps,
                                        Mike Jacobson
                                        Jacobson%lsuvax.bitnet@cunyvm.cuny.edu

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Jun 89 22:50:35 -0400
From:      tmallory@BBN.COM
To:        cire|eric <cire@cisco.com>
Cc:        tcp-ip@sri-nic.arpa, tmallory@BBN.COM
Subject:   Re: Token Ring Mac Addresses
Eric,

I've been a little behind in my mail, and have saved your message for a later
moment, which is now.  Though I don't have a copy in front of me, my memory is
that the cover letter which the IEEE sent with a block address assignment, as
well as the address itself, explicitly addressed the fact that the bit orders
for 802.3 and 802.4-5 are reversed.  The assigned address block refers to the
bits as they appear on the wire(fiber, etc.).  Our address was printed in
three forms:  binary network order, 802.3 hex, and 802.5 hex.  Reversing the
bits in each byte is the correct way to go for the different network types.

BTW There was a recent tip-ip posting concerning the hardware addresses from
some well-known manufacturer's equipment which did not match the assigned
address block(perhaps AT&T?), that appeared to be a bit-reversal problem.

Hope this is helpful, and that you didn't get too many versions of this
message.

Tracy Mallory
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 89 20:38:14 GMT
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz(Y))
To:        comp.protocols.tcp-ip
Subject:   Is This List Still Alive?


	After not hearing anything from this list for a week or so now,
	i'm curious if it has been disbanded or whatever.

	Thanks.

	steven m. schultz
	sms@wlv.imsd.contel.com

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 02:50:35 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring Mac Addresses

Eric,

I've been a little behind in my mail, and have saved your message for a later
moment, which is now.  Though I don't have a copy in front of me, my memory is
that the cover letter which the IEEE sent with a block address assignment, as
well as the address itself, explicitly addressed the fact that the bit orders
for 802.3 and 802.4-5 are reversed.  The assigned address block refers to the
bits as they appear on the wire(fiber, etc.).  Our address was printed in
three forms:  binary network order, 802.3 hex, and 802.5 hex.  Reversing the
bits in each byte is the correct way to go for the different network types.

BTW There was a recent tip-ip posting concerning the hardware addresses from
some well-known manufacturer's equipment which did not match the assigned
address block(perhaps AT&T?), that appeared to be a bit-reversal problem.

Hope this is helpful, and that you didn't get too many versions of this
message.

Tracy Mallory

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 15:27:23 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Net Management Tool Survey


	Network Management Tool Descriptions Wanted

The Internet Engineering Task Force (IETF) is now requesting entries
for a catalog of tools for managing TCP/IP internets.  The catalog
will be a compendium of the tools available to assist network managers
in debugging and maintaining their networks.  Network management tools
and LAN management tools (other than breakout boxes) will included.
The IETF intends to publish the catalog as an RFC.

Entries describing public domain, copyrighted, and commercial tools
are solicited.  Vendors are encouraged to submit descriptions of their
products.  Descriptions from knowledgeable users of commercial and
noncommercial tools are also welcome.

Tool descriptions should be objective, no more than two or three pages
long, and should contain the following sections (where applicable):

  1. Tool name.

  2. Key work list (for now, a best guess.  A uniform
     key-word list is under development).

  3. Abstract: a brief description of the tool's
     purpose and characteristics.

  4. Mechanism: how the tool works.

  5. Caveats: warnings about tool impact on system
     performance, etc.

  6. Hardware requirements.

  7. Software requirements.

  8. Related analysis tools: post processors, data
     reduction tools, graphics support, etc.

  9. Availability and support: how to obtain the
     tool, and whether it is in the public domain,
     copyrighted, or commercially available.  This will
     not include pricing information.

  10. Bugs and limitations.

An IETF review panel will edit all catalog entries.  Though
contributors will be given final authority to approve or disapprove
revisions to their submissions, the IETF reserves the right to exclude
entries that do not meet its editorial criteria.  Editing of the
catalog will be completed this November.

Send tool descriptions or requests for further information to:

  Robert Stine              phone: (703) 448-0210
  SPARTA, Inc.              fax:   (703) 734-3323
  Suite 1070                email: stine@sparta.com
  7926 Jones Branch Drive
  McLean, VA 22102

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 17:17:06 GMT
From:      cccar@levels.sait.edu.au (Chris Rusbridge)
To:        comp.protocols.tcp-ip
Subject:   48 Kbps SLIP?

We are thinking of offering network access to external customers via 
SLIP. This seems to be easy to achieve up to 19,200 bps using the 
Annex terminal servers and similar devices. However, we'd also like to 
be able to offer this capability at 48 Kbps. Some questions:

a) Is there anything about SLIP that makes this not a sensible choice 
at 48 Kbps?

b) Is there a better way of providing high speed network access?

c) What equipment would we need to provide this service? (The best we
have been able to come up with so far is a SUN3/150 with SUNlink/IR,
plus the fast serial interface, but that's a pretty expensive
solution. It would be cheaper by far to put a cisco Hybridge at each
end...) 

Any information gratefully accepted.

Chris Rusbridge

Academic Computing Service Manager, SA Institute of Technology
ACSnet:		Chris.Rusbridge@levels.sait.oz [.au]
InfoPSI:	Chris.Rusbridge@sait.edu.au	(DTE 505282622004)
Phone: 		+61 8 343 3098  Fax: +61 8 349 6939  
Post: 		The Levels, SA 5095 Australia

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 19:12:15 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   IP Extended Security Option (RFC 1038)

Folks,

The Extended Security Option (Type=133) looks like a good thing.  We
have gone ahead and put in the hooks required to utilize it.  However,
there are some IP routers that get bent out of shape when it arrives on
their doorstep.  In our case, Cisco routers send back an ICMP parameter
problem at Pointer=0.  Other IP routers, based on 4.3BSD route the
packets without a problem (Sun, 4.3BSD VAX, Bridge-GS7).  I gather that
there is code in the IP routers that specifically checks for types 130
and 133 and rejects them, because they do not complain about an option
such as the following:

	8f088001 00000000
	
which is a bit pattern that satisfies the criteria for an IP option that
is copied to all fragments and of variable length ( 8 octets ).  This is
the extremely little know option 15.

I have a few questions for those in the know:

1. Will the IAB include this as a recommended feature in the Official
   Protocol Standards?

2. Is there a problem with passing an IP option which is formatted correctly
   even though it is not specifically mentioned in RFC791?

3. It appears that most vendor's (Cisco, BBN, Proteon, ...) ICMP
   handlers are failing to calculate the correct pointer for problem
   packets in the Parameter Problem Message.  According to RFC792, the
   gateway or host processing the IP header that finds a problem with
   some field should return a pointer (displacement) to that field
   (such as pointer==1, if there is something wrong with the TOS field).
   Or, is it the case that the 'problem' is truly with the Version/IHL
   field?

   Anyone planing on fixing this problem?
   
   Cornett   (cpw@lanl.gov)
   
   P.S. I am now using my first name, since there are so many
        Internetists named Phil[l].  (Or, is that Internetites?)

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 19:44:47 GMT
From:      toddpw@tybalt.caltech.edu (Todd P. Whitesel)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP and clear text account/password

Why not implement it as a telnet option (UNIX-PASSWORD or something similar)?

todd whitesel
toddpw @ deimos.caltech.edu
toddpw @ caltech.bitnet

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 21:14:32 GMT
From:      baker@Vitam6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   Routers and Bridges

Someone recently placed some questions about Routers and Bridges on the tcp-ip
mailing list; I didn't receive it.  If said individual would be so kind as
to mail me a copy thereof, I will add Vitalink's two cents to the conversation.

Fred Baker
Vitalink Communications
6607 Kaiser Drive
(415) 795 6233
baker@vitalink.com

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 89 22:22:40 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE considered harmful?


   From: prisma!mo@uunet.uu.net
   Date: Tue, 30 May 89 08:07:02 -0600

   [...]  According to the advertising copy, TCP provides reliable
   virtual circuits.  In my book, knowing that the other end has
   croaked is part of the definition of "reliable."

But just because you aren't getting replies does NOT mean the other
end "croaked", just that something did.  If it's internal to the
network, it should recover and you can continue.  The indication that
the other end "croaked" is receiving a RST!  How an application deals
with being temporarily partitioned has to be up to that application.
There are just too many possibilities.
						     Since this is
   mechanism that is going to have to be reinvented by lots of
   protocols, it makes sense to get it right ONCE [...]

But there isn't one right answer so how can we "get it right ONCE"?
The whole argument here is that the BSD implementation goes against
the design of TCP in that they chose one specific requirement and
implemented a solution to it ONCE, but what I want is NOT what they
provide and what the guy in the next office wants is not what I want.
No strategy that is built into the TCP layer will be right for all
applications, and it can get in the way of applications that want some
other specific type of handling for these cases.

	[...] so people don't have to (1) reinvent all the bugs and
   (2) can just use it for what they really want to be doing.

But you don't have to break TCP (oops, I mean add to it) to prevent
people from reinventing things.  Provide them with a library of
different techniques for handling various network problems.  If I want
one of the standard techniques, I just use it.  If I want something
special, I write it (and if it's of general use, it's an addition to
the library).

	    __
  /|  /|  /|  \		Michael A. Patton, Network Manager
 / | / | /_|__/		Laboratory for Computer Science
/  |/  |/  |atton	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 01:17:53 GMT
From:      davidf@colnago.wpd.sgi.com (David Fenstemaker)
To:        comp.protocols.tcp-ip
Subject:   LOCUS PC-Interface


Has anyone had any experience with Locus Corporation's
PC-Interface product? It is used allow a DOS PC to be able
to use a Unix system as a file server. It uses Ethernet TCP/IP, UDP
or RS-232. 

You have to port some server software on the Unix side.
Has any one done this port?

Thanks.

David Fenstemaker

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 16:06:22 GMT
From:      jbvb@ftp.COM (James Van Bokkelen)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NetBIOS specification in RFC

RFC 1000 is nice, but it only summarizes what came before.  You really
want the file "rfc-index.txt" from SRI-NIC, which has everything up to
the minute (they are beyond 1100 by now).


-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 16:29:05 GMT
From:      swonk@ccicpg.UUCP (Glen Swonk)
To:        comp.protocols.tcp-ip
Subject:   PC packet monitor software

Does anyone know of a source for a PC program
that can be used as a simple packet monitor?

Something simple and with source if possible.
Ideally it should just run on any PC with a standard
Ethernet card and be able to just "capture" packets
to a destination host.

Any pointers are appreciated.

thanks,

glenn
-- 
Glenn L. Swonk		CCI Computers 
(714)458-7282		9801 Muirlands Boulevard
			Irvine, CA 92718
uunet!ccicpg!swonk

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 17:08:31 GMT
From:      tpc@bnr-fos.UUCP (Tom Chmara)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable datagram service available? (SUMMARY)

In article <526@bnr-fos.UUCP> I asked...

>Does anyone know of any
>	a) free
>	b) $$
>software which implements reliable datagram service, something like the
>	SOCK_SEQPACKET
>(sequenced, reliable, two-way connection-based byte stream for fixed-length
> datagram)
>described in the literature?

"DID WE GET LETTERS!?!"
To summarize:
	- I asked for the wrong thing, though many people figured out what
	  it was I wanted vs asked for.  As Craig Partridge & jqj@hogg
	  were so kind as to point out, with admirable restraint..
	  (jqj's words):

		"You asked about both RDP and sequenced packet protocols.
		4.3BSD supports a sequenced packet protocol, SPP, in the
		XNS domain.  A reliable SPP carries almost all of the baggage
		(except fragmentation/reassembly) that a TCP stream does i.e.
		is just as expensive.  All it does is *in addition to providing
		a stream* provides information to the client on packet
		boundaries.  Not what you want."

	  What I WANTED was reliable datagrams.  (Craig Partridge HAS a
	  sequenced packet protocol:  RDP, for those who might want it; contact
	  him at craig@nnsc.nsf.net).

	- I heard about TWO reliable datagram protocols.  One is eXpress
	  Transfer Protocol (XTP).  Rex Buddenberg (budden@manta.nosc.mil)
	  described it as follows:

		"Not exactly free, and not exactly here yet either...but.
		Reliable datagram service isn't as easy as it sounds at first
		encounter.  First, consider how TCP handles things:
			<description left out>
		Note that you've burned up 9 packets in order to get one packet
		through the system.  Further, the data packet is the fourth one
		in line -- if latency is a concern (and in tactical applications
		it most definitely is), then you've eaten up a lot of overhead
		before you get real performance.

		What we are currently latched onto is eXpress Transfer Protocol.
		XTP allows the connection open, the data and the connection
		close to all go in the very first packet.  So you get out with
		a grand total of 3 packets for guaranteed delivery; and the
		data goes in packet #1 now.

		XTP is being build by Protocol Engines Inc in Santa Barbara.
		They intend to embed it in a chipset in a year or so.  In the
		meantime, some beta sites are running C versions.  If you are
		looking for a 'today' answer this isn't it, but next year..."

	 I heard from many people about the second reliable datagram protocol:
	 Guy Middleton won with being first here; jqj@hogg, dave crocker
	 (dcrocker@ahwahnee.stanford.edu) also replied.  Sorry if I missed
	 anyone...  The protocol is VMTP ( Versatile Message Transport
	 Protocol) and is described by RFC 1045.
	
	 The abstract for RFC 1045 describes VMTP as
		"a transport protocol specifically designed
		to support the transaction model of communication, as
		exemplified by remote procedure call (RPC).  The full function
		of VMTP, including support for security, real-time, asynchronous
		message exchanges, streaming, multicast and idempotency,
		provides a rich selection to the VMTP user level.
		Subsettability allows the VMTP module for particular
		clients and servers to be specialized and simplified to the
		services actually required."
	
	VMTP is layered atop IP; i.e. is a peer protocol to UDP and TCP.  The
	VMTP README file for the second release notes that VMTP
		"is available for "Sun-3, Sun-4, Vax, and DEC mips architecture
		machines"

	VMTP is available from Stanford University Distributed Systems Group.
	If you wish to be added to the VMTP mailing list, drop a line to
	vmtp-ip-request@gregorio.stanford.edu.  Postings to the mailing list
	are sent to vmtp-ip@gregorio.stanford.edu.
	I do not know any details regarding licensing for educational or
	commercial use.

Thanks to all who responded; if I've missed your name in the above credits,
please accept my abject apologies.  Response to my question was as always
quick, insightful, and clear.  Thanks again.
	---tpc---
-- 
I am sole owner of the above opinions. Licensing inquiries welcome.
------------------------------------------------------------------------
Tom Chmara			UUCP:  ..utgpu!bnr-vpa!bnr-fos!tpc
BNR Ltd.  			BITNET: TPC@BNR.CA

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 18:18:47 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   Release 3.x of the Clarkson packet driver

In article <244@opus.NMSU.EDU> rocks@nmsu.edu (Dave Rocks) writes:

   	I need a packet driver for 3C523mc adapter for NCSA TELNET and
   	NOVELL.

You and about a billion other people.   Anyway, release 3.x of the
Clarkson packet driver collection is now available.  The READ.ME file
appears below.

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, and by modem.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc
flash.bellcore.com:/pub/ka9q/drivers.arc
louie.udel.edu:/pub/ka9q/drivers.arc

(On these last two, look in /pub first -- I had to ask the sysadmins to
move the drivers to /pub/ka9q, and they may not have gotten around to it.)

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	send ka9q drivers01

Repeat for drivers02, drivers03, and drivers04.  Combine the four parts
and unarchive it.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

Opus:

260/360 in the Nodelist.  Drivers.arc is file requestable.




		Release 3.0 of the Clarkson packet drivers

If you are a user, all you need do is locate the correct packet driver for your
interface, and read DRIVERS.DOC.


Enclosed you will find

3C501.ASM     Device dependent 3COM 3C501 code.
3C501.COM     Executable for a packet driver for the 3COM 3C501.
3C503.ASM     Device dependent 3COM 3C503 code.
3C503.COM     Executable for a packet driver for the 3COM 3C503.
3C523.ASM     Device dependent 3COM 3C523 code.
3C523.COM     Executable for a packet driver for the 3COM 3C523.
DEFS.ASM      Definitions and macros.
DRIVERS.DOC   User documentation.
GENERIC.ASM   Device dependent generic code (a skeleton only).
HEAD.ASM      Resident device independent generic code.
MAKEFILE      Makefile.  Uses tasm and tlink, but MS may work.
NI5010.ASM    Device dependent Interlan NI5010 code.
NI5010.COM    Executable for a packet driver for the Interlan NI5010.
NI5210.ASM    Device dependent MICOM-Interlan NI5210 code.
NI5210.COM    Executable for a packet driver for the MICOM-Interlan NI5210.
PACKETQA.TXT  Questions from R. Nelson and Answers from jbvb@vax.ftp.com
PACKET_D.108  Packet driver spec version 1.08
READ.ME       This file.
README.503    Bob Clements' README file for the 3c503.
SLIP8250.ASM  Device dependent SLIP driver using IBM-PC 8250.
SLIP8250.COM  Executable for a SLIP packet driver for the IBM-PC 8250.
TAIL.ASM      Non-resident device independent generic code.
WD8003E.ASM   Device dependent Western Digital WD-8003e code.
WD8003E.COM   Executable for a packet driver for the Western Digital WD-8003e.

I have been in a quandry for some time about the credit that I should take
for these packet drivers.  I created the infrastructure for the packet
drivers, but all of the device dependent portions were written by other
people.  So I feel uncomfortable about taking all the credit.  Probably
the best term to describe what I do is "Editor and publisher", because I
perform a function similar to that served in the literary world.  So, I
sign myself,

	Russell Nelson, Editor of the Clarkson packet drivers.
	nelson@clutx.clarkson.edu, nelson@clutx.bitnet

Changes from version 2.0 to 3.0 of the drivers:

NOTE: Only the SLIP8250, NI5210, and 3c523 drivers have been tested.  All
     others are believed to work.

GNU General Public License adopted.  The restriction on commercial usage
     prevented some companies from distributing the packet drivers.  This
     is entirely my idea, so send any comments to nelson@clutx.clarkson.edu.
3c523 driver added, thanks to Dan Lanciani (ddl@harvard.edu).
Gregg Stefanik (wstef@eng.clemson.edu) is working on a 3c505 driver.  Don't
     bug him about it unless you're willing to be a alpha tester.
User documentation added (DRIVERS.DOC).
Brad Clements (no relation to Bob Clements) fixed the NI5210 driver so that
     it will work with a MTU of 1500.
The NI5210 now checks for shorts and opens before it starts up, thanks to
     Brad.
All memory-mapped packet drivers now check the packet length in send_pkt to
     ensure that too-long packets get trapped.  All packet drivers will
     work with MTUs of 1500 (plus 14 bytes of Ethernet header).
Deborah Swanberg noticed that attach_type was returning NO_CLASS
     when it meant to return NO_TYPE.
She also noted that packet drivers weren't returning unique handles.  This
     is only a problem with Phil Karn's code, as his code directs *every*
     packet driver to the same receiver routine.  With non-unique handles,
     it was impossible to tell which packet driver was upcalling the
     receiver.  Unique handles are now generated, based on the starting
     segment of the driver.  The latest version of Karn's code uses different
     receiver routines, so the code to implement this will eventually go away.
Tail.asm now prints the Ethernet address of the interface (if it is an Ethernet
     class device)
Micom has sold Interlan, and Racal has bought it, so perhaps the NI5210 is
     now the Racal-Interlan NI5210?
If anyone is interested in using the Zenith Z-100 with a SLIP packet driver, please
     send me (Russell Nelson) mail.  I have it partially written, but will
     probably never use it myself.
WD8003E and 3c503 sped up slightly -- stole movemem from NI5210.


Changes from version 3 to 2.0 of the drivers:

Version numbering now changed.  If the skeleton changes, the major version is
     incremented and all the minor versions are reset to zero.

Support for version 1.08 of the packet driver spec included.
Bob Clements' 3c503 driver added.  See README.503.
Some comments improved.
BAD_COMMAND checking code fixed.
cld instructions added to ensure that DF=0.
NI5210 sped up slightly -- look at movemem in ni5210.asm for an especially
     fast routine to move memory around.


Changes from version 2 to 3 of the drivers:

SLIP8250 can now be one of three classes: SLIP, AX.25, and KISS.
Tail.asm now checks for a packet driver already at the given interrupt.
Tail.asm now echoes its arguments in hex and decimal.
Tail.asm will close stdout so that a file handle won't be used up in
     case the user redirects stdout to NUL.
Head.asm now supports driver termination.
Termin.com added to terminate a driver.
Head.asm now does a stack swap to avoid pushing too many things when
     interrupting MS-LOSS.


Changes from version 1 to 2 of the drivers:

!!  Arguments are now in decimal by default  !!  Use a 0x prefix for hex.

DEFS.ASM created.
The loadport macro improved.
SLIP8250 driver added, thanks for a C version from Phil Karn.
     I've tried to put some 16550 support in, but I don't have one to
     test it with.  The documentation insists the TBRE goes low when
     the transmit buffer is not empty, while it makes sense for it to stay
     high while the buffer is not full.  I suspect the documentation is
     wrong.
NI5010 driver added, thanks for a C version from Bill Doster.
WD8003 driver added, by Bob Clements.
Loadport macro added to WD8003 driver by Russell Nelson.
Numeric arguments may now be specified in octal, decimal or hex, using the
     C notation.
Numeric arguments can now use up to 32 bits.
Source files reformatted.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
I'm a right-to-lifer -- everyone has a right to earn a living sufficient to
feed himself and his family.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 18:30:02 GMT
From:      hwajin@wrswrs.UUCP (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

In article <111@xicom.UUCP> alex@xicom.UUCP (Alex Laney) writes:
>
>	RPC is a standard part of NFS, no? I recall (faintly) somewhere that
>Interactive advertised this as part of their NFS product.
>
>	I have a copy of their Host-based TCP-IP, and the RPC3.9 source code.
>My experience is that with modification of the headers, I could get it to
>compile, but it would crap-out at run-time. This was a few months ago, so I
>don't recall the exact error. I will be trying again soon, however.

If you have their NFS for the SVR3 UNIX and TCP/IP (probably Lachman derived),
you should be able to use RPC3.9 with minor modifications.  

RPC implementation is, in a way, duplicated in most Unix implementations
-- the one in the kernel code which is being used by NFS and linked 
into the kernel itself usually and the one that is provided as user
level library for application use.  Since RPC library used in normal
application programs are built entirely on top of socket library you
should have no problem if you have a compatible 4.3 BSD TCP/IP and socket
library with your system, which I assume you do.  If your TCP/IP doesn't
implement all necessary socket calls, socket options, and ioctl's 
you may run into some problems.  What kind of modifications did you have
to make to the header files?


-- 
{uunet,rtech,sun}!wrs!hwajin  bae@tis.llnl.gov  hwajin@wrs.com

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 18:53:11 GMT
From:      baker@Vitam6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   Bridges and Address Filtering

This is a reply to Steve Elias' question concerning Bridges and Address
Filtering.  Vitalink uses several different approaches to Address Filtering
based on the needs of the algorithm involved, some of which are software
based and some of which are hardware based.

The simplest and most effective software algorithms that we have found
capitalize on the fact that most vendors implement some sort of serial
number in the vendor-specific field of the Ethernet Address.  A few
examples:
	U/B Address:	00-DD-00-xx-xx-00  where xx-xx is a number
	DECNET IV:	AA-00-04-00-xx-yz  where y is AREA and zxx is NODE
					     (approximately)
	3COM Address:	09-00-02-xx-xx-xx  where xx-xx-xx is a big-endian
	                                     integer

Net net is that if aa-bb-cc-dd-ee-ff is an Ethernet Address, -ee- is the
most commonly "different" octet, and -ff follows close behind.  Hashes that
include them generally work pretty well.  Lookup tables that have no hash to
jump start them don't work for beans, and even in hashed lookup tables, this
word should be compared against first. One of our algorithms, used to
quickly discard local traffic, can discard at LAN speed even on a 10 MHz
68010, so software approaches should not be discounted out of hand.

Hardware approaches generally fall into two categories:  Associative Content
Addressable RAMs (CAMs) such as AMD's, and lookup engines.  Vitalink uses a
lookup engine in our TransRING (Transparent Token Ring) Bridge, and that
works pretty well.  The problem with the TI Chipset is that it can only
process a very limited number of frames per second, so any help one can give
it in knowing what it can safely ignore is helpful. Ethernet controllers are
generally more capable, so discarding before or after the controller is more
a question of what MIPS rating one is willing to pay for, and how that trades
off against the cost of the lookup engine.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1989 23:00-EDT
From:      CERF@A.ISI.EDU
To:        m.cs.uiuc.edu!zweig@UXC.CSO.UIUC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP socket ambiguity?
The two sockets (on different IP addresses) should be
considered distinct.

Vint Cerf
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 20:27:39 GMT
From:      latzko@pilot.njin.net (Alex )
To:        comp.protocols.tcp-ip
Subject:   Re: LOCUS PC-Interface

In article <34862@sgi.SGI.COM> davidf@colnago.wpd.sgi.com (David Fenstemaker) writes:

> Has anyone had any experience with Locus Corporation's
> PC-Interface product? It is used allow a DOS PC to be able
> to use a Unix system as a file server. It uses Ethernet TCP/IP, UDP
> or RS-232. 
In the long distant past this product was supported by ATT as their
answer to PC-UNIX networking.  It ran using a weird and propriety
protocol known as 3BNet.  It was usable but only just!  

Seriously, ATT dropped support for it ( at version 2.80 ) and as is
quite reasonable LOCUS wanted a real amount of real money to support
it.  The only fly in the ointment is they couldn't supply a TCP/IP
version for the ATT servers we have ( and bletch are still using until
the 386 boxes which are going to replace them are on line ) due to
some contract weirdness.

The biggest win it had was in the way it mounts disks.  The down side
is you are only able to mount one disk at a time in the versions I
have seen. (the last version I have personally used is V2.85.)  The
biggest loss is the way it deals with printing.  It doesn't print
until you exit an application ( unless it is MS-Word which knows how
to deal with weird networking code .)

Naturally, it doesn't support NETBIOS ( why should it ? )

I have seen and used the TCP/IP version and it does work as
advertised, but are you really sure a version of NFS ( either PC-NFS
from SUN or InterDrive from FTP Inc ) wouldn't be a better choice.

Just for the record the redirector in SUN PC-NFS is based on the LOCUS
product. The guts of MERGE/386 (from LOCUS) is as far as I know also
based on the PCI redirector.

Currently, PCI is available as a supported product from Pyramid, IBM
and ( I think ) DEC.

> 
> You have to port some server software on the Unix side.
> Has any one done this port?
 This normally comes as part of the package.  LOCUS does this.
> 
> Thanks.
 Yer Welcome,
> David Fenstemaker

As always if I have made a mistake I am sure someone will unleash
vicious ( or even friendly ) flames in my direction with corrections.

Cheers
/S*
latzko@rutgers.edu

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 21:23:51 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   real sloooww local mail with internet link down


	Whenever our link to the outside world goes down, local mail gets
real slow (like messages spending over 30 minutes to an hour in the
sendmail queue).  We're running sendmail 5.59 with the IDA enhancements and
bind 4.8.  I suspect that what is happening is that our named is trying to
contact some outside named to resolve an address and timing out, but I
don't see why it should do that on local addresses.  Apparantly, whatever
it is, it's not critical because eventually the mail does get delivered.

	Can somebody give me some hints as to what might be happening and
how to prevent it?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 21:55:02 GMT
From:      frg@jfcl.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

This is probably a stupid question since I'm not familiar with the way
different systems (ie BSD) implement TCP timeouts.  But wouldn't the
problem of dissimilar systems (ie, AX.25 on one end and Cray on the
other) still be solvable by basing the timeout on the smoothed round
trip time (srtt)?  If the keepalive timer were some significant multiple
of srtt (or longer, if srtt is short) then it would still scale.

Proper behavior, of course, is still open to debate -- whether the
application or TCP should do the teardown.  I'm not joining in...
       fred 

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 22:03:21 GMT
From:      news@comp.vuw.ac.nz (News Admin)
To:        comp.dcom.lans,comp.sys.mac,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Backup via network, request for info.


    I posted this request for information about two weeks ago with no reply
from the net.  It is possible that my posting went to the bit bucket so I
am reposting it.  I apologise if you have seen this already.
--

    We have recently invested in a campus wide network.  At the moment 
the network is Ethernet running on optical fibre, in the future we hope 
to upgrade this to FDDI.

    One of the services we hope to offer users of the network is remote
backup of their personal computers, file-servers, departmental computers 
etc, onto our central machine(s) with disk farm(s) attatched.  

*Question*:  Is there any software out in netland that exists, or is being 
developed that does this sort of thing?  

    Software using TCP/IP would be of the most interest to us, however info. 
on any software would be appreciated.  If there is no software out there at 
all we are considering developing the software.

*Questions*:  If we were to develop our own software, what functions, apart 
from full and partial backup/restore, would people like to see in such a 
system?  Are there other people/organisations, out there, who would be 
interested in a backup system like this?

    If we were to "roll our own" the intitial environment would probably 
be a Unix server backing up, Macs on appletalk via Kinetics/Multigate, IBM PC
clones and Unix workstations on Ethernet.
    Software that we know about is by Dan Tappan, at BBN Corporate Computer
Resource Centre.  This software backs up a Mac via a Kinetics FastPath 
bridge to a Unix machine running CAP.
    Replies via email please.  If there is enough response I will post a
summary.  Many thanks in advance ...

Tony Martindale                            Computing Services Centre,
Domain: tony@rata.vuw.ac.nz                Victoria University of Wellington,
Path: ...!uunet!vuwcomp!rata!tony          P.O. Box 600,
Tel: +64 4 721-000  Fax: +64 4 712-070     Wellington, New Zealand.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 89 23:28:37 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

Sorry, I can't let this go by without commenting on Phil's message
and this discussion, even though the discussion has mostly died down.
(I haven't been reading tcp-ip very often, but noticed this subject
line going by.)

Last time Phil and I talked about keepalives in person, I asked him
whether he had problems with telnet/rlogin servers accumulating on
his systems if they didn't use keepalives.  We certainly accumulate
junk, including xterm programs, waiting for input from a half-open
connection.  Phil told me that he doesn't have problems, because
he runs a "wall" every night to force output to all users, and of
course breaking connections that time out.  In other words, Phil
violently objects to servers requesting keepalives from TCP, but
allows the system manager (himself) to force them above the application
level.  And before people jump up to point out the difference in time
scales, the current BSD code sends no keepalive packets until a connection
has been idle for 2 hr, and that interval is easily changeable.
One proposal for the Host Requirements document was to wait for 12 hr.
I think that's a bit high, but the difference is only a factor of 6.
Compare the number of keepalive packets with the number of packets
exchanged by an xterm and an X server over the course of a week
if used 4 hours a day!

Phil says:
	... I'd go a little further, though,
	and say that a REMOTE USER (not just the application code) must always
	be able to turn off keepalives, even on binary-only systems. It does no
	good to say "the application must be able to disable keepalives" when
	I'm having problems with a remote server that I have no administrative
	control over.

I'm sorry, Phil, but remote users have no more right to override system
management policies than do local users (at least on *our* systems!).
On some of the systems where I have guest accounts, local or remote
users are logged off if they aren't active for two hours.  I don't like
that, either, but I don't claim that the managers of those systems
have no right to enforce such a policy.

		Mike

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 02:20:44 GMT
From:      karl@giza.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: real sloooww local mail with internet link down

roy@phri.UUCP writes:
   Whenever our link to the outside world goes down, local mail gets
   real slow (like messages spending over 30 minutes to an hour in the
   sendmail queue).
   ...
   Can somebody give me some hints as to what might be happening and
   how to prevent it?

What is probably happening is that your mailer is timing out on every
single request made of your nameserver, because your nameserver is
occupied with timing out in attempts to do things like check with
primaries for status of its secondary zone dumps.  While the
nameserver is so occupied, it won't pay any attention to ordinary
requests from the mailer.

The solution to your problem is probably to install the asynchronous
zone transfer stuff that has been discussed from time to time;
probably your best bet is to bring up UToronto's modified BIND, which
has all the good bug fixes + async zone xfer + a few bazillion other
neat features.  (I haven't brought it up yet myself, but our
connection to the outside world has been so stable that it is only in
the most rare circumstances that I have anything to worry about.)

--Karl

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 03:00:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP socket ambiguity?

The two sockets (on different IP addresses) should be
considered distinct.

Vint Cerf

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 03:24:14 GMT
From:      gary@SALT.ACC.COM (Gary Krall)
To:        comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering

>Date: 31 May 89 22:43:45 GMT
>From: robert@g.ms.uky.edu  (Robert Lee)
>Organization: U of Kentucky, Communications Services, Networking.
>Subject: Re: bridges & address filtering
>To: tcp-ip@sri-nic.arpa
>Status: R

Robert,

>With the UB DLB we can program filters bi-directionally but not 
>uni-directionally.  It would be nice if we could do this with a bridge
>also it would be *very* nice if there was a extensive set of tools that
>would work with bridges at the network management level. 

ACC's ACS 4110 (remote ethernet bridge) product implements SNMP 
management in an effort to provide some of the tools necessary to
manage bridges.  

Currently, SNMP commands are entered locally through a RS232 console
port mounted on the rear of the unit.  Through that port commands
can be issued to the local unit or to any currently accessible
remote unit.  Management stations which support SNMP (and those
ACC enterprise specific variables) could also access the units.

>For example here are some things I would like to be able to do with
>a bridge.
 
>1) Be able to tell the bridge to disconnect from a ethernet for a time
>or until I tell it to turn its packet forwarding back on.

The SNMP implementation on the ACS 4110 unit supports the ability
to disconnect or connect from a ethernet in two ways.  The first is
to disable the physical port, or alternatively the spanning tree
port (802.1) may be disabled.  In either case when the port is
enabled packet forwarding may resume.

>2) Be able to tell the bridge to forward all the packets it sees.

In a local environment this might make sense, but in a remote
environment where bandwitdh is at a premium this is not suggested.
However, the ACS 4110 can certainly be configured to disable
"learning mode" and effectively forward all packets it sees.

>3) Programmable filters that don't degrade packet forwarding 
>to any high degree.

The ACS 4110 supports filters based on the 802.1 specification;
in general the specification of arbitrary filters is not
without it's cost.  It all comes down to implementation and
capabilities of the unit.

>4) A extensive set of statistical variables.  Like # packets/sec. 
>Collision etc etc.  Also it would be nice if these results 
>could be put into a file that can be processed with statistical 
>programs like SAS or SPSS.

SNMP management supports basic data collection and control.  Some 
statistics are available to the user such as number of packets passing
through an interface.  Rather then having the unit itself calculate
statistics, a SNMP based management station could
calculate more complex statistics such as packets/sec based on
collected data and so on.

>5) Bridges usually only look at the ethernet address header and
>not what type of packet it is.  It would be nice if there was a 
>facility that allow the bridge to forward based on packet types.  
>I can do this to some extent with filters now.

I mention this above, but in addition to priority forwarding on 
protocol type the ACS 4110 can also discard by protocol.

>Anyway, that's what I would like for a bridge.   

Hope that helped.

>Robert Lee
>SYSBOB@UKCC
>University of Kentucky

Gary.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Jun 89 09:05:45 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   SNMP software for PC.
I have a few boxes on my network that collect SNMP statistics.  What I
don't have is a program that will retrieve this information and allow me
to look at it.  Does such software exist for a PC?  If so, how can I get
it?

Thanks.

--------------------------------------------------------------------
|Mike Rackley                           |  (601)325-2942           |
|Mgr. Systems & Networks Programming    |  Rackley@MsState.BITNET  |
|Mississippi State University           |  Rackley@CC.MsState.EDU  |
--------------------------------------------------------------------
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Jun 89 15:50:09 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        jarvis.csri.toronto.edu!utgpu!utzoo!bnr-vpa!bnr-fos!tpc@rutgers.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Reliable datagram service available? (SUMMARY)
Your quotation of Rex Buddenberg's comment that TCP requires a minimum of
9 packets to deliver one did not ring true, so I did a little background
querying.  At the moment, the contest is between 3 and 5 packets, but
certainly not 5.  (Just is case anyone thinks that this note is trying
to suggest that a reliable datagram protocol is not a good idea, don't.
It's only that 9 is such a high number, it makes TCP look unreasonable.)

The theory that suggests 3 packets says that the originator sends
a packet that contains an open(SYN), close(FIN), and the data.  The
receiver returns a packet that contains a a SYN/FIN/ACK, and the
original host then returns an ACK.  (3-way handshake.)

Dave
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 14:05:45 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   SNMP software for PC.

I have a few boxes on my network that collect SNMP statistics.  What I
don't have is a program that will retrieve this information and allow me
to look at it.  Does such software exist for a PC?  If so, how can I get
it?

Thanks.

--------------------------------------------------------------------
|Mike Rackley                           |  (601)325-2942           |
|Mgr. Systems & Networks Programming    |  Rackley@MsState.BITNET  |
|Mississippi State University           |  Rackley@CC.MsState.EDU  |
--------------------------------------------------------------------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 14:13:48 GMT
From:      jtkohl@ATHENA.MIT.EDU (John T Kohl)
To:        comp.protocols.tcp-ip
Subject:   TROFF or TeX macros for RFC's?

Does anybody have TROFF macros for generating RFC's?  [The stuff I need
most is for generating the standard +---+ style boxes for network
protocol descriptions].

Please send information (NOT macros yet) to me.

Thanks,

John Kohl <jtkohl@ATHENA.MIT.EDU>
Digital Equipment Corporation/Project Athena

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 18:24:13 GMT
From:      mahoney@ssgp32.UU.NET (Mike Mahoney)
To:        comp.protocols.tcp-ip
Subject:   net_tool for TCP/IP



I am interested in obtaining information regarding the functionality, cost
(if any), etc. of 'net_tool' a software package that manages and monitors
machines and network usage utilizing a Sun workstation. I have called Sun 
but they don't know anything about it (according to the person that I spoke 
with). I also checked an issue of Catalyst and couldn't find anything in 
there. If anybody out there in netland has used, or is familiar with, this 
software I would love to here from them. Specifically:

	1.	Is the software in the public domain? If not, where can
		I obtain the details on it?

	2.	Is there a version of the software available for System V
		(possibly running under X windows) or is it written
		specifically for Sun Windows?

	3.	What similar products are available, public domain or 
		otherwise?


Replys can be e-mailed to me (mahoney@ssgp62.Prime.COM) or mailed by land. 
I will summarize for the net in I get enough response. Thanks in advance.


				Mike Mahoney
				Prime Computer
				Technology Drive, MS 23A-34
				Milford, MA  01757

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 89 22:50:09 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable datagram service available? (SUMMARY)

Your quotation of Rex Buddenberg's comment that TCP requires a minimum of
9 packets to deliver one did not ring true, so I did a little background
querying.  At the moment, the contest is between 3 and 5 packets, but
certainly not 5.  (Just is case anyone thinks that this note is trying
to suggest that a reliable datagram protocol is not a good idea, don't.
It's only that 9 is such a high number, it makes TCP look unreasonable.)

The theory that suggests 3 packets says that the originator sends
a packet that contains an open(SYN), close(FIN), and the data.  The
receiver returns a packet that contains a a SYN/FIN/ACK, and the
original host then returns an ACK.  (3-way handshake.)

Dave

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jun 89 08:34:23 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        dcrocker@ahwahnee.stanford.edu, stev@vax.ftp.com, tcp-ip@sri-nic.arpa
Subject:   Re: SO_KEEPALIVE considered harmful?
Steve,

Let me try, one last time:

If the application can direct TCP as to the periodicity and the action
to be taken (notify application vs. abort connection) then the application
will not abort your connection unless the application programmer decided
to force that condition.  Under proper design, the programmer will give the
user a switch to set, indicating something about the "persistance" that
is desired.

With respect to having the mechanism in tcp or the application, I agree with
you, philosophically, that the mechanism should be in the application (although
I believe the OSI model would put it into the session layer, but that seems
mostly to be part of the application process, these days.

The major issues, however, are kernel vs. user space, and additional
complexity to the application protocol.

There is a remarkable economy that derives from puting this mechanism
into the kernel/transport system.  It may be an accident that TCP does
not have the mechanism but can be tricked into creating one, but it still
is remarkably simple.

Most application protocols have very simple interaction styles and tend to
be relatively easy to program.  To force time-based generation of action
would complexify these protocols significantly.

Dave
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 89 02:09:47 GMT
From:      philf@lindy.Stanford.EDU (Phil Fernandez)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Looking for P.D. TCP/IP for PS/2 - OS/2 EE


I'm trying to find a (hopefully public domain) implementation of
TCP/IP for an IBM PS/2 (386 processor) running OS/2 EE 1.1.  I'd like
to use it with a 3Com 3C523 board.  Can anyone help me find such an
animal?  I'd also appreciate pointers to non-public domain
implementations for the same environment).

Please mail directly to me:

Phil Fernandez
Metaphor Computer Systems
Mountain View, CA

philf@lindy.stanford.edu
{...sun}!lindy.stanford.edu!philf

Thanks!

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Jun 89 16:48:38 EDT
From:      rayan@ai.toronto.edu (Rayan Zachariassen)
To:        comp.protocols.tcp-ip
Subject:   SLIP sliding away...

People interested in running SLIP under SunOS 4.0 may wish to retrieve the
file pub/slipware.tar.Z by anon. FTP to ai.toronto.edu (128.100.1.65):

-rw-r--r--  1 root       756689 Jun 10 16:20 slipware.tar.Z

This is a collection of tar files that should be "everything you would
ever need to run SLIP on a Sun".  The individual components are also
available in the same location:

-rw-r--r--  1 root       297054 Jun 10 16:19 gated.tar.Z
-rw-r--r--  1 root        27125 Jun 10 16:19 slip-3.x.tar.Z
-rw-r--r--  1 root        25933 Jun 10 16:19 slip-4.0.tar.Z
-rw-r--r--  1 root        87827 Jun 10 16:19 tip.tar.Z
-rw-r--r--  1 root       307534 Jun 10 16:19 yapt5.5c.tar.Z

The :readme file from slipware.tar:
-------------------------------------------------------------------------

Files in this collection (890610):

gated.tar	- GATEway Daemon (1.9.1.3)
slip-3.x.tar	- SLIP for SunOS 3.x
slip-4.0.tar	- SLIP for SunOS 4.0 (1.14)
tip.tar		- TIP w/ SLIP support
yapt5.5c.tar	- SunOS 4.0.[012] serial line patch tape (by permission)

-------------------------------------------------------------------------
Note that gated, slip*, and tip, are all publically redistributable, and
the Sun YAPT5.5c patch tape contents are included by OK from Sun people.

I consider this version of SunOS 4.0 STREAMS SLIP to be Release quality.

It is highly unlikely there are bugs in it, so before you send me mail
about something please double check yourself, or use other resources.

I will NOT send out copies by mail, but am sending the SLIP and TIP
packages to comp.sources.unix for posting.  Perhaps slipware or components
will show up at various archive servers.

If you wish to contribute improvements or send an electronic postcard, I'm

Rayan Zachariassen <rayan@ai.toronto.edu>


Yours for Better connectivity through SLIPpage.

rayan


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 89 15:34:23 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

Steve,

Let me try, one last time:

If the application can direct TCP as to the periodicity and the action
to be taken (notify application vs. abort connection) then the application
will not abort your connection unless the application programmer decided
to force that condition.  Under proper design, the programmer will give the
user a switch to set, indicating something about the "persistance" that
is desired.

With respect to having the mechanism in tcp or the application, I agree with
you, philosophically, that the mechanism should be in the application (although
I believe the OSI model would put it into the session layer, but that seems
mostly to be part of the application process, these days.

The major issues, however, are kernel vs. user space, and additional
complexity to the application protocol.

There is a remarkable economy that derives from puting this mechanism
into the kernel/transport system.  It may be an accident that TCP does
not have the mechanism but can be tricked into creating one, but it still
is remarkably simple.

Most application protocols have very simple interaction styles and tend to
be relatively easy to program.  To force time-based generation of action
would complexify these protocols significantly.

Dave

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 89 18:46:39 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP specmanship?

Frank,

Let me know who the vendor is.  I'll spread the word to boycott them
hear at LANL.

Cornett

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 89 20:17:37 GMT
From:      paul@UXC.CSO.UIUC.EDU ("Paul Pomes ", I'm the NRA!)
To:        comp.protocols.tcp-ip
Subject:   Background FTP

BFTP is available for anon-FTP from venera.isi.edu in /pub/BFTP.201.tar.Z .

/pbp

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 89 04:31:10 GMT
From:      tmac@macvax.engin.umich.edu
To:        comp.protocols.tcp-ip
Subject:   Re: background ftp

>	Hi there,
>	I was looking for the source file of bftp- background ftp- which I
>	believe allows the user to do 'other things' while files are being
>	ftp'ed over.  Could someone email me the file or tell me where it is
>	available.
>	Thanks in advance
>	Roy George

It's availiable via anonymous ftp to uxc.cso.uiuc.edu.  The
compressed tar file is in net/BFTP.12.tar.Z, and the individual
files are also in net/bftp.

	_Tom

***************************************************************************
Tom McLeary                             BellNet: (313) 936-8039
UNIX System Administrator               ARPANet: tmac@caen.engin.umich.edu
Computer Aided Engineering Network      NoNet  : is good net.
229 Chrysler Center                     HairNet: keeps hair out of coffee.
University of Michigan                  FishNet: on the weekends.
Ann Arbor, MI   48109

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 89 23:04:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Super-Dumb Transport Protocol?


  Is there a protocol out there (possibly one for which an RFC is still
forthcoming) that is designed to do file-transfer from a server to a
client at minimal computational cost? That is, a protocol that just involves a
client sending a reqest which, if received by the server, generates a bunch of
IP datagrams in response (maybe with a terribly naive checksum/retransmit
of lost/damaged packets mechanism).

  FTP has far too much baggage -- sitting as it does on top of TCP -- and
TFTP is close, but still sits on top of UDP. I was thinking of an utterly
mindless protocol so I can run it on a PC which has some archival files
on a hard disk and whenever somebody wants a copy of one, they basically
send the filename and snarf up the replies. Optimally, the PC would just
need to have IP and this snarf/barf protocol in order to be an archive
server.

  I have been toying with the idea of using a Mac or an AT as a net-accessible
archive-disk, and bringing up TCP/IP/UDP/NFS/whatever seems like way too
much work, both in terms of hacking and in terms of getting the best
performance out of the slow, dumb box. I could come up with a local kludge
for this protocol -- but if there is something like it already out there,
I would like to know.

-Johnny Streamlined/Stripped-Down

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 02:16:25 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, cccar@levels.sait.edu.au
Subject:   Re: 48 Kbps SLIP?

I don't know of anything that makes 48Kbps SLIP unworkable, assuming
that the equipment on both ends can support it.  However in general
I'd only use SLIP if the cost of real routers is too high.  There are
advantages to the more conventional synchronous protocols.  One is
that typically the synchronous controller cards will deal with a whole
HDLC packet at once, so that the load on the processor is less.
Another is that SLIP is a minimal protocol.  Most vendors' synchronous
support has provisions for detecting when the line has hung and doing
things to reset it, and also for passing multiple protocols (e.g. IP
and DECnet) on the same line.  You mention needing Sunlink/IR in order
to do this on a Sun.  We have a SLIP connection between a terminal
server and a Sun acting as a gateway, and are not using Sunlink/IR.
There's a P.D. SLIP implementation for the Sun.  However we're using
9600.  It may be that you need something more exotic at 48Kbps.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1989 0922-PDT (Monday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        Mike Brescia <brescia@bbn.com>
Cc:        AFDDN.BEACH@gunter-adam.af.mil, tcp-ip@sri-nic.arpa, customer-support@cisco.com
Subject:   Re: EGP and C-30s
Mike,
>     We're installing cisco MGS gateways at different sites on Milnet and 
>     occasionally a problem crops up with exchanging EGP updates with the
>     "new" core buttergates.  Essentially there seems to be an infinite 
>     cycling up and down between the gateways with the core never sending an 
>     update.
>
>     This gones on until the PSN (C-30) is reset, at which point updates from
>     the core begin coming in.
>     ... nothing except resetting the PSN seems tp work.
>
> This sounds like an X.25 type of problem, involving x.25 window size, x.25
> packet size, and resources in the local PSN.

	This same problem (or at least a very similar one) can occur in
1822-connected gateways, or at least it could when Stanford lost its PSN
connection in March.  At the time, cisco looked at it and Steve Atlas
put in some patches into the Butterflies to make them work properly in
passive mode, but the problem was still unsolved when the PSN's plug got
pulled.

						Philip

PS: It seems that even when things are "working" that EGP connectivity
    between ciscos and Butterflies is not as robust as one might like.
    I observe in the SRI ARPANet gateway this morning:

		neighbor      uptime     j/k
		----------------------------
		10.6.0.22       2:08       3
		10.2.0.68       2:46       2

    Ideally, one would hope that the uptime of the peer relationships
    would be roughtly equal to the uptime of the gateway (ie, 2 weeks
    instead of 2 hours) and that j/k = 4.
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 02:47:06 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   IP forwarding on Suns


>Does anyone know what the Sun default (OS3.5) is for forwarding IP packets
>when one with a different net address is received? Assume the Sun only has
>one e-net connection. (Right, it's not a gateway, but the 'foreign-net'
>packets are there, and I can't get rid of them.)

Depends on the state of the ipforwarding bit in the kernel. By default
this is on so the Sun will indeed forward the packets. To stop that
patch the word in the kernel to zero, something like (WARNING WARNING
OFF THE TOP OF MY HEAD!!!)

	% adb -k -w /vmunix /dev/mem
	ipforwarding?W 0
	$
	%

Should take effect on the next boot tho you could patch the running
image. Wait a few minutes, someone on this list will say "oh yeah" and
correct me if that example isn't quite right.

It's defined in ip_input.c (.o) in the kernel build tree, if you
patched it there it would stay patched but that might be annoying also
if you ever build machines that are supposed to act as gateways, very
mysterious months later when someone builds a kernel and it won't
forward packets, I suppose you could have both versions and use a
build script to install the right one.

	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 14:50:58 GMT
From:      oconnor@interlan.interlan.COM (Mary O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Host Requirements


Could someone please forward the Host Requirements or inform me where to
obtain access ?
Thanks.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 15:03:53 GMT
From:      kdb@intercon.uucp
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac

In article <8906021917.AA14948@anes.ucla.edu.ANES>, stan@ANES.UCLA.EDU (Stan Stead) writes:
> Could someone please mail to me possible sources for NFS for a MAC II,
> and suggestions for ethernet cards.  Thanks in advance.
> 
> Stanley W. Stead
> UCLA School of Medicine / Dept of Anesthesiology
> BELL:	(213) 206-6238
> ARPA:	ucla-an!stan@ee.UCLA.EDU
> BITNET:	ucla-an!stan@EE
> UUCP:	{randvax | ucla-cs}\
> 			    !ucla-an!stan
> UUCP:	{att|decvax}!hermix/

I don't know of anyone who has NFS running on the Mac.  I had heard that
CITI had a version that ran on the Mac, but I believe that it was funded
by Apple and is not in the public domain.  Apple has the right to commercially
ship that version or a version based on CITI code (again, I am not totally
sure of these facts, so if someone knows different please jump in).  Apple,
however, has not made any announcments that say they are going to ship it
in the near future.  I would think that they do have plans on shipping a
version sometime in the near future.  At least I hope so, we have been holding
off on doing something like this because we don't want to get caught putting
time into something that Apple is going to end up supplying for low $$.

Hope that answers you question about NFS.
--
Kurt Baumann
InterCon Systems Corporation
46950 Community Plaza
Suite 101-132
Sterling, VA 22170

Phone: 703.450.7117  FAX: 703.437.3454  AppleLink: D1988
Email: kdb@intercon.uucp

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 16:22:00 GMT
From:      almquist@JESSICA.STANFORD.EDU (Philip Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP and C-30s

Mike,
>     We're installing cisco MGS gateways at different sites on Milnet and 
>     occasionally a problem crops up with exchanging EGP updates with the
>     "new" core buttergates.  Essentially there seems to be an infinite 
>     cycling up and down between the gateways with the core never sending an 
>     update.
>
>     This gones on until the PSN (C-30) is reset, at which point updates from
>     the core begin coming in.
>     ... nothing except resetting the PSN seems tp work.
>
> This sounds like an X.25 type of problem, involving x.25 window size, x.25
> packet size, and resources in the local PSN.

	This same problem (or at least a very similar one) can occur in
1822-connected gateways, or at least it could when Stanford lost its PSN
connection in March.  At the time, cisco looked at it and Steve Atlas
put in some patches into the Butterflies to make them work properly in
passive mode, but the problem was still unsolved when the PSN's plug got
pulled.

						Philip

PS: It seems that even when things are "working" that EGP connectivity
    between ciscos and Butterflies is not as robust as one might like.
    I observe in the SRI ARPANet gateway this morning:

		neighbor      uptime     j/k
		----------------------------
		10.6.0.22       2:08       3
		10.2.0.68       2:46       2

    Ideally, one would hope that the uptime of the peer relationships
    would be roughtly equal to the uptime of the gateway (ie, 2 weeks
    instead of 2 hours) and that j/k = 4.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 16:33:47 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Hackers and Mailers and Bind


The main reason we do not like hackers is that they deprive us of
resources (either by theft or denial of service).

Mailers that result in multiple copies being re-produced in ludicrous
quantities deny service (bandwidth through network, disk space on 
mailbox host (message store), user time discarding) are half as bad as
this.

What punitive measures are to be taken against sites that do not
maintain their service MHS's properly...? 

or

what's the difference between negligence and recklessness?

cheers

jon

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 17:17:04 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: background ftp

The latest version of the source for BFTP, "BFTP.201.tar.X", is 
available via anonymous FTP from venera.isi.edu, in the "pub/" 
directory.  (The version may change from time to time.)

In addition RFC 1068, which provides a more complete description 
of BFTP, is available from the SRI-NIC, via mail or FTP.

--Annette	

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 17:52:30 GMT
From:      west@udel.EDU (James H West)
To:        comp.protocols.tcp-ip
Subject:   XTP

In article <17445@louie.udel.EDU> west@udel.EDU (James H West) writes:
>Greetings,
>
>I am currently working on a project (for the National Institute of Standards
>and Technology, they don't run News so I'm posting from an old collage 
>account) to compare/Contrast OSI Transport class 4 with a protocol called
>XTP (Defined by Protocol Engines, Inc.  The architect is Greg Chesson).
>
>XTP is suppose to occupy level three and four in the ISO OSI refernce
>model.  It is suppose to allow Real-Time communication across a network.
>
>Does anyone have some experience with XTP?
>
>Can anyone give some insights into the difference between XTP and other
>transport protocols? (such as TCP or VMTP)
>
>Has anyone had the chance to form opinions about XTP that they would care
>to share?
>
>I will post responses that are emailed to me (See the addres below),
>but I read all these news groups so email or posting makes no difference
>to me.
>
>Thanks in advance for your help:
>
>Jim West
>
>------------------------------------------------------------------------
>Jim West
>email: west@osi.ncsl.nist.gov (Work)
>       west@udel.edu	      (Personal)
>
>National Institute of Standards and Technolgy
>Building 225/B217
>Gaithersburg MD 20899
>
>Phone: (301) 975-3619
>************************************************************************
>Standard Disclaimers:
>My opinions/statements are not those of my employer or the 
>University of Delaware

Newsgroups: comp.protocols.iso
Subject: XTP and real time communication
Summary: 
Expires: 
Sender: 
Reply-To: west@udel.EDU (James H West)
Followup-To: comp.protocols.iso
Distribution: usa
Organization: University of Delaware
Keywords: XTP, Transport class 4

Greetings,

I am currently working on a project (for the National Institute of Standards
and Technology, they don't run News so I'm posting from an old collage 
account) to compare/Contrast OSI Transport class 4 with a protocol called
XTP (Defined by Protocol Engines, Inc.  The architect is Greg Chesson).

XTP is suppose to occupy level three and four in the ISO OSI refernce
model.  It is suppose to allow Real-Time communication across a network.

Does anyone have some experience with XTP?

Can anyone give some insights into the difference between XTP and other
transport protocols? (such as TCP or VMTP)

Has anyone had the chance to form opinions about XTP that they would care
to share?

I will post responses that are emailed to me (See the addres below),
but I read all these news groups so email or posting makes no difference
to me.

Thanks in advance for your help:

Jim West

------------------------------------------------------------------------
Jim West
email: west@osi.ncsl.nist.gov (Work)
       west@udel.edu	      (Personal)

National Institute of Standards and Technolgy
Building 225/B217
Gaithersburg MD 20899

Phone: (301) 975-3619
************************************************************************
Standard Disclaimers:
My opinions/statements are not those of my employer or the 
University of Delaware

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 17:56:17 GMT
From:      west@udel.EDU (James H West)
To:        comp.protocols.tcp-ip
Subject:   Re: XTP


Sorry about the mess in the previous posting.  I'm still learning
about this software.

Jim West

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Jun 89 17:33:47 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Hackers and Mailers and Bind

The main reason we do not like hackers is that they deprive us of
resources (either by theft or denial of service).

Mailers that result in multiple copies being re-produced in ludicrous
quantities deny service (bandwidth through network, disk space on 
mailbox host (message store), user time discarding) are half as bad as
this.

What punitive measures are to be taken against sites that do not
maintain their service MHS's properly...? 

or

what's the difference between negligence and recklessness?

cheers

jon
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 21:38:05 GMT
From:      jkrey@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   RFC1102 Now Available



----- Begin Forwarded Message -----

From jkrey@venera.isi.edu Wed May 10 17:14:53 1989
Posted-Date: Wed, 10 May 89 16:14:47 PST
Received-Date: Wed, 10 May 89 17:14:51 -0700
Message-Id: <8905110014.AA29023@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.61/5.51)
	id <AA29023>; Wed, 10 May 89 17:14:51 -0700
To: Request-for-Comments-List:;
Subject: RFC1102 Now Available
Cc: jkrey@venera.isi.edu
Reply-To: jkrey
Date: Wed, 10 May 89 16:14:47 PST
From: Joyce K. Reynolds <jkrey@venera.isi.edu>
Status: RO


A new Request for Comments is now available from the Network Information
Center in the online library at SRI-NIC.ARPA.

	RFC 1102:

        Title:      Policy Routing in Internet Protocols    
       	Author:     D. Clark
	Mailbox:    ddc@LCS.MIT.EDU
	Pages:      22
	Characters: 59,664 

		pathname: RFC:RFC1102.TXT

The purpose of this RFC is to focus discussion on particular problems
in the Internet and possible methods of solution.  No proposed
solutions in this document are intended as standards for the Internet.
Distribution of this memo is unlimited.

RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname
RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC.  Log in
with FTP username ANONYMOUS and password GUEST.  The NIC also provides
an automatic mail service for those sites which cannot use FTP.  Address
the request to SERVICE@SRI-NIC.ARPA and in the subject field of the
message indicate the RFC number, as in "Subject: RFC nnnn".

Requests for special distribution should be addressed to either the
author of the RFC in question or to NIC@SRI-NIC.ARPA.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to POSTEL@ISI.EDU.

Requests to be added to or deleted from this distribution list should be
sent to RFC-REQUEST@SRI-NIC.ARPA.

Joyce K. Reynolds





----- End Forwarded Message -----

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 89 21:39:13 GMT
From:      jkrey@VENERA.ISI.EDU (Joyce K. Reynolds)
To:        comp.protocols.tcp-ip
Subject:   RFC1103 Now Available


A new Request for Comments is now available from the Network Information
Center in the online library at SRI-NIC.ARPA.

	RFC 1103:

        Title:      A Proposed Standard for the Transmission of
                    IP Datagrams over FDDI Networks
       	Author:     D. Katz
	Mailbox:    Dave_Katz@um.cc.umich.edu
	Pages:      9
	Characters: 19,439

		pathname: RFC:RFC1103.TXT

This RFC specifies a method of encapsulating the Internet Protocol (IP)
datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber
Distributed Data Interface (FDDI) Networks.  This RFC specifies a proposed
protocol standard for the Internet community.  Comments are welcome.

RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname
RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC.  Log in
with FTP username ANONYMOUS and password GUEST.  The NIC also provides
an automatic mail service for those sites which cannot use FTP.  Address
the request to SERVICE@SRI-NIC.ARPA and in the subject field of the
message indicate the RFC number, as in "Subject: RFC nnnn".

Requests for special distribution should be addressed to either the
author of the RFC in question or to NIC@SRI-NIC.ARPA.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to POSTEL@ISI.EDU.

Requests to be added to or deleted from this distribution list should be
sent to RFC-REQUEST@SRI-NIC.ARPA.

Joyce K. Reynolds

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jun 89 07:25:56 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        phri!roy@nyu.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  real sloooww local mail with internet link down
Does sendmail place mail into separate queues, depending upon
destination?  If not, then a large queue is subject to the degradation
of linear search.

Dave
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 06:38:00 EDT
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   win/route questions
Date sent:  13-JUN-1989 06:34:28 

Hello,
	I'm in the process of installing a gateway on a small tcp/ip network. 
I'm using a PC and running WIN/ROUTE software. On one side (192.9.200.*) I have
VAXes, SUN's and PC's all using ethernet. On the other side, I have a bunch of
PC's on a small token ring net with Proteon cards (192.10.200.*). I'm using the
NETBIOS driver for the Proteon cards. I can't for the life of me figure out 
what the routing table ROUTES is supposed to have in it for entries. Does 
anyone have a similar system running? I'd like to see your ROUTES file. 

Thanks in advance,

Dave


================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
Eastman Kodak Subsidiary                  ||             //   ||      ||  
170 Enterprise Center                     ||            //    ||       ||  
Middletown, R.I. 02840                    ||           //-----||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||          //      ||      ||
(401) 847-7260                            ||         //       ||_____||
================================================================================

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 06:09:13 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Super-Dumb Transport Protocol?

In article <93400023@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes:
>That is, a protocol that just involves a
>client sending a reqest which, if received by the server, generates a bunch of
>IP datagrams in response (maybe with a terribly naive checksum/retransmit
>of lost/damaged packets mechanism).

Sounds like TFTP to me, just add in the acknowledgements.

>  FTP has far too much baggage -- sitting as it does on top of TCP -- and
>TFTP is close, but still sits on top of UDP.

I've done this several times, so I'm not just hypothesizing here.  If
you've already got an IP, UDP is *trivial*. It adds some demultiplexing
and checksums. It has an 8 byte header. It almost does nothing. IP proper
is *much* more complicated.

The real complexity is in dealing with timeout and retransmission.
You'll find that you'll implement it primarily dealing with a certain
speed of network (serial lines or ethernet or FDDI) and then other
people will come along and run it over a speed at the opposite end of
the spectrum and it won't work so well, so you'll tinker with the
algorithms, and other people will come along and run it on a congested
overloaded network like the ARPANET (well, former-ARPANET) and you'll
need to tinker some more. There's a lot of stuff out there to look at
already to learn about these algorithms, especially Van Jacobsen's
work, but that's where a lot of the complexity comes in.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"We had some good machines/But they don't work no more" - Shriekback

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 10:38:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   win/route questions

Date sent:  13-JUN-1989 06:34:28 

Hello,
	I'm in the process of installing a gateway on a small tcp/ip network. 
I'm using a PC and running WIN/ROUTE software. On one side (192.9.200.*) I have
VAXes, SUN's and PC's all using ethernet. On the other side, I have a bunch of
PC's on a small token ring net with Proteon cards (192.10.200.*). I'm using the
NETBIOS driver for the Proteon cards. I can't for the life of me figure out 
what the routing table ROUTES is supposed to have in it for entries. Does 
anyone have a similar system running? I'd like to see your ROUTES file. 

Thanks in advance,

Dave


================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
Eastman Kodak Subsidiary                  ||             //   ||      ||  
170 Enterprise Center                     ||            //    ||       ||  
Middletown, R.I. 02840                    ||           //-----||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||          //      ||      ||
(401) 847-7260                            ||         //       ||_____||
================================================================================

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 14:14:58 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac


*I don't know of anyone who has NFS running on the Mac.  I had heard that
*CITI had a version that ran on the Mac, but I believe that it was funded
*by Apple and is not in the public domain.  Apple has the right to commercially
*Kurt Baumann
*InterCon Systems Corporation
*46950 Community Plaza
*Suite 101-132
*Sterling, VA 22170

*Phone: 703.450.7117  FAX: 703.437.3454  AppleLink: D1988
*Email: kdb@intercon.uucp


i believe that peter honeyman did this for them. i dont know what
heppened either, but there was talk at the last interop about it
being just cresting the horizon. i have also heard talk of someone
doing a appletalk to NFS gateway. what is involved i have no idea, so
dont bother to ask. the only appletalk packets i see are from the 2
MACS the doc people have when they boot up in the morning.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 14:23:20 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac



>I don't know of anyone who has NFS running on the Mac.  I had heard that
>CITI had a version that ran on the Mac, but I believe that it was funded
>by Apple and is not in the public domain.  Apple has the right to commercially
>ship that version or a version based on CITI code (again, I am not totally
>sure of these facts, so if someone knows different please jump in).  Apple,
>however, has not made any announcments that say they are going to ship it
>in the near future.  I would think that they do have plans on shipping a
>version sometime in the near future.  At least I hope so, we have been holding

This is correct.  I did a story on NFS for a magazine called MIPS, and in
the process interviewed the people at CITI. (The story's coming out in a
month or so.)  The CITI people (whose names escape me, but they're on the
net) said that Apple had funded their work and had the rights to it, and that
they didn't know of any other sources for NFS code for Apple.
	As recently as a month or six weeks ago, NFS was supposed to be
announced on June 12 with all the other Apple products.  Under nondisclosure,
I was briefed by Apple on May 3 or so.  (My nondisclosure ended on June 12.)
About a week afterward, they called and said the product would not be
released on June 12 after all.  I was not able to get an official reason why
it was being pulled, or any indication of if or when it might be released
after all.
	It's a cool product.  It includes an implementation of TCP/IP and an
NFS client with a typical Mac interface.
-- 
"Why should I let a loathsome little toad like you touch my breast
when you haven't even read my books!"
                                        "Starstruck," by Elaine Lee

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 14:25:56 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  real sloooww local mail with internet link down

Does sendmail place mail into separate queues, depending upon
destination?  If not, then a large queue is subject to the degradation
of linear search.

Dave

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 15:25:48 GMT
From:      akoifman@bbn.com (Alex Koifman)
To:        comp.protocols.tcp-ip
Subject:   Network Management info needed

I am just starting to work on a Network Management project.  We 
are going to implement an SNMP on an Internet Gateway.

Can you recommend me any literature that I can read in order to come
up to speed on the subject?  I have the RFCs 1052, 1098, 1065, 1066
and two SNMP development kits (MIT and CMU).  Are there any training
seminars (preferably in the Boston area), text-books, etc.?

Thanks,

    Alex Koifman

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 20:16:35 GMT
From:      umbaugh@hcx (Dr David L. Umbaugh)
To:        comp.protocols.tcp-ip
Subject:   NFS for the mac

stev@vax.ftp.com said:
   Date: Tue, 13 Jun 89 10:14:58 EDT

	. . .
   being just cresting the horizon. i have also heard talk of someone
   doing a appletalk to NFS gateway. what is involved i have no idea, so
   dont bother to ask. the only appletalk packets i see are from the 2
   MACS the doc people have when they boot up in the morning.

Cayman Systems makes a LocalTalk to EtherTalk gateway similar to the
Kinetics FastPath.  Cayman's "Gatorbox" also translates from
AppleShare file protocol to NFS.  A mounted NFS volume on one of our
Suns appears on our Macintosh desktops just like our AppleShare
volume.

L. David Umbaugh (Dave)
CSE Dept. Univ. Texas at Arlington
internet:  umbaugh@hcx.arl.utexas.edu     phonenet:  cs_umbaugh@uta.edu
CSNET:  cs_umbaugh%uta.edu@relay.cs.net   BITNET:  B652LDU@UTARLG
snail-mail: P.O.Box 19015, Arlington, TX  76019
telephone: (817) 273-3628

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 89 20:22:19 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   UDP vs TCP


Jeff:

There is one list of port number assignments used by both UDP and TCP.
If it makes sense to run a particular protocol on TCP, then use the number
from the list as a TCP port. If it makes sense to run a particular protocol 
on UDP, then use the number from the list as a UDP port. 

--jon.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 06:15:36 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for SunOS4.0


As I continue to get tons of requests for my patches, and tons of
questions about them, let me try to answer them again.  I have taken
the code written by Van Jacobson and others at Lawrence Berkeley Labs
called tcpdump and modified it to run under SunOS4.0.  The original
code only ran under SunOS3.5.  This code can run only on Sun's and has
not been tested by me (or anyone else that I know) on anything other
that Sun-3's.

In order for the program to run properly under SunOS4.0, a kernel fix
is needed to repair the broken NIT interface.  Sun can supply you with
a new nit_if.o.  If this object is not incorporated into the kernel,
it will appear as if you are receiving duplicate ethernet packets.
This is because the bug manifests itself by making all of the
snapshots in each chunk identical.

I have been informed by Marc Lavine of 3Com (marcl@vax.spd.3com.com) 
that the program dumps core when decoding arp packets.  I don't know
if my diffs are causing this or if the problem occurs with the old
version, but if I get a chance I will attempt to find the problem...
So please use this stuff at your own risk.

For those of you still trying to get this stuff, the following is a list
of sites that I know of (there may be others...):

ftp.ee.lbl.gov           original sources for Sun-3's running SunOS3.5
devvax.tn.cornell.edu    patches to sources for SunOS4.0
titan.rice.edu           binaries for Sun-3's running SunOS3.5
ncar.ucar.edu            binaries for Sun-3's running SunOS4.0

The four sites listed above all provide anonymous ftp service, and
titan.rice.edu provides mail archive retrieval service, but I'm not
sure of the specifics.  Please try to retrieve the things that you
need from these sites before sending a note to me.  And please do not
ask me to mail the original sources, please try a near neighbor first.

If you have questions other than requests, I'd be happy to hear from
you (especially if you fixed the problem with the arp decoding).

Good Luck

Micky

  arpa: micky@cunixc.cc.columbia.edu
  uucp: ...!rutgers!columbia!cunixc!micky
bitnet: malua@cuvmc

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 07:03:45 GMT
From:      freiss@nixpbe.UUCP
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.mail.misc
Subject:   IMAP2 sources needed


Hi netlanders,

does anyone out there on USENET have the IMAP2 sources? I know they
are available via anonymous ftp from sumex-aim.stanford.edu,
but (you guessed it) I don't have access to the Internet from here,
and my mails to Mark Crispin (author of RFC1064 / IMAP2) seem to be
swallowed up by a black hole somewhere on the way.

So.. if anyone has them, I would be *very* grateful if you could
mail them to me. Or if you know of a mailserver that carries the
IMAP2 sources, that would be great too.

Thanx in advance,
Martin

--
 Martin Freiss        UUCP:   USA: ..!uunet!philabs!linus!nixbur!freiss.pad
 Nixdorf Computer AG         !USA: ..!mcvax!unido!nixpbe!freiss.pad
 Dept. DS2            NERV:  freiss.pad
 Pontanusstr. 55
 D-4792 Paderborn     "Drink wet cement, get stoned."

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jun 89 14:00 CDT
From:      Ken Connelly <CONNELNI%UIAMVS.BITNET@VM1.NoDak.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: HACKERS AND MAILERS AND BIND
What's the point???  Do you have a problem with a particular site?
Or a particular piece of software?  Or what?
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 12:48:07 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP software for PC.

If you anonymous'ly FTP into nisc.nyser.net in the "pub/msdos-SNMP"
directory you will find some useful binaries that work layered over
the FTP Software PC/TCP package.

Marty
------------------

    I have a few boxes on my network that collect SNMP statistics.  What I
    don't have is a program that will retrieve this information and allow me
    to look at it.  Does such software exist for a PC?  If so, how can I get
    it?

    Thanks.

    --------------------------------------------------------------------
    |Mike Rackley                           |  (601)325-2942           |
    |Mgr. Systems & Networks Programming    |  Rackley@MsState.BITNET  |
    |Mississippi State University           |  Rackley@CC.MsState.EDU  |
 --------------------------------------------------------------------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 12:58:20 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   NFS for the mac

*   doing a appletalk to NFS gateway. what is involved i have no idea, so


*AppleShare file protocol to NFS.  A mounted NFS volume on one of our


*L. David Umbaugh (Dave)
*CSE Dept. Univ. Texas at Arlington
*internet:  umbaugh@hcx.arl.utexas.edu     phonenet:  cs_umbaugh@uta.edu
*CSNET:  cs_umbaugh%uta.edu@relay.cs.net   BITNET:  B652LDU@UTARLG
*snail-mail: P.O.Box 19015, Arlington, TX  76019
*telephone: (817) 273-3628


appleshare, right, sorry about that, i knew something looked wrong,
but couldnt put my finger on it . . . . 

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 14:59:43 GMT
From:      ntanaka@ARAGORN.GANDALF.CS.CMU.EDU (Nobuyoshi Tanaka)
To:        comp.protocols.tcp-ip
Subject:   Query on IP over LAPB

Folks,

  I am interested in how to implement IP over LAPB (or HDLC).  Are
there any references, any public domain implementations or any
pointers to comercial products.

  Please reply to me via e-mail (ntanaka@cs.cmu.edu), I will summarise
the replies and post the result.

  Thanks in advance.
-- 

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 15:56:11 GMT
From:      lawhorn@optis31.uucp (Jeff Lawhorn)
To:        comp.protocols.tcp-ip
Subject:   Internationalized Telnet



I'm interested in modifying Telnet (vt100) to support 8bit international
character sets.  If any one out there has done this work or can make
any suggestions in this area, please let me know.  Telnet seems to
use the upper 32 characters for server/client control information.

--
Jeff Lawhorn
lawhorn@opti
opti!lawhorn@berick.uucp
ucsd!sdsu!berick!opti!lawhorn

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 16:33:07 GMT
From:      warrens@SUN.COM (Warren Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

RPC/XDR is a necessary component of NFS, but it is not a "part" of
NFS any more than IP is.  We demonstrated NFS over OSI connectionless
transports more than 2 years ago, for instance.

RPCSRC 3.9 (I assume that this was what you meant by RPC 3.9) is a
reference implementation of the RPC/XDR libraries.  The reference base
is BSD, not System V.  It is a "freely licensed" piece of code.

You shouldn't expect it to run on top of Interactive's IP stack unless
the socket interface that you got from Interactive is the same as
Berkeley's 4.3.  Headers may be only part of the problem.  RPCSRC 3.9
is not what ships with any particular vendors implementation of NFS.
RPC does, but not RPCSRC (which is a particular instantiation of RPC).
The interface to the RPC libraries should be the same across all
implementations (I would like to hear, if this is not true).

It sounds like you did not get the RPC from Interactive.  Why not?
Don't they supply it external to NFS?

You are welcome to share any changes that you make to RPCSRC for
creating a reference version for Interactive's socket interface.
Just leave the copyright notices intact, so that others are also
allowed "freely licensed" access to the code you send out.  

By the way, there is a RPCSRC 4.0 available in the sun-spots newsgroup
at Rice University.  It was supposed to have made it into comp.sources
last March, but I am not sure if it has actually gotten out yet.  This
release contains Secure RPC, which has an improved authentication
mechanism.  It also assumes a 4.3BSD base.

-Warren A. Smith
Sun Microsystems

----- Begin Included Message -----

>From tcp-ip-RELAY@SRI-NIC.ARPA Mon Jun 12 23:57:19 1989
Date: 2 Jun 89 22:14:15 GMT
From: jarvis.csri.toronto.edu!utgpu!utzoo!dciem!nrcaer!sce!xicom!alex@rutgers.edu  (Alex Laney)
Organization: XICOM Ottawa,Ont. Canada
Subject: Re: RPC Library sources for System V
References: <457@focsys.UUCP>
Sender: tcp-ip-relay@sri-nic.arpa
To: tcp-ip@sri-nic.arpa


	RPC is a standard part of NFS, no? I recall (faintly) somewhere that
Interactive advertised this as part of their NFS product.

	I have a copy of their Host-based TCP-IP, and the RPC3.9 source code.
My experience is that with modification of the headers, I could get it to
compile, but it would crap-out at run-time. This was a few months ago, so I
don't recall the exact error. I will be trying again soon, however.


Alex Laney, Xicom Technologies.

uunet!mitel!sce!xicom!alex (not alex@xicom.uucp)


----- End Included Message -----

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 18:08:53 GMT
From:      davidf@colnago.wpd.sgi.com (David Fenstemaker)
To:        comp.protocols.tcp-ip
Subject:   X.25 Certification Question

Does anyone have the phone number or addresses of the
following U.S. and European Networks in order to obtain 
X.25 certifications?

Telenet
Accunet
Datex-P (West Germany)
PSS (UK)
Transpac (France)
Datapak (Sweden)

Thanks.

David Fenstemaker

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 19:00:00 GMT
From:      CONNELNI@UIAMVS.BITNET (Ken Connelly)
To:        comp.protocols.tcp-ip
Subject:   Re: HACKERS AND MAILERS AND BIND

What's the point???  Do you have a problem with a particular site?
Or a particular piece of software?  Or what?

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 19:03:04 GMT
From:      EARN@BBRBFU01.BITNET
To:        comp.protocols.tcp-ip
Subject:   Info on the 3C543 board wanted.

Hello,
 I'm looking for information enabling us to write a driver for the 3C543
 board ( the Etherlink/NuBus card that plugs in your Mac-II ).
  1) Apple Belgium (who sold it) hasn't anything
  2) The 3Com representatives offer a complete info-package on all their
     boards for 50000 Belgian Francs ( about 1200 $ ), which is too much...
     (money and info, I mean...)
 We won't use the board or the software for commercial purposes, nor will we
 distribute it to 3rd parties.

Any information on this beast ( 3C543 board ) is welcome, even pointers or
symbolic links to where the info might or might not be.

Eric Luyten,
Brussels Free University Computer Centre, Belgium.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 19:17:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Super-Dumb Transport Protocol?


  Thanks to all who pointed out how simple IP/UDP/TFTP can be (I got lots of
e-mail). One can make a dumb IP with a naive view of the network (say, a RARP
server plus a gateway somewhere that will accept any packets I dump onto the
local net that are for nonlocal hosts), a 100-line implementation of UDP and
a TFTP responder. Boink!
  What I _didn't_ want was routing/runtime support above what a really dumb
operating system (MS-DOS, Mac-OS...) could provide/a limited number of
simultaneous connections. The only thing I object to in TFTP is the stop-and-
wait aspect of the protocol -- thoroughly evil on a high-speed, high-latency
connection.
  While I agree it's a waste of time to reinvent the wheel, and that nobody
will be able to speak a new (slightly different) protocol, this seems like
a terribly simple wheel (so not too much time wasted) and, well, nobody spoke
NFS much more than five years ago, either....
  The reason I'm interested in a super-dumb protocol is that a server could
easily have the disk- and net-bandwidth to barf files out to hundreds or
thousands of users simultaneously, but if it has to do anything much more
complicated than just fetch a sector and transmit it (trick: calculate the
checksums when you put the archived file on disk -- no snarftime math!) over
the network, the bottleneck will be at the CPU/Memory interface where it
doesn't belong.

-Johnny Still-scratching-my-head

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 89 19:34:28 GMT
From:      dgregory@fstohp.crd.ge.com (David B Gregory)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for VMS 9 (free)


We are looking for a good (workable) TCP/IP for VMS
that is in the public domain. Needs telnet and ftp, smtp
not critical.  Have tried CMU but seems to have lots of 
problems... any help would be appreciated.
Dave Greg          
Dave Gregory

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Jun 89 19:05:04 +02
From:      EARN%BBRBFU01.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Info on the 3C543 board wanted.
Hello,
 I'm looking for information enabling us to write a driver for the 3C543
 board ( the Etherlink/NuBus card that plugs in your Mac-II ).
  1) Apple Belgium (who sold it) hasn't anything
  2) The 3Com representatives offer a complete info-package on all their
     boards for 50000 Belgian Francs ( about 1200 $ ), which is too much...
     (money and info, I mean...)
 We won't use the board or the software for commercial purposes, nor will we
 distribute it to 3rd parties.

Any information on this beast ( 3C543 board ) is welcome, even pointers or
symbolic links to where the info might or might not be.

Eric Luyten,
Brussels Free University Computer Centre, Belgium.
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 13:36:44 GMT
From:      jmatrow@ncrwic.Wichita.NCR.COM (John Matrow)
To:        comp.protocols.tcp-ip
Subject:   Need DOS Domain Name Server

I need information on Domain Name Server products to use on DOS with
Ethernet in our facility.
I am aware of BIND from FTP Software and I found one bundled in
EXport Management Software from Excelan.
-- 
John Matrow   Information Systems & Services, NCR E&M Wichita
 NCR:654-8851 <J.Matrow@Wichita.NCR.COM>
(316)636-8851 <uunet!ncrlnk!ncrwic!j.matrow>
              "Call 202/653-1800 for a good time!"

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 14:01:00 GMT
From:      MOSS@cs.umass.EDU ("Eliot Moss, GRC A351B, x5-4206  15-Jun-1989 0900")
To:        comp.protocols.tcp-ip
Subject:   NFS for Mac

While it may not be what folks are looking for, A/UX (Apple's version of
Unix) includes NFS server and client, as well as the usual complement of
TCP/IP servers and clients (Telnet, FTP, etc.). The newer versions of A/UX
allow regular Mac OS programs to be run under A/UX, too. As a separate piece
of software you can get X11 for A/UX as well.

					Eliot Moss
					Asst Prof
					Dept of Comp and Info Sci
					Univ of Mass
					Amherst, MA 01003
					Moss@cs.umass.edu

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 14:44:48 GMT
From:      oconnor@interlan.interlan.COM (Mary O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Host Requirements


  Would someone please forward a copy of the Host Requirements or direct
  me to where I may obtain access ? 
 
    Thank You.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 15:20:43 GMT
From:      djh@cci632.UUCP (Daniel J. Hazekamp)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   How can I force some routes through an Ethernet Bridge??

First, the scenario:

	We have 2 local ethernets with different Class C internet addresses
connected via a gateway host. A single host on Net A, has some leased line
connections to additional offsite ethernets. All hosts are running 4.2 BSD
Networking software.


			      Net B
	----------------------------------------------------
				|
			   -----------
			   |  local  |
			   | gateway |
			   |   host  |
			   -----------
				|
	----------------------------------------------------
			      Net A		|
					   -----------
					   |  remote |
					   | gateway |
					   |   host  |
					   -----------
	leased lines to offsite Nets   ---->  |   |



I've replaced the 'local gateway host' with an ethernet bridge.

			      Net B
	----------------------------------------------------
				|
			   -----------
			   | ethernet|
			   |  bridge |
			   -----------
				|
	----------------------------------------------------
			      Net A		|
					   -----------
					   |  remote |
					   | gateway |
					   |   host  |
					   -----------
	leased lines to offsite Nets   ---->  |   |
	
I then added routing information to allow hosts on Nets A and B to talk to
each other through the bridge.

		On Net B hosts:
			/etc/route add NetA NetB 0

		On Net A hosts:
			/etc/route add NetB NetA 0

At this point, telnet, ftp, rlogin, etc all work between hosts on Nets A and B.

The problem is that I can't get to any hosts on the offsite networks from Net B
hosts. Under the original setup, I assigned the 'default' route to the 'remote' 
gateway host as follows:

		/etc/route add default rgateway 1

With the new setup, this fails on all the Net B hosts, even though I have a
valid route to Net A. The error message returned is 'Network Unreachable'. This
is clearly bogus, since I can rlogin, ftp, etc to all the Net A hosts.

Any help would be appreciated.

Note: I realize that one solution is to modify the setup such that Nets A and B
are simply 2 segments with the same Class C net address. We'd like to avoid this
if at all possible.

Dan Hazekamp
Computer Consoles Inc.
Rochester, NY

UUCP:		rochester!cci632!djh
Internet:	cci632!djh@cs.rochester.edu
-- 
Dan Hazekamp					rochester!cci632!djh
Computer Consoles Inc. (CCI)			uunet!ccicpg!cci632!djh
Rochester, NY					uunet!rlgvax!cci632!djh

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 18:56:02 GMT
From:      rex@nbc1.UUCP (Rex Espiritu)
To:        comp.protocols.tcp-ip
Subject:   FAILSAFE/Tandem

We are currently in the process of evaluating Fail Safe Computer Systems, Inc.
's implementation of tcp-ip (with telnet and ftp) for connectivity with a
Tandem.  If anyone has already done this and/or has used Failsafe on a
programmatic level (e.g. using UNIX 4.3BSD sockets on a Sun to "talk" with
a Guardian/TAL process on the Tandem), I'd be very interested in their
experience(s) and opinion(s) with regard to this matter.  Please send me
e-mail or call me if you or anyone you know is familiar with these issues as
we'd appreciate any info/help.

We've already successfully tested "bare bones" communication over Ethernet
between a UNIX process (using ULTRIX sockets) on a DEC MicroVAX and a
Guardian process (using FailSafe) on a Tandem.  Right now, we're interested
in finding out things like the quality of documentation, software/hardware
support, error recovery, bugs, ease of programming, etc.

Again, any experience in the use and testing of these things would be
appreciated.  Please contact me in any of the ways listed below if you can
help.

-- 
M. Rex Espiritu, Jr.                       National Broadcasting Company, Inc.
rex@nbc1.ge.com                            30 Rockefeller Plaza, Room 1615W
{crdgw1,ge-dab,philabs}!nbc1!rex           New York, NY  10112   212-664-5390
"Where there is no vision, the people shall perish."--Is

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 89 23:38:42 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Host Requirements


The Host Requirements RFC draft document is available for anonymous FTP
from host: VENERA.ISI.EDU.  There are two parts, with pathnames: 

   pub/ietf-hosts.rfcL.txt
   pub/ietf-hosts.rfcU.txt

For Unix fans, there are also corresponding compressed files:

   pub/ietf-hosts.rfcL.txt.Z
   pub/ietf-hosts.rfcU.txt.Z

Bob Braden

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 03:59:43 GMT
From:      jbm@uncle.UUCP (John B. Milton)
To:        comp.protocols.tcp-ip,unix-pc.general
Subject:   Is rhost() a front end to gethbyname()

I'm new to writing socket code, and I've run across some code that uses rhost(),
which is not in my library. Does this perform a similar function to
geth[ost]byname()? Anybody got some good get-aquainted-to-sockets code?

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:466-9324; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 13:24:18 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac



>being just cresting the horizon. i have also heard talk of someone
>doing a appletalk to NFS gateway. what is involved i have no idea, so

Cayman's Gatorbox can function in this way, I believe...
-- 
"Why should I let a loathsome little toad like you touch my breast
when you haven't even read my books!"
                                        "Starstruck," by Elaine Lee

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 13:24:39 GMT
From:      ron@hardees.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,unix-pc.general
Subject:   Re: Is rhost() a front end to gethbyname()

Rhost was the 4.1 BSD TCP host lookup routine.  It's syntax
(if I recall) was roughly:

	long	rhost(namep)
	char	**namep;

Where namep is a pointer to a character array containing the
name to be looked up.  When successful rhost puts a pointer
to an array containing the official host name in namep and
returns the internet address.

-Ron

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 13:41:53 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   subnets/routers/bridges/redirects bug?


has anyone seen the following problem, and if so (or they understand
it), can they explain it better...?


Configuration:

src            dst a
 |                |
------------------------------- subnet ~b
        |                |
       subnet          MAC        
      routing        Bridge
       sun C             |
        |                |
------------------------------- subnet b
                | 
              dst b


error 1:
We got the subnet mask wrong on some src hosts

They routed to all subnets *except* b, via 
sun C, which has the *SAME* ethernet address on
both interfaces!! (by default, now changed).

- The bridge forwarded their packets so the sun saw them on both
interfaces. (bridge should prob. have kept local traffic local, but it
saw the ethernet address in its farside port list, so assumed it wasnt
local - i.e.bridge should check both for non-existence in local port as
well as existence in farside port before forwarding, maybe?)

- Interface on b receiving them causes IP on sunC to send icmp redirects
(didnt see where it was redirecting to, but suspect the same suns
interface on subnet ~b).

- Hosts on ~b get routing entries installed, *for every host* on subnet
 ~b, even though if running real routing 

- Major disaster (and prob a bug):

They subsequently (prob because they confuse redirect information when
their subnet mask is wrong) 
route *broadcast* packets to sunC - i.e. put IP broadcast in Ethernet
unicast packets directed to subnet router, which...

- Correctly drops them...

Hence, all services that rely on broadcast (for instance locating YP
servers) die the bad death.

so do the subnets/ethernets because they are flooded all the time with
redirects

(this was not restricted to suns - dec/hp and other YP clients were
just as bad).

p.s. our 3 fixes - 
0) fix subnet masks
i) turn off redirect in subnet router,
ii) turn off one erthernet interface in subnet router

other people's fixes:
0) never use the same physical address on multiple IP interfaces.
i) never send an IP broadcast to a router as it isnt going to route it
anyway.
ii) dont use broadcast for locating important clients, use
multicasts.

anyone agree/disagree with findings?

jon 

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 15:11:23 GMT
From:      virchaux@CLSEPF51.BITNET (Jacques Virchaux EPFL-SIC)
To:        comp.protocols.tcp-ip
Subject:   Modem connection from a Sun

Does anybody has some source to manage a Hayes modem from a Sun.

I have a Sun 3/150 with SunOs 3.5 and an ALM-2 (16 asynch. ports) and
the goal is to dial out from a process to establish a transparent
connexion.

Please answer directly to <virchaux@sic.epfl.ch> and not to the list.

Jacques Virchaux
Swiss Federal Institute of Technology
CH-1015 Lausanne
Switzerland

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 16:06:21 GMT
From:      armstrongk@LUAC.SDSC.EDU (KAREN ARMSTRONG 619-534-5077)
To:        comp.protocols.tcp-ip
Subject:   Netowrking and Supercomputers Fifth Annual Workshop

****************************************
****************************************
Networking and Supercomputers
Fifth Annual Workshop
July 11-13
San Diego, CA
****************************************
****************************************

Contact: 
	Sandra Davey
	San Diego Supercomputer Center
	Networking and Supercomputers Workshop
	PO Box 85608
	San Diego, CA  92138-5608

	or by telephoning 619-534-5026
	or by sending electronic mail to 
	daveysl@sds.sdsc.edu




Networking plays an important role in today's 
distributed computing and in nationwide user 
communities. The development and availabilitiy of 
Local Area Networks (LANs), national and regional 
Wide Area Networks (WANs) to interconnect the 
LANs, and affordable yet powerful workstations are 
helping change the users interface to 
supercomputing resources.

In this Workshop, we will examine current 
developments in the following areas:

*Wide Area Networks (Developments and 
Infrastructure)
*New and Evolving Standards (Technology and 
Environment)
*Supercomputer Performance (Benchmarks)
*Local and Wide Area Networks 
Performance/Statistics
*Network Operations
*New Applications Utilizing Networks
*Network Security

PROGRAM HIGHLIGHTS

Dr. Robert Kahn, Corporation for National Research 
Initiatives, will be the keynote speaker at the 
Workshop.  Dr. Kahn is heading up the collaborative 
research effort on Very High Speed Networks, 
sponsored by DARPA and the NSF.  This program is 
designed to involve industry and the academic 
community in a cooperative effort to explore the 
technology necessary for the development of a 
gigabit/second research network and to 
demonstrate its utility.  Dr. Kahn will describe the 
progress of this plan.

PRELIMINARY PROGRAM
(This is a tentative agenda which is subject to minor changes.)

TUESDAY, JULY 11

	9:00 - 9:15	Welcome
	
	9:15 - 10:45	Keynote Address - Dr. Robert Kahn, 
President, Corporation for National Research Initatives,  Gigabit 
Research Networks for the 90s.

	10:45 - 11:00	Break

	11:00 - 11:45	Introduction to the Federation of American 
Research Networks (FARnet)-Speaker to be announced.

	11:45 - 1:00	Lunch

	1:00 - 1:45	NASA/DARPA Research Internet Gateway-
John Lekasman, NASA/AMES

	1:45 - 2:30	To Be Announced

	2:30 - 2:45	Break

	2:45 - 3:30	Supercomputer Performance Measurement - 
The PERFECT Club - Mike Berry, University of Illinois at 
Urbana/Champlain

	3:30 - 4:30	Fiber Distributed Data Interface (FDDI) - To 
Be Announced

	Evening:	Harbor Excursion (Boarding 
Time 6:00 p.m.)


WEDNESDAY, JULY 12

	9:00 - 9:45	Network Performance Benchmarking - Bilal Chinoy , MERIT

	9:45 - 10:45	Network Monitoring in Los Nettos - A High 
Bandwidth Network - Danny Cohen and Walter Prue, Information 
Sciences Institute

	10:45 - 11:00	Break

	11:00 - 12:00	Network Security - A Discussion of the 
Worm - Keith Thompson, NASA/AMES, Phil Lapsley, LBL, Keith 
Bostic, LBL

	12:00 - 1:00	Lunch

	1:00 - 1:45	CP* and the High Speed Channel - Randy 
Holbelheinrich, Los Alamos National Laboratories

	1:45 - 2:30	Bringing Supercomputer Graphics to your 
Desktop with Compression/Decompression - Dr. Larry Rapagnani, 
Air Force Weapons Laboratory

	2:30 - 2:45	Break

	2:45 - 3:30	Using X-Windows Remotely - Alan Katz, 
Information Sciences Institute

	3:30 - 4:30	POSIX - To Be Announced

	Evening:	Tour of the San Diego Supercomputer 
Center.  Refreshments courtesey of Cray Research, Inc.(Bus 
departs Holiday Inn at 4:45 p.m.)

THURSDAY, JULY 13

	9:00 - 10:30	Panel discussion on using WANs and 
Supercomputers Panel Moderator - Paul Love, San Diego 
Supercomputer Center  Panel Participants:  Joe Choy, National 
Center for Atmospheric Research, Alan Blatechey, North Carolina 
State Network, Bill Yurick

	10:30-10:45	Break

	10:45 - 12:00	Panel Discussion on using LANs and 
Supercomputers Panel Moderator - Charlie Catlett, National Center 
for Supercomputing Applications.  Panel Participants:  Keith 
Bossange, Ultra, Jim Hughes, Network Systems Corporation, Joe 
Wenker, Cray Research, Kirk Lougheed, ciscoSystems

	12:00		Conference Ends

REGISTRATION

Registration is $200 per person.  If registration is 
mailed by June 23 no late fee will be charged. 
Please contact Sandra Davey for further information.

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jun 89 14:41:53 +0100
From:      Jon Crowcroft <J.Crowcroft@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   subnets/routers/bridges/redirects bug?

has anyone seen the following problem, and if so (or they understand
it), can they explain it better...?


Configuration:

src            dst a
 |                |
------------------------------- subnet ~b
        |                |
       subnet          MAC        
      routing        Bridge
       sun C             |
        |                |
------------------------------- subnet b
                | 
              dst b


error 1:
We got the subnet mask wrong on some src hosts

They routed to all subnets *except* b, via 
sun C, which has the *SAME* ethernet address on
both interfaces!! (by default, now changed).

- The bridge forwarded their packets so the sun saw them on both
interfaces. (bridge should prob. have kept local traffic local, but it
saw the ethernet address in its farside port list, so assumed it wasnt
local - i.e.bridge should check both for non-existence in local port as
well as existence in farside port before forwarding, maybe?)

- Interface on b receiving them causes IP on sunC to send icmp redirects
(didnt see where it was redirecting to, but suspect the same suns
interface on subnet ~b).

- Hosts on ~b get routing entries installed, *for every host* on subnet
 ~b, even though if running real routing 

- Major disaster (and prob a bug):

They subsequently (prob because they confuse redirect information when
their subnet mask is wrong) 
route *broadcast* packets to sunC - i.e. put IP broadcast in Ethernet
unicast packets directed to subnet router, which...

- Correctly drops them...

Hence, all services that rely on broadcast (for instance locating YP
servers) die the bad death.

so do the subnets/ethernets because they are flooded all the time with
redirects

(this was not restricted to suns - dec/hp and other YP clients were
just as bad).

p.s. our 3 fixes - 
0) fix subnet masks
i) turn off redirect in subnet router,
ii) turn off one erthernet interface in subnet router

other people's fixes:
0) never use the same physical address on multiple IP interfaces.
i) never send an IP broadcast to a router as it isnt going to route it
anyway.
ii) dont use broadcast for locating important clients, use
multicasts.

anyone agree/disagree with findings?

jon 
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jun 89 21:03:02 EDT
From:      Tony Monteiro <MONTEIRO@graf.poly.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   CD/ROM players via TCP/IP
Has anyone heard of anything that will allow a CD/ROM to be
accessible via TCP/IP? I am especially interested in devices
that can play multiple CD/ROM's. Thanks.


Tony Monteiro
Polytechnic University
New York
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 18:01:20 GMT
From:      alycef@socrates2.rdrc.rpi.edu (Alyce Faulstich)
To:        comp.protocols.tcp-ip,unix-pc.general
Subject:   Re: Is rhost() a front end to gethbyname()


I am a "returning" net reader after a leave of almost 2 years.  I seem to
remember some discussion about it being very difficult to replace the
battery of a 3b1.  I didn't pay much attention at the time, but since
I was also on leave from my 3b1 for almost a year (during which it was
powered off) I'm afraid that I will have to replace the battery.  I was
hoping that I would find answers on the net without having to ask any
questions, but the topic was probably exhausted long ago!  Please, would
someone jump-start my memory by letting me know what the 3b1 battery
issues are?

Alyce Faulstich
alyce@rdrc.rpi.edu

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 20:41:09 GMT
From:      jfitzger%talcott@mashnee.UUCP (Jeffrey J. Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: MTU sizes


	We're a country seldom heard from so for a change I thought I'd
put in our two cents...

	We're supporting the mtu discovery option as part of our next
release v5.10, due to be released sometime in July of this year.  For
those of you who missed v5.00 our on-board port-to-port bridge forwarding
(and flooding) performance is now at wire speed and the performance for
the various routers is about half wire speed.  Note that this is independent
of your configuration (number of routers, concurrent bridging/routing,
number of slots/interfaces, presence of IP options, SNMP, Telnet, etc).
Also, our off-board (board to board - when two ethernet ports just won't 
cut it ;-) performance is just as a good, though the off-board bridge is
limited to the same as the router performance (i.e. about half wire speed).

	Our default mtu on sync and T1 lines is 1600 bytes - enough for
a max ethernet frame with encapsulation.

	Of course, the mtu discovery option is (like the basic and
extended security options) configurable due to its 'experimental' nature.

Jeff

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 20:48:06 GMT
From:      rlk@tusun2.knet.utulsa.edu ( Richard L. Kruse II)
To:        comp.protocols.tcp-ip
Subject:   Best TCP/IP for a VAX running VMS


About two weeks ago I posted a query as to the "best" TCP/IP
implementation to use on a VAX 6320. I failed to mention that
we would be running VMS. As promised, here is the summary of
the replies I received. Thanks very much to all responders;
you have given us some very useful information, as although
we have not made our decision yet, I feel that we have enough
information to make a sensible decision...

The top vendors of choice here look like Wollongong and TGV.
I received a roughly one-for-one recommendation between these
two vendor's products (WIN/TCP and MultiNet, respectively).
I also had a few plugs for Fusion, Process and Ultrix.

As I'm not sure of the correct "netiqette" for posting
summaries, I will stop there. Anyone interested in more
detail should send me mail, and I will gladly send them more
of the details.

Anyone who can give me some guidelines for the *correct* way
to post a summary, please do so! If I missed the boat totally,
I could be talked into a better (read longer) summary...

Hope this helps

Rick Kruse
University of Tulsa

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 89 21:30:35 GMT
From:      hwajin@wrswrs.UUCP (Hwajin Bae)
To:        comp.protocols.tcp-ip,unix-pc.general
Subject:   Re: Is rhost() a front end to gethbyname()

In article <556@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes:
>I'm new to writing socket code, and I've run across some code that uses rhost(),
>which is not in my library. Does this perform a similar function to
>geth[ost]byname()? Anybody got some good get-aquainted-to-sockets code?

Ahhhh... memories...
The rhost() system call is an older 4.1BSD equivalent of gethostby*()
like calls... so it's better to convert the code to use newer gethostby*()
style calls.  THe only still widely available 4.1 BSD TCP/IP code is
the one by Excelan whose TCP/IP and socket code runs on (literally) their 
intelligent ethernet boards.  Most of us are using 4.3 based TCP/IP as 
you know.

hwajin
-- 
{uunet,rtech,sun}!wrs!hwajin (UUCP)
bae@tis.llnl.gov (Internet)
Wind River Systems, 1351 Ocean Ave, Emeryville, CA 94608

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 01:03:02 GMT
From:      MONTEIRO@GRAF.POLY.EDU (Tony Monteiro)
To:        comp.protocols.tcp-ip
Subject:   CD/ROM players via TCP/IP

Has anyone heard of anything that will allow a CD/ROM to be
accessible via TCP/IP? I am especially interested in devices
that can play multiple CD/ROM's. Thanks.


Tony Monteiro
Polytechnic University
New York

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Jun 89 12:38 AST
From:      CUTB%ACUPR.UPR.CUN.EDU@CORNELLC.cit.cornell.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Technical Specifications needed

        I need all the major criteria to make clear the technical
specifications needed for a proposal in order to recieve the best
implementation of TCP/IP in harmony with the needs of my institution.
Please I need the help as soon as possible.  Thanks.
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 10:18:02 GMT
From:      paolo@semto.UUCP (Paolo Zeppegno)
To:        comp.protocols.tcp-ip
Subject:   DIAL-UP slip availability

We are in urgent need of an implementation of a dial-up slip.
We know there are some implementation around, but there seem to be
nothing in the public domain. If someone has informations about this
subject, or better has implemented it and is willing to share it, please
reply to me via email.
Thanks in advance
	- paolo zeppegno
	Systems & Management
	torino ITALY

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 14:11:15 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: HACKERS AND MAILERS AND BIND

Since this response is through the TCP/IP group rather than the BIND group
the context is incomplete.  Rutgers is running a BIND mail concentrator
which began retransmitting messages at 20 minute intervals increasing the
size of the message at each interval.  In the USA the internet is a "free"
service (your tax dollar at work) the only cost is loss of bandwidth and
the irritation of browsing through duplicated messages.  The author of the
message is in the UK--he is charged for each packet that traverses the
transatlantic link wheether or not he originated the message traffic.  No
doubt you would be piqued if you were paying three days worth of duplicate
message traffic.

Merton

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 16:38:00 GMT
From:      CUTB@ACUPR.UPR.CUN.EDU
To:        comp.protocols.tcp-ip
Subject:   Technical Specifications needed


        I need all the major criteria to make clear the technical
specifications needed for a proposal in order to recieve the best
implementation of TCP/IP in harmony with the needs of my institution.
Please I need the help as soon as possible.  Thanks.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 18:37:25 GMT
From:      dupont@inria.inria.fr (Francis Dupont)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: How can I force some routes through an Ethernet Bridge??

I apologize for the long include, but it is necessary to explain the problem
before ...

In article <29219@cci632.UUCP>, djh@cci632.UUCP (Daniel J. Hazekamp) writes:
> First, the scenario:
> 
> 	We have 2 local ethernets with different Class C internet addresses
> connected via a gateway host. A single host on Net A, has some leased line
> connections to additional offsite ethernets. All hosts are running 4.2 BSD
> Networking software.


			      Net B
	----------------------------------------------------
				|
			   -----------
			   |  local  |
			   | gateway |
			   |   host  |
			   -----------
				|
	----------------------------------------------------
			      Net A		|
					   -----------
					   |  remote |
					   | gateway |
					   |   host  |
					   -----------
	leased lines to offsite Nets   ---->  |   |



> I've replaced the 'local gateway host' with an ethernet bridge.

			      Net B
	----------------------------------------------------
				|
			   -----------
			   | ethernet|
			   |  bridge |
			   -----------
				|
	----------------------------------------------------
			      Net A		|
					   -----------
					   |  remote |
					   | gateway |
					   |   host  |
					   -----------
	leased lines to offsite Nets   ---->  |   |
	
> I then added routing information to allow hosts on Nets A and B to talk to
> each other through the bridge.
> 
> 		On Net B hosts:
> 			/etc/route add NetA NetB 0
> 
> 		On Net A hosts:
> 			/etc/route add NetB NetA 0
> 
> At this point, telnet, ftp, etc all work between hosts on Nets A and B.
> 
> The problem is that I can't get to any hosts on the offsite networks
> from Net B hosts. Under the original setup, I assigned the 'default'
> route to the 'remote' gateway host as follows:
> 
> 		/etc/route add default rgateway 1
> 
> With the new setup, this fails on all the Net B hosts, even though
> I have a valid route to Net A. The error message returned is
> 'Network Unreachable'. This is clearly bogus, since I can rlogin,
> ftp, etc to all the Net A hosts.

The solution is not in manuals, but is rather simple :
 you give a fake internet address in NetB to rgateway,
 put the route via this address and
 publish an ARP entry with the Ethernet address of rgateway and
 its IP address in NetB.

          /etc/route add default rgateway-B 1
          /etc/arp -s rgateway-B rgateway-ether pub

 The last command is not in regular BSD 4.2 networking, but you need only
one machine with this capability. It works because the network software
need only the ethernet address of next hop when the route is a route
through a gateway (its metric is > 0). But all the gateways must have
'interface' routes (with metric 0) from the local host to them, if not
you get an 'Network Unreachable' error when you try to add a route
through such a gateway.

Francis.Dupont@inria.fr

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 23:19:14 GMT
From:      philf@lindy.Stanford.EDU (Phil Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP for real-time OS


I'm looking to identify commercial source-code implementations of
TCP/IP to run on top our our real-time kernel.  We'd want to license
the source code to port to our 680x0-based server products.  The
overall structure and service interfaces to our kernel are much like
those of Ready Systems' VRTX, so a TCP/IP for VRTX would be the
perfect beast.

Please mail to me; I'll summarize to the net if there's interest.

UUCP:  ...sun!lindy.stanford.edu!philf
Internet:  philf@lindy.stanford.edu

Phil Fernandez
Manager, System Software
Metaphor Computer Systems

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 89 23:25:50 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Is rhost() a front end to gethbyname()

Boy, our network is really getting good.  I got the answer before the
question!

Cornett

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 89 14:52:33 GMT
From:      davecb@yunexus.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: CD/ROM players via TCP/IP

In article <8906171008.AA21507@ucbvax.Berkeley.EDU> MONTEIRO@GRAF.POLY.EDU (Tony Monteiro) writes:
>Has anyone heard of anything that will allow a CD/ROM to be
>accessible via TCP/IP? I am especially interested in devices
>that can play multiple CD/ROM's. Thanks.

  At the Usenix conference just past I was looking at CD-rom players
attached to Suns, in a publisher's booth where they had just released
their first CD, a copy of the Gnu project's complete works to date.
  Presumably you can at least ftp from suns, in the event you can't get
the dsks exported by nfs.

--dave

-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 223-8968      |    He's so smart he's dumb.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 89 22:40:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Specification vs. Implementation


   I have been looking over the draft printouts of the Host Requirements
RFCs and there are a few points that both confuse and bother me.
   It seems to me that there is a big difference between a specification and an
implementation. That's why RFCs exist -- otherwise, source code to the
BSD 4.3 implementation of TCP/IP would be published as "the protocol"....
   So why on Earth does the Host Requirements (draft) RFC tell me that when
I implement my IP I need to provide calls that specify, among other things,
pointers to buffers? And, while I'm asking about RFCs, why does RFC 793
call SYN-SENT/ESTABLISHED/etc. "states" when, according to p.70, the SYN-
RECEIVED state needs to know whether the connection was originally opened
passively or actively -- i.e. a state that cares which state it was entered
from? There should be 2 states: SYN-RECEIVED-AND-I-USED-TO-BE-IN-LISTEN and
the complementary one. Of course, there's the boo-boo involving SND.WL1 and
SND.WL2 never getting initialized.
   Yes yes yes yes yes! I know that it is pointed out that there is no need
to implement the calls literally -- "A host implemntation MUST support the
logical information flow implied by these calls, but need not literally
implement the calls themselves." If the requirement is _for_ information
flow, shouldn't it be _in terms of_ information flow? I guess I just don't
see the point of using function-calls that can probably be traced back to a
specific implementation to express ideas which can be cast just as clearly
in other terms.
   It seems to me that specifying a protocol in terms of assigning stuff to
variables and calling functions with pointers is missing an important point.
   I suppose I would just like to see the phrase "for example" appear more
often....
   Granted, I detest the long-winded, nit-picky, incomprehensible way the ISO
specifies things as much as the next guy -- but at least a protocol is
specified in terms of what services it needs to provide -- not which variables
to increment...
   I've never written a line of code that uses mbufs, and I never intend to.
If I want to write in C++ and use new/delete to have memory management
handled by lovingly hand-crufted code to do it, I don't want to have my boss
shake a finger at me and say "this doesn't comply with the host-requirements
RFC:  you don't have a pointer to a buffer, and you use an error-object to
handle error-reporting, and...."
   It's not a huge point, really -- so please don't burn my house down for
going on about it. But it seems like a messy way to do something that alot of
people have worked hard to come up with ways to do cleanly.
   The chains binding specification to implementation need to be broken once
and for all, and I think June 1989 is high time. Protocols ought to be
specified in terms of functionality, not function-calls.

-Johnny Zweig
-------------------------------------------------------------------------------
 (These opinions are my own -- and maybe I'm just cranky because I've been
  trying to write an object-oriented implementation of TCP and not getting
  enough sleep. So don't blame the UIUC Department of Computer Science for
  engendering or encouraging a jerk like me; I just use their 56 kbps line to
  Purdue....)

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 00:56:32 GMT
From:      gatesl@netcom.UUCP (Lee Gates)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac

>Cayman Systems makes a LocalTalk to EtherTalk gateway similar to the
>Kinetics FastPath.  Cayman's "Gatorbox" also translates from
>AppleShare file protocol to NFS.  A mounted NFS volume on one of our
>Suns appears on our Macintosh desktops just like our AppleShare
>volume.

  Regaring the Cayman Gator Box--Does anyone know if it is possible to
use it to translate from the AppleShare to NFS and to also get to DECNET?  

Thanks, Lee
--
gatesl@netcom.uucp

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Jun 89 08:14 CST
From:      "Billy Barron, VAX System Manager" <BILLY@vaxb.acs.unt.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: CD/ROM players via TCP/IP
Path: ntvax!billy
From: BILLY@vaxb.acs.unt.edu (Billy Barron, VAX System Manager)
Newsgroups: tcpip
Subject: Re: CD/ROM players via TCP/IP
Message-ID: <1863@vaxb.acs.unt.edu>
Date: 19 Jun 89 08:13:51 GMT
References: <1726@vaxb.acs.unt.edu>
Lines: 14

In article <1726@vaxb.acs.unt.edu>, Tony Monteiro <MONTEIRO@GRAF.POLY.EDU> writes:
> Has anyone heard of anything that will allow a CD/ROM to be
> accessible via TCP/IP? I am especially interested in devices
> that can play multiple CD/ROM's. Thanks.
>  
One solution I know that will work is to have a CD-ROM on a PC and then run
NCSA Telnet on the PC in server mode.  

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAXB::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 08:13:51 GMT
From:      BILLY@vaxb.acs.unt.edu (Billy Barron, VAX System Manager)
To:        comp.protocols.tcp-ip
Subject:   Re: CD/ROM players via TCP/IP

In article <1726@vaxb.acs.unt.edu>, Tony Monteiro <MONTEIRO@GRAF.POLY.EDU> writes:
> Has anyone heard of anything that will allow a CD/ROM to be
> accessible via TCP/IP? I am especially interested in devices
> that can play multiple CD/ROM's. Thanks.
>  
One solution I know that will work is to have a CD-ROM on a PC and then run
NCSA Telnet on the PC in server mode.  

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAXB::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 14:14:00 GMT
From:      BILLY@VAXB.ACS.UNT.EDU ("Billy Barron, VAX System Manager")
To:        comp.protocols.tcp-ip
Subject:   Re: CD/ROM players via TCP/IP

Path: ntvax!billy
From: BILLY@vaxb.acs.unt.edu (Billy Barron, VAX System Manager)
Newsgroups: tcpip
Subject: Re: CD/ROM players via TCP/IP
Message-ID: <1863@vaxb.acs.unt.edu>
Date: 19 Jun 89 08:13:51 GMT
References: <1726@vaxb.acs.unt.edu>
Lines: 14

In article <1726@vaxb.acs.unt.edu>, Tony Monteiro <MONTEIRO@GRAF.POLY.EDU> writes:
> Has anyone heard of anything that will allow a CD/ROM to be
> accessible via TCP/IP? I am especially interested in devices
> that can play multiple CD/ROM's. Thanks.
>  
One solution I know that will work is to have a CD-ROM on a PC and then run
NCSA Telnet on the PC in server mode.  

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAXB::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 14:17:33 GMT
From:      chris@cayman.COM (Chris North)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac


 
>   Regaring the Cayman Gator Box--Does anyone know if it is possible to
> use it to translate from the AppleShare to NFS and to also get to DECNET?  

  At this time the GatorBox does not support DecNET routing.  We are very
interested in putting in this functionality, however I cannot give you an
approximate release date.  


-- 
Chris North                                chris@cayman.COM
Cayman Systems
26 Landsdowne Street
Cambridge MA  02139                        617-494-1999

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 17:18:15 GMT
From:      dgp@stc-auts.UUCP (Dave G. Pitts)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for IBM MVS/SP/XA

Hello world! I'm looking to connect IBM mainframes to TCP/IP using the
standard IBM TCP/IP software. Has anyone had any experience with this
package? I've heard rumors that it does not work. Also, what are the
best controllers/interfaces to use. We have been investigating the Intel
box.
 
 
--Thanks. Everbody needs a little slack -- Bob

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 17:30:39 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Internationalized Telnet

As I recall, the [*] design intent of <IAC> was to allow for alien character
sets in the usual fashion: if you want an <IAC> in the stream, double it;
otherwise (i.e., an <IAC> NOT followed or preceded by an <IAC>), it gets
interpreted.  But, then, that was a long time ago and if history is any guide
some key implementations will have ignored that precept and won't interoperate
it you try to apply it....
   cheers, map

[*] At least one other attendee of the relevant meeting told me five or six
years later that it was my design intent; even if it was (and I'm inclined
to accept it), though, presumably nobody these days cares much about design/
designer intentions, so pay it no more mind than is customary.
-------

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 18:30:57 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   IP/TCP/UDP/ICMP Specifications

I am curious about the specifications of IP/TCP/UD/ICMP on Berkeley machines.
Do the RFC's describe all the facets of the protocols?? I have heard about
something called Military Standards (MIL-STD-17xx) which describe the military
versions of the protocols. Do the protocols on the BSD machines have
characteristics from both the RFC's and MIL-STD's (There was mention of
MIL-STD's during the recent battle concerning SO_KEEPALIVE) ??

Also, are the MIL-STDS's a good reference and are they available by uucp
or anonymous ftp?

- Mark

------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 20:10:49 GMT
From:      hoodr@csusac.uucp (Robert Hood)
To:        comp.protocols.tcp-ip
Subject:   RARP daemon wanted


	Does anybody know where I could find a RARP daemon for UNIX?  I have
access to FTP and UUCP.  Send mail to ...csusac!hoodr. Thanks.

	Robert

-- 
-----------------------------------------------------------------------------
  Robert Hood   -- California State University:  Sacramento (ooooh...)

    UUCP:  ..csusac!hoodr

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 20:47:39 GMT
From:      estrin@USC.EDU (Deborah Estrin)
To:        comp.protocols.tcp-ip
Subject:   IEEE INFOCOM '90 Call for Papers

Here is a good place for submitting TCP/IP and other network related
research and experimental papers. 

INFOCOM '89 will take place in San Francisco, June 5-7 1990.
This is the Ninth Annual Joint Conference of the IEEE Computer and
Communications Societies and the theme is "The Multiple Facets of
Integration".

Authors are invited to submit full papers on recent advances in
computer communications. 

Schedule: Full paper (5 copies) due August 31, 1989
	  Notification Jan 1, 1990
	  Camera ready copies due Feb 15, 1990
	  Conference June 5-7, 1990

Submit papers to: Prof. M. Gerla, Technical Program Chair, IEEE
Infocom '90, Dept of Computer Science, UCLA-BH 3732H, Los Angeles, CA
90024 (213)825-2660.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 21:16:56 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.pcnet
Subject:   PCLAN/NetBIOS/TCP problem


I'm having a problem with IBM's PCLAN program.  The problem appears
with both versions 1.2 and 1.3 (I don't know about earlier versions).

I've noticed that when using either Ungermann-Bass PCNIUs (with Release
16.0 of their TCP/PC software) or WD8003E's (with PC/TCP v2.03 pl 1
software) the PCLAN server does not drop non-existent sessions.

Both of the HW/SW combinations are using the NetBIOS as referenced in
RFC's 1001 & 1002.

Clients who connect to the server are still "seen" by the server even
after the PC is turned off.  This presents a problem the next day when
the same clients attempt to connect to the server again.  If the server
has available NETBIOS/TCP sessions, then the client is able to re-connect.
However, this still leaves a non-existent session on the server end.
If the server does not have any available NETBIOS/TCP sessions, then the
client is not able to re-connect.

Is this a problem with PCLAN?
Is this a problem with my configuration of PCLAN?
   (I start the server via the following command: net start srv test /cac:0)
Is this a problem with both UB and FTP's software?
Is this a (RFC 1001/2) NetBIOS bug? 

Any help would be greatly appreciated.

Thanks.

--tony olejnik
  University of Pennsylvania
  Data Communications and Computing Services
  Suite 221A
  3401 Walnut Street
  Philadelphia, PA 19104
  (215) 898-9408
  tony@dccs.upenn.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 21:20:41 GMT
From:      alex@xicom.UUCP (Alex Laney)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

In article <647@wrs.UUCP>, hwajin@wrswrs.UUCP (Hwajin Bae) writes:
> 
> If you have their NFS for the SVR3 UNIX and TCP/IP (probably Lachman derived),
> you should be able to use RPC3.9 with minor modifications.  

I don't have their NFS. Their Host-based TCP-IP doesn't include it. With
their TCP-IP you could support System V Remote File System, not NFS, or
RPC. It did include the BSD networking daemons.
> ... If your TCP/IP doesn't
> implement all necessary socket calls, socket options, and ioctl's 
> you may run into some problems.  What kind of modifications did you have
> to make to the header files?
> 
The failure I got WAS in an ioctl call.

The mods I made were to change some of the #include lines that referred to
BSD includes, and substituted or added the include lines to refer to where
Interactive put them on my system. It compiled with no other problems.

I am now going to try with the other TCP-IP they supply, which supports an
Interlan board (NP600) exclusively. My interest is to support Xicom's own
product (SNA gateway) over TCP-IP lines. I hope that I can do it without
clashing with RPC products.



-- 
Alex Laney, Xicom Technologies Corp., Ottawa, Canada (613) 728-9099
uunet!mitel!sce!xicom!alex (NOT alex@xicom)     Fax: (613) 728-1134
"You save time, increase the amount of work done and it is easy."

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 89 22:59:03 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Sys V sources for tn3270 wanted

Recently, I asked about getting the BSD sources for tn3270.  Many
thanks go to Steve Talent and Peter Yee for helping out.  BUT,
since we have tn3270 up on Macs and Apollos (BSD4.3), the guys on the
HP machines (HP/UX, a Sys V port) are screaming

SO......

Is there a Sys V port available for this utility?

As always, thanks 1E6 (in advance)

-- 
Steve Scott            UUCP: {killer|texbell}!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 00:05:41 GMT
From:      azad@amdcad.AMD.COM (A.T. Hassani-Azad)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans,comp.arch
Subject:   Has anybody used SES/workbench, Network II.5, or COMMNET II.5

This is my first posting to USENET.

I would appreciate any information concerning the use of NETWORK II.5,
COMMNET II.5, or SES/workbench.  I am interested in using the above mentioned
products for network modeling and simulation.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1989 05:08-EDT
From:      CERF@A.ISI.EDU
To:        estrin@USC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IEEE INFOCOM '90 Call for Papers

Deborah,

here is another option for papers on networking - note
the prize $ for student papers.

Vint Cerf
Chairman, ACM/SIGCOMM
--------------------------------------------


------PRELIMINARY CALL FOR PAPERS

ACM SIGCOMM '90 SYMPOSIUM

Communications Architectures and Protocols

Philadelphia, Pennsylvania


 (Subject to ACM approval.)

The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.  Authors are invited to
submit full papers concerned with both theory and practice.  The areas
of interest for the symposium include, but are not limited to the
following: analysis and design of computer network architectures and
algorithms, innovative results in local area networks,
computer-supported collaborative work, network interconnection and
mixed-media networks, high-speed networks, resource sharing in
distributed systems, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words.  All submitted papers will be reviewed and
will be judged with respect to their quality and relevance.  Authors of
selected papers will be expected to sign an ACM copyright release form.
The Proceedings will be distributed at the symposium and published as a
special issue of SIGCOMM Computer Communication Review.  A few of the
submitted papers will be selected for publication in the ACM
Transactions on Computer Systems.  

Submit 5 copies of each paper to the program chairman: Phil Karn,
Bell Communications Research, Mail-stop 2P-357,
435 South St, Morristown, New Jersey, 07960, USA
Telephone: (201) 829-4299; EMAIL: karn@flash.bellcore.com

For more information about the symposium, contact Prof. David Farber,
General Chair, Professor of Computer and Information Science
and of Electrical Engineering, University of Pennsylvania,
200 South 33rd St, Philadelphia, Pennsylvania, 19104-6389;
Tel: (215) 898-9508 or 274-8192; EMAIL: farber@cis.upenn.edu


Papers on Networking In The Year 2000

One or more sessions of the conference will be devoted to the subject
of networking in the year 2000.  Papers in these sessions will focus
on key issues in building very fast (1 gigabit per second and faster) and/or
very large (200 million end nodes or more) data networks.  Persons interested
in submitting papers in this area are encouraged to contact either the
program chair, Phil Karn, or Craig Partridge (craig@bbn.com), who will
be coordinating the papers in this area.


Student Paper Award

Papers submitted by students will enter a student-paper
award contest.  Among the accepted papers, a maximum of four
outstanding papers will be awarded (1) full conference registration and
(2) a travel grant of $500 US dollars.


IMPORTANT DATES

Deadline for paper submission: March 20, 1990
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1989 05:18-EDT
From:      CERF@A.ISI.EDU
To:        m.cs.uiuc.edu!p.cs.uiuc.edu!zweig@UXC.CSO.UIUC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Specification vs. Implementation
Johnny,

Flaming aside, your points have merit. Please bear in mind, however,
that the RFCs were written rather a long time ago when the normal
programming paradigms and languages for communication protocol
implementation typically used concepts like pointers and
function calls/system calls.

It is HARD to write good specifications which are readable,
applicable to a variety of implementation methods, and specific
enough to really tie down the details. Erring in one direction
leaves you open to complaints about insufficient detail while
erring in the other leads to cries that you've bound the
implementation options too severely.

Have you done any implementions based on the OSI specifications?
Marshall Rose has, and I'm not sure he'd fully concur with your
apparent view that these specs are easier to use...

Vint Cerf
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 02:21:39 GMT
From:      alex@xicom.UUCP (Alex Laney)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

In article <8906141633.AA01919@sunned.sun.com>, warrens@SUN.COM (Warren Smith) writes:

When I hear the acronym NFS, I immediately think Sun's NFS running on a
TCP-IP Ethernet. And that is based on RPC.

> It sounds like you did not get the RPC from Interactive.  Why not?
> Don't they supply it external to NFS?

I haven't bought NFS either. I got their TCP-IP as part of being a
registered Independent Software Vendor, and developing for their X-11
Windowing System. Interactive's X depended on TCP-IP libraries for their
Alpha release. 

We here at Xicom are in a really early stage of investigating available
TCP-IP packages for System V/386 systems and LANs. I looked at RPC, because
I was given a manual for Netwise, Inc.'s NETWISE product. This is similar
in function to Sun RPC, but is somewhat more high-level. You can port
Netwise's product to any Network by describing a RPC specification
(describing procedures to make a call to a remote procedure) and split
your application across a network. It doesn't assume any specific type
of network library. They do sell pre-configured versions however.

Anyways, my point really was that I had seen an Interactive brochure that
listed RPC as part of THEIR NFS product. I stand corrected if I recall
                      ^^^^^
this incorrectly. (A lot of brochures go by my desk)

> You are welcome to share any changes that you make to RPCSRC for
> creating a reference version for Interactive's socket interface.
> Just leave the copyright notices intact, so that others are also
> allowed "freely licensed" access to the code you send out.  

I wasn't really planning to release anything. If we support Interactive's
TCP-IP/NFS/RPC, then we will have to buy it from them. It's the price of
admission. I'm quite willing to share my experiences with anyone, but it
hasn't been that serious a study so far.

> By the way, there is a RPCSRC 4.0 available in the sun-spots newsgroup
> at Rice University.  It was supposed to have made it into comp.sources
> last March, but I am not sure if it has actually gotten out yet.  This
> release contains Secure RPC, which has an improved authentication
> mechanism.  It also assumes a 4.3BSD base.

My news feed was missing for most of April and May, so I may have missed
Sun RPC 4.0. Anyone know for certain if it has been posted?

-- 
Alex Laney, Xicom Technologies Corp., Ottawa, Canada (613) 728-9099
uunet!mitel!sce!xicom!alex (NOT alex@xicom)     Fax: (613) 728-1134
"You save time, increase the amount of work done and it is easy."

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 09:08:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE INFOCOM '90 Call for Papers


Deborah,

here is another option for papers on networking - note
the prize $ for student papers.

Vint Cerf
Chairman, ACM/SIGCOMM
--------------------------------------------


------

ACM SIGCOMM '90 SYMPOSIUM

Communications Architectures and Protocols

Philadelphia, Pennsylvania


 (Subject to ACM approval.)

The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.  Authors are invited to
submit full papers concerned with both theory and practice.  The areas
of interest for the symposium include, but are not limited to the
following: analysis and design of computer network architectures and
algorithms, innovative results in local area networks,
computer-supported collaborative work, network interconnection and
mixed-media networks, high-speed networks, resource sharing in
distributed systems, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words.  All submitted papers will be reviewed and
will be judged with respect to their quality and relevance.  Authors of
selected papers will be expected to sign an ACM copyright release form.
The Proceedings will be distributed at the symposium and published as a
special issue of SIGCOMM Computer Communication Review.  A few of the
submitted papers will be selected for publication in the ACM
Transactions on Computer Systems.  

Submit 5 copies of each paper to the program chairman: Phil Karn,
Bell Communications Research, Mail-stop 2P-357,
435 South St, Morristown, New Jersey, 07960, USA
Telephone: (201) 829-4299; EMAIL: karn@flash.bellcore.com

For more information about the symposium, contact Prof. David Farber,
General Chair, Professor of Computer and Information Science
and of Electrical Engineering, University of Pennsylvania,
200 South 33rd St, Philadelphia, Pennsylvania, 19104-6389;
Tel: (215) 898-9508 or 274-8192; EMAIL: farber@cis.upenn.edu


Papers on Networking In The Year 2000

One or more sessions of the conference will be devoted to the subject
of networking in the year 2000.  Papers in these sessions will focus
on key issues in building very fast (1 gigabit per second and faster) and/or
very large (200 million end nodes or more) data networks.  Persons interested
in submitting papers in this area are encouraged to contact either the
program chair, Phil Karn, or Craig Partridge (craig@bbn.com), who will
be coordinating the papers in this area.


Student Paper Award

Papers submitted by students will enter a student-paper
award contest.  Among the accepted papers, a maximum of four
outstanding papers will be awarded (1) full conference registration and
(2) a travel grant of $500 US dollars.


IMPORTANT DATES

Deadline for paper submission: March 20, 1990

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 09:18:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Specification vs. Implementation

Johnny,

Flaming aside, your points have merit. Please bear in mind, however,
that the RFCs were written rather a long time ago when the normal
programming paradigms and languages for communication protocol
implementation typically used concepts like pointers and
function calls/system calls.

It is HARD to write good specifications which are readable,
applicable to a variety of implementation methods, and specific
enough to really tie down the details. Erring in one direction
leaves you open to complaints about insufficient detail while
erring in the other leads to cries that you've bound the
implementation options too severely.

Have you done any implementions based on the OSI specifications?
Marshall Rose has, and I'm not sure he'd fully concur with your
apparent view that these specs are easier to use...

Vint Cerf

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 14:47:08 GMT
From:      angel@cbnewsh.ATT.COM (angelique.m.anderson)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for a 3b20s running r&d

Has anybody had the experience of installing tcp-ip on a 3b20 running 2.1.1.1
r&d unix?  We have installed it and cannot use it. It crashes the system.
HELP!!!!!

I would appreciate any help,
Angel Anderson
AT&T Bell Labs, Holmdel, NJ (201) 949-0523

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 17:32:40 GMT
From:      4jde@s5000uunet!s5000 (jesse evans)
To:        comp.protocols.tcp-ip
Subject:   SWS avoidance


I have a question about the use of 'Eff.snd.MSS' in the receiver's SWS avoidance
algorithm as defined in section 4.2.3.3 of the Host Requirements RFC.
Should the algorithm use 'MRS - 20' instead of 'Eff.snd.MSS'?
-- 
Jesse Evans			UUCP: 	uunet!s5000!4jde
UNISYS - Computer System Group		4jde@s5000.sp.unisys.com
Roseville,MN 			AT&T: 	612-635-2299
		 

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 17:59:21 GMT
From:      wmg@cbnewsk.ATT.COM (william.m.gilroy)
To:        comp.protocols.tcp-ip
Subject:   subnets (how to use?)


I was wondering if anyone could explain (or show me where to
RTFM) on subnetting.  I have read the sun manuals on the subject
and it is still not clear.  What I am trying to do is have a 
server with two ethernets, but I do not want to route all 
the traffic on the main ethernet to the second ethernet.  
I don't understand how to set up the hosts file in relation
to the subnet mask.  Am I missing some simple?
I think subnets are just what I need.  If I am going about 
this all wrong, feel free to let me know.

Thanks,

Bill

William M. Gilroy - AT&T-BL Engineering Research Center
att!howard!wmg
(609) 639-2206  - CORNET 258
[ General disclaimer ]  - Nothing reserved except the right to send 
lawyers, guns, and money.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 19:06:56 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Add to the mailing list

Can I get stuck on the mailing list?

		Thanks,
			Mark
------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 89 20:02:36 GMT
From:      jwabik@uc.msc.umn.edu (jwabik)
To:        comp.protocols.tcp-ip
Subject:   Jacobson's Compression/Prediction code?  Docs?


I'm tring to get additional information (or code!  8^) on Van Jacobson's
TCP/IP Compression/Prediction software ..  I've been pointed to ucbarpa,
but couldn't find anything there ....

Any info would be appreciated.

Thanks ..

	-Jeff

--
Jeff A. Wabik				E/Mail:	 jwabik@msc.umn.edu
Minnesota Supercomputer Center 		AT&T:    +1 612 626 0211
Minneapolis, MN  			FAX:     +1 612 624 6550

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 89 17:16:00 MDT
From:      "2645 Breckenridge, Autherine" <arbreck@sandia.gov>
To:        "hostmaster" <hostmaster@sri-nic.arpa>
Subject:   TCP-IP-REQUEST
Please add arbreck@sandia.gov to the list tcp-ip-request.  Thank you.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 89 12:43:54 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip
Subject:   Re: Jacobson's Compression/Prediction code?  Docs?

Van said that he has submitted the tcp compression as an rfc.  A few people
are reviewing it now.  Provided the reviewer don't find any major problems
with Van's rfc they will issue a rfc number and the code will go up on ucbarpa.
This might happen around the begining of July.

Cheers,
Mark A. Verber			Physics Department, Ohio State University
verber@mps.ohio-state.edu	174 West 18th Avenue
614-292-8002			Columbus,  OH 43210

   There are two major products that come out of Berkeley: LSD and
   BSD UNIX.  We don't believe this to be a coincidence.

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 89 13:20:25 GMT
From:      alan@s5000uunet!s5000 (Al Kiecker)
To:        comp.protocols.tcp-ip
Subject:   SWS avoidance

Sorry if this is a repeat posting ... we may have a problem with our news
system....



I have a question about the use of 'Eff.snd.MSS' in the receiver's SWS avoidance
algorithm as defined in section 4.2.3.3 of the Host Requirements RFC.
Should the algorithm use 'MRS - 20' instead of 'Eff.snd.MSS'?
-- 
Jesse Evans			UUCP: 	uunet!s5000!4jde
UNISYS - Computer System Group		4jde@s5000.sp.unisys.com
Roseville,MN 			AT&T: 	612-635-2299
		 
-- 
Al Kiecker			UUCP: 	uunet!s5000!alan
UNISYS - Computer System Group		alan@s5000.sp.unisys.com
Roseville,MN 			AT&T: 	612-635-2574
		"Don't Worry, Be Happy" 

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 89 23:16:00 GMT
From:      arbreck@SANDIA.GOV ("2645 Breckenridge, Autherine")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP-REQUEST

Please add arbreck@sandia.gov to the list tcp-ip-request.  Thank you.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 07:08:52 GMT
From:      herb@linkit.FIDONET.ORG (Herb Crosby)
To:        comp.protocols.tcp-ip
Subject:   DIAL-UP slip availability


 pz> From: paolo@semto.UUCP (Paolo Zeppegno)
 pz> Date: 17 Jun 89 10:18:02 GMT
 pz> Organization: Systems & Management (Torino - Italy)
 pz> We are in urgent need of an implementation of a dial-up slip.
 pz> We know there are some implementation around, but there seem
 pz> to be
 pz> nothing in the public domain. If someone has informations about
Seems the last release of the KA9Q's PD code had dial-up slip iwth 
with the attach command.  You fed it the number and other params 
on the attach just like you would the L.SYS file in UUCP.
look for the .1 version of april release.  if you can not get to 
it on belcore or via the net call here in the states to (713) 480-1840.
that's my bbs and it has it posted with a limit of 360k download 
per 24 hr. so it would take about 3 days to get the source/exe/doc's
if you have a fidonet connections it is net 106/node 7873 in zone 
1. and is file requestable.
--  
Herb Crosby - via FidoNet node 1:106/7873
UUCP: ...!splut!linkit!herb
ARPA: herb@linkit.FIDONET.ORG
serviced via UFGATE 1.0

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jun 89 15:09 MST
From:      Terry Wimmer <WIMMER@rvax.ccit.arizona.edu>
To:        TCP-IP@sri-nic.arpa
Subject:   Resign from list
I need to resign from this list from now until the end of July due in part to vacation.

thanks

Terry Wimmer

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1989 13:43:32 EST
From:      OMKAR.P..RATH@EVAX.ARL.UTEXAS.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Help needed on Socket Programming! (Sorry if this is a repeat)

To TCP/IP Internetworking Gurus:

I am a Master's student at the U of Texas at Arlington.

I have a question about "socket programming" under the 4.2 BSD Unix system.
You can call me a novice in the field of systems programming at the network
level.  I browsed thru the different Users Groups and found yours to be the
closest thing that could possibly help me.

The Query:
----------
I have been assigned the job of implementing the "transport layer" for a 
particular distributed application.  This will constitute a set of processes
running on each of the nodes.  Needless to say these processes will need to
"talk" to each other.  However the "talking" occurs only sparingly and rest
of the time the processes are busy doing other things of higher importance.

What I'm looking for is a "non-blocking" message passing kind of mechanism
where the processes can deposit messages into other processes' "mailboxes"
and continue on their own.  I understand the theory but when it comes to the 
implementation I'm stuck.  Can a process "deposit" a message in another process'
"mailbox" while the latter process is say servicing a User input? (Sort of
like getting interrupted and coming back.)

Question 1: Any suggestions, ideas, references?

IPC primitives by way of using sockets seems to be the way to go.  I came 
across a System V manual by AT&T called "Network Programmers Guide"
(ISBN # 0-13-940461-9) which explains just the kind of thing that I'm looking
for (ref. CH 6).

Question 2: We here at the Univ. of Texas @ Arlington have SUN 3/50(60) work-
stations running 4.2 BSD.  Does any one know of a "Network Programmers
Guide" or manual for the 4.2 BSD?

Those of you who are into this sort of thing will at once know what I'm
talking about.  Thanks in advance for your time.

Sincerely,

Omkar Rath
CS_RATH@EVAX.ARL.UTEXAS.EDU
Internet Address: 129.107.2.1
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 14:20:16 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for VMS

Does anyone have a tn3270 implementation for VMS systems?

Thanks,
Hank

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 16:43:46 GMT
From:      fossum@VACS.UWP.WISC.EDU (Timothy Fossum)
To:        comp.protocols.tcp-ip
Subject:   SLIP drivers for IBM 43xx machines

I'm looking for a SLIP driver for an IBM 4381, probably using a 7171
box.  Does anyone have information about whether such a beast exists?
We have the requisite VM TCP/IP software installed, but as yet no
line to the outside (Internet) world.  Thanks in advance.
-----------------------------------------------------------------------------
Timothy Fossum -- UW-Parkside -- Wood Road, Box No. 2000 -- Kenosha, WI 53141
Department of Applied Computer Science -- fossum@vacs.uwp.wisc.edu (Internet)

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 17:21:39 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.sys.misc
Subject:   Wanted -- r-syite for Unisys DDN1100 package.

Wanted -- a Unisys 1100 peer to the BSD r-suite commands, rexec and rsh. This
would allow a program to initiate commands on a remote OS1100 host, and vice-
versa, over the TCP/IP protocol stack.

Ths Unisys environment is: System base 3r2, DDN1100 3r2 in the host for FTP
(but no SMTP) with TCP-IP stack in the DCP.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 18:43:32 GMT
From:      OMKAR.P..RATH@EVAX.ARL.UTEXAS.EDU
To:        comp.protocols.tcp-ip
Subject:   Help needed on Socket Programming! (Sorry if this is a repeat)


To TCP/IP Internetworking Gurus:

I am a Master's student at the U of Texas at Arlington.

I have a question about "socket programming" under the 4.2 BSD Unix system.
You can call me a novice in the field of systems programming at the network
level.  I browsed thru the different Users Groups and found yours to be the
closest thing that could possibly help me.

The Query:
----------
I have been assigned the job of implementing the "transport layer" for a 
particular distributed application.  This will constitute a set of processes
running on each of the nodes.  Needless to say these processes will need to
"talk" to each other.  However the "talking" occurs only sparingly and rest
of the time the processes are busy doing other things of higher importance.

What I'm looking for is a "non-blocking" message passing kind of mechanism
where the processes can deposit messages into other processes' "mailboxes"
and continue on their own.  I understand the theory but when it comes to the 
implementation I'm stuck.  Can a process "deposit" a message in another process'
"mailbox" while the latter process is say servicing a User input? (Sort of
like getting interrupted and coming back.)

Question 1: Any suggestions, ideas, references?

IPC primitives by way of using sockets seems to be the way to go.  I came 
across a System V manual by AT&T called "Network Programmers Guide"
(ISBN # 0-13-940461-9) which explains just the kind of thing that I'm looking
for (ref. CH 6).

Question 2: We here at the Univ. of Texas @ Arlington have SUN 3/50(60) work-
stations running 4.2 BSD.  Does any one know of a "Network Programmers
Guide" or manual for the 4.2 BSD?

Those of you who are into this sort of thing will at once know what I'm
talking about.  Thanks in advance for your time.

Sincerely,

Omkar Rath
CS_RATH@EVAX.ARL.UTEXAS.EDU
Internet Address: 129.107.2.1

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 20:37:05 GMT
From:      sxn@SUN.COM (Stephen X. Nahm)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC Library sources for System V

In article <120@xicom.UUCP> alex@xicom.UUCP (Alex Laney) writes:
>My news feed was missing for most of April and May, so I may have missed
>Sun RPC 4.0. Anyone know for certain if it has been posted?

Not that I know of.  I sent an upgrade package (RPCSRC 3.9-to-4.0) to the
comp.sources.unix moderator in November; still hasn't shown up here.

But you can get the full RPCSRC 4.0 package from several places:

1) It appeared on the Sun User's group "SEX" tape in the rpc4.0 directory.

2) It is available via anonymous ftp from bcm.tmc.edu and from the
   archive-server@bcm.tmc.edu.  If you use the archive server, send mail to
   archive-server@bcm.tmc.edu with a Subject of "send nfs index" to see all the
   names of the files.  There are 17 shar files in RPCSRC and 4 for secure rpc.

3) I also dropped it off at titan.rice.edu (the sun-spots archive).  It was
   still sitting in the "incoming" ftp directory there the last time I looked.

You can also order it from Sun for $100, but if the tape isn't in stock it will
take several weeks to get it.  Call 800-USA-4SUN and ask for:

    RPC-4.0-X-X-5   For 1/4" cartridge tar tape
    RPC-4.0-X-X-6   For 1/2" 1600BPI tar tape; or

The major new thing in RPCSRC 4.0 over 3.9 (besides some minor bug fixes and
enhancements) is the inclusion of Secure RPC.  Unfortunately, I could not
include any DES code, which is required.  (The rest of RPCSRC 4.0 was set up to
not require Secure RPC, so the main library still works.)  I'm hoping to get
some time to write an interface between the Secure RPC code and the DES code
that was posted to comp.sources.unix a while back.  (Has anyone already done
this?)

-- 
Steve Nahm                              sxn@sun.COM or sun!sxn

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jun 89 17:20:16 P
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   tn3270 for VMS
Does anyone have a tn3270 implementation for VMS systems?

Thanks,
Hank
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 21:42:05 GMT
From:      carson@tron.UUCP (Dana Carson)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   TCP/IP for HP3000


We are currently looking for a good TCP/IP implementation for an HP3000 running
MPE.  So far all we have discovered is Wollongong, whose VAR is a bit too
"uncooperative".  Would appreciate any alternatives, especially if you have
experience with them.  Also comments on the Wolly product.

Marty Adkins
Westinghouse Electric Corp.
Baltimore, MD.
(301)765-1479
VSG%Plaza.dnet%tron.UUCP@umbc3.UMBC.EDU

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 22:09:00 GMT
From:      WIMMER@RVAX.CCIT.ARIZONA.EDU (Terry Wimmer)
To:        comp.protocols.tcp-ip
Subject:   Resign from list

I need to resign from this list from now until the end of July due in part to vacation.

thanks

Terry Wimmer

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 23:10:18 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE INFOCOM '90 Call for Papers

Some minor corrections to the ACM SIGCOMM '90 call for papers:

My snail mailing address is

	Phil Karn
	Bellcore
	Room 2P-357
	445 South St
	PO Box 1910
	Morristown, NJ 07962-1910

and my email address is karn@thumper.bellcore.com.

The addresses given in the announcement will work, but these are more
direct.

I would especially like to encourage papers in the field of very high
speed packet switching, where "very high speed" means speeds of 150
megabits/sec or more.  Topics covered could include high speed packet
switch architectures, host interfaces, access protocols (including
fragmentation/reassembly protocols and algorithms), transport
protocols designed for high bandwidth-high delay paths, network resource
management, etc.

Phil

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 89 23:25:42 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring Patent


I saw the following article a few weeks ago in comp.protocols.tcp-ip.

>          Unfortunately, I know quite a bit about the Soderblom
>          patent. It was first issued in the fall of 1981 after much
>          consideration at the Patent Office. The senior patent in
>          this area is Farmer and Newhall (AT&T). During the '70's,
>          there were several interferences between the claims of
>          Soderblom and those of Farmer and Newhall.  The Farmer and
>          Newhall design, patented in 1971, was used by Dave Farber to
>          help in the creation of the UC Irvine Ring (If I'm wrong,
>          Dave, Please correct me). Then, Jerry Saltzer, Dave Clark,
>          Ken Pogren and a bunch of people here at Proteon used the UC
>          Irvine Ring to help in the creation of ProNET-10.
 
>          Proteon never expected patent problems. In fact, in 1982, I
>          presented details of our design at IEEE Headquarters in NYC
>          to many AT&T employees including Bob Lucky. We joked about
>          the fact that I was using BSTJ figures for my presentation,
>          thus bringing new meaning to the phrase "not invented here".
>          The Soderblom patent applied to systems which consisted of a
>          master and a plurality of terminals. Farmer and Newhall was
>          the senior patent when it came to closed loop operations.
 
>          In 1983 or maybe 84, Soderblom presented at IEEE802.5. We
>          were well aware of the Soderblom position. IEEE staff were
>          also involved. We went ahead on the basis that Soderblom
>          would provide licenses in a nondiscriminatory way. We also
>          had a good idea of the probable terms for such a license.
 
>          Since that time, the Patent Office has allowed a reissue of
>          the Soderblom patent. The reissue has much more general
>          claims. Many organizations filed objections which were
>          brushed aside by the patent Office. That's why he has
>          general coverage of a 1967 idea until 1998. His patents have
>          run out elsewhere in the world. Don't blame Olaf.
 
>          Many of us object to the whole procedure. That is, Was the
>          token ring a new concept or an" old combination" in 1967?
>          Many of us object to the details of the legal rangling.
>          Nonetheless many of us have signed up simply because the
>          patent office has spoken. In all cases, the exact terms of
>          the license are covered by a non disclosure clause.
 
>          It is also clear that some have chosen not to sign a
>          license with Soberblom. It is expected that someone will
>          take this to court for resolution.  Time will tell.
 
>          Howard Salwen, Chairman-Founder
>          Proteon, Inc.
>          hs@relay.proteon.com


I looked up the patent abstract in the Patent Office Official Gazette
of October 6, 1981.  The engineering library at MIT has a
subscription. On page 420 is found patent number 4,293,948, Data
Transmission System, whose abstract follows.

1.  Apparatus for the transmission of data characters in pulse form
from a plurality of terminal units to a master unit comprising in 
combination:

	pulse input and pulse output means for each said terminal
	unit and for said master unit,

	a single series loop connecting said terminal units in
	series along said loop between the pulse output means
	and pulse input means of said master unit and over which
	pulses originating either with said master unit or any
	terminal unit are transmitted always in the same
	predetermined direction,

	each said terminal unit including:

	(a) pulse responsive means connected to said pulse input means
	for receiving pulses appearing at said pulse input means,

	(b) decoding means distinctively responsive to pulses
	received by said pulse responsive means,

	(c) and logic means responsive to said decoding means for
	normally interconnecting said pulse input and pulse output
	means to thereby complete the loop at said terminal, unit,

	(d) said logic means in response to a distinctive pattern
	of said pulses appearing at the associated pulse input
	means interrupting the loop between said pulse input and
	pulse output means of stored data of arbitrary variable 
	length as required by said terminal unit for transmission
	over the loop to said master unit,

	(e) said logic means being effective upon the opening of 
	said at the first upstream terminal unit having data to
	send for inhibiting the receipt at any downstream terminal
	unit of pulses otherwise effective to control said downstream
	terminal unit to transmit data.

---------------------------------------------------------------------

As usual, the language is totally obscure, and if the actual patent
is similarly written, I would feel that the patent officer would have
been negligent not to have rejected the application on those grounds
alone.  I wrote away for the complete patent (it only costs a $1.50)
but if this abstract contains the key elements of the patent, the
issue of whether the token ring was a new concept or an old
combination in 1967 seems totally irrelevant.

From the abstract, Soderblum seems to have patented a circuit which
is an intelligent unidirectional digital repeater/transceiver.  The
intelligence involves the ability to become a transmitter of queued
data upon reception of signals (a packet) on the receive input.
Clearly, the 802.5 MAU is such an intelligent unidirectional digital
repeater/transceiver.  Likewise, the FDDI MAU contains two
intelligent unidirectional digital repeater/transceivers.  However, I
doubt either MAU has any circuits borrowed from the Soderblom
circuit.

Now, I would consider the following scenario analogous to what
Soderblom has achieved at the patent office.

It is 1890 and I build the first electric stove which I patent.
After I start selling my electric stove, other people begin selling
electric stoves.  However, their heating elements, control elements
and insulation are completely different.  In fact, other
manufacturers begin manufacturing toasters and perculators and other
devices which cook or prepare food using heat generated by
electricity.

I then go off and accuse all of these other manufacturers of patent
infringement.  I would hope that the court would find my claims
gratuitous except in the case of a stove manufacturer who had copied
my original electric stove down to the nuts and bolts.

In other words, I would have rights to my own design and that's all.
Purporting to owning the concept of cooking with
electrically-generated heat would seem a bit presumptuous.

The Soderblum patent is equally presumptuous.  Unidirectional digital
repeaters have been around since the 50s.  Adding a circuit so that a
digital repeater receiving a signal from the receive input could
become a transmitter is a nice little modification, and it might even
have been slightly difficult using 1967 hardware logic and it may
even be reasonable to give Soderblum a patent for that specific 1967
circuit which no one in their right mind would ever use today.
However, the trend to make relative dumb repeating, amplifying and
filtering devices ever more intelligent through the addition of
interpretive or program-type logic has existed in electronics since
the first electronics engineers began working at the job and
certainly has increased with the availability of microcontroller
chips, PLAs and PLDs. 

There is no obvious justification in granting patent rights over all
circuits which constitute a class distinguished from a pre-existing
class of circuits simply through minor extensions to enable some
interpretation of incoming data with the result that the behavior of
the circuits might be altered on the basis of interpretation.



Joachim Martillo



	

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 05:28:21 GMT
From:      VSBENZI@WEIZMANN.BITNET (Benzi mizrahi)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS for the mac

Hello all,

   Since the name of Cayman Gator box has been mentioned in this
   discussion, I'd like to post a question about it.

   Can we  do  mount, from a Mac connected to ethernet via GatorBox,
   to VMS host running FUSION nfs server? Is there anyone out who
   succeeded in this task? Thanx, benzi

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jun 89 18:47:58 -0700
From:      streeter@nsipo.nasa.gov
To:        tcp-ip@sri-nic.arpa, ietf@venera.isi.edu
Cc:        villasenor@oblio.arc.nasa.gov
Subject:   Solicitation for networking experiments
This mail message is being redistributed to the general networking
community while STRONGLY EMPHASIZING that (a) the due date is July 5, 1989,
and (b) the requirement is for experiments in POLICY mechanisms (rather
than applications).
----------------------------------------------------------------------------

 ------- Forwarded Message
>> Return-Path: richer@vax.darpa.mil
>> Received: Mon, 19 Jun 89 21:53:18 -0700 from merit.edu by nsipo.arc.nasa.gov (5
>> .61/1.5)
>> Received: Mon, 19 Jun 89 23:46:35 EST from VAX.DARPA.MIL by merit.edu (5.59/1.6
>> )
>> Received: from sun29.darpa.mil by vax.darpa.mil (5.54/5.51)
>> 	id AA26216; Mon, 19 Jun 89 15:24:00 EDT
>> Posted-Date: Mon 19 Jun 89 15:29:51-EDT
>> Received: by sun29.darpa.mil (5.54/5.51)
>> 	id AA00534; Mon, 19 Jun 89 15:29:52 EDT
>> Date: Mon 19 Jun 89 15:29:51-EDT
>> From: Ira Richer <RICHER@vax.darpa.mil>
>> Subject: solicitation
>> To: fepg@merit.edu, IAB@venera.isi.edu, PFRICC@vax.darpa.mil
>> Cc: richer@vax.darpa.mil
>> Message-Id: <614287791.0.RICHER@SUN29.DARPA.MIL>
>> Mail-System-Version: <SUN-MM(217)+TOPSLIB(128)@SUN29.DARPA.MIL>
>> 
>> Folks,
>> 
>> please act on the following and circulate it to anyone who may be interested.
>> 
>> ira
>> - ---------------
>> 
>>                 SOLICITATION FOR NETWORKING EXPERIMENTS
>> 
>> Summary
>> 
>> The purpose of this note is to solicit ideas for networking 
>> experiments using high-capacity links and gateways that will soon be
>> available through the government. 
>> 
>> 
>> Background
>> 
>> By early fall of '89 DARPA will have installed the DRI (Defense
>> Research Internet), three cross-country T1 trunks with drops at
>> roughly eight sites on each trunk.  Each trunk will have a drop at
>> NYSERNET in New York and at Ames in California where the trunks will
>> be interconnected; other drops are in general different for each
>> trunk.  One trunk each is nominally assigned to DARPA, DOE, and NASA
>> for experimental/research use.  The DRI will be in place for about 
>> two years and thus represents a valuable resource to the research 
>> community (4.5 Mbps-year worth of research!). 
>> 
>> In addition to the DRI, DARPA also has contracts with three vendors
>> to develop high-performance gateways, RIGs (Research Internet 
>> Gateways), with "modular" software, the intent being to facilitate 
>> experiments with new networking algorithms.  The RIG contractors 
>> are BBN, GTE (with Proteon), and SRI (with Cisco).
>> 
>> 
>> Ground Rules
>> 
>> This is a solicitation for IDEAs, not proposals.  There are no funding
>> implications associated with this solicitation, although there may be
>> a broader, more formal solicitation in the future that could have a
>> funding intent.
>> 
>> Of particular urgency now are suggestions for initial experiments
>> that can be implemented quickly (within a few months) so that we can
>> begin to use the DRI capacity when it becomes available.  Experiments
>> should use RIGs, but if necessary and appropriate, other devices may 
>> be proposed.
>> 
>> Because the DRI and RIGs will be experimental but will be linked to the 
>> Internet (which is operational), the DRI will be a closed environment;
>> that is, packets must be specifically directed toward the DRI.
>> 
>> Experiments in the general area of "policy mechanisms" are of the most
>> interest at this time.  Policy mechanisms include "policy-based"
>> routing, capacity allocation, and accounting.  However, we have
>> concluded that short-term experiments on policy-based routing are
>> probably impractical primarily because the short-term time frame is 
>> not commensurate with the effort required; nevertheless, ideas for 
>> experiments that refute this conclusion are most welcome.
>> 
>> Experiments in other areas (e.g., multicasting, applications) will
>> also be considered.
>> 
>> 
>> Action
>> 
>> Please send any ideas to richer@vax.darpa.mil, and include the
>> following information (a lot of detail is NOT required):  purpose;
>> description of configuration; explanation of why the DRI is an
>> appropriate testbed; what hardware is needed and what software must be
>> implemented (in hosts, gateways, agents, etc.); test traffic ("real"
>> or artificial) to be used; rough estimate of professional time
>> needed to get it going; and anything else you think is appropriate.
>> 
>> Implementation of some of the experiments might require information 
>> from the RIG vendors, and in fact some could conceivably influence 
>> the design of the RIGs.  There will be a RIG design review beginning 
>> July 17.  Also, the FRICC Engineering Planning Group that will 
>> review proposed experiments meets next on July 6  Therefore, if at 
>> all possible, submit ideas by July 5; if not by that date, then 
>> try to have them in before July 12.
>> 
>> Please circulate this message to anyone who may be interested in this
>> activity. 
>> - ---------------------------
>> 
>> ------- End of Forwarded Message
>> 


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jun 89 08:28:21 +0300
From:      Benzi mizrahi <VSBENZI%WEIZMANN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: NFS for the mac
Hello all,

   Since the name of Cayman Gator box has been mentioned in this
   discussion, I'd like to post a question about it.

   Can we  do  mount, from a Mac connected to ethernet via GatorBox,
   to VMS host running FUSION nfs server? Is there anyone out who
   succeeded in this task? Thanx, benzi
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 14:57:41 GMT
From:      genej@ecsvax.UUCP (Gene Jackson)
To:        comp.protocols.tcp-ip
Subject:   Internet Systems Corp.

I am trying to locate Internet Systems Corp.  which advertised a Mac
implementation of the NCSA Telnet product called TCP/Connect.   They
were in Reston, Va but I can not locate them by directory assistance.
Does anyone know if this product is still being sold either by them
or some other company?

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 15:01:51 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Proxy ARP and the RIP protocol


I'm not real sure where to get the proxy ARP code BUT for info on
ARP, RARP, proxy ARP, etc, etc, I can recommend the following book

Internetworking with TCP/IP - Principles, Protocols, and Architecture

by Douglas Comer
Prentice-Hall

ISBN 0-13-470154-2


-- 
Steve Scott            UUCP: {killer|texbell}!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 15:18:10 GMT
From:      HAL@SRI-NIC.ARPA (Hal Huntley)
To:        comp.protocols.tcp-ip
Subject:   SLIP for HPs

It has been a while since I have read this mailing list, so forgive me 
if I am duplicating a question recently asked. I have access to the
archives if the pointers are in there.

I'm looking for a SLIP implementation for HP's 9000 series computers
and for HP workstations running HP-UX. A commercial implementation
would be nice, but if there is something equivalent to what can be 
obtained for SUNs, that would be OK too.

Thanks,

Hal Huntley
SRI International
Phone: (415) 859-2236
Internet: hal@sri-nic.arpa   or   hal@spam.istc.sri.com
-------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 17:25:58 GMT
From:      raj@hpindwa.HP.COM (Richard Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for HP3000

/ hpindwa:comp.protocols.tcp-ip / carson@tron.UUCP (Dana Carson) /  2:42 pm  Jun 22, 1989 /

We are currently looking for a good TCP/IP implementation for an HP3000 running
MPE.  So far all we have discovered is Wollongong, whose VAR is a bit too
"uncooperative".  Would appreciate any alternatives, especially if you have
experience with them.  Also comments on the Wolly product.

Marty Adkins
Westinghouse Electric Corp.
Baltimore, MD.
(301)765-1479
VSG%Plaza.dnet%tron.UUCP@umbc3.UMBC.EDU
----------

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 19:10:35 GMT
From:      rlk@tusun2.knet.utulsa.edu ( Richard L. Kruse II)
To:        comp.protocols.tcp-ip
Subject:   Best TCP/IP for a VAX with VMS



After sifting through the requests for more info on this
subject, and receiving some pointers on summary posting
(thanks, Thomas Brisco!), I decided to make a stab at posting
a summary of the replies I received (I actually received 26). 

Thanks again to all of you who took time to respond. The 
replies helped us make an informed decision. The decision
was basically between MultiNet from TGV and WIN/TCP from
The Wollongong Group.

What was the decision, you ask? Well, we finally chose the 
MultiNet product from TGV (we are actually dealing with SRI).
Some of the factors used in making the decision included 
availability of source code (thus making patches over the net
possible and easy), UNIX-like utilities (RPC, FINGER, WHOIS,
LPD, R-commands, TALK), and the pricing. 

Let me point out that both Wollongong and TGV offer NFS servers,
GATED routing and SNMP, as well as the standard TCP/IP stuff.

I was pleased and impressed that representatives from both
of the top contendors, TWG and TGV, took time to reply
to my query as well; nice to see them involved!

To assist any of you who might need this, here are the contacts
I know of for the "top two":

TGV: Desiree@Warbucks.AI.SRI.COM (Desiree Champagne)
TWG: djw@twg.com (Dennis Wong) [I hope this is the right person -
	we actually dealt mostly with DEC re: Wollongong - rlk]

Rick Kruse
University of Tulsa

Now for the (long) summary (drum roll here...)

******************************************************************************
As I stated previously, the top vendors of choice here seem to
be TGV (with MultiNet) and Wollongong (with WIN/TCP).
There were a few votes for others, including Fusion, Ultrix and
4.3 BSD (I *wish* we could run U**x ;-}).

******************************************************************************
From: enger@sccgate.scc.com ( Robert M. Enger)

We use wollongong.  
[Some stuff deleted here. -rlk ]

The Multinet product (that used to be available from SRI) is supposed
to be good.  Kashtan (?) and another person are supposed to have left
SRI to continue development of Multinet for commercial sale.  Maybe
SRI can direct you to them for further info.

The other little guys are in general WAY WAY OUT OF DATE.
They lag way behind the latest internet engineering.

if you want discriminators, ask possible vendors how much of the
Jacobson/Karels/Karn upgrades they have implemented.  slugs like Bridge
and CMC won't even know what you're talking about.  While wollongong
hasn't done the header template prediction stuff, they have done the
slow start/congestion control stuff, a good sign in my opinion.


******************************************************************************
From: "Louis A. Mamakos" <uunet!trantor.umd.edu!louie>

Run Ultrix on your VAX 6320.  It has all of the TCP/IP networking you need
for free already included.

******************************************************************************
From: uunet!proteon.com!jas (John A. Shriver)

I think Wollongong remains the best.  Forget Network Research Fusion,
it's been a cruel hoax in my experience.  You might want to look at
Process Software's package, its doesn't have all the bells and
whistles that Wollongong does, but it's solid.  Also, they are small
enough that support comes from the developers, which is a big win for
you.


******************************************************************************
From: Ed Frankenberry <uunet!BBN.COM!ezf>

Have you talked to DEC about VUX "the VAX-Ultrix connection"?
It was in beta test the last time I checked, and may be available now.
It is/will be a standard layered software option.

[This wasn't available when we talked to DEC, and also didn't provide
the flexability we were looking for - seemed to use a Ultrix machine
as a gateway, and from our conversations the product seemed to add
to the complexity of networking, just what we *don't* need. -rlk]

******************************************************************************
From: Yehavi Bourvine +972-2-584279 <uunet!CUNYVM.CUNY.EDU!YEHAVI%HUJIVMS.BITNET>

I have exactly the same problem as you have. We are buying a VAX-6330 and
have to support more than 100 incoming TELNET sessions. The replies I got for
my message specify Wollgong and MultiNet as the ones that will do the job.
We've finally choosed MultiNet (I've ordered an evaluation copy to test it
before we buy it) because it seems (according to the publications) better
and comes with full sources (and has site licence in good price...).
I enclose here all the replies I got, including my correspondence with
the MultiNet people.

[Interesting replies included... -rlk]

From: pack@acdpyr.UCAR.EDU (Dan Packman)

We run Wollongong 5.0.1 (the first SMP version of their product) and if
anything it is more robust than previous versions under VMS V4.x.  Their
early products were seriously flawed, but I can wholeheartedly recommend
the current release.  Dec has muddied the waters by announcing their own
tcp/ip implementation that initially will only allow Decwindows to
operate but might eventually have a user level (ftp, telnet, etc).  Dec's
product might ultimately prove the best and most seamless, but right now
they don't have a complete product.


From: Lori Corrin <purple@hadrian.uwo.ca>

I'm the person around here responsible for our multinet software.
We tried running the fusion software around December 88 and there
were still SMP problems. Multinet seems to have solved them.
We did have to run through a few patches for some wierdness but
it never took more than a day for me to get a patch ftped to me.
We tend to use rlogin from our terminal servers (we have a number
of unix boxes).  The rcommands are part of the distribution. Along
with some other real nice features. From what we could tell the
system seemed to slow down when we hit 110+ users (as a 6230) but
we were never able to determine if the slowdown was the cpu or
multinet although I'm tending to suspect the cpu since I haven't seen
the problem since we upgraded to a 6330. I would expect approx the same
performance from telnet since they are both implementing through the
multinet kernel.
The annoyances tend to relate to signal processing  (ie ^C doesn't
respond immediately but after the next buffer). We have to put a
monitor on it to find that problem. The other problems involve some
wierdness to our suns in ftp.

The one thing lacking in the Multinet I find is the documentation they
shipped me an improved version without the improved documentation but I
knew that when I asked for it. The existing documentation works fine
but some of the new features aren't documentated. (like rlogin) My copy
included source and I used that if I had problems following what was
going on.

Multinet also has an NFS server side available and are working on a
client side I believe.


From: Lori Corrin <purple@hadrian.uwo.ca>

We have some problems with flow control. With ^O/^C the abort output flag
doesn't seem to be a priority packet it waits till the current buffer is done.
This could be a problem with our terminal server, we're going to put a monitor o
n it to see who's not doing what.
Also ftp doesn't support type tenex which is a bit inconvient. and we've found
a wierd problem that happens to our suns were a  ftp connection is made to
the suns and every other user command  (in the same ftp session) takes a few
minutes to respond with the password prompt. Again we're not sure were the
problem originates with this one.
With the remote printer service an ^L seems to get sent at the beginning of a
job to the remote printer which was screwing up our postscript. We're told that
one is a VMS symbiont problem so wrote a simple filter to check the first couple
of characters and see if it's a postscript file and if it is strip out the
preceding characters.
The sources are in gnu C (they supply gnu C as well.) but it seems to use some
of the VMS libraries.
It supports a variety of devices: ethernet, arpanet, x.25 and chaosnet. It also
handles ip over decnet  and shared vms ethernet. It will run decnet over ip as w
ell. Those are the ones in my manuals If you're looking for something specific
you might talk to ken adelman (adelman@tgv.com) he's the technical support for m
ultinet and they may have some devices available that aren't in my documentation


From:     adelman@TGV.COM (Kenneth Adelman)

> 1. I guess the MultiNet can use a dedicated ethernet controller (DEUNA etc).
>    without running DECnet on it. Right?

    Correct. And the procedure is exactly the same as if DECnet was
running.

> 2. Is it possible to remove and re-use (as the system's manager will) the
>    various utilities, like some of Rxxx, or replace the SMTP server with
>    my own one?

    Yes. You can replace clients by defining symbions to invoke yours,
and replace servers by using the server configuration manager utility to
specify a different image to be run.

> 3. I heard that the sources are a standard part of the package. Since it was
>    not mentioned in the SPD, is it still the case?

    The SPD I gave you is for the product purchased from TGV. You should
purchase from SRI International, as they have a better educational price
and include sources at no additional charge.


>From: David L. Kashtan <KASHTAN@SRI-IU.ARPA>
>
>1) What hardware is needed to connect a Vax VMS system to a Tcp/Ip network?
>    That depends on what the communication medium is going to be.
>    Assuming that this will be Ethernet (that is the most common medium),
>    MultiNet will work with any of the following hardware interfaces:
>        a) DEC ethernet (DEUNA/DEQUNA/DELUA  ...etc).  MultiNet also
>           can share this ethernet interface with other networking
>           protocols (.e.g. DECNET)
>
>        b) Interlan NI1010 ethernet interface.
>
>        c) 3-Com ethernet interface.
>
>        d) Excelan EXOS ethernet interface.
>
>    If what you need is something OTHER than ethernet, there are a wide
>    variety of communications controllers that are supported by MultiNet.
>    Just let me know what you are going to be using as the communication
>    medium.
>
>2) How much does it cost?
>        You will have to get the pricess from the various
>        manufacturers.  Most VAXes nowadays come with an
>        ethernet interface -- so there is no extra hardware
>        cost for MultiNet.  If you need to buy an ethernet
>        interface the following may be of interest:
>            DEC -- theirs tends to be the most expensive
>                   but support should be good.
>
>            Interlan -- Less expensive than DEC.  We have
>                    had good reliability with these.
>
>            3-Com -- No longer manufactures these -- you would
>                 have to get them on the 2nd hand market.
>                 Not recommended.
>
>            Excelan -- Their interface has On-Board TCP, which
>                   MultiNet cannot make use of (it runs its
>                   own TCP in the VMS kernel).  Thus, you are
>                   probably paying for things that you don't
>                   need.
>
>3) What software is required to be in VMS in order for MULTINET to run?
>    None -- it runs on a "vanilla" VMS system.
>
>    To recompile any of the user-level code will require the DEC
>    VAX-11 "C" compiler.  It is unlikely that you will need to
>    recompile anything.
>
>    To recompile the networking kernel will require either a VMS system
>    that also has Eunice (A UNIX system layered on top of VMS) or a VAX
>    running 4.2bsd or 4.3bsd UNIX.  It is VERY unlikely that you will
>    need to recompile the networking kernel.
>


From: "RANDY CATOE" <randy@TWG.COM>
Subject: RE: TcpIp software for SMP VAXes and large number of incoming Telnets.
To: "yehavi" <yehavi%hujivms.bitnet@cunyvm.cuny.edu>

Wollongong routinely tests new software at a commercial database development
company that runs a cluster of six or more 6360 VAX systems. The normal load
on those systems is in excess of 300 telnet users each. The TCP/IP software
is WIN/TCP.

The WIN/TCP networking kernel differs from its competitors in that we have built
an SMP implementation that accomplishes multi-processor synchronization on
a per connection basis. The result is that we incur far less multi-processor
synchronization overhead than in other approaches. This results in more
processor resources for other computing.


From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu>

I wasn't directly involved in the evaluation, but we are running the
Wollongong WIN/TCP package on the recommendation of the systems group at
the main Indiana University campus in Bloomington, IN.  We haven't had any
problems with it yet, but most of our terminal connections are still via
LAT (here at I.U.P.U.I. in Indianapolis).  Also, our load is rather light
compared to BACS in Bloomington (50-60 users on an 8800).  We are still
running VMS V4.7 (to go to V5.1 this summer).  We are running version V3.2
of the WIN/TCP product.

BACS at I.U. Bloomington is using Telnet rather heavily in a cluster of 2
8820s running VMS A5.0-2 and WIN/TCP V5.0, and one each of a 11/780, 11/785,
and an 8650 running VMS V4.7 and WIN/TCP V3.0 (I think, maybe V3.2).  Their
loads range up to about 100 users on each of the 8820s, 40-50 on the 11/78xs
and 80 or so on the 8650, with more than 90% of the connections by Telnet.

BACS did some pretty thorough testing on each of the three products you
mentioned and Telnet performance was a very important issue.  Also,
whatever they decided on was going to be recommended to other sites all
over the indiana-net.  There was also a side issue about which vendors could
get their software working the smoothest under 5.0 on the SMP machines
(the testing was going on early last fall).  I don't know how cooperative
the TCP/IP vendors are over there, but BACS was testing this stuff for a
couple of months, and I think they got some kind of temporary evaluation
license deal from the vendors being evaluated for that period (of course,
there were a lot of $$$ at stake :-).  Maybe you could get a similar deal;
there's certainly no substitute for a hands-on pounding out of the products
on one's own system, with one's own load, etc., to make sure you're getting
what's best for your site...  Attached below is a summary on the BACS
evaluation I received from the manager of the systems group there.


From:    AQUA::FLOWERS      "Chuck Flowers" 16-MAY-1989 13:42

In my group, Steve Smail did the testing of the various vendor's TCP
products. Fusion was dropped early due to lack of stability. It could
not stand up to any kind of load. The battle then boiled down to TWG
and MultiNet. Both products have their pros and cons but for a high load
system where the maximum speed and stability is needed, TWG was the
vendor of choice. The big advantage to MultiNet was the price. In fact
(pending Jim Williams completion of the contract) we will be offering
MultiNet to our departmental users who need the TCP/IP functionality.
MultiNet has offered us a site license which makes it a very attractive
package. The TWG package does impact the cpu significantly. In our
dual cpu 8820s, we may see 75% (of one cpu) kernel loading with 75
users on the system depending on activity. But it was the best
offering at the time of our testing and still is to our knowledge. It
is also more expensive than MultiNet but it can stand all the load
that we can throw at it!


From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu>

I think by "unstable", Chuck meant that under heavy loads the system would
tend to crash.  Remember that this was going on last fall when all the
TCP/IP vendors were still getting the bugs out of their software for SMP.
SMP device-driver synchronization bugs tend to show up (i.e., cause the
system to bugcheck and die) more often as the load (processes using the
driver or device) increases.  The MultiNet product is inexpensive, and the
user interfaces are more VMS-native-like than the Wollongong product.
However, what one is paying for with the Wollongong product is support.
Support for the MultiNet product was limited at the time the evaluation
was taking place (sort of like, you report the bug and they'll try to
fix it in the next release).  Wollongong eventually supplied patches on the
spot and got their product to the point where it could stand up under a heavy
load, so that's why we're running the Wollongong stuff.  Since the product
was going to be critical to system availability (since almost all their
terminal connects are via Telnet), the stability and support issues were
considered to outweigh the issues of how nice the user interface looked
and price.  Perhaps the situation has changed since last fall.  I noticed
in the file VENDORS-GUIDE.DOC from the Network Information Center
(nic.sri.com) that Excelan Inc. is now licensed to sell MultiNet.



From:     DESIREE@Warbucks.AI.SRI.COM (Desiree Champagne)

    In cases of problems you can contact us via email, phone and
fax.  Fixes can be ftp'd or a new tape will be shipped.  (I almost
always ship tapes via federal express or courier.)

    What you heard may be correct in both cases.  Depending on
what the fixes actually were, we may not have made a general
distribution tape and shipped to everybody.  It is totally dependent
on if is an actual bug that HAS to be fixed or if it is just something
that a user wishes us to install...  In the case of major bugs that
can cause any performance problems, tapes are shipped if necessary;
otherwise all users are notified via the mailing list.  (For instance,
we discovered an SMP bug that affects only the last 25 tapes shipped;
we are reshipping to all sites running multiprocessors.)

    In short, we make every effort to provide service to our
clients...and the feedback we have had is that our support is
excellent.  If you wish, I can give you references that I believe will
be compeletely honest about our strong and weak points.


From: Peter Marshall <peter@hadrian.uwo.ca>

We tried Fusion and ran into problems and we were not happy with the support.
We eventually returned the Fusion and purchased Multinet which has had
exceptional support (even though we officially don't have any).  I'm not
sure if we ever got 100 connections before everyone left for Summer, but
we were up in the high 80s without great problems.  We are currently using
"rlogin" rather than telnet for most connections.

[Whew! Thanks, Yehavi! -rlk]
******************************************************************************

From: uunet!Kodak.COM!messingr (Rich Messinger x24361 B83, Rm 528, RL, 02221)

We have just been going thru an analysis of the same question for our
8800.  The other main contender that we saw was the solution form 
Excelan where much of the work is done on the board.  Check them out
as well as Wollongong.

******************************************************************************

From: "Paul Pomes (I'm the NRA!)" <drd!texbell!uiucuxc!uxc.cso.uiuc.edu!paul>

The best comes free with 4.3 BSD UNIX.

[My personal favorite! -rlk]


******************************************************************************
I would strongly encourage you to look into the Multinet tcp-ip package that
is distributed by SRI.  It was strongly recommended to me by "networking
gurus everywhere", and from looking at the flyer describing it and knowing
the wollongong product from experience, I think you get more for your money
with the MultiNet product.

The MultiNet  product supports decnet over ip, ip over decnet, slip, lpd and 
you can even get nfs for it for an additional fee.  The wollongong product
does not include any of these.  Additionally, you can get sources for the
MultiNet product, not so with the Wollongong product.


******************************************************************************
From: uunet!THENIC.THE.NET!STUART   (L. Stuart Vance)

My personal recommendation is MultiNet, sold by SRI International.  It is the
most fully featured IP for VMS implementation I've run across.  I've included
the latest release notes for your reference at the end of this message.
[I left these out 'cause this is getting long... -rlk]

I have several qualms about Wollongong [qualms left out -rlk]
You might also check out Fusion from Network
Research Corp (NRC).  The contact at SRI is Desiree' Champagne (415/859-6083).
NRC's number is 805/485-2700.  SRI will give you a 30 day trial of the software
if you want to check it out.

******************************************************************************
From: uunet!decwrl.dec.com!hwchoy%zpovc.DEC (Life, The Universe and Everything.)

I would strongly urge you to look at *real closely* the attached
products. I have left the developer's address at the end. Talk to him if
you like, he's real nice and technical. 

ps: understand that I don't represent my company (DEC) in any capacity 
over this matter. But you're welcomed to quote it as my personal 
opinion.

[Deleted attached MultiNet Spec Sheet -rlk]

******************************************************************************
From: "RANDY CATOE" <uunet!TWG.COM!randy>

determining the BEST solution obviously requires criteria.

If you choose from a performance criterion, I believe that  you will
find WIN/TCP from Wollongong a superior choice for SMP machines. WIN/TCP's
SMP implementation was developed and continues to be tested with the assistance 
of test sites where 6360 machines are the norm. In order to minimize multi-
processor overhead, WIN/TCP uses a finer degree of granularity for "spin-locks"
than other implemenations of TCP/IP (or for that matter DECnet).

If you're choice is feature driven, WIN/TCP is continually being enhanced by a 
team of engineers to include the latest network technology. We have recently 
upgraded to the lastest BSD compatible versions of network utilities such as
BIND and GATED. We offer a VMS SNMP agent for network management, A VAXmail
SMTP relay, an ALL-IN-ONE relay, support for IP security options (as well as
other security enhancements such as support for VMS security alarms).

The Wollongong Group, INC also offers a choice of support agreements, and 
a full complement of training to select from.

******************************************************************************
From: drd!jarsun1!jensen (peter jensen)

	I must have missed your original query about TCP/IP on VMS.
Anyways, we have a MicroVAX-II running VMS.  All our other systems
are Sun workstations.  Anyways, when I looked into this in the
beginning of '88, places like Wollongong and NRC wanted $6000+ for
their TCP/IP alone.  Since cost was a factor, we decided to go with
CMU's TCP/IP.  It only costs $150 (still), and has worked out beautifully.
It meets all our needs for telnet and ftp.  It also has lpr and lpd for
remote printing both ways, and mail (which we don't use).  It has a
$QIO interface to the network routines, which I have used to write little
utilities.  It also comes with complete source code, but you need a BLISS
compiler if you want to make any changes.

	Quite a few universities use this software already, and I have no
problems recommending it.

******************************************************************************

I hope this helps and turns out to be more than just a waste of bandwidth! -rlk

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 20:28:27 GMT
From:      art@dinorah.wustl.edu (Arthur B. Smith)
To:        comp.unix.ultrix,comp.unix.wizards,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Stdio over sockets

Hi!

    We are trying to do stream i/o (stdio.h stuff) over stream type
sockets in the internet address family (instead of the more
conventional (normal or character special) files or pipes), in Ultrix
3.0, and are having some problems.  We have not tried this under any
other operating systems.    

    We are constructing the FILE * stream by calling fdopen on the
socket descriptor.  The Ultrix documentation says that fdopen can be
applied to descriptors obtained from open, dup, creat or pipe.
Sockets are not mentioned as being either allowed or disallowed.
Fdopen returns non-NULL, so it presumably is succeeding, but
subsequent fprintf's seem to be failing.

    Does anyone know for sure if we can or can't do what we are trying
to do?  Since stream type sockets support the read, write and close
system calls, one would expect most operations to work.  Sockets DO
return errors to fstat calls, though, so any operation that insists on
checking the descriptor's status could fail.  

    Any help will be greatly appreciated.  Please respond by e-mail,
and I fill forward responses to any who request them.  I will post a
summary if the need seems to demand it.  Thanks in advance!

    	    -art smith (art@dinorah.wustl.edu    or
    	    	    	...!uunet!wucs1!dinorah!art)

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 21:52:14 GMT
From:      lcz@dptudg.sat.datapoint.com (Lee Ziegenhals)
To:        comp.sys.m68k,comp.protocols.tcp-ip
Subject:   SLIP driver for SystemV/68

Does anyone know of a SLIP driver for Motorola Delta series systems
running SystemV/68?  Specifically, V/68 R3V5 with Network Services
Extension R3V5.

Thanks!

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 22:22:36 GMT
From:      gts@violet.berkeley.edu (Greg Small)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.pcnet
Subject:   PCLAN/NetBIOS/TCP problem

= Article 26 of comp.protocols.pcnet:     Date: 19 Jun 89 21:16:56 GMT
= From: tony@scotty.dccs.upenn.edu (Anthony Olejnik)
=
= I'm having a problem with IBM's PCLAN program.  When using either Ungermann-
= Bass PCNIUs (with Release 16.0 of TCPPC) or WD8003E's (with PC/TCP v2.03 pl
= 1) the PCLAN server does not drop non-existent sessions.
= 
= Clients who connect to the server are still "seen" by the server even after
= the PC is turned off.  This presents a problem the next day when the same
= clients attempt to connect to the server again.  If the server has available
= NETBIOS/TCP sessions, then the client is able to re-connect.  However, this
= still leaves a non-existent session on the server end.

The temporary solution for UB TCP-PC 16.0 is to turn on TCP Heartbeats.  This
allows the server to time-out the connection.  RFC1001/1002 also provides a
separate heartbeat for Netbios sessions only but that is not implemented in
16.0 (comming in 16.1?).  You should check PC/TCP for a similar option.

There is a similar problem that PC Net/LAN does not clean up a Netbios
connection if the workstation IP address is changed while the server has a
Netbios connection open.  When the workstation logs back into the server the
connection under the old IP address is maintained.

I guess from your question that the UB TCPPC 16.0 and the PC/TCP interoperate
OK under RFC1001/1002?

Gregory T Small                                      (415)642-5979
Personal Computer Networking & Communications        gts@violet.Berkeley.EDU
Workstation Support Services - Software Group        ucbvax!jade!gts
267 Evans Hall                                       SPGGTS@UCBCMSA.BITNET
University of California, Berkeley, Ca 94720

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 89 22:28:48 GMT
From:      kdb@intercon.uu.net (Kurt bauamn)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Systems Corp.

In article <7245@ecsvax.UUCP>, genej@ecsvax.UUCP (Gene Jackson) writes:
> I am trying to locate Internet Systems Corp.  which advertised a Mac
> implementation of the NCSA Telnet product called TCP/Connect.   They
> were in Reston, Va but I can not locate them by directory assistance.
> Does anyone know if this product is still being sold either by them
> or some other company?

I normally would have replied to this through mail, but there may be others
out there who want to know this as well.  InterNet Systems Corporation was
forced to change it's name last fall, it is now called InterCon Systems 
Corporation and is located in Sterling Viginia, just up the road from Reston.
Yes we are still selling TCP/Connect, and would be happy to talk to you :-)

See phone number below.
--
Kurt Baumann

InterCon Systems Corporation
46950 Community Plaza
Suite 101-132
Sterling, VA 22170              Phone: 703.450.7117

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 89 01:09:01 GMT
From:      buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan)
To:        comp.protocols.tcp-ip
Subject:   SLIP for xxx machine

I noticed two requests for SLIP for machines other than Sun.  I would
like to get SLIP for our Silicon Graphics 4D/20.

As a service to the net I am willing to collect a listing of PD and
commercial SLIP implementations for any machine running any operating
system, and post the results back here.

I will be on a business/vacation trip for the next two weeks, so be
patient.  Also my uucp address has not been tested yet for incoming mail.

Buck
Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1989 22:30-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   New release of IP Multicast code for BSD-based systems
Release 1.2 of the Stanford IP Multicast software is now available for
anonymous FTP.  This software includes kernel modifications for 4.3BSD,
SunOS 4.0 and Ultrix 3.0 to support IP multicasting as specified in
RFC-1054.  It also includes an experimental IP multicast routing demon
that implements the Distance-Vector Multicast Routing Protocol (DVMRP),
an earlier version of which is specified in RFC-1075.

This release includes support for the following hardware/OS configurations:

    Machines		Operating Systems	Network Interfaces
    --------		-----------------	------------------
    Vax or Microvax	4.3+ or 4.3-tahoe	de, qe, sl*, lo

    Decstation 3100	Ultrix 3.0		se, lo

    Sun 2*, 3 or 4*	SunOS 4.0		ie, le, ec*, lo


"4.3+"	is Berkeley's 4.3BSD release plus the networking software
	released to the public on 4/4/88, available via anonymous
	FTP from ucbarpa.berkeley.edu.
"de"	is DEC's DEUNA Ethernet interface.
"qe"	is DEC's DEQNA Ethernet interface.
"se"	is DEC's AMD LANCE Ethernet interface.
"ie"	is Sun's Intel 82586 Ethernet interface.
"le"	is Sun's AMD LANCE Ethernet interface.
"ec"	is Sun's 3Com Ethernet interface.
"sl"	is Rick Adams's Serial Line IP (SLIP) driver for 4.3BSD.  (Allows
	the use of IP multicast addressing on a point-to-point link.)
"lo"	is the BSD loopback driver.  (Allows the use of IP multicast for
	intra-machine IPC, whether or not there are multicast-capable
	interfaces present.)

THE SOFTWARE HAS NOT BEEN TESTED ON MACHINES OR INTERFACES MARKED WITH "*".

The 4.3BSD changes require access to the kernel source files.  The SunOS
and Ultrix changes require access to only those source files included in
a binary distribution.

I encourage ports to other machines, operating systems, and interfaces.
I would appreciate receiving copies of any changes required to support
other configurations, for inclusion in future releases.  I would also
appreciate reports of bugs and suggestions for improvement.  Discussion
of changes, bugs, etc. takes place on the VMTP-IP mailing list, which
you may join by sending a message to vmtp-ip-request@gregorio.stanford.edu.

To learn more about this software, fetch the file "ipmulticast.README"
from directory "vmtp-ip" on host gregorio.stanford.edu.  The full
software release is available from the same directory, as a compressed
tar file in "ipmulticast.tar.Z", or uncompressed in "ipmulticast.tar".

Steve Deering
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 89 17:31:33 GMT
From:      dd@ariel.unm.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Help needed on Socket Programming! (Sorry if this is a repeat)


>I have a question about "socket programming" under the 4.2 BSD Unix system.

	You might want to consider upgrading your sun to a 4.3-based
	release of the operating system.  The socket programming
	interface works a whole lot better there...

>The Query:
>----------
>I have been 
>[...]
>Question 1: Any suggestions, ideas, references?
>
>IPC primitives by way of using sockets seems to be the way to go.  I came 
>across a System V manual by AT&T called "Network Programmers Guide"
>(ISBN # 0-13-940461-9) which explains just the kind of thing that I'm looking
>for (ref. CH 6).

	It does seem that sockets provide the mechanism you are looking
	for.  4.x BSD systems are probably signifiicantly different than
	System V systems, though.

>Question 2: We here at the Univ. of Texas @ Arlington have SUN 3/50(60) work-
>stations running 4.2 BSD.  Does any one know of a "Network Programmers
>Guide" or manual for the 4.2 BSD?

	The thing you would be looking for IF you ran 4.3 BSD are the 
	documents PS1:7, and PS1:8 of the Unix Programmers Manual,
	Supplementary Documents manual set.

>Those of you who are into this sort of thing will at once know what I'm
>talking about.  Thanks in advance for your time.
>
>Sincerely,
>
>Omkar Rath
>CS_RATH@EVAX.ARL.UTEXAS.EDU
>Internet Address: 129.107.2.1


Don Doerner				dd@ariel.unm.edu
University of New Mexico CIRT
2701 Campus Blvd, NE
Albuquerque, NM, 87131			(505) 277-8036

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 89 19:25:55 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Specification vs. Implementation

Indeed, specifications should not be tied to implementations--though
designs should have been done with implementability in mind--that's
why The Book says
   An interface
   to an interpreter
   of a protocol
   is NOT
   the protocol
(line breaks approximate; haven't found the box that contains the
home copy of The Book yet).

HOWEVER, I do hope you just omitted the joke symbol when you said
that otherwise the 4.3BSD code would be the spec....

  fatigued (from upacking around 7500 pounds of Stuff) cheers,
      map
-------

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Jun 89 03:22:37 EDT
From:      "Matt Korn" <KORN%YKTVMT.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP for IBM MVS/SP/XA
In article <492@stc-auts.UUCP>,
<nbires!stcvax!stc-auts!dgp@ucbvax.Berkeley.EDU> (Dave G. Pitts) writes:

> Hello world! I'm looking to connect IBM mainframes to TCP/IP using the
> standard IBM TCP/IP software. Has anyone had any experience with this
> package? I've heard rumors that it does not work.

I don't think you could have heard rumors about the IBM TCP/IP for MVS
product.  IBM TCP/IP for MVS was announced 9/88, and will not be
generally available until 6/30/89.

If you do install the product and find something that does not work,
you can contact the TCP/IP group at the T.J. Watson Research Center.
We have an 800 number (published in the product announcement), and
there is also an IBM TCP forum on BITNET (IBMTCP-L@CUNYVM) which the
developers listen and contribute to.

Matt Korn
TCP/IP Development Group
IBM T.J. Watson Research Center
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 04:02:12 GMT
From:      tn07+@ANDREW.CMU.EDU (Thomas Neudecker)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Systems Corp.

The correct name of the company is InterCon and the software is called
TCPConnect.  It is a good package with VT240 and Tectronics 1440 emulation.

You can try to send E-Mail to Kurt at D1988@Applelink.Apple.Com


                         --TN

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 05:30:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   New release of IP Multicast code for BSD-based systems

Release 1.2 of the Stanford IP Multicast software is now available for
anonymous FTP.  This software includes kernel modifications for 4.3BSD,
SunOS 4.0 and Ultrix 3.0 to support IP multicasting as specified in
RFC-1054.  It also includes an experimental IP multicast routing demon
that implements the Distance-Vector Multicast Routing Protocol (DVMRP),
an earlier version of which is specified in RFC-1075.

This release includes support for the following hardware/OS configurations:

    Machines		Operating Systems	Network Interfaces
    --------		-----------------	------------------
    Vax or Microvax	4.3+ or 4.3-tahoe	de, qe, sl*, lo

    Decstation 3100	Ultrix 3.0		se, lo

    Sun 2*, 3 or 4*	SunOS 4.0		ie, le, ec*, lo


"4.3+"	is Berkeley's 4.3BSD release plus the networking software
	released to the public on 4/4/88, available via anonymous
	FTP from ucbarpa.berkeley.edu.
"de"	is DEC's DEUNA Ethernet interface.
"qe"	is DEC's DEQNA Ethernet interface.
"se"	is DEC's AMD LANCE Ethernet interface.
"ie"	is Sun's Intel 82586 Ethernet interface.
"le"	is Sun's AMD LANCE Ethernet interface.
"ec"	is Sun's 3Com Ethernet interface.
"sl"	is Rick Adams's Serial Line IP (SLIP) driver for 4.3BSD.  (Allows
	the use of IP multicast addressing on a point-to-point link.)
"lo"	is the BSD loopback driver.  (Allows the use of IP multicast for
	intra-machine IPC, whether or not there are multicast-capable
	interfaces present.)

THE SOFTWARE HAS NOT BEEN TESTED ON MACHINES OR INTERFACES MARKED WITH "*".

The 4.3BSD changes require access to the kernel source files.  The SunOS
and Ultrix changes require access to only those source files included in
a binary distribution.

I encourage ports to other machines, operating systems, and interfaces.
I would appreciate receiving copies of any changes required to support
other configurations, for inclusion in future releases.  I would also
appreciate reports of bugs and suggestions for improvement.  Discussion
of changes, bugs, etc. takes place on the VMTP-IP mailing list, which
you may join by sending a message to vmtp-ip-request@gregorio.stanford.edu.

To learn more about this software, fetch the file "ipmulticast.README"
from directory "vmtp-ip" on host gregorio.stanford.edu.  The full
software release is available from the same directory, as a compressed
tar file in "ipmulticast.tar.Z", or uncompressed in "ipmulticast.tar".

Steve Deering

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 06:49:02 GMT
From:      KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
To:        comp.protocols.tcp-ip
Subject:   (none)


As one of the developers of MultiNet I wanted to take this
opportunity to thank you for those positive responses regarding
MultiNet TCP/IP for VAX/VMS.  I also wanted to point out a
couple of inaccuracies and respond to Randy Catoe's messages
about MultiProcessor synchronization and VAX/VMS SpinLocks:

1) With all due respect to Mr. Catoe (and I quote):

  "The WIN/TCP networking kernel differs from its competitors in that we have built
   an SMP implementation that accomplishes multi-processor synchronization on
   a per connection basis. The result is that we incur far less multi-processor
   synchronization overhead than in other approaches. This results in more
   processor resources for other computing."

	If by synchronization overhead you refer to the overhead of
	acquiring/releasing Multiprocessor synchronization locks,
	the choice of fine-grained vs. course-grained locking makes
	no difference whatsoever (although it is possible, if you
	try to minimize the time that locks are held, to incur
	GREATER overhead with the fine-grained locking scheme
	due to  the multiple acquisition/release of spinlocks).

	I think the real debate is over the amount "spinning"
	done by CPU's that are waiting to acquire a spinlock.
	I must say, at the outset, that my initial (and intuitive)
	reaction is that having a spinlock per connection would
	be a big win over having several "strategically" chosen
	global spinlocks.  Luckily, we did NOT press ahead with
	the scheme that Wollongong used before implementing the
	easier "global" spinlock scheme and measuring its
	performance.

	Before talking about performance, I would like to point
	out a side issue that is actually quite significant.
	Both MultiNet and Wollongong's WIN/TCP use the 4.Xbsd
	Berkeley TCP protocol modules.  I feel that in order
	to participate in and derive benefit from 4.Xbsd
	protocol development it is necessary to minimize
	source changes to accomodate VAX/VMS MultiProcessing.
	Although I have not seen Mr. Catoe's sources, I would
	bet that they underwent some pretty serious modification
	to accomodate a spinlock per connection.  The MultiNet
	scheme of a few well chosen global spinlocks required
	NO source changes to the 4.Xbsd TCP protocol modules.

	Now for performance:  We did some performance measurement
	on several MultiProcessor machines with 100-150 active
	network	logins (some were Telnet and some were Rlogin).
	The MultiNet scheme resulted in an average of 2.8% of
	CPU time spent in network spinlock sychronization
	(this compares favorably to the 1.5% CPU time spent
	 in spinlock synchronization due to the VAX/VMS scheduler)!
	So -- in the best of cases, Mr Catoe's scheme might
	buy you an extra couple of percent of CPU.  But also
	note that we got an overall GAIN of 10% by using the
	GNU "C" compiler instead of the UNIX-PCC compiler
	(which is used to compile Wollongong's WIN/TCP).

	It is my understanding that the folks at NRC
	(FUSION TCP/IP) were using per connection spinlocks
	and ripped them out in favor of global spinlocks --
	they got better performance.

	My conclusion -- don't always follow your intuition
	without testing the concepts first.  Fine-grained
	locking is not always as good as one might think
	it would be.  And ALWAYS use the best compiler you
	can find!

2) "MultiNet from SRI comes with full sources..."

	MultiNet from SRI comes with partial sources, the
	sources for several key modules (the interface
	between the networking protocols and the VAX/VMS
	kernel) are not supplied, although the object modules
	ARE provided -- so you can indeed link the network.
	Full sources are supplied for all the network protocol
	modules and all the User-Level clients and servers.


3) There was an excerpt from a letter that I wrote that was obviously
   VERY OLD.  My host hasn't been SRI-IU.ARPA for many years!

	>To recompile any of the user-level code will require the DEC
	>VAX-11 "C" compiler.  It is unlikely that you will need to
	>recompile anything.
	>
	>To recompile the networking kernel will require either a VMS system
	>that also has Eunice (A UNIX system layered on top of VMS) or a VAX
	>running 4.2bsd or 4.3bsd UNIX.  It is VERY unlikely that you will
	>need to recompile the networking kernel.

    ALL the MultiNet code (both the networking kernel and the
    user-level code) is now compiled using the GNU "C" compiler,
    which is provided as part of the MultiNet distribution.  The
    switch from Eunice/UNIX-PCC to GCC got us about 10% better
    performance from the network kernel.


-------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 07:22:37 GMT
From:      KORN@YKTVMT.BITNET ("Matt Korn")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for IBM MVS/SP/XA

In article <492@stc-auts.UUCP>,
<nbires!stcvax!stc-auts!dgp@ucbvax.Berkeley.EDU> (Dave G. Pitts) writes:

> Hello world! I'm looking to connect IBM mainframes to TCP/IP using the
> standard IBM TCP/IP software. Has anyone had any experience with this
> package? I've heard rumors that it does not work.

I don't think you could have heard rumors about the IBM TCP/IP for MVS
product.  IBM TCP/IP for MVS was announced 9/88, and will not be
generally available until 6/30/89.

If you do install the product and find something that does not work,
you can contact the TCP/IP group at the T.J. Watson Research Center.
We have an 800 number (published in the product announcement), and
there is also an IBM TCP forum on BITNET (IBMTCP-L@CUNYVM) which the
developers listen and contribute to.

Matt Korn
TCP/IP Development Group
IBM T.J. Watson Research Center

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 20:29:05 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: DIAL-UP slip availability

>Seems the last release of the KA9Q's PD code had dial-up slip iwth 

I hate to keep bringing this up, but my TCP/IP code is not public domain.
It is copyrighted, but I grant free use to noncommercial users.

Phil

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 89 23:54:55 GMT
From:      hans@ditmela.oz (Hans Eriksson)
To:        comp.protocols.tcp-ip
Subject:   World record furthest telnet: Australia -> Sweden


I beleive I can claim the (current) world record for the furthest
telnet login: Melbourne -> Stockholm.

This weekend the IP-link between Hawaii and Australia (Melbourne Uni)
finally came up. A couple of minutes ago I telnetted to my old host
back home (re.sics.se) and read my news. Sloooow, but nevertheless
working.

According to my MacII the distance is around 15,600 km. But that is
via Asia. Via America I guess it around 22,000 km.

/hans

P.S. On a "silent" weekend, I might try a nfs mount...
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 04:17:37 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Stdio over sockets

Sockets do not return errors from fstat calls.  The result of an
fstat is `the right thing'.

What is probably happening is that your program(s) do(es) not use
fflush.  If you write to a terminal device, C (not Unix: it says
to do it this way in the proposed C standard) stdio by default buffers
text up to the first newline.  Once you send a newline to a stdio
stream, the text (including the newline) is printed immediately.
Devices that are not terminals, however, get fully-buffered: text is
not printed until a `sufficiently large amount' accumulates, or until
the C program uses the fflush() stdio routine.

Any good C book should explain this, at least if it was written after
the first few drafts of the proposed standard were issued.

Chris

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 13:41:00 CST
From:      "MIKE CHISHOLM" <chisholm@mdc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Proxy ARP code for unix hosts acting as routers
Hello,
Can anyone tell me where I can find code to implement proxy-arp on
unix hosts serving as routers.  The hosts are HP's running HP-UX, SUN's
IBM RT's and if possible Apollo's.

		Michael Chisholm
		chisholm@mdc.com

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Jun 89 14:56:06 EST
From:      Stephen Fultz <IGJF400%INDYCMS.BITNET@UICVM.uic.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Port parm on telnet commands

What is the value of the port parameter on TELNET and FTP.
   1) Is of use to casual users?
   2) Is used only for testing?
   3) Is it of any use?
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      MON, 26 Jun 1989 18:44:22 EST
From:      Jeffery K. Bacon <BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   tn3270 on PC/3c503
Wanted: a version of tn3270 to run on IBM PC's/clones. Needs to support
3com 501 and 503 cards, and must work with/in a PC-NFS environment. PD
software preferable, but not necessary. Any comments/pointers/suggestions
would be most appreciated.

Jeffery Bacon
Academic Computing Svcs, Michigan Technological Univ.
bitnet: bacon@mtus5  uucp:  <backbone>!rutgers!umix!anet!bacos

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 15:32:51 GMT
From:      ntanaka@ARAGORN.GANDALF.CS.CMU.EDU (Nobuyoshi Tanaka)
To:        comp.protocols.tcp-ip
Subject:   Query on IP over LAPB --- Summary

Two weeks ago, I asked net people about implementation of IP over
LAPB.  I have had several responses via e-mails.  I will post here the
summary.  Thanks to all responders!
					--Nobu

______________________________________________________________________
Question:

  I am interested in how to implement IP over LAPB (or HDLC).  Are
there any references, any public domain implementations or any
pointers to comercial products.

______________________________________________________________________
satz@cisco.com:

cisco Systems supports IP and multiple protocols over LAPB. The router
product has two kinds of LAPB for serial lines. One is plain LAPB (DTE or
DCE) where IP packets are put in the data field of IFRAMEs. The other is
what we call Multi-LAPB where the first 16 bits of the IFRAME contain a
packet type. Ethernet packet types are used to identify protocols.
Multi-LAPB can be either DTE or DCE too.  [almes@rice.edu also told me
the pointer to satz.--Nobu]

______________________________________________________________________
From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>:

I am the Chairman of the IETF Working Group which is standardizing this.
 We hope to have an RFC out by the end of the summer.  What are you up
to?

______________________________________________________________________
From: nowicki@Sun.COM (Bill Nowicki):

You do not need the retransmission part of HDLC. We use the framing
part for our point-to-point links because most serial chips can do this
in hardware, including the CRC.  We sell a software product called
SunLink Inter-Network Router that implements it, but the protocol is
open, and can run on the Sun CPU ports up to 56Kbps, (such as is done
on Sun.COM!) or through higher-speed optional hardware like the Sun MCP.

The reference I have for the protocol (could be old) is:

"Synchronous Point-to-Point Protocol",
Xerox System Integration Standard XSIS 158412, December 1984.

  US Mail address:                    Telephone:
    Xerox Corporation                   (408) 737-4652
    475 Oakmead Parkway
    Sunnyvale, CA 94086
    Attn: Xerox Systems Institute
    MS: SVHQ 4

______________________________________________________________________
From: mahan@ncsa.uiuc.edu (Kurt Mahan):

There is an RFC (930?  I can't remember off the top of my head ) that
describes it.  [I'm not sure.  RFC930 is not.--Nobu]

I did it already here at NCSA ( for a project we are working on.. )..

______________________________________________________________________
From: Nick Felisiak <nick@spider.co.uk>

Just for fun, I set this up a few weeks ago here at Spider.  By way of
background, we've developed X.25 and TCP for V.3 streams, so I had ready
access to all the bits.

I had two hosts with synchronous boards, set up one as a DTE and one as
a DCE, wrote a glue module, based on or SLIP driver, which took the
bottom end of IP and fed it into the HDLC driver.  Since HDLC is frame
oriented, there was no need for the escape mechanisms which SLIP needs.

Unfortunately, the source is all commercial, so I can't just send it all to
you (and I bet you want to run it on a BSD machine, right :-)), but just to say
it works, and isn't that much work if you have the right code already around.
-- 

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 19:11:03 GMT
From:      harker@motcsd.UUCP (Robert Harker)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Wanted: tftpd syslogd routed for Sys V.3


I am looking for working copies of the following Berkeley TCP/IP daemons ported
to System V.3:
	tftpd		(trivial file transfer protocol daemon)
	syslogd (system error logging daemon)
	routed (Berkeley RIP routing information protocol daemon)

I have the source code for these programs and have built a working version of
the tftp program, but ran into socket problems with tftpd.  Before I invest a
lot of work into porting these programs I was wondering if anyone has done it
already.

Question, is routed a pure user level program or does it need parts of it
compiled into the kernel?

Please send me mail if you have done it or know of somebody who has.

Thanks in advance
Robert Harker
harker@motcsd.csd.mot.com
...!apple!motcsd!harker

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 19:41:00 GMT
From:      chisholm@MDC.COM ("MIKE CHISHOLM")
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP code for unix hosts acting as routers

Hello,
Can anyone tell me where I can find code to implement proxy-arp on
unix hosts serving as routers.  The hosts are HP's running HP-UX, SUN's
IBM RT's and if possible Apollo's.

		Michael Chisholm
		chisholm@mdc.com

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 19:56:06 GMT
From:      IGJF400@INDYCMS.BITNET (Stephen Fultz)
To:        comp.protocols.tcp-ip
Subject:   Port parm on telnet commands


What is the value of the port parameter on TELNET and FTP.
   1) Is of use to casual users?
   2) Is used only for testing?
   3) Is it of any use?

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 20:00:00 GMT
From:      stanonik@NPRDC.NAVY.MIL (Ron Stanonik)
To:        comp.protocols.tcp-ip
Subject:   milnet billing

We've heard rumors that milnet sites might be charged for network
access (something like $100k per year for a psn connection, plus
packet charges).  Currently end-users (ie, milnet hosts) are not
being billed; apparently dca is picking up the tab, though we understand
that "informational bills" are being sent to overseeing organizations.

Well, this raises many questions.

1) Is any of it true?  Will overseeing organizations be receiving
real bills, and should end-users expect to pay those bills; ie,
need to budget for them?

2) What charging rates should be expected?  In particular, how will
packet charges be figured (ip packets or psn packets)?

3) If ip packets are the measure, will a gateway be billed for packets
routed through it, or will the orginating network be billed?  The
information all seems available for the latter; ie, the address is
in the packet, and the network is presumably registered with NIC.

4) Is there a better forum for these questions?

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 20:13:15 GMT
From:      little@SAIC.COM (Mike Little)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Systems Corp.

Gene Jackson asks:
>I am trying to locate Internet Systems Corp.  which advertised a Mac
>implementation of the NCSA Telnet product called TCP/Connect.   They
>were in Reston, Va but I can not locate them by directory assistance.
>Does anyone know if this product is still being sold either by them
>or some other company?

 I believe the name (or current name) of the company you are looking for
is InterCon Systems Corp.  They are now located in Sterling.  The following
name, phone and address may help.

		Kurt Baumann
		InterCon Systems Corporation
		46950 Community Plaza
		Suite 101-132
		Sterling, VA  22170

		Phone 703-450-7117
		Email: kdb@intercon.uucp

They evidently also have this product available for PCs.

					-Mike

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 22:49:47 GMT
From:      pardo@june.cs.washington.edu (David Keppel)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Wanted: 4.3BSD TCP/IP physical layer driver for Lance chipset

Recently, parts of the 4.3 BSD TCP/IP code were made freely available.
The default physical layer driver is for whatever is the driver on a
VAX.  I am looking for a transportable or retargetable driver for the
Lance chipset.

A public domain implementation would be great.  This is for use in a
commercial product, so it would also be possible to buy code or hire
somebody.

aTdHvAaNnKcSe

	;-D on  ( The nutwork spatialist )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 22:55:06 GMT
From:      David_W_Carroll@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Wanted: Streams TLI examples for TCPIP

I am looking for any examples of TCP/IP implemented under AT&T 
System V.3.3 (Motorola 8000) using streams TLI. I need to 
create a custom service compatible with rcp.
 Thanks
Dave Carroll
CADnet Inc
2420 CAmino Ramon #202
San Ramon, CA  94583
415-275-0990

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 89 23:44:22 GMT
From:      BACON@MTUS5.BITNET (Jeffery K. Bacon)
To:        comp.protocols.tcp-ip
Subject:   tn3270 on PC/3c503

Wanted: a version of tn3270 to run on IBM PC's/clones. Needs to support
3com 501 and 503 cards, and must work with/in a PC-NFS environment. PD
software preferable, but not necessary. Any comments/pointers/suggestions
would be most appreciated.

Jeffery Bacon
Academic Computing Svcs, Michigan Technological Univ.
bitnet: bacon@mtus5  uucp:  <backbone>!rutgers!umix!anet!bacos

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 04:44:56 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: Wanted: 4.3BSD TCP/IP physical layer driver for Lance chipset

In article <8586@june.cs.washington.edu> pardo@cs.washington.edu (David Keppel) writes:
> Recently, parts of the 4.3 BSD TCP/IP code were made freely available.
> The default physical layer driver is for whatever is the driver on a
> VAX.  I am looking for a transportable or retargetable driver for the
> Lance chipset.

The DEQNA (if_qe.c) driver isn't for a lance, but on the other hand,
it seems awfully lance-like and would be a pretty good starting point.

The DEUNA actually contains a Lance chip, so the ring buffer setup
is even more lance-like, however there seems to be more layering to
confuse the issue.
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jun 89 12:18:40 EDT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        Stephen Fultz <IGJF400%INDYCMS.BITNET@UICVM.uic.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Port parm on telnet commands

I use the telnet port paramater all the time to check smtp servers, to
connect to finger sockets and to work with special programs.

Admittedly our telnet program is configured to only do option negotiation
(at least start it) when you don't specify a telnet port.

ftp port...never used it for anything else but it is possible.

-Rudy
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jun 89 18:08 EDT
From:      "Art Stine - Sr. Network Engineer" <ABSTINE@clvms.clarkson.edu>
To:        TCP-IP@sri-nic.arpa
Subject:   TCP for Venix on Pro-350
Does anyone know of a TCP/IP implementation which works on Venix
on a DEC Pro-350 (no snickers please... I didn't buy it...)? thanks alot

art stine
sr network engineer
clarkson u
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 16:18:40 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Port parm on telnet commands


I use the telnet port paramater all the time to check smtp servers, to
connect to finger sockets and to work with special programs.

Admittedly our telnet program is configured to only do option negotiation
(at least start it) when you don't specify a telnet port.

ftp port...never used it for anything else but it is possible.

-Rudy

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 16:47:36 GMT
From:      frank@tubkom.UUCP (Frank Ruge)
To:        comp.protocols.tcp-ip,rec.ham-radio.packet
Subject:   Searching SLIP for HP 9000/350


I'm looking for the SLIP-protocol for a HP 9000/350.
If anybody out there knows something about an implementation,
please mail a few lines.

                                     frank

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 19:12:00 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  milnet billing

[I've had to post this separately to the list because this mail
handler I use has some warped ideas about header processing.  A
copy DID go to Ron Stanonik, notwithstanding the header above.
I thought others might care to see it also.]

Hello Ron,

I'll bite, since you may not find other takers.  In fact, I'll even
break my usually unbreakable rule about NEVER reciting the questions
before responding.
 
> We've heard rumors that milnet sites might be charged for network
> access (something like $100k per year for a psn connection, plus
> packet charges).  Currently end-users (ie, milnet hosts) are not
> being billed; apparently dca is picking up the tab, though we understand
> that "informational bills" are being sent to overseeing organizations.

It's disappointing that the word doesn't get out better than it does.
Personally, I'm not surprised; in theory, this has all been a matter of
general knowledge throughout DoD for quite a while.  In case there are
others in the same boat, I'll try to cover a lot of territory with this
answer.  Of course, this message is unofficial.

It was made a matter of policy in 1986 by JCS memo MJCS-137-86 that
there would be "usage sensitive billing" on the DDN.  This is somewhat
a consequence of OMB Circular A-130 (December 1985), which generally
requires policies of this sort for most big information technology
facilities in the Government.  A-130 has extensive fine print defining
its scope, too much to include here.  JCS MOP 195, the main policy
directive governing DDN, has been adjusted to include billing-related
responsibilities.

DCA is not picking up the tab for MILNET hosts in general at present,
and never entirely did in the past either.  There is currently an
administratively determined cost split among DoD organizations.  For FY
1989, the Army, Navy, and Air Force are each paying $2,320,000 per
month.  Smaller agencies are also paying negotiated fees of various
amounts, loosely based on how many hosts they have on the network.  A
few users pay $6,300 per month per port.

DCA gets budget money for certain costs of managing DDN, and they get
budget money for their own use of DDN.  The usage part goes into the CSIF
(Communications Service Industrial Fund) where it is commingled with
the contributions from the rest of DoD, not only for DDN but for DSN,
ARPANET, and whatever the other 15 or so common user systems are.  There
is only one CSIF and its revenues balance its expenditures every year.
The individual systems don't have to balance.  The operational costs of
DDN (and DSN, etc.) are all paid out of the CSIF.  Certain management
and "other" costs come out of the DCA budget.  Certain overhead costs
such as the Monitoring Centers are paid out of the CSIF and thus are
distributed over the users.  The CSIF chunk of overall DDN cost is large
compared to the other part.  So, basically, the users are paying, but
at a high organizational level.

The "informational bills" are being sent to give managers a handle
on their usage levels.  I believe that those sent so far are all from
a sort of pre-prototype billing system.  The gears of the real phase-1
("Interim") billing system are just starting to grind now.  The ultimate
billing is embedded in an existing DECCO billing vehicle called the
Carrier Cost & Obligation (CC&O) report, which is where your billing
would normally show up if (for example) you leased a telco line.  Since
there is not much room in the CC&O for useful detail, there will be a
new report called the DDN Supplemental Billing Report.  The "bills"
sent thus far contained information that will be used in the supplemental
report, but the format and some other details differ.

> 1) Is any of it true?  Will overseeing organizations be receiving
> real bills, and should end-users expect to pay those bills; ie,
> need to budget for them?

The generic answer is "yes" but the details will depend on management
decisions in your chain of command.  The intent of the system is to
create an effective feedback loop which makes the consequences of
user behavior fall upon the users.  Just how far down the org chart the
budgeting will descend, and how soon, is somewhat at the organization's
option, but the JCS directives refer to the "lowest practical level."
 
> 2) What charging rates should be expected?  In particular, how will
> packet charges be figured (ip packets or psn packets)?
 
The charging is per 128 octet (or less) subnet packet sent.  If an AHIP
(1822) host sends a 512-octet (excluding leader) regular message to the
PSN, or if an X.25 (Basic or Standard) host sends an X.25 packet with
512 octets of data, it counts for 4 packets because it generates 4
subnet packets.  If the host sends 513 data octets, it counts for 5
packets.  Yes, this means that IP and TCP headers are billable data.

In the earlier planning stages we seemed to have a "tariff du jour" but
this seems to be settling down.  DCA issues a formal rate letter every
few months with projected forward pricing for all the common user
services, including DDN.  For hosts, cost components include access
line charge(s) if circuits must be leased between your host/gateway and
the PSN, monthly access charges which depend on access line speed and
single/dual homing, and kilopacket charges.  All CSIF charges have an
overhead factor of about 1% applied to cover some of the CSIF cost of
doing business.

There is a complication here in that all of the Services are not cutting
over to packet charge allocation simultaneously.  Therefore, there are
two rate schedules for MILNET, one with packet charges separate, and one
with no packet charges but a considerably higher monthly charge.  The
classified networks have their own price schedule, with no packet charges
at this time.  There's another complication, too: to try to ensure some
stability of real expenditure vs. projections as this scheme begins, a
number of special temporary rules have been worked out in various
organizations to confine the budgetary hits between various ceilings
and floors.

Here is a sampling of the planning rates for FY 1990.  The table of
access rates represents dollars per month per host.  Note that
special rates exist for dual homed hosts.  Below that are the
kilopacket rates, which are added onto the "MILNET (Plus Pkt Chg)"
column for those to whom it applies.  Terminal rates exist, too,
but I don't feel like typing in the entire chart.  I believe that
the Navy will be on packet charging during FY 1990 and the Army and
Air Force will be using the composite rate with no packet charges.

Access Single/     MILNET       CLASSIFIED   MILNET COMPOSITE
Rate   Dual    (Plus Pkt Chg)                  (No Pkt Chg)
------ ------  --------------   ----------   ----------------
50/56K Single       2,100          5,600           4,150
50/56K Dual         2,700          7,300           5,650
19.2K  Single       1,600          4,800           2,250
19.2K  Dual         2,000          6,250           3,050
9.6K   Single       1,000          4,000           1,350
9.6K   Dual         1,300          5,200           1,800

Traffic Precedence    Kilopacket Charge
------------------    -----------------
Level 1 (Routine):
   - Peak                   $1.30
   - Off-Peak               $1.00
Level 2                     $3.00
Level 3                     $4.00
Level 4 (Flash)             $5.00

> 3) If ip packets are the measure, will a gateway be billed for packets
> routed through it, or will the orginating network be billed?  The
> information all seems available for the latter; ie, the address is
> in the packet, and the network is presumably registered with NIC.

Loosely speaking, bills go to PSN ports.  If you have a gateway
connected to a PSN, the TSR that got you the port (or a subsequent
change) specifies the Program Descriptor Code (PDC) to be charged for
the packets that port sends, as well as for its monthly charge, and
generally for its access line costs if any.  There are also billing
mechanisms for TAC usage; details are a touch byzantine, but the
philosophy is analogous.  My report (referred to below) tells about
this.

The PSN doesn't look at IP headers.  Also, there is quite a bit of
non-IP traffic in DDN - somewhere between 5% and 25%, probably toward
the middle of that range, but since nothing looks, deriving these
numbers is a difficult proposition.  Then there is GOSIP...

There has been a serious discussion going on for almost a year about
upgrades for the second phase of the DDN billing capability.  MITRE (in
the person of me) did a study of technical issues and alternatives.
Peeking at IP headers was among the possibilities considered.  The
study report was published a couple of months ago for authorized
distribution.  It is pending public release authorization - "due" in a
couple of weeks, but it will get here when it gets here.  DoD people
can probably get copies now; quite a few were apparently distributed to
various "key players" in the services.  There is also a somewhat shorter
DCA document ("Analysis of Potential Future DDN Billing System Features")
covering some of the same territory; for maximum coverage, you probably
need both.  If you think it's appropriate for you to receive these
documents and you have difficulty obtaining them, drop me a note and I'll
try (as my time and patience permit) to get it taken care of through an
appropriate channel.

The sticking point with all enhancements is that the services (users)
will have to pay for developing and fielding enhancements, and I gather
that they are not sure that an elaborate centralized system is worth
the cost.  Military organizations with views on this should be working
with their service or agency's TCO or other appropriate focal point to
get their positions considered.

> 4) Is there a better forum for these questions?

Among net mailing lists, probably not (sigh).  Most of the key players
in this drama don't inhabit mailing lists.  You can talk to me
informally about technical issues, for what that's worth.  DoD
Services/Agencies all have TCO's and/or other kinds of focal points for
DDN, and that is the channel to input any official opinions.  There
have been a number of miscellaneous documents, briefing slides, etc.,
distributed to those people at various meetings on the subject, and
some of that information might be useful to you.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org / (703) 883-6832

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 20:14:45 GMT
From:      barnett@crdgw1.crd.ge.com (Bruce G. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: tcpdump for SunOS4.0

In article <1588@cunixc.cc.columbia.edu>, micky@cunixc (Micky Liu) writes:
>
>As I continue to get tons of requests for my patches, and tons of
>questions about them, let me try to answer them again.  I have taken
>the code written by Van Jacobson and others at Lawrence Berkeley Labs
>called tcpdump and modified it to run under SunOS4.0.

I came in late to this conversation, so forgive any redundant information.

The etherfind in SunOS 4.0 has been enhanced to provide most of the features
of tcpdump.

--
Bruce G. Barnett	<barnett@crdgw1.ge.com>  a.k.a. <barnett@[192.35.44.4]>
			uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 22:08:00 GMT
From:      ABSTINE@CLVMS.CLARKSON.EDU ("Art Stine - Sr. Network Engineer")
To:        comp.protocols.tcp-ip
Subject:   TCP for Venix on Pro-350

Does anyone know of a TCP/IP implementation which works on Venix
on a DEC Pro-350 (no snickers please... I didn't buy it...)? thanks alot

art stine
sr network engineer
clarkson u

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 89 22:49:16 GMT
From:      heberlei@iris.ucdavis.edu (Todd)
To:        comp.protocols.tcp-ip
Subject:   raw sockets under SunOS 4.0 (help please)


I am trying to port some of my network software that I wrote on a
Sun-3/50 running SunOS 3.4 to one running 4.0.  Unfortunately my
network analyzer needs to open a socket as:

	socket (AF_NIT, SOCK_RAW, NITPROTO_RAW)

but I am getting "protocol not supported".

Any clues as to what I need to do would be GREATLY appreciated.


Todd Heberlein
heberlei@iris.ucdavis.edu	128.120.57.20

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 00:38:55 GMT
From:      baker@Vitam6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   Internet Mail from Holland

What would be the simplest/cheapest way for Vitalink Europe to obtain Internet
Mail access from Gouda, Holland?

baker@vitalink.com

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 01:46:37 GMT
From:      dtm@MBUNIX.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Jacobson algorithm


I've been trying to get a hold of Jacobson's algorithm to
compute the TCP smoothed round-trip time.  Does anyone know
of any on-line copies or other references than:

"Congestion Avoidance and Control," V. Jacobson,
ACM SIGCOMM '88, August 1988.

David Miller
dtm@mitre.org

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 11:00:12 GMT
From:      barnett@crdgw1.crd.ge.com (Bruce Barnett)
To:        comp.unix.wizards,gnu.emacs.gnews,comp.protocols.tcp-ip
Subject:   RFC915 sources?

I haved tried posting this request several times, and never got a
constructive answer.

Where can I get the sources to the UUCP path server described in RFC915?

This allows me to telnet to our UUCP server on port 117 and ask for
the path to a particular UUCP machine.

The RFC915 document lists an address to send mail to.  No good.
The addresses for the authors are unusable.
(They are Rudy Nedved, Marc Elvy, and possibly Alan Langerman)
I have posted to comp.sources.wanted.
I have even tried probing the uucp-path ports on several machines,
hoping to find a server. (So I can send mail to the sysadmin).

No Luck.

I have tried writing my own server, but time is short and the bugs are
long.

So, one last time, can anyone help?

(The Gnews newsreader uses this as one of the three ways of generating
a reply address. We also need such a network service as access to
our UUCP gateway is restricted.)

--
Bruce G. Barnett	<barnett@crdgw1.ge.com>  a.k.a. <barnett@[192.35.44.4]>
			uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 13:32:23 GMT
From:      wrl@COS1.FAC.FORD.COM (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   DDN Billing Question


Bill,
Thanks for the good DDN Billing information.

I have a question for you or others out there, how is DCA going
to handle the billing of data coming through the Mailbridges from
the Arpanet and the NSFNET. I'm sure the Milnet users will pay for data
coming from them destined for the Internet but how will data be
charged if I send E-Mail to a host on the Milnet??

I'm not going to say they can't charge me but is this a cost that
DCA will absorb themselves ?????

Thanks



-----------------------------------------------------------------------
Bill Lewandowski		Ford Aerospace Corp. - Colorado Springs
FORDNET II 220-1899		Internet: wrl@cos1.fac.ford.com
AT&T (719) 594-1899		UUCP: {decwrl,sun,sgi} !wdl1!wrl
FAX: (719) 594-1614		MCIMAIL: WLEWANDOWSKI
-----------------------------------------------------------------------

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 16:06:24 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

Hans,

As some might say, that's great DX. Might I interest you in coming up
network time (NTP) on those antipodal hosts and claim the DX award
for time synchronization. Next, you get to try the Worked All Clocks
award. The more serious agenda here is to measure the delays and
dispersions on those paths over a significant interval and compare with
similar data I have here on the US - Norway path.

Dave

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1989 00:29-EDT
From:      CERF@A.ISI.EDU
To:        murtoa.cs.mu.oz.au!ditmela!hans@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: World record furthest telnet: Australia -> Sweden
Now,

can you telnet back again to your own host - and use
some source routing to force the connection truly around
the world...

Vint Cerf.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 89 23:06:35 GMT
From:      billc@wupulm.UUCP (Bill Canning)
To:        comp.sources.wanted,comp.lang.fortran,comp.protocols.tcp-ip
Subject:   Any TCP/IP source code in FORTRAN

I am looking for any source code I can find for TCP/IP in FORTRAN.  Please
e-mail me if you can help at all.

Thanks,
Bill

..!uunet!wugate!wupost!wupulm!billc

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 00:38:22 GMT
From:      hegstrom@TECNET-CLEMSON.ARPA
To:        comp.protocols.tcp-ip
Subject:   Source for 3-Com mail SMTP gateway?{

We need to be able to send and receive DDN (Internet SMTP) mail
from our 3-Com network.  We have DDN (Wollengong TCP/IP) and 3-Com 
3+Share on the same ethernet.

If you know how to do this please email directly to

hegstrom@tecnet-clemson.a{pa

or call me, John Hegstrom, at (301) 863-3365

Thanks.

There is a product called Promulgate which will do this.  It runs
on a Sun 386 and costs $35K hardware included.  That seems high.

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 00:46:26 GMT
From:      brianw@hpausla.HP.COM (Brian Wallis)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

Ummm... 

Hate to say it, but we do it just about every day. HP Australian
Software Operation (ASO) has an internet connection to HP's closed
subnet (and has had for about a year) which is regularly used for
telnet, ftp, etc to HP sites in the US, UK and Germany to name the
more common ones.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 03:54:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Comments on your RFC 1106

Richard,

A reading of your RFC gives a good impression on the surface, and in a
closed, high-speed network, it would probably be a "good thing" to
allow very large windows.  However, my concern, from the point of view
of running a host with a high volume of ftp activity, is that I don't
believe proper window value are being used now, and that opening up
the possibility of even higher windows will clog all available
bandwidth, especially when several connections are active with several
retransmissions in progress.

Case in point: there are hosts connecting to us with connections
through a local high speed network, which negotiate 8K, 16K, and even
64K windows.  What does not appear to be taken into account is that
the connections in the middle are at much lower speeds (or the
opposite case where the connected net is some medium-to-high speed,
but the host connection is at some lower speed).  The result is that
we try to keep the pipe full as requested, but the inevitable
retransmissions are tying up the limited bandwidth for the other
connections.

Even now I'm not sure we should blindly accept any legal max packet
and window size, just because it's legal for a single connection.  It
seems to me that we should be exercising some overall management of
the aggregate of all the connections as to both timely serviceability
and available bandwidth on our end.  Unfortunately, the only tools we
have as a measure are connection-by-connection round-trip times to use
to compute retransmission intervals, and, although we seem to be
getting closer, it still ignores the overall picture.

I guess I'm not ready to accept requests for gigabyte windows when
some hosts still don't know a reasonable window to request under 64K
now...(not to mention *where* we're going to find the address space to
hold the retransmission buffers)...

--Frank

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Jun 89 08:55:33 CDT
From:      Paul Lustgraaf <@CCVAX.IASTATE.EDU:GR.PJL@ISUMVS.BITNET>
To:        tcp-ip@sri-nic.arpa
Subject:   help with trailer details wanted
 
Is anyone out there intimate with the details of trailers?  We have
an implementation here that will not accept trailers, so we thought
we would hack away at it a little to see if we could add the ability
to at least accept them.  After consulting RFC 893, we have a question:
 
Does the length in the trailer refer to the length of the original
header only, or does it also include the 4 octets of the trailer
"header"?
 
Any references or samples of code that decode trailers would be
appreciated.  I have looked in the BSD source, but was unable to
find the code in question.  Probably due to terminal c-sickness :-).
 
 
Paul Lustgraaf      grpjl@ccvax.IaState.edu or gr.pjl@isumvs.bitnet
(515) 294-1556      Network Specialist, Iowa State University, Ames, IA
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 04:29:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

Now,

can you telnet back again to your own host - and use
some source routing to force the connection truly around
the world...

Vint Cerf.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 05:01:45 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

In article <8906281206.aa05174@huey.udel.edu> Mills@UDEL.EDU writes:
> Hans,
> 
>                      ... Next, you get to try the Worked All Clocks
> award...

Actually the real challange is to get those silly shuttle control
computers on the internet.  Columbia.NASA.gov anyone?  They could
even run rrn to keep the astronauts from getting bored during
countdowns!  8-)



-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      THU, 29 Jun 1989 14:27:45 EST
From:      Jeffery K. Bacon <BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   X.xxx protocols?
I know that perhaps this isn't the best place to ask, but for lack of
a better one:

Does anyone know where we here might be able to ftp copies of the X.400
specs (and anything we may need to see that's related)? We're working
on setting up campus mail, and I'd like to see just what X.400 IS before
I (we) throw the idea out the window, especially since we might have to
migrate to it someday.

Perhaps another question worth asking: Can one implement X.400 stds on top
of what is essentially a TCP/IP environment? Or do we even want to try?
This probably sounds like a stupid question


Jeffery Bacon
Academic Computing Svcs., Michigan Technological University
bitnet: bacon@mtus5  uucp: <backbone>!rutgers!umix!anet!bacos

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      THU, 29 Jun 1989 15:03:46 EST
From:      Jeffery K. Bacon <BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   to complete what I was saying....
Yes, it's probably a stupid question, (X.400 over TCP), but we're not
versed in ISO/OSI here, so we can't know for sure. Your patience is
greatly appreciated.

Thanks -jb

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 11:52:09 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        alt.sources.d,comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.questions
Subject:   line mode diffs for telnetd wanted.

Dear netlanders.

I am looking for extensions for telnetd under (bsd) unix that
provide for line modus. I am using some real slow IP links
over which the single char modus is really unfeasable.

I have seen, that Crays version of telnetd (under unicos) provides
this feature, and switches correctly between line and single-char
modus, as the user changes from shell to vi, or vice versa.

This is exactly what I would like to have in my telnetd on
Sun, HP, Vax or any other workstation.

Does anyone know where I could find for example diffs to 
berkeleys telnetd that will do the trick ??

Toerless Eckert			E-Mail: eckert@informatik.uni-erlangen.de
University of Erlangen		        {pyramid,unido}!fauern!eckert
Lehrstuhl fuer Betriebsysteme	BITNET: tte@derrze0.bitnet
Martensstrasse 3		Phone:  +49 9131 85 7908
8520 Erlangen, W-Germany

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 12:53:10 GMT
From:      mankin@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Jacobson algorithm

David,

>I've been trying to get a hold of Jacobson's algorithm to
>compute the TCP smoothed round-trip time.  Does anyone know
>of any on-line copies or other references than:
 
>"Congestion Avoidance and Control," V. Jacobson,
>ACM SIGCOMM '88, August 1988.

The SIGCOMM paper is *the* reference as things stand for Jacobson's
variance estimation round trip time algorithm.   I chair a working
group at the IETF that is writing an RFC on TCP performance algorithms.
Here is a part of our draft which deals with the RTT estimation
(notice, by the way, that it's important to do the Karn algorithm
on the sampling, in addition to Jacobson).

The Performance W.G. draft will be submitted as an RFC probably in the fall,
so it's not really something to cite yet, but I hope the section is
helpful to you.

By the way, another place where these algorithms will be specified in
time is for TP4 in the NIST Implementors' Agreements.   A colleague and
I prepared a text for this and he submitted it to the Lower Layer SIG
this past month.  

Allison Mankin
MITRE-Washington Networking Center
----------------------------------------------------------------------------

       RTT ESTIMATION AND RTO CALCULATION

  In normal operation, TCP implementations use estimates
of Round Trip Time (RTT: the elapsed time between the
transmission of segments and the receipt of their
acknowledgements) as the basis for calculating the value for
Retransmission Timeout (RTO: the maximum time a TCP
implementation will await acknowledgement without
retransmitting a segment).  The RTO value is calculated
dynamically from RTT estimates so that TCP can operate over
a wide range of network hardware and under varying load
conditions.

  For acceptable TCP performance, the RTO must be neither
too low nor too high.  If a TCP implementation consistently
uses too large an RTO, then it will be slow in detecting
dropped segments.  Dropped packets will cause the TCP peers
to become inactive, as the sending TCP waits for RTO to
expire and the receiving TCP waits for a sequence number it
can acknowledge.  On the other hand, too low an RTO value
will result in spurious retransmissions, since the sending
TCP will misinterpret delays as loss.  This is clearly
wasteful, and can cause congestion.

  The TCP specification  (RFC 793) includes an algorithm 
"given...as illustration," that calculates RTO based on an RTT estimate.
Though the algorithm is widely used in TCP implementations,
it has known flaws, and has proven to be inadequate.  The
two major problems with this RTO algorithm are:

     1. It does not address the issue of sampling RTTs
        in the event of segment retransmission; and

     2. It cannot cope with the high variation in RTT
        that typifies highly utilized systems.

  Phil Karn has developed an algorithm that solves the
first of the above problems (Karn and Partridge, SIGCOMM '87), 
and Van Jacobson has developed an algorithm that solves the second 
(Jacobson, SIGCOMM '88).  Experience has shown that using Jacobson's 
algorithm, starting with the SYN segments exchanged during 
the 3-way handshake of a TCP open,
to compute RTO based on RTT samples, and Karn's algorithm to
select RTT samples, can dramatically improve TCP
performance.  As a result, the Host Requirements RFC
mandates the use of these algorithms (Section 4.2.3.1).

  The RTT sampling problem that arises when segments are
retransmitted is that it is impossible for the sending TCP
to determine which transmission is being acknowledged.  In
other words, there is no way to tell whether the RTT should
be measured from the initial segment transmission, or from
excess traffic as a result of a poor RTT estimate.

  Jacobson's algorithm addresses problems in RTO
calculation.  Originally, RTO was calculated as:

            RTO = beta * SRTT,

where beta is a constant between 1.3 and 2, and SRTT is the
"Smoothed Round Trip Time."  SRTT is obtained by the
formula:

   SRTT(n+1) = alpha*SRTT(n) + (1 - alpha)RTT(n)

where alpha is a constant between 0.8 and 0.9, and
RTT(n) is the nth RTT measurement.  This approach for
calculating an average is known as "exponential smoothing."
It is a weighted average: the most recent observations are
given the most weight, while the impact of earlier
observations decreases as the algorithm is iterated.

  The problem with the original RTO calculation is that a
fixed multiplier is used to cope with the variance of round
trip delay.  This approach is inadequate for the Internet;
it is well known that RTT varies tremendously.  This is not
surprising: from queuing theory, we expect that systems
under heavy load will display large variance in delay.
Increasing a fixed beta sufficiently to accommodate the
range of delay variance would result in an RTO much too
inflated.

  In the Jacobson algorithm, RTO is calculated as:

          RTO = SRTT + 2 * MDEV,

where MDEV is the average absolute error -- the "mean
deviation" -- of SRTT.  Jacobson chose mean deviation rather
than standard deviation because it is much simpler to
calculate.  As he points out, however, the mean deviation is
itself a rather good estimator for standard deviation.  A
rough summary of the Jacobson algorithm is that delays as
great as roughly two standard deviations above average will
be accepted without retransmission.  The most important
feature of this algorithm is that RTO is dynamically
tailored for the sampled RTT variance.

  In Jacobson's algorithm, the estimate for MDEV is
derived from second-order exponential smoothing, as follows:

            Err = | RTT - SRTT |

    SErr(n+1) = gamma*SErr(n) + (1 - gamma)Err

where Serr(n) is the nth "smoothed error."  Because it is
desirable to have RTO adapt quickly when network load and
delay increases, the value for gamma should probably be
lower than the value used for alpha.  Jacobson suggest 0.75.

  In TCP implementations, SRTT and SErr are recalculated
often.  Hence, the calculation should be efficient.  In an
appendix of "Congestion Control and Avoidance," (SIGCOMM
'88), Jacobson presents an integer arithmetic implementation
of his algorithm that requires only 6 adds, three shifts,
and a compare, to get values for SRTT, SErr, and RTO.

  The procedures for calculating SRTT and SErr are
recursive, as each new SRTT and SErr is a function of the
previously calculated SRTTs or SErrs, respectively.  For the
first calculation, however, there are no previously
calculated values to use.  Hence, these algorithms need
seeds for the first calculation.  The Host Requirements RFC
encourages an initial value of 0 for RTT and 3 for RTO.  It
also recommends that the Jacobson algorithm begin operation
with the SYN segments exchanged during the 3-way handshake
of a TCP open (Section 4.2.3.1).

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 13:03:09 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Comments on your RFC 1106

Window size, packet size (MSS), and retransmit times are not all
inherently tied together.  (Related, yes; inextricably, no.)

Retransmit buffer space is (becoming) cheap.  One problem with large
windows (and small packets) in TCP, though, is that the effect on
overall transmission rate of random packet loss is magnified.  Other
this, the `Jacobson/Karels' (seems to me `Karn' ought to appear here
too) algorithms seem to work well in practise with the (admittedly not
large) 64 kB maximum windows in 4.3BSD-tahoe (only 1/64th of a
megabyte, hence `not large').

Chris

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 14:33:41 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Internet Systems Corp.



*I am trying to locate Internet Systems Corp.  which advertised a Mac
*implementation of the NCSA Telnet product called TCP/Connect.   They
*were in Reston, Va but I can not locate them by directory assistance.
*Does anyone know if this product is still being sold either by them
*or some other company?


intercon systems, not internet systems.

phone number is 703-435-8170.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 15:37:02 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

A long time ago, when the world was young and research sites still had
guest accounts, the host I was supposed to be using via a TAC was down.
Bored, I scanned the manuals, and learned of a guest account on a
machine in London.  I connected to it, and found a news item advertising
a guest account on a system in D.C.  Of course, I couldn't resist that,
either.  So every character I typed went from North Carolina, via satellite
to London, thence to D.C. via another satellite hop.  The echo, and
presumably the acknowedgements, went via the same twisty path.  Not
what one would call a responsive system...

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 16:56:23 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Mail/sendmail/RFC822 Question

This is a question concerning the use of an embedded space within a recipient
name.  RFC822 states on page 11 that the following is a legal address construct

		"first last"@domain

and I would assume that

		"first last"%demesne@domain

is also a valid construct.  The problem that I am having is that either Mail
or sendmail complains about an unbalanced quoted string when the above construct
is used and then attempts to deliver the message to

		first, last%demesne@domain

which is not the intended action.  Is this action a "feature" of the 4.3bsd
Mail or sendmail?

Merton

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 17:41:19 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

Dave,

   Does this mean the NIC will now accept applications for a Worked All
   Continents certificate? How about Worked All Networks? Worked All Hosts
   (real tough)?

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 18:03:35 GMT
From:      kate@NRC.COM (Kathi Samec)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP mailing list

Please add kate@nrc.com to the list. I hope this is where I was supposed
to send this request. I haven't had news access for many moons.

-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec  
 Network Research Corporation / nrcvax!kate@TRWIND.TRW.COM or kate@NRC.COM
 2380 North Rose Avenue       / hplabs!sdcrdcf!psivax!nrcvax!kate        
 Oxnard, Ca. 93030            / kate@nrcvax.UUCP                         
                           
 

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 18:26:02 GMT
From:      jeff@hpctdkz.HP.COM (Jeff Hughes)
To:        comp.protocols.tcp-ip
Subject:   RIP and routed


   Can someone please tell me where to get a hold of the source code
for "routed" on Berkeley's 4.3 version of UNIX? I am interested in 
the RIP protocol in particular.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 19:27:45 GMT
From:      BACON@MTUS5.BITNET (Jeffery K. Bacon)
To:        comp.protocols.tcp-ip
Subject:   X.xxx protocols?

I know that perhaps this isn't the best place to ask, but for lack of
a better one:

Does anyone know where we here might be able to ftp copies of the X.400
specs (and anything we may need to see that's related)? We're working
on setting up campus mail, and I'd like to see just what X.400 IS before
I (we) throw the idea out the window, especially since we might have to
migrate to it someday.

Perhaps another question worth asking: Can one implement X.400 stds on top
of what is essentially a TCP/IP environment? Or do we even want to try?
This probably sounds like a stupid question


Jeffery Bacon
Academic Computing Svcs., Michigan Technological University
bitnet: bacon@mtus5  uucp: <backbone>!rutgers!umix!anet!bacos

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 20:03:46 GMT
From:      BACON@MTUS5.BITNET (Jeffery K. Bacon)
To:        comp.protocols.tcp-ip
Subject:   to complete what I was saying....

Yes, it's probably a stupid question, (X.400 over TCP), but we're not
versed in ISO/OSI here, so we can't know for sure. Your patience is
greatly appreciated.

Thanks -jb

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 20:11:48 GMT
From:      tperala@umn-d-ub.D.UMN.EDU (Tim Perala)
To:        comp.protocols.tcp-ip
Subject:   ICMP Multiple Echo Replies

I have been getting strange behaviour when pinging a particular
host on the Internet.  I have not seen this behaviour with any
other host.  

Here is a script of what is happening...

Script started on Thu Jun 29 14:41:41 1989
1% /etc/ping multimax.encore.com
PING multimax.encore.com: 56 data bytes
64 bytes from 129.91.1.14: icmp_seq=0. time=215. ms
64 bytes from 129.91.1.14: icmp_seq=1. time=221. ms
64 bytes from 129.91.1.14: icmp_seq=2. time=210. ms
64 bytes from 129.91.1.14: icmp_seq=3. time=213. ms
64 bytes from 129.91.1.14: icmp_seq=3. time=220. ms
64 bytes from 129.91.1.14: icmp_seq=4. time=226. ms
64 bytes from 129.91.1.14: icmp_seq=5. time=229. ms
64 bytes from 129.91.1.14: icmp_seq=6. time=275. ms
64 bytes from 129.91.1.14: icmp_seq=7. time=1064. ms
64 bytes from 129.91.1.14: icmp_seq=8. time=284. ms
64 bytes from 129.91.1.14: icmp_seq=8. time=289. ms
64 bytes from 129.91.1.14: icmp_seq=9. time=622. ms
64 bytes from 129.91.1.14: icmp_seq=10. time=231. ms
64 bytes from 129.91.1.14: icmp_seq=12. time=598. ms
64 bytes from 129.91.1.14: icmp_seq=13. time=619. ms
64 bytes from 129.91.1.14: icmp_seq=14. time=307. ms
64 bytes from 129.91.1.14: icmp_seq=15. time=243. ms
64 bytes from 129.91.1.14: icmp_seq=16. time=224. ms
64 bytes from 129.91.1.14: icmp_seq=17. time=211. ms
^C
----multimax.encore.com PING Statistics----
18 packets transmitted, 19 packets received, -5% packet loss
round-trip (ms)  min/avg/max = 210/342/1064
2% ^D  
script done on Thu Jun 29 14:42:34 1989

Notice that I receive multiple replies on some of the requests.
I have no reason to believe that my ping program is in error.
What are some possible explanations for this behaviour, aside 
from the obvious, that the recipient of the request is actually 
generating multiple replies from a single ICMP echo request?

Just curious.

Tim Perala
Systems Programmer
Information Services
University of Minnesota, Duluth
(218) 726-6122

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 21:05:46 GMT
From:      mathis@FORNAX.ECE.CMU.EDU (Matt Mathis)
To:        comp.protocols.tcp-ip
Subject:   Domain Name Screaming

Does anybody have a description of the bug (and fix) of the interaction
between Yellow Pages and the Domain Name System?  This bug causes some
systems to send DNS requests at high rates for sustained periods in response
to remote DNS server or network failures.   High rates means typically 20
per second for workstations.   I have clocked some at as much as 100 pps!
Needless to say this is hard on gateways, and disaster to people behind
56k links.

I have a vague description, so I don't need another.  What I really want is a
document which I can hand to the administrator of some wayward host and
say "Fix this or else turn it off."  Needless to say some of said
host administrators are running broken "plug and play" systems, and need
pretty explicit directions.

Also, it would be extremely useful if someone has a remote test bed which can
be pointed at a suspect host to determine if it has the bug.

Thanks,
--MM--

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 21:09:43 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

Brian has a point.  Australia to Singapore (wrong way) over the HP
Internet is probably the reigning DX.  Minimum round trip time seems to
be about 2 seconds (adding together the ping time from California to
each location).  

On a different topic, we seem to have some INTERESTING routing to
Australia.  Check out this ping report:

64 bytes from 0x0f102101: icmp_seq=3. time=7994. ms
64 bytes from 0x0f102101: icmp_seq=8. time=3174. ms
64 bytes from 0x0f102101: icmp_seq=7. time=4242. ms
64 bytes from 0x0f102101: icmp_seq=6. time=6150. ms
64 bytes from 0x0f102101: icmp_seq=11. time=1214. ms
64 bytes from 0x0f102101: icmp_seq=5. time=7430. ms
64 bytes from 0x0f102101: icmp_seq=10. time=2453. ms
64 bytes from 0x0f102101: icmp_seq=9. time=3838. ms
64 bytes from 0x0f102101: icmp_seq=12. time=1265. ms

wunder

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 22:01:30 GMT
From:      rab@ssc-vax.UUCP (Robert A. Birgenheier)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.apollo
Subject:   PC to Apollo FTP


Please excuse the cross-posting.

  I talked recently with someone who was having problems trying to
connect from a pc to an Apollo via TCP/IP FTP.  Here are the
particulars:

   Compaq 286 logged on to a Novell LAN
   (Micom)-Interlan TCP/IP gateway on the server (NP600 card)
   remote host is Apollo (DN160?, I think)

He can sucessfully Telnet to the Apollo, can FTP to Administrator's
account on Apollo, but when trying to FTP to a user's account is told
'can't set to home directory' or something like that.  Anyone out there
with any help/suggestions?

Please email or direct postings to comp.dcom.lans.  I think that is
the appropriate group for continued discussion.
-- 
Robert Birgenheier
uw-beaver!ssc-vax!rab

Lefebvre Belebvre

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 23:03:04 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

>Actually the real challange is to get those silly shuttle control
>computers on the internet.  Columbia.NASA.gov anyone?  They could
>even run rrn to keep the astronauts from getting bored during
>countdowns!  8-)

You think you're joking, right? This is actually not so unlikely. There
is at least one "ham in space" operation scheduled for an upcoming
Shuttle mission where astronaut/astronomer Ron Parise, WA4SIR, will
carry an amateur packet radio station with him. It is entirely possible
(though I haven't actually proposed it) that he could operate TCP/IP
from space -- after all, they do have GRID computers that look like PCs
on the inside, and the KA9Q code will run just fine on them. The longer
things slide in the shuttle mission schedules, the easier it'll be to do
this sort of stuff as the necessary hardware becomes more and more
widespread.

The fun part would be doing the IP redirects as the shuttle moves from
one ground station gateway to the next...

Phil

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 89 23:26:26 GMT
From:      rfox@tandem.UUCP (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re:Comments on your RFC 1106


<of running a host with a high volume of ftp activity, is that I don't
<believe proper window value are being used now, and that opening up
<the possibility of even higher windows will clog all available
<bandwidth, especially when several connections are active with several

In the general networking case this is the case. I don't think anybody would
like a host to open its window to 100K and try and shovel that much data out
onto the internet to traverse arbitrary paths to a destination. At least
not now......

  But what about the case where a site has a private t1 satellite for there
disposal?  Running standard tcp over this link even with the window fully
opened doesn't fully utilize the link. It utilizes about 50% of the link at 
best. The users of this link might not really desire to use a link of this
nature. At NASA this was the case. There was a t1 ground link and a t1
satellite link to the same location. 
If the performance of the satellite was not comparable or
very close to being comparable to the ground link the users would not use it.
To make the satellite link more appealing we needed to make the bandwidth
utilization comparable to the ground link. Thus, the use of big windows fits the
bill. Now the links can be used in the following ways: ground link is used for
telnet type traffic and the satellite is used for bulk file transfers. 

Notice this was just one example of where big windows can make a difference. 
With todays networks becoming faster each year the use of bigger windows
will become very important. Already some local area networks can support
mtus greater than 64K. Thus to fully utilize these networks, big windows
will be neccessary. Even if our goal isn;t to fully utilize the lan but just
to get "better performance out of them" it might make sense to use an mtu close
to the mediums capability and have >64K windows. 

Another obvious place that big windows will come useful is in the giga-bit
bandwidth range. The arguments for this is just an extrapolation of the last
argument. Also for a good argument read 1077.

<now...(not to mention *where* we're going to find the address space to
<hold the retransmission buffers)...

This is a good argument. But remember memory is becoming cheaper and
cheaper..... we are already starting to make 4meg chips. In a few years
it might not be uncommon to see workstations with 32 megs.... Thus buffer
space might become just another cheap commodity. A good argument for this
can be found in a very recent paper by Craig Partridge that was presented
at the INARC last month.



Frank, I hope this gives some insight as to why the work was done and to why
it might be a very important idea in the near future. I appreciate your
comments and would be interested in any follow up.



rich

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 00:14:25 GMT
From:      cliff@violet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

Duplicate ICMP Echo Replies are an interesting phenomenon.  I've
seen a lot of them and in my experience they have never been caused
by errors at the recipient, although that is always a possibility.

They seem usually to be caused by inappropriate link-level retransmission
of the packets, and they sometimes point to a link that's failing or
heading in that direction.  For example, with some link-level protocols
a device may see a NAK when the packet actually made it out the other
end of the link, and it then does a retransmission of the packet. 

I have often seen this associated with the particular data patterns in
the packet itself (groan!).

In the past I've seen these within the UC Berkeley network, and on our
local NSF Regional (BARRNet), and in both these cases they've meant
trouble.  That is, when I start seeing duplicates around here I'm sure
that something in our net needs fixing fast.

I don't think they always mean trouble.  I see them occasionally 
going across the NSFNet backbone and yet we have no problems
with the backbone.

You can anonymously ftp a version of ping that detects and reports
duplicates, as well as allows you to specify a data fill pattern from
jade.berkeley.edu.  The files of interest are pub/ping.c and pub/ping.8.

	Cliff Frost	<cliff@cmsa.berkeley.edu>
	Data Communications and Network Services
	UC Berkeley

RE:
In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes:
>I have been getting strange behaviour when pinging a particular
>host on the Internet.  I have not seen this behaviour with any
>other host.  
>...
>Notice that I receive multiple replies on some of the requests.
>I have no reason to believe that my ping program is in error.
>What are some possible explanations for this behaviour, aside 
>from the obvious, that the recipient of the request is actually 
>generating multiple replies from a single ICMP echo request?

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 00:32:21 GMT
From:      hans@ditmela.oz (Hans Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re:  World record furthest telnet: Australia -> Sweden

In article <8906281206.aa05174@huey.udel.edu> Mills@UDEL.EDU writes:
> As some might say, that's great DX. Might I interest you in coming up
> network time (NTP) on those antipodal hosts and claim the DX award
> for time synchronization. Next, you get to try the Worked All Clocks
> award.

Well, there aren't that many world records available, so I'd had to
try that way to fame :-)

> The more serious agenda here is to measure the delays and
> dispersions on those paths over a significant interval and compare with
> similar data I have here on the US - Norway path.

Sure, could you send me an extract of your data so I known what to
measure and in what form. Better make sure that the data really are
comparable.

/hans
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 00:38:00 GMT
From:      hans@ditmela.oz (Hans Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <2830002@hpausla.HP.COM> brianw@hpausla.HP.COM (Brian Wallis) writes:
>
> Hate to say it, but we do it just about every day. HP Australian
> Software Operation (ASO) has an internet connection to HP's closed
> subnet (and has had for about a year) which is regularly used for
> telnet, ftp, etc to HP sites in the US, UK and Germany to name the
> more common ones.

Yeah, I hate you saying that too ;-)

Anyway, you are commersial, I'm just a poor lonely researcher in the
outskirts of the world (sorry, my dear Australians! I love the country
anyway).

But I'd guess I have to modify my claim:

World record for longest telnet via the Internet:
Melbourne -> Stockholm via the western hemisphere (~ 22,000km).

/hans
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 00:43:55 GMT
From:      hans@ditmela.oz (Hans Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <[A.ISI.EDU]29-Jun-89.00:29:13.CERF> CERF@A.ISI.EDU writes:
> Now,
>
> can you telnet back again to your own host - and use
> some source routing to force the connection truly around
> the world...

There is no IP-links going via the eastern hemishpere (yet). Of course
there maybe someone running IP over X.25 (I have thought about doing
that myself).

What I have done is calling SICS (Stockholm) via X.25 and then telnet
to Australia. I guess that Australia PTT takes the shortest path to
Sweden which should be via the easter hemisphere, and then I completed
the circumnavigation via the IP-links Scandinavia->US->Australia.

/hans

p.s. I wonder when one can go around the world in just 80 milliseconds...
-- 
Hans Eriksson (hans@ditmela.oz.au)
CSIRO/DIT, 55 Barry Street, Carlton, Victoria 3053, Australia (we are GMT+10)
Tel: +61 3 347-8644 Fax: +61 3 347-8987 Home: +61 3 534-5188
On a years leave from Swedish Institute of Computer Science (hans@sics.se)

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 08:48:59 GMT
From:      iain@etive.ed.ac.uk (Iain Lindsay)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

I have observed multiple echo replies when using an old 3com ethernet V1.0
interface on one of our vaxes.  What appears to happen is that the interface
sends a packet, which is then followed on the wire by a packet from another
machine, with minimal packet spacing.  The 3com i/f erroneously thinks the two
packets collided and flags an error, causing the packet to be retransmitted.
Thus, the target host sees two identical packets and sends two replies.  There
are probably numerous other mechanisms which can duplicate packets and which do
not invlove dogdy hardware.
-Iain..

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 13:57:35 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   SysV tn3270 sources needed

I am sorry to post this here but I have been attempting
to e-mail Mr. Merritt at the iris government machine
with no luck

Mr. Merritt, 

If you are out there listening, I have been trying to
email you in regards your response on the SysV tn3270
sources.  Please email me again with your phone number
or call me at the number listed in my signature


-- 
Steve Scott            UUCP: {killer|texbell}!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 14:44:22 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <8906281206.aa05174@huey.udel.edu>, Mills@UDEL.EDU writes:
> Might I interest you in coming up network time (NTP) on those antipodal
> hosts and claim the DX award for time synchronization.

We've done that already ... in fact, that one of the first things we
got going (there were some people here sick of clocks that never keep
quite the right time - keeping them in sync with each other was fine,
but only of marginal interest when that meant they all showed the wrong time).

Actual use was one host here slaved off one in Hawaii, which was slaved
off one somewhere on the mainland, and the rest of the net here slved off
the privileged one.   We have (at the minute) no way to accurately measure
any error in the absolute time, but it was certainly too small to detect
comparing (manually) the signals from the phone company and the time on
the systems here.

We hope to be able to get access to Australia's standard time clock
(caesium beam thing, which is keep in sync with Paris) sometime in the
near forseeable future, then we'll be able to tell if you're really sending
us the true time, or just something close...

Unfortunately, the leased line carriers have taken the circuit away to
try and get the error rate to something close to acceptable, so we're
back to looking at our watches again.

kre

ps: If Hans really wanted to calculate how far his bits really went going
to Sweden and back he'd want to include the distance of 3 satellite hops
that I know about between here and there (perhaps more).  With 3 of those
the total distance is something pretty enormous, and the delays agree with
it...  (I saw rtt's from ping of about 10 seconds to sics.se last weekend,
with a drop rate about 75%).

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 15:25:03 GMT
From:      adoyle@bbn.com (Allan Doyle)
To:        comp.realtime,comp.protocols.tcp-ip
Subject:   Need TCP/IP to run under PSOS

I'm looking for an implementation of TCP/IP that I can run on a Motorola
MVME-147 board under pSOS.

The MVME 147 has the LANCE chipset, and a 68030 CPU. pSOS is a real-time
kernel. Any code that I can bash into submission is welcome. It does
not have to fit the 147 board and pSOS like a glove but the closer the
better :-)

Allan Doyle                                              adoyle@bbn.com
BBN Systems and Technologies Corporation		 (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 15:45:40 GMT
From:      pschmidt@bbn.com (Peter H. Schmidt)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   GatorBoxes shipping immediately

FYI for those interested in connecting their macs to their unix/tcp boxes:
Cayman is now shipping GatorBoxes immediately...

...Peter

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 17:01:28 GMT
From:      biocca@swr (Alan Biocca)
To:        comp.realtime,comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP to run under PSOS

In article <42213@bbn.COM> adoyle@BBN.COM (Allan Doyle) writes:
>I'm looking for an implementation of TCP/IP that I can run on a Motorola
>MVME-147 board under pSOS.
 
>The MVME 147 has the LANCE chipset, and a 68030 CPU. pSOS is a real-time
>kernel. Any code that I can bash into submission is welcome. It does
>not have to fit the 147 board and pSOS like a glove but the closer the
>better :-)


Two possibilities -- vxWorks and hacking unix drivers.

The easy way -- buy it.  vxWorks from Wind River Systems.
vxWorks will support pSOS and has TCP/IP support and runs on the mv147.
Turnkey.  RPC, NFS, ftp, rsh, telnet, etc.  ready and waiting.  I've done
it the hard way (kernel and driver and ...) and it pretty much killed a
100K$ project because it cost too much to get everything working.  vxWorks
is a bargain.

The hard way -- get a unix driver for the ethernet interface.  Then hack
to fit (man weeks..months..year?).  This was done here at LBL.  We weren't
using the mv147 at the time, but were using a CMC board and the unix driver
could be made to work with pSOS pretty well.  One group here at LBL had it
working in production with quite a few systems online.  They have recently
decided the cost of maintaining this kludge to be excessive (they'd like to
take advantage of new boards easily instead of having to face redoing the
stuff every time).

The CMC board was probably easier than the 147 will be since 1) it had TCP/IP
in prom onboard, and 2) unix drivers were available from CMC.  I suspect
that motorola doesn't have unix drivers available for the 147, but if they
do that is a good place to start.  If the drivers don't include the TCP layers
then BSD 4.3 TPC/IP is probably the thing to add.  vxWorks uses it.


Disclaimer -----------------------------------------------------------------
I have no direct affiliation with Wind River Systems, the company that 
produces vxWorks, but am a user and have been involved with several projects
using their product.  It is, like any real product, not perfect.  It provides
tremendous advantages over other methods for many projects and so is worth
consideration.  It has been justified enough here at LBL to go to the 
significant trouble it takes to obtain a site license. Your mileage may differ.

	Alan K Biocca

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 18:47:11 GMT
From:      John_Robert_Breeden@cup.portal.com
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   DECnet PCSA driver programmer needed

I need to get a driver written to an ethernet board for PCSA/DECdos (both the
DLL and scheduler). The board is very similar to the Micom and Exelan boards
(same chip). I work for a Fortune 10 company and we need this driver produced
ASAP.

I have the budget, do you have the talent? This is a serious message - speed 
is of the essence. Serious inquirys please contact me at one of the 
addresses below.

net: john_robert_breeden@cup.portal.com
attmail: !jbreeden
work phone (voice): 415-442-3838

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 19:26:22 GMT
From:      kate@NRC.COM (Kathi Samec)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP for Venix on Pro-350

In article <8906280250.AA01997@ucbvax.Berkeley.EDU> ABSTINE@CLVMS.CLARKSON.EDU ("Art Stine - Sr. Network Engineer") writes:
>Does anyone know of a TCP/IP implementation which works on Venix
>on a DEC Pro-350 (no snickers please... I didn't buy it...)? thanks alot
>
>art stine
>sr network engineer
>clarkson u

Network Research Corp has a version of TCP for the system you are talking 
about. It is an older version(about 2 years ago) but it works I guess.
-- 
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Kathi Samec  
 Network Research Corporation / nrcvax!kate@TRWIND.TRW.COM or kate@NRC.COM
 2380 North Rose Avenue       / hplabs!sdcrdcf!psivax!nrcvax!kate        
 Oxnard, Ca. 93030            / kate@nrcvax.UUCP                         
                           
 

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 20:07:21 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on PC/3C503

Our PC/TCP package includes a TN3270, and we support all the 3Com cards.
We don't share a single network interface with Sun's PC/NFS, but we do have
an add-on NFS client (called "Interdrive") which works with PC/TCP.

IBM has a TN3270 in their DOS TCP/IP package, and it runs on 3C501s (I don't
know about 3C503s), but it won't share with PC/NFS, and doesn't have an NFS
of its own.

Excelan has a TN3270 as an option to their DOS package, but it only runs
on Excelan cards, and they don't (to my knowlege) have an NFS.

If you want p-d software, your only choice is NCSA, which will run on
the 3Com cards, but won't share with PC/NFS, and doesn't have an NFS
of its own.  Once upon a time, Greg Minshall had a version of the Unix
tn3270 which ran on a U-B NIU's TCP/IP, but you couldn't build it
without a 'curses' library which wasn't on the distribution, and the
code hasn't been updated in the last couple of Berkeley tn3270 versions.

These are all the DOS tn3270s I know of.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 20:32:36 GMT
From:      lars@salt.acc.com (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes:
>1% /etc/ping multimax.encore.com
>PING multimax.encore.com: 56 data bytes
 ...
>64 bytes from 129.91.1.14: icmp_seq=3. time=213. ms
>64 bytes from 129.91.1.14: icmp_seq=3. time=220. ms
 ...
>64 bytes from 129.91.1.14: icmp_seq=8. time=284. ms
>64 bytes from 129.91.1.14: icmp_seq=8. time=289. ms
 
>Notice that I receive multiple replies on some of the requests.
>I have no reason to believe that my ping program is in error.
>What are some possible explanations for this behaviour, aside 
>from the obvious, that the recipient of the request is actually 
>generating multiple replies from a single ICMP echo request?

Somehow, two copies of an ICMP request made it to the host in question.
Are there redundant routes ? Could two datagrams have been forwarded by
two different gateways out of your LAN ?

/ Lars Poulsen <lars@salt.acc.com>     (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service                Affiliation stated for identification only
                  My employer probably would not agree if he knew what I said !!

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 21:19:29 GMT
From:      boykin@calliope.Encore.COM (Joseph Boykin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Multiple Echo Replies

In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes:
>I have been getting strange behaviour when pinging a particular
>host on the Internet.  I have not seen this behaviour with any
>other host.  
>>In article <25908@agate.BERKELEY.EDU> cliff@violet.berkeley.edu (Cliff Frost) writes:
>>Duplicate ICMP Echo Replies are an interesting phenomenon.  I've
>>seen a lot of them and in my experience they have never been caused
>>by errors at the recipient, although that is always a possibility.
 ...
>I don't think they always mean trouble.  I see them occasionally 
>going across the NSFNet backbone and yet we have no problems
>with the backbone.

The Internet host being talked about is mine, and since I've done must
of the TCP/IP hacking on this system I thought it would be useful
for me to respond.

Firstly, I have also seen multiple ICMP replies from various hosts
(although never from multimax.encore.com).  And as was also suggested,
I've never seen these to cause problems, either when we've recieved
them or in other cases.

Our host is hooked up to the Internet (NEARnet) via a Cisco gateway box.
In doing some experimentation we've found that the real cause of the problem
is that the gateway box is the one duplicating the reply messages.  At this
point we don't know why, but we'll look into it (after the July 4th holiday!).

In case anyone is interested... the system is an Encore Multimax 520 with
eight NS32532 CPUS's (8+MIPS/CPU) running a parallelized version of the MACH
operating system.

----

Joe Boykin
Encore Computer Corp
Vice-Chair, IEEE Computer Societies'
    Technical Activities Board

Internet: boykin@encore.com
UUCP: encore!boykin

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 21:35:02 GMT
From:      Makey@LOGICON.ARPA (Jeff Makey)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

In article <5896@ditmela.oz> hans@ditmela.oz.au (Hans Eriksson) writes:
>I wonder when one can go around the world in just 80 milliseconds...

The radius of the Earth is about 4000 miles, which gives a
circumference of about 25000 miles.  The speed of light is about
186000 miles per second, so the lower bound for going around the world
is 25000/186000 == 0.13 seconds or so.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@LOGICON.ARPA    UUCP: {nosc,ucsd}!logicon.arpa!Makey

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 89 22:19:12 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Re: World record furthest telnet: Australia -> Sweden

Actually, there is an IP link via the eastern hemisphere.  Its a 
MILNET sattelite shot via a bird over the indian ocean.

Mike

END OF DOCUMENT