The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 88 09:40:57 PDT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        lars@ACC-SB-UNIX.ARPA, tcp-ip@sri-nic.arpa
To: tcp-ip@sri-nic.arpa
Date: Mon, 1 Aug 88 08:44:14 PDT
From: lars (Lars J Poulsen)
Message-Id: <8808011544.AA13705@ACC-SB-UNIX.ARPA>
Subject: Re:  TCP/IP over X.25 under Unix ? (really: those damn cc-lines)

Sorry; along with Keith McCloughrie I confess to problems with editing
cc-lines, thus letting you all read a personal reply (Though the damage
may have been limited since it was in a furreign tongue).

	/ Lars Poulsen
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Aug 88 15:44:50 EDT
From:      Doug Greenwald <R1ECGF%AKRONVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   HP TCP/IP Conformance

Hi,

A few weeks ago, i saw something mentioned concerning problems with
HP systems with TCP/IP.  Something about problems getting HP's to work
with various gateways.  I would appreciate seeing this info again.  We
are currently looking at various vendors for networkable workstations,
an HP is one of the contenders, if you or they can show us that thier
workstations support TCP/IP and/or Ethernet networking with minimal
'adjustments'.

Please respond directly to me and I will sumarize to the net if there is
sufficient interest.

Doug Greenwald
Engineering Computer Graphics Facility
University of Akron

Bitnet:  R1ECGF@AKRONVM
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 11:53:33 GMT
From:      gregb@dowjone.UUCP (Greg_Baber)
To:        comp.protocols.tcp-ip
Subject:   Re: Instrumenting a TCP Implementation

In article <8807291003.AA24101@ucbvax.berkeley.edu> kzm@TWG.COM (Keith McCloghrie) writes:
[stuff eaten]
>> We, at the Department of Computer Science, University of Maryland, have
>> done an instrumentation of TCP/IP. Here is the abstract from the
>> Technical Report describing our work:
>> "We ....
>>                ... code)."
>> Interested persons can get a copy of the Report by sending mail to
>> 	tcplog@chakra.cs.umd.edu 
>> Please quote the following numbers in your request:
>> CS-TR 2063 and UMIACS-TR 88-50
Interested! Please send me the reports too.








>Thank-you,
>Keith.


-- 
Reply to: Gregory S. Baber		Voice:	(609) 520-5077
	  Dow Jones & Co., Inc.		E-mail:	..princeton!dowjone!gregb
	  Box 300
	  Princeton, New Jersey 08543-0300

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 18:07:00 EDT
From:      <enger@gburg.scc.com>
To:        "geoff" <geoff@usafa.arpa>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   VMS TCP/IP software
Geoff:

I will have to concur that Wollongong is expensive, but to some extent
you get what you pay for.  Those guys send engineers to all the networking
conferences.  TWG seems to be incorporating some of the more important
protocol enhancements into their products in a timely fashion.  Their version
3.2 software incorporates the Van Jacobson window adjustment scheme.

We use version 3.2 and are pretty happy with it.  When all I can find to 
complain about is CC: fields in the mailer (and thats a VMSmail problem really)
it can't be too bad a product, right?

The capability to keep up the with latest developments may become increasingly
important.  The ability to respond to Usage Sensitive Charging by incorporating
a more efficient telnet may be a big win to your budget.  If you use the TWG
package to connect to the wide area subnet you may appreciate their support
when BBN womps PSN 7.0 on you :-) .

Although I am not a user of the product, I have heard generally good reports
on the Multinet product.  This product was (maybe still is) available from
SRI.  I believe two of its developers have left SRI to persue the further
developement and enhancement of the product.  You may wish to review the 
recent TCP/IP archives to locate them.

Good luck in your quest,
Bob Enger
Contel Federal Systems



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 15:37:43 GMT
From:      eckert@faui10.uucp (Toerless Eckert)
To:        comp.sources.wanted,comp.unix.wizards,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Again: looking for gated

I looking for the sources of gated.

As i do not have access to the internet, i cannot get them through ftp.
I only have access to bitnet and uucp. I also could get files
using anonymous ftam over the PSN.

Is there any bitnet listserver that has gated, or can someone send me the
sources by mail ?

Toerless Eckert	(tte@derrze0.bitnet)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 18:41:35 GMT
From:      geoff@USAFA.ARPA (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   VMS TCP/IP software news

We have a number of VAXen connected via an ethernet and would like to
get them talking to our tcp/ip systems  Do you have any pricing
information yet and what about government or educational discounts?
We presently have Wollongong's software running on one of our systems
and I am not satisfied with it; plus it is so expensive.

	geoff

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 19:29:01 GMT
From:      bobn@ism780c.isc.com (Robert Noh)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   TCP/IP on VMS 5.0

Is there any implementation of TCP/IP that is ready to go
on VMS 5.0?  Or, is there an implementation that is
due to be released "real soon, now?"  

(Rumor has it that SRI's Multinet runs on 5.0.  Can anyone
confirm this?)

On a related note, does anyone have a list of TCP/IP implementations
that run on a multiprocessor machine?  This is more for a reference
than anything else, but I still would like the information.

Thanks in advance.  Post or mail your replies to me.  Any
mail responses will be summarized to the net.

Robert Noh              {sdcrdcf|attunix|microsoft|sfmin}!ism780c!bobn

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 19:44:50 GMT
From:      R1ECGF@AKRONVM.BITNET (Doug Greenwald)
To:        comp.protocols.tcp-ip
Subject:   HP TCP/IP Conformance


Hi,

A few weeks ago, i saw something mentioned concerning problems with
HP systems with TCP/IP.  Something about problems getting HP's to work
with various gateways.  I would appreciate seeing this info again.  We
are currently looking at various vendors for networkable workstations,
an HP is one of the contenders, if you or they can show us that thier
workstations support TCP/IP and/or Ethernet networking with minimal
'adjustments'.

Please respond directly to me and I will sumarize to the net if there is
sufficient interest.

Doug Greenwald
Engineering Computer Graphics Facility
University of Akron

Bitnet:  R1ECGF@AKRONVM

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 20:14:11 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Can anyone help this guy?

Hi, I got this note from a friend of mine in Tokyo (edited to remove
unnecessary text).  Can anyone help him out?  Thanks, -- Mark

Date: Mon 1 Aug 88 21:42:37
From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP>
Subject: Proxy ARP on SUN

Mark,

I have a question about Proxy ARP. My colligue in Tohoku University
wants to use Proxy ARP on SUN. As far as I know, there are two Proxy
ARP software. One is developed in U-texas and the other is developed
by Barry Shein(bzs@bu-cs.bu.edut). I've alreay seni, I got this note from a friend of mine in Tokyo (edited to remove
unnecessary text).  Can anyone help him out?  Thanks, -- Mark

Date: Mon 1 Aug 88 21:42:37
From: ken-ichiro murakami <MURAKAMI@NTT-20.NTT.JP>
Subject: Proxy ARP on SUN

Mark,

I have a question about Proxy ARP. My colligue in Tohoku University
wants to use Proxy ARP on SUN. As far as I know, there are two Proxy
ARP software

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 21:05:55 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Furreign tongue

Lars:

Dansk is not necessarily a furreign tonque--my basic problem was the
communications software for my PC at home does not provide immediate
interpretation of the european character sets.  The most made out of
your discussion was that support for the ACP6250 was provided and
available from some vendor in Stockholm.

Merton

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 21:16:57 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP over X.25 under Unix ?

Lars:

My CIT224 seems to be brain-damaged.  Is the "}" the "a" with the "o" on top
and the "|" a "o" with a "/"?  These were the only characters that wouldn't
translate correctly.

Merton

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 22:07:00 GMT
From:      enger@BLUTO.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   VMS TCP/IP software

Geoff:

I will have to concur that Wollongong is expensive, but to some extent
you get what you pay for.  Those guys send engineers to all the networking
conferences.  TWG seems to be incorporating some of the more important
protocol enhancements into their products in a timely fashion.  Their version
3.2 software incorporates the Van Jacobson window adjustment scheme.

We use version 3.2 and are pretty happy with it.  When all I can find to 
complain about is CC: fields in the mailer (and thats a VMSmail problem really)
it can't be too bad a product, right?

The capability to keep up the with latest developments may become increasingly
important.  The ability to respond to Usage Sensitive Charging by incorporating
a more efficient telnet may be a big win to your budget.  If you use the TWG
package to connect to the wide area subnet you may appreciate their support
when BBN womps PSN 7.0 on you :-) .

Although I am not a user of the product, I have heard generally good reports
on the Multinet product.  This product was (maybe still is) available from
SRI.  I believe two of its developers have left SRI to persue the further
developement and enhancement of the product.  You may wish to review the 
recent TCP/IP archives to locate them.

Good luck in your quest,
Bob Enger
Contel Federal Systems

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 88 23:25:49 GMT
From:      microsoft!jonsm@beaver.cs.washington.edu  (Jon Smirl)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Microsoft MAC/Vector interface

|  1. You do all of your binding (setting up handlers for incoming packets)
|  at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while
|  starting your protocol modules.

At OS/2 config.sys time a driver can actually do an awful lot *more* than
it can after config.sys time.  This is because it is running at ring 3 at
that time and can do file i/o for example.  After init, all driver code is
ring 0 and can't do any os services except devhlps.  If the above
remark is really about wanting to write protocol code to live at ring
3, this can actually be done within the present structure--see the
response to point 2 below.

Note that we will in the future be extending the protocol manager to add
dynamic binding and unbinding.    The current bind command logically can do
that today; all that is missing is the unbind command and a way to ask the
protocol manager to issue a binds and unbinds at run time.

In fact, the version 2 protocol manager spec will allow for several
run time functions, including dynamic binding, unbinding, and query/change
module config settings.  Ring 3 APIs to the protocol manager will let
applications invoke these services.  

|
|  2. You cannot un-bind, ever.  No transient network protocols built into
|  programs, no un-loadable protocol TSRs.  Instead, you have to edit a file
|  & reboot if you need more memory to run your CAD program or whatever....

See note about our planned bind/unbind extensions above.

Regarding transient protocols--on OS/2 you can do this by writing a stub
protocol module that interfaces to a ring 3 protocol daemon.  The daemon
would ioctl threads down to the stub to get requests and pass back
responses--or better, ioctl down the address of a shared memory area where
request queues could be managed between ring 0 and 3.  A similar thing
could be done on DOS 3.

Regarding unloading TSRs--again using the stub protocol module, you
could bring in the actual protocol code as an EXE which certainly
could terminate and free its memory.

Regarding "editing a file" to reconfig:  there is no requirement for a
module to take its config from protocol.ini, or to do it only at boot
time.  Modules can use private means to get config, including doing it
dynamically at run time via ioctls to the driver or whatever.  Modules can
be written to even resize themselves when run time reconfig happens--ie, if
they dynamically allocate their buffer space, or have an app-level daemon
do this for them.  (All this is saying is that if you are creative you
can even get the effect of dynamic reconfig sooner than when we provide
a standardized way for doing it).


|
|  3. Rather than telling MAC/Vector what kind of packets you want, instead
|  it goes down its list of handlers, asking them one after another "do you
|  want this packet".  This means that there is no possibility of
arbitration
|  (or even error detection) when two applications want the same type, and
|  opens the door for "badly behaved applications" to screw things up for
|  the rest of us.
|

We considered providing a way to provide packet dispatch info to the
vector, but providing adequate flexibility here was far more complexity
and overhead than seemed justified by the need.  What does it mean to tell
it "what kind of packet you want"--do you specify what the source address
should be, or destination SAP, or both, or some bit masked address compare,
or do you also want to include specific packet command codes, or protocol
type bytes, or other compare conditions, or what?  Cases can be made for all
these and more, and that just leads to absurd complexity for a
little-needed function.  In general it is a "configuration error" to have
two drivers installed that would conflict over what packets they want;
indeed, all that a complex descriptor mechanism would do is let you detect
this configuration error.  That would be nicer than not detecting it, but
again, the amount of overhead to detect this rather unusual error
condition did not appear justified.  The current polling scheme works just
fine for what we believe the 99% case to be--protocols sharing a mac where
the conflicts don't arise.  We are interested in any concrete suggestions
on what a better solution would be, or why there is some important need
not addressed by the current solution.


microsoft!jonsm
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 00:07:46 GMT
From:      Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP question

It appears that my message got damaged on the way out.  Anyway,
MURAKAMI@NTT-20.NTT.JP (or %NTT-20.NTT.JP@RELAY.CS.NET) is trying to
get ahold of software that supports Proxy ARP and is having problems.
He isn't directly on the Internet.  Can anyone help him?
-------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 13:36:48 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: How many people receive TCP-IP

enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.

	And then, don't forget to add in all the people who read TCP-IP as
its usenet alter ego, comp.protocols.tc-ip.  The most recent stats from
Brian Reid (which somehow I missed the first time around, for no reason
that I can explain) estimate that something like 9800 people see this
material in that forum.  My guess is that that far outweighs the count of
people who are on the mailing list, either directly or via mail exploders.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 14:08:48 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   BOOTP vendor support

I am in the midst of implementing network bootstrap code for
our Amiga NFS product.  I have the new Sun bootparams bootstrapper
stuff going, but it seems to fall short of what is really needed.
In particular we're a bit worried that Sun requires use of RARP
in bootstrapping and that casual perusal of vendor glossies shows
not much support for RARP by vendors other than Sun (and NFS licensees).  

BOOTP seems to be a whole notch better in the sense that it is
a simpler protocol, it supplies HDW -> Internet address translation
without using RARP, and using the vendor specific field (RFC-1048)
seems to provide everything a booting machine needs eg subnet mask,
UTC time offset, name server locn, etc.  Since BOOTP doesn't use
RARP we can provide portable source to our customers who do not 
have it.  Now, the question: who else is/will support BOOTP?  The
only other vendor I've seen supporting BOOTP is SGI.  Is BOOTP
a dead end in light of Sun ASI, etc?

While I've got your attention, is anyone aware of any efforts towards
automating IP address generation?  It would seem a natural extentsion
to either RARP or BOOTP, modulo the usual database consistency 
problems.

					Rick Spanbauer
					Ameristar

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 15:48:30 GMT
From:      rochester!srs!dan@bbn.com  (Dan Kegel)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP and NFS for MacOS?
I'm asking this on behalf of a friend at a large defense contractor, who 
doesn't have internet access (but does have lots of pretty missiles and guns).
He'd like to use his Unix boxes as file and CPU servers, and use a mix
of Mac SE and Mac 2 boxes as clients; Ethernet would be use to connect
everything.

We think there is an Ethernet card for the SE, so that's not a problem.

The question is software.  We know about TOPS; however, it hasn't yet been
ported to his particular Unix box.
Can anybody suggest TCP/IP and (oh, please) NFS (that's Sun's Network File
System) packages that run under the Mac OS?  Or any other networking 
alternatives?

Please reply by e-mail, and I'll summarize.
Thanks...
-- 
  Dan Kegel   "We had to get it passed before the columnists attacked!"
  srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 88 18:56:03 GMT
From:      jch@CHUMLEY.TN.CORNELL.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Again: looking for gated

Gated is available for annonymous FTP from devvax.tn.cornell.edu as
pub/gated/gated.tar.Z. 

Gated is available via electronic mail by sending mail to
gated-people-archive@devvax.tn.cornell.edu with a subject line of

	get gated.tar.*

Several pieces of mail will be sent to you which comprise a split,
uuencoded, compressed tar file.

Questions and experiences relating to gated may be sent to the gated
mailing list, gated-people@devvax.tn.cornell.edu.  Requests for addition
to the list should be sent to gated-people-request@devvax.tn.cornell.edu.

Jeff

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 88 21:59:26 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

In article <19880727152537.7.DCP@SWAN.SCRC.Symbolics.COM> DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) writes:
>... Networks
>are a LOT LOT bigger and broadcasts are on people's mind, whether it's a
>real problem or not.

Actually, it has always seemed to me that ARP -- the mapping between physical
addresses and logical ones, so to speak -- was the one place where use of
local broadcast was proper and defensible.  I personally would put ARP last
on the list of broadcast problems to be fixed, and a number of other things
much higher.  I have trouble believing that ARP by itself, if it were the
only use of broadcast, would be a real problem.  Is it really so?
-- 
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 00:43:25 GMT
From:      bdale@hpcsrc.HP.COM (Bdale Garbee)
To:        comp.protocols.tcp-ip
Subject:   Re: a proposed modification to ARP

>Let's also remember that ARP runs on 5 networks other than Ethernet
>(Experimental Ethernet, AX.25, ProNET, Chaosnet, and ARCNET)

Not to mention Amateur Radio AX.25 ala the KA9Q package.  

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 10:57:40 GMT
From:      DEDOUREK%UNB.CA@CORNELLC.CCS.CORNELL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Re: How many people receive TCP-IP

> enger@GBURG.SCC.COM writes:
> > An easy way to get a start at the determination is to look at the
> main > distribution list at the NIC. [...] some of those direct
>
>    And then, don't forget to add in all the people who read TCP-IP as
> its usenet alter ego, comp.protocols.tc-ip.  The most recent stats

Ditto the BITNET LISTSERV service.

John DeDourek, University of New Brunswick, Fredericton, N.B. Canada
dedourek@unb.ca  (dedourek@unb.bitnet)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 13:44:39 GMT
From:      dd@sei.cmu.edu (Dennis Doubleday)
To:        comp.protocols.tcp-ip
Subject:   Question about TCP/IP on VMS


I currently have an application running on Ultrix which uses TCP/IP.
Each machine in the network has a server running on it.  The server is
opened in passive mode and listens at a known port for traffic.  Under
Ultrix this "known port" is defined by adding an entry for my server
into the file /etc/services.  How is this done under VMS?  How are the
well-known ports defined?  Or does this depend on the TCP/IP software
you have?

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 15:22:51 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft MAC/Vector interface

The message from microsoft!jonsm was presumably a mis-posting, since it
replied to something I had said on pcip@udel.edu (comp.protocols.tcp-ip.ibmpc).
Unless people are interested, I won't debate DOS & OS/2 arcana here.

James VanBokkelen
FTP Software Inc.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:25:54 GMT
From:      mark@cbnews.ATT.COM (Mark Horton)
To:        comp.protocols.tcp-ip
Subject:   Re: ACSNET Access

In article <644@stcns3.stc.oz> dave@stcns3.stc.oz (Dave Horsfall) writes:
>Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz

What I don't understand is why some Australians advertise their addresses
as dave@stcns3.stc.oz, as shown in the From: line and the signature of
the referenced article.  .oz is NOT an official domain, while .oz.au IS.

The UUCP map does list .oz and knows how to get to it.  This puts .oz up
there with the other "semi-official" domains like .uucp, .bitnet, .cdn,
and the like.  People routing via UUCP can get to them, but people using
some other incarnation of the domain system, especially TCP/IP, cannot.

Posting to a worldwide computer network with an incomplete domain name
is like giving your phone number and forgetting the country code.  It
might work locally, but it doesn't necessarily work in some other country.

Please encourage other Australians to use the full name .oz.au on their
domain style addresses, unless they are really sure that the context is
specific to ACSNET.

>dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave

This stuff looks fine, although both are kludges to get around various
limitations when you're trying to say dave@stcns3.stc.OZ.AU .  If this
form doesn't work, then something is broken somewhere (or maybe the
person you're sending to just doesn't answer their mail.)

	Mark

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:44:35 GMT
From:      dennis@rlgvax.UUCP (Dennis.Bednar)
To:        comp.protocols.tcp-ip
Subject:   subnet IP mask stored in route or interface struct?

Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis.  However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis.  Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same
network should be adjacent.

In the figure below, the ---- lines represent a single physical
ethernet cable. Gw1, and gw2 stand for gateway 1 and gateway 2.
Both gw1 and gw2 below have multi-homed IP addresses (that is two
separate home addresses, one for each network connection).
In the figure below, subnet1 and subnet2 (in the same network)
are separated apart by a different network, consisting of just
a single subnet. Subnet 1 and 2 below are class C network addresses
containing 3 bytes of <network-number>, and 4 bits for the <subnet-number>.
The network in the middle is a class B network composed of 2 bytes
of <network-number>, and 4 bits for the <subnet-number>.

			    gw1		    gw2
	--------------------	------------	------------------
Name	subnet1			network		subnet2
Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20
IPmask	255.255.255.0xf0	255.255.0xf0.0	255.255.255.0xf0

The problem with using the IP mask for an interface is that
gw2 above will have trouble forwarding packets destined for hosts
in subnet1.  Suppose there is packet destined for host
192.7.8.0x11.  I will show the problem after giving some
background information.

------ Begin of some background information:

There is presumed to be 3 tables of routing table structures
containing
	<destination,	gateway,	flags, interface-ptr>.
These 3 tables are the host routing table, the subnet routing
table, and the network routing table.  Destination is the
IP address of a host (if in host routing table), of a subnet
(if in subnet routing table), or of a network (if in netowrk
routing table). The flag indicates if the route is direct (ie
through a local gateway or the home machine) or indirect thru
a remote gateway (ie the flag is used instead of the
recommended algorithm described in RFC950 to decide if the
packet should be sent directly or thru a gateway).  The interface
pointed to by interface-ptr is presumed to contain (at a minimum):
	< my_ip_addr,	my_ip_mask>

The 3 tables are searched in this order: host, subnet, network, using
the dg.ip_dest as a key into the route.destination field.  For a
host table search, all 4-bytes are compared.  The subnet table search
is described separately below.  The network table search compares
ip_network_of(dg.ip_dest) with route.destination. The search stops
when a route has been found. The subnet table search is this:

	for each subnet routing table entry
		if (route.dest == (dg.ip_dest & route.interface.my_ip_mask))
			{
			found = routing table entry;
			break;	/* stop table search */
			}

Once the route has been found, the route.flag tells whether to send
directly or through a gateway, as opposed to the recommended algorithm
described in RFC950.

---- end of background information

Now here is the problem: the subnet table search on gw2 above will
fail to locate the route entry in its subnet table, because the ip_mask
will strip off too many bits (2.5 bytes) causing the compare of
route.destination in the subnet table to fail:
	if (192.7.8.0x10 == (192.7.8.0x11 & 255.255.0xf0.0))
	if (192.7.8.0x10 == (192.7.0.0))

I would like to point out that by storing an IP mask on a per route
basis, this problem would go away, since the IP mask would be correct
for the destination subnet, which is remote to this particular network.

I would appreciate any comments on this matter.
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 16:58:07 GMT
From:      sow@eru.mt.luth.se (Sven-Ove Westberg)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Whois sources.


I would be very pleased to know where I could get programs
to Unix for the tcp/whois protocol and database?

Regards,

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel:     +46-920-91677  (work)                 +46-920-48390  (home)
UUCP:    {uunet,mcvax}!enea!cad.luth.se!sow
ARPA:    sow%cad.luth.se@ucbvax.berkeley.edu  (only dumb ARPA mailers)
Internet: sow@cad.luth.se
Bitnet:  sow%cad.luth.se@sekth

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:25:32 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP Conformance


   A few weeks ago, i saw something mentioned concerning problems with
   HP systems with TCP/IP.  ...

   We are currently looking at various vendors for networkable
   workstations, an HP is one of the contenders, if you or they can
   show us that their workstations support TCP/IP and/or Ethernet
   networking with minimal 'adjustments'.

I think this is worth answering to the whole list.  HP's Unix
machines do implement a full TCP/IP, and do work with other systems.
The networking is based on 4.2 BSD, and will be upgraded to use the
Van Jacobson algorithms at the earliest possible time.

[The Unix boxes are the HP9000 Series 300 (68000-based) and HP9000
Series 800 (RISC-based).  HP's name for their Unix OS is HP-UX.]

The HP3000 minicomputers (runnning MPE) use a limited version of the
TCP/IP protocols.  They do not support UDP, use real 802.3 instead
of Ethernet, and use HP Probe instead of ARP.  HP is working on
Ethernet and ARP for the HP3000.

The HP3000 uses proprietary login and file transfer protocols.
Regular ARPA services (Telnet, FTP, and SMTP) are available from The
Wollongong Group.

The HP1000 runs a TCP/IP which is similar to the HP3000, but the
1000 already support Ethernet, I believe.

If you have MPE systems, you need a gateway that talks 802.3 and
Probe.  The only gateways that do that are the HP9000 series 300 and
series 800 machines (HP-UX), and boxes from cisco Systems, Inc.

Walter Underwood
HP Software Engineering Systems
Palo Alto, CA

PS: HP-UX can set Precedence and Security on TCP connections.
Anybody wanna try it?

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:29:04 GMT
From:      deke@valhalla.ee.rochester.edu
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Status of NTP?


What is the status of NTP?  I have rfc958, is this the most (and
only) relevant document?

I would like to keep 35 or so machines on my networks time-synched
*with eachother*..... having that common time be "correct" is
icing on the cake.  Up till now I have tried using 4.[23]BSD timed
and /usr/ucb/rdate on UN*X machines, and they work fine, but I
certainly wouldn't mind using a more elegant method.


- Deke Kassabian
-------------------------------------------------------------------------------
\ deke@ee.rochester.edu                  "Experience is something you don't   /
\   or ...!rochester!ur-valhalla!deke     get until just after you need it."  /
\-----------------------------------------------------------------------------/

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 17:47:27 GMT
From:      ted@ultra.UUCP (Ted Schroeder)
To:        comp.protocols.tcp-ip
Subject:   Re: How many people receive TCP-IP

enger@GBURG.SCC.COM writes:
> An easy way to get a start at the determination is to look at the main
> distribution list at the NIC. [...] some of those direct recipients are
> mail exploders. [...] perform the above process iteratively to get some
> idea of the ultimate number of recipients.

ames!nyu.edu!phri!roy  (Roy Smith) writes:
>	And then, don't forget to add in all the people who read TCP-IP as
> its usenet alter ego, comp.protocols.tc-ip.

Also don't forget the bitnet shadow list TCPIP-L at BYUADMIN!

      Ted Schroeder                   ultra!ted@Ames.arc.nasa.GOV
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 ted@Ultra.COM
      408-922-0100

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 21:34:22 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's Algorithm for AT&T Stream Implementations

I hope someone on the net can answer to my question.
I am curious that whether we can apply Van Jacobson's Algorithm to
AT&T Stream TCP/IP implementations easily.
I would like to know more detail about Van Jacobson's Algorithm clearly.

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 88 22:13:09 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4

I hope someone can answer to my question.
I would like to know difference between 4.3 BSD and 4.4 BSD, and
between AT&T V.3 and AT&T V.4, in terms of networking implementations.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:02:30 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP Conformance


	From: Walter Underwood <wunder@sde.hp.com>
	
	I think this is worth answering to the whole list.  HP's Unix
	machines do implement a full TCP/IP, and do work with other systems.
	The networking is based on 4.2 BSD, and will be upgraded to use the
	Van Jacobson algorithms at the earliest possible time. ...

I am not sure that anything based on 4.2BSD is `full TCP/IP' (unless it
has had all the 4.3BSD fixes added), but in any case, 4.3BSD is
available for the HP9000 Series 300, from the University of Utah.

Chris

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:14:22 GMT
From:      amdahl!bungia!datapg!questar!bthpyd!wiebe@ames.arc.nasa.gov  (Glen Wiebe)
To:        tcp-ip@sri-nic.arpa
Subject:   Micom-Interlan NP100 ethernet woes

	We are in the process of installing a couple of Micom-Interlan
NP100 ethernet boards in two VAX 750s.  One I can get working and the
other I cannot.

	The VAX 750 on which it works has disks connected to an Emulex
massbus disk controller.  The VAX 750 on which I have trouble has one
RA81 disk on a DEC UDA50 disk controller. (I suspect this may be the
problem).  We are running the original 4.3bsd release.

	When powering up the system the NP100 goes through a series
of internal self diagnostics.  It never completes these successfully
and the driver (ix0) for the NP100 cannot reset it (it times out
waiting for a response).  The NP100 board is ok since it works fine
in the other VAX.

	Does anyone have ideas on what the problem might be?
Thanks.

--------
Glen J. Wiebe				UUCP	rutgers!bungia!bthpyd!wiebe
Bethel College, St. Paul, MN		ATT	(612) 638-6106
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 00:52:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet IP mask stored in route or interface struct?

Dennis Bednar (decwrl!sun!pitstop!sundc!rlgvax!dennis) asks:
    Does 4.3BSD store the IP subnet mask in the route structure
    (struct rtentry) or the interface structure (struct ifnet)?
    The reason I ask, is that RFC 950 suggests that it be stored
    on a per interface basis.  However, I have found a particular
    case (described below), in which it is better to store the mask
    on a per route basis.  Perhaps the example I have contrived
    violates an unmentioned assumption that subnets in the same
    network should be adjacent.

Yes, but this is not so much an "unmentioned assumption" as it is
a rule that is not stated in the most obvious place.  As an author
of RFC950, I suppose I must take the blame for not repeating in
RFC950 this statement from the first page of RFC940:

   The use of subnets is an optional local decision.  The fact that a
   network has subnets is invisible outside that network, and the change
   is local and can be instituted at a site without any global Internet
   perturbations.  A complex of links is assigned a single IP network
   number, and outside that complex it appears as a single network with
   that number.  Only inside does local structure appear.

[Note that the first paragraph of RFC950 says, in effect, "read RFC940."]

Following this rule, the "particular case" is in violation:

	    --------------------gw1----------------gw2------------------
    Name	subnet1			network		subnet2
    Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20

because the distinction between subnet1 and subnet2 would have to be
visible outside network 192.7.8.0 in order for things to work.

Solutions: Use different Class C numbers for the two isolated pieces,
or tie them together with a gateway connected to both subnets.  The latter
solution is less likely to fill up other people's routing tables.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 02:29:56 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   HP TCP/IP Conformance


   I am not sure that anything based on 4.2BSD is `full TCP/IP' (unless it
   has had all the 4.3BSD fixes added), ...

I agree, and the people that work on our TCP agree.  We have fixed the
behavior, but it is still a 4.2 programming interface.  That is why I
pointed out the 4.2 heritage.  Geez, I'd almost forgotten how bad 4.2
was ...

wunder

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1988 06:50-EDT
From:      CERF@A.ISI.EDU
To:        rochester!srs!dan@BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP/IP and NFS for MacOS?
I have been given to understand that there is a Unix for the MAC.
If that is true, NFS should be available as well. The MAC Unix
is called AUX, I believe. I don't have a point of contact, but
the product is supported by Apple, I believe.

Vint Cerf
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 03:09:56 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Status of NTP?

Deke,

See RFC-1059. Then, you might want to talk to Mike Petry, who has a 4.3bsd
daemon which is now chiming at a few dozen systems just now. Also, a bunch
of new radio clocks have come up, making the total at least seven going
on nine. Depending on your confidence and precision required, you might
want to run NTP on only a few of your machines and timed on the rest; however,
NTP depends for robustness on having a number of peers and using a weighted
selection algorithm to cast out the falsetickers.

Dave

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1988 07:19-EDT
From:      CERF@A.ISI.EDU
To:        rochester!ur-tut!ur-valhalla!deke@CU-ARPA.CS.CORNELL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Status of NTP?
Deke,

NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective
protocol and the RFC is in DRAFT STANDARD status.

Vint Cerf
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 88 12:02 EST
From:      <JFISHER%USGSRESV.BITNET@CUNYVM.CUNY.EDU> (James R. Fisher)
To:        tcp-ip@sri-nic.arpa
Subject:   tcp/ip for Amdahl UTS
Hello:

   We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO
on an Amdahl 5890.
   We want a tcp/ip implementation for it; I'd be happy to hear from
anyone out there who knows any vendors of tcp/ip for such an environment.

Thanks much.
Jim Fisher
jfisher@usgsresv.bitnet
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 10:50:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and NFS for MacOS?

I have been given to understand that there is a Unix for the MAC.
If that is true, NFS should be available as well. The MAC Unix
is called AUX, I believe. I don't have a point of contact, but
the product is supported by Apple, I believe.

Vint Cerf

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 11:19:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Status of NTP?

Deke,

NTP RFC 1059 dated July 88 just released. RFC 1059 is an elective
protocol and the RFC is in DRAFT STANDARD status.

Vint Cerf

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:11:48 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and NFS for MacOS?

This month's BYTE has a rather scathing set of articles on A/UX - Unix
for the MAC.  A/UX appears to be closest to system V than any of the
other UNIXs.

But hold on to your wallet - it costs either $5000 or $10,000
depending on your system configuration - this is *without* source code
(which does not appear to be available at this time)  

Mike

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:25:00 GMT
From:      LENTZ@NUACC.ACNS.NWU.EDU ("Beat the system, pull the plug.")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for AT&T UNIX-PC 7300's

Subject: TCP-IP for AT&T UNIX_PC 7300's

	I hope someone can help me.  I am a student in the Integrated
Science Program at Northwestern University and we would like to hook our
7300's to the local campus network.  This requires TCP/IP software, which
we do not know where to obtain.  Can anyone make any recommendations?  Also
can the 7300 handle a 19200bps line for the connection?  I seem to remem-
ber some discussion regarding this problem a couple of weeks ago but 
skipped over it at that point as it was not relevent then.  Will modifications
to the daemons help reduce the overhead so that the 7300 will be able to
keep up with the traffic it must handle?  Please excuse any ignorance on my
part as I am still new to  UNIX and the 7300's.  Thanks.

						Robert Lentz
					Bitnet: Lentz@Nuacc
					Internet: Lentz@Nuacc.Acns.Nwu.Edu

P.S.   If anybody can recommend a good source for MMDF or another good mail
	program this would also be appreciated. 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 13:52:09 GMT
From:      ooblick@lts.UUCP (Mikki Barry)
To:        comp.newprod,comp.protocols.tcp-ip,comp.sys.mac
Subject:   TCP/Connect - NCSA Telnet Plus Support

Learning Tree Software, Inc. would like to announce the formation of
a new company:  InterNet Systems Corporation.  ISC is modifying the
existing NCSA Telnet for the Macintosh to produce new and nifty features, 
and is offering telephone support.  We will begin shipping this new product
Sept. 1.

The price of $495 (with substantial discounts for multiple copies) includes
an updated manual, the software, and one year of telephone support.
Current NCSA Telnet users can contact us for special pricing. (703)
435-8170.  Until InterNet Systems Corp. gets on the net, LTS will
forward mail sent to uunet!lts!comment.

InterNet Systems Corp. will be at MacWorld sharing the Kinetics
booth.  We will have a special show discount for this product, as
well as RealTalk, a new and nifty product similar to "talk" on Unix
systems.  It also includes a file transfer program, and window servers.
Current pricing is $79.95 for one, or $219.95 for a three pak (in a
peachy keen binder that will light up your bookshelf).  It has so many
neato features that you really should come see it at MacWorld.

Mikki Barry
Grand Poohbah

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 14:02:16 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Ken Olsen on TCP/IP

Quoted without permission from Digital News, August 1, 1988:

"Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks.'"

Does this reflect a lack of confidence in the Ultrix group?

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 14:18:57 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   subnet IP mask stored in route or interface struct?

Your configuration is illegal per RFC 1009.  To quote:

         The interconnected LANs of an organization will be given the
         same network number but different subnet numbers.  The
         distinction between the subnets of such a subnetted network
         must not be visible outside that network.  Thus, wide-area
         routing in the rest of the Internet will be based only upon the
         <Network-number> part of the IP destination address; gateways
         outside the network will lump <Subnet-number> and <Host-number>
         together to form an uninterpreted "rest" part of the 32-bit IP
         address.

The whole point of subnets is to provide a LAYERED, HEIRARCHICAL
approach to routing.  Anyone outside the subnetted network must be
able to route solely on the basis of network number.  Hosts on your
network 128.5 cannot do this.  Your configuration does not work
because it is illegal.

It is surely possible to envision all sorts of ways of "solving" this
supposed problem.  But then you will fail to solve the problem that
subnetting was intended to solve.  That problem was that routing at
the upper (network) layer was overloading from too many networks.
Subnets, by hiding a layer of the network topology, solved this.  The
restrctions of subnets are readily dealt with by proper (sub)network
design.

[The same approach was applied to DECnet in Phase IV, with areas.
What you are asking for is the equivalent of allowing node 7.33 in
DECnet to plopped down in the middle of area 5 and have it work.]

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 14:40:03 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Precedence & IP Options (was: HP TCP/IP Conformance)

I can testify that HP UX doesn't have the 4.2 "crash on unknown IP option"
bug (which at least a couple of other 4.2-derived Unices still have).

If you (or anyone else) have Internet hosts which you would like to check
out with TCP using Precedence and the IP Basic & Extended Security options,
send me mail, giving the name & IP address, and any other constraints you
would like to impose (I will not be able to deliver on 'a phone call before
you try it').  Commercial IP routers from Proteon, and the MIT C-gateway,
are known to forward packets containing these options.  4.3 Unix and cisco
terminal concentrators handle them correctly at the application layer, so
I have hopes that 4.3 & cisco routers will forward them as well.  If you
are connected to the Internet via a 4.2-based router, it may fail to forward
the packets, or even crash.

I will reply with e-mail declaring a time when I will do the testing (which
can interrupt operations on some hosts, e.g. SunOS 3.4 and Ultrix 2.0).  I
will use ICMP Echo Request and TCP (usually finger, Telnet or SMTP if finger
isn't supported) to test behaviour.  Symptoms I have observed while testing
the Basic & Extended security options include:

	Go deaf to the net for 5 minutes on either Ping or TCP (but not crash)
	Ignore Ping, crash on TCP or UDP.
	Ignore Ping and TCP.
	Ignore Ping, Reset attempted TCP connections.
	Ignore Ping, open TCP connections ok.
	Reply w/o option to Ping, open TCP connections ok.
	Reply w/option to Ping, ignore TCP connection attempts.
	Reply w/option to Ping, Reset attempted TCP connections.
	Reply w/option to Ping, open TCP connections ok.

The current list of implementations that I have observed correctly supporting
TCP with IP Precedence is:

	Wiscnet on IBM VM systems.
	KA9Q on IBM PCs.
	PC/TCP v2.03 (in beta test).

The list of implementations which I have observed as unable to handle the
RFC-1038 IP Security options will appear later this month.

James VanBokkelen
FTP Software Inc.
(617) 868-4878
jbvb@vax.ftp.com

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 15:52:28 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP and NFS for MacOS?

> Mike St. Johns writes:
>
> But hold on to your wallet - it costs either $5000 or $10,000
> depending on your system configuration - this is *without* source code
> (which does not appear to be available at this time)  



If this is indeed the cost, it might be less expensive to get
source code from another place, and then pay a team of developers
to adapt it for the new machine.

Not necessarily a joke, but perhaps a semi scathing commentary on
the price.

these are my comments and are probably not the views of my employer.

Don

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 16:49:56 GMT
From:      tjb@Apple.COM (Tom Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and NFS for MacOS?

In article <8808041311.AA03609@beast.DDN.MIL> stjohns@BEAST.DDN.MIL (Mike St. Johns) writes:
>This month's BYTE has a rather scathing set of articles on A/UX
Scathing...hmmm...in my humble interpretation, I would say perhaps
lukewarm.  The summary in the review says "...[A/UX is] a good
first step toward the MacII into a Unix workstation."  Anyway, lest I be
accused of out-of-context quoting, it's best to judge for one's self.
A recent issue of UNIX World had a fairly positive review (not sure
which issue, sorry), as did the June 27 issue of UNIX Today
(BTW, I am a contractor, not an Apple employee).

>But hold on to your wallet - it costs either $5000 or $10,000
>depending on your system configuration - this is *without* source code

I'm not sure if it's clear from this posting that these prices include the
fully configured MacII (monitor, floppies, 80Mb hard drive, etc.).

Those interested in details about A/UX can read or post requests
to comp.unix.aux.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 17:02:00 GMT
From:      JFISHER@USGSRESV.BITNET (James R. Fisher)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for Amdahl UTS

Hello:

   We will soon be running Amdahl's UTS (Unix) version 1.2 under VM/HPO
on an Amdahl 5890.
   We want a tcp/ip implementation for it; I'd be happy to hear from
anyone out there who knows any vendors of tcp/ip for such an environment.

Thanks much.
Jim Fisher
jfisher@usgsresv.bitnet

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 17:17:27 GMT
From:      adelman@WARBUCKS.AI.SRI.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about TCP/IP on VMS

> I currently have an application running on Ultrix which uses TCP/IP.
> Each machine in the network has a server running on it.  The server is
> opened in passive mode and listens at a known port for traffic.  Under
> Ultrix this "known port" is defined by adding an entry for my server
> into the file /etc/services.	How is this done under VMS?  How are the
> well-known ports defined?  Or does this depend on the TCP/IP software
> you have?

    Depends on the TCP/IP software you have. On MultiNet you add an
entry to a text file which gets compiled into a binary database and
loaded into a global section for fast access. On WINS/TCP I believe
that you add an entry to the etc:[000000]services file just like under
Unix.  Well known ports don't HAVE to be defined in these files, it
just makes it convenient because your code can reference the port by
name instead of number.

						Kenneth Adelman
						TGV

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 20:08:55 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and NFS for MacOS

The misinformation is getting a little thick.

AUX for Apple's Macintosh II is a port of System V with BSD networking,
(I don't know how many 4.3 enhancements are in 1.0, 1.1 should be full
4.3BSD TCP/IP) other BSD enhancements and full NFS support.  It works.
Right now it is plain vanilla, X is coming, black and white only for now,
Mac ToolBox graphics are available.  The auto-config has everyone else's
UNIX beat.  Running AUX doesn't prevent you from running MacOS, just
takes up a whole 80MB drive.

AUX does NOT cost more than $1000.
If you buy two Mac II systems with identical hardware, one with AUX and
the other with MacOS (the original Macintosh operating system), then you
will find the cost of AUX is anywhere from $200 to $500 depending on
the hardware you actually buy.  Plus manuals, 6-foot set, isn't real
cheap, order separately.  If you call the extra expense of the hard
disk a part of the UNIX cost, then you haven't been running many Suns.

This is a full product line, dealers and everything, contact your nearest
AUX-certified Apple dealer or a sales office.

Below this line, I am referring to MacOS, NOT AUX.  For you PC users,
think of this as DOS vs. XENIX, one has the applications, the other
is UNIX.
------------------------

There is no commercial NFS for the Mac.  Cayman Systems (Cambridge, MA,
(617)494-1999) is releasing "real soon now" a box which converts NFS to AFP,
the Apple Filing Protocol standard for shared disks under MacOS.
NFS for MacOS in software is doable, primarily for Ethernet-equipped
Macs, no announcements that I know of.

TCP/IP for MacOS has been announced as "in development" at Apple in
Cupertino.  Target for release is before end of 1988.  Demos scheduled
for the TCP/IP Interoperability Conference in September.

There are no commercial releases of TCP/IP or TCP/IP applications for MacOS
shipping that I know of at the time I am writing this.  Before the end of
the year, expect 4 or more vendors to ship.

University products are available from Cornell, Brown, Illinois (NCSA),
Michigan, and Stanford, but some are restricted use.

I am biased, Anonymous FTP to 128.174.20.50 for release package and source
to NCSA Telnet for the Macintosh.  What can you lose, it's public domain?


I tried to stick to facts, but if there are any opinions above, they are
my own.


Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)

National Center for Supercomputing Applications (NCSA) 
University of Illinois, Urbana-Champaign

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 88 20:17:27 GMT
From:      john@twg-ap.UUCP (John Caughy)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: TCP/IP on VMS 5.0

From article <12515@ism780c.isc.com>, by bobn@ism780c.isc.com (Robert Noh):
> 
> On a related note, does anyone have a list of TCP/IP implementations
> that run on a multiprocessor machine?  This is more for a reference
> than anything else, but I still would like the information.
> 
The implementation for the HP 9000 500 series from Wollongong operates
in a multiprocessor environment.  The TCP/IP provides a single thread
for all users of the system and appears to be quite responsive.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 08:16:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE:  Van's algorithm's in Streams
This is in response to Kwang Sung's query:

Our newest version of Streams TCP contains Van's and Nagles algorithms
for congestion control, etc.  The header-predection performance code is
scheduled for addition, shortly, although we are still trying to understand
its impact under mixed traffic conditions.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 09:37:00 PDT
From:      Leo J McLaughlin <ljm@twg.com>
To:        tcp-ip <tcp-ip@louie.udel.edu>
Subject:   802.3 routing
>>   A few weeks ago, i saw something mentioned concerning problems with
>>   HP systems with TCP/IP.  ...

>>   We are currently looking at various vendors for networkable
>>   workstations, an HP is one of the contenders, if you or they can
>>   show us that their workstations support TCP/IP and/or Ethernet
>>   networking with minimal 'adjustments'.


>The HP3000 uses proprietary login and file transfer protocols.
>Regular ARPA services (Telnet, FTP, and SMTP) are available from The
>Wollongong Group.

>If you have MPE systems, you need a gateway that talks 802.3 and
>Probe.  The only gateways that do that are the HP9000 series 300 and
>series 800 machines (HP-UX), and boxes from cisco Systems, Inc.

>Walter Underwood
>HP Software Engineering Systems
>Palo Alto, CA


The Wollongong Group also provides a product that allows a PC to function
as a gateway for MPE systems, WIN/ROUTE2.

leo j mclaughlin iii
Project Leader
The Wollongong Group

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 06:09:43 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: Difference between 4.3 BSD and 4.4 BSD, and between V.3 and V.4

4.4BSD does not exist.  There is a post-4.3-BSD release of TCP; it
is available via anonymous FTP from Berkeley.edu.  It implements
the `Jacobsen/Karels' algorithms.

(The new TCP code is included in 4.3BSD-tahoe.)

Chris

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 08:28:00 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, root@sbcs.sunysb.edu
Subject:   Re: BOOTP vendor support

The only vendor that I know uses bootp is cisco.  Their gateways can
use it to get IP addresses.  (They can also use RARP - they send both
types of request, and believe whichever response they hear.)  They
also have the code needed to pass bootp requests across gateways.
I've never understood why other vendors don't use it, since it's
clearly easier to install than RARP, and more general.  I've not had
any trouble bringing up bootp on Unix systems, and it should also be
possible on Unix-based stuff like TWG's IP for VMS.  I'd be inclined
to use bootp anyway for any new products.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1988 13:43-EDT
From:      CERF@A.ISI.EDU
To:        LENTZ@NUACC.ACNS.NWU.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP-IP for AT&T UNIX-PC 7300's

FTP Software can supply PC-based TCP/IP if you are running MS/DOS.
FTP Software is in Cambridge, MA. There are undoubtedly other sources
of supply including freeware say from MIT/LCS.

The DDN Network Information center at SRI International is another
good place to check - they have a lengthy catalog of software 
which they have compiled as "DDN Protocol Implementations and
Vendors Guide" NIC 50002. It is also available on-line at
SRI-NIC.ARPA.

MMDF is available from Prof. David Farber, University of Pennsylvania,
Computer and Information Systems: farber@cis.upenn.edu

Vint Cerf
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:51:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Accidentally including the CC line
This is in reply to Bob <enger@gburg.scc.com> note:

Some people may have missed the trailing smile at the end of your comment
about wishing you could accidentally replying to CC recipients.  I force 
myself to use our VMS product, mostly out of masochism but partly so issues
such as the one you raise are familiar.  Keith McCloghrie works on a number
of our products, but not the VMS one, so he can affort the luxury of
using a Unix interface (MH, when last I checked).

Why should I burden everyone with this clarification?  Well, the problem
is that the VMS user interface to mail, with our TCP product, is standard
DEC issue, called VAXmail.  While we have integrated into it as best
possible, through their foreign service interface, we do not touch the basic
vaxmail product.

We are thinking of offering a richer mail system for a number of platforms,
but that is mostly my way of trying to find an excuse to use some old
but fondly rememebered experiences.  

Another alternative, shortly, will be All-In-One.

Dave Crocker
The Wollongong Group


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 10:36:55 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Micom-Interlan NP100 ethernet woes

The NP100 driver included in 4.3BSD (presumably written by or for
Interlan; at any rate, it was not done at Berkeley) is egregiously
buggy.  A later revision of the driver (done after Berkeley got an
NP100) is available from Berkeley, either as part of 4.3BSD-tahoe or
separately.  Contact Keith Bostic <bostic@okeeffe.berkeley.edu> if you
need just the driver.

Chris

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 88 17:01 EST
From:      "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)", <LEICHTER@Venus.YCC.Yale.Edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Moderated Newsgroup Posting
Path: venus!leichter
From: leichter@venus.ycc.yale.edu
Newsgroups: mail.tcp-ip
Subject: Re: Ken Olsen on TCP/IP
Message-ID: <34@venus.ycc.yale.edu>
Date: 5 Aug 88 17:01:31 GMT
References: <venus mail.tcp-ip:1807>
Organisation: VMS NEWS V4.0
Lines: 32

In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes:
> Quoted without permission from Digital News, August 1, 1988:
> 
> "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
> system, because we can't fix it if it breaks.'"
> 
> Does this reflect a lack of confidence in the Ultrix group?

The actual, full quote - from Ken Olsen - is:

	"Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
	 system, because we can't fix it if it breaks - nobody can.'"
						     -------------

It's generally considered unfair to quote out of context.  To CHANGE the con-
text - to deliberately mark something as a full sentence, with no indication
that you've left out part of the text, a part which changes the mean of what
came before - is bad enough.  To then continue on and ask a question based on
the falsely-imputed meaning is downright dishonest.

Olsen goes on to clarify what he means even further:

	"TCP/IP is OK if you've got a little informal club, and it doesn't
	 make any difference if it takes a while to fix it."

Now, you can disagree with this statement - probably most of the readers of
this list WILL disagree, though perhaps not all.  But there's a world of
difference between disagreeing on the merits, and the intellectual dishonesty
of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning
to them that wasn't there to start with.

							-- Jerry
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 13:35:04 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and NFS for MacOS?

There were actually two articles - one about Apple in general, and
another about the A/UX stuff.  The one about Apple in general starts
out with "... A/UX is another of Apple's software mistakes."
The other article was kinder.

Mike

(THis is the August 1988 issue of Byte we are discussing /msj/)

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 14:08:09 GMT
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

Cisco's bootp also works on the terminal server in SLIP mode.  I've
used the CMU PCIP distribution with it and it worked first time.  No
more custom netdev on 8 million PC's.
/a

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 14:13:30 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

I agree with the opinion that BOOTP is a good way to initialize a dumb
device. We at Digital Communication Associates are designing new products
that use BOOTP and TFTP to downline load code and configurations. A 
manufacturer of communications equipment has a great deal of impetous
to support these protocols. He requires them to boot. We will support 
BOOTP on both our large, disk based systems and our small diskless units.
In a typical configuration, the dumb devices will boot from the disk-based
units. When a customer wants only the smaller, cheaper units, they will have 
to boot from another vendor's device.

I am curious whether the minicomputer-oriented vendors will include support 
for BOOTP in their standard distributions. TWG, SRI, NRC, etc would be
well served by including as much functionality as possible. However, 
I wonder if the minicomputer manufacturers will be as likely to support
a protocol to load generic hardware. Would they fear selling fewer units
of there own diskless stations and terminal servers ? I also would like to
know of other BOOTP implementations to test against. 

Bill VerSteeg
DCA

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 15:16:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   RE:  Van's algorithm's in Streams

This is in response to Kwang Sung's query:

Our newest version of Streams TCP contains Van's and Nagles algorithms
for congestion control, etc.  The header-predection performance code is
scheduled for addition, shortly, although we are still trying to understand
its impact under mixed traffic conditions.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:18:01 GMT
From:      spl1!laidbak!stevea@elroy.jpl.nasa.gov  (Steve Alexander)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Van Jacobson's Algorithm for AT&T Stream Implementations
In article <160@bud.UUCP> kwang@bud.UUCP (Kwang Sung) writes:
>I am curious that whether we can apply Van Jacobson's Algorithm to
>AT&T Stream TCP/IP implementations easily.

Lachman's System V STREAMS TCP has been shipping with Van's TCP (as
well as the latest UCB IP and UDP fixes) since June.  Van's algorithms
were easy to integrate into our code.  The fact that we run over STREAMS
had no impact at all.

At the performance seminar in May, a great deal of material was handed
out that described these enhancements.  Perhaps ACE has extra copies
that you could obtain from them.

Their address is:

	Advanced Computing Environments
	480 San Antonio Rd, Suite 100
	Mountain View, CA 94040
	415-941-3399

Hope this helps...

Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com
Lachman Associates, Inc.            | ...!{ihnp4,sun}!laidbak!stevea
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 16:37:56 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

Not exactly a vendor, but the MIT uVAX C-Gateway also uses bootp, not only
to find out its IP address but also to invoke TFTP to boot the gateway
code.  The gateway code also has the ability to forward bootp requests
through to appropriate bootp servers if necessary.  With the one exception
that the boot code had to be specific to a subnet (because the 4.2 servers
would only recognize broadcast addreses of the form net.subnet.0) bootp
has worked very well.

Also, CMU has been using bootp to auto-configure IBM PC's for quite a while
using the bootp vendor field to set the various other things the PC's need
to know.  [Now for the vendor support part] We'll be including a bootp
client for configuring PC's using the CMU style vendor field (actually
either CMU style or RFC-1048) with our next release.

						David Bridgham
						FTP Software

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 17:15:36 GMT
From:      cam%columbia-pdn@ACC-SB-UNIX.ARPA (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Enet + TCP/IP for Honeywell

Folks,

Does anyone know of a tcp/ip implementation for Honeywell systems and the
associated enet hardware?

Chris Markle - ACC
cam%columbia-pdn@acc-sb-unix.arpa

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 17:43:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for AT&T UNIX-PC 7300's


FTP Software can supply PC-based TCP/IP if you are running MS/DOS.
FTP Software is in Cambridge, MA. There are undoubtedly other sources
of supply including freeware say from MIT/LCS.

The DDN Network Information center at SRI International is another
good place to check - they have a lengthy catalog of software 
which they have compiled as "DDN Protocol Implementations and
Vendors Guide" NIC 50002. It is also available on-line at
SRI-NIC.ARPA.

MMDF is available from Prof. David Farber, University of Pennsylvania,
Computer and Information Systems: farber@cis.upenn.edu

Vint Cerf

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 18:55:34 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Re: Micom-Interlan NP100 ethernet woes


Substantial changes have been made to the Interlan np100
driver that was distributed with 4.3BSD.  If anyone is
attempting to use this driver, please contact me for a
new copy.

Keith Bostic

bostic@ucbvax.berkeley.edu
uunet!keith

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 18:59:00 GMT
From:      dan@srs.UUCP (Dan Kegel)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Summary: TCP/IP and NFS for the Mac

I recently asked the net for info about networking for the Mac SE, and
recieved many helpful responses.

There seem to be only two systems that let plain old Mac programs transparantly 
access files on a remote Unix fileserver:

1. TOPS, a proprietary network file system developed independantly 
   and later purchased by Sun; this has been available for some time.
   The only Unix box that TOPS currently runs on is the Sun-3.
   Either LocalTalk or Ethernet may be used to connect the Macs to the Sun.
   TOPS phone number is (800) 445-8677 or (415) 769-8700.
   System cost:
    Software:
     TOPS server on Sun ($900 for 1-4 clients, $1600 for 1-16 clients)
     TOPS client on Mac ($250 per client)
    Hardware:
     using LocalTalk: $50 per client + $2000 for the Kinetics Fastpath bridge
     using EtherTalk: $600 per client

2. Cayman Systems' Gatorbox, an NFS (Ethernet) to AFP (LocalTalk) bridge; 
   the box and software sell for $3495, and takes about 6 weeks to get.
   The Unix box must be running NFS (and most can; many are shipped with it).
   It links up to 32 Macs running Apple's network (AFP on LocalTalk) to 
   a standard Ethernet network.
   Cayman Systems' phone number is (617) 494-1999.
   System cost:
	$50 per client (for LocalTalk cable) + $3500 for the Gatorbox bridge

Other NFS systems, rumored but not currently available, are
3. University of Michgan had a client version of NFS for the Mac at last 
   years Sun Connectathon.  Don't think they ever fielded it.

4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project 
   that put tcp/ip and NFS on Macs, under contract to Apple.
   Apple has the software now; it's unclear when if ever they will release it.

LocalTalk is Apple's 200 kilobit/sec serial networking hardware, which
is quite slow compared with the 10 Megabit/sec Ethernet;
one might therefore expect to be able to connect up only five or ten Macs
per LocalTalk bus before seeing degradation, as opposed to fifty or so on an 
Ethernet bus.  (I've never tried it, so I dunno.)


There are also systems available that let TCP/IP aware programs communicate
with other machines on an Ethernet; this isn't as nice as transparant file
access, but it can be pretty darn useful.

1. Kinetics sells Ethernet boards for all versions of the Macintosh; it
   also sells a TCP/IP (Ethernet) to TCP/IP (Appletalk) bridge.

2. NCSA maintains a professional-looking TELNET package for the PC and the Mac
   which supports remote login, multiple VT102 emulation, Tek 4014 emulation,
   subnetting, and dynamic IP address assignment via RARP.
   I think this is shipped with Kinetics equipment.
   It is available for anonymous FTP over the Darpanet from 
   ftp.ncsa.uiuc.edu   (128.174.20.50).   Contacts listed on their blurb:
       Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)
       Gaige B. Paulsen             gaige@ncsa.uiuc.edu
       National Center for Supercomputing Applications (NCSA)
       University of Illinois, Urbana-Champaign

3. Either Stanford or Columbia maintain something called KIP and CAP
   which seems to be another TCP/IP package; NCSA would know more about it.

4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation.

Thanks to everybody who replied.  I'm still looking for something that
supports NFS over Ethernet right to the Mac...
-- 
  Dan Kegel   "We had to get it passed before the columnists attacked!"
  srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 20:29:51 GMT
From:      ozalp@aya.cs.cornell.edu (Ozalp Babaoglu)
To:        comp.protocols.tcp-ip
Subject:   x.25 as an internet backbone



suppose a country (italy, to be precise) currently has a single
internet site (in pisa) and has been registered as a top-level domain
(domain .IT).  there are three class C type IP addresses
allocated to the country.  what are some reasonable ways to structure
subdomains in this country domain and incorporate LANs at other
sites (cities) into the internet? the physical transport medium
available is x.25 (both private and PDN run by the telephone company).

what is the technology of choice for ethernet-x.25 gateway hardware
and the software to do the routing and encapsulation (of IP
packets over x.25)?  any suggestions will be appreciated.

	ozalp babaoglu

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 88 02:53:00 EST
From:      "BARRY NEWTON" <newton@enh.nbs.gov>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Advertising
If everybody on the tcp-ip distribution list were to give the "Grand Poohbah"
one telephone call on his thoughtfully provided number, he might come to
a more clear understanding of the value and consideration involved in 
keeping crowded resources clear...

But don't do it.  It wouldn't be nice:-)

Barry

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 22:01:00 GMT
From:      LEICHTER@Venus.YCC.Yale.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
To:        comp.protocols.tcp-ip
Subject:   Moderated Newsgroup Posting

Path: venus!leichter
From: leichter@venus.ycc.yale.edu
Newsgroups: mail.tcp-ip
Subject: Re: Ken Olsen on TCP/IP
Message-ID: <34@venus.ycc.yale.edu>
Date: 5 Aug 88 17:01:31 GMT
References: <venus mail.tcp-ip:1807>
Organisation: VMS NEWS V4.0
Lines: 32

In article <venus mail.tcp-ip:1807>, jqj@hogg.cc.uoregon.EDU writes:
> Quoted without permission from Digital News, August 1, 1988:
> 
> "Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
> system, because we can't fix it if it breaks.'"
> 
> Does this reflect a lack of confidence in the Ultrix group?

The actual, full quote - from Ken Olsen - is:

	"Our attitude with TCP/IP is, 'Hey, we'll do it, but don't make a big
	 system, because we can't fix it if it breaks - nobody can.'"
						     -------------

It's generally considered unfair to quote out of context.  To CHANGE the con-
text - to deliberately mark something as a full sentence, with no indication
that you've left out part of the text, a part which changes the mean of what
came before - is bad enough.  To then continue on and ask a question based on
the falsely-imputed meaning is downright dishonest.

Olsen goes on to clarify what he means even further:

	"TCP/IP is OK if you've got a little informal club, and it doesn't
	 make any difference if it takes a while to fix it."

Now, you can disagree with this statement - probably most of the readers of
this list WILL disagree, though perhaps not all.  But there's a world of
difference between disagreeing on the merits, and the intellectual dishonesty
of picking words OUT OF THE MIDDLE OF A SENTENCE and ascribing a new meaning
to them that wasn't there to start with.

							-- Jerry

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 23:23:37 GMT
From:      winter@Apple.COM (Patty Winter)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Summary: TCP/IP and NFS for the Mac

In article <944@srs.UUCP> srs!dan@cs.rochester.edu (Dan Kegel) writes:
>
>4. Phil Karn's KA9Q package is another (public-domain?) TCP/IP implementation.
					^^^^^^^^^^^^^^^^

For amateur radio and university research uses, yes. Otherwise, no.



Patty

=============================================================================  
Patty Winter N6BIS                        DOMAIN: winter@apple.com
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
=============================================================================

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 88 23:51:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Accidentally including the CC line

This is in reply to Bob <enger@gburg.scc.com> note:

Some people may have missed the trailing smile at the end of your comment
about wishing you could accidentally replying to CC recipients.  I force 
myself to use our VMS product, mostly out of masochism but partly so issues
such as the one you raise are familiar.  Keith McCloghrie works on a number
of our products, but not the VMS one, so he can affort the luxury of
using a Unix interface (MH, when last I checked).

Why should I burden everyone with this clarification?  Well, the problem
is that the VMS user interface to mail, with our TCP product, is standard
DEC issue, called VAXmail.  While we have integrated into it as best
possible, through their foreign service interface, we do not touch the basic
vaxmail product.

We are thinking of offering a richer mail system for a number of platforms,
but that is mostly my way of trying to find an excuse to use some old
but fondly rememebered experiences.  

Another alternative, shortly, will be All-In-One.

Dave Crocker
The Wollongong Group

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 88 01:20:32 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Summary: TCP/IP and NFS for the Mac

This is a bit tangential an answer to the original question "Who has
NFS on MacOS?".  For small machines there are NFS implementations
available for both the IBM PC and Amiga.  Sun sells PC-NFS for the
IBM PC - package price is ~$900.  Ameristar Technology sells NFS
for the Amiga - package cost also $900.  Since part of my time
is spent at Ameristar, I'll allow myself the luxury of giving
their phone number: (516) 698-0834.  You probably already know
how to contact Sun anyways :-).

				Rick Spanbauer
				Ameristar Technology


PS. I would like to hear from anyone who has a Gator Box.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 88 01:48:29 GMT
From:      davidc@TERMINUS.UMD.EDU (David R. Conrad)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support


Add the University of Maryland to the list of Universities that use
bootp for PCs.  Our public workstation labs use it with RFC1048
extensions to provide information for the TCP/IP for the PC that we use
here.  We currently use a bootp server per subnet so we don't have to
worry about gateways forwarding requests although our bootp server
(based on CMU's with local additions) does have forwarding capabilities. 
We'd also be interested in having more vendors (particularly Proteon)
support bootp forwarding

-drc

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 88 07:53:00 GMT
From:      newton@ENH.NBS.GOV ("BARRY NEWTON")
To:        comp.protocols.tcp-ip
Subject:   Advertising

If everybody on the tcp-ip distribution list were to give the "Grand Poohbah"
one telephone call on his thoughtfully provided number, he might come to
a more clear understanding of the value and consideration involved in 
keeping crowded resources clear...

But don't do it.  It wouldn't be nice:-)

Barry

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 88 17:23:35 GMT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re:  x.25 as an internet backbone

> From lars@acc.arpa Sat Aug  6 09:35:15 1988
> Date: 5 Aug 88 20:29:51 GMT
> From: ozalp@cu-arpa.cs.cornell.edu  (Ozalp Babaoglu)
> Organization: Cornell Univ. CS Dept, Ithaca NY
> Subject: x.25 as an internet backbone
> To: tcp-ip@sri-nic.arpa
> 
> suppose a country (italy, to be precise) currently has a single
> internet site (in pisa) and has been registered as a top-level domain
> (domain .IT).  there are three class C type IP addresses
> allocated to the country.  what are some reasonable ways to structure
> subdomains in this country domain and incorporate LANs at other
> sites (cities) into the internet? the physical transport medium
> available is x.25 (both private and PDN run by the telephone company).
> 
> what is the technology of choice for ethernet-x.25 gateway hardware
> and the software to do the routing and encapsulation (of IP
> packets over x.25)?  any suggestions will be appreciated.
> 
> 	ozalp babaoglu

For each campus, assume an ethernet with its own network number.
(class C may be adequate for a while). For each of these, nominate
a router with an X.25 interface to be the gateway to the outside world.
Suitable routers include Ultrix with ACC's ACP5250, SUN with SUNLINK,
VMS with Wollongong TCP/IP and ACP5250, and many otehrs as well as
standalone router boxes. The router must run EGP, ROUTE-D or similar
gateway protocol to advertize reachability.

If the private X.25 network has a DNIC and can communicate with the public
data network, then you have one X.25 world, and all X.25 should use
one network number. If not, get a network number for the X.25 network.

Since X.25 has no ARP mechanism, all routers must share knowledge of IP
address to X.25 address mappings. This means a centralized management
of each X.25 IP network. CSNET does this on a commercial basis in
the US, and it would be to your advantage to join them so that
your PTT network is joined with the X.25 part of CSNET. However, I
don't know if their fee schedule makes this practical.

Another possibility is to declare your X.25 network to be its own
IP network, and have a single gateway to the outside (via CSNET or
AC.UK or via a private arrangement with a US site) but this means you
have to have fairly sophisticated traffic analysis in the gateway
in order to charge back the international X.25 charges to the member
institutions (since they all will be charged to the gateway).
I don't know of any router equipped to do this.

Let me know how you arfe involved with the evangelism in Italy,
and contact me if I can be of more help.

/ Lars Poulsen
  ACC Customer Service.

P.S.: No slight is intended of any product not mentioned above.
      I have nothing against CMU TCP/IP or Hewlett-Packard.
      SRI MultiNet is a fine product, and so is the ACS4020...
      products mentioned above are for examples only.
      My employer does not know I'm sending this ...
      is that enough disclaimers ?

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 88 04:59:14 GMT
From:      sm.unisys.com!csun!polyslo!steve@oberon.usc.edu  (Steve DeJarnett)
To:        tcp-ip@sri-nic.arpa
Subject:   nroff source for recent TCP/IP paper from Rutgers???

	I recently read the paper posted by Charles Hedrick from Rutgers, and
found it quite informative.  I was wondering if the source (nroff or TeX) was 
available.  It would be nice to have a printout that was more suitable for
reading than a normal printout.  I didn't save the author's email address, so
sorry for the posting.

	Thanks in advance,

-------------------------------------------------------------------------------
| Steve DeJarnett            | Smart Mailers -> steve@polyslo.CalPoly.EDU     |
| Computer Systems Lab       | Dumb Mailers  -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ.       |------------------------------------------------|
| San Luis Obispo, CA  93407 | BITNET = Because Idiots Type NETwork           |
-------------------------------------------------------------------------------
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 88 05:24:30 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP vendor support

> *Excerpts from ext.in.tcp-ip: 5-Aug-88 Re: BOOTP vendor support David R.*
> *Conrad@terminus (517)*
 
> We'd also be interested in having more vendors (particularly Proteon)
> support bootp forwarding

Hear Hear!  We find BOOTP very useful.  It's biggest problem though is that it
requires special support in gateways to forward requests across subnets.
Either that or a server for every subnet, which is a real pain since it is
often cost prohibitive.  As a campus support organization we can't afford to
put a server machine (or two for redundancy) on each net.  From my experience,
it takes less than 150 lines of code or so for a fairly robust gateway
forwarder implementation.  In case it helps anybody, here is most of the code
from our router implementation.  Everyone's router is different of course, so I
doubt if it will 'just slip in'.

Drew

/*
 * Bootstrap Protocol (BOOTP).  RFC 951.
 *
 * 07-Oct-86  Drew D. Perkins (ddp) at Carnegie-Mellon University
 *      Started history.
 *
 **********************************************************************
 */
 
#include "cond/bootp.h"

#if     C_BOOTP > 0

/*
 *  bp_input - process an incoming BOOTP server packet.
 *
 *  dv    = the device supplying the packet
 *  p     = the supplied BOOTP packet (with offset and length adjusted to
 *          remove any encapsulating headers/trailers)
 *  sport = the UDP source port of the sender of the datagram
 *  saddr = the datagram's IP source address
 *  daddr = the datagram's IP destination address
 *          (These will typically be pointers into the encapsulating IP
 *          header preceding the RCP packet - beware!)
 *
 *  The following consistency checks are performed on the BOOTP packet:
 *  - the physical length of the packet must be large enough to contain a
 *    minimal BOOTP header.
 *  If the packet is a boot request:
 *  - the packet must not have been through too many gateways.
 *  - the requestor must have waited a long enough time for service.
 *  If the packet checks out, the message is counted and processed
 *  according to the protocol.
 */

void bp_input(dv, p, sport, saddr, daddr)

  struct device      *dv;
  struct packet      *p;
         short        sport;
  struct socket p_pkt saddr;
  struct socket p_pkt daddr;

{
    register struct bootp p_pkt bp;
    register struct device *dvt;        /* determined target device of pkt */
    register struct ipmap *im;          /* IP routing table entry */
    register struct addmap *am;         /* ARP routing table entry */
    struct socket src, dest, tmp;       /* src and dest of outgoing IP pkt */
    short dport;                        /* destination UDP port */
    int flag = 0;                       /* Have seen incoming device flag */

    if (p->p_len < BOOTHEAD) {  /* Packet large enough? */
        profile(dv, bp_rmin);
        errorlog(p, EL_BP_RMIN);
        goto out;
    }

    bp = poff(bootp, p);
#ifdef BOOTPDEBUG
    if (p->p_flag&P_TRACE) {
        printf("BOOTP (%d):\r\n", p->p_len);
        bp_prt(bp);
    }
#endif  /* BOOTPDEBUG */

    switch(bp->bp_op) {         /* Check opcode */
        case BOOTREQUEST:
                                /* Only forward after some amount time */
            if (ntohs(bp->bp_secs) < BOOTMINSECS) {
                profile(dv, bp_rsecs);
                goto out;
            }
                                /* Prevent loops */
            if (bp->bp_hops++ > BOOTMAXHOPS) {
                profile(dv, bp_rhops);
                errorlog(p, EL_BP_RHOPS);
                goto out;
            }
            for (dvt=dv; flag == 0 || dvt != dv; dvt=dvt->dv_prnext[PR_IP]) {
                flag = 1;
                bcopy((char *)&dvt->dv_praddr[PRA_IP],(char *)&tmp, PRL_IP);
                if (bp->bp_giaddr.s_addr == tmp.s_addr) {
                    profile(dv, bp_rloop);
                    errorlog(p, EL_BP_RLOOP);
                    goto out;
                }
            }

            profile(dv, bp_reqcnt);

                                /* Fill in gateway field if empty */
            if (!bp->bp_giaddr.s_addr) {
                copout(&dv->dv_praddr[PRA_IP], (char p_pkt) &bp->bp_giaddr,
                                PRL_IP);
            } else {
                profile(dv, bp_rgway);
            }

            src.s_addr = bp->bp_giaddr.s_addr;
            dest.s_addr = daddr->s_addr;

                                /* Check out destination address */
            am = ar_map(PR_IP, (char p_pkt)daddr);
            if (am == 0 || !(am->am_flag&AM_BCAST)) {
                dest.s_addr = ipaddr(0xff, 0xff, 0xff, 0xff);
                profile(dv, bp_rbaddst);
            }

            dport = UD_BOOTPS;  /* Send to BOOTP Server */
            break;

        case BOOTREPLY:
            if (!bp->bp_yiaddr.s_addr) {
                profile(dv, bp_runkaddr);
                errorlog(p, EL_BP_RUNKADDR);
                goto out;
            }

            profile(dv, bp_repcnt);
            dest.s_addr = bp->bp_yiaddr.s_addr;
                                /* Set up arp cache */
            im = im_map(daddr, IM_ME);
                        /* If it isn't found then we got this by mistake */
            if (im == 0) {
                goto out;
            }
            dvt = im->im_dv;
            ar_remap(PR_IP,(char p_pkt)&dest,(char p_pkt)bp->bp_chaddr, dvt);
            src.s_addr = saddr->s_addr;
            dport = UD_BOOTPC;  /* Send to BOOTP client */
            break;

        default:
            profile(dv, bp_rbadop);
            errorlog(p, EL_BP_ROP);
            goto out;
    }

    ud_output(dv, p, sport, dport, (struct socket p_pkt) &dest,
                                        (struct socket p_pkt) &src);
    return;
out:
    (*(p->p_done))(p);
}


void bp_prt(bp)
register struct bootp p_pkt bp;
{
    char tempa[20],tempb[20],tempc[20],tempd[20];
    int i;

    printf("    op: %d, hops %d, id %ld, secs %d\r\n",
        bp->bp_op, bp->bp_hops, bp->bp_xid, bp->bp_secs);
    printf("    htype %d, hlen %d, chaddr ",
        bp->bp_htype, bp->bp_hlen);
    for (i = 0; i < bp->bp_hlen; i++)
        printf("%2x", bp->bp_chaddr[i]);
    printf("\r\n    ciaddr = %s, yiaddr = %s, siaddr = %s, giaddr = %s\r\n",
        ip_fmt(&bp->bp_ciaddr, tempa),
        ip_fmt(&bp->bp_yiaddr, tempb),
        ip_fmt(&bp->bp_siaddr, tempc),
        ip_fmt(&bp->bp_giaddr, tempd));
}
 #endif  /* C_BOOTP */

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1988 21:06-EDT
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        urbaniak@G.BBN.COM
Subject:   Ether types
per Torben Nielson's request. (that host not resolved from here.)

Some Known Ethernet and IEEE802.3 "Type" Fields		6/18/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
Some Known Ethernet Vendor Addresses		8/7/88

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme.

00000C	Cisco
00002A	TRW
00005A	S & Koch
000093	Proteon
00009F	Ameristar Technology
0000AA	Xerox		Xerox machines
0000C0	Western Digital
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
08007C	Vitalink	TransLAN III
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET
Some Known Ethernet Multicast Addresses		6/18/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-09-xx-xx-xx	????	HP multicasts
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-00-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 88 21:59:16 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Moderated Newsgroup Posting

It was clearly wrong of me to have elided an elision symbol after 
my quotation.  However, I rather resent being called "downright
dishonest."  Granted that Olsen clearly believes that the problem is
TCP/IP, not any incompetence of the Ultrix group, remember that he
sells a product -- Ultrix -- that includes support for networking.  It
would seem to me that the thrust of the quotation remains that Olsen is
not serious about delivering the TCP/IP based Ultrix networking that
DEC advertises.  Phrased differently, I believe it fair to conclude
that Olsen in fact has no confidence that his Ultrix group can deliver 
on DEC's marketing promises.

Another quotation out of context from the same source:  "VAX is VMS."

This discussion is rapidly shifting away from topics of interest to
the TCP-IP mailing list, and to ones more appropriate to INFO-VAX.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 88 23:02:44 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Ether types...

Would someone kindly mail me a copy of the current list of valid Ethernet
types. I know it's out there somewhere and I've seen it fly by every so often.
I'm sitting and looking at a dump of Ethernet packets and I'm seing a couple
of strange things. Trying to find out what the packets are.

Anyone happen to know if there're legitimate reasons for sending to yourself
onan Ethernet? That is, Ethernet packets where the source and the destination
address are identical? Seems pointless since as far as I know, you cannot read
packets you yourself transmitted off of the wire..... Am I wrong?

						Torben

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 01:06:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ether types

per Torben Nielson's request. (that host not resolved from here.)

 Some Known Ethernet and IEEE802.3 "Type" Fields		6/18/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
 Some Known Ethernet Vendor Addresses		8/7/88

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme.

00000C	Cisco
00002A	TRW
00005A	S & Koch
000093	Proteon
00009F	Ameristar Technology
0000AA	Xerox		Xerox machines
0000C0	Western Digital
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
08007C	Vitalink	TransLAN III
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET
 Some Known Ethernet Multicast Addresses		6/18/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-09-xx-xx-xx	????	HP multicasts
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-00-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 08:28:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE:  HP TCP/IP Conformance
One minor correction to Walter Underwood's note about gatewaying of
packets between the 802.3-based TCP for the HP3000 MPE/V and normal
Ethernet TCP/IP:

In addition to the other solutions available for relaying, Wollongong
offers a product called WIN/ROUTE2 for DOS.  It runs as a dedication DOS
application turning the PC into an IP router between HP3000s and ethernet
devices.  It does not talk PROBE, so that routes betweeen it and the
3000s need to be manually configured.

Performance of the device scales with the speed of the PC box.

Dave

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 11:02:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE:  Van's algorithms in Streams
To answer Van's query about my previous note:

We do not expect Berkeley code to port directly over to our Streams
implementation.  While it would be delightful if it did, the Streams
architecture lends itself to a substantially different implementation
style, although many of the routines can translate quite easily.  In the
good cases, this means that the left window on your screen shows BSD and
the right show the streams code, and you do fairly straightforward
translations.

The other piece of my comment was simply management-speak for saying that
we don't have any in-house experience with this software revolution wrought
by Van, et cie, so that we ought to gain some familiarity with its
dynamics before shipping it to customers (who have a fairly strong expectation
that we will support the code we ship.)  Given the history of Van's
changes to TCP code, I suspect that my m-speak was mostly a formality.

Dave

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon 8 Aug 88 15:20:55-PDT
From:      William Westfield <BILLW@MATHOM.CISCO.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Some ethernet controllers can hear themselves.
Some ethernet controllers are capable of hearing packets that they are
transmitting as they are being transmitted.  If this is true, then
sending a packet to yourself is a good way to check whether the
ethernet is in good shape - it checks the transceiver and the ethernet
cable as well as the controller.

Bill Westfield
cisco Systems.
-------
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 88 17:38:36 PDT
From:      croft@csli.Stanford.EDU (Bill Croft)
To:        tcp-ip@sri-nic.ARPA
Subject:   BOOTP 'vendors'
Although I havent been keeping close track, here is a partial list of
companies and organizations using BOOTP or offering it in their
products.  This also includes organizations that are evaluating it or
running it in-house in their R&D groups.  (Let me know if your name
isnt on the list).

Since client and server implementations are public domain and FTPable
from safe.stanford.edu, it is straightforward for a vendor to use
it in their products.  One of the next issues of ConneXions has an
overview article on BOOTP by Jeff Mogul of DEC's Western Research Lab.

Companies: 
	Cisco, FTP Software, DEC (server in next Ultrix release),
	Silicon Graphics, Kinetics (CMU ROMs), DCA, BBN, Data
	General, HP Labs, Spider Systems Ltd., Ciba-Geigy AG,
	Bellcore.

Universities: 
	Stanford, CMU, MIT, Rutgers, Rice, Boston U., U.  Maryland, U.
	Michigan, Harvard, Penn-State, Purdue, McMaster U., etc.
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 12:42:36 GMT
From:      rzahavi@GATEWAY.MITRE.ORG (Ron Zahavi)
To:        comp.protocols.tcp-ip
Subject:   Re: Enet + TCP/IP for Honeywell

>> 
>> Folks,
>> 
>> Does anyone know of a tcp/ip implementation for Honeywell systems and the
>> associated enet hardware?
>> 
>> Chris Markle - ACC
>> cam%columbia-pdn@acc-sb-unix.arpa


Honeywell has a tcp/ip implementation (FTP, SMTP, TELNET) for the DPS6 and DPS8
systems (I worked on the SMTP for both).  For more complete information on
various configurations, etc. you can contact Mr. Dana Crabil at (703) 827-3000.
 
  -- Ron --

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 88 16:56:17 EDT
From:      Root Boy Jim <rbj@nav.icst.nbs.gov>
To:        ico!dougm@handies.ucar.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
? From: ico!dougm@handies.ucar.edu  (Doug McCallum)

? You would have thought that AT&T would have understood the need of
? name servers and related tools that become an absolute necessity with
? large networks.

Why would you think that? Since when does TPC know anything about networks
except the phone system? Their solution would more likely be a special
purpose hardware box that dials 411 and communicates directly with the
synthesized voice that says `the number is...'.

?       			Doug McCallum
? 			Interactive Systems Corp.
? 			dougm@ico.isc.com

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	Careful with that VAX Eugene!
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon 8 Aug 88 17:11:40-EDT
From:      Jim Stevens <Stevens@A.ISI.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        Stevens@A.ISI.EDU
Subject:   VAX VMS 5.0 TELNET & FTP?

A colleague of mine who is not currently connected to the Internet asks
the following question:

  We are looking for a commercial version of FTP and TELNET that
  supports and runs within the auspices of VAX/VMS version 5.0 for our
  VAX 11/785 cluster.  

  We are getting ready to convert our VAX cluster over to version 5.0,
  and  have been advised that our EXCELAN version of FTP and TELNET are
  not currently supported under 5.0.  EXCELAN is currently working on a
  5.0 version, however it is not currently available. 

  If anyone has any data that can help us out, it would certainly be 
  appreciated.

Please respond directly to me.

Thanks,  Jim Stevens  (Stevens@A.ISISI.EDU)
-------
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 15:28:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   RE:  HP TCP/IP Conformance

One minor correction to Walter Underwood's note about gatewaying of
packets between the 802.3-based TCP for the HP3000 MPE/V and normal
Ethernet TCP/IP:

In addition to the other solutions available for relaying, Wollongong
offers a product called WIN/ROUTE2 for DOS.  It runs as a dedication DOS
application turning the PC into an IP router between HP3000s and ethernet
devices.  It does not talk PROBE, so that routes betweeen it and the
3000s need to be manually configured.

Performance of the device scales with the speed of the PC box.

Dave

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 88 20:35:39 cdt
From:      german%uxh.cso.uiuc.edu@uxc.cso.uiuc.edu (Gregory German)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: TCP/IP and NFS for the Mac
>>>This is a bit tangential an answer to the original question "Who has
>>>NFS on MacOS?".  For small machines there are NFS implementations
>>>available for both the IBM PC and Amiga.  Sun sells PC-NFS for the
>>>IBM PC - package price is ~$900.  Ameristar Technology sells NFS
>>>for the Amiga - package cost also $900.  Since part of my time
>>>is spent at Ameristar, I'll allow myself the luxury of giving
>>>their phone number: (516) 698-0834.  You probably already know
>>>how to contact Sun anyways :-).
>>>
>>>Rick Spanbauer
>>>Ameristar Technology

Here is a list of PC-NFS prices FYI.  I just thought I would point out the
$995 price for the PC included an ethernet card.

PC-NFS-56 Media: $325 (1-4 copies) - $175 (250+ copies)

PC-NFS-51 Media and Manual: $395 (1-4 copies) - $220 (250+ copies)

PC-NFS-3C-51 Media, Manual and Board: $995 (1-4 copies) - $645 (250+ copies)

You can get down to about $100/copy of the software with right to copy
options if you are heavy (500+) use.

I have not checked recently, but the board included was the 3COM 3C501
last time I checked.  (Sept. 1987)

         Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
Office:  181 Digital Computer Lab.
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 17:13:04 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: Van's algorithm's in Streams

> The header-predection performance code is scheduled for
> addition, shortly, although we are still trying to understand
> its impact under mixed traffic conditions.

Dave -

Are you working on header prediction in-house or is the above
management-speak for "Berkeley hasn't given us the code yet"?
(We haven't given it to anybody yet -- but "real soon now".)

We've been running the header prediction tcp for 3 months now
and the only "impact" I've observed is that things get faster --
under any traffic conditions.  That shouldn't be too surprising:
The "prediction" code adds about 6us of compares to the tcp
input processing.  If the prediction loses, you fall through to
the old input code (about 220us of processing, on the average).
If the prediction wins, you do about 25us of processing, on the
average.  For bidirectional dataflows (e.g., telnet, smtp, etc.)
the prediction wins slightly more than half the time (there are
counters in our implementation to measure this -- I was
surprised the hit rate was so high).  [On unidirectional flows,
the prediction wins all the time.]  So, the impact for, say, N
packets is:  old = N * 220;  new = N/2 * 226 + N/2 * 31.  I.e.,
you pick up about a factor of two on bidirectional traffic and a
factor of seven on unidirectional traffic.  (Times will vary --
these were on a Sun-3/60.  But the new/old ratios should stay
about the same on different architectures.)

Of course, I should point out again that the prediction didn't
make much difference in overall performance -- it just made a
small part of the work smaller.  Given halfway reasonable
protocols (as opposed to, say, the ISO protocols) and a half
decent implementation, protocol processing seems to be a small
fraction of the cost of networking.  So far, my data makes me
suspect that people working on hardware assists for protocol
processing are solving the wrong problem.

 - Van

ps- Just to ground the above timings in reality, here's our
    header prediction code from the 4bsd netinet/tcp_input.c.
    This code goes shortly after the pcb lookup (which is
    cached so it usually costs 3 32-bit compares).  Other
    than checksumming the packet & making sure the header
    length makes sense, this is the complete tcp input processing.

    /*
     * Header prediction: check for the two common cases
     * of a uni-directional data xfer.  If the packet has
     * no control flags, is in-sequence, the window didn't
     * change and we're not retransmitting, it's a
     * candidate.  If the length is zero and the ack moved
     * forward, we're the sender side of the xfer.  Just
     * free the data acked & wake any higher level process
     * that was blocked waiting for space.  If the length
     * is non-zero and the ack didn't move, we're the
     * receiver side.  If we're getting packets in-order
     * (the reassembly queue is empty), add the data to
     * the socket buffer and note that we need a delayed ack.
     */
    if (tp->t_state == TCPS_ESTABLISHED &&
	(tiflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK &&
	ti->ti_seq == tp->rcv_nxt && ti->ti_win == tp->snd_wnd &&
	tp->snd_nxt == tp->snd_max) {
	    if (ti->ti_len == 0) {
		    if (SEQ_GT(ti->ti_ack, tp->snd_una) &&
			SEQ_LEQ(ti->ti_ack, tp->snd_max) &&
			tp->snd_cwnd >= tp->snd_wnd) {
			    /*
			     * this is a pure ack for outstanding data
			     * and we're not in the middle of slow-start
			     * or congestion avoidance.
			     */
			    ++tcppredack;
			    if (tp->t_rtt && SEQ_GT(ti->ti_ack,tp->t_rtseq))
				    tcp_xmit_timer (tp);
			    sbdrop (&so->so_snd, ti->ti_ack - tp->snd_una);
			    tp->snd_una = ti->ti_ack;
			    m_freem (m);
			    /*
			     * If all outstanding data is acked, stop the
			     * retransmit timer.  If there's no one
			     * waiting to output, let tcp_output decide
			     * between more output or persist.  Otherwise
			     * give the user a crack at the new space,
			     * assuming he'll call tcp_output when it's
			     * filled.  If there is more data to be acked,
			     * restart retransmit timer, using current
			     * (possibly backed-off) value.
			     */
			    if (tp->snd_una == tp->snd_max)
				    tp->t_timer[TCPT_REXMT] = 0;
			    else if (tp->t_timer[TCPT_PERSIST] == 0)
				    tp->t_timer[TCPT_REXMT] = tp->t_rxtcur;

			    if ((so->so_snd.sb_flags & SB_WAIT) ||
				so->so_snd.sb_sel)
				    sowwakeup(so);
			    else if (so->so_snd.sb_cc)
				    (void) tcp_output (tp);
			    return;
		    }
	    }
	    else if (ti->ti_ack == tp->snd_una &&
		     tp->seg_next == (struct tcpiphdr *)tp &&
		     ti->ti_len <= sbspace(&so->so_rcv)) {
		    /*
		     * this is a pure, in-sequence data packet
		     * with nothing on the reassembly queue and
		     * we have enough buffer space to take it.
		     */
		    ++tcppreddat;
		    tp->rcv_nxt += ti->ti_len;
		    /*
		     * Drop TCP and IP headers then add data
		     * to socket buffer
		     */
		    m->m_off += sizeof(struct tcpiphdr);
		    m->m_len -= sizeof(struct tcpiphdr);
		    sbappend(&so->so_rcv, m);
		    sorwakeup(so);
		    tp->t_flags |= TF_DELACK;
		    return;
	    }
    }

    /*
     * Prediction failed:  do things one step at a time.
     ...

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 18:02:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   RE:  Van's algorithms in Streams

To answer Van's query about my previous note:

We do not expect Berkeley code to port directly over to our Streams
implementation.  While it would be delightful if it did, the Streams
architecture lends itself to a substantially different implementation
style, although many of the routines can translate quite easily.  In the
good cases, this means that the left window on your screen shows BSD and
the right show the streams code, and you do fairly straightforward
translations.

The other piece of my comment was simply management-speak for saying that
we don't have any in-house experience with this software revolution wrought
by Van, et cie, so that we ought to gain some familiarity with its
dynamics before shipping it to customers (who have a fairly strong expectation
that we will support the code we ship.)  Given the history of Van's
changes to TCP code, I suspect that my m-speak was mostly a formality.

Dave

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 20:09:00 GMT
From:      falken@caen.engin.umich.edu (David R  Falkenburg)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Summary: TCP/IP and NFS for the Mac

In article <944@srs.UUCP>, dan@srs.UUCP (Dan Kegel) writes:
> 3. University of Michgan had a client version of NFS for the Mac at last 
>    years Sun Connectathon.  Don't think they ever fielded it.
> 
> 4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project 
>    that put tcp/ip and NFS on Macs, under contract to Apple.
>    Apple has the software now; it's unclear when if ever they will release it.

Here at university of michigan, we had been using (testing, etc.) the
CITI MacNFS.  Both 3 & 4 were the same project--  Honeyman was project
manager for both MacIP and MacNFS.

both products are now in apple's hands.

ALSO

didn't anybody mention CAP (specifically AUFS)?

it allows the unix box to act as an appleshare file server
with the advent of System 6.0's inclusion of AppleShare Client
this is a mostly free (with the exception of the kbox) alternative
to systems like tops.

-dave falkenburg
 university of michigan computer aided engineering network
 falken@caen.umich.edu
 umix!caen.engin.umich.edu!falken

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Aug 88 01:42:31 EDT
From:      Peter DiCamillo <CMSMAINT%BROWNVM.BITNET@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Release of Brown University's tn3270 for the Macintosh
Please forgive the posting of this announcement to several relevant
distribution lists.

The first release of Brown University's tn3270 for the Macintosh is now
available.  This program consists of the NCSA TCP/IP kernel by Tim
Krauskopf and Gaige B. Paulsen, Telnet 3270 option negotiation code
developed by Greg Minshall at Berkeley, and 3270 emulation and Macintosh
user interface code developed at Brown.  It allows a Macintosh with a
TCP/IP connection to access a host as a full-featured 3270 terminal.
tn3270 is available via Internet anonymous FTP, over BITNET, or from
Brown for a small distribution fee.  Details of tn3270's features and
availability are provided below.

NETWORK FEATURES

tn3270 includes all the features of version 2.0 of the NCSA TCP/IP
kernel.  These include support for both Ethernet connections and
LocalTalk connections via a Kinetics gateway, a built-in FTP server,
and domain nameserver support. Also, tn3270 supports dynamic IP number
assignment when a Kinetics gateway is running KIP code, and allows the
user to override the default Telnet terminal type and port number.

EMULATION FEATURES

On all Macintoshes, tn3270 emulates a 3278 with extended highlighting,
APL, and the APL/Text character set.  In addition, most graphics
capabilities of a 3179 G or PC/GX are emulated.  tn3270 also supports
several 3270 enhancements, including typeahead and special blank
processing.

On a Macintosh II (or other Macintosh with color Quickdraw) tn3270
supports 3279 base color, four color, and eight color text, and eight
color 3179 graphics.  On Macintoshes with large screens, tn3270 supports
either 9 or 12-point text for 24 lines, and 32 lines using 9-point text.

Although primarily a 3270 emulation program, tn3270 also provides basic
line mode Telnet support, and emulates a VT-52 terminal.

MACINTOSH FEATURES

tn3270 allows the 3270 cursor to be moved with a single mouse click, and
allows the user to set the function of a double mouse click.  Full
MultiFinder support is provided, and on color Macintoshes the standard
color picker may be used to set any screen colors.  tn3270 utilizes
offscreen bitmaps for fast, flicker-free screen refreshing.  The speed
of tn3270 can approach that of a locally-connected 3270, with updates
as fast as two screens per second.

SPECIAL FEATURES

In addition to FTP server support, special support is provided for
VM/CMS file transfer.  Easy-to-use CMS RMAC and WMAC commands may be
used to upload and download files during a CMS terminal session
through the Telnet connection.  Data transfer rates can be as high as
10K bytes/second.

Brown also distributes an asynchronous terminal program, Term, which
provides a user interface nearly the same as tn3270's when used with an
IBM 7171.  The combination of Term and tn3270 provides users with a
consistent terminal interface, whether they have a high-speed network
connection or a modem connection.  The same CMS RMAC and WMAC commands
also work with Term.

HOW TO OBTAIN TN3270

Brown encourages tn3270 to be freely distributed, provided the program
is not modified and the copyright notices are retained. tn3270 can be
obtained in any of the following ways:

Anonymous FTP from BROWNVM.BROWN.EDU (128.148.128.40):
    The distribution files are in the highest level directory.  Begin
    by retrieving the file $READ-ME.FIRST which describes the other
    files.

Anonymous FTP from NCSA (128.174.20.50):
    The distribution files are the contents of the directory
    NCSA_Telnet/tn3270.

BITNET distribution from LISTSERV@BROWNVM.BITNET:
    Request the distribution files by sending LISTSERV the command
    "get tn3270 package".  This command may be sent as a message
    over BITNET, or as the first line of text in standard RFC 822
    formatted mail. Other packages available are "tn3270xf" for the CMS
    file transfer programs, and "term" for the Term program.  Issue the
    command "get local filelist" for a complete list of available
    files.

Mail order from Brown:
    Starting on September 1, Brown will accept mail orders for copies
    of the tn3270 disk and documentation.  To place an order, send a
    check payable to Brown University for $20 to:
        tn3270 Distribution
        Brown University Computer Store
        P.O. Box 1885
        Providence, RI 02912
    (Orders from Rhode Island must include 6% sales tax.)

KEEPING UP-TO-DATE

The NCSA Telnet Digest will be used for discussing issues related to
tn3270, as well as NCSA Telnet.  To subscribe to the digest, send a
request to telnet-request@ncsa.uiuc.edu.

SOURCE AVAILABILITY

tn3270 source is written for Manx Aztec C, using the MPW-compatible
library and include files.  Brown intends to distribute the source in
the near future.  An announcement of source availability will be made
in the NCSA Telnet Digest mentioned above.

Peter DiCamillo
BITNET:    CMSMAINT@BROWNVM
Internet:  CMSMAINT%BROWNVM.BITNET@MITVMA.MIT.EDU
U.S. Mail: Computing and Information Services, Brown University,
           P.O. Box 1885, Providence, RI 02912
Phone:     (401) 863-7582
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 88 21:49:49 GMT
From:      nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ")
To:        comp.protocols.tcp-ip
Subject:   modification to arp

of course I am shure many other people thought of it, perhaps I missed
it, so I shall dare to speak it out (got my asbestos overall):

Why not resolve the problem of a dead hosts's ARP entries at least for orderly
downed hosts by a FLUSH function code ARP packet.  

A host that would receive such a packet ( broadcasted for all or for local
subnet) should compare the ARP contents with the originating address, and
then flush the corresponding routing table entry or flag it down. This 
mechanism could be added to avoid timer rundowns. By the way I like that
timer concept.

An orderly downed host could broadcast that packet prior to it's halt,
and I think most operating systems (or, challenge for interface
designers, interface software could do that in a blip of last power in
case of power off) even could signal their bye from the net in panic state
or whatever the operating system has as last code (dump code) running
prior to a real crash. Most micros sense the power line for power up
and generate a power fail signal.

And: if this additional packet is created, it would not rule out
present implementations using ARP since they should ignore an invalid
packet (which is no REQUEST or other known type). Some call that upwards
compatibility.
                                                          
Comments, flames, shootings???



And of course, this is my personal stuff.





Michael
 

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 88 03:31:36 GMT
From:      nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ")
To:        comp.protocols.tcp-ip
Subject:   some interim notes on the bsd network speedups

Bravo! This is what I would call REAL speedups;
 
as I understand the result, there is now a Sun 3/60 under SunOS4
with 750kB/s transfer rate and 1.25MB forwarding capacity.
                                               
I do in no way discredit this work by furnishing some remarks to
the mail article and I do not want anybody to do tricky quoting
or implying negative contents. A good artist always merits some
critics, not only thumb handclapping with the crowd.

One remark to the 50% cpu load on forwarding: I guess that is the
fact that the ethernet is at it's capacity limit and so the interface
imposes cpu idle cycles on the transfer activities.

One remark on loop unrolling: a sun is a pipelined processor machine
BUT the compiler seems not to provide for memory prefetches nor for 
optimized loop structures. Only in this context an unrolling of scalar
loops on a single processor machine can have results.

One remark on "overhead" : if you have a slow scalar performing machine
with some simple compiler that does not know about advantageous
memory fetch instruction placing, the loop overhead seems to be
small with respect to the instruction completion times within the
loop. But this is not small loop overhead!

A remark to the broken Cray's: it is absolutely true that on a fast
machine with sophisticated instruction buffering, with compilers
that take full advantage of memory "oddities" and with multiple 
parallel working functional units per processor the overhead of
the return to the first instruction of a loop becomes prohibitive 
if the next instruction lies out of memory sequences and out of 
instruction buffers and the like. But the overhead is only big relatively
to the instruction time spent within the loop which is already smaller
than the sum of the executed instructions which seems not to be true
in the case of the Sun. ( I intentionally left vectorization apart since
this does not exist on the Sun)  

So Your school is perfectly right - for Your choosen combination of
software (compiler, virtual memory, processor architecture ... ) and 
hardware. 
And that's it!

The fact that just 1kB segments seem to be the optimum copy size 
seems to me more a Sun specific sort of resonance effect between 
memory transfers, virtual memory managing and interface readyness
ON THE LOCAL MACHINE. 

As a physicist I learned to look very critically at experiments and their
setups and I like to point out that Your performance test between two
I guess equally optimized Suns certainly shows Your great competence
on the field and the very true betterments Your code changes brought to
the Sun OS4. But the experiment strictly only holds for Your configuration
of two machines that operate at their - equal !!! - optimum configuration
of packet munching parameters. This is sort of a formula I race. 

In a network You have to deal with what You call "broken" partners.
They also work at least close to their respective optimum parameter
configuration - resp. they would like to. Isn't it sort of a racism
to declare that broken?

And in a network You have to deal with the network medium itself.
And no doubt: the bigger the chunks are, the better the network throughput
is. Yes, I know that this is true for the monochromatic case of all equal
packet lengths, but packet size distribution primarily causes disadvantages for
the individual transfer ( small packet waiting for big one to pass).
Now, if You operate a machine that's interface can deliver 100MB but the
fastest channel You have will only gulp 10MB or 50MB (Ether, NSC Hyper),
from the point of writing networking code on such a fast machine You have
an interest to flood the net with a big packet and then continue with
the honest work of letting users use the CPU until the 4MB Working station
eventually may accept another packet. And even under these  circumstances
the networking software has to be as fast as possible to waste as little
resources and cpu cycles as possible since Your CPU does not earn money
by servicing 100MB interfaces with a some GB badnwidth CPU nor by pushing 
around small memory segments but by giving CPU cycles to users' number	 
crunching codes.
(this is a hit on the people that think " oh, the link is only xxxkB/s,
why bother writing a code that could serve yyMB/s").
So on my opinion there are more viewpoints to observe than the 
record breaking perspective in clinical and artificial environment. 






disclaimers as usual (sometimes I have bad conscience because somebody pays
NW costs for my private ognions)
                                                      




Michael.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 88 17:23:47 PDT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        tcp-ip@sri-nic.arpa
Subject:   PSERV - a sample TCP/IP client/server pair
PSERV - a sample piece of functional TCP/IP Berkeley socket programming.

Every so often, programmers new to socket programming ask for working
examples. I will give you this small example to play with.

This program is a minimal remote spooling package, intended to solve
a personal problem: I use every day two VMS systems and a Unix system.
In my work area we have a LaserWriter connected to the Unix system,
but I have to ride a sloooow elevator two floors to get to a VMS printer.

I really wanted to write a small "lpd" client, but found that this
would require the cooperation of system managers on both machines, since
(1) LPD will only accept commands from known hosts
(2) LPD will only accept connections from privileged ports (<1024)
    and the Wollongong VMS package enforces this also; you need
    system privileges to get a low-numbered port on WIN/TCP.

So I decided to write my own mini protocol. This program illustrates
the basic mechanism used by any server/client pair, and is small enough
to dink around with fairly safely. [After all, if the system lets an
unprivileged user do it, it must be safe :-) ?]

The client runs un 4.3BSD or VMS/WIN/TCP; the server runs on 4.3BSD.

Enjoy.

	/ Lars Poulsen
	  ACC Customer Service
--------------------------------- Cut Here --------------------------------
In order not to clutter up TCP-IP unnecessarily (God knows I've done that
enough recently) I've sent the actual source code to UNIX-SOURCES on
BRL-SMOKE.ARPA. This is a relay for comp.sources; I don't know if it is
two-way, so if anyone on the Usenet side needs it, I guess I can mail it.

/ Lars Poulsen
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 88 15:42:24 GMT
From:      amdahl!ems!quest!cnt!rod@ames.arc.nasa.gov  (rod merry)
To:        tcp-ip@sri-nic.arpa
Subject:   IBM VM TCP/IP?
I am interested in the channel protocol which IBM uses for their
VM TCP/IP to 8232 product.  If you have experience with the
source code or are aware of documentation from IBM please
respond via email or phone.

Thanks in advance.
rod  (612-535-8111)
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 88 17:07:07 GMT
From:      aeras!bud!kwang@sun.com  (Kwang Sung)
To:        tcp-ip@sri-nic.arpa
Subject:   Difference between the various STREAM implementations.
I hope someone on the net can answer to my interesting question.

I would like know "what is the significant difference between the following
various products in according to AT&T STREAMS Functional Specification ?".

1. The Wollongong STREAM implementation.
2. The Convergent STREAM implementation. ( ~ Lachman's STREAM product)
3. The Mitre STREAM implementation. ( ~ Unisoft's STREAM product)
4. CMC, EXCELAN STREAM implementation.
5. Or, any other STREAM implementation, if you can think.

Kwang Sung
Sr. Software Engineer,
ARIX Corp.
UUCP: ...!sun!aeras!smaug!kwang
UUCP: ...!sun!aeras!bud!kwang
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 88 17:44:51 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ether types...

In article <88Aug7.130257hst.4295@dorsai.ics.hawaii.edu> torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") writes:
>Anyone happen to know if there're legitimate reasons for sending to yourself
>onan Ethernet? That is, Ethernet packets where the source and the destination
>address are identical? Seems pointless since as far as I know, you cannot read
>packets you yourself transmitted off of the wire..... Am I wrong?

Whether you can hear yourself send is very much dependent on your Ethernet
controller.  Some can, some can't.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 88 18:12:00 GMT
From:      necntc!primerd!ENI!S39!E.TATE@ames.arc.nasa.gov
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: TCP/IP and NFS for the Mac

/* Written 11:16 pm  Aug  8, 1988 by falken@caen.engin.umich.edu in S39:comp.protocols.tcp-ip */
In article <944@srs.UUCP>, dan@srs.UUCP (Dan Kegel) writes:
> 3. University of Michgan had a client version of NFS for the Mac at last 
>    years Sun Connectathon.  Don't think they ever fielded it.
> 
> 4. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project 
>    that put tcp/ip and NFS on Macs, under contract to Apple.
>    Apple has the software now; it's unclear when if ever they will release it.

Here at university of michigan, we had been using (testing, etc.) the
CITI MacNFS.  Both 3 & 4 were the same project--  Honeyman was project
manager for both MacIP and MacNFS.

both products are now in apple's hands.

ALSO

didn't anybody mention CAP (specifically AUFS)?

it allows the unix box to act as an appleshare file server
with the advent of System 6.0's inclusion of AppleShare Client
this is a mostly free (with the exception of the kbox) alternative
to systems like tops.

-dave falkenburg
 university of michigan computer aided engineering network
 falken@caen.umich.edu
 umix!caen.engin.umich.edu!falken
/* End of text from S39:comp.protocols.tcp-ip */
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 88 23:46:37 GMT
From:      root@sbcs.sunysb.edu  (root)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: TCP/IP and NFS for the Mac
In article <8808090135.AA27359@uxh.cso.uiuc.edu>, german@UXH.CSO.UIUC.EDU (Gregory German) writes:
> Here is a list of PC-NFS prices FYI.  I just thought I would point out the
> $995 price for the PC included an ethernet card.
> PC-NFS-3C-51 Media, Manual and Board: $995 (1-4 copies) - $645 (250+ copies)
> 
	Yes, and $900 buys you NFS client, telnet, ftp and a Lance
	based shared memory Ethernet card for the Amiga.

	If you want to buy 250+ copies of AmigaNFS, I'm sure Ameristar
	will happily beat the $645 price too :-).

> You can get down to about $100/copy of the software with right to copy
> options if you are heavy (500+) use.
> 
> I have not checked recently, but the board included was the 3COM 3C501
> last time I checked.  (Sept. 1987)
> 
>          Greg German (german@uxc.CSO.UIUC.EDU) (217-333-8293)
> US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801
> Office:  181 Digital Computer Lab.

Sorry this turned somewhat commercial.  This original posting was meant
to be informational.

					Rick Spanbauer
					Ameristar Technology
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 88 00:45:17 GMT
From:      booloo@lll-lcc.llnl.gov  (Mark Boolootian)
To:        tcp-ip@sri-nic.arpa
Subject:   info on ftp
--
  I am in need of some information and am hoping to obtain a few pointers from
a few kindly souls.  I'm a neophyte in this realm (networking) so please bare
with me.
  We are in the process of trying to gateway a net implemented with TCP/IP to
another net that is of our own design.  The gateway will be provided by a
VAX.  I have been given the task of modifying the ftp server to speak our own
homegrown protocol, thus creating what seems to me to be an "ftp gateway."
  I don't want to even begin to fumble around with my ideas of what is involved
as my thoughts aren't very clear at this moment (nor at any other, for that 
matter).  What I'm hoping is that some of you might steer me in a direction
where I can read about ftp (and the ftp server) and get some practical 
knowledge about what all is involved here.  Sorry if this seems open-ended
and vague but that is currently where where my head resides.

  Please E-Mail replies and don't post to the net.  I'm a long ways behind on
reading this newgroup and I might never find the reply.  Thanks in advance for
any help.

  mb
--

-- 
uucp:  {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa:  booloo@lll-lcc.arpa
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 88 09:46:05 -0500
From:      Gurudatta Parulkar <guru@flora.wustl.edu>
To:        tcp-ip@sri-nic.arpa
Cc:        "Dave Clark"<ddc@xx.lcs.mit.edu>, lixia@flora.wustl.edu, cheriton@pescadero.stanford.edu
Subject:   Comments on Proposed Transport Protocols

We just completed a DRAFT of a technical report with the abstract
enclosed. If you would like a copy to review, please send me a note.
I want to mention that this report does not contain any quantitative
analysis, and has only qualitative reasoning to support the claims.

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
St. Louis MO 63130 
(314) 889-4621
-------------------------------------------------------------------------
				   
	       Comments on Proposed Transport Protocols

			     Anil Bhatia
			    James Sterbenz
			    Guru Parulkar
			 guru@flora.wustl.edu

	      Computer and Communication Research Center
		    Department of Computer Science
			Washington University
			  St. Louis MO 63130
				   
			       Abstract


Over the last few years, a number of research groups have made
considerable progress on the design of high speed networks -- on the
order of a few hundred Mbps to a few Gbps. The emphasis of this work
has been on the design of packet switches and on the design of network
access protocols. However, this work has not yet addressed the
internetworking and transport level issues in a high speed internet.

The ARPA Internet, which has contributed a number of fundamental ideas
to the field of internetworking of diverse networks, cannot be used in
its current form as a model for the very high speed internetworks
(VHSI) of the future.In this report, we propose a revised internet
model, called the VHSI model, which among other things, argues for a
number of application-oriented lightweight transport protocols
(ALTPs). As part of our effort on the design of a VHSI model, we
considered the appropriateness of recently proposed transport
protocols, NETBLT and VMTP, as ALTP candidates. The purpose of this
report is to present the results of this study, and present our
thoughts on the design of ALTPs.

The summary of the results of this study is that NETBLT and VMTP have
contributed a number of interesting ideas to the design of transport
protocols, and they do improve upon TCP within the current Internet
model for the applications they were originally designed for.
However, we believe that these protocols are not appropriate solutions
for the VHSI model, because the underlying assumptions and trade-offs
that these protocols are based on are very different in the VHSI
model. For example, the VHSI model assumes a {\em quasi-reliable}
connection-oriented internet protocol (as opposed to the current
unreliable datagram IP), which can make performance guarantees and can
ensure that the internet is congestion free (almost all the time).
Also, the network speeds in the VHSI are a few order of magnitude more
than what NETBLT and VMTP assume. We argue that the transport
protocols in the VHSI model should avoid end-to-end flow control as
much as possible, and make the end-to-end error control application
specific and indepedent of the end-to-end latency. In general, the
transport protocols should be simpler, designed to be mostly
implemented in VLSI, well integrated with the host architecture and
operating system, and targetted for a specific class of applications.

The rest of this report is organized as follows: Section 2 provides an
overview of the ARPA Internet model and the VHSI model. It also gives
an overview of TCP and its associated problems. Section 3 provides an
overview of NETBLT and VMTP and summarizes how these protocols are
improvements over TCP.  Section 4 describes the limitations of NETBLT
and VMTP within the VHSI model. Section 5 presents our thoughts on the
design of ALTP protocols for VHSI, and finally, Section 6 is the
conclusion.


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 88 09:22:01 EDT
From:      Barry Shein <bzs%bu-cs.bu.edu%bu-it.bu.edu%ntt-sh.ntt.jp@RELAY.CS.NET>
To:        MURAKAMI%ntt-20.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET
Cc:        tcp-ip%sri-nic.arpa%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, Crispin%sumex-aim.stanford.edu%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, george%iguanodon.cis.ohio-state.edu%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, nowicki%sun.com%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, celeste%coherent.com%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, earle%mahendo.Jpl.Nasa.Gov%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET, he%idt.unit.no%relay.cs.net%nuesun.ntt.jp%RELAY.CS.NET%ntt.jp@RELAY.CS.NET
Subject:   Summary: Proxy ARP on SUN

(quite a CC: list, oh well.)

Here's the deal:

I wrote a proxy arp based upon Sun's rarpd server which has been in
production here at BU for over a year. The mainline is definitely
Sun's but I call out to a bunch of routines which I wrote and put in a
separate file, mainly the logic like "does this packet need a proxy
rarp?" and the formatting of the reply and read-in of a table of
networks to do Proxy arp for.

So I've distributed it only as the .o (binary) of Sun's stuff and my
added sources for relinking with a makefile and manual page.

Some folks reported problems, the bit shift thing can be easily fixed
but the "unaligned read" is a little mysterious (gee, works here,
same machine, same OS, I'll have a look.)

I don't believe any of this will work under Sun O.S. 4.0 (at least one
try to recompile indicated some things had changed and 4.0 sources
might be needed to make it work again.)

So it's a little shaky at best, got me thru the night.

Some of my tardiness in replying to people is explained by the fact
that I am currently changing jobs and just haven't been around, I'm
catching up (gee, these net requestors are harsh taskmasters!)

The good news is this:

A) I'll put what I have up for anonymous FTP soon, anyone that has
a copy of my stuff should of course feel free to redistribute as
stated above, binary of the mainline etc., as I distributed it.

B) Haavard Eidnes claims to have completely written a new Proxyd from
scratch based on my basic design (not the Sun sources) and I assume
will make all sources available. He recently asked if he could just
re-work the manual page I distributed and of course I said yes
(Haavard: if you still haven't gotten my permission here it is again,
if I didn't want people using my stuff I wouldn't give it out!)

SOOOOOO...

You should probably wait for B) to become available and that will
solve all sorts of problems. My Proxyd kind of got out there by
accident when someone mentioned I had given them a copy on one of the
major lists. I knew it was a bit kinky and never really intended it
for wide distribution nor thought all the problems could be worked out
w/o a complete re-write due to its being based on the Sun rarpd (tho
it was a good idea at the time, it was up in an hour or two.)

And, of course, you might also consider Sun's product.

Also, as I understand it you can get some limited amount of proxy
arping by just sticking published arptab entries in with /etc/arp
under SunOS or 4.3 (and probably others.) That's a limited hack as
it's per-host rather than per-network so either you need large tables
or small networks, but I thought I'd mention it.

	-Barry Shein


-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed 10 Aug 88 10:22:44
From:      ken-ichiro murakami <MURAKAMI%ntt-20.ntt.jp@RELAY.CS.NET>
To:        tcp-ip%sri-nic.arpa%nuesun.ntt.jp@RELAY.CS.NET
Cc:        Crispin%sumex-aim.stanford.edu%nuesun.ntt.jp@RELAY.CS.NET, george%iguanodon.cis.ohio-state.edu%nuesun.ntt.jp@RELAY.CS.NET, nowicki%sun.com%nuesun.ntt.jp@RELAY.CS.NET, celeste%coherent.com%nuesun.ntt.jp@RELAY.CS.NET, earle%mahendo.Jpl.Nasa.Gov%nuesun.ntt.jp@RELAY.CS.NET, he%idt.unit.no%relay.cs.net%nuesun.ntt.jp@RELAY.CS.NET
Subject:   Summary: Proxy ARP on SUN

I recently asked Mark<Crispin@sumex-aim.stanford.edu> for info about
Proxy ARP on SUN. He kindly forwarded to TCP-IP mailing-list, and I
received many helpful responses. I modified and summarized these
responses. Mark, George, Bill, Celeste, Greg and Haavard, thank you
very much for your help. I hope this summary also helps other net
people. 

(1) Barry Shein<bzs@bu-cs.bu.edu>'s proxy ARP daemon

> From: "George M. Jones" <george@iguanodon.cis.ohio-state.edu>

> I have Sun 3 (or possibly 4) binary and man page for Barry Shein's
> proxy arp daemon, but you will have to contact him directly about
> source. 

(2) "consulting special product" from Sun

> From: Bill Nowicki <nowicki@sun.com>
> From: "Celeste C. Stokely" <celeste@coherent.com>
> From: Greg Earle <earle@mahendo.Jpl.Nasa.Gov>

> Proxy ARP is available as a "consulting special product" from Sun
> Software Support. If you are in the USA, you can call
> 1-800-USA-4-SUN and request it. If you are not in the USA, you can
> probably get it from the technical support people in your Sun sales
> office. 
> The author, David Robinson, has made it available for anonymous FTP
> from elroy.JPL.NASA.GOV as well as (I believe) the ~ftp/pub
> directory on uunet.UU.NET. I should warn you that Sun's code is
> basically David's, with perhaps minor modifications. Note that the
> code is for SunOS 3.4 or SunOS 3.5.  There is no support for SunOS
> 4.0 as of yet. 

(3) From: Haavard Eidnes IDT <he%idt.unit.no@relay.cs.net>

> I just happen to have written such a program. It will run on SunOS
> 3.3, 3.4 and 3.5 -- the SunOS 4.0 code for using NIT is different, and
> I haven't got any SunOS 4.0 machines here yet.
> I tried out Barry Shein <bzs@bu-cs.bu.edu>'s program, proxyd, but
> could not make Barry's proxyd work for me. It stopped with the
> error message "badly aligned read" after a small number of packets
> (when started with the '-d' option, at least). Besides, Barry's
> program is only partly delivered in source form, and a comment in
> there seemed to indicate that it was specific for class B subnetted
> hosts. Also, there was a shift in there somewhere (>>8) that should
> not be there -- I reported it to Barry, but got the usual silence...

> As my program stands now, it has a couple of mis-features that I
> intend to weed out before I let the net have it (I intend to
> distribute it freely). I have not yet created a man page for my
> program -- I thought of using Barry Shein's ,and asked him for
> permission. He hasn't responded yet.
> I intend also to complete the distribution with a README file before
> I let it loose on the net. 

> Sorry, no documentation yet, but you can largely use Barry's man
> page, except that you can't have comments anywhere on a line of the 
> /etc/proxytab file, only in the first column.
> Good luck! Please report back to me if you find bugs or implement
> enhancements (diff -c2 is preferred for updates/changes).





Again, thank you very much for your help.

--Ken

	Ken-ichiro Murakami
	NTT Laboratories
	Tokyo, Japan
-------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 88 17:58:06 PDT
From:      braden@venera.isi.edu
To:        dzoey@terminus.umd.edu
Cc:        braden@venera.isi.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  FTP questions.
	
	
	I have some questions about FTP.  Why is there an EOR indication in the
	descriptor code for block mode? If you are sending record oriented data
	then you are presumably using a record structure which already defines
	its EOR indication.  

Joe, 

Huh? If you are sending record-oriented data, then the FTP EOR indication
marks the end of each record.  The record structure is not assumed to be
somehow encoded into the data, but is made explicit... so another system
that also has record structure, but encodes it differently, can handle
the data.

    If you are not sending record oriented data then
	why do you need to determine EOR? 
	
You don't.  You don't have to set the EOR bit if it is inappropriate.
That's the nice thing about bits, they can be on or off.

    Is it correct to duplicate the EOR
	information if you are using a record structure in block mode?
	
No. See above. 
	
	Does the EOR in block mode indicate that at most one record per block
	may be sent?  
	
Yes.

	I like the fact that you don't need to close the data connection when
	transfering in block or compressed mode since there is an EOF indication.
	When using page or record structures in stream mode, it is possible to detect
	EOF (since it is part of the descriptor info) even though the mode
	is stream.  Why is it necessary to close the data connection even though
	EOF is indicated in the structure.  
	
It isn't necessary. Section 3.2 discusses at some length when the connection
has to be closed. For block mode, it is the server's option.
	
	P.S.  Does anyone know of any machine I can test block mode and record
	      structure against?  IBM VM/TCP will do block mode but only
	      stream structure and 2.4 Ultrix does neither...
	
Try any of the OS/MVS systems derived from the UCLA ACP.

Bob Braden
	
	
	
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 88 17:19:18 EDT
From:      dzoey@terminus.UMD.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   FTP questions.

I have some questions about FTP.  Why is there an EOR indication in the
descriptor code for block mode? If you are sending record oriented data
then you are presumably using a record structure which already defines
its EOR indication.  If you are not sending record oriented data then
why do you need to determine EOR? Is it correct to duplicate the EOR
information if you are using a record structure in block mode? This
seems to be so, but I'm seeking reassurance.   

Does the EOR in block mode indicate that at most one record per block
may be sent?  

I like the fact that you don't need to close the data connection when
transfering in block or compressed mode since there is an EOF indication.
When using page or record structures in stream mode, it is possible to detect
EOF (since it is part of the descriptor info) even though the mode
is stream.  Why is it necessary to close the data connection even though
EOF is indicated in the structure.  

I have the nagging feeling that I'm missing something basic, like EOF
descriptors are optional in record descriptors or EOR is optional in block
descriptors.  Can someone enlighten me?  Please?  


                        Adthanksvance

                        Joe Herman
                        PC/IP @ Maryland

P.S.  Does anyone know of any machine I can test block mode and record
      structure against?  IBM VM/TCP will do block mode but only
      stream structure and 2.4 Ultrix does neither...

dzoey@terminus.umd.edu


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 88 17:04:49 GMT
From:      att!chinet!mcdchg!clyde!watmath!utgpu!utzoo!yunexus!maccs!beame@ucbvax.Berkeley.EDU  (Carl Beame)
To:        tcp-ip@sri-nic.arpa
Subject:   NFS for IBM PC

     We are currently involved in the creation of the commercial product
   BW-NFS, an implementation of Network File System for the PC (client version).
   Now that the alpha-test stage is complete, we are looking for interested
   parties to participate in beta-testing.

     The physical requirements are PCs with 3Com 3C501 ethernet cards,
   and DOS 3.x. Servers which implement NFS, RPC and XDR and have a C
   compiler are a must.

        - Carl Beame

          Beame@McMaster.CA
          ... !uunet!attcan!utzoo!utgpu!maccs!beame
          (416) 648-6556
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 88 19:23:50 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Summary: TCP/IP and NFS for the Mac

There has apparently been some confusion regarding the status of my
TCP/IP package. As it very clearly states when you bring it up, it is
copyrighted by myself. Although I have granted to noncommercial users
(including university and amateur radio groups) the right to use, copy
and modify it for free, this does not in any way diminish my other
rights under copyright, nor does it place the package into the public
domain.

I am well aware that my policy of openly publishing my sources makes it
much harder, as a practical matter, to keep commercial users from
abusing my copyright restriction. It has also probably diminished the
commercial value of the software.  However, very early on I decided
that, despite this risk, open publication was essential to maximize the
benefit to the amateur radio community for which the package is
primarily intended.

Although most of the code in the package is by myself, certain sections
have been contributed by other amateurs with the same understanding:
free for noncommercial use only.  The authors of these sections are
identified by comments in their respective source files.

I ask others to respect the wishes of myself and the other authors in
this matter. Thank you.

Phil Karn, KA9Q

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 88 20:30:18 GMT
From:      hsi!stevens@uunet.uu.net  (Richard Stevens)
To:        tcp-ip@sri-nic.arpa
Subject:   IEEE 802.2, 802.3 & Ethernet questions
I have a few questions regarding the use of TCP/IP on an Ethernet.
From reading RFC 1042, I'm led to believe that "all communication
is performed using 802.2 type 1 communication."  That would seem to
imply that the 8-byte LLC header and SNAP header is being used,
but going through our 4.3 BSD sources, I can't find any refernces
to these headers.  Later in the RFC, they talk about "Interoperation
with Ethernet", which makes me think that what we're using is the
"Ethernet" instead of the 802.3 link level control.
I can't find many references that describe 802.2 at all - I don't
want to read the IEEE standard (if possible) and Stallings Volume 2
(which the local bookstore doesn't have) appears to be the only
reference I've seen.

(1) What are the differences between Ethernet V1.0 and V2.0 and 802.3 ?
	From seeing how our hardware is set up, it appears that all our
	interface cards are set for 802.3.

(2) Do any TCP/IP implementations on an "ethernet" use the 802.2 LLC ?
	Looking at the RT PC AIX V2.1 manual (pp. 1-17 to 1-19) leads
	me to belive that this implementation does use the 802.2 LLC.

(3) Why do some documents refer to the 2-byte field in the Ethernet
	MAC (immediately following the destination address and source
	address) as "length" (RFC 1042, for example) while others call
	it "packet type" (Comer's new book, for example) ?

(4) Are there any implementations of TCP/IP on a Token-Ring (802.5)
	other than the RT PC ?

Thanks for any light anyone can shed on this.

	Richard Stevens
	Health Systems International, New Haven, CT
           { uunet | yale } ! hsi ! stevens
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 88 09:16:00 PST
From:      <art@acc.arpa>
To:        "hsi!stevens" <hsi!stevens@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   RE: IEEE 802.2, 802.3 & Ethernet questions

Richard,

>I have a few questions regarding the use of TCP/IP on an Ethernet.
>From reading RFC 1042, I'm led to believe that "all communication
>is performed using 802.2 type 1 communication."  That would seem to
>imply that the 8-byte LLC header and SNAP header is being used,
>but going through our 4.3 BSD sources, I can't find any refernces
>to these headers.  Later in the RFC, they talk about "Interoperation
>with Ethernet", which makes me think that what we're using is the
>"Ethernet" instead of the 802.3 link level control.

We tend to get a little lax in our use of terminology.  People tend to
interchange the use of the terms "Ethernet" and "802.3" even though they
are not really quite the same thing.

>I can't find many references that describe 802.2 at all - I don't
>want to read the IEEE standard (if possible) and Stallings Volume 2
>(which the local bookstore doesn't have) appears to be the only
>reference I've seen.

The IEEE 802 standards are much easier reading than some of the ISO or
CCITT documents.

>(1) What are the differences between Ethernet V1.0 and V2.0 and 802.3 ?
>	From seeing how our hardware is set up, it appears that all our
>	interface cards are set for 802.3.

First keep in mind that these specifications have mechanical, electrical and
protocol components.

Ethernet V1.0 is the original, derived from the 3mb/sec CSMA/CD work done
at Xerox PARC.  This standard was pushed by the joint efforts of DEC, INTEL,
and Xerox.

Ethernet V2.0 was released a few years later and mainly changed the electrical
interface between the host and transceiver.  The MAC headers did not change
between V1.0 and V2.0 and both define the last word of the MAC header to be
the protocol type.

When IEEE took up standardization of LANs, 802.3 was developed for CSMA/CD
(Ethernet type) LANS.  802.3 is really broader than Ethernet and covers more
speeds and media types (and is still being extended).  802.3 and Ethernet V2.0
are close enough at mechanical and electrical levels to be functionally
equivalent.  IEEE 802 defines many MAC technologies (CSMA/CD, token bus,
token ring) but attempts to provide a common link level service.  To do this,
802 protocols are broken into two layers, Media Access Control (MAC) and
Logical Link Control (LLC or 802.2).  The MAC headers tend to differ amoung
the LAN types, but each LAN type has at least one type of "Information" MAC
frame.  These MAC frames carry LLC packets whose length must be derived from
the MAC header.  For 802.3 there is only one MAC frame type.  The 802.3 MAC
header consists of <Dest, Src, Len>, where Dest and Src are either 2 byte
or 6 byte MAC addresses and Len is the LLC packet length.  For networks
using 6 byte addresses, the Ethernet and 802.3 headers only differ in the
last word being a protocol id or an LLC length respectively.

In 802 protocols, the LLC header identifies the next layer "user" using
the "Service Access Point" (SAP) fields.  Unfortuneately, they only defined
6 usable bits for LLC SAPs and refused to assign standard SAP values for
protocols like ARP (though IP was assigned a value).  To solve this problem,
the Sub-Network Access Protocol (SNAP) was defined to expand protocol
identification.  One variant of the SNAP header carries Ethernet protocol
type codes.  RFC 1042 is basically describing this situation.

>
>(2) Do any TCP/IP implementations on an "ethernet" use the 802.2 LLC ?
>	Looking at the RT PC AIX V2.1 manual (pp. 1-17 to 1-19) leads
>	me to belive that this implementation does use the 802.2 LLC.

Most TCP/IP vendors still use Ethernet MAC headers, but there are one or
two that have adopted LLC and SNAP.  It is expected that when ISO protocols
get established that 802.2 will be more widespread.  Note that for "Etherenet"
it is possible to distinguish between Ethernet and 802.3 MAC headers because
the Ethernet protocol types are illegal LLC length values and vice versa.

>(3) Why do some documents refer to the 2-byte field in the Ethernet
>	MAC (immediately following the destination address and source
>	address) as "length" (RFC 1042, for example) while others call
>	it "packet type" (Comer's new book, for example) ?

As above, in Ethernet it is "type" and in 802.3 it is "length".

>(4) Are there any implementations of TCP/IP on a Token-Ring (802.5)
>	other than the RT PC ?

I believe that IBM's VM TCP/IP supports TR.  I would assume Proteon does
in their routers and some universities are probably running TCP/IP TRs.
(Of course there is the whole TR source routing controversy :-> ).

>Thanks for any light anyone can shed on this.

I hope this helps.

>	Richard Stevens
>	Health Systems International, New Haven, CT
>           { uunet | yale } ! hsi ! stevens

						Art Berggreen
						art@acc.arpa

------
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 09:53:43 PDT
From:      braden@venera.isi.edu
To:        dzoey@terminus.umd.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP questions.
	
	Bob, thanks for clearing up some of my misconceptions.  I realize
	now that the EOR bit in block mode is useful for page structure.
	
Apparently we are still not communicating. Page structure is irrelevant.

Suppose you have a file that is a sequence of records; call them
(C1,D1), (C2,D2), (C3,D3)..., where the Ci's are the control information that
the local operating system uses to delimit records (typically a count and
maybe some flag bits), and Di's are the ACTUAL DATA parts of the
records.  To transmit this file using FTP, you would transmit:  D1, EOR,
D2, EOR, D3, EOR... where the EOR flags are transmitted as specified by
the FTP protocol, eg in block mode in the block headers.  The local
operating system control fields are NOT transmitted, only the data parts
Di.

Bob Braden


-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 09:25:05 EDT
From:      dzoey@terminus.UMD.EDU
To:        braden@venera.isi.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP questions.
Bob, thanks for clearing up some of my misconceptions.  I realize
now that the EOR bit in block mode is useful for page structure.

I'm still a little confused about when it is permissible to keep
the data connection open.

[in stream mode]
>> Why is it necessary to close the data connection even though
>> EOF is indicated in the structure.  
	
> It isn't necessary. Section 3.2 discusses at some length when the connection
> has to be closed. For block mode, it is the server's option.

My question about when to close the data connection stems from section
3.3 where it says:
"When using the stream mode of data transfer, the end of file must be
indicated by closing the connection."

I guess that is pretty straight forward, but if EOF can be determined
from the structure, it seems a shame to have to close the connection
to signal EOF again.

> Bob Braden
	                    Thanks for the help.

                        Joe Herman

dzoey@terminus.umd.edu	
	
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 09:41:59 EDT
From:      jas@proteon.com (John A. Shriver)
To:        hsi!stevens@uunet.uu.net
Cc:        tcp-ip@sri-nic.arpa
Subject:   IEEE 802.2, 802.3 & Ethernet questions
IEEE 802.3 != Ethernet.

There are no frame format or protocol differences between Ethernet
Version 1 and 2.  The only differences are subtle (but important) ones
in the electrical interface over the transceiver cable between the
host and transceiver.

IEEE 802.3 does not have the same frame format as Ethernet.  What was
the type field in Ethernet becomes a length field.  Thus, a new
header has to be added to indicate what Network layer protocol the
packet is for.  This (among other things) is provided by IEEE 802.2.

One backwards-compatability has been provided in 802.3 for Ethernet
format frames.  It turns out that almost all of the values of the type
field were longer than a maximum length Ethernet packet.  So, if the
length is too long, it must be a type.

Electrically, IEEE 802.3 is quite similar to Ethernet Version 2,
mostly stricter.  Again, the differences are primarily in the
transceiver cable.  On the coax, all three standards are fully
compatible. 

Almost nobody runs IP over "Ethernet" using the RFC1042 encapsulation.
Instead, the format defined in RFC894 "A Standard for the Transmission
of IP Datagrams over Ethernet Networks" is used.  (Note that RFC894 is
older than those 4.3bsd sources, whereas RFC1042 is much newer.)  I
guess the existence of any "Ethernet" RFC1042 implmenations stems from
an obsession with standards (eg. IEEE) over interoperability.

Of course, the other 802 networks (802.4 and 802.5) most definitely
use the RFC1042 encapsulation.


-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 14:58:38 MDT
From:      ntia!chris@handies.ucar.edu (Chris Bogart)
To:        nbires!tcp-ip@sri-nic.arpa

    We are going to do performance measurements of IP, both DoD and ISO
versions, at NTIA, and I am looking for information concerning the two
standards.  Does anyone know of any documents which compare and contrast the
two IP's?  I'm interested in how they differ in:
     - interface with transport layer
     - functions performed

   Thanks in advance for any help you can give me.

   My UUCP mailing address is:

    ...ihnp4!stcvax!nbires!ntia!chris 

    or U.S. Mail

                     Chris Bogart
                     NTIA/ITS.N3
                     325 Broadway
                     Boulder, CO 80303
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 13:57:37 EDT
From:      barns@gateway.mitre.org (Bill Barns)
To:        braden@venera.isi.edu, dzoey@terminus.UMD.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP questions.
As best I recollect (someone correct me if I'm wrong), TOPS-20 transfers
that use page structure and stream mode do not close the data connection
after each file.  I don't recall hearing anyone claim that this was
the wrong thing to do, at least within the last few years.  By analogy,
I think it is ok to leave the connection up for record structure and
stream mode.

It's unfortunate that 3.3 is not quite consistent with 3.2 (and
implicitly disagrees with 3.4.x also, where a point is made of
saying that the close is necessary in file structure, but nothing is
said about it for the other structures.)  I think that 3.2 should be
believed.  The closing of the data connection at the end of any transfer
is at the server's discretion, so you wouldn't be out of spec to do it
if you are writing a server, but as you said in the first place,
it seems like a useless thing to do.

I believe that MIL-STD-1780 FTP is consistent with what I have just
said.  The relevant reference seems to be section 5.4.2, entitled
"Alternate Data" (huh?)  The MIL-STD has its little organizational
glitches too, you see.  Sigh.  I have not noticed anything in the MIL-STD
that replicates the troublesome wording of 3.3 of the RFC, but given
the way the MIL-STD is put together, I'm not willing to make a promise
even though I've got it open right in front of me.

Bill Barns / MITRE / barns@gateway.mitre.org
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 17:15:28 PDT
From:      braden@venera.isi.edu
To:        barns@gateway.mitre.org, dzoey@terminus.umd.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP questions.
	
	As best I recollect (someone correct me if I'm wrong), TOPS-20 transfers
	that use page structure and stream mode do not close the data connection
	after each file.  I don't recall hearing anyone claim that this was
	the wrong thing to do, at least within the last few years.  By analogy,
	I think it is ok to leave the connection up for record structure and
	stream mode.
	
That sounds right to me.  If the receiver can unambiguously tell when the
end of data has come by somehow parsing the stream, the sender does not
have to close the connection to indicate EOF.  The record-structure
escape sequences in stream mode can carry the EOF bit, or the page
structure has its own encoding that says "last page".

	It's unfortunate that 3.3 is not quite consistent with 3.2 (and
	implicitly disagrees with 3.4.x also, where a point is made of
	saying that the close is necessary in file structure, but nothing is
	said about it for the other structures.)  I think that 3.2 should be
	believed.  The closing of the data connection at the end of any transfer
	is at the server's discretion, so you wouldn't be out of spec to do it
	if you are writing a server, but as you said in the first place,
	it seems like a useless thing to do.
	
Right.

	I believe that MIL-STD-1780 FTP is consistent with what I have just
	said.  The relevant reference seems to be section 5.4.2, entitled
	"Alternate Data" (huh?)  The MIL-STD has its little organizational
	glitches too, you see.  Sigh.  I have not noticed anything in the MIL-STD
	that replicates the troublesome wording of 3.3 of the RFC, but given
	the way the MIL-STD is put together, I'm not willing to make a promise
	even though I've got it open right in front of me.

Well, I wouldn't know a MIL-STD FTP even if (especially if?) I met one
coming through a dark alley on a moonless night.  But people I trust tell
me it is obsolete, being based on RFC-765, so I wouldn't pay attention to
it anyway.  Unfortunate, DoD turned its back on Internet standards
some time ago.

Bob Braden
	
	Bill Barns / MITRE / barns@gateway.mitre.org
	
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 23:20:22 -0500
From:      Gurudatta Parulkar <guru@flora.wustl.edu>
To:        tcp-ip%sri-nic.arpa@uunet.UU.NET
Subject:   retry
>    We just completed a DRAFT of a technical report with the abstract
>    enclosed. If you would like a copy to review, please send me a note.
>    I want to mention that this report does not contain any quantitative
>    analysis, and has only qualitative reasoning to support the claims.

    				   
    	       Comments on Proposed Transport Protocols

    			     Anil Bhatia
    			    James Sterbenz
    			    Guru Parulkar
    			 guru@flora.wustl.edu

Well, I received over 70 requests in last two days asking for copies of
this report. To avoid mailing those many copies, I have decided to
make it available via anonymous ftp. Could you please retrieve this
via ftp to flora.wustl.edu ? In case you cannot, please send me (or to
anil@flora.wustl.edu) another note, and we'll send you a printed copy.
I guess the abstract seems to have raised the expectations too much!?

In any case, we'll appreciate your comments on the report. 


The details for anonymous ftp are 

Host -       flora.wustl.edu (128.252.123.41)
File name in pub directory -  cotp.tar or cotp.tar.Z  
                              (cotp = comments on transport protocols) 
When you do uncompress and untar, you will get four files:
  cotp.tex  - in LaTeX format
  bib.tex   - bibliography to go with cotp.tex
  fig1.ps   - figure in postscript form
  fig2.ps   - figure in postscript form


-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
St. Louis MO 63130 
(314) 889-4621



-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 88 14:01:28 +0200
From:      he@idt.unit.no
To:        bzs@bu-cs.bu.edu
Cc:        MURAKAMI@ntt-20.ntt.jp, tcp-ip@sri-nic.arpa, crispin@sumex-aim.stanford.edu, george@iguanodon.cis.ohio-state.edu, nowicki@sun.com, celeste@coherent.com, earle@mahendo.Jpl.Nasa.Gov
Subject:   Summary: Proxy ARP on SUN
Barry Shein writes:
   Some of my tardiness in replying to people is explained by the fact
   that I am currently changing jobs and just haven't been around, I'm
   catching up (gee, these net requestors are harsh taskmasters!)

Uh, I probably am guilty of some harshness, especially in my letter to
Murakami that got forwarded to this list.  I really am sorry for my
wording, and I apologise.

To follow up on Barry's good news section:

I've completed my proxy arp daemon for SunOS 3.[345], with README file
and man page (based on Barry's -- thanks Barry!).  I'll probably get
around to submitting my code to SunSpots for inclusion in their
sun-source archive.  However, as it usually takes some time between
things get submitted to they make it to the archive, I propose that it
should be FTP'able also.  For those of you in a hurry, you can pick it
up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar.
It's only ~26KBytes.  However, for most of you this is the other side
of the Atlantic, so don't expect too god performance...

Unfortunately, we'll (temporarily, but for at least 2 months) lose our
internet connection this coming monday (August 15th), so I'll send a
copy off to Barry and ask him to put it in their anonymous FTP area.


Regards,

Haavard Eidnes, Division of Computer Systems and Telematics
		Norwegian Institute of Technology, N-7034 Trondheim, Norway
E-Mail; any of:
	he@idt.unit.no		(will soon cease to work)
	he%idt.unit.no@norunix.bitnet
	eidnes@norunit.bitnet
	h_eidnes%vax.runit.unit.uninett@cernvax.uucp
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 88 18:25:45 GMT
From:      rochester!srs!dan@cu-arpa.cs.cornell.edu  (Dan Kegel)
To:        tcp-ip@sri-nic.arpa
Subject:   Update on "NFS and TCP/IP for the Mac"
I recently posted a summary about networking between the Mac SE and Unix 
machines.  Enough new information has come in to make reposting worthwhile.

There seem to be only two systems that let plain old Mac programs transparantly 
access files on a remote Unix fileserver:

1. Cayman Systems' Gatorbox
   This box lets Mac applications use files from any NFS file server;
   it is also a complete superset of the Kinetics FastPath.
   Not only does it allow use of TCP/IP protocols on LocalTalk,
   but it allows use of AppleTalk protocols on Ethernet, and 
   translates Apple Filing Protocol requests into NFS requests regardless of 
   whether they arrive over Ethernet or Appletalk.
   Either LocalTalk or Ethernet may be used to connect the Macs to the box;
   either thick or thin Ethernet may be specified.
   The number of Macs that one Gatorbox can support depends on how often the
   Macs need to use the network. 
   This is a slick box!  They built EXACTLY what I was looking for.

   Cayman Systems' phone number is (617) 494-1999.

   System cost:
    Using LocalTalk: $50 per client + $3500 for the Gatorbox bridge
    Using EtherTalk: $600 per client + $3500 for the Gatorbox bridge

2. TOPS, a proprietary network file system developed independantly 
   and later purchased by Sun; this has been available for some time.
   The only Unix box that TOPS currently runs on is the Sun-3.
   Either LocalTalk or Ethernet may be used to connect the Macs to the Sun.
   TOPS phone number is (800) 445-8677.

   System cost:
    Software:
     TOPS server on Sun ($900 for 1-4 clients, $1600 for 1-16 clients)
     TOPS client on Mac ($250 per client)
    Hardware:
     using LocalTalk: $50 per client + $2000 for the Kinetics Fastpath bridge
     using EtherTalk: $600 per client

Another NFS systems, rumored but not currently available, are
3. Peter Honeyman (one of the authors of HoneyDanBer uucp?) led a project 
   at CITI that put tcp/ip and NFS on Macs, under contract to Apple.
   Apple has the software now; it's unclear when if ever they will release it.
   UMich was involved in testing CITI's software.

Terminology:
 LocalTalk is Apple's 230 kilobit/sec serial networking hardware;
 EtherTalk is Ethernet, the standard 10 Megabite/sec networking hardware;
 Appletalk is Apple's set of networking protocols;
 TCP/IP is a standard networking protocol.
 (Although Appletalk is usually used with LocalTalk, and TCP/IP is usually
  used with Ethernet, any protocol can concievable run over any hardware.)

 NFS is a standard file serving protocol;
 Appleshare is Apple's file serving protocol.


There are also systems available that let TCP/IP aware programs communicate
with other machines on an Ethernet.
1. Kinetics sells Ethernet boards for all versions of the Macintosh; it
   also sells a TCP/IP (Ethernet) to TCP/IP (LocalTalk) bridge, called
   the FastPath.

2. NCSA maintains a professional-looking TELNET package for the PC and the Mac
   which supports remote login, multiple VT102 emulation, Tek 4014 emulation,
   subnetting, and dynamic IP address assignment via RARP.
   I think this is shipped with Kinetics equipment.

3. Either Stanford or Columbia maintain something called KIP and CAP
   which seems to be another TCP/IP package; this might also be used with
   the FastPath or Gatorbox.

4. Phil Karn's KA9Q package is another TCP/IP implementation.
   It is free for non-commerical use, and source is available. 

Thanks to everybody who sent in corrections.
-- 
  Dan Kegel   "We had to get it passed before the columnists attacked!"
  srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 88 20:16:21 GMT
From:      caip.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEEE 802.2, 802.3 & Ethernet questions
Arrgggg. There are two issues: electrical and software.  Electrically,
Ethernet v1, Ethernet v2, and IEEE 802.3 all put out signals that are
more or less compatible on the cable.  We've seen problems with
Ethernet v1 talking to IEEE now and then (where we have a choice, we
standardize on Ethernet v2), but by and large you can mix all three
types of equipment on the same cable.  However between the transceiver
and the computer things are less free.  Each given computer's
interface board is designed with a particular type of transceiver in
mind.  You must use the one they had in mind.  These days most
equipment is designed to take either Ethernet v2 or IEEE 802.3
transceivers.  The two standards are very close electrically.  Some
equipment can even deal with all three types of transceiver.  But
there is still equipment around (and probably even being sold) than
can deal only with Ethernet v1 transceivers.  So make sure your vendor
tells you.  (To make things worse, the people you can get to normally
don't know the difference between the three standards, so it is
sometimes hard to find out.  We normally assume Ethernet v2 unless
stated otherwise.)

There are also differences that show up in the software rather than
the hardware.  802.3, which is nominally about the hardware, does
reflect this difference in its terminology, but it shows up mostly in
802.2.  Ethernet uses an Ethernet type code in the Ethernet header.
It does not use 802.2 By using the type codes, the device-level
software is able to determine the protocol and dispatch the packet to
the right protocol-handling software.  IEEE did one of those wonderful
political numbers on us and changed the type field to a length field.
They then added 802.2 which has ways to figure out what the packet is
about.  Mostly TCP/IP implementors have ignored 802.2 and continued
to use the Ethernet type code rather than the length code that 802.3
describes.  The vendors generally claim that their systems support
802.3, but to the extent that they are putting a type code rather than
a length code in the Ethernet header, one could claim that actually
are supporting Ethernet v2 rather than 802.3.

This is all done for compatibility.  Since the original
implementations were done in the days before the IEEE standards, it is
natural that they used the Ethernet type code rather than 802.2.
Newer implementations then continued this, in order to be able to talk
to the older ones.  Vendors that put out a product that insists on
using 802.2 find that they can't talk to anyone.  (This happened to
H-P with the 3000.)  Their customers tend to demand a change.  However
for newer networks that following the 802.x standards (e.g. token and
broadband networks), it's almost certain that full 802.x, including
802.2, will be used.  That's what the new 802.x RFC is about.  It
should probably contain a warning explaining this situation, so that
people realize that it typically does not apply to Ethernet.  In order
to make it easier to design bridges that will connect a new network to
an old one, some vendors are probably going to support both formats on
Ethernet/802.3.  It is possible to design software that can deal with
both types of encapsulation.  When you want to talk to somebody, you
encode an ARP request both ways, send them both, and see which one he
answers.  In the ARP table, you have a flag indicating which
encapsulation to use with that host.  However at the moment most
software for 802.3 was really designed for Ethernet, and does not use
802.2.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 88 23:46:18 GMT
From:      holmes@ford-wdl1.arpa  (Randy D. Holmes)
To:        tcp-ip@sri-nic.arpa
Subject:   MAC II timing on ethernet ?

  I was wondering if anybody could get me started in the right direction
  in a search for some timing stats. I'm trying to find out how fast
  a Mac II can transfer a large amount (1M+) of data to a second Mac II
  on an ethernet with various currently available configurations.
  Tests from RAM to RAM would be ideal, but at this point I'll settle 
  for anything.  I have contacted Kinetics, 3Com, and Apple, but nobody 
  will admit to any bench marks. Any help at all would be greatly appreciated
  

  Randy Holmes

  holmes@ford-wdl1.arpa
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 00:09:38 GMT
From:      admin.cognet.ucla.edu!casey@CS.UCLA.EDU  (Casey Leedom)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEEE 802.2, 802.3 & Ethernet questions
In article <Aug.11.16.16.21.1988.23584@athos.rutgers.edu>
	hedrick@athos.rutgers.edu (Charles Hedrick) writes:
> 
> IEEE did one of those wonderful political numbers on us and changed the
> type field to a length field.  They then added 802.2 which has ways to
> figure out what the packet is about.

  So just how complicated is this predicate that figures out what type of
packet has been received.  It's got to be more complicated than simply
doing a case statement based on a type field.

  A prevoius article on this subject also mentioned the political nature
of this design decision.  It stated that IEEE wanted everyone to be at
equal disadvantage.  Does this make it right to make a bad design?

> Mostly TCP/IP implementors have ignored 802.2 and continued to use the
> Ethernet type code rather than the length code that 802.3 describes.

  Did you mean that second IEEE number (802.3 near the end of the sentence)
to be 802.2?  I'm still not exactly sure what the differences between
802.2 and 802.3 are, but I don't want to waste any more of your or the net's
time.  Thanks for the info.

Casey
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 88 08:50:49 EDT
From:      george@iguanodon.cis.ohio-state.edu (George M. Jones)
To:        he%idt.unit.no@relay.cs.net
Cc:        bzs@bu-cs.bu.edu, MURAKAMI@ntt-20.ntt.jp, tcp-ip@sri-nic.arpa, crispin@sumex-aim.stanford.edu, nowicki@sun.com, celeste@coherent.com, earle@mahendo.Jpl.Nasa.Gov
Subject:   Summary: Proxy ARP on SUN
   
   I propose that it
   should be FTP'able also.  For those of you in a hurry, you can pick it
   up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar.
   It's only ~26KBytes.  However, for most of you this is the other side
   of the Atlantic, so don't expect too god performance...

I managed to successfully FTP it at the blinding rate of 9.8
characters/sec.  It is now available for anonymous FTP from
tut.cis.ohio-state.edu (128.146.8.60) as as ~ftp/proxydarp/proxyarpd.shar

---George Jones
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george

Quality of life can be measured as the inverse of lawyers per thousand.
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 88 12:48:36 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP for Token Ring
As far as I know, you can get TCP/IP for 802.5 Token Ring from these
vendors, for these machines:

   IBM		PC/XT/AT/PS/2, PC/RT, 9370 & larger VM machines.
   Proteon	PC/XT/AT, P4200 IP router
   FTP Software	PC/XT/AT/PS/2 

Some of the other VM & MVS TCP/IP vendors may also support 802.5, but
I don't know for sure.

James VanBokkelen
FTP Software Inc.
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 88 13:18:21 EDT
From:      map@gaak.LCS.MIT.EDU (Michael A. Patton)
To:        admin.cognet.ucla.edu!casey@cs.ucla.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   IEEE 802.2, 802.3 & Ethernet questions
   Date: 12 Aug 88 00:09:38 GMT
   From: admin.cognet.ucla.edu!casey@cs.ucla.edu  (Casey Leedom)

   [...]

     So just how complicated is this predicate that figures out what type of
   packet has been received.  It's got to be more complicated than simply
   doing a case statement based on a type field.

If you already have a case statement for Ethernet types you presumably
have a default clause to discard types you don't want.  You just add a
simple test here that if the code is less than the max length, treat
it as an IEEE802 packet.  The feature of this technique is it doesn't
slow down the processing of any traffic you presently deal with and
can deal with IEEE802 nearly as fast as assuming that's all there is.

If you want to be IEEE802 biased, you could put the max length test on
the outside and do the ether-type dispatch in the "too long" clause.
Again normal 802 traffic isn't slowed by the ability to handle
Ethernet, and Ethernet traffic isn't much worse off.

If you have a reasonable compiler, the protocol you're biased for
executes an identical instruction stream as in the one protocol case
and the other is charged only a few (probably 2) extra instructions.
The only problem is you may get to do more processing of packets that
get thrown away.

	Mike Patton, Network Manager
	Laboratory for Computer Science
	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.
Your mileage may vary, void where prohibited by law. :-)
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 88 14:54:33 EST
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Help with TCP problem
Hello-


I am running CMU V6.2(6.3 is on order)TCP/IP on a VAX 11/785. We seem to have
developed a strange problem. We can TELNET and FTP into other networks from this
node but we seem to have lost connectivity with our network. All other TCP nodes
on our network can connect with each other but can not connect with the 11/785.

With logging enabled I get the following message:

	23:59:58.26 Log event mask set to 80000000
	23:59:57.84 Memory Mgmt. Fault detected., EC = 00158214

Can someone help me with this....thanks in advance



Keith Heilner
Heilner_k@sitvxb
Heilner_k@vaxb.stevens-tech.edu
------------

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 12:58:20 GMT
From:      root@yale.UUCP (Celray Stalk)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Update on "NFS and TCP/IP for the Mac"


I just received an information packet from Kinetics. Included was a paper
bound book "Network Primer" published by Kinetics. Section 5, Network Software,
mentions a package developed by the Center for Information Technology
Integration (CITI) group of the Information Technology Division of the
University of Michigan called MacNFS.

According to the article, "Apple Computer has recently acquired the rights to
MacNFS. For availability information, contact Apple or CITI." Anyone have
information on this?

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 13:16:33 GMT
From:      iguanodon.cis.ohio-state.edu!george@tut.cis.ohio-state.edu  (George M. Jones)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: Proxy ARP on SUN
he@idt.unit.no writes:
    I propose that it
    should be FTP'able also.  For those of you in a hurry, you can pick it
    up from loke.unit.no (IP: 128.39.5.27), in ~ftp/pub/proxyarpd.shar.
    It's only ~26KBytes.  However, for most of you this is the other side
    of the Atlantic, so don't expect too god performance...

It is now available on tut.cis.ohio-state.edu (128.146.8.60) as
~ftp/proxyarp/proxyarpd.shar.

---George Jones
-=-
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george

Quality of life can be measured as the inverse of lawyers per thousand.
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 16:21:41 GMT
From:      rlgvax!dennis@uunet.uu.net  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: Proxy ARP on SUN
In article <8808101322.AA20581@bu-cs.bu.edu>, bzs%bu-cs.bu.EDU%bu-it.bu.EDU@ntt-sh.ntt.jp (Barry Shein) writes:
> I wrote a proxy arp based upon Sun's rarpd server ...

Could someone please explain what is "proxy arp"?
Thanks in advance.
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 16:39:13 GMT
From:      panda!teddy!rdt@husc6.harvard.edu  (Ron D. Thornton)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEEE 802.2, 802.3 & Ethernet questions

As noted, the differences between V1 ethernet, V2 ethernet, and 802.2/802.3
are both electrical and header format.  On the coax, all 3 versions are fairly
compatible.  I don't have the specifications in front of me, but IEEE probably
changed some edge specifications just to be different.

On the tranceiver to controller electrical side:

Version 1 used DC coupling on the tranceiver cable interface which make it
totally incompatible with Version 2 or 802.3 tranceivers (some tranceivers/
controllers can be strapped for either DC or AC coupling).

Version 2 changed to AC coupling on the tranceiver cable interface.  V2 also 
specified that collision detect from the tranceiver should be forced on when 
a transmission is ended to provide a heartbeat or verification from the 
tranceiver.

803.2 took Version 2, played with some differential levels and driver/receiver
specifications but remains reasonable compatible with the Version 2 tranceiver
interface.  It also added an optional control signal from the controller
to the tranceiver and added an optional 3rd state to the collision presence
signal (oscillate at 5Mhz instead of 10Mhz).

On the packet header side:

All 3 versions define the first 6 octets as destination address, and next 6
as source address.

Version 1 and 2 ethernet use the next 2 octets as type field to define the
next higher protocol level.

802.3 uses those 2 octets as a length field.  Short packets may need to
be padded and this field tells where data ends and padding starts.  The
ethernet specs leave it to the next level in the protocol to determine
what is data and what is pad.  802.3 relys on the next level up, 802.2 to
define more octets that are then used to determine the next level of protocol.

There is an escape in the 802.3 header specification that allow 802.3 and
ethernet packets to co-exist.  The maximum packet length is 1500 and any
802.3 packet with a length field greater than maximum can be used in a user
defined fashion.  By only using ethernet type codes greater than 1500 you 
know at a glance if a packet is 802.3 or ethernet.  All internet type codes 
have values greater than 1500.

	-Ron-
	rdt@genrad.COM
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 88 21:48:05 GMT
From:      amdahl!cerebus!edb@ames.arc.nasa.gov  (Edward Bunch)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEEE 802.2, 802.3 & Ethernet questions
I have a practical question. 
When dealing with tranceiver cables, how does one tell the difference between
the three? I was told once that on a Ethernet tranceiver cable pin 1 (ground)
was missing; ground really being on pin 7. Is this true? Need I worry about
the type of tranceiver cable I use? The cables are rarely marked "For use with
802.3 etc.".
-- 
Edward A. Bunch
Fujitsu America, Inc.
Computer Support and Administation.
{uunet,amdahl,sun}!cerebus!edb
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Aug 88 09:47:41 EDT
From:      bzs%bu-cs.bu.edu@bu-it.BU.EDU
To:        rlgvax!dennis@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Summary: Proxy ARP on SUN

>In article <8808101322.AA20581@bu-cs.bu.edu>, bzs%bu-cs.bu.EDU%bu-it.bu.EDU@ntt-sh.ntt.jp (Barry Shein) writes:
>> I wrote a proxy arp based upon Sun's rarpd server ...
>
>Could someone please explain what is "proxy arp"?
>Thanks in advance.
>-- 
>FullName:	Dennis Bednar

I'll be explaining it at a talk at Interop88...ok, ok, that's not
what you wanted to hear.

In short, a non-subnet host will broadcast an ARP for a host that's
actually on another subnet and won't hear it (why?) A proxy arp daemon
responds with the hardware address of the gateway the packets should
be sent to (possibly, but not necessarily, itself.) The original host
doesn't know better and sends subsequent traffic to that gateway which
then forwards the packets appropriately.

See, I believe, RFC's 925 and 1027. Doug Comer's latest text also has
a section on it.

	-Barry Shein
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 88 19:42:12 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   Re: Summary: TCP/IP and NFS for the Mac

Just to add a bit to the list, Kinetics has recently announced
a "TCPort Toolkit", which includes TCP/IP support for the Mac
(installed as drivers) and a programming library to interface to
the drivers (and a "socket emulation" library).  It isn't available
until October or so (I haven't seen the announcement).  (In addition,
there is a separate product with telnet, ftp, etc.)

Greg Minshall					Kinetics
...ucbvax!mtxinu!kinetics!minshall		(415)947-0998

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 88 21:13:10 GMT
From:      motsj1!mcdchg!clyde!watmath!utgpu!utzoo!henry@hplabs.hp.com  (Henry Spencer)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: Proxy ARP on SUN
In article <972@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes:
>Could someone please explain what is "proxy arp"?

Proxp arp is when one machine answers an ARP request aimed at another,
giving its own physical address rather than the target's address.  I.e.,
"send anything meant for him to me".  The main purpose of this is to hide
network partitioning:  if the gateway between two physical networks does
proxy ARP on network A for all machines on network B, and vice-versa, the
two networks look like one on the IP level.  It's sort of a poor man's
subnetting.  The main advantage is that it hides the topology completely
and can be used with hosts that don't do subnetting properly.  The main
disadvantage is that it's a special-purpose hack that doesn't work well
in unfavorable circumstances (e.g. complex topologies).
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 88 05:44:19 GMT
From:      (Casey Leedom)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Summary: Proxy ARP on SUN
In article <8808121250.AA03525@iguanodon.cis.ohio-state.edu>
	george@tut.cis.ohio-state.edu writes (George Jones):
> 
> I managed to successfully FTP it at the blinding rate of 9.8 characters/sec.
> It is now available for anonymous FTP from tut.cis.ohio-state.edu
> (128.146.8.60) as as ~ftp/proxydarp/proxyarpd.shar

  I had such a difficult time getting through to Ohio State, I left copies
of the shar in ~ftp/pub on lll-crg.llnl.gov (128.115.1.1) and cs.ucla.edu
(128.97.28.20).

Casey
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 88 08:36:22 PDT
From:      DDN Reference <NIC@SRI-NIC.ARPA>
To:        att!chinet!mcdchg!usenet@ucbvax.berkeley.edu
Cc:        tcp-ip@SRI-NIC.ARPA, nic@SRI-NIC.ARPA
Subject:   Learning Tree Software and Internet Advertising
We thought you should be made aware of the usage policies of the DDN. Read
"DDN" wherever "ARPANET" is mentioned.

The ARPANET was not designed for commercial gain such as product advert-
isement. Learning Tree Software should pursue other means of making their
products known. The following paragraphs from the DDN New User Guide, which
the DDN Network Information Center produced for the Defense Communications
Agency, summarize the purpose of the ARPANET. Note: ARPANET Traffic
originating from other networks still needs to follow the guidelines.

        The purpose of the ARPANET is to provide a facility for
        advanced packet-switched communications technologies
        research and experimental communication support of
        government-sponsored university computer science research.
        Consequently, access to, and use of, ARPANET will not be
        authorized to support operational (as opposed to
        experimental) communication requirements.  Such operational
        facilities are provided for DoD users by the DDN (such as
        MILNET), and for others by public and private
        packet-switched networks (such as TYMNET or TELENET).

        Users of ARPANET may only use the network to conduct the
        official business for which their access was authorized.
        They must not violate privacy or any other applicable laws,
        and must not use the network for private gain or for
        commercial purposes, such as advertising or recruiting.

-------
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 88 10:31:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Van's algorithms in Streams
Steve Alexander cites Lachman's Streams implementation as containing
Van's performance enhancements.  While the congestion control enhancements
drop in relatively easily, it is my understanding that Van has not yet
released his header-prediction changes.  I would be interested to know
the origins of the code that Lachman acquired.  Steve?

With respect to the ease of adding Berkeley code to Streams, the key is
the degree of conformance to streams architecture.  One can be formally
conformant, but still have variations is certain features.

Dave

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 88 10:05:00 CDT
From:      anil@flora.wustl.edu (Anil Bhatia)
To:        tcp-ip%sri-nic.arpa@uunet.UU.NET
Subject:   Technical report "Comments on Proposed Transport Protocols"

		RE: Draft of Techinal Report
				   
	       Comments on Proposed Transport Protocols

			     Anil Bhatia
			    James Sterbenz
			    Guru Parulkar
			 guru@flora.wustl.edu



A POSTSCRIPT version of the draft of our technical report
is now available. This can be copied over the net by 
anonymous FTP on "flora.wustl.edu" with any password.


- anil
anil@flora.wustl.edu

---------------------------------------------------
Direct further enquiries to:

Guru Parulkar
guru@flora.wustl.edu
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Mon 15 Aug 88 09:37:57-EDT
From:      Del Waggoner <Waggoner-D@OSU-20.IRCC.OHIO-STATE.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        Waggoner-D@OSU-20.IRCC.OHIO-STATE.EDU
Subject:   Re: TCP/IP for Token Ring
thanks for the information...
-------
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon 15 Aug 88 18:12:25-PDT
From:      William Westfield <BILLW@MATHOM.CISCO.COM>
To:        dcrocker@TWG.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Van's algorithms in Streams
Grumble.

All things considered, Van's congestion control enhancments
are MUCH more important than the header-prediction changes.

Bill Westfield
cisco Systems.
-------
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 88 00:52:43 GMT
From:      jerry@olivey.olivetti.com (Jerry Aguirre)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Wanted: rarp or bootp for 4.3BSD

I need to be able to run either a RARP or Bootp server on a 4.3BSD Vax.
Any pointers to where I can obtain either would be much appreciated.

					Jerry Aguirre @ Olivetti ATC

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 88 15:40:09 PST
From:      geoff@Fernwood.MPK.CA.US (the tty of Geoff Goodfellow)
To:        tcp-ip@sri-nic.arpa
Subject:   BOF on SLIP at Interop 88 -- Thurs Sept 19th.
There will be a birds of a feather session on SLIP at the InterOP '88 Conference
Thursday Sept 29th after the formal sessions conclude.

If you have SLIP hackery to share, please contact me.  I'd like to schedule
a few 10 minute presentations at the start of the BOF on interesting works
involving SLIP, completed or in progress.

Topics might be:  dynamic dial-up SLIPing / SLIP header compression / SLIP
security & authentication / itinerant host SLIPing / SLIP built into modems /
SLIP over Value Added Networks / Etc / other suggestions welcomed...

Geoff Goodfellow
Anterior Technology
Geoff@Fernwood.MPK.CA.US
(415) 328-5615
-------
Interop is soliciting topics for other BOF sessions.  If you feel you have a
topic of interest, contact Advanced Computing Environments at (415) 941-3399
to schedule a discussion during the conference.
-------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 88 14:21:07 GMT
From:      mcvax!ukc!etive!adam@uunet.uu.net  (A Hamilton)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Ether loopback...
In article <12420888971.28.BILLW@MATHOM.CISCO.COM> BILLW@MATHOM.CISCO.COM (William Westfield) writes:

: Some ethernet controllers are capable of hearing packets that they are
: transmitting as they are being transmitted.  If this is true, then
: sending a packet to yourself is a good way to check whether the
: ethernet is in good shape - it checks the transceiver and the ethernet
: cable as well as the controller.
: 
Actually not so.  Many ethernet controllers have a smart processor which will
check for a loopback packet and return it to the host as if it had been
received from the Ethernet.  But the transceivers CANNOT listen during
their own transmission.

In article <88Aug7.130257hst.4295@dorsai.ics.hawaii.edu> torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") writes:
>
>Anyone happen to know if there're legitimate reasons for sending to yourself
>onan Ethernet? That is, Ethernet packets where the source and the destination
>address are identical? Seems pointless since as far as I know, you cannot read
>packets you yourself transmitted off of the wire..... Am I wrong?
>
>						Torben

No, you are right (in terms of hardware but it has to be fixed by some
form of s/w [see above]) but it is not pointless.
There are 2 reasons I am aware of.
1)	The IEEE 802.3 spec. says that all stations should be capable of
receiving a self-addressed Ethernet packet as though it were received from the
net (section 2.3.3.5).  The IEEE 802.2 spec. requires a station to transmit
such a packet at startup so as to perform a "duplicate address check".
(The packet is an IEEE 802.2 TEST packet).  It is required that exactly
one reply is received in an appropriate period of time (this one packet is
from the originating station itself which replies to this TEST packet as
to any other).  Section 6.9.2 is the relevant bit in my (out-of-date) copy.

2)	Loopback tests are often required if no other station supports the
relevant s/w.  They can also be useful as they give very different timing
effects.  Under these circumstances it can be very useful if packets go out
onto the real network where they can be picked up by a monitor, rather than
being soft looped entirely.


		Adam Hamilton
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 88 18:29:00 GMT
From:      clio!berger@uxc.cso.uiuc.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TFTP on PS/2

Can you make do with NCSA Telnet?  I believe it supports the micro channel
architecture.

			Mike Berger
			Department of Statistics 
			Science, Technology, and Society
			University of Illinois 

			berger@clio.las.uiuc.edu
			{ihnp4 | convex | pur-ee}!uiucuxc!clio!berger
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 88 19:59:17 GMT
From:      mcvax!enea!kth!draken!ragge@uunet.uu.net  (Ragnar Sundblad)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: MAC II timing on ethernet ?
In article <3950005@wdl1.UUCP> holmes@wdl1.UUCP (Randy D. Holmes) writes:
>  I was wondering if anybody could get me started in the right direction
>  in a search for some timing stats. I'm trying to find out how fast
>  a Mac II can transfer a large amount (1M+) of data to a second Mac II
>  on an ethernet with various currently available configurations.
>  Tests from RAM to RAM would be ideal, but at this point I'll settle 
>  for anything.  I have contacted Kinetics, 3Com, and Apple, but nobody 
>  will admit to any bench marks. Any help at all would be greatly appreciated

I made some stupid programs to benchmark ethernet bridges with MacIIs.
One of them just sends ethernet packets at the highest speed possible,
the other just receives and counts them.
With these I got 98-99 percent, meaning ~1.24MByte/s.
The NUBUS and MacII should have no troubles keeping this speed.
The bottleneck is usually the ethernet driver, not the hardware.
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 88 05:15:00 EDT
From:      "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        farnham
Subject:   THANKS!!
To all the wonderfully kind people out their in TCP/IP land who helped
me gather beginners info.
Thank you, I received a great deal of helpful information and have finally
digested it and am moving on to the reading list I was sent. I really
appreciated all of the feedback and wanted you all to know I thought it
was great that so many of you responded to my queries.


                                     Emily D. Farnham
                                     code 2861.7
                                     Naval Research Laboratory
                                     Washington, D.C. 

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 88 08:51:46 EDT
From:      ted@nadc.arpa (T. Calkins)
To:        farnham%nrl.decnet@NRL3.ARPA, tcp-ip@sri-nic.arpa
Cc:        farnham@sri-nic.arpa
Subject:   Re:  THANKS!!
>From tcp-ip-RELAY@SRI-NIC.ARPA Wed Aug 17 08:32:48 1988
>Received: by NADC.ARPA (5.51/1.0 )
>	id AA28307; Wed, 17 Aug 88 08:32:34 EDT
>Message-Id: <8808171232.AA28307@NADC.ARPA>
>Received: from nrl.arpa by SRI-NIC.ARPA with TCP; Wed, 17 Aug 88 02:19:20 PDT
>Date: 17 Aug 88 05:15:00 EDT
>From: "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa>
>Subject: THANKS!!
>To: "tcp-ip" <tcp-ip@sri-nic.arpa>
>Cc: farnham@SRI-NIC.ARPA
>Status: R
>
>To all the wonderfully kind people out their in TCP/IP land who helped
>me gather beginners info.
>Thank you, I received a great deal of helpful information and have finally
>digested it and am moving on to the reading list I was sent. I really
>appreciated all of the feedback and wanted you all to know I thought it
>was great that so many of you responded to my queries.
>
>
>                                     Emily D. Farnham
>                                     code 2861.7
>                                     Naval Research Laboratory
>                                     Washington, D.C. 
>
>
---------------------------
Emily:
   Would you be interested in "sharing" the TCP/IP "beginners info"
that you recieved from the net?
   If yes, mail it directly to me: ted@NADC.ARPA. If no, thanks
anyway.
   For now,
                  Ted Calkins  ( ted@NADC.ARPA )
 
NADC = Naval Air Development Center
       Warminster, PA
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 88 07:59:37 GMT
From:      david@elroy.jpl.nasa.gov  (David Robinson)
To:        tcp-ip@sri-nic.arpa
Subject:   proxyarpd for SunOS 4.0
I have finished a port of proxyarpd to SunOS 4.0
using the new STREAMS NIT modules.

It is available for anonymous FTP from
	elroy.jpl.nasa.gov  [128.149.1.100]

I have sent the changes back to the author also.


-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 88 17:09:56 EDT
From:      Philip Prindeville  <philipp@Larry.McRCIM.McGill.EDU>
To:        geoff@fernwood.mpk.ca.us
Cc:        TCP/IP <tcp-ip@sri-nic.arpa>
Subject:   Re:  BOF on SLIP at Interop 88 -- Thurs Sept 19th.
SLIP is currently being refined by the IETF Point-to-Point
Protocol working group.  Rather than have duplication of
effort, you should get in contact with Dre Perkins
<ddp@andrew.cmu.edu> or the interest mailing list
<ietf-ppp-interest@ucdavis.edu>...

-Philip
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 88 21:31:55 -0400
From:      Craig Partridge <craig@SH.CS.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Van's algorithms

	For people interested in Van's work, I suggest you read
the paper he is giving at SIGCOMM '88 this week.  It explains most of
the performance improvements he has made.  (SIGCOMM is probably the
most important networking conference of the year -- consider this 
a plug to join ACM SIGCOMM).


Craig
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed,  17 Aug 88 10:12 +0300
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Tcp/Ip code for Unix V.
We are looking for TcpIp sources implemented for system-V, version 5.2.
Does anyone have such sources and can give them? The low-level driver is
preferably EXOS, but others will be good too.
                                            Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
Israeli DECnet:  HUJICC::YEHAVI                       H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 88 18:19:22 GMT
From:      awm@doc.ic.ac.uk (Aled Morris)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   /etc/services

Below, I have included a copy of my /etc/services file.  I am trying to
build a comprehensive table of known ports, starting from "Assigned
Numbers" (the most recent version in my possession is RFC1010), and
including as many operating system quirks as is feasible.  Hopefully,
the publication of this in Unix /etc/services format will encourage the
use of standard port numbers and names, and avoid future clashes (some
hope! :-)

There are no doubt a large number of holes in this (my first attempt).

Please mail me any corrections, and I will update my master copy.  A
number of services have been given protocol type "new", if you know
better, please mail me.  If you have already done any of this, please
mail me,  I don't want to duplicate anyone's effort!

I assume that with the emergence of ISO networking standards, /etc/services
will be updated.  If anyone has implemented ISO versions of any of these
services, I would be glad to include them---I expect the entry would be
something like:

	finger	79/tp4		# ISO "Finger" server

MAIL ONLY PLEASE, DON'T FOLLOWUP TO THE NET.
^^^^ ^^^^ ^^^^^^

Aled Morris
systems programmer

    mail: awm@doc.ic.ac.uk    |    Department of Computing
    uucp: ..!ukc!icdoc!awm    |    Imperial College
    talk: 01-589-5111x5085    |    180 Queens Gate, London  SW7 2BZ


#
# /etc/services: Network services, Internet style
# Aled Morris (awm@doc.ic.ac.uk), 15th Aug, 1988
#
# See RFC1010 "Assigned Numbers" (issued May, 1987) for details.
#
# Operating systems consulted were:
#	4.3BSD, 4.2BSD, SunOS 4.0_Export, Gould UTX/32 2.1a, HP-UX 6.0,
#	Dynix 3.0.8
#
# Notes:
#	RJE	(5) all implementations used port 77
#	LOGIN	(49) all implementations use port 513
#	MTP	(57) the only private terminal access protocol I could find
#	PRINTER	(35) all implementations use port 515
#	PORTMAP (111) is the name used by HP-UX for SUNRPC
#	LINK	(245) many 4.2 derived systems use the name for port 87
# unknown protocols are marked "new"
#
# NAME		PORT/PROTOCOL	ALIASES		COMMENTS
# ----		---- --------	-------		--------
# reserved	0
# unassigned	1-4
# rje		5				# remote job entry
echo		7/tcp
echo		7/udp
discard		9/tcp		sink null
discard		9/udp		sink null
systat		11/tcp		users
daytime		13/udp
daytime		13/tcp
netstat		15/tcp				# unassigned in RFC1010
qotd		17/tcp		quote		# Quote of the Day
chargen		19/tcp		ttytst source	# Character Generator
chargen		19/udp		ttytst source
ftp-data	20/tcp		ftpdata
ftp		21/tcp
telnet		23/tcp
smtp		25/tcp		mail
nsw-fe		27/new				# NSW User System FE
msg-icp		29/new				# MSG ICP
msg-auth	31/new				# MSG Authentication
dsp		33/new				# Display Support Protocol
#		35/new				# any private printer server
time		37/tcp		timserver
time		37/udp		timserver
rlp		39/new		resource	# Resource Location Protocol
graphics	41/new				# Graphics
name		42/udp		nameserver
whois		43/tcp		nicname		# usually to sri-nic
mpm-flags	44/new				# MPM FLAGS Protocol
mpm		45/new				# Message Processing Module
mpm-snd		46/new				# MPM [default send]
ni-ftp		47/new				# NI FTP
#login		49/new				# Login Host Protocol
la-maint	51/new				# IMP Logical Address Maint.
domain		53/udp
domain		53/tcp
isi-gl		55/new				# ISI Graphics Language
mtp		57/tcp				# any private terminal access
#		59/new				# any private file service
ni-mail		61/new				# NI MAIL
via-ftp		63/new				# VIA Systems - FTP
tacacs-ds	65/new				# TACACS-Database Service
bootps		67/new				# Bootstrap Protocol Server
bootpc		68/new				# Bootstrap Protocol Client
tftp		69/udp
netrjs-1	71/new				# Remote Job Service
netrjs-2	72/new				# Remote Job Service
netrjs-3	73/new				# Remote Job Service
netrjs-4	74/new				# Remote Job Service
#		75/new				# any private dial out service
rje		77/tcp		netrjs		# any private RJE service
finger		79/tcp				# Finger
hosts2-ns	81/new				# HOSTS2 Name Server
mit-ml-dev	83/new				# MIT ML Device
mit-ml-dev	85/new				# MIT ML Device
link		87/tcp		ttylink		# any private terminal link
su-mit-tg	89/new				# SU/MIT Telnet Gateway
mit-dov		91/new				# MIT Dover Spooler
dcp		93/new				# Device Control Protocol
supdup		95/tcp				# SUPDUP
hostnames	101/tcp		hostname	# usually to sri-nic
iso-tsap	102/tcp				# ISO-TSAP
x400		103/tcp				# ISO Mail (X.400)
x400-snd	104/tcp				# X.400-SND
csnet-ns	105/tcp				# Mailbox Name Nameserver
rtelnet		107/new				# Remote Telnet Service
pop-2		109/tcp		pop postoffice	# Post Office Protocol (rev.2)
sunrpc		111/udp		portmap		# SUN Remote Procedure Call
sunrpc		111/tcp		portmap
auth		113/new				# Authentication Service
sftp		115/new				# Simple File Transfer Protocol
uucp-path	117/tcp				# UUCP Path Service
nntp		119/tcp		usenet untp	# Network News Transfer
erpc		121/new				# HYDRA Expedited RPC
ntp		123/tcp				# Network Time Protocol
locus-map	125/new				# Locus PC-Interface Net Map
locus-con	127/new				# Locus PC-Interface Conn Server
pwdgen		129/new				# Password Generator Protocol
cisco-fna	130/new				# CISCO FNATIVE
cisco-tna	131/new				# CISCO TNATIVE
cisco-sys	132/new				# CISCO SYSMAINT
statsrv		133/new				# Statistics Service
ingres-net	134/new				# INGRES-NET Service
loc-srv		135/new				# Location Service
profile		136/new				# PROFILE Naming System
netbios-ns	137/new				# NETBIOS Name Service
netbios-dgm	138/new				# NETBIOS Datagram Service
netbios-ssn	139/new				# NETBIOS Session Service
emfis-data	140/new				# EMFIS Data Service
emfis-cntl	141/new				# EMFIS Control Service
bl-idm		142/new				# Britton-Lee IDM
NeWS		144/tcp		news		# Window System
sur-meas	243/new				# Survey Measurement
#link		245/new				# LINK
#
# unassigned	143-159
# reserved	160-223
# unassigned	224-241
# unassigned	247-255
#
# KIP AppleTalk interface
# official numbers as of April, 1988
#
at-rmtp		201/udp				# AppleTalk Routing Maintenance
at-nbp		202/udp				# AppleTalk Name Binding
#at-3		203/udp				# AppleTalk unused
at-echo		204/udp				# AppleTalk Echo
#at-5		205/udp				# AppleTalk unused
at-zis		206/udp				# AppleTalk Zone Information
#at-7		207/udp				# AppleTalk Unused
#at-8		208/udp				# AppleTalk Unused
#
# Unofficial port assignments.
#
exec		512/tcp
biff		512/udp		comsat
login		513/tcp
who		513/udp		whod
shell		514/tcp		cmd		# no passwords used
syslog		514/udp
printer		515/tcp		spooler		# experimental
talk		517/udp				# old talk (bsd4.2, utx2.0)
ntalk		518/udp				# new talk (bsd4.3, utx3.0)
efs		520/tcp				# for LucasFilm
route		520/udp		router routed
search		525/tcp		searchd		# inter-machine search
timed		525/udp		timeserver
tempo		526/tcp		newdate
courier		530/tcp		rpc		# experimental
conference	531/tcp		chat
netnews		532/tcp		readnews
netwall		533/udp				# -for emergency broadcasts
uucp		540/tcp		uucpd		# uucp daemon
new-rwho	550/udp		new-who		# experimental
remotefs	556/tcp		rfs_server rfs	# Brunhoff remote filesystem
rmonitor	560/udp		rmonitord	# experimental
monitor		561/udp				# experimental
rlb		1260/tcp			# HP-UX
ingreslock	1524/tcp
nft		1536/tcp			# HP-UX
nfsd		2049/udp			# HP-UX NFS implementation
rfa		4672/tcp			# HP-UX Remote File Access
man		9535/tcp			# remote manual server
rman		9535/udp			# more of same
#
# the end

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 88 20:58:59 GMT
From:      jpm@sauna.hut.fi (Jussi-Pekka Mantere)
To:        comp.sys.mac,comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Re: Update on "NFS and TCP/IP for the Mac"

In article <951@srs.UUCP>, dan@srs (Dan Kegel) writes:
>There seem to be only two systems that let plain old Mac programs
>transparantly access files on a remote Unix fileserver:
>
>1. Cayman Systems' Gatorbox
>   This box lets Mac applications use files from any NFS file server;
How about using Mac files stored on the NFS file server from the Unix
side? Will there be three different files for the three Macintosh file
forks (info, data & resource)? If so, how will a text file be stored?
Especially, is there any character set conversions from US ASCII
to a "national" ASCII set (pick your favorite European character set)?
>   it is also a complete superset of the Kinetics FastPath.
Will it be able to run KIP (Kinetics Internet Protocol) code or is
it compatible with KIP style dynamic IP address assignment?
How will it configure itself to the two networks? Does it "autoconfigure"
itself, the way Kinetics FastPath 4 does, or does it require explicit
network administration?
>   Not only does it allow use of TCP/IP protocols on LocalTalk,
>   but it allows use of AppleTalk protocols on Ethernet, and 
  Is this "EtherTalk" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   translates Apple Filing Protocol requests into NFS requests regardless of 
>   whether they arrive over Ethernet or Appletalk.
>   Either LocalTalk or Ethernet may be used to connect the Macs to the box;
>   either thick or thin Ethernet may be specified.
>   The number of Macs that one Gatorbox can support depends on how often the
>   Macs need to use the network. 
>   This is a slick box!  They built EXACTLY what I was looking for.
BUT: Can it be used to access both AppleTalk-in-IP speaking hosts
(an Unix host running CAP (Columbia Appletalk Package)) and
EtherTalk speaking hosts (a VAX/VMS host with AppleTalk for VMS,
a Sun-3 with TOPS for Sun) from Macs speaking either AppleTalk or
EtherTalk?

To summarize: I'm impressed, but does it work for us?

>Terminology:
> EtherTalk is Ethernet, the standard 10 Megabite/sec networking hardware;
Actually, EtherTalk is another Ethernet-protocol, and not restricted to
any particular hardware. For example, a Mac can use EtherTalk over
twisted pair wires, or phone lines, with the appropriate hardware.
Not necessarily your "standard networking hardware" :-)

>  Dan Kegel   "We had to get it passed before the columnists attacked!"
>  srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
-- 
Jussi-Pekka Mantere				jpm@cs.hut.fi
Helsinki University of Technology, Finland	jpm@finhutcs.bitnet
Laboratory of Information Processing Science	+ 358 0 451 2487

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 88 01:41:00 EDT
From:      "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        farnham
Subject:   Re:  Status of NTP?
From:	NRL::MAILER       29-JUN-1988 12:38
To:	NRL::FARNHAM
Subj:	[From: celeste@coherent.com] Charles Hedrick's tcp/ip intro

Return-Path: <celeste@coherent.com>
Received: from ames.arc.nasa.gov by nrl.arpa with SMTP ; Wed, 29 Jun 88 12:37:51 EDT
Received: Wed, 29 Jun 88 09:33:43 PDT by ames.arc.nasa.gov (5.59/1.2)
Received: from frosted.coherent.com by coherent.com (3.2/SMI-3.2)
	id AA26349; Wed, 29 Jun 88 09:26:40 PDT
Received: by frosted.coherent.com (3.2/SMI-3.2)
	id AA22634; Wed, 29 Jun 88 09:26:40 PDT
Date: Wed, 29 Jun 88 09:26:40 PDT
From: celeste@coherent.com (Celeste C. Stokely)
Message-Id: <8806291626.AA22634@frosted.coherent.com>
To: farnham%nrl.DECnet@NRL3.ARPA
Subject: Charles Hedrick's tcp/ip intro

I'm assuming that this is what you're looking for. If so, enjoy!

..Celeste Stokely
Coherent Thought Inc.
UUCP:	...!{ames,sun,uunet}!coherent!celeste   Domain: celeste@coherent.com
Internet: coherent!celeste@ames.arpa or ...@sun.com or ...@uunet.uu.net
VOX:  415-493-8805
SNAIL:3350 W. Bayshore Rd. #205, Palo Alto CA  94303

From amdcad!ames!rutgers!topaz.rutgers.edu!hedrick Mon Jun 29 15:40:52 PDT 1987
Article 451 of comp.protocols.tcp-ip:
Path: sun!amdcad!ames!rutgers!topaz.rutgers.edu!hedrick
>From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP introduction
Message-ID: <12979@topaz.rutgers.edu>
Date: 28 Jun 87 07:52:42 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 936


I keep seeing requests on various newsgroups for an introduction to
TCP/IP.  I also get such requests locally.  I believe that the only
appropriate description of TCP/IP is the RFC's.  However I also think
a brief introduction is likely to be helpful before plowing right
into them.  The following document is an attempt to do that.  It also
recommends some RFC's to look at and tells you how to get them.

		--------------------------------

This document is a brief introduction to TCP/IP, followed by advice on
what to read for more information.  This is not intended to be a
complete description, but merely enough of an introduction to allow
you to start reading the RFC's.  At the end of the document there will
be a list of the RFC's that we recommend reading.

TCP/IP is a set of protocols developed to allow cooperating computers
to share resources across a network.  It was developed by a community
of researchers centered around the ARPAnet.  Certainly the ARPAnet is
the best-known TCP/IP network.  However as of June, 87, at least 130
different vendors had products that support TCP/IP, and thousands of
networks of all kinds use it.

First some basic definitions.  Although TCP/IP (or IP/TCP) seems to be
the most common term these days, most of the documentation refers to
the "Internet protocols".  The Internet is a collection of networks,
including the Arpanet, NSFnet, regional networks such as NYsernet,
local networks at a number of University and research institutions,
and a number of military networks.  The term "Internet" applies to
this entire set of networks.  The subset of them which is managed by
the Department of Defense is referred to as the "DDN" (Defense Data
Network).  This includes some research-oriented networks, such as the
Arpanet, as well as more strictly military ones.  (Because much of the
funding for Internet protocol developments is done via the DDN
organization, the terms Internet and DDN can sometimes seem
equivalent.)  All of these networks are connected to each other, and
users can send messages from any of them to any other (except where
security or other policy restrictions control access).  Officially
speaking, the Internet protocol documents are simply standards adopted
by the Internet community for its own use.  More recently, the
Department of Defense issued a MILSPEC definition of TCP/IP.  This was
intended to be a more formal definition, appropriate for use in
purchasing specifications.  However most of the TCP/IP community
continues to use the Internet standards.  The MILSPEC version is
intended to be consistent with it.

Whatever it is called, TCP/IP is a family of protocols.  A few are
basic ones used for many applications.  These include IP, TCP, and
UDP.  Others are protocols for doing specific tasks, e.g. transferring
files between computers, sending mail, or finding out who is logged in
on another computer.  Any real application will use several of these
protocols.  A typical situation is sending mail.  First, there is a
protocol for mail.  This defines a set of commands which one machine
sends to another, e.g. commands to specify who the sender of the
message is, who it is being sent to, and then the text of the message.
However this protocol assumes that there is a way to communicate
reliably between the two computers.  Mail, like other application
protocols, simply defines a set of commands and messages to be sent.
It is designed to be used together with TCP and IP. TCP is responsible
for making sure that the commands get through to the other end.  It
keeps track of what is sent, and retransmitts anything that did not
get through.  If any message is too large for one packet, e.g. the
text of the mail, TCP will split it up into several packets, and make
sure that they all arrive correctly.  Since these functions are needed
for many applications, they are put together into a separate protocol,
rather than being part of the specifications for sending mail.  You
can think of TCP as forming a library of routines that applications
can use when they need reliable network communications with another
computer.  Similarly, TCP calls on the services of IP.  Although the
services that TCP supplies are needed by many applications, there are
still some kinds of applications that don't need them.  However there
are some services that every application needs.  So these services are
put together into IP.  As with TCP, you can think of IP as a library
of routines that TCP calls on, but which is also available to
applications that don't use TCP.  This strategy of building several
levels of protocol is called "layering".  We think of the applications
programs such as mail, TCP, and IP, as being separate "layers", each
of which calls on the services of the layer below it.  Generally,
TCP/IP applications use 4 layers:

  - an application protocol such as mail
  - a protocol such as TCP that provides services need by many applications
  - IP, which provides the basic service of getting packets to their
	destination
  - the protocols needed to manage a specific physical medium, such as
	Ethernet or a point to point line.

TCP/IP is based on the "catenet model".  (This is described in more
detail in ien-48.txt.)  This model assumes that there are a large
number of independent networks connected together by gateways.  The
user should be able to access computers or other resources on any of
these networks.  Packets will often pass through a dozen different
networks before getting to their final destination.  The routing
needed to accomplish this should be completely invisible to the user.
As far as the user is concerned, all he needs to know in order to
access another system is an "Internet address".  This is an address
that looks like 128.6.4.194.  It is actually a 32-bit number.  However
it is normally written as 4 decimal numbers, each representing 8 bits
of the address.  (The term "octet" is used by Internet documentation
for such 8-bit chunks.  The term "byte" is not used, because TCP/IP is
supported by some computers that have byte sizes other than 8 bits.)
Generally the structure of the address gives you some information
about how to get to the system.  For example, 128.6 is a network
number assigned by a central authority to Rutgers University.  Rutgers
uses the next octet to indicate which of the campus Ethernets is
involved.  128.6.4 happens to be an Ethernet used by the Computer
Science Department.  The last octet allows for up to 254 systems on
each Ethernet.  Note that 128.6.4.194 and 128.6.5.194 would be
different systems.  (The structure of an Internet address is described
in a bit more detail later.)

Of course we normally refer to systems by name, rather than by
Internet address.  When we specify a name, the network software looks
it up in a database, and comes up with the corresponding Internet
address.  Most of the network software deals strictly in terms of the
address.  (rfc-882.txt describes the database used to look up names.)

TCP/IP is a "connectionless" protocol.  Information is transfered in
"packets".  Each of these packets is sent through the network
individually.  There are provisions to open connections to systems.
However at some level, information is put into packets, and those
packets are treated by the network as completely separate.  For
example, suppose you want to transfer a 15000 octet file.  Most
networks can't handle a 15000 octet packet.  So the protocols will
break this up into something like 30 500-octet packets.  Each of these
packets will be sent to the other end.  At that point, they will be
put back together into the 15000-octet file.  However while those
packets are in transit, the network doesn't know that there is any
connection between them.  It is perfectly possible that packet 14 will
actually arrive before packet 13.  It is also possible that somewhere
in the network, an error will occur, and a packet won't get through
at all.  In that case, that packet has to be sent again.  In fact,
there are two separate protocols involved in doing this.  TCP (the
"transmission control protocol") is responsible for breaking up the
message into packets, reassembling them at the other end, resending
anything that gets lost, and putting things back in the right order.
IP (the "internet protocol") is responsible for routing individual
packets.  It may seem like TCP is doing all the work.  And in small
networks that is true.  However in the Internet, simply getting a
packet to its destination can be a complex job.  A connection may
require the packet to go through several networks at Rutgers, a serial
line to the John von Neuman Supercomputer Center, a couple of
Ethernets there, a series of 56Kbaud phone lines to another NSFnet
site, and more Ethernets on another campus.  Keeping track of the
routes to all of the destinations and handling incompatibilities among
different transport media turns out to be a complex job.  Note that
the interface between TCP and IP is fairly simple.  TCP simply hands
IP a packet with a destination.  IP doesn't know how this packet
relates to any packet before it or after it.

It may have occured to you that something is missing here.  We have
talked about Internet addresses, but not about how you keep track of
multiple connections to a given system.  Clearly it isn't enough to
get a packet to the right destination.  TCP has to know which
connection this packet is part of.  This task is referred to as
"demultiplexing."  In fact, there are several levels of demultiplexing
going on in TCP/IP.  The information needed to do this demultiplexing
is contained in a series of "headers".  A header is simply a few extra
octets tacked onto the beginning of a packet by some protocol in order
to keep track of it.  It's a lot like putting a letter into an
envelope and putting an address on the outside of the envelope.
Except with modern networks it happens several times.  It's like you
put the letter into a little envelope, your secretary puts that into a
somewhat bigger envelope, the campus mail center puts that envelope
into a still bigger one, etc.  Here is an overview of the headers that
get stuck on a message that passes through a typical TCP/IP network:

We start with a single data stream, say a file you are trying to
send to some other computer:

   ......................................................

TCP breaks it up into managable chunks.  (In order to do this, TCP has
to know how large a packet your network can handle.  Actually, the
TCP's at each end say how big a packet they can handle, and then they
pick the smallest size.)

   ....   ....   ....   ....   ....   ....   ....   ....

TCP puts a header at the front of each packet.  This header actually
contains at least 20 octets, but the most important ones are a source
and destination "port number" and a "sequence number".  The port
numbers are used to keep track of different conversations.  Suppose 3
different people are transferring files.  Your TCP might allocate port
numbers 1000, 1001, and 1002 to these transfers.  When you are sending
a packet, this becomes the "source" port number, since you are the
source of the packet.  Of course the TCP at the other end has assigned
a port number of its own for the conversation.  Your TCP has to know
the port number used by the other end as well.  (It finds out when the
connection starts, as we will explain below.)  It puts this in the
"destination" port field.  Of course if the other end sends a packet
back to you, the source and destination port numbers will be reversed,
since then it will be the source and you will be the destination.
Each packet has a sequence number.  This is used so that the other end
can make sure that it gets the packets in the right order, and that it
hasn't missed any.  (See the TCP specification for details.  TCP
doesn't number the packets, but the octets.  So if there are 500
octets of data in each packet, the first packet might be numbered 0,
the second 500, the next 1000, the next 1500, etc.)  Finally, I will
mention the Checksum.  This is a number that is computed by adding up
all the octets in the packet (more or less - see the TCP spec).  The
result is put in the header.  TCP at the other end computes the
checksum again.  If they disagree, then something bad happened to the
packet in transmission, and it is thrown away.  So here's what the
packet looks like now.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |           other junk          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   your data ... next 500 octets                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ......                                                      |

If we abbreviate the TCP header as "T", the whole file now looks like this:

   T....   T....   T....   T....   T....   T....   T....   T....

TCP now sends each of these packets to IP.  Of course it has to tell
IP the Internet address of the computer at the other end.  Note that
this is all IP is concerned about.  It doesn't care about what is in
the packet, or even in the TCP header.  IP's job is simply to find a
route for the packet and get it to the other end.  In order to allow
gateways or other intermediate systems to forward the packet, it adds
its own header.  The main things in this header are the source and
destination Internet address (32-bit addresses, like 128.6.4.194), the
protocol number, and another checksum.  The source Internet address is
simply the address of your machine.  (This is necessary so the other
end knows where the packet came from.)  The destination Internet
address is the address of the other machine.  (This is necessary so
any gateways in the middle know where you want the packet to go.)  The
protocol number tells IP at the other end to send the packet to TCP.
Although most IP traffic uses TCP, there are other protocols that can
use IP, so you have to tell IP which protocol to send the packet to.
Finally, the checksum allows IP at the other end to verify that the
packet wasn't damaged in transit.  Note that TCP and IP have separate
checksums.  This is because IP doesn't know anything about TCP.  As
far as IP is concerned, everything after its header is just a bunch of
bits.  So IP computes a checksum of its own header, and IP at the
other end checks it to make sure that the message didn't get damaged
in transit.  Once IP has tacked on its header, here's what the
message looks like:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     junk      |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TCP header, then your data ......

If we represent the IP header by an "I", your file now looks like this:

   IT....   IT....   IT....   IT....   IT....   IT....   IT....   IT....

At this point, it's possible that no more headers are needed.  If your
computer happens to have a direct phone line connecting it to the
destination computer, or to a gateway, it may simply send the packets
out on the line (though likely a synchronous protocol such as HDLC
would be used, and it would add at least a few octets at the beginning
and end).

However most of our networks these days use Ethernet.  So now we have
to describe Ethernet's headers.  Unfortunately, Ethernet has its own
addresses.  The people who designed Ethernet wanted to make sure that
no two machines would end up with the same Ethernet address.
Furthermore, they didn't want the user to have to worry about
assigning addresses.  So each Ethernet controller comes with an
address builtin from the factory.  In order to make sure that they
would never have to reuse addresses, the Ethernet designers allocated
48 bits for the Ethernet address.  People who make Ethernet equipment
have to register with a central authority, to make sure that the
numbers they assign don't overlap any other manufacturer.  Ethernet is
a "broadcast medium".  That is, it is in effect like an old party line
telephone.  When you send a packet out on the Ethernet, every machine
on the network sees the packet.  So something is needed to make sure
that the right machine gets it.  As you might guess, this involves the
Ethernet header.  Every Ethernet packet has a 14-octet header that
includes the source and destination Ethernet address, and a type code.
Each machine is supposed to pay attention only to packets with its own
Ethernet address in the destination field.  (It's perfectly possible
to cheat, which is one reason that Ethernet communications are not
terribly secure.)  Note that there is no connection between the
Ethernet address and the Internet address.  Each machine has to have a
table of what Ethernet address corresponds to what Internet address.
(We will describe how this table is constructed a bit later.)  In
addition to the addresses, the header contains a type code.  The type
code is to allow for several different protocol families to be used on
the same network.  So you can use TCP/IP, DECnet, Xerox NS, etc. at
the same time.  Each of them will put a different value in the type
field.  Finally, there is a checksum.  The Ethernet controller
computes a checksum of the entire packet.  When the other end receives
the packet, it recomputes the checksum, and throws the packet away if
the answer disagrees with the original.  The checksum is put on the
end of the packet, not in the header.  The final result is that your
message looks like this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Ethernet destination address (first 32 bits)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ethernet dest (last 16 bits)  |Ethernet source (first 16 bits)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Ethernet source address (last 32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type code              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IP header, then TCP header, then your data                   |
   |                                                               |
	...
   |                                                               |
   |   end of your data                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Ethernet Checksum                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we represent the Ethernet header with "E", and the Ethernet
checksum with "C", your file now looks like this:

   EIT....C   EIT....C   EIT....C   EIT....C   EIT....C   EIT....C 

When these packets are received by the other end, of course all the
headers are removed.  The Ethernet interface removes the Ethernet
header and the checksum.  It looks at the type code.  Since the type
code is the one assigned to IP, the Ethernet device driver passes the
packet up to IP.  IP removes the IP header.  It looks at the IP
protocol field.  Since the protocol type is TCP, it passes the packet
up to TCP.  TCP now looks at the packet sequence number.  It uses the
sequence numbers and other information to combine all the packets into
the original file.

The ends our initial summary of TCP/IP.  There are still some crucial
concepts we haven't gotten to, so we'll now go back and add details in
several areas.  (For detailed descriptions of the items discussed here
see, rfc793.txt for TCP, rfc791.txt for IP, and rfc894.txt and
rfc826.txt for sending IP over Ethernet.)


Well-known sockets and the applications layer
=============================================

So far, we have described how a stream of data is broken up into
packets, sent to another computer, and put back together.  However
something more is needed in order to accomplish anything useful.
There has to be a way for you to open a connection to a specified
computer, log into it, tell it what file you want, and control the
transmission of the file.  (If you have a different application in
mind, e.g. computer mail, some analogous protocol is needed.)  This is
done by "application protocols".  The application protocols run "on
top" of TCP/IP.  That is, when they want to send a message, they give
the message to TCP.  TCP makes sure it gets delivered to the other
end.  Because TCP and IP take care of all the networking details, the
applications protocols can treat a network connection as if it were a
simple byte stream, like a terminal or phone line.

Before going into more details about applications programs, we have to
describe how you find an application.  Suppose you want to send a file
to a computer whose Internet address is 128.6.4.7.  To start the
process, you need more than just the Internet address.  You have to
connect to the file transfer server at the other end.  In general,
network programs are specialized for a specific set of tasks.  Most
systems have separate programs to handle file transfers, remote
terminal logins, mail, etc.  When you connect to 128.6.4.7, you have
to specify that you want to talk to the file transfer program.  This
is done by having "well-known sockets" for each program.  Recall that
TCP uses port numbers to keep track of individual conversations.  User
programs normally use more or less random port numbers.  However
specific port numbers are assigned to the programs that sit waiting
for requests.  For example, if you want to send a file, you will start
a program called "ftp".  It will open a connection using some random
number, say 1234, for the port number on its end.  However it will
specify port number 21 for the other end.  This is the official port
number for the ftp server.  Note that there are two different programs
involved.  You run ftp on your side.  This is a program designed to
accept commands from your terminal and pass them on to the other end.
The program that you talk to on the other machine is the ftp server.
It is designed to accept commands from the network connection, rather
than an interactive terminal.  There is no need for your program to
use a well-known socket number for itself.  Nobody is trying to find
it.  However the servers have to have well-known numbers, so that
people can open connections to them and start sending them commands.
The official port numbers for each program are given in "Assigned
Numbers".

Note that a connection is actually described by a set of 4 numbers:
the Internet address at each end, and the TCP port number at each end.
Every packet has all four of those numbers in it.  (The Internet
addresses are in the IP header, and the TCP port numbers are in the
TCP header.)  In order to keep things straight, no two connections can
have the same set of numbers.  However it is enough for any one number
to be different.  For example, it is perfectly possible for two
different users on a machine to be sending files to the same other
machine.  This could result in connections with the following
parameters:

               Internet addresses         TCP ports
connection 1  128.6.4.194, 128.6.4.7      1234, 21
connection 2  128.6.4.194, 128.6.4.7      1235, 21

Since the same machines are involved, the Internet addresses are the
same.  Since they are both doing file transfers, one end of the
connection involves the well-known port number for file transfer.  The
only thing that differs is the port number for the program that the
users are running.  That's enough of a difference.  Generally, at
least one end of the connection asks the network software to assign it
a port number that is guaranteed to be unique.  Normally, it's the
user's end, since the server has to use a well-known number.

Now that we know how to open connections, let's get back to the
applications programs.  As mentioned above, once TCP has opened a
connection, we have something that might as well be a simple wire.
All the hard parts are handled by TCP and IP.  However we still need
some agreement as to what we send over this connection.  In effect
this is simply an agreement on what set of commands the application
will understand, and the format in which they are to be sent.
Generally, what is sent is a combination of commands and data.  They
use context to differentiate.  For example, the mail protocol works
like this: Your mail program opens a connection to the mail server at
the other end.  Your program gives it your machine's name, the sender
of the message, and the recipients you want it sent to.  It then sends
a command saying that it is starting the message.  At that point, the
other end stops treating what it sees as commands, and starts
accepting the message.  Your end then starts sending the text of the
message.  At the end of the message, a special mark is sent (a dot in
the first column).  After that, both ends understand that your program
is again sending commands.  This is the simplest way to do things, and
the one that most applications use.

File transfer is somewhat more complex.  The file transfer protocol
involves two different connections.  It starts out just like mail.
The user's program sends commands like "log me in as this user", "here
is my password", "send me the file with this name".  However once the
command to send data is sent, a second connection is opened for the
data itself.  It would certainly be possible to send the data on the
same connection, as mail does.  However file transfers often take a
long time.  The designers of the file transfer protocol wanted to
allow the user to continue issuing commands while the transfer is
going on.  For example, the user might make an inquiry, or he might
abort the transfer.  Thus the designers felt it was best to use a
separate connection for the data and leave the original command
connection for commands.  (It is also possible to open command
connections to two different computers, and tell them to send a file
from one to the other.  In that case, the data couldn't go over the
command connection.)

Remote terminal connections use another mechanism still.  For remote
logins, there is just one connection.  It normally sends data.  When
it is necessary to send a command (e.g. to set the terminal type or to
change some mode), a special character is used to indicate that the
next character is a command.  If the user happens to type that special
character as data, two of them are sent.

We are not going to describe the application protocols in detail in
this document.  It's better to read the RFC's yourself.  However there
are a couple of common conventions used by applications that will be
described here.  First, the common network representation: TCP/IP is
intended to be usable on any computer.  Unfortunately, not all
computers agree on how data is represented.  There are differences in
character codes (ASCII vs. EBCDIC), in end of line conventions
(carriage return, line feed, or a representation using counts), and in
whether terminals expect characters to be sent individually or a line
at a time.  In order to allow computers of different kinds to
communicate, each applications protocol defines a standard
representation.  Note that TCP and IP do not care about the
representation.  TCP simply sends octets.  However the programs at
both ends have to agree on how the octets are to be interpreted.  The
RFC for each application specifies the standard representation for
that application.  Normally it is "net ASCII".  This uses ASCII
characters, with end of line denoted by a carriage return followed by
a line feed.  For remote login, there is also a definition of a
"standard terminal", which turns out to be a half-duplex terminal with
echoing happening on the local machine.  Most applications also make
provisions for the two computers to agree on other representations
that they may find more convenient.  For example, PDP-10's have 36-bit
words.  There is a way that two PDP-10's can agree to send a 36-bit
binary file.  Similarly, two systems that prefer full-duplex terminal
conversations can agree on that.  However each application has a
standard representation, which every machine must support.

(For more details about the protocols mentioned in this section, see
rfc821.txt and rfc822.txt for mail, rfc959.txt for file transfer, and
rfc854.txt and rfc855.txt for remote logins.  For the well-known port
numbers, see the current edition of Assigned Numbers, and possible
rfc814.txt.)


Protocols other than TCP: UDP and ICMP
======================================

So far, we have described only connections that use TCP.  Recall that
TCP is responsible for breaking up messages into packets, and
reassembling them properly.  However in many applications, we have
messages that will always fit in a single packet.  An example is name
lookup.  When a user attempts to make a connection to another system,
he will generally specify the system by name, rather than Internet
address.  His system has to translate that name to an address before
it can do anything.  Generally, only a few systems have the database
used to translate names to addresses.  So the user's system will want
to send a query to one of the systems that has the database.  This
query is going to be very short.  It will certainly fit in one packet.
So will the answer.  Thus it seems silly to use TCP.  Of course TCP
does more than just break things up into packets.  It also makes sure
that the data arrives, resending packets where necessary.  But for a
question that fits in a single packet, we don't need all the
complexity of TCP to do this.  If we don't get an answer after a few
seconds, we can just ask again.  For applications like this, there are
alternatives to TCP.

The most common alternative is UDP ("user datagram protocol").  UDP is
designed for applications where you don't need to put sequences of
packets together.  It fits into the system much like TCP.  There is a
UDP header.  The network software puts the UDP header on the front of
your data, just as it would put a TCP header on the front of your
data.  Then UDP sends the data to IP, which adds the IP header,
putting UDP's protocol number in the protocol field instead of TCP's
protocol number.  However UDP doesn't do as much as TCP does.  It
doesn't split data into multiple packets.  It doesn't keep track of
what it has sent so it can resend if necessary.  About all that UDP
provides is port numbers, so that several programs can use UDP at
once.  UDP port numbers are used just like TCP port numbers.  There
are well-known port numbers for servers that use UDP.  Note that the
UDP header is shorter than a TCP header.  It still has source and
destination port numbers, and a checksum, but that's about it.  No
sequence number, since it is not needed.  UDP is used by the protocols
that handle name lookups (see ien-116.txt, rfc882.txt, and
rfc883.txt), and a number of similar protocols.

Another alternative protocol is ICMP ("Internet control message
protocol").  ICMP is used for error messages, and other messages
intended for the TCP/IP software itself, rather than any particular
user program.  For example, if you attempt to connect to a host, your
system may get back an ICMP message saying "host unreachable".  ICMP
can also be used to find out some information about the network.  See
rfc792.txt for details of ICMP.  ICMP is similar to UDP, in that it
handles messages that fit in one packet.  However it is even simpler
than UDP.  It doesn't even have port numbers in its header.  Since all
ICMP messages are interpreted by the network software itself, no port
numbers are needed to say where a ICMP message is supposed to go.


Routing
=======

The description above indicated that the IP implementation is
responsible for getting packets to the destination indicated by the
destination address, but little was said about how this would be done.
The task of finding how to get a packet to its destination is referred
to as "routing".  In fact many of the details depend upon the
particular implementation.  However some general things can be said.

First, it is necessary to understand the model on which IP is based.
IP assumes that a system is attached to some local network.  We assume
that the system can send packets to any other system on its own
network.  (In the case of Ethernet, it simply finds the Ethernet
address of the destination system, and puts the packet out on the
Ethernet.)  The problem comes when a system is asked to send a packet
to a system on a different network.  This problem is handled by
gateways.  A gateway is a system that connects a network with one or
more other networks.  Gateways are often normal computers that happen
to have more than one network interface.  For example, we have a Unix
machine that has two different Ethernet interfaces.  Thus it is
connected to networks 128.6.4 and 128.6.3.  This machine can act as a
gateway between those two networks.  The software on that machine must
be set up so that it will forward packets from one network to the
other.  That is, if a machine on network 128.6.4 sends a packet to the
gateway, and the packet is addressed to a machine on network 128.6.3,
the gateway will forward the packet to the destination.  Major
communications centers often have gateways that connect a number of
different networks.

Routing in IP is based entirely upon the network number of the
destination address.  Each computer has a table of network numbers.
For each network number, a gateway is listed.  This is the gateway to
be used to get to that network.  Note that the gateway doesn't have to
connect directly to the network.  It just has to be the best place to
go to get there.  For example at Rutgers, our interface to NSFnet
is at the John von Neuman Supercomputer Center (JvNC). Our connection
to JvNC is via a high-speed serial line connected to a gateway whose
address is 128.6.3.12.  Systems on net 128.6.3 will list 128.6.3.12 as
the gateway for many off-campus networks.  However systems on net
128.6.4 will list 128.6.4.1 as the gateway to those same off-campus
networks.  128.6.4.1 is the gateway between networks 128.6.4 and
128.6.3, so it is the first step in getting to JvNC.

When a computer wants to send a packet, it first checks to see if the
destination address is on the system's own local network.  If so, the
packet can be sent directly.  Otherwise, the system expects to find an
entry for the network that the destination address is on.  The packet
is sent to the gateway listed in that entry.  This table can get quite
big.  For example, the Internet now includes several hundred
individual networks.  Thus various strategies have been developed to
reduce the size of the routing table.  One strategy is to depend upon
"default routes".  Often, there is only one gateway out of a network.
This gateway might connect a local Ethernet to a campus-wide backbone
network.  In that case, we don't need to have a separate entry for
every network in the world.  We simply define that gateway as a
"default".  When no specific route is found for a packet, the packet
is sent to the default gateway.  A default gateway can even be used
when there are several gateways on a network.  There are provisions
for gateways to send a message saying "I'm not the best gateway -- use
this one instead."  (The message is sent via ICMP.  See rfc792.txt)
Most network software is designed to use these messages to add entries
to their routing tables.  Suppose network 128.6.4 has two gateways,
128.6.4.59 and 128.6.4.1.  128.6.4.59 leads to several other internal
Rutgers networks.  128.6.4.1 leads indirectly to the NSFnet.  Suppose
we set 128.6.4.59 as a default gateway, and have no other routing
table entries.  Now what happens when we need to send a packet to MIT?
MIT is network 18.  Since we have no entry for network 18, the packet
will be sent to the default, 128.6.4.59.  As it happens, this gateway
is the wrong one.  So it will forward the packet to 128.6.4.1.  But it
will also send back an error saying in effect: "to get to network 18,
use 128.6.4.1".  Our software will then add an entry to the routing
table.  Any future packets to MIT will then go directly to 128.6.4.1.

Most IP experts recommend that individual computers should not try to
keep track of the entire network.  Instead, they should start with
default gateways, and let the gateways tell them the routes, as just
described.  However this doesn't say how the gateways should find out
about the routes.  The gateways can't depend upon this strategy.  They
have to have fairly complete routing tables.  (It is possible to do
hierarchical routing, where all of the gateways on a campus know about
the campus network, but direct all off-campus traffic to a single
gateway with connections off-campus.)  For this, some sort of routing
protocol is needed.  A routing protocol is simply a technique for the
gateways to find each other, and keep up to date about the best way to
get to every network.  rfc1009.txt contains a review of gateway design
and routing.  However rip.doc is probably a better introduction to the
subject.  It contains some tutorial material, and a detailed
description of the most commonly-used routing protocol.


Details about Internet addresses: subnets and broadcasting
==========================================================

As indicated above, Internet addresses are 32-bit numbers, normally
written as 4 octets (in decimal), e.g. 128.6.4.7.  There are actually
3 different types of address.  The problem is that the address has to
indicate both the network and the host within the network.  It was
felt that eventually there would be lots of networks.  Many of them
would be small, but probably 24 bits would be needed to represent all
the IP networks.  It was also felt that some very big networks might
need 24 bits to represent all of their hosts.  This would seem to lead
to 48 bit addresses.  But the designers really wanted to use 32 bit
addresses.  So they adopted a kludge.  The assumption is that most of
the networks will be small.  So they set up three different ranges of
address.  Addresses beginning with 1 to 126 use only the first octet
for the network number.  The other three octets are available for the
host number.  Thus 24 bits are available for hosts.  These numbers are
used for large networks.  But there can only be 126 of these very big
networks.  The Arpanet is one, and there are a few large commercial
networks.  But few normal organizations get one of these "class A"
addresses.  For normal large organizations, "class B" addresses are
used.  Class B addresses use the first two octets for the network
number.  Thus network numbers are 128.1 through 191.254.  (We avoid 0
and 255, for reasons that we see below.  We also avoid addresses
beginning with 127, because that is used by some systems for special
purposes.)  The last two octets are available for host addesses,
giving 16 bits of host address.  This allows for 64516 computers,
which should be enough for most organizations.  (It is possible to get
more than one class B address, if you run out.)  Finally, class C
addresses use three octets, in the range 192.1.1 to 223.254.254.
These allow only 254 hosts on each network, but there can be lots of
these networks.  Addresses above 223 are reserved for future use, as
class D and E (which are currently not defined).

Many large organizations find it convenient to divide their network
number into "subnet".  For example, Rutgers has been assigned a class
B address, 128.6.  We find it convenient to use the third octet of the
address to indicate which Ethernet a host is on.  This division has no
significance outside of Rutgers.  A computer at another institution
would send any packet whose destination address began with 128.6 on
the best route to Rutgers.  They would not have different routes for
128.6.4 or 128.6.5.  But inside Rutgers, we treat 128.6.4 and 128.6.5
as separate networks.  In effect, gateways inside Rutgers have
separate entries for each Rutgers subnet, whereas gateways outside
Rutgers just have one entry for 128.6. Note that we could do exactly
the same thing by using a separate class C address for each Ethernet.
As far as Rutgers is concerned, it would be just as convenient for us
to have a number of class C addresses.  However using class C
addresses would make things inconvenient for the rest of the world.
Every institution that wanted to talk to us would have to have a
separate entry for each one of our networks.  If every institution did
this, there would be far too many networks for any reasonable gateway
to keep track of.  By subdividing a class B network, we hide our
internal structure from everyone else, and save them trouble.  This
subnet strategy requires special provisions in the network software.
It is described in rfc950.txt.

0 and 255 have special meanings.  0 is reserved for machines that
don't know their address.  In certain circumstances it is possible for
a machine not to know the number of the network it is on, or even its
own host address.  So 0.0.0.23 would be a machine that knew it was
host number 23, but didn't know on what network.  

255 is used for "broadcast".  A broadcast is a message that you want
every system on the network to see.  Broadcasts are used in some
situations where you don't know	who to talk to.  For example, suppose
you need to look up a host name and get its Internet address.
Sometimes you don't know the address of the system that has the host
name data base.  In that case, you might send the request as a
broadcast.  There are also cases where a number of systems are
interested in information.  It is then less expensive to send a single
broadcast than to send packets individually to each host that is
interested in the information.  In order to send a broadcast, you use
an address that is made by using your network address, with all ones
in the part of the address where the host number goes.  For example,
if you are on network 128.6.4, you would use 128.6.4.255 for
broadcasts.  How this is actually implemented depends upon the medium.
It is not possible to send broadcasts on the Arpanet, or on point to
point lines.  However it is possible on an Ethernet.  If you use an
Ethernet address with all its bits on (all ones), every machine on the
Ethernet is supposed to look at that packet.

Although the official broadcast address for network 128.6.4 is now
128.6.4.255, there are some other addresses that may be treated as
broadcasts by certain implementations.  For convenience, the standard
also allows 255.255.255.255 to be used.  This refers to all hosts on
the local network.  It is often simpler to use 255.255.255.255 instead
of finding out the network number for the local network and forming a
broadcast address such as 128.6.4.255.  In addition, certain older
implementations may use 0 instead of 255 to form the broadcast
address, e.g. 128.6.4.0.  Finally, certain older implementations may
not understand about subnets.  Thus they consider the network number
to be 128.6.  In that case, they will assume a broadcast address of
128.6.255.255 or 128.6.0.0.  Until support for broadcasts is
implemented properly, it can be a somewhat dangerous feature to use.

Because 0 and 255 are used for unknown and broadcast addresses, normal
hosts should never be given addresses containing 0 or 255.  Addresses
should never begin with 0, 127, or any number above 223.  Addresses
violating these rules are sometimes referred to as "Martians", because
of rumors that the Central University of Mars is using network 225.


Packet splitting and reassembly
===============================

TCP/IP is designed for use with many different kinds of network.
Unfortunately, network designers do not agree about how big packets
can be.  Ethernet packets can be 1500 octets long.  Arpanet packets
have a maximum of around 1000 octets.  Some very fast networks have
much larger packet sizes.  At first, you might think that IP should
simply settle on the smallest possible size.  Unfortunately, this
would cause serious performance problems.  When transferring large
files, big packets are far more efficient than small ones.  So we want
to be able to use the largest packet size possible.  But we also want
to be able to handle networks with small limits.  There are two
provisions for this.  First, TCP has the ability to "negotiate" about
packet size.  When a TCP connection first opens, both ends can send
the maximum packet size they can handle.  The smaller of these numbers
is used for the rest of the connection.  This allows two
implementations that can handle big packets to use them, but also lets
them talk to implementations that can't handle them.  However this
doesn't completely solve the problem.  The most serious problem is
that the two ends don't necessarily know about all of the steps in
between.  For example, when sending data between Rutgers and Berkeley,
it is likely that both computers will be on Ethernets.  Thus they will
both be prepared to handle 1500-octet packets.  However the connection
will at some point end up going over the Arpanet.  It can't handle
packets of that size.  For this reason, there are provisions to split
packets up into pieces.  The IP header contains fields indicating the
a packet has been split, and enough information to let the pieces be
put back together.  If a gateway connects an Ethernet to the Arpanet,
it must be prepared to take 1500-octet Ethernet packets and split them
into pieces that will fit on the Arpanet.  Furthermore, every
implementation of TCP/IP must be prepared to accept pieces and put
them back together.  This is referred to as "reassembly".

TCP/IP implementations differ in the approach they take to deciding on
packet size.  It is fairly common for implementations to use 576-byte
packets whenever they can't verify that the entire path is able to
handle larger packets.  The problem is that many implementations have
bugs in the code to reassemble pieces.  So many implementors try to
avoid ever having splits occur.  Different implementors take different
approaches to deciding when it is safe to use large packets.  Some use
them only for the local network.  Others will use them for any network
on the same campus.  576 bytes is a "safe" size, which every
implementation must support.


Ethernet encapsulation: ARP
===========================

There was a brief discussion above about what IP packets looked like
on an Ethernet.  The discussion showed the Ethernet header and
checksum.  However it left one hole: It didn't say how to figure out
what Ethernet address to use when you want to talk to a given Internet
address.  In fact, there is a separate protocol for this, called ARP
("address resolution protocol").  Note by the way that ARP is not an
IP protocol.  That is, the ARP packets do not have IP headers.
Suppose you are on system 128.6.4.194 and you want to connect to
system 128.6.4.7.  Your system will first verify that 128.6.4.7 is on
the same network, so it can talk directly via Ethernet.  Then it will
look up 128.6.4.7 in its ARP table, to see if it already knows the
Ethernet address.  If so, it will stick on an Ethernet header, and
send the packet.  But suppose this system is not in the ARP table.
There is no way to send the packet, because you need the Ethernet
address.  So it uses the ARP protocol to send an ARP request.
Essentially an ARP request says "I need the Ethernet address for
128.6.4.7".  Every system listens to ARP requests.  When a system sees
an ARP request for itself, it is required to respond.  So 128.6.4.7
will see the request, and will respond with an ARP reply saying in
effect "128.6.4.7 is 8:0:20:1:56:34".  (Recall that Ethernet addresses
are 48 bits.  This is 6 octets.  Ethernet addresses are conventionally
shown in hex, using the punctuation shown.)  Your system will save
this information in its ARP table, so future packets will go directly.
Most systems treat the ARP table as a cache, and clear entries in it
if they have not been used in a certain period of time.

Note by the way that ARP requests must be sent as "broadcasts".  There
is no way that an ARP request can be sent to the right system.  After
all, the whole reason for sending an ARP request is that you don't
know the Ethernet address.  So an Ethernet address of all ones is
used, i.e. ff:ff:ff:ff:ff:ff.  By convention, every machine on the
Ethernet is required to pay attention to packets with this as an
address.  So every system sees every ARP requests.  They all look to
see whether the request is for their own address.  If so, they
respond.  If not, they could just ignore it.  (Some hosts will use ARP
requests to update their knowledge about other hosts on the network,
even if the request isn't for them.)  Note that packets whose IP
address indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255) are
also sent with an Ethernet address that is all ones.


Getting more information
========================

This directory contains documents describing the major protocols.
There are literally hundreds of documents, so we have chosen the ones
that seem most important.  Internet standards are called RFC's.  RFC
stands for Request for Comment.  A proposed standard is initially
issued as a proposal, and given an RFC number.  When it is finally
accepted, it is added to Official Internet Protocols, but it is still
referred to by the RFC number.  We have also included two IEN's.
(IEN's are an older form of RFC.)  The convention is that whenever an
RFC is revised, the revised version gets a new number.  This is fine
for most purposes, but it causes problems with two documents: Assigned
Numbers and Official Internet Protocols.  These documents are being
revised all the time, so the RFC number keeps changing.  You will have
to look in rfc-index.txt to find the number of the latest edition.
Anyone who is seriously interested in TCP/IP should read the RFC
describing IP (791).  RFC 1009 is also useful.  It is a specification
for gateways to be used by NSFnet.  As such, it contains an overview
of a lot of the TCP/IP technology.  You should probably also read the
description of at least one of the application protocols, just to get
a feel for the way things work.  Mail is probably a good one
(821/822).  TCP (793) is of course a very basic specification.
However the spec is fairly complex, so you should only read this when
you have the time and patience to think about it carefully.
Fortunately, the author of the major RFC's (Jon Postel) is a very good
writer.  The TCP RFC is far easier to read than you would expect,
given the complexity of what it is describing.  You can look at the
other RFC's as you become curious about their subject matter.

Here is a list of the documents you are more likely to want:

   rfc-index - list of all RFC's
   rfc1012  -  somewhat fuller list of all RFC's
   rfc1011  -  Official Protocols.  It's useful to scan this to
	see what tasks protocols have been built for.  This defines
	which RFC's are actual standards, as opposed to requests
	for comments.
   rfc1010  -  Assigned Numbers.  If you are working with TCP/IP,
	you will probably want a hardcopy of this as a reference.
	It's not very exciting to read.  It lists all the offically
	defined well-known ports and lots of other things.
   rfc1009  -  NSFnet gateway specifications.  A good overview of
	IP routing and gateway technology.
   rfc973   -  update on domains
   rfc959   -  FTP (file transfer)
   rfc950   -  subnets
   rfc894   -  how IP is to be put on Ethernet, see also rfc825
   rfc882/3 -  domains (the database used to go from host names to
	Internet address and back -- also used to handle UUCP
	these days).  See also rfc973
   rfc854/5 -  telnet - protocol for remote logins
   rfc826   -  ARP - protocol for finding out Ethernet addresses
   rfc821/2 -  mail
   rfc814   -  names and ports - general concepts behind well-known ports
   rfc793   -  TCP
   rfc792   -  ICMP
   rfc791   -  IP
   rfc768   -  UDP
   rip.doc  -  details of the most commonly-used routing protocol
   ien-116  -  old name server (still needed by several kinds of system)
   ien-48   -  the Catenet model, general description of the philosophy
	behind TCP/IP
  
The following documents are somewhat more specialized.

   rfc813   -  window and acknowledgement strategies in TCP
   rfc815   -  packet reassembly techniques
   rfc816   -  fault isolation and resolution techniques
   rfc817   -  modularity and efficiency in implementation
   rfc879   -  the maximum segment size option in TCP
   rfc896   -  congestion control
   rfc827,888,904,975,985  - EGP

To those of you who may be reading this document remotely instead of
at Rutgers: The most important RFC's have been collected into a
three-volume set, the DDN Protocol Handbook.  It is available from the
DDN Network Information Center, SRI International, 333 Ravenswood
Avenue, Menlo Park, California 94025 (telephone: 800-235-3155).
You should be able to get them via anonymous FTP from sri-nic.arpa.
File names are:
  RFC's:
    rfc:rfc-index.txt
    rfc:rfcxxx.txt
  IEN's:
    ien:ien-index.txt
    ien:ien-xxx.txt
rip.doc is available by anonymous FTP from topaz.rutgers.edu, as
/pub/tcp-ip-docs/rip.doc.

Sites with access to UUCP but not FTP may be able to retreive them
via UUCP from UUCP host rutgers.  The file names would be 
  RFC's:
    /topaz/pub/pub/tcp-ip-docs/rfc-index.txt
    /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt
  IEN's:
    /topaz/pub/pub/tcp-ip-docs/ien-index.txt
    /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt
  /topaz/pub/pub/tcp-ip-docs/rip.doc
Note that SRI-NIC has the entire set of RFC's and IEN's, but rutgers
and topaz have only those specifically mentioned above.



-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 88 00:52:46 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@sri-nic.arpa
Subject:   yes, Ethernet controllers really can hear their own output
adam@etive.ed.ac.uk (A Hamilton) tells us that Ethernet transceivers
"CANNOT listen during their own transmission." but must use software
to simulate doing so.  The version 2 Ethernet spec in section 7.2.1.2
requires that "In the case of a station transmitting without collision
interference, the station's own transmit transitions on the coaxial
cable will also appear on the receive pair, after a delay due to
propagation through the transceiver."  So there is no problem with the
transceiver.  However most controllers can't receive at the same time
as they transmit.  I just took at look at the description for the
Intel Ethernet chips.  These are among the most common chips used in
controllers (and happen to be the only ones I have details on).  The
82501, which does the signal processing, is full duplex, and can
handle send and receive at the same time.  The controller chip, 82586,
can do so only when it is in loopback mode.  One gets the impression
that they explicitly disallow simultaneous sending and receiving
because the chip can't handle the throughput of doing both at once.
(I am guessing that this is the limit because they say that in
loopback mode, where they do send and receive at the same time, the
size of packet must be limited in order to avoid overruning the
receiver portion.)

The message from Bill Westfield saying that some controllers can hear
their own packets is describing an actual controller made by Bill's
company (cisco).  It really does hear its own output.  I don't think
this is the first controller with this property.  (At the very least,
I think Stanford's MEIS had it.)
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 88 07:38 EST
From:      BEAME%SSCvax.McMaster.CA@CORNELLC.CCS.CORNELL.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: yes, Ethernet controllers really can hear their own output

The 3C501 ethernet board for the PC can listen and receive its own output
BUT ...

        If the packet sent is over around 512 bytes, it causes the transmitted
packet to become garbled and have an incorrect CRC.

-Carl
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 88 13:46:33 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   re: Van's algorithms

I got an interesting question:

> How does one go about joining SIGCOMM?

There are two methods:

    (1) If you are already an ACM member, call the membership line and
    ask to be added to SIGCOMM.    They will add you *free* (at least
    they used to).  You'll only start paying SIGCOMM dues when your
    ACM membership is renewed.

    (2) If you are not an ACM member, join the ACM and while you are
    doing that, sign up for SIGCOMM (an extra few $$).

Craig
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 88 16:49:57 GMT
From:      mcvax!dkuug!freja!hartvig@uunet.uu.net  (Hartvig Ekner)
To:        tcp-ip@sri-nic.arpa
Subject:   Another reason for loopback packets
I have found that some ethernet chips (NIC's) simply die if they don't
get to transmit a packet every now and then. This is particularly true
for the early versions of the Intel 82586. Sending a loopback packet
every second or so is the best solution I could come up with.

Hartvig Ekner              ...mcvax!diku!hartvig
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 88 22:57:57 GMT
From:      lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: mbuf leaks

In article <2881@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes:
: Can anyone suggest good techniques for tracking down mbuf leaks?

I don't know if this is still valid, but in 4.2 I split up the DATA mbuf
type into twenty-some-odd different types of mbufs, depending on where they
were allocated.  After tweaking netstat to show which DATA type, it was easy
to see which allocator didn't have a matching deallocator.  Generally
that was sufficient to deduce the location of the leak.  Sometimes a
judicious printf or two helps as well, just so you don't go overboard.
Generally you want to hide a printf behind a debugging variable you can
turn on and off with adb.

There may be better tools to diagnose this by now...

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 88 23:39:19 GMT
From:      amdahl!nsc!rfg@ames.arc.nasa.gov  (Ron Guilmette)
To:        tcp-ip@sri-nic.arpa
Subject:   ENOTTY running System V shl(1) with WINS/TCP-IP.
Has anybody ever gotten the System V shell layers program "shl" to run on
any machine which uses the Wollogong TCP-IP product (aka WINS)?

I called Wollogong and they said that this is not supported and never has been.

But I'm stubborn and I think it should be!

(We are running WINS 2.1 on System V.3.1).

The shl program works fine when used from a "real" RS-232 serial port but it
(internally) gets the errno ENOTTY when it tries to do the ioctl SXTIOCLINK
operation if the "controlling" "terminal" is actually an rlogin'd pty.
This causes "shl" to exit with the message "not using a tty device".

We tracked this into the kernel and found out that the "sxt" driver was
returning the ENOTTY because of the fact that there was no "struct tty"
pointer in the cdevsw[] table entry for the major device number of the
/dev/ttypX devices.  We were able to fix that up easily because there
was already an array of "struct tty" things allocated to hold "tty" style
information for the pty's.  So we just forced the name of that array into
the proper entry in our conf.c file and relinked the kernel.

Now it doesn't get ENOTTY anymore, but "shl" gets hung up inside of the sxt
driver somewhere.

Does anybody have a fix?

-- 
Ron Guilmette
National SemiConductor
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 88 03:04:57 GMT
From:      munnari!otc!metro!ipso!stcns3!dave@uunet.uu.net  (Dave Horsfall)
To:        tcp-ip@sri-nic.arpa
Subject:   Serial TCP/IP - all the same?
Just a simple question - is there a single standard for TCP/IP over an
RS-232 line (SLIP?), or are there many (like Ethernet1.0/2.0/802.3 etc)?

We are trying to determine what is wrong with our serial link (a CCI
Power 6/32 running Sys V) and our local agents have never heard of a
serial TCP/IP analyser, but are willing to write a protocol module for
the famous LM-1 box.  If we can provide the specs, that is.

As a last resort, I'll dig out the Tektronix 834, but decoding SNA frames
with that was bad enough, and I won't even _consider_ looking at X.25!
Hence our interest in the LM-1, if it'll do serial TCP/IP.

Many thanks for any advice...

-- 
Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz
dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave
		UUCP does it with a bang!
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 88 10:59:10 PDT
From:      braden@venera.isi.edu
To:        BILLW@mathom.cisco.com, dcrocker@twg.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Van's algorithms in Streams
	Date: Mon 15 Aug 88 18:12:25-PDT
	From: William Westfield <BILLW@MATHOM.CISCO.COM>
	Subject: Re:  Van's algorithms in Streams
	To: dcrocker@TWG.COM
	Cc: tcp-ip@SRI-NIC.ARPA
	In-Reply-To: Message from "Dave Crocker <dcrocker@twg.com>" of Mon 15 Aug 88 10:31:00-PDT
	Message-Id: <12422755198.10.BILLW@MATHOM.CISCO.COM>
	Status: R
	
	Grumble.
	
	All things considered, Van's congestion control enhancments
	are MUCH more important than the header-prediction changes.
	
	Bill Westfield
	cisco Systems.
	-------
	
Bill,

I strongly agree. The congestion control enhancements will improve the
performance of the Internet for EVERYBODY, and will significantly improve
the THROUGHPUT for the enhanced TCP's over most real Internet paths.  The
header-prediction changes only reduce the CPU OVERHEAD for the individual
system and are mostly important for a TCP operating over a high-speed
one-hop path, e.g., across a LAN.  

Bob Braden
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 88 17:25:00 PDT
From:      John Bartas <jb@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
     A Birds of a Feather session on OS/2 has been set up for 
7:30pm Thursday the 29th at INTEROP 88. The discussion will 
include implementing TCP/IP on OS/2, supporting network hardware, 
porting applications, and APIs. 

     Please contact me with any further ideas for topics. The 
field is wide open. 

     Also: ACE is still looking for more BOF sessions. If you 
have a topic you would like to moderate a session on, contact 
them at (415) 941-3399 
-----------------------------------------------------
John Bartas
Project Leader
The Wollongong Group

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 88 14:06:36 WET DST
From:      Nick Felisiak <mcvax!tarantula.spider.co.uk!nick@uunet.UU.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Re: mbuf leaks
In article <2690@jpl-devvax.JPL.NASA.GOV> responding to  <2881@ttidca.TTI.COM>
lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) writes:

> 
> In article <2881@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes:
> : Can anyone suggest good techniques for tracking down mbuf leaks?
> 
> I don't know if this is still valid, but in 4.2 I split up the DATA mbuf
> type into twenty-some-odd different types of mbufs, depending on where they
> were allocated.  After tweaking netstat to show which DATA type, it was easy
> to see which allocator didn't have a matching deallocator.  Generally
> that was sufficient to deduce the location of the leak.
> [...]
> 
> There may be better tools to diagnose this by now...
> 
> Larry Wall
> lwall@jpl-devvax.jpl.nasa.gov
>

Working with streams buffers (rather than 4.2 mbufs), on our TCP and X.25
packages,  I have used the following technique sucessfully:

1.  #define allocb(size, pri) Xallocb (size, pri, __LINE__, __FILE__),
    and ditto for all its friends (freeb, dupb, etc).

2.  Add a couple of fields to the header structures, or build parallel
    structures maintained by the 'X*' functions, which record the line
    and file info thoughtfully included by cpp as the last two parameters.

3.  When a lost buffer is identified, find out exactly where it came from.

Doing this *without* source is somewhat tricky - you need to put a small
module between the top of tcp (or whatever), and the stream head to catch
blocks coming up and down from the user.  However, it is possible.

Nick Felisiak

nick@spider.co.uk  (nick%spider.co.uk@uunet.uu.net)
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 88 18:46:08 GMT
From:      spl1!laidbak!aes@lll-winken.llnl.gov  (Andy Schweig)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  Van's algorithms in Streams
In article <8808160634.AA03685@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
>Steve Alexander cites Lachman's Streams implementation as containing
>Van's performance enhancements.  While the congestion control enhancements
>drop in relatively easily, it is my understanding that Van has not yet
>released his header-prediction changes.  I would be interested to know
>the origins of the code that Lachman acquired.  Steve?

Steve did not mention anything about Van's header prediction code.
Since it was not available at the time of our last release, it was
not included.  What we did include was all of the available
congestion control algorithms from Van et al.

>With respect to the ease of adding Berkeley code to Streams, the key is
>the degree of conformance to streams architecture.  One can be formally
>conformant, but still have variations is certain features.

It is certainly true that some of the Berkeley code requires modification
before it can be incorporated into a STREAMS-based implementation.  Some
of it, in fact, is conceptually incompatible with the STREAMS approach.

However, changes in areas such as congestion control rarely present any
problems.  Since our product is based on the 4.3BSD TCP/IP code, these
changes pretty much just dropped right in.  In areas of the code such as
this that deal with the mechanics of the TCP protocol itself, there are
virtually no STREAMS dependencies, so the fact that our code is
STREAMS-based was not an issue.

Andy Schweig - TCP/IP Development
Lachman Associates, Inc.
...!laidbak!aes
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 88 21:12:48 GMT
From:      nic.MR.NET!como!pwcs!ems!quest!cnt!rod@csd1.milw.wisc.edu  (rod merry)
To:        tcp-ip@sri-nic.arpa
Subject:   BLAST?
Can someone pass along some information on what I think is a bulk
file transfer protocol called BLAST on top of TCP/IP.  One of my
company's salespeople has been talking about it, he says its from
NCAR.

thanks
rod
-- 
Rod Merry                               rod@cnt.MN.ORG
Computer Network Technology             {quest|bungia}!cnt!rod
9440 Science Center Drive		     
Minneapolis, MN 55428                        (612)535-8111
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 88 21:15:57 GMT
From:      indra@amdcad.AMD.COM (Indra K. Singhal)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   tn3270 for the IBM PC ??

Does anyone know if tn3270 has been ported to the 
IBM PC ? If so, I would greatly appreciate hearing about
it.

Thanks.
-- 
Indra K. Singhal                      |                                |
{ucbvax,decwrl,allegra}!amdcad!indra  |      This space for rent !     |
indra@amdcad.AMD.COM                  |                                |
(408) 749-5445(w)                     |                                | 

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Sat 20 Aug 88 03:25:05-EDT
From:      John Romkey <ROMKEY@XX.LCS.MIT.EDU>
To:        tcp-ip@sri-nic.arpa, pcip@udel.edu
Subject:   Packet Driver BOF at Interop '88
I'm going to be running a Birds of a Feather session at the next TCP/IP
Interoperability Conference, in September. This BOF will take place on
Wednesday the week of the conference, at 5PM. It won't run past 6PM
because the conference reception will be then, though if there's enough
interest (or need) we can continue it later on or at another time if
we can find a place for it.

The BOF will be about "standardizing" on a programming interface through
which MS-DOS applications (yes, presumably running on IBM PC-like things)
can access a network interface and send raw packets. This interface should
allow multiple protocol stacks to run simultaneously in the machine, and
should insulate the application as much as possible from the network media
particular network interface being used.

While I was at FTP Software, I designed and implemented something called
the "Packet Driver" interface, which has been becoming rather popular on
the PC/IP mailing list recently. The packet driver has some problems, both
with ambiguities in the specification and with some important pieces of
lacking functionality. I want to redesign the interface to allow it to
be more efficient, more general and more powerful, and I want to make sure
that it will meet the needs of protocol implementors and network itnerface
manufacturers. If this is done properly, vendors of non-smart board
TCP/IP implementations will not have to keep writing new drivers every time
a new ethernet card comes out; they'll be able to point to this specification
and have hardware vendors implement a driver which conforms to it. The
hardware vendors have the advantage that as soon as they've written this
driver, their hardware will be supported by whatever conforming software
already uses it, with little effort on their part (no beating up on
software companies to support them).

I want to encourage vendors of TCP/IP and proprietary LAN protocols for the IBM
PC to come to the BOF, and for IBM PC network interface vendors to attend.

I hope to generate an RFC from this spec, and get several pieces of public
domain software written that we can give out to people who want to support it,
in order to make their task easier.

					- john romkey
					  epilogue technology corp.

-------
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 88 19:13:43 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.protocols.tcp-ip
Subject:   Multiple TCP/IP servers on one Host.


I have an 8 port Micom TCP/IP terminal server with all ports set to slave mode
connected to a non-TCP/IP host.  This setup allows TCP/IP hosts access to a non
TCP/IP host over Ethernet.  I now need to add more ports, and intend buying
another 8 port server to add to the first.  Now the problem.  The first server
is accessed by name and all the ports are treated as a "hunting group".  How
can I add a second server without giving it a different name and internet
number so the user will not have to try each server in turn to find a vacant
port?  Is there any way, transparent to the user, that he can "TELNET server1"
and if the first server is all in use automatically "TELNET server2"?

Martin Holland.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 88 01:17:16 GMT
From:      fletcher@cs.utexas.edu (Fletcher Mattox)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Interlan drops a byte?

Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface
drop a byte of data?  Well, that's what we're seeing.  

For example, if you

	% rsh remotehost cat 183_byte_file

and the remotehost is a 4.3/Interlan host, the rsh will fail.

If you look at a packet on the wire, say, with etherfind or tcpdump,
the IP header claims there are 223 bytes (183+40 TCP/IP headers), which
is correct.  Yet there are really only 222 bytes of data in the packet.  
Hmm.

Futhermore other file sizes fail.  It appears that if (n%256 == 183)
where n is the number of bytes in the above rsh, then TCP/IP fails
because a byte is dropped from the data.

If we replace the Interlan with a DEUNA, all is as it should be.

Any ideas?

--
Fletcher Mattox 	fletcher@cs.utexas.edu	 cs.utexas.edu!fletcher

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 88 11:23:20 EDT
From:      dms@wheaties.ai.mit.edu (David M Siegel)
To:        tcp-ip@sri-nic.arpa
Subject:   SGMP
Our Proteon Gateways support SGMP (simple gateway monitoring
protocol). Does anyone have pointers to Unix software that can frob
the gateway using this protocol? Proteon claims there is some software
floating around, but couldn't point me to it.

Thanks,

-Dave
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 88 22:24:42 EDT
From:      "Robert J. Reschly Jr." <reschly@BRL.MIL>
To:        Fletcher Mattox <cs.utexas.edu!fletcher@husc6.harvard.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Interlan drops a byte?

      Fletcher,

   I just tried two tests against vgr.brl.mil, a vax running 4.3 (plus
some tahoe code, I believe), and did not see the problem you mention.
Vgr is a Perdue implementation dual 780 and is running an Interlan
NI1010 Ethernet card.  I ran the tests from a Gould 6081 connected to
the same Ethernet.

   The first test was against a file containing 90 'a's, a newline, 91
'b's, and another newline, and the second was against a file containing
183 'a's.  I piped the output of the "rsh" to 'wc', and got 183 bytes
both times.

   Two questions, a) which Interlan interface are you using, and  b)
do you have any other Interlan boards you can test against?  Our
experience has been that, though the board is not the fastest, it has
been reliable.

				Later,
				    Bob 
   --------
Phone:  (301)278-6678   AV: 298-6678    FTS: 939-6678
Arpa:   reschly@BRL.MIL (or BRL.ARPA)   UUCP:   ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
        Advanced Computer Systems Team
        Systems Engineering and Concepts Analysis Division
        U.S. Army Ballistic Research Laboratory
        ATTN: SLCBR-SE  (Reschly)
        APG, MD  21005-5066             (Hey, *I* don't make 'em up!)

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 88 20:12:43 GMT
From:      aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: SGMP
The usual recommendation for SGMP is to talk to the folks at Nysernet.
An initial implementation was done at RPI.  It's more or less public
(not public domain, but freely distributable).  Nysernet cleaned it up
a good deal, and is selling it for a minimal cost (not enough to make
money -- just enough to cause everybody maximal administrative
overhead).  They have also produced an SNMP version.  cisco and
Rutgers have been playing with the original RPI code.  As long as you
don't want anything sophiscated (e.g. I haven't gotten the X
window-based stuff to work), it's fine.  I'm not sure how happy cisco
would be about doing free software distribution to Proteon's
customers, but you could take our copy.  (However you should probably
consider Nyser's first.  It's likely to be better in the long run.)
There is also a project at Berkeley that's rewriting SGMP.  So far
they seem to have a subroutine library but almost no applications.

(By the way, I don't know who to contact at these Nysernet or
Berkeley, so please don't ask.  At cisco, you might contact
customer-service@mathom.cisco.com.)
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 88 20:38:43 GMT
From:      mailrus!emv@ames.arc.nasa.gov  (Edward Vielmetti)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: SGMP
Merit is using an sgmp monitor to watch the NSFnet machines.  
I believe I saw an "IBM Internal Use Only" banner on it, but
to be quite honest I have no idea what its availability is.
It runs under X and is quite colorful.  

I suspect that nsfnet-info@merit.edu would be able to give you
more information if they are willing.  The file 
	nis.nsf.net: [NSFNET] MONITOR.MTG-6-88
has some interesting information on sgmp and snmp strategies
for the NSFnet backbone.  (nis.nsf.net is 35.1.1.48).

--Ed
Edward Vielmetti, U of Michigan mail group
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 88 10:19:09 PDT
From:      satz@clash.cisco.com
To:        aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: SGMP
The RPI SGMP tools are available for anonymous ftp from clash.cisco.com
(192.31.7.24). The file you want is sgmp.tar.Z. It is a compressed tar file
containing the most recent working sources with bug fixes made at cisco and
Rutgers. Please note that this software is being provided as is without any
assertion as to its quality, usefulness or correctness. This code will make
core files for you if you push it too hard. However it is quite useful as
an introduction to ASN.1 and SGMP if you are persistant enough. Any bug
reports sent to me will be politely ignored. However, if you fix a bug,
please send it back for inclusion in the distribution.

Greg Satz
cisco Systems

PS. requests for sending this through the mail cannot be honoured so please
do not ask.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 12:49:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Van's algorithms in Streams
Another religious issue...

Network friendliness vs. throughput?

Clearly, any host participating in an internet needs to be a good neighbor.
Van, et cie's, combined efforts seem to provide enough mechanism to settle
the questions of "how?"

The question of whether it is more or less important that performance is,
mostly, deciding on the number of checksums that can fit on the head of a
PIN.  Nonetheless, I am curious to see the dominant point of view assuming
that internet friendliness must be the answer.  It presupposes a certain
kind of market.

If 90% of the marketplace is on small lans, then performance is likely to
be foremost in the customers' minds.  They do little or no internetting and
therefore do not care about congestion control.

No, the current number probably is not 90%, but there is a threshold,
somewhere, that says performance needs to dominate.

Dave

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 88 13:36:43 -0400
From:      Atul Khanna BBNCC 20/670 873-2531 <akhanna@ALEXANDER.BBN.COM>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        tcp-ip@SRI-NIC.ARPA, akhanna@ALEXANDER.BBN.COM
Subject:   Re: Van's algorithms
>>     (2) If you are not an ACM member, join the ACM and while you are
>>     doing that, sign up for SIGCOMM (an extra few $$).

You can also join SIGCOMM without becoming an ACM member (annual dues
= $37).
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 15:27:53 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for the IBM PC??

Greg Minshall's spring 1987 Unix tn3270 distribution included a TN3270 for
the PC, but it was built around U-B's socket library (for their NIU card),
and used a curses package that Berkeley had done (which may not have been
generally available).  This may have changed in newer releases.

FTP Software's PC/TCP has included a TN3270 since July 1987 (based on Greg's
3270 emulator).  It emulates a 3278-2, and does screen redisplays quite
rapidly (1/4 sec or less).  The version that will ship with v2.03 of PC/TCP
has a re-mappable keyboard, simple 4-color support, and will emulate a 3278-4
on an EGA or VGA.

IBM's TCP/IP for DOS also includes a TN3270, but I haven't seen it or
its manual.  It was done at UMD under contract (based on Greg's code, I
think).

James VanBokkelen
FTP Software Inc.
(617) 868-4878

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 16:29:08 GMT
From:      brad@cayman.COM (Brad Parker)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Broadcast IP on Apple LocalTalk

From article <612@kinetics.UUCP>, by minshall@kinetics.UUCP (Greg Minshall):
> From article <63660@sun.uucp>, by pugs%whitsun@Sun.COM (Tom Lyon):
> There are a few points here.  First off, there is no relation between
> AppleTalk zones and IP subnetworks specified "anywhere".  The fact is
> that quite often there is such a relation, but no one can count on it.

I disagree. The MacIP implementations I know of do a lookup for the gateway
with the zone name "*".  This implies that the "domain" (if you will)
for the MacIP forwarding is the current zone.  The MacIP forwarding is
generally specified as an IP subnet or a subrange thereof. So, a relationship
excists between AppleTalk zones and IP subnet forwarding by the gateway.

I've taken this to further imply that an IP broadcast should be sent by
a gateway to all nets in the current zone, just and an NBP Bridge request
would be.

Certainly I haven't seen any of this on paper.  One could argue that it's
not part of any formal spec, but that the implementations seem to enforce the
relationship described above.

ps: I have a terrible cold and all of this might be jibberish; but at least
it's an interesting thought ;-)

-brad
-- 
"What will you do when you wake up one morning to find that God's made you
blind in a beautiful person's world and all those great recepies have let you
down, and you're twenty and a half and you're not getting age where you go look
for the boys 'says I love you lets get married and have kids." -Billy Bragg.

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 17:19:09 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP

The RPI SGMP tools are available for anonymous ftp from clash.cisco.com
(192.31.7.24). The file you want is sgmp.tar.Z. It is a compressed tar file
containing the most recent working sources with bug fixes made at cisco and
Rutgers. Please note that this software is being provided as is without any
assertion as to its quality, usefulness or correctness. This code will make
core files for you if you push it too hard. However it is quite useful as
an introduction to ASN.1 and SGMP if you are persistant enough. Any bug
reports sent to me will be politely ignored. However, if you fix a bug,
please send it back for inclusion in the distribution.

Greg Satz
cisco Systems

PS. requests for sending this through the mail cannot be honoured so please
do not ask.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 17:36:43 GMT
From:      akhanna@ALEXANDER.BBN.COM (Atul Khanna BBNCC 20/670 873-2531)
To:        comp.protocols.tcp-ip
Subject:   Re: Van's algorithms

>>     (2) If you are not an ACM member, join the ACM and while you are
>>     doing that, sign up for SIGCOMM (an extra few $$).

You can also join SIGCOMM without becoming an ACM member (annual dues
= $37).

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 19:49:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Van's algorithms in Streams

Another religious issue...

Network friendliness vs. throughput?

Clearly, any host participating in an internet needs to be a good neighbor.
Van, et cie's, combined efforts seem to provide enough mechanism to settle
the questions of "how?"

The question of whether it is more or less important that performance is,
mostly, deciding on the number of checksums that can fit on the head of a
PIN.  Nonetheless, I am curious to see the dominant point of view assuming
that internet friendliness must be the answer.  It presupposes a certain
kind of market.

If 90% of the marketplace is on small lans, then performance is likely to
be foremost in the customers' minds.  They do little or no internetting and
therefore do not care about congestion control.

No, the current number probably is not 90%, but there is a threshold,
somewhere, that says performance needs to dominate.

Dave

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 20:29:06 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?

There are many different serial encapsulations used by TCP/IP over
serial lines.  To start with, it depends on whether the line is
synchronous or asynchronous.  The protocol used on async lines (SLIP)
is pretty standard, and has its own RFC (RFC1055).  On synchronous lines,
things are more complicated - for example, our (cisco Systems) products
support about 5 different encapsulations.  Two of these are X.25 and 
DDN X.25, which are pretty much standardized.  An ordinary X.25 protocol
analyzer is useful for debugging these.  We also support LAPB (level 2
of X.25) with and without a "packet type" field, and a sort of bare HDLC
protocol (which is not any sort of standard, but can be documented).
Other vendors are rumored to use DEC's DDCMP protocols, and/or various
non-standard protocols, some of which are considered proprietary.

There is currently an Internet Engineering Task Force who is
investigating the specification of a standard for Point-to-Point
serial links, but this is likely to take a while, and it is still
likely that a vendor would like to talk their own protocol to their
own boxes.

I don't know of any serial analyzers that support ANY of the TCP/IP
formats used on serial lines - even the standard ones...

Bill Westfield
cisco Systems.
-------

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 22:32:53 GMT
From:      rlgvax!dennis@uunet.uu.net  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Serial TCP/IP - all the same?
In article <759@stcns3.stc.oz>, dave@stcns3.stc.oz (Dave Horsfall) writes:
> Just a simple question - is there a single standard for TCP/IP over an
> RS-232 line (SLIP?), or are there many (like Ethernet1.0/2.0/802.3 etc)?
> 
> We are trying to determine what is wrong with our serial link (a CCI
> Power 6/32 running Sys V) and our local agents have never heard of a
> serial TCP/IP analyser, but are willing to write a protocol module for
> the famous LM-1 box.  If we can provide the specs, that is.

Yes, there is a single standard for SLIP.  It basically is a protocol
that describes the format and manner when sending IP packets over a
serial (RS-232 asynchronous) line. SLIP is not that complicated.
Basically SLIP describes the characters used to surround an IP packet,
and describes how such characters may be sent as data within the IP
packet by using data escaping conventions. There are several sources
of information:

	The recent RFC written by John Romkey (I believe) that describes SLIP,
	A mail message that I once posted that describes SLIP (below).

You can also use a line monitor (aka datascope) to look at the packets
on the RS-232 asynch line.  From my own experience, when things don't
work, it is usually a network configuration or routing problem.  Make sure
that your gateways file is correct.  Netstat or nstat may be helpful.
Also check that your hosts file is correct. Usually one of
the gateways doesn't know how to properly forward an IP packet, and the
packet sometimes loops until the TTL (time to live) field in the IP
header hits zero, and the packet disintegrates.

Finally, it would be rather easy to write a SLIP RS-232 line analyzer.
Simply dedicate two RS-232 ports for "passing thru" information, while
capturing it.  That is, read from port 1, and write the same to port 2,
and vice-versa. Place the two ports between the sending and receiving
machines, and you then passively intercept the traffic between the
two active machines. Then you can use your computer to analyze the packets
at a leisurely basis.  I once wrote such a tool.

Below is the text of an old message that describes the SLIP packet format,
and justifies the rules for the escape conventions used:

		How IP Packets are Sent over an Asynchronous Line



	+------------+--------------------------------------------+-------------+
	| LNI header |    LNI (Local Network Interface) data      | LNI Trailer |
	+------------+-----------+------------+-------------------+-------------+
	             | IP header | TCP header | optional TCP data |
	             +-----------+------------+-------------------+

	             |<------------ Data Encoding Rules --------->|


			Special Octets Used For Data Encoding

	 Name      Hex  Octal  Decimal    Description
	FRMEND     0xc0  0300    192      Frame End Character
	FRMESC     0xdb  0333    219      Frame Escape Character
	M_FRMEND   0xdc  0334    220      Meta Frame End Character
	M_FRMESC   0xdd  0335    221      Meta Frame Escape Character


	There is no LNI header for an asynchronous serial line.
	That is, there is no special character to introduce a sent frame.

	In the LNI data field, the sender applies the following rules:
	A data FRMEND octet is sent as FRMESC, M_FRMEND sequence.
	A data FRMESC octet is sent as FRMESC, M_FRMESC sequence.
	All other octets are sent without any translation.
	The receiving IP decodes by stripping and translating the extra octets.

	The LNI trailer contains only the FRMEND octet.
	That is, a frame is sent ending with the FRMEND character.



	Example:
	Want to send ('a', FRMESC, 'b', FRMEND, 'c').
	Sent as ('a', FRMESC, M_FRMESC, 'b', FRMESC, M_FRMEND, 'c', FRMEND).
	Note the last sent octet is not part of the LNI data field.



	Data Octet To Send               Data Sequence Actually Sent
	Hex   Octal   Decimal             Hex           Octal       Decimal
	0xdb  0333    219           (0xdb, 0xdd)    (0333, 0335)    (219, 221)
	0xc0  0300    192           (0xdb, 0xdc)    (0333, 0334)    (219, 220)






	Justification of the Rules:

	1. Sending the FRMEND data octet as a FRMESC, M_FRMEND sequence:
	   We must be able to send the FRMEND as a data character,
	   so the FRMEND has to be escaped, otherwise the receiver would
	   misinterpret it as a premature end of packet.


	2. Sending the FRMESC data octet as a FRMESC, M_FRMESC sequence:
	   Because the FRMESC is used as an escape, there has to be a way
	   of treating a FRMESC as data.  For example, if this rule weren't
	   defined, then there would be an ambiguous packet.  Suppose the
	   sender wanted to send the (data_char, FRMESC, M_FRMEND, data_char)
	   sequence.  According to rule 1 only, there would be no translation
	   of octets.  Therefore the receiver would receive it as
	   (data_char, FRMEND_data_char, data_char),
	   which is not what is intended.

-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 88 22:42:08 GMT
From:      rlgvax!dennis@uunet.uu.net  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Interlan drops a byte?
In article <3210@cs.utexas.edu>, fletcher@cs.utexas.edu (Fletcher Mattox) writes:
> 
> If you look at a packet on the wire, say, with etherfind or tcpdump,
> ...

Say, these "ethernet sniffer" tools sound like very useful tools.
Do these tools run on the UNIX machine, or on a PC?  Is source
available? Tell me more about them.  Thanks.

-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 02:29:10 GMT
From:      davidc@TERMINUS.UMD.EDU (David R. Conrad)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for the IBM PC??

>IBM's TCP/IP for DOS also includes a TN3270, but I haven't seen it or
>its manual.  It was done at UMD under contract (based on Greg's code, I
>think).

Nope.  IBM's tn3270 is based originally on work done by Jacob Rehkter at
IBM's TJ Watson Research Center, modified by Drew Perkins of CMU, then
modified by us.

-drc
-------------------------------------------------------------------------------
David R. Conrad      The University of Maryland       arpa: davidc@umd5.umd.edu
(301) 454-2946              PC/IP Group             bitnet: conradd@umdd.bitnet

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 88 08:56:45 EDT
From:      Frank KAstenholz <KASTEN@MITVMA.MIT.EDU>
To:        <tcp-ip@sri-nic.arpa>
Cc:        Dave Crocker <dcrocker@TWG.COM>
Subject:   Re:  Van's algorithms in Streams
Speaking as a commercial developer who is trying to make extensive use of
TCP/IP in a product that will eventually be required to move large images
through a network very quickly and highly reliably I would say that the more
important of the two choices (friendliness vs speed) is that one be a good
neighbor.

Our products perform newspaper composition - editing articles, pictures,
ads, graphics, etc, designing pages, and sending full page images to a photo
typesetter. All of this requires a fairly large bandwidth (worst case - a
newspaper page could be over 20 Megabytes and the requirement is to ship one
of these pages to the phototypesetter every minute). However, while the speed
requirement is high, that can allways be alleviated by throwing more money
at the system (buying more/bigger CPU's, etc, etc).  What is important to
us (and maybe many other commercial developers/users of TCP) is that the
network be reliable. If the newspaper does not get printed then the publisher
looses his/her ad revenue for the day, etc, etc and that is millions. So,
a reliable network is more important than a fast one - even on a single local
lan.

This is only one data point but I guess that it represents a large portion
of the people who wish to integrate TCP into their products.


Frank Kastenholz
Atex/EPPS/Eastman Kodak

All opinions are mine and mine alone (etc etc etc).
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 05:32:10 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?

In article <977@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes:
>	Justification of the Rules:

The justifications you gave explain why there must be SOME escape
convention (which should go without saying), but not why that
particular one was chosen.  Why is this particular escape convention
better than the old "double the special characters" convention or
preceding a special character by the escape character?  I don't think
the doubled-character convention would actually work in SLIP because
of the lack of a header (if a packet begins with FRMEND_data_char
there would be three FRMEND characters in a row, and it would look
like the FRMEND_data_char is actually the last character of the
previous packet).  But it would work to precede a FRMEND_data_char or
FRMESC_data_char with a FRMESC: when forming a packet, you search for
a FRMEND or FRMESC; if you find a FRMESC first you remove it from the
stream, read the next character into the packet buffer, and then
search again.  The only advantage I see of the chosen scheme is that
packetization and escape processing can occur as separate steps; was
this the issue that resulted in this more complex scheme?



Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 07:16:49 GMT
From:      hulsebos@philmds.UUCP (Rob Hulsebos)
To:        comp.protocols.tcp-ip
Subject:   Re: Difference between the various STREAM implementations.

In article <163@bud.UUCP> kwang@bud.UUCP (Kwang Sung) writes:
>I would like know "what is the significant difference between the following
>various products in according to AT&T STREAMS Functional Specification ?".
>
>1. The Wollongong STREAM implementation.
>2. The Convergent STREAM implementation. ( ~ Lachman's STREAM product)
>3. The Mitre STREAM implementation. ( ~ Unisoft's STREAM product)
>4. CMC, EXCELAN STREAM implementation.
>5. Or, any other STREAM implementation, if you can think.

Me too! Me too! Especially anything to do with Unisoft!

------------------------------------------------------------------------------
R.A. Hulsebos                                       ...!mcvax!philmds!hulsebos
Philips I&E Automation Modules                            phone: +31-40-785723
Building TQ-III-1, room 11
Eindhoven, The Netherlands                                # cc -O disclaimer.c
------------------------------------------------------------------------------

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 88 11:26:55 edt
From:      snorthc@nswc-g.ARPA
To:        nic.MR.NET!como!pwcs!ems!quest!cnt!rod@csd1.milw.wisc.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  BLAST?
BLAST stands for Blocked Asynch protocol (I think) it is
usually done over serial lines.  It is proprietary, but
the company does have implementations for a bunch of HW.

BLAST gives something on the order of ZMODEM file xfer rates,
2 - 3 times Kermits.

The only way I can see to run BLAST over TCP/IP would be to establish
a Telnet session and run it over that session.  No matter what the
problem, it wuld seem there is a better solution.

Hope this helps

	Stephen Northcutt (snorthc@nswc-g.arpa)

Standard disclaimer applies
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 12:05:03 GMT
From:      swb@DAINICHI.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?


  >I don't know of any serial analyzers that support ANY of the TCP/IP
  >formats used on serial lines - even the standard ones...
  >
  >Bill Westfield

For a project we almost did last year, both Tekelec and LP-COM were
interested in writing a TCP/IP formatting module for us to watch T1
lines (taking into account the encapsulation schemes of several
vendors), and for a reasonable price to boot.  One of them was even
willing to talk with us during the development process to make sure it
suited our needs(!)  I don't know if they went ahead without us or
not.
						Scott

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 12:56:45 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank KAstenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Van's algorithms in Streams

Speaking as a commercial developer who is trying to make extensive use of
TCP/IP in a product that will eventually be required to move large images
through a network very quickly and highly reliably I would say that the more
important of the two choices (friendliness vs speed) is that one be a good
neighbor.

Our products perform newspaper composition - editing articles, pictures,
ads, graphics, etc, designing pages, and sending full page images to a photo
typesetter. All of this requires a fairly large bandwidth (worst case - a
newspaper page could be over 20 Megabytes and the requirement is to ship one
of these pages to the phototypesetter every minute). However, while the speed
requirement is high, that can allways be alleviated by throwing more money
at the system (buying more/bigger CPU's, etc, etc).  What is important to
us (and maybe many other commercial developers/users of TCP) is that the
network be reliable. If the newspaper does not get printed then the publisher
looses his/her ad revenue for the day, etc, etc and that is millions. So,
a reliable network is more important than a fast one - even on a single local
lan.

This is only one data point but I guess that it represents a large portion
of the people who wish to integrate TCP into their products.


Frank Kastenholz
Atex/EPPS/Eastman Kodak

All opinions are mine and mine alone (etc etc etc).

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 15:24:27 GMT
From:      pierre@imag.imag.fr (Pierre LAFORGUE)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
>Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface
>drop a byte of data?  Well, that's what we're seeing.  
>For example, if you
>	% rsh remotehost cat 183_byte_file
>and the remotehost is a 4.3/Interlan host, the rsh will fail.

Your report is not very accurate; I think it depends of the Interlan
interface.
Here, we are using the both types: NI1010A and NP100. Both work well (I tried 
your test, of course).
May be your problem comes from your software driver. For instance, the original
BSD4.3 NP100 driver was bugged.
You may ask Un. of Berkeley for the updated driver.
-- 
Pierre LAFORGUE
pierre@imag.imag.fr      pierre@imag.UUCP      uunet.uu.net!imag!pierre

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 15:26:55 GMT
From:      snorthc@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  BLAST?

BLAST stands for Blocked Asynch protocol (I think) it is
usually done over serial lines.  It is proprietary, but
the company does have implementations for a bunch of HW.

BLAST gives something on the order of ZMODEM file xfer rates,
2 - 3 times Kermits.

The only way I can see to run BLAST over TCP/IP would be to establish
[Da Telnet session and run it over that session.  No matter what the
problem, it wuld seem there is a better solution.

Hope this helps

	Stephen Northcutt (snorthc@nswc-g.arpa)

Standard disclaimer applies

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 17:35:16 GMT
From:      paul@UXC.CSO.UIUC.EDU (Paul Pomes)
To:        comp.protocols.tcp-ip
Subject:   Interlan drops a byte?

I've also run into the problem using a Interlan 1010A card in a 4.3 BSD
VAX 11/780 with Van's TCP fixes.  Transfers kept coming up one byte short
in transferring the X.V11R2 split files from expo.lcs.mit.edu to
uxc.cso.uiuc.edu.  It was not a constant problem.  Retrying the transfer
would usually get the complete file.  One file did require six attempts
before a 512,000 copy was obtained rather than 511,999.  A cmp of the
two files showed the difference to be at the very end of the file.

Paul Pomes
Univ of Ill, CSO

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 18:38:06 GMT
From:      spp@zabriskie.uucp (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?

>The justifications you gave explain why there must be SOME escape
>convention (which should go without saying), but not why that
>particular one was chosen.  Why is this particular escape convention
>better than the old "double the special characters" convention or
>preceding a special character by the escape character?  
>
>Barry Margolin

Let me attempt an answer -- the SLIP frame-escape method has the
property that the only place a FRAME_END character appears in the
SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur
within a packet even in escaped form.  Thus, transmitting SLIP's use
one or more FRAME_ENDs to clear an idle channel, and a receiving slip 
always knows to reset itself if it gets a FRAME_END.  This approach 
might have a slight robustness advantage.  Other escape conventions
might not provide the transmitting SLIP with a definite way of 
resetting the receiver if the receiver is in an unknown state.

steve pope (spp@berkeley.EDU)

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 18:49:58 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   wanted - Nameserver binaries for an ULTRIX 2.0

The subject says it all - I've got the named/domaind stuff from
Berkeley, but since I've got a binary only system - I've got some
trouble even getting the libraries built!

Is there anyone out there with a source-license Ultrix 2.0 who has
built the nameserver libraries and is willing to give me a copy -
binary?

Umm - this is for a uVax II.

Thanks, Mike

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 20:13:14 GMT
From:      brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

Dennis Bednar wrote asking for "ethernet sniffer" info, whether they
(etherfind, tcpdump) ran on Unix boxes, PCs, was source available, etc.

I've just gone through using two reasonable tools, the Network General
"Sniffer", and the Exelan "LANalyser", both PC based for ethernet
analysis, as well as using Van's Tcpdump (daily) and SMI's Etherfind
(only where tcpdump is not available) for the purpose of determining
why a diskless Sun fails under some conditions to boot when running
the 4.0 release of the Sun OS. So I'll share what little I know.

The "Sniffer" is a menu-driven package that runs on a PC, either lap-top
or the usual notion of a PC. It only uses 2 bytes of a packet for filtering,
so one's ability to form a reasonably complex "from/to/size/type" boolean
is limited, though I personally didn't find this limitation a problem at
all - having lived with "noisier" tools. Price, $19,000, $15,000 for the
single-board PC.

The "LANalyser" is less menu-oriented, also runs on a PC, either flavor,
and uses more bytes for filtering. Price, $15,000.

The LANalyser was the choice of SRI's link-level folks whos interest is
mostly in connectivity diagnosis.

The Sniffer was the choice of my own staff, whos interest is both connectivity
and network-level and above diagnosis. With it we found that the diskless
boot problem resulted from interactions between VMS hosts running TWG/SRI
ip software and the Sun's broadcast boot request. Details available upon
request.

Tcpdump is not available in source form, one can either ftp it from any of
the usual places, or if one is not able to ftp from say, lbl or ucbarpa,
via tape from someone who is. It comes as an executable binary (Sun 3.x),
with awk scripts for digestion of its output, in tar format. On a lan with
a lot of hosts, getting a Sun just to run tcpdump seems very reasonable to
me -- I've seen a quote for a 3/50 (used) for $850... I use it to catch
the initiation of "hostile" and "questionable" events here - we've several
scripts to wrap it which may be in our ftp area (spam) if either I or Tim
remember to keep those versions current, and to diagnosis some really bad
vendor cruft (line-at-a-time smtp, with a seperate cr/lf packet!), etc.

Etherfind is available from SMI as part of their operating system release.
It supports fewer of the boolean constructions than tcpdump, and I really
avoid using it since Van's first release of tcpdump.

Another possibility is SMI's traffic routine, which is visual, a nice intro
to the activities on the wire, but little beyond that. Almost no filtering
is possible. Each of these use the NIT interface, particular to SMI, which
has bugs. For those sourced, putting metering into the device driver(s) is
an equivalent approach.

Others on this last can easily improve on this little note, in particular
someone from Network General and Exelan on pricing, "protocol suite" software
extra pricing, and capabilities.

Happy lan-ing Dennis!

Eric

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 20:18:44 GMT
From:      bar@dpmizar.sw.Datapoint.COM (Brian Ruptash)
To:        comp.protocols.tcp-ip
Subject:   Test Specifications

According to USAF DDN PMO people, the NBS is working on a full suite
DDN (DDN X.25, TCP/IP et al, FTP, TELNET, SMTP) reference test system,
under contract for DCA.  Apparently this system necessitates active
responders in the host under test.

Does anyone know of this system, and whether its specifications, and
more importantly those for the responders, are available yet?

-- Brian

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 20:56:45 GMT
From:      schoff@BEAR-MOUNTAIN.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP


    The usual recommendation for SGMP is to talk to the folks at Nysernet.
    An initial implementation was done at RPI.  It's more or less public
    (not public domain, but freely distributable).  Nysernet cleaned it up
    a good deal, and is selling it for a minimal cost (not enough to make
    money -- just enough to cause everybody maximal administrative
    overhead).

Actually we rewrote it from scratch and saved the "look and feel" of
the applications.  Additionally we added about 10 more applications
including a BSD/UNIX agent/server.  We followed the CMU model
for Tektronix/VMS/TCP administratively, becaue we heard it worked,
time will tell though.  However we have distributed a LOT of university/
non-profit licenses (source) so far, and we release a new version
about every quarter so its not an orphan.  These are important due to the
growing network management needs in terms of more complex and useful tools.

    (By the way, I don't know who to contact at these Nysernet or
    Berkeley, so please don't ask.  At cisco, you might contact
    customer-service@mathom.cisco.com.)

snmplisc@nisc.nyser.net does work for people who are interested.

Marty

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 21:26:44 GMT
From:      yeongw@C.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP

For information on NYSERNet's SGMP distribution, please contact

		Edward Nadeau,
		NYSERNet Inc.,
		165 Jordan Road,
		Troy, NY 12180
		nadeaut@nisc.nyser.net
		(518) 283-8860

Our SNMP (IDEA0011-02) distribution is not available for public distribution
yet.


Wengyik

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 88 21:49:39 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: BOF on SLIP at Interop 88 -- Thurs Sept 19th.

Well, having seen a plethora of "please add me" messages to
ietf-ppp-interest@ucdavis.edu following my posting on this
list about how one can (passively) follow developments on
the SLIP working group, and feeling immensely guilty about
it, I should restate that (as per age-old tradition), requests
to be added to the list should be sent to:

	ietf-ppp-request@ucbdavis.edu

asking to be added to the "interest" list.  Please do NOT send
requests directly to ietf-ppp-interest, or the whole readership
will get a copy of your message.

Thanks for your cooperation,

-Philip

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 02:54:54 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?

# Let me attempt an answer -- the SLIP frame-escape method has the
# property that the only place a FRAME_END character appears in the
# SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur
# within a packet even in escaped form.

Now let _me_ list another reason why this is a Good Thing.  There are quite
a few smart serial devices in the world these days.  Most of the time they
don't use any of their smarts -- getting UNIX line editing into the serial
board is something one can be quite proud of, if one can make it work at all.

If you can help do SLIP by adding some logic to your serial card, you can get
a nice performance bang for a small amount of effort: tell your serial card
to collect bytes until a timeout, buffer overflow, or terminating character
in the input.  If you use a large enough timeout and buffer, your main CPU
only has to deal with SLIP when a whole packet has arrived.

If you don't have a smart serial card, you can still get a little bit of
benefit from this down in the lowest levels of your input driver.  But if
you have a protocol that makes you keep track of state between input
characters, it gets harder no matter where you are trying to optimize it,
and you will probably end up not optimizing it.

Yours for fewer interrupts,
-- 
Paul Vixie
Digital Equipment Corporation	Work:  vixie@dec.com	Play:  paul@vixie.UUCP
Western Research Laboratory	 uunet!decwrl!vixie	   uunet!vixie!paul
Palo Alto, California, USA	  +1 415 853 6600	   +1 415 864 7013

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 04:58:40 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  BLAST?

I remember getting a number of brochures (sp) several years ago on BLAST.
My memory may be faulty; however, as I recall they were offering an ISO
1745 based protocol package using options A, B, and C.  Option C being
the transparent mode with a CRC for longitudinal integrity using either
CRC-16 or CRC-CCITT (ISO 2145?).  Basically, a souped up IBM Bisynchronous
Serial Communications (BSC) protocol with a generic nameplate.  It would
be a good replacement for SLIP over a long haul, multi-drop, and/or store
and foreward link--uses standard well-formed packets which can be supported
by chips such as the 68521 rather than a roll your own home-brew protocol.

Merton Campbell Crockett                   EATON Information Management Systems
System Software Manager                         31717 La Tienda Drive, Box 5009
AN/GYQ-21(V) Program                               Westlake Village, CA   91359

Internet:  mcc@etn-wlv.EATON.COM
Easynet:   DECWRL::mcc@etn-wlv.EATON.COM

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 11:23:31 GMT
From:      steve@umiacs.UMD.EDU (Steven D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interlan drops a byte?


   The problem here is not in your Interlan card; I've had the same problem
with my Sun-3/60.  I did a packet spy once, and it seems that under certain
circumstances, expo seems to send the FIN with a sequence number that is one
too low.

   The spy I made of the problem is enclosed below, so that others more
knowledgeable in the ways of TCP may check my reasoning.  I think expo is
running vanilla SunOS 3.4 TCP, but I'm by no means certain of that...

	-Steve

Spoken: Steve Miller    Domain: steve@mimsy.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742

pktnum 2483, timestamp 577459160 sec 410000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 228, id 95c5, off 0,
    ttl 18, protocol 6, sum e, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d52972,108d4e01
    data off 5, flags=10<ACK> window 1000,    sum 45a2, urgent 0
    TCP data length 512 (0x200) bytes

pktnum 2484, timestamp 577459160 sec 410000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6f9, off 0,
    ttl 1e, protocol 6, sum dad9, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d52f72
    data off 5, flags=10<ACK> window 2000,    sum f076, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2485, timestamp 577459160 sec 530000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 228, id 95c6, off 0,
    ttl 18, protocol 6, sum d, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d52b72,108d4e01
    data off 5, flags=10<ACK> window 1000,    sum 81b0, urgent 0
    TCP data length 512 (0x200) bytes

pktnum 2486, timestamp 577459160 sec 530000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6fa, off 0,
    ttl 1e, protocol 6, sum dad8, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d52f72
    data off 5, flags=10<ACK> window 2000,    sum f076, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2487, timestamp 577459160 sec 810000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 228, id 95c7, off 0,
    ttl 18, protocol 6, sum c, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d52d72,108d4e01
    data off 5, flags=10<ACK> window 1000,    sum 96d3, urgent 0
    TCP data length 512 (0x200) bytes

[expo sent 512 bytes after seq 1d52d72 ]

pktnum 2488, timestamp 577459160 sec 810000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6fb, off 0,
    ttl 1e, protocol 6, sum dad7, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d52f72
    data off 5, flags=10<ACK> window 2000,    sum f076, urgent 0
    TCP data length 0 (0x0) bytes

[fnord acks that]

pktnum 2489, timestamp 577459160 sec 930000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 1b8, id 95c8, off 0,
    ttl 18, protocol 6, sum 7b, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d52f71,108d4e01
    data off 5, flags=19<FIN,PUSH,ACK> window 1000,    sum 2a8, urgent 0
    TCP data length 400 (0x190) bytes

[expo, whose sequence number was 1d52f72, now sends a FIN with the sequence
number one too low.]

pktnum 2490, timestamp 577459160 sec 930000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6fc, off 0,
    ttl 1e, protocol 6, sum dad6, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d53102
    data off 5, flags=10<ACK> window 1e71,    sum f075, urgent 0
    TCP data length 0 (0x0) bytes

[fnord acks that]

pktnum 2491, timestamp 577459161 sec 70000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6fe, off 0,
    ttl 1e, protocol 6, sum dad4, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d53102
    data off 5, flags=11<FIN,ACK> window 2000,    sum eee5, urgent 0
    TCP data length 0 (0x0) bytes

[fnord sends its fin, with seq # 108d4e02]

pktnum 2492, timestamp 577459161 sec 230000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 28, id 95cb, off 0,
    ttl 18, protocol 6, sum 208, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d53102,108d4e01
    data off 5, flags=11<FIN,ACK> window 1000,    sum fee5, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2493, timestamp 577459161 sec 250000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b6ff, off 0,
    ttl 1e, protocol 6, sum dad3, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e01,1d53103
    data off 5, flags=11<FIN,ACK> window 2000,    sum eee4, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2494, timestamp 577459161 sec 270000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 28, id 95cc, off 0,
    ttl 18, protocol 6, sum 207, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d53102,108d4e02
    data off 5, flags=11<FIN,ACK> window 1000,    sum fee4, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2495, timestamp 577459161 sec 410000 usec, len 54
Ethernet level: dst host 08:00:20:00:6f:74,
    src host 02:07:01:00:8a:17, type 800
IP header: version 4, header len 5,
    service 0, len 28, id 95cd, off 0,
    ttl 18, protocol 6, sum 206, src 121e00d4,
    dst 80087803
TCP header: source port 14,    dst port 477, <seq,ack> 1d53103,108d4e02
    data off 5, flags=10<ACK> window 1000,    sum fee4, urgent 0
    TCP data length 0 (0x0) bytes

pktnum 2496, timestamp 577459161 sec 410000 usec, len 54
Ethernet level: dst host 02:07:01:00:8a:17,
    src host 08:00:20:00:6f:74, type 800
IP header: version 4, header len 5,
    service 0, len 28, id b700, off 0,
    ttl 1e, protocol 6, sum dad2, src 80087803,
    dst 121e00d4
TCP header: source port 477,    dst port 14, <seq,ack> 108d4e02,0
    data off 5, flags=4<RST> window 0,    sum 41c9, urgent 0
    TCP data length 0 (0x0) bytes

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 14:01:27 GMT
From:      rminnich@super.ORG (Ronald G Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial TCP/IP - all the same?

In article <80@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
>Now let _me_ list another reason why this is a Good Thing.  There are quite
>a few smart serial devices in the world these days.  Most of the time they
>don't use any of their smarts -- getting UNIX line editing into the serial
   Second the motion. Actually there have been quite a few 
systems over the years that support 'break sets' or 'tell me 
when you get this character or an overflow'. A few that come to mind:
HP3000-supported 'tell me when you get a buffer terminated by x'- with timeout
DG Eclipse with their smart ALM- supported programmable break sets.
Commodore Amiga- supports 'tell me when you get a buffer terminated by x'

   Louie Mammakos' port of the Karn code uses the amiga's ability
to suck up a bunch of characters 'til you get FRAME_END. This is 
a Good Thing. Saves the amiga OS a lot of work, and opens the 
possibility of letting a smart chip do the job.
   The 'two escape chars. in a row' seems like a good idea till
you have to handle all the weird exception conditions...
i had never really thought about why the way SLIP does it is 
such a good idea till now, but it sure is a good idea.
ron

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 14:45:09 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Less expensive network monitors

If you have less than 15K to spend, and already own a sufficiently IBM-
compatible PC or AT, both the Lanalyzer and the Sniffer are available in
do-it-yourself versions, where you get a card and software and install it
in your machine.  I believe the price range is 5K - 9K.  Performance is
comparable to the complete versions (which is necessarily lower than the
HP monitor, because the Sniffer uses an existing PC Ethernet interface
(3C505 in some versions, NP600 or other cards in others) to capture packets,
and Excelan uses a specialized relative of their EXOS205 card, with a
conventional LAN controller chip).

If you don't have 5K, but do have a PC (or AT or PS/2), and particularly
if you already own an Ethernet (or ProNET-10) card, you can either buy
LANWatch (from us, $1200 quantity 1), or get the MIT/CMU PC-IP distribution,
and use Netwatch (which is free).  Both packages put the Ethernet interface
in promiscuous mode, and capture as many of the passing packets as they can.

Netwatch only runs on the interfaces supported by PC-IP (NI5010, 3C500 and
P1300) which are all single-buffered, so you won't do too well on loaded
networks.  LANWatch supports lots of cards (including Proteon's P1340/1344
for monitoring 802.5 token rings), and many of these can do pretty well,
particularly in a fast AT or PS/2.  However, you are never going to capture
all the traffic on a heavily-loaded network.  LANWatch also has lots of
neat features that Netwatch doesn't have, and you get enough source to
change/enhance the packet parsing and filtering routines, as well as support.

James VanBokkelen
FTP Software Inc.
(617) 868-4878

PS: LANWatch has a help hot key instead of menus, for those in a hurry...

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 20:29:09 GMT
From:      rfg@nsc.nsc.com (Ron Guilmette)
To:        comp.protocols.tcp-ip
Subject:   Does TCP/IP "comform" to ISO/OSI?

I'm sitting here looking at a document that says that "The XYZ implementation
of TCP/IP comforms to the ISO/OSI reference model."

I'm not really a networking kinda guy so I don't know if that's a lie or not.

Is it?

I seem to recall having heard once that TCP/IP is NOT COMFORMANT with ISO/OSI.

-- 
Ron Guilmette
National SemiConductor
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 21:28:23 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Test suite for IP based systems


Is there an application program written to test IP based systems ?
Public domain code would be best, but I would consider paying for 
a good test suite. I recall that somebody was trying to start a 
firm for this purpose, but I never heard any hard facts about a test suite.

What I am looking for is something that I can put on a private ethernet
cable, do some minimal configuration (i.e give it some IP addresses and 
the applications that I want tested), and walk away
from. I would like to come back and have a printout saying "Yes the target
knows about redirects", "The target responds to the following Telnet
negotiations properly", "The target can FTP a file at xxxxx Bytes/Sec",etc.

I need this suite for regression testing of systems that I am
modifying. It is so time consuming to make sure 
nothing breaks as I add new features to my code. If such a system doesn't
exist, would anybody like to work with me to put one together?


Bill VerSteeg
Digital Communications Associates

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 22:52:35 GMT
From:      tait@versatc.UUCP (Tait Kirkham)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   RUNNING FTP IN BATCH MODE


		Does anyone out there know if it is possible to run ftp in a "batch" mode?

		Specifically,  I wish to be able to connect to a remote system and execute
		FTP commands from a batch file, rather than having to log in and type the
		commands in at the terminal. 

		Does anyone know if this is possible?   Currently I am running on a 286 PC,
		DOS, and Excelan software.

		I would appreciate any information you may have to offer.

		Thanks in advance

		Tait Kirkham
-- 
{pyramid,uunet}!versatc!tait     Tait Kirkham
Versatec, 2805 Bowers Avenue, Santa Clara, Ca. 95051 (408)988-2800x5070

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 88 23:58:58 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Layer 7 Protocol Converters, "Type of Service" Routing

Thanks everyone on the net for answering to my questions on STREAMS.
I wish you can go and see my country KOREA for 1988 summer Olympics.
As a matter of fact, Korea is the safest country like Israel.
So, don't worry, and please go and see.

I have another questions to someone on the network.

1. In order to migrate to OSI from DoD, I think, we need Layer 7 
   Protocol Converters to provide interoperability for coexistence.
   Is anybody working on, or has anybody worked on those Protocol 
   Converters before ?
   Please give me the name of the product.
  
2. I would like to know which product has already included 
   "Type of Service" routing.

Thanks again, please reply to me.

Kwang Sung
Sr. Software Engineer
ARIX Corp.
UUCP: ...!sun!aeras!smaug!kwang

 

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 00:27:57 GMT
From:      simpsong@ncoast.UUCP (Gregory R. Simpson @ The North Coast)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Interfacing HP Workstations to VMS (alternative methods/comments)


Hello,      

I'm interested in any first hand experience people might have with
interfacing Unix Based Workstations with a VMS Decnet network.
My specific situation is this:

My employer is considering the purchase of several HP Workstations.
However, for the purchase to be approved, they must interface cleanly
with our large installed base of VMS machines. My approaches toward
achieving this goal are:

1) TCP/IP interface... Probably the public domain CMU version.
2) NFS ... A commercial product
3) NS ... Hp's proprietary networking
4) NFS'ing the HP's to an Ultrix uVax and then running decnet between
   the uVax and the Vax Clusters...

How good are the above solutions? Would someone on an HP be able to 
easily spool jobs to a printer on a VMS machine using one of the above
approaches? Do you know of a better approach to achieving a high
level of connectivity? Any and all comments are appreciated. Please
mail results to me, and I will summarize if interest warrants it.

I prefer mail to the address shown below, although other addresses
are acceptable.

Thanks for any insight,

Greg    (Prefered e-mail address: simpsong%ltd2.decnet@ge-crd.arpa)


-- 
---
      Gregory R. Simpson       

Prefered  Internet: SIMPSONG%LTD2.decnet@ge-crd.arpa
or  
Alternate Internet: necntc!ncoast!simpsong@harvard.HARVARD.EDU

UUCP: <BACKBONE>!cbosgd!ncoast!simpsong
UUCP: {ames,mit-eddie,harvard,talcott}!necntc!ncoast!simpsong

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 00:58:46 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Friendliness vs performance

For Dave Crocker.

I would recast the question more in terms of capacity/throughput
traded off against robustness/fault tolerance/survivability.  Fair?

Most users tend to underestimate the real fault tolerance needs.
Once a network is put in place, it attracts applications like ants
to a picnic.  Before you can spell TCP/IP, the network has become
so critical that it's failure becomes intolerable.  I'm familiar
with a few horror stories like one about a bank that lost its 
funds transfer net for several hours.  The interest charges on the
cash it had to borrow to keep afloat ranged into 8 figures.

I have three very clear requirements where workstations and sensors
on a LAN is clearly the best way to go.  In all three cases, network
loading is very modest -- one ridiculously so: in terms of dozens
of bytes per day [!!].  But fault tolerance -- immunity against either
damage or component failure -- is vital to all three.

The curious technological development is that in the LAN world,
this isn't a trade off.  The only fault tolerant LAN architecture
out there readily available is doubly linked rings.  Discounting
Proteon's proprietary products, this leaves FDDI -- somewhat
higher performance than ether...

Fault tolerance is a lot like paychecks -- most of us rather take
them for granted.  They come every couple weeks -- especially for
us folks whose paychecks are provided by the taxpayers.  And like
LAN service -- expected to be there when we want to use it.  Watch
the fracas when your taken for granted paycheck or LAN fails.
I'd suggest a caveat for a vendor: fault tolerance may not gain
you lots of customers, but lack of it can lose a bunch.

Rex Buddenberg

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 10:39:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Friendliness vs. Performance
It is quite heartening to have honest-to-goodness customers demanding
robustness features.  In a perhaps-overly-cautious attempt to avoid
getting commercial in the discussion, I did not mention in my previous
note that our VMS product was one of the -- maybe even THE -- first to
be shipped to customers with Van & Co.'s congestion/slow-line features
and the next releases of our Streams and DOS products will contain them.
In other words, folks, please don't take my previous comments as suggesting
that the robustness features should not be included.

My concern was that the absolute assumption of its requirement be tempered
somewhat by looking at actual customer requirements; in some percentage of
cases, reasonable robustness and superb performance are more important
than superb robustness and reasonable performance.

Please note that standard implementations of TCP, using old-style congestion
and retransmission algorithms, are significantly robust.  In fact, we probably
are missing the boat by using the term to refer to the recent improvements...

The new capabilities do not alter data-loss with respect to the user.  They
alter packet-loss on the net, thereby reducing retransmission requirements.
With or without the new features, users will get equivalent data transfer
integrity at the receiving application.  With the new code, however, successful
COMPLETION of the transfer may be different.  (I.e., if you get the bits, they
will be correct.)

In effect, I was going creating an artificial constraint, much like asking a
person who they would save, if a parent and a spouse were drowning and they
could save only one.  On the other hand, there are limited development
resources and prioritizing customer requirements is essential.  Just because
all you knowledgeable, demanding networkers have the priorities set one
way -- which I agree with as someone who has suffered with Internet
performance -- does not mean that it is correct for the masses.  Long-term,
it IS correct, since they will all be part of a global internet and will
be subject to the phenomena that the new algorithms address.  However,
short-term, many of those networkers are isolated.

Dave

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 06:07:28 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Saying that something conforms to the OSI reference model is
essentially meaningless, so yes, TCP/IP does conform.  The reference
model is the basic conceptual layering.  You can use those layers to
analyze just about any protocol suite.  What you're thinking of is the
ISO protocol suite.  That's a specific set of protocols, and TCP/IP
doesn't follow it.  As far as I can tell, vendor statements that their
(non-ISO) protocol follows the OSI reference model is almost entirely
hype.  At best it means that the design is close enough to ISO that
eventual migration to the ISO protocols will be easier than with a
protocol suite that is very different in philosophy.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Aug 88 11:57:06 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   named vs. bind
SunOS4.0 documents the named daemon as providing internet domain name
server capability.  I have seen references on the net to porting bind
to SunOS4.0 to provide the same capability.  What are the differences
in named and bind?

Mike Rackley
Mississippi State University
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 1988 11:59-EDT
From:      CLYNN@G.BBN.COM
To:        steve@GRINCH.UMIACS.UMD.EDU
Cc:        paul@UXC.CSO.UIUC.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Interlan drops a byte?
Steve,
	It looks like another instance of the "have to retransmit a
FIN, so better subtract one from the sequence #" bug. Note that the
response (maybe to pktnum 2483, but possibly to an earlier packet
since the timestamps on 2483 and 2484 are identical) in pktnum 2484
was to ack 1d52f72. Thus the receiver has already received the data
being retransmitted in pktnums 2485, 2487 and 2489.
    [Clearly useless retransmissions -- maybe (the timestamps are all
    very close) an instance of the "retransmit all unacked data on a
    retransmission timeout" algorithm, or (the timestamps are not
    exactly equal) a "retransmit on ack before updating/processing
    send-left & processing the retransmit queue" design deficiency].
It would have been nice if the trace began earlier, say on the first
transmission of the packet containing sequence number 1d53100; was
a FIN sent at the "same" time?
    [Note [fnord sends its fin, with seq  # 108d4e02] you mean 108d4e01.
    Also, notice that in pktnum  2492, a FIN is being  (re)transmitted at
    a different sequence number, 1d53102, than it was in pktnum 2489,
    1d53101 = 1d52f71+190.]

Charlie
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 10:22:44 GMT
From:      rcdswal@dutrun.UUCP (Guus van der Wal)
To:        comp.protocols.tcp-ip
Subject:   KA9Q with MOCOM NI5010

This must have been asked many times before, but I began to
use Ethernet only recently.
I have a MICOM interlan NI5010 ethernet adapter in my IBM pc/at.
I also have Phil Karn's KA9Q TCP-IP software. The KA9Q docs
only talk about the 3COM 3C500 ethernet card.
 
Is there anybody out ther who has (made) KA9Q working with MICOM ??
Thanks in advance
                          Guus
-- 
Guus van der Wal
Computing Centre Technical University Delft
USEnet: rcdswal@dutrun
BITnet: rcdswal@hdetud1

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 12:51:00 GMT
From:      monty@hcx1.SSD.HARRIS.COM
To:        comp.protocols.tcp-ip
Subject:   Re: BLAST?


There is a product called BLAST (and BLAST II) sold by Communications
Research Group (800-242-5278 or 504-923-0888). It is an asynchronous file
transfer package akin to XMODEM and Kermit. Their literature claims it is far
more robust ("error-free" read error correction) and higher performance than
either of the above. It is full duplex and uses a sliding window protocol and
one spot in their literature says it is X.25 and ISO compatible so maybe the
sliding window stuff is borrowed from X.25.

I don't think it has anything to do with TCP/IP at all although you could
probably run it over a Telnet or Rlogin connection.

Our company sells it on our Un*x boxes, I personally have never used it so
cannot verify or deny its functionality or performance.

Hope this helps.

Monty.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Aug 88 17:22:52 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Ron Guilmette <nsc!rfg@HPLABS.HP.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Does TCP/IP "comform" to ISO/OSI?
It is my personal understanding (as an active participant in some of the ISO
groups) that the Reference Model was developed by ISO as a guide to how ISO
should think about the functional decomposition of service/protocol
standardization.  This is something of concern to ISO internally; not something
of external concern.  Thus there is no Conformance Statement clause in the
Reference Model standard, and (consequently) no objective way to evaluate the
claim that something does or doesn't "conform to the reference model".  Rather,
the Reference Model was made an International Standard so the world outside ISO
could see and understand (perhaps not agree with) the rules which were to
govern the development of standards for particular services and protocols by
ISO.

Regards,
Alex McKenzie
 
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 15:59:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  Interlan drops a byte?

Steve,
	It looks like another instance of the "have to retransmit a
FIN, so better subtract one from the sequence #" bug. Note that the
response (maybe to pktnum 2483, but possibly to an earlier packet
since the timestamps on 2483 and 2484 are identical) in pktnum 2484
was to ack 1d52f72. Thus the receiver has already received the data
being retransmitted in pktnums 2485, 2487 and 2489.
    [Clearly useless retransmissions -- maybe (the timestamps are all
    very close) an instance of the "retransmit all unacked data on a
    retransmission timeout" algorithm, or (the timestamps are not
    exactly equal) a "retransmit on ack before updating/processing
    send-left & processing the retransmit queue" design deficiency].
It would have been nice if the trace began earlier, say on the first
transmission of the packet containing sequence number 1d53100; was
a FIN sent at the "same" time?
    [Note [fnord sends its fin, with seq  # 108d4e02] you mean 108d4e01.
    Also, notice that in pktnum  2492, a FIN is being  (re)transmitted at
    a different sequence number, 1d53102, than it was in pktnum 2489,
    1d53101 = 1d52f71+190.]

Charlie

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 16:10:01 GMT
From:      jgh@root.co.uk (Jeremy G Harris)
To:        comp.protocols.tcp-ip
Subject:   Call queueing

The BSD listen(2) syscall (on a socket) provides for the specification
of a queue of pending connection requests.  So does the TLI T_LISTEN function.

What are the pros and cons of this functionality?  Is it merely a matter
of the cost of copying a protocol control block versus the cost of opening
and initialising one?  Or is there also a functional benefit?

    Jeremy.

-- 
Jeremy Harris			jgh@root.co.uk

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 20:17:00 EDT
From:      <enger@gburg.scc.com>
To:        "dcrocker" <dcrocker@twg.com>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Friendliness vs. Performance:  Performance can provide two WINS
I do not mean to diminish the importance of the Friendliness aspects of
Van's work.  Indeed, I am a user of WIN/TCP 3.2 and thus enjoy the benefits.

Van's header-prediction / code-streamlining work can however provide two
improvements for the user.  First, given the proper underlying network(s),
the user can see improvements in transfer speed.  More importantly, regardless
of the underlying network(s), the user will enjoy a REDUCTION in the amount 
of CPU utilization.  Thus, Van's work could be thought of as efficiency
improvements.  Everyone wants faster computers; Van has done something to help.



Van Jacobson for President!

Cheers,
Bob Enger

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 16:46:41 GMT
From:      john@uw-nsr.UUCP (John Sambrook)
To:        comp.protocols.tcp-ip
Subject:   Hanging FTP sessions

I've run into a problem with ftp(1) and would appreciate some advice.

I would like to move some files via anonymous FTP from one system to
another.  The systems in questions are Data General MV/10000 systems
running DG/UX 3.11 and DG/UX TCP/IP 2.02.

I am, of course, able to login to the remote system as user "anonymous",
password "guest".  If I then do an "ls" command I get a listing of the
three directories (bin, etc, pub) in ~ftp, as I expect.  So far, nothing
unusual.

Now, if I try to get a long list, with "ls -l", the connection seems to
hang.  Believe me, I have waited for periods of thirty minutes but have
never gotten past this hang condition.  I have the same problem if I 
try to copy the files I want from ~ftp/pub.  The connection is established
as expected, with the "PORT" and "Opening data connection" messages
printed on our end, but no data ever flows.  I have hash mark printing
on.

I have tried several different systems locally (including VMS, AOS/VS, 
4.3BSD) to fetch the files but I still have the hang condition.

I don't know if it is related, but when I do "stat" on our local ftp(1)
system it prints the page size of both "ftp-user" and "ftp-daemon" as
2048 bytes.  Is it possible that this is too long and that some type of
fragmentation is occuring?

Sorry I can't be more concrete; I don't have a lot of experience 
debugging TCP/IP problems, and even fewer tools for doing so.

Please feel free to send mail; I'll post a summary of responses.  If 
you would rather post a response that's fine too, though I doubt many
other people have this problem.

Thank you very much,

John Sambrook                        Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05           UUCP: uw-nsr!john
Seattle, Washington  98195               Dial: (206) 548-4386

-- 
John Sambrook                        Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05           UUCP: uw-nsr!john
Seattle, Washington  98195               Dial: (206) 548-4386

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 16:57:06 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   named vs. bind

SunOS4.0 documents the named daemon as providing internet domain name
server capability.  I have seen references on the net to porting bind
to SunOS4.0 to provide the same capability.  What are the differences
in named and bind?

Mike Rackley
Mississippi State University

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 17:14:17 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   4.3 networking bugs

The "FIN bit with incorrect sequence number" problem appeared in some
early 4.3 tapes.  There is a fix for it, which I think has been circulated
on comp.bugs.4bsd, and may be available for FTP from ucbarpa.  If not,
I have a copy (pub/fin_bug.43) on vax.ftp.com.  If you don't have source,
bitch at your vendor (the fix first circulated last summer).

Depending on the vintage of your 4.3, there are a number of other bugs
which appear in TCP output, or cause network-related crashes.  I know
of 9 of these, there may be more.

There is another bug, which I just saw:  The Van Jacobsen 4.3 code which
was made public domain a few months ago sends ICMP Source Quench messages
with random values in the "code" field.  I asked a friend with source, and
he says that the field is not initialized (it should always be 0).

James VanBokkelen
FTP Software Inc.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 17:39:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Friendliness vs. Performance

It is quite heartening to have honest-to-goodness customers demanding
robustness features.  In a perhaps-overly-cautious attempt to avoid
getting commercial in the discussion, I did not mention in my previous
note that our VMS product was one of the -- maybe even THE -- first to
be shipped to customers with Van & Co.'s congestion/slow-line features
and the next releases of our Streams and DOS products will contain them.
In other words, folks, please don't take my previous comments as suggesting
that the robustness features should not be included.

My concern was that the absolute assumption of its requirement be tempered
somewhat by looking at actual customer requirements; in some percentage of
cases, reasonable robustness and superb performance are more important
than superb robustness and reasonable performance.

Please note that standard implementations of TCP, using old-style congestion
and retransmission algorithms, are significantly robust.  In fact, we probably
are missing the boat by using the term to refer to the recent improvements...

The new capabilities do not alter data-loss with respect to the user.  They
alter packet-loss on the net, thereby reducing retransmission requirements.
With or without the new features, users will get equivalent data transfer
integrity at the receiving application.  With the new code, however, successful
COMPLETION of the transfer may be different.  (I.e., if you get the bits, they
will be correct.)

In effect, I was going creating an artificial constraint, much like asking a
person who they would save, if a parent and a spouse were drowning and they
could save only one.  On the other hand, there are limited development
resources and prioritizing customer requirements is essential.  Just because
all you knowledgeable, demanding networkers have the priorities set one
way -- which I agree with as someone who has suffered with Internet
performance -- does not mean that it is correct for the masses.  Long-term,
it IS correct, since they will all be part of a global internet and will
be subject to the phenomena that the new algorithms address.  However,
short-term, many of those networkers are isolated.

Dave

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 17:49:28 GMT
From:      edward@csvaxa.UUCP (Edward Wilkinson)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte? -- NOW: ethernet sniffer tools

In article <978@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes:
)In article <3210@cs.utexas.edu>, fletcher@cs.utexas.edu (Fletcher Mattox) writes:
)) 
)) If you look at a packet on the wire, say, with etherfind or tcpdump,
)) ...
)
)Say, these "ethernet sniffer" tools sound like very useful tools.
)Do these tools run on the UNIX machine, or on a PC?  Is source
)available? Tell me more about them.  Thanks.

Same here, please!   These   sound very useful,   especially for those
debugging ethernet programs. Post the info as it  would probably be of
use to many. Thanks in advance,

	Ed
-- 
Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ
uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward   DTE: 530163000005
Janet/Greybook: E.Wilkinson@nz.ac.massey      Phone: +64 63 69099 x8587
CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz    New Zealand = GMT+12

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 18:46:15 GMT
From:      kenk@algedi.UUCP (Ken Koster N7IPB)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Networking PC's with VMS , UNIX and Mac's running TOPS


  Sundstrand is in the process of choosing a network package that is 
capable of handling our diverse collection of systems. We currently
have a large number of MSDOS pc's (AT,XT,PS-2's,etc.) and 1 AT running
uPort UNIX (My machine) that are not networked. We also have a number
of VAX running VMS that are networked with DECNET and 30-40 MAC's that
are networked with TOPS.
  I have been asked to submit a list outlining the networking requirements
for the engineering department. I would appreciate comments from anyone who
has experience either setting up or using various products in this kind of
environment. All comments and suggestions would be greatly appreciated.

PLEASE - PLEASE - Email direct to me I WILL summerize for the net.

Thanks in advance.-- 
Ken Koster  			Work: uport SYSV   uunet!pilchuck!algedi!kenk
A lone Unix-pc 			Home: Amiga		   uunet!pilchuck!algedi!kkamie!kenk
in the MSDOS swamp		Packet Radio: 	   N7IPB@KE7OM	

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 21:22:52 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does TCP/IP "comform" to ISO/OSI?

It is my personal understanding (as an active participant in some of the ISO
groups) that the Reference Model was developed by ISO as a guide to how ISO
should think about the functional decomposition of service/protocol
standardization.  This is something of concern to ISO internally; not something
of external concern.  Thus there is no Conformance Statement clause in the
Reference Model standard, and (consequently) no objective way to evaluate the
claim that something does or doesn't "conform to the reference model".  Rather,
the Reference Model was made an International Standard so the world outside ISO
could see and understand (perhaps not agree with) the rules which were to
govern the development of standards for particular services and protocols by
ISO.

Regards,
Alex McKenzie
 

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 22:25:46 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Ron,  The OSI model is intended to be a reference model for discussing
and describing computer to computer communications.  It is an idealization
of how that communications should take place.  It was developed in the late 
70's.  It has a sevenlayer description that rather clearly describers
what should happen on each computer and with their communications devices.

TCP/IP when looked at from that model perspective has 4 or 5 layers distinctly
differentiated.  (Of ocurse, TCP/IP does all of the work, it just does it with
a different number of layers -- if you like cake, who cares if it is 5 or 7
layers?)

But, TCP/IP does not interoperate with the ISO implementations of OSI.
Saying that would be very "confusing".  I have seen IBM and DEC and Apple
documents that all compare their proprietary protocols to the OSI model
They all essentially say they conform to the OSI model.  They do, as
does TCP/IP.  It just does not mean much.  What matters is "can the two
computers send meaningful traffic back and forth?"

Dan
-------

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      25 Aug 88 22:39:11 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does TCP/IP "comform" to ISO/OSI?

The question is:

	Does OSI conform to ARM?
	
The answer is:

	No.
	
Phil Wood,  cpw@lanl.gov

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 00:17:00 GMT
From:      enger@GBURG.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Friendliness vs. Performance:  Performance can provide two WINS

I do not mean to diminish the importance of the Friendliness aspects of
Van's work.  Indeed, I am a user of WIN/TCP 3.2 and thus enjoy the benefits.

Van's header-prediction / code-streamlining work can however provide two
improvements for the user.  First, given the proper underlying network(s),
the user can see improvements in transfer speed.  More importantly, regardless
of the underlying network(s), the user will enjoy a REDUCTION in the amount 
of CPU utilization.  Thus, Van's work could be thought of as efficiency
improvements.  Everyone wants faster computers; Van has done something to help.



Van Jacobson for President!

Cheers,
Bob Enger

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 00:49:52 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  Friendliness vs. Performance

It's hard to make guesses as to what will sell.  But aside from
occasional tests in the PC-compatible area, there isn't a lot of
benchmarking hysteria in the TCP/IP world.  So I'd think vendors would
not be under the sort of pressure to get performance at all costs that
they are in some other markets.  From the point of view of a manager I
can tell you that I get lots of calls about inability to get mail
through to distant sites, and broken telnet connections.  By and large
our users do not carefully time their FTP's and call me when their
throughput is only 100 kbits/sec.  I have conducted various reviews of
Internet performance at the IETF meetings, where we asked an
assemblage of network managers what problems they were seeing.  Again,
it's clear that everytime somebody gets a "connection broken" message,
their network manager gets an irate call, but I don't see signs of
irate users demanding 20% more speed.  (Gross slowdowns are another
thing, of course.)

So if there were really a speed/robustness tradeoff, I'd strongly
recommend that vendors favor robustness.  But I'm not even convinced
that there is.  The only case I know of where using Van's
recommendations would slow you down is where by not using them you
manage to get more than your fair share of a gateway.  It's clear that
this isn't a stable situation: only one person can do this at a time,
and you can't guarantee that he will be able to do it consistently.
Furthermore, you're going to start seeing gateways that defend
themselves against this sort of thing.  This is not just a concern of
us wierdos on the Internet either.  There are lots of big corporate
networks being built, and they typically have lots of serial lines
carefully spec'ed to have no more bandwidth than necessary.

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Aug 88 09:37:06 PDT
From:      postel@venera.isi.edu
To:        vsi1!versatc!tait@ames.arc.nasa.gov
Cc:        tcp-ip@sri-nic.arpa
Subject:   RUNNING FTP IN BATCH MODE

See RFC-1068.

--jon.
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Aug 88 07:03:22 edt
From:      snorthc@nswc-g.ARPA
To:        tcp-ip@sri-nic.arpa, vsi1!versatc!tait@ames.arc.nasa.gov
Subject:   Re:  RUNNING FTP IN BATCH MODE
FTP SW has a script facility for their FTP that will allow you
to automate login/send/receives.

They also have drivers of the excelan card.

Now the only question is, did I beat JVB to the punch. :-)

	Stephen Northcutt (snorthc@nswc-g.arpa)

My only relationship with FTP SW is as a user of their products!
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Aug 88 18:39:29 -0700
From:      Keith McCloghrie <kzm@TWG.COM>
To:        tcp-ip@sri-nic.arpa
Cc:        kzm@TWG.COM
Subject:   Re: SGMP

There is some question about how long SGMP will be around.  It is
being replaced by SNMP, the specification for which has just been
published as RFC 1067.  Yesterday's official annoucement (from Jon 
Postel/Joyce Reynolds) stated :

  "This memo specifies a draft standard for the Internet community. 
  TCP/IP implementations in the Internet which are network manageable 
  are expected to adopt and implement this specification."

The concept of a "draft" standard is new to the Internet community,
but the latter sentence leaves no room for doubt about what conformant
TCP/IP vendors must do.

Note that whereas SGMP (as its name implies) was aimed at managing 
IP gateways, SNMP uses the set of variables (called the MIB - the
Management Information Base) specified by RFC-1065/1066.  This set
not only includes just about all the gateway-specific and common 
variables of SGMP, but also adds an initial set of host-specific 
variables (e.g. TCP and UDP objects).  As a result, many more 
vendors are already implementing SNMP for gateways and for hosts, 
than ever implemented SGMP.

Keith.
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 11:03:22 GMT
From:      snorthc@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  RUNNING FTP IN BATCH MODE

FTP SW has a script facility for their FTP that will allow you
to automate login/send/receives.

They also have drivers of the excelan card.

Now the only question is, did I beat JVB to the punch. :-)

	Stephen Northcutt (snorthc@nswc-g.arpa)

My only relationship with FTP SW is as a user of their products!

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 13:13:23 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Dan:

You were absolutely right when you stated, "...TCP/IP does not interoperate
with the ISO implementations of OSI.  Saying that would be very "confusing"."

It is confusing!  What *is* an ISO implementation of OSI.  OSI is merely a
architectural reference model.  It is not a protocol nor is it a protocol
suite.  I have written networking software ten (10) years ago that is con-
formant to the OSI model.  I doubt that you can find any software suite that
allows two (2) or more computer systems to exchange information that is not
conformant to the OSI model.  The model is a formalized statement of the 
logical process to establish a communication link and exchange information.

Now if you had said that IP/TCP is not interoperable with the ISO IP/T4
protocols or the Internet protocol suite is not interoperable with the
DECNet protocol suite.  That would be less "confusing".

Merton

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 14:00:31 GMT
From:      mankin@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  4.3 networking bugs

The unitialized code field for ICMP source quench goes back to
the original 4.3, Van's code just inherited it.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 14:32:58 GMT
From:      nancy@ftp.COM (Nancy Connor)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: RUNNING FTP IN BATCH MODE

You can execute FTP commands from a batch file on some systems.  I
don't know if Excelan's version of TCP/IP on the PC does this, but
some do.  In particular, FTP Software's PC/TCP product does this via
"take files".  Our FTP client will allow you to specify your login
name, password and the name of a file on the command line and will
then execute commands from the batch file you've specified.  If you
want more information on PC/TCP, send me mail, but I can't help with
Excelan's product.

	-Nancy Connor
	FTP Software
	...!harvard!ftp!nancy
	nancy@ftp.com

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 17:11:52 GMT
From:      auerbach@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP

My company, Epilogue Technology, is developing a set of tools for SNMP
(the sucessor to SGMP).

These include a complete SNMP agent which is both highly portable
and small.  The same tools could support an SNMP management station.

Target date for completion is September 15.

These tools have been updated to conform to RFC1065/1066/1067.

For further information, please contact Epilogue Technology at 415/594-1141.

			--karl--

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 18:01:27 GMT
From:      neil@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   References


Dear Sir/Madam:

I am looking for discussions/references that happened approximately 1 - 3 years
ago that debated the pros and cons of using a fixed Vs variable packet
length in high speed packet switches. In particular I am interested in 
their effect on switch to switch synchronization and also the implications
on queue/buffer sizes.

References or text including those debates would be greatly appreciated.

Neil Barrett
Washington University in Saint Louis
Computer and Communication Research Center
St. Louis, Mo 63130

Net Address:

neil@flora.wustl.edu
neil%flora.wustl.edu@uunet.uu.net
neil%flora.wustl.edu@cunyvm.cuny.edu

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 18:24:48 GMT
From:      andy@ocsmd.uucp (Andy Liwen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for big, big Blue


We are looking for _high speed_ connections to an IBM, big iron, type
main frame, via TCP/IP / EtherNet, from a SUN or like processor.  The
data we need to transfer must move faster than the 56Kb rate available
to the majority of "line" type connections we have found.  Either
vanilla ethernet or token-ring seem to be the fastest connections viable
for the big blue beast.

What we are seeking help on is software TCP/IP access from the big blue
iron and hardware alternatives.  We have only confirmed IBM (gag) token
ring availability on the blue end.  We would like to consider ethernet
alternatives for blue also.  

If any one has leads, connections, or products in this area, e-mail
replys would really be appreciated.  

//Andy Liwen


______________________________________________________________________________
uucp     : ..uunet!ocsmd!andy
bitnet   : andy%ocsmd@uunet.uu.net             snail : Online Computer Systems
internet : andy@ocsmd.uu.net                           20251 Century Blvd.

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 20:06:49 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

If there were a Supreme Court of Science (and if it hadn't been packed),
I'd be delighted to accept a case which held that the protocol sub-suite
consisting of TCP-or-UDP-over-IP is a more appropriate realization of
stated "OSI" "Reference Model" principles than is the protocol sub-suite
consisting of X.25-and-X.75, on a contingency fee basis.  However, since
as Charles Hedrick rightly observes, "TCP/IP" isn't in the set of
International Standards Organization-sanctioned protocols, and since
"conform to OSI" really ought to connote "interoperate with other protocols/
protocol interpeters in the ISO-sanctioned set", if there were a
Supreme Court of Semantics, I daresay I'd only be willing to attempt
to defend your XYZ Corp.'s blurb on a win-lose-or-draw flat fee basis--
and that a large enough one to be able to retire comfortably on.
(And if I won, I'd be sure that that court was packed.) 

Or, if legal metaphors are not to your taste, a fair way of answering
your question is, "Not in any practical sense, even though a sufficiently
subtle protocol theologian could probably have a lot of fun with it."

   cheers, map

P.S. In case the reference to the "ARM" in Phil Wood's message was
not familiar, it stands for the ARPANET Reference Model, which preexists
the ISO/OSI RM in fact, though not on paper (i.e., the ARM didn't get
written up [or down] until some years after it had been "invented" ...
and used).
-------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 20:07:34 GMT
From:      msa@clinet.FI (Markku Savela)
To:        comp.protocols.tcp-ip
Subject:   CMU TCP/IP and APOLLO ACCESS package


   Apollo have a package (ACCESS?), which makes the files on
the VMS visible on the Apollo work station (kind of NFS).  I
guess there is no hope of getting it work under CMU TCP/IP?
(Officially it seems to function only with Wollongong and
Excelan TCP/IP packages on the VMS).

   I was brave enough to try starting ACCESS on VAX/VMS running
CMU TCP/IP and was revarded by a nice "FATAL BUG CHECK ..." :-)
Never expected it to work, but some people win in lotteries, too...
--
Markku Savela, msa@clinet.fi

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 20:27:00 GMT
From:      msa@clinet.FI (Markku Savela)
To:        comp.protocols.tcp-ip
Subject:   CMU TCP/IP problem?


    This question would belong to some CMU TCP/IP mailing list,
but I cannot subscribe (I have to pay for received private mail).

    We have a CMU TCP/IP version 6.2 on VMS (micro VAX). There seems
to be something wrong in closing FTP file transfer connections. They
seem seem hang around in some WAIT-state for several seconds after
the transfer is completed.

    This causes problems with MSEND/MPUT -commands, if there are
several short files. IP ACP runs out of connections after 20 or
30 files...

    Perhaps I should order the next version 6.3? Or is this a
serious case of RTFM?. Being no wizard on TCP/IP, I installed
the package almost with all defaults...

    Another minor inconvenience is, that it looks like I couldn't
FTP files from VMS, unless user has directly access rights to the
files.  If access rights are given through ACL's, CMU TCP/IP does
not seem to notice and refuses the transfer (specifically: user
has been granted an "access identifier" and files have a specific
ACL entry for this identifier giving access to the owners).
Another case of RTFM? :-)
 ---
Markku Savela, msa@clinet.fi

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      26 Aug 88 21:32:34 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Test suite for IP based systems

Bill,  I know of no such wonderful regression test suite.  DCA has developed
(via a contractor) a whole set of tests for TCP/IP and the three applications
that does what you want, but it requires putting a lot of probe points in the
tested system.  The software is available from NBS now.

Dan
-------

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 88 01:39:29 GMT
From:      kzm@TWG.COM (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP


There is some question about how long SGMP will be around.  It is
being replaced by SNMP, the specification for which has just been
published as RFC 1067.  Yesterday's official annoucement (from Jon 
Postel/Joyce Reynolds) stated :

  "This memo specifies a draft standard for the Internet community. 
  TCP/IP implementations in the Internet which are network manageable 
  are expected to adopt and implement this specification."

The concept of a "draft" standard is new to the Internet community,
but the latter sentence leaves no room for doubt about what conformant
TCP/IP vendors must do.

Note that whereas SGMP (as its name implies) was aimed at managing 
IP gateways, SNMP uses the set of variables (called the MIB - the
Management Information Base) specified by RFC-1065/1066.  This set
not only includes just about all the gateway-specific and common 
variables of SGMP, but also adds an initial set of host-specific 
variables (e.g. TCP and UDP objects).  As a result, many more 
vendors are already implementing SNMP for gateways and for hosts, 
than ever implemented SGMP.

Keith.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Aug 88 19:35:37 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Martin Holland <mcvax!ukc!stc!idec!prlhp1!hollandm@UUNET.UU.NET>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Multiple TCP/IP servers on one Host.
     How can I add a second server without giving it a different name and
     internet number so the user will not have to try each server in turn to
     find a vacant port?

I could imagine designing a solution based on the fact that the MICOMs are
connected on an ethernet, and they could cooperate, using the same IP address
(and, by the way, the same ethernet address, preferably a 'multicast' one).
Address recognition in a particular one of the boxes would have to include
the IP protocol (TCP), and the TCP port (corresponding to the terminal port.)

I know of no such design being implemented, nor how you would invent one that
would work on a non-promiscuous net.

Perhaps you can trade your box in for one with more ports.

Good hunting,
Mike
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 88 16:42:06 GMT
From:      spock!a3bee2!omega!grzesiak@yale-bulldog.arpa  (John L Grzesiak)
To:        tcp-ip@sri-nic.arpa
Subject:   Net Help
Hello:
   I have an implementation I'd like to try and have little idea
 about how to go about it. I have a few UNIX boxes , two of which are
 CADMUS 9000's . I have Network cards and drivers for these systems.
 The cards I have are: 3com ethernet and Excelan EXOS 203 (a pair of each).

 What I'd like to know is:
      A) Which of these is a better install?
         (Ease of install , reliable , versatile ,etc)
      B) Can these cards be cheated and how?
         ( Can they be used point to point without tranceivers
            because all I need from them is remote disk mount capability)
      C) If these cards can't be cheated , where can I get thin ethernet
         tranceivers and equipment for these?

    Any help is appreciated - Thank you in advance.....

      John Grzesiak
      Omega Dynamics
      47 Spring Street
      Wallingford Ct 06492.    (203) 284-8530 voice
                               (203) 289-9300 work (9-5 Eastern)
                               (203) 284-3776 guest:guest (computer)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 88 21:55:22 GMT
From:      hedrick@aramis.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: named vs. bind

Named and bind are sort of the same thing.  Named is the name of the
name daemon program.  Bind seems to be the name of the package as a
whole, which includes named and the resolver.  However people
sometimes say they are bringing up bind when they mean named and visa
versa.  Sun includes bind as part of 4.0.  However there are reasons
why somebody might want to start with the current Berkeley source and
reinstall it:
  - they might want the very latest version of named
  - they might want to build the resolver into libc
Let me explain.

In case you're not familiar with the terms: the name daemon is a
program that keeps a database of all hosts known to your machine.
When other programs want to look up a name, they send a message to
your name daemon.  If it doesn't already know, the name daemon asks
other servers around the net, and eventually comes up with an answer,
which it sends back to your program.  The reason for sending all
requests through a single name daemon rather than having each program
talk to the network for itself is that this allows the name daemon to
build up a cache of known names, so that it normally doesn't have to
go out to the network.  Individual application programs typically
don't last very long, so any cache they built up wouldn't do much
good.  You need not run the name daemon on each machine.  You can put
it just on a few servers and point the other systems to them.

The resolver is simply a set of subroutines used to send questions to
the name daemon, and get back the responses.  The most commonly used
subroutine is a replacement for gethostbyname. It looks to the caller
like the gethostbyname supplied by Sun, but instead of looking things
up in the host table or YP, it asks the name daemon.

Now, for why somebody might want to port bind to Sun 4.0.  Sun
supplies named (possibly called in.named).  It's slightly out of date,
though there's an update package you can get from Sun with the newest
one.  Sun also supplies the resolver routines in a library
libresolv.a.  However that only helps you if you have source, since
you have to load your programs with -lresolv.  Sun's version of
telnet, ftp, etc., is not loaded with the resolver, so they will not
talk to named.  Their idea is that programs should use YP, and YP
should talk to named if the name isn't in the YP database.
Unfortunately, the interface from YP to named doesn't work.  There's
an update package you can get from Sun to fix that.  However even if
it worked, some of us don't like having to go through two different
daemons to look up names.  Also, the Berkeley resolver lets users
define their own abbreviations for host names, and if you put the
requests through YP, that mechanism doesn't work.  So some of us want
to rebuild the sharable library, /usr/lib/libc.so.1.x, so that it has
the resolver instead of the YP-based gethostbyname and gethostbyaddr.
Because of the way sharable libraries work, this will instantly fix
telnet, ftp, etc.  If you don't do much Arpanet traffic, it's probably
good enough to get the bind update package from Sun, which has the
newest named and the fixed version of ypserv that knows how to talk to
named.  However if you do a lot of network traffic, you'll want to
talk to your Sun representative and ask them to create a version of
libc with the resolver in it.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 88 22:32:15 GMT
From:      fletcher@cs.utexas.edu (Fletcher Mattox)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <3334@imag.imag.fr> pierre@imag.UUCP (Pierre LAFORGUE) writes:
>In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
>>Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface
>>drop a byte of data?  Well, that's what we're seeing.  
>>For example, if you
>>	% rsh remotehost cat 183_byte_file
>>and the remotehost is a 4.3/Interlan host, the rsh will fail.
>
 
>Your report is not very accurate;

Well, no.  The report is quite accurate.  Maybe it's not as complete
as it could have been, though.  :-)

	card:		Interlan BD-N11010, rev C, assy rev A, S.N A-103.
	transceiver:	Interlan NA1010
	driver:		@(#)if_de.c     7.1 (Berkeley) 6/5/86

It does appear that nobody else has seen this, so I'm still a little
puzzled.  Someone did mention that Interlan shipped some bad cards
about five years ago which had a similar problem.  Our card is
at least that old.  Anyway, I've quite worrying about it and just
replaced it with a DEUNA, since we have plenty of those.

Thanks to all who responded.

Fletcher

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      27 Aug 88 23:35:37 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.


     How can I add a second server without giving it a different name and
     internet number so the user will not have to try each server in turn to
     find a vacant port?

I could imagine designing a solution based on the fact that the MICOMs are
connected on an ethernet, and they could cooperate, using the same IP address
(and, by the way, the same ethernet address, preferably a 'multicast' one).
Address recognition in a particular one of the boxes would have to include
the IP protocol (TCP), and the TCP port (corresponding to the terminal port.)

I know of no such design being implemented, nor how you would invent one that
would work on a non-promiscuous net.

Perhaps you can trade your box in for one with more ports.

Good hunting,
Mike

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 03:45:59 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

jgh@root.co.uk asked about why listen(2) allows a queue of pending
connection requests.

Under the BSD networking model, when you want to listen() for a
connection, you first get a socket and then listen() on it. When a
connection is opened, you do an accept() (which gets you a new socket)
to actually get ahold of the connection. A server which wants to be
able to handle more than one connection at a time normally fork()s,
and the child process does the actual work while the parent goes back
to listen()ing.

If you don't allow a queue of pending requests, then from the time
when the listen() completes to the time when the server issues a new
listen(), there is no one listening. Any incoming requests will then
get a reset. The window of time is probably pretty small, on the order
of milliseconds, but you want it to be 0. So you need listen() to be
able to handle more than one incoming request. And you have to tell
listen() how many to handle so that the kernel can allocate
appropriate resources.
				- john romkey

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 03:48:54 GMT
From:      aglew%vger@XENURUS.GOULD.COM (Andy-Krazy-Glew)
To:        comp.protocols.tcp-ip
Subject:   SGMP

..> Software for SGMP monitoring

My wife wrote some stuff to collect statistics from SGMP gateways
working for the University of Illinois' CSO. I'm forwarding your note
to her, and you can send her email at irvan@uxc.cso.uiuc.edu.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have nameserver
    aglew@gswd-vms.gould.com    - if you don't
    aglew@gswd-vms.arpa 	- if you use DoD hosttable
    aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 03:50:38 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <3237@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox)
 writes:
>	card:		Interlan BD-N11010, rev C, assy rev A, S.N A-103.
>	transceiver:	Interlan NA1010
>	driver:		@(#)if_de.c     7.1 (Berkeley) 6/5/86

  Well, I think you're going to have an enormous amount of difficulty
trying to use if_de.c with your Interlan.  Why don't you try if_il.c?
And as someone mentioned earlier, you should grab the latest copy of that
driver since there were some significant bugs in the copy distributed
with 4.3BSD.

Casey

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 06:48:11 GMT
From:      sung@june.cs.washington.edu (Sung Kwon Chung)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: RUNNING FTP IN BATCH MODE

Here are two quick solutions to do batch-mode ftp.  They are written in
shell script, that means they are of no use for some of you who don't have
the shell, sorry.

The first one (ftp1.sh) is for simple ftp'ing.  It works fine for small number
of files.  The limit depends on the command buffer size of `mget' and some 
other factors unknow to me :-)  Is is used like,
	% ftp1.sh host pub a b c d e f g
to get file a, b, ..., g on host:pub.

The second one (doftp) is a bit more complicated, but versatile (and
extensible if you want). doftp uses other two shell scripts (ftp.sh and 
waitfor). It requires a file which contains the names of the files to be
ftp'ed.  Each line in the file contains one file name.  If `files.list'
contains wanted file names on host:pub,
	% doftp host pub files.list
will transfer all of them (of course, if everything goes right).
I used it to bring over 70 odd (irregularly selected) files from
an archive site.

To use them, extract the scripts to their names and do "chmod +x" them.
Please see the notes at the end of this message before trying them.
========================= ftp1.sh =========================
#!/bin/sh
#
# simple ftp 
# Usage: ftp1.sh host direcrory file1 file2 file3 .....
#
host=$1; directory=$2; shift; shift;
ftp -n -i $host << ___EOF___
user anonymous guest
cd $directory
mget $*
bye
___EOF___
exit $?
------------------------------------------------------------


The following three files are for the `doftp'.
========================= doftp =========================
#!/bin/sh
# Usage: doftp host directory namelistfile
# needs ftp.sh and waitfor
# Set up the pipes and temp files, and invoke ftp and its command feeder
#     ftp-out$$ : conversation during the job, feed-back to ftp.sh
#     ftp-log$$ : just for logging the commands
#	sung@cs.washinton.edu, 8/22/88
if test "$#" != "3"
then
    echo "doftp host directory namelistfile" 1>&2
    exit 1
fi

oldmask=`umask`		#
umask 077 		# if we need to make the conversation unreadable 
cat >ftp-out$$ </dev/null
cat >ftp-log$$ </dev/null
umask $oldmask

( ftp.sh  $2 $3  <ftp-out$$) |
                     tee ftp-log$$ | 
                                    ( ftp -v -n $1  >ftp-out$$ 2>&1 )
------------------------------------------------------------
========================= ftp.sh =========================
#!/bin/sh
# ftp.sh: ftp command feeder
#
# Uage: (sleep 1; ftp.sh dir namelistfile <ftp-out) |
#					 (ftp -v -n host-name >ftp-out) 
# See `doftp' and `waitfor'
#	sung@cs.washington.edu, 8/22/88

if test "$#" != "2" 
then
	echo " Uage: (sleep 1; ftp.sh dir namelistfile <ftp-out) | (ftp -v -n host-name >ftp-out)" 1>&2
	exit 2
fi

echo "user anonymous guest"		# login
result=`waitfor "230"`			# okay?
if test "$result" = "ERROR"
 then exit 1
fi

echo "cd $1"
result=`waitfor "250"`			# 250 CWD successful
if test "$result" = "ERROR"
 then exit 1
fi

# other FTP commands here, if needed

for f in `cat $2`		# main loop
do
   destName=$f	# file name change may be used here.  a:b.c --> a-b.c
   if test ! -f $destName	# get it, only when it is not there
   then
      echo "get $f $destName"
      result=`waitfor "226"`	# 226 Transfer complete
      case "$result" in
      "OK") echo "got $f" 1>&2 ;;
      "ERROR") echo "failed getting $f, abort the job" 1>&2;
               exit 1;;
      # other cases may need to be considered here
      esac
   fi
done
exit 0
------------------------------------------------------------
========================= waitfor ==========================
#!/bin/sh
# Usage: result=`waitfor string`
#    wait for given string from std input while monitoring error messages
#    Usually, `string' is an expected message number (e.g., 250).  It
#    detects 5xx error messages.
#	sung@cs.washington.edu, 8/22/88
while true
do
  read aLine
  if  test "$aLine" != ""
  then
    case "$aLine" in
    "$1"*) echo "OK"; exit 0 ;;
    *'timed out'*) echo "ERROR"; exit 1 ;;	# timeed out message
    5*) echo "ERROR"; exit 1 ;;			# 5XX error msg
    *) ;
    esac
  else
   sleep 3
  fi
done
------------------------------------------------------------
The scripts are for anonymous login.  For non-anonymous login, you can
change the `user' command line. (Be sure to set proper file protection
in this case.) Or you can use .netrc file and auto-login feature.  In this
case, '-n' option is in `doftp' should be removed.

There is much room for improvement especially for error message handling,
and retrial in the case of partial fairlure.  So please feel free to
make further extensions or modifications as needed.

Hope this helps some of you.

Sung K. Chung                     |       sung@cs.washington.edu
Dept. of Computer Science, FR-35  | {decvax,ucbvax}!uw-beaver!uw-june!sung
University of Washington          |
Seattle, WA 98195                 |

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1988 18:59-EDT
From:      CERF@A.ISI.EDU
To:        craig@NNSC.NSF.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   SIGCOMM Membership
SIGCOMM also allows affiliate membership. If you are a member of
any of the AFIPS organizations, IEEE, etc., you can become an
affiliate member of SIGCOMM without necessarily being a member of ACM.

I don't have the dues information at hand, but it costs more that
way than if you are already a member of ACM, but possibly less if
you don't plan to become a member of ACM because you are already a
member of, say, IEEE Computer or Communication Societies.

I'll check the $ figures and post to TCP/IP.

Vint
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 15:14:41 GMT
From:      fletcher@cs.utexas.edu (Fletcher Mattox)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

>>	driver:		@(#)if_de.c     7.1 (Berkeley) 6/5/86

Um, make that:

	driver:		@(#)if_il.c     7.1 (Berkeley) 6/5/86

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 1988 22:55-EDT
From:      CERF@A.ISI.EDU
To:        nsc!rfg@HPLABS.HP.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?
Just about anything that is layered can be claimed to be conformant.
The TCP/IP protocols don't necessarily include all layers of OSI
(e.g., there isn't a distinct session or presentation layer, for
instance).

I don't think there is much advantage in conformance to the
reference model - the great advantages come from having a
set of compatible and interoperable protocols supported by
many vendors. This is certainly the case for the bulk of the
TCP/IP implementations and will presumably be the case, some day,
for many of the OSI implementations also.

Vint Cerf
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 22:59:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM Membership

SIGCOMM also allows affiliate membership. If you are a member of
any of the AFIPS organizations, IEEE, etc., you can become an
affiliate member of SIGCOMM without necessarily being a member of ACM.

I don't have the dues information at hand, but it costs more that
way than if you are already a member of ACM, but possibly less if
you don't plan to become a member of ACM because you are already a
member of, say, IEEE Computer or Communication Societies.

I'll check the $ figures and post to TCP/IP.

Vint

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      28 Aug 88 23:00:52 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <15566@shemp.CS.UCLA.EDU> (casey@cs.ucla.edu) I write:
>   Well, I think you're going to have an enormous amount of difficulty
> trying to use if_de.c with your Interlan.  Why don't you try if_il.c?
> And as someone mentioned earlier, you should grab the latest copy of that
> driver since there were some significant bugs in the copy distributed
> with 4.3BSD.
 
> From: Chris Torek <chris@gyre.umd.edu>
> Apparently Interlan makes a DEUNA-style board.  Also, the major bugs
> were in if_np.c, not if_il.c ...

  Opps!  I should know better too.  Thanks for the correction.

Casey

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 02:55:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Just about anything that is layered can be claimed to be conformant.
The TCP/IP protocols don't necessarily include all layers of OSI
(e.g., there isn't a distinct session or presentation layer, for
instance).

I don't think there is much advantage in conformance to the
reference model - the great advantages come from having a
set of compatible and interoperable protocols supported by
many vendors. This is certainly the case for the bulk of the
TCP/IP implementations and will presumably be the case, some day,
for many of the OSI implementations also.

Vint Cerf

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Aug 88 10:58:42 EDT
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   TDR function of Micom NI5210 card
Has anyone ever gotten the TDR function of the Micom NI5210 card to work?

I've tried it using both thinwire and transceiver connections, opens, shorts
and good connections (plus disconnected xcver cable) and the TDR status
returned is always    87FF

which is , ethernet OK.

Anyone have any ideas?

Brad Clements
bkc@omnigate.clarkson.edu
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 1988 11:18-EDT
From:      CLYNN@G.BBN.COM
To:        tcp-ip-request@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Call queueing
Jeremy,
	As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
	As with all implementations, tradeoffs have been made.  I feel that
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
    1) examining the IP-address identity of the caller before deciding
       ACKnowledge the SYN vs. send a RESET,
          What if X were to place a "collect" call to such an implementation
          and send 4K data; then the receiver process start up and decides
          it doesn't want to accept the call.  Who pays for the 4K bytes?
          (The receiver COULD make the 4K available to the appliaction.)
    2) checking its routing tables and applying administratively specified
       per IP-address source routing, etc.,
    3) selecting initialization parters based on IP-level parameters such as
       TOS and options, or
           Maybe local system has a method for setting the TCP MSS (which
           the spec says has to be in the SYN packet).           
    4) specifying initial TCP-level options, etc.

Charlie
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 08:35:20 GMT
From:      hulsebos@philmds.UUCP (Rob Hulsebos)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   ftp/rcp can't copy devices

When I use the 'ftp' or 'rcp' command, and want to copy a disk-partition
(accessed via /dev/rdsk/*) to the other end, both utilities
complain: "not a plain file".

Of course, the manual doesn't mention that only plain files can be
transferred. Does anybody know why ftp and rcp behave this way?

Suprisingly, copying _to_ a device is allowed. An ftp-command like
"put /unix /dev/null" works fine, and is a nice trick to test the overhead
incurred by the filesystem on the receiving end.

------------------------------------------------------------------------------
R.A. Hulsebos                                       ...!mcvax!philmds!hulsebos
Philips I&E Automation Modules                            phone: +31-40-785723
Building TQ-III-1, room 11
Eindhoven, The Netherlands                                # cc -O disclaimer.c
------------------------------------------------------------------------------

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Aug 88  14:28:19 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        ocsmd!andy@UUNET.UU.NET
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  TCP/IP for big, big Blue
Check out ACC, Advintech, Fibronics, and Network Solutions for TCP/IP
for IBM mainframes running the MVS and MVS/XA operating systems.  For
VM, your best bet is probably the IBM TCP/IP for VM package.  They all
should be listed in the SRI-NIC vendors guide.
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 14:11:50 GMT
From:      kdb@lts.UUCP (Kurt D. Baumann)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP under RTX on a PDP-11


Does anyone have any information where I might obtain a copy of
TCP/IP running under RTX on a pdp-11?  I have someone who is
interested getting a copy running on his pdp-11.  Thanks...

Please send mail to me concerning the above if you have any leads as
to where I might be able to find a RTX version of TCP/IP.

By the way, we did not know, that posting to what we thought
(wrongly it seems) was a usenet only group, that our message would
get put onto the arpanet.  Sorry about that, we had no intention of
using the arpanet as an advertising medium.  Please accept my
appologies about this.

Thanks!

Kurt Baumann
uunet!lts!kdb

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 14:58:42 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   TDR function of Micom NI5210 card

Has anyone ever gotten the TDR function of the Micom NI5210 card to work?

I've tried it using both thinwire and transceiver connections, opens, shorts
and good connections (plus disconnected xcver cable) and the TDR status
returned is always    87FF

which is , ethernet OK.

Anyone have any ideas?

Brad Clements
bkc@omnigate.clarkson.edu

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 15:18:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

Jeremy,
	As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
	As with all implementations, tradeoffs have been made.  I feel that
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
    1) examining the IP-address identity of the caller before deciding
       ACKnowledge the SYN vs. send a RESET,
          What if X were to place a "collect" call to such an implementation
          and send 4K data; then the receiver process start up and decides
          it doesn't want to accept the call.  Who pays for the 4K bytes?
          (The receiver COULD make the 4K available to the appliaction.)
    2) checking its routing tables and applying administratively specified
       per IP-address source routing, etc.,
    3) selecting initialization parters based on IP-level parameters such as
       TOS and options, or
           Maybe local system has a method for setting the TCP MSS (which
           the spec says has to be in the SYN packet).           
    4) specifying initial TCP-level options, etc.

Charlie

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 15:48:02 GMT
From:      dougm@violet.ICO.ISC.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

In reply to your message of 25 Aug 88 16:10:01 GMT
-------
> The BSD listen(2) syscall (on a socket) provides for the specification
> of a queue of pending connection requests.  So does the TLI T_LISTEN function.
 
> What are the pros and cons of this functionality?  Is it merely a matter
> of the cost of copying a protocol control block versus the cost of opening
> and initialising one?  Or is there also a functional benefit?

The reason you want to allow for queueing of incoming connection requests is
that you want to buffer them while an application is processing a previous
one.  The alternative is to reject the connections until the application is
ready again.  Even with minimal overhead tin getting the appliation started
there will be cases where multiple connection requests arrive back-to-back
from the network.  You don't want to reject these so you queue them until
there is time to properly respond.

In the BSD systems, the queued connection requests get accepted
automatically.  In the TLI mechanism, it is possible that the connection
request has not been responded to giving the application final say on
whether to accept or reject the request.

One minor clarification, the TLI indication to queue connection requests is
in the t_bind call and not the t_listen.  T_listen is not the same as the
socket listen.  t_listen waits for an incoming connection request and
returns that to the application.  The information in the connection request
is then given to the t_accept call if the connection is to be accepted or
the t_snddis call if the connection is to be rejected.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 17:57:35 GMT
From:      jja@tut.fi (Ahola Jari)
To:        comp.dcom.lans,comp.sys.hp,misc.wanted,comp.protocols.tcp-ip
Subject:   TCP/IP for HP 3000/935 and associated questions


Hello there,

	I'd like to hear comments from those of you who are familiar
	with the software (hardware?) from the Wollongong Group for
	the HP 3000 series, if such a thing even exists. The problem
	is that we should connect tens of HP's Vectra series PCs, a Sun
	workstation to serve the PCs and then the problem: we should also
	get the 3000/935 from HP connected to this mess (preferably via Sun).

	Question: Has the Wollongong group anything to offer (or some other
	party) to provide the following services between Sun/HP 3000 ?

	Regular TCP/IP services
	Access to HP's application software (databases etc) using TCP/IP
	Other Goodies

	Any information would be greatly appreciated.

-jja



-- 
Jari 'jja' Ahola	| Tampere University of Technology, CS dept.
Opiskelijankatu 16 A 12 | P.O. Box 527, 33101 Tampere, Finland
33720 Tampere 		| Tel (intl) 358 31 162708 (work)/358 31 174009 (home)
Finland. Puh. 931-174009| Net address: jja@tut (UUCP)  AHOLA@FINTUTA (BITNET)

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 18:24:23 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Looking for more complete FTP implementations

Here at Sirius Systems we have just about completed our new FTP server and
are looking for others with whom we might exchange files at the upcoming
Interop-88 show.  At the show we expect to have the following features:

Modes:		Stream, Block, and Compressed
Structure:	File and Record
Type:		ASCII and Image
Format:		Noprint, TELNET, and Control (ASA)

We are not going to do structure page since we do not run on
DECSystem-20's.  Neither are we going to support type EBCDIC since the
hosts speak ASCII.  We are also not going to implement the following FTP
commands since they would serve no function on our hosts:

	ALLO, ACCT, CDUP, SMNT

In addition to the above we plan to implement the ability to restart a
failed transfer from a checkpoint.  For those of you who care, we use
5120 octets (bytes) as our checkpoint interval (unless someone else can
give us a good reason to use some other value or formula). 

If you have an FTP that can do more than the minimum defined
implementation we would like to hear from you.  Thanks. 

Brian Lloyd
Sirius Systems, Inc.
P.O. Box 2202
Petersburg, VA 23804
(804) 733-7944
brian@wb6rqn.uucp
Share and enjoy!

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 18:28:19 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for big, big Blue

Check out ACC, Advintech, Fibronics, and Network Solutions for TCP/IP
for IBM mainframes running the MVS and MVS/XA operating systems.  For
VM, your best bet is probably the IBM TCP/IP for VM package.  They all
should be listed in the SRI-NIC vendors guide.

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Aug 88 00:30 EDT
From:      PMDF Mail Server <Postmaster%CC.UMONTREAL.CA@CORNELLC.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Your message could not be delivered to:

    WARD

Your message has been enqueued and undeliverable for 3 days.
The mail system will continue to try to deliver your message
for an additional 9 days.

The beginning of your message follows:

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      29 Aug 88 23:45:54 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TDR function of MICOM NI5210 card

PC/TCP's NI5210 driver implements the TDR function, and I've tested it,
so the hardware is there.  Check your code carefully against the Intel
handbook for the 82586.  I don't think it has anything to do with
jumpers on the card.

James VanBokkelen
FTP Software Inc.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 00:05:08 GMT
From:      chris@mimsy.UUCP (Chris Torek)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: ftp/rcp can't copy devices

In article <779@philmds.UUCP> hulsebos@philmds.UUCP (Rob Hulsebos) writes:
>When I use the 'ftp' or 'rcp' command, and want to copy a disk-partition
>(accessed via /dev/rdsk/*) to the other end, both utilities
>complain: "not a plain file".
>
>Of course, the manual doesn't mention that only plain files can be
>transferred. Does anybody know why ftp and rcp behave this way?

Both attempt to determine the size of the file before sending it.
(Only rcp's protocol actually requires this.)  There is no way to
find the size of a special file without reading it, and in the process
the data may vanish (e.g., reading /dev/tty or a socket).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 02:25:29 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   In search of resolver for EXCELAN under XENIX and/or DOS...

In search of a Domain Name Resolver for EXCELAN TCP/IP		8/29/88
I am in search of a domain name resolver (source preferred, binary ok)
for the Excelan TCP/IP under XENIX (8011-04) and/or for Excelan TCP/IP
for DOS (8051 or something like that).  A name Server would also be
necessary, but not required as we have a SUN and a VAX running named.

Excelan TCP/IP (for DOS and XENIX) is based on 4.1BSD sockets (yeach).
If anyone has or knows of any ports for Excelan TCP/IP, please let me
know directly via E-MAIL at "scottr@csc-lons.arpa".  I WILL summarize
to the net.

Thanks in advance,
------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 04:03:28 GMT
From:      dupuy@douglass.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: ftp/rcp can't copy devices


Actually, it is possible to copy from a device, using a somewhat obscurely
documented feature of ftp.  You can specify a shell command as the source or
destination of a tranfer - the command runs on the local machine in either
case.  An example which I used just a few weeks ago:

% ftp another_machine
				# password/login deleted
ftp> send "|dd if=/dev/rst8" somefile.tar
				# silly messages from dd and ftp deleted
ftp> bye
%

You don't need the quotes if the command is one word.  This can be quite useful
for spooling dumps to a remote machine which doesn't support /etc/rmt - a big
IBM mainframe with _lots_ of disk space is ideal.  By creating a ~/.netrc file,
you can even have ftp batch jobs to spool your dumps.

As Chris Torek noted, the rcp protocol requires that the size of the file be
known, which is not possible in general for devices.  There is no equivalent
feature (that I know of) in rcp to allow sending from programs.

@alex

-- 
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 14:27:03 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q with MOCOM NI5010

In article <362@dutrun.UUCP> rcdswal@dutrun.UUCP (Guus van der Wal) writes:

   I have a MICOM interlan NI5010 ethernet adapter in my IBM pc/at.
   I also have Phil Karn's KA9Q TCP-IP software. The KA9Q docs
   only talk about the 3COM 3C500 ethernet card.

   Is there anybody out ther who has (made) KA9Q working with MICOM ??

Ha!  Interesting that you should ask that question, since I have recently
ported Bill Doster's NI5010 driver from C (to be compiled in) to a packet
driver.  This is not tested, however.  You (and in fact, anyone who is
interested) can either debug it yourself or wait until I get a NI5010
loaned to me from another department, which may take as long as two weeks.
I'll mail a copy to anyone who's really hot to get a copy...
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Shuzan held out his short staff and said, "If you call this a short staff,
you oppose its reality.  If you do not call it a short staff, you ignore the
facts.  Now, what do you wish to call it?"

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 16:15:44 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

In article <12425583151.27.PADLIPSKY@A.ISI.EDU> 
>PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes:
>I'd be delighted to accept a case which held that the protocol sub-suite
>consisting of TCP-or-UDP-over-IP is a more appropriate realization of
>stated "OSI" "Reference Model" principles than is the protocol sub-suite
>consisting of X.25-and-X.75

Seems to me this argument of "OSI implies X.25 and X.75" is a little
obsolete.  In the US, I don't expect to have to run OSI protocols over
virtual circuit networks, but rather that future OSI-IP internetworks
will be "equivalent" to the Internet, that is, a connectionless,
datagram network.  In fact, I am looking forward to running OSI
applications, like directory service, on top of tcp/ip protocols.

Of course, in Europe (except UK) the situation is different.

	Kent England, Boston University

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 17:41:21 GMT
From:      keith@tarantula.spider.co.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.


In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how
to get several terminal servers acting in "milking machine" mode to the same
host, to appear as one to other nodes on the network. I could suggest
upgrading to a SpiderPort, which has 10 lines to the NTS100's 8, but I don't
think this is really a terribly helpful solution.

This is an interesting problem, and while there are a number of possible
approaches to solving which fit in with the TCP/IP archectiture, none are
completely satisfactory, particularly if the requirement is for a scheme
which is transparent to the incoming (Telnet client) caller.

One approach could be to use the Telnet Reconnection option (NIC 15391). Here
the connection would be established to a Telnet server which knows when
all the ports on one server were full, and could then tell the client
to try connecting to a different server on another Internet address. However,
this requires the Reconnection option to be implemented on all possible
clients. Since I have never heard of any implementations of this with TCP, I
suspect this approach is a non-starter. Has anyone used the Telnet
Reconnection option over TCP for this sort of thing anywhere ?

There is also an issue here of who does the redirect - should there be a
central server which everybody connects to intially, and which keeps track
of everyone's resources so it knows where to redirect to, or should one
server simply redirect to another when it knows it is full ? The issue
of who knows what ports are free is something which generally needs to be
addressed for various schemes like this. For example, the ARP-based scheme
proposed by Mike Brescia <brescia@park-street.bbn.com>.

Another way is to fudge name lookup in some way. If a name server could be
got at, it could return a different address in response to the same user
string depending on how loaded the telnet servers are. This is not very nice
as it blurs functional boundaries between name servers, and what one could
call "resource location servers". This suggests another approach, where the
client sends a request out to find out what server(s) have free ports, and
uses the information returned to decide who to actually connect to (cf 
BOOTP). Resource Location Protocol (RFC 887) might be a possibility here.

A cleaner scheme for exploiting the name lookup mechanism as a solution is
to have an alias-on-fail arrangement. For example if a given hostname fails,
prepend a "&" and try again. The host table would then look something like:

spport1		192.35.138.1
&spport1	192.35.138.2
spport2		192.35.138.3

The disadvantages with this are again it requires non-standard client
software, and the cumulative time-out delay could get quite large towards
the end of the list (eg. &&&spport1 ).

Clearly with all these schemes there is a trade-off between cleanness of
approach, and how transparent it is to existing hosts. If one approach could
be standardised on as best, then I think some progress towards solving
this problem might be made.

Keith Mitchell


Spider Systems Ltd.		keith@spider.co.uk
65 Bonnington Road		keith%spider@uk.ac.hw.cs
Edinburgh, Scotland		keith%spider.co.uk@uunet.uu.net
+44 31-554 9424			...!uunet!ukc!spider!keith

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:03:21 GMT
From:      tomc@oakhill.UUCP (Tom Cunningham)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   CMU TCP/IP and Micom NI1010A


From what I gather, CMU TCP/IP does not support the Micom NI1010A Ethernet
interface.  Has anyone modified the code so that it does?

Tom Cunningham  Motorola Inc.  Austin TX
uunet!mnetor!oakhill!tomc
cs.utexas.edu!oakhill!tomc
-- 
Tom Cunningham  Motorola Inc.  Austin TX
uunet!mnetor!oakhill!tomc
cs.utexas.edu!oakhill!tomc

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:12:35 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   NVLAP information


For informationon NVLAP, contact

John L. Donaldson
Manager, Laboratory Accreditation
National Institute of Standards and Technology  (formerly NBS)
Admin A527
Gaithersburg, MD 20899
(301) 975-4016


Ole
-------

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 20:52:34 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q with MOCOM NI5010

> Is there anybody out ther who has (made) KA9Q working with MICOM ??

I have recently added support for FTP Software's Packet Driver
interface. This allows the code to use any packet driver that follows
the spec. Several people have so far contributed drivers for the following
boards:

TRW PC-2000
NI5010
WD8003

and others are on the way (SLIP, 3C501). A major revision of the package
should be out in a month or so; watch for it.

Phil

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 21:16:56 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

> 	Does OSI conform to ARM?
> 	
> 	No.

And, of course, one might ask the question: "Do the 'OSI Protocols'
conform to TCP/IP?" The answer again, sadly, is also no.

But even if you limit the discussion to reference models, the "OSI
Model" is hopelessly out of date. By the time you delete the unnecessary
layers (e.g., Session), combine distinct layers that really shouldn't be
separate (e.g., Application and Presentation), create the sublayers
required by modern concepts like internetworking (the Internet and
Subnet Layer) and multiple access networks (e.g., the Media Access
Layer), about the only morsel you'd still have left from the original
OSI model is that "Layering is often a useful tool in building
networks".

Then when you add Postel and Cohen's paper showing how a fixed number of
layers is simply unworkable in the real world, what you finally end up
with looks remarkably like the ARPANET Reference Model (ARM).

But does ISO ever revise its preconceived ideas and admit its mistakes?
Of course not.  It just covers them over with even more paper and ad
hype.

"No Need for XYZ, Just TCP!"   --Seen on a British billboard

Phil

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 22:36:03 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet Options Commonly Supported

	I am trying to find a list of the most commonly supported
Telnet options that would be useful for a terminal server or other
implementation to support on the Internet.  I am not interested in
MILnet specific options, unless they are likely to be adopted in the
Internet. 

	Is this list reasonably complete and well defined?

	Original rfc854 characters supported:
	interrupt (^C)
	abort (^C, ^X?)
	hello (Are You There?)
	erase character (<BS> or <DEL>)
	erase line (^U)
	new line character(s) (<CR><LF> or <CR>)
	bell (^G)
	tab, vt, lf, ff

	Commonly supported options:
	binary mode
	echo control (remote and local, mostly remote)
	suppress Go Ahead (not needed for ansi-style terminals)
	status (confirm status of telnet options)
	terminal type character string
	telnet 3270 data streams (tn3270)
	

	I have glanced over rfc1053 and the X.3 terminal handling and
transmission control parameters look quite interesting, but I suspect
it's too early to expect anyone to have any implementations of this.
	Have I omitted any widely supported options or included any
widely unsupported options in the above list?
	Is there a document that goes into more detail summarizing the
state of telnet options as of a recent date?

	Kent England, Boston University
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 23:08:37 GMT
From:      BILLY@VENERA.ISI.EDU ("Billy Brackenridge")
To:        comp.protocols.tcp-ip
Subject:   Microsoft 3Comm MAC Spec available via FTP

I now have an on-line copy of the Microsoft / 3Comm Media ACcess
(MAC) protocol specification.

This specification is the Microsoft 3Comm proposed standard for low
level networking under MS-DOS and OS/2. If you make any kind of
network hardware for IBM-PC or AT machines or write transport layer
protocols, you should look at this specification.

This file can be obtained via FTP from VENERA.ISI.EDU with the
path name pub/mac.txt.  Log in with FTP user name ANONYMOUS and
password GUEST. cd to the directory pub and retrieve the file.

The file is 225K bytes long. No I won't mail it to you unless 
exceptional conditions warrant exceptional behavior.

This version is dated 5/14/88. There are minor changes since the last
version I distributed.

Feel free to copy this document. Microsoft has assured me they are
interested in the widest possible distribution.

In the past networking code for the PC has been incompatible. The
various TCP/IP packages have been unable to operate resident in a PC
with the commercial proprietary network packages. If this standard is
adopted by the industry, users should have a wider choice of
interoperating protocol stacks and network hardware.

I would like to assume that part of Microsoft's and 3Comm's
motivation for publishing this specification is to get feedback from
the network community. Unfortunately the specification has leaked out
slowly and in a form that appears to be "take it of leave it". There
have been many objections to portions of this specification. Like
"The Last Temptation of Christ" many of those who cry the loudest
haven't read or comprehended the specification. I have corresponded
with others actually attempting to implement this specification who
have serious reservations and suggestions for improvement.

John Romkey will be running a PC special interest group session at
Interop '88. Many people have expressed an interest in discussing
this specification at that session. Everyone with whom I have
corresponded has expressed an interest in seeing a Microsoft and/or
3Comm representative at Interop '88 who can answer technical
questions about this specification.
-------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      30 Aug 88 23:32:51 GMT
From:      auerbach@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: TDR function of MICOM NI5210 card

Recently I put together a driver for an Ether-board that uses the Intel
82586 controller.  As part of the software initialization I had it do
a TDR check.  It was useful for testing the cable, and more importantly,
the drop cable and connectors.

However, there were circumstances where the TDR check failed -- mainly
on broadband networks and over-extended Ethernets.

If you do the TDR it would probably be useful to add an option to bypass
the test for those nets on which it fails but not as a result of an error.

				--karl--

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 08:35:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Multiple TCP/IP servers on one host
You have a basic question to ask:  Is the solution to your problem constrained
to use existing mechanisms or do you have freedom to implement additional
capabilities?  If you must use only existing products, then you are unlikely
to find a solution.

In general, Keith Mitchell's set of alternative is reasonable, if you
can build your own mechanisms.  (There are some interesting problems
involved with having the different milking machines know about each other
and each other's availability, but most of this is surmountable.)

Probably the minimum amount of effort -- even having a minute chance of
working without any development -- is to use the ability of the Domain
Name Service to list multiple addresses for a host.  Here's how it goes:

1.  For management purposes, list each milking machine by a unique name.
    Then, you can access specific ones, when you need to.

2.  Choose a generic name, under which you list all of the milking machines'
    addresses.

3.  When you need to do an access, use the generic name to do a DNS lookup
    and get the list of addresses.

4.  Choose an address from the list.  If you want to attemp load-leveling,
    throw a random number, to select the first address.

    (Sorry, but true, empirically-derived load-leveling does not work
    without all of the inter-milking machine communication mentioned above.)

5.  Pray that the milking machine product sends a reasonable rejection when
    all of its lines are full.

6.  When receiving such an error, try the next address.

The reason that you may be able to use this scheme without software development
is that there may be some telnet implementations out there that do step 6
already.  Unfortunately, I doubt it.

Dave Crocker
The Wollongong Group

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 02:22:20 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   Sun netstat traffic for DECNet

Is there any experience using Sun network tools, traffic, netstat, etc to
monitor and diagnose DECNET or DEC LAT, DEC PCSA?  Do any of the Sun 
services know how to identify the DEC protos?

-- 
 suned1!efb@elroy.JPL.Nasa.Gov   sun!tsunami!suned1!efb   efbatey@NSWSES.ARPA
    Any statements / opinions made here are mine, alone, not those of the    
    United States, the DoD, the Navy, the Congress, the Judiciary, nor ...   

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:14:05 GMT
From:      messing@MCL.UNISYS.COM (Judy Messing)
To:        comp.protocols.tcp-ip
Subject:   Re: Test suite for IP based systems

Bill,
The DCA Upper Level Test System, the DCA system referred to by Dan Lynch, is 
available through NTIS (National Technical Information Service).  It does not 
require any tuning of your protocol implementation.  It does however 
require simple application programs (specifications for which are also
available from NTIS) which act as the upper level user of your protocol.
The Test System refers to this programs as remote drivers. Currently,
the Test System runs using Ultrix 1.1.  I believe DCA has plans to port
the system to other operating systems.

We developed this system for DCA and often used the test suites in regression
testing as we tried to ensure that adding new capabilities did not break
things that formerly worked. If you have further questions, I'll be glad
to answer them.

Judy Messing
Unisys

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:31:47 GMT
From:      hlg%columbia-pdn@ACC-SB-UNIX.ARPA (Howard Goodman acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   PING w/source route option


I am looking for a version of PING which supports the source-route option.
If anyone has such an animal, would they please respond to me directly.
The versions I am looking for run on a Vax 750/Unix and a 3B System V.
Thank you.
---------

Howard Goodman
hlg%columbia-pdn@acc-sb-unix.arpa

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 14:46:00 GMT
From:      watt-alan@yale.UUCP
To:        comp.protocols.tcp-ip
Subject:   ANNEX II Terminal Server Experiences?

From: "Alan S. Watt" <watt-alan>

I just received a technical blurb on the "ANNEX II" terminal server
by Encore Computer Corp.  What is especially interesting about it
is you can configure any number of the ports for SL/IP.  The blurb
doesn't mention whether it does proxy ARP, but does say it has
"Full support of 4.3 bsd TCP/IP including Subnets", and "Complete
implementaiton of IP routing".


Question:
	Does anyone out there have any experience using this machine
	with SL/IP, and if so would they share them, either by
	follow-up or E-mail?

Thanks in advance.

	- Alan S. Watt
	  High Speed Networking, Science and Engineering Computing Facility
	  Dunham 232; (203) 432-4243,4007
	  watt-alan@cs.yale.edu

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 15:00:21 GMT
From:      scott@h-three.UUCP (scott)
To:        comp.bugs.4bsd,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Interlan drops a byte?

In article <3210@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
>Has anybody else seen a 4.3BSD VAX with an Interlan Ethernet interface
>drop a byte of data?  Well, that's what we're seeing.  
 
I've seen Micom/Interlan Ethernet controllers drop bytes. I've seen
them loose a bit, left shifting subsequent data by a bit. Somehow, these
errors were not caught by any of their protocol error checking.

Micom/Interlan claims that fixes are/were in the works. BTW, this was
observed on a Multibus I board.

-- 
Scott H. Crenshaw			scott%h-three@uunet.uu.net
h-three Systems Corporation             uunet!h-three!scott
POB 12557				100 Park Drive Suite 204
Research Triangle Park, NC 27607	(919) 549-8334 

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 15:35:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP servers on one host

You have a basic question to ask:  Is the solution to your problem constrained
to use existing mechanisms or do you have freedom to implement additional
capabilities?  If you must use only existing products, then you are unlikely
to find a solution.

In general, Keith Mitchell's set of alternative is reasonable, if you
can build your own mechanisms.  (There are some interesting problems
involved with having the different milking machines know about each other
and each other's availability, but most of this is surmountable.)

Probably the minimum amount of effort -- even having a minute chance of
working without any development -- is to use the ability of the Domain
Name Service to list multiple addresses for a host.  Here's how it goes:

1.  For management purposes, list each milking machine by a unique name.
    Then, you can access specific ones, when you need to.

2.  Choose a generic name, under which you list all of the milking machines'
    addresses.

3.  When you need to do an access, use the generic name to do a DNS lookup
    and get the list of addresses.

4.  Choose an address from the list.  If you want to attemp load-leveling,
    throw a random number, to select the first address.

    (Sorry, but true, empirically-derived load-leveling does not work
    without all of the inter-milking machine communication mentioned above.)

5.  Pray that the milking machine product sends a reasonable rejection when
    all of its lines are full.

6.  When receiving such an error, try the next address.

The reason that you may be able to use this scheme without software development
is that there may be some telnet implementations out there that do step 6
already.  Unfortunately, I doubt it.

Dave Crocker
The Wollongong Group

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 16:55:26 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.

In article <16115.8808301546@brahma.cs.hw.ac.uk>
> keith@tarantula.spider.co.UK (Keith Mitchell) writes:
>
>In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how
>to get several terminal servers acting in "milking machine" mode to the same
>host, to appear as one to other nodes on the network. 
>
	There are actually two problems: How to assign multiple
rotaries (telco terminology) to one box and how to assign multiple
boxes to one rotary.  It seems to me the solutions to both problems are
related and require particular capabilities of both client and host
server telnet implementations.

>This is an interesting problem, and while there are a number of possible
>approaches to solving which fit in with the TCP/IP archectiture, none are
>completely satisfactory, particularly if the requirement is for a scheme
>which is transparent to the incoming (Telnet client) caller.
>
	Seems to me that name server lookup can handle this
transparently, so long as the resolver in the client telnet takes
reasonable actions on the response received.
>
>Another way is to fudge name lookup in some way. If a name server could be
>got at, it could return a different address in response to the same user
>string depending on how loaded the telnet servers are.

	This is the same situation as a multi-homed host and I believe
the name server is set up to handle this with multiple records for a
single host.  Just substitute the concept of "multi-box rotary" for
"multi-homed host".  Name servers return all addresses listed for a
given name.  The resolver on the telnet client would need to be smart
enough to try all returned names before giving up on the connection
request.  So the problem becomes one for the client (ie terminal)
server and not the host (ie, milking machine) server.  If the client
server simply tries the first address returned and drops others, then
this approach fails.

	The other situation is different.  The host server must be
able to associate a subset of its ports to one IP address, possibly
down to one IP address per port.  Then the client telnet requests
service by name and receives either the single IP address that the
host server will associate to, say, three serial ports, or it receives
three separate responses corresponding to the three separate ports of
that rotary.  In the first case, the client only has to try one
connection and the host server handles port contention itself.  The
second case is the same as the multi-box rotary problem above and the
client server must be able to try multiple addresses in sequence
before aborting the attempt and reporting back to the user.

	So it seems to me that the solution is partly in client telnet
(try all addresses in sequence) and partly in the host telnet
(associate one or more ports to one IP address for efficiency).

	Kent England, Boston University

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 18:24:24 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Kent England:

Just for the  record, it seems to ME that there's no connection whatsoever
between my observation that TCP/UDP-IP is philosophically closer to the
"Reference Model" than X.25-X.75 and "this argument of 'OSI implies X.25
and X.75'" you mention.  If anything, the observation is more reasonably
misconstruable as a suggestion that OSI precludes X.25-X.75 than that it
implies 'em, although it doesn't say that either.

Of more interest, however, is whether you'll actually be able to satisfy
your stated expectation that you won't "have to run OSI protocols over
virtual circuit networks " "[i]n the US":  As long as DDN and GOSIP mandate
X.25, neither ARPA nor ISO IP users will be able to avoid paying (in one or
more senses) for unasked-for subnet functionality, in the long haul, as it
were.  Are you, perhaps, counting on ISDN to save the day?  (For that
matter, does anybody out there know for sure whether ISDN, unlike X.25, WILL
offer datagram service, and, unlike X.75, dynamic/"real" alternate routing?)
If so, you'd be better advised to argue with the proprietors of DDN and
the propounders of GOSIP about the non-OSIness of X.25, not with me, since
the bold-face line in the middle of p.154 of _The Elements of Networking
Style_ (Prentice-Hall, 1985) proves that I haven't lumped OSI and X.25 for
several years--even if I'll never forgive the panacea pedlars who had
tricked me into lumping them previously.

   cheers, map
-------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      31 Aug 88 22:55:50 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Phil, you make me sad.  But now I will make you angry!

Neither you nor I are unbiased observers.  In as much as you have given
your slanted view (i.e., no need for session, presentation should be
application-specific, etc.), I might as well give my slanted views.

The problem with you TCP/IP extremists is that you only have one tool, a
hammer.  It's a nice stainless steel hammer which gets the job done
quite handily.  But it is still a hammer.  As such, every problem to you
guys looks like a nail.  (In fairness, OSI extremists are the same way).
Although at the lower layers, OSI (levels 3&4) is still quite silly at times;
at the upper layers, I think the TCP/IP community could learn quite a
few things.  Some of which you might even find useful.

I won't bother launching into an assault on TCP/IP at this point, for
two reasons: 1) you wouldn't appreciate it, and 2) I'm using it to get
things done today.

The problem is that you snipe at the parts you don't like, rather than
trying to appreciate the entire picture.  On the whole, OSI has a lot of
good points going for it, even though some of the actual parts are
pretty lousy.

/mtr

END OF DOCUMENT