The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 13:01:00 GMT
From:      CURT.ELLMANN@mail.admin.wisc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Wang VS & TCP/IP

to: digennar@umbc3.umbc.edu, tcp-ip@sri-nic.arpa

We have a large VS network as well as a large(r) ip network.  Presently
one of the VSes in our wang net is equipped with wang's tcp/ip product.
I will reserve comment on that, however ;-)  If someone is interested
let me know.

As far as WLOC/Ether cards, I am running a 3com with FTP software's
TCP/IP package as well as a WLOC card in my pc with no problems.

In fact, since both of the emulators (Wang's and FTP's ) are suspendable
(FTP's is a TSR type) switching between VS and IP hosts is most
painless.  Perhaps you are running into a configuration (interrupts etc)
problem with the two cards?

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 14:56:00 GMT
From:      dan@ccnysci.UUCP (Dan Schlitt)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Telnet problems with Bridge CS/1's

In article <7502@charlie.OZ> jgm@kokab.cc.deakin.OZ () writes:
:We have Bridge CS/1's and CS/200's running s/w version 20000 into
:Suns running SUNOS 4.0. The telnet client on the Bridge boxes
:passes a <CR><NUL> string (which is produced by the Suns as per
:the telnet protocol spec) to the terminal as is (i.e. without
:stripping the <NUL>). This upsets terminals which may use \015 as
:part of their cursor address sequence.
:
:Has anyone else seen this problem? Is there a fix for it? The
:Australian agents are mainly into XNS, and do not seem to
:understand the problem.
:
:John Moorfoot 		ARPA:	jgm%charlie.oz.au@uunet.uu.net
:			UUCP:	...!uunet!munnari!charlie.oz!jgm

We also have problems with Bridge telnet handling of <CR><NUL>.
On some versions of their software it is broken.  They know about it
but refuse to supply fixed software.  More recent versions are capable
of doing the "right thing".  It is configurable in case you want to do
the wrong thing.



-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@ccnysci                        City College of New York
dan@ccnysci.bitnet                 New York, NY 10031
                                   (212)690-6868

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 15:53:41 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI


*Indeed, conformance testing is quite secondary to these fields; perhaps
*we can agree on Laphroaig as a common presentation syntax.  I am continuing
*studies into the role of the MacAllen...

*howard@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
*(703) 883-2812 [W] (703) 998-5017 [H]
*DISCLAIMER:  Opinions expressed are not necessarily those of the Corporation
*for Open Systems, its members, or any standards body.


go with the feeling. the Spider Systems people always have "the frog"
at their hospitality suites. you would be amazed at the constructive
work that gets done when the workers are properly lubricated with 
"the frog".

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 15:59:23 GMT
From:      khj@ecsvax.UUCP (Kenneth H. Jacker)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Mac NCSA Telnet & 3B2/WIN Problem

** Hardware **
Mac II;  2MB;			| 3B2/500
Kinetics EtherPort II		|

** Software **
System 6.0.2			| System V
NCSA Telnet v2.2		| WIN/TCP v2.1

** Problem **
NCSA telnet's connect request to the 3B2 is "timing out",
eventually producing a "host or gateway not responding" error
message.


Our 3B2s are able to "telnet" and "ftp" among themselves.  We've
checked that the (thin) cables *are* connected/terminated
properly. Prior to the Mac's error dialog, packets (ARP?) are
being transmitted.


Please write to me if you have any ideas ...  Thanks!

-- 
Kenneth H. Jacker               Domain:   khj@uncecs.edu
Dept of Math Sciences           BITNET:   khj@ecsvax
Appalachian State Univ          UUCP:     ...!ecsvax!khj
Boone, NC  28608

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 16:26:20 GMT
From:      howard@cos.com (Howard C. Berkowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI



I am often asked by audiences new to OSI, "Why are there seven layers?"
The most accurate answer to this, of course, is "because there are."

[If I wanted to be REALLY accurate, I would comment that seven
layers are an arbitrary decomposition done long before any OSI
implementations; equally good cases could be made for five or
eleven, or other numbers.  Would the Bill of Rights be more
or less useful if the same material were covered in nine or
eleven Amendments].

Of course, the real question being asked is, "Do I need to know what
all seven layers do?"  Now, if the questioner is a typical MIS
manager or other end user, the answer is "no, only developers really
need to know."

Since this answer makes many people suspicious of Secret Mysteries,
I appeal to their experience.  Most MIS managers, while unfamiliar
with the esoteric theology of network architecture, are reasonably
familiar with Sin.

Audiences exhibit reasonably consistent behavior when asked to
consider the Seven Deadly Sins.  Approximately 75% of the audience,
asked to consider these sins, immediately thinks of Lust.

This is entirely appropriate to the OSI Reference Model, because
Lust is clearly the Physical Layer.  The mechanisms associated
with male and female connectors clearly are instantiations of 
Lust architecture.

In general, the rest of the audience (with key exceptions) has
thought of Avarice and Gluttony.  These, also, have their OSI
counterparts.  If one thinks of Avarice in a business context,
one thinks of The Bottom Line; OSI architects simply put the
Bottom Line on top, and named it Application.  One should know
what the Bottom Line is, even when it is on top.

Gluttony deals with Reaching Out and Touching, Ingesting, etc.
These are clearly functions of the Network and Transport
Layers (i.e., Network being associated with the adjacent course
of the meal, while Transport is more concerned with eventual
dessert), and all OSI users need to be nourished.

In any audience, however, there is always one (and usually
only one) who thinks of Sloth.  

Sloth is analogous to the Presentation Layer.  No one knows
exactly what Sloth is or even how to confess it (bless me, for
I have committed Sloth?  or, I have slothed...?).  Nevertheless,
it is necessary for theological completeness of the Sin Reference
Model. 
 
In like manner, no one really knows why presentation is there,
other than for theological completeness of the OSI Reference
Model.   MIS users may safely ignore it; only implementors in
the parishes need be concerned with it.   

-- 
howard@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [W] (703) 998-5017 [H]
DISCLAIMER:  Opinions expressed are not necessarily those of the Corporation
for Open Systems, its members, or any standards body.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 17:28:20 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Seeking advice on establishing a LARGE centralized mail system

We've been thinking of tackling this problem here at MIT.  Our initial
planning is as follows:

*  The full name of every member of the MIT community will be known to
   the mail hub.  Mail sent to someone's full name will result in:
	1) The mail is delivered if the name is unique and the person
	   has a mailbox 
	2) An error response is generated saying "[full name] does not
	   have an electronic mail address, please send mail to MIT
	   Room ..., Cambridge MA 02139"
	3) An error response is generated saying "[full name] is
	   ambiguous, please choose one:" followed by a list of people
	   giving the name, title, address, and a unique email
	   identifier.
	4) An error response saying "addressee unknown".
*  Every member of the MIT community will be given a unique
   identifier for email purposes.  For most active email users, this
   will be their login name.  For other people and those with name
   conflicts, it will be their initials and a number, similar to the
   NIC's whois database.

This information will be kept up-to-date by Moira, the Athena Service
Management System, and regularly updated on the mailhub.  Users will be
allowed to update some of their own information, and to become
unlisted if they want to.

Moira currently contains all of the necessary information for the
students here at MIT, only the staff and remaining faculty must be
added.  The primary development effort will be modifications to the
mail hub.
				-Mark Rosenstein
				MIT Project Athena Systems Development

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 17:46:16 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Security Problems in TCP/IP


	You may recall the thread of a discussion I started regarding
security on TCP/IP internets.  I think it was called "IP
authentication of hosts" or something similar.

	Well, Steve Bellovin of Bell Labs told me about an article he
had written and was soon publishing that I should read.  I did.  I
recommend it to your attention.

	It is in ACM Computer Communication Review Vol 19, No. 2,
April 1989 pg 32 available on your news stands now.  It is entitled
"Security Problems in the TCP/IP Protocol Suite".

	Steve covers these problem areas:

	TCP Sequence Number Prediction
	Source Routing
	RIP attacks
	EGP attacks
	ICMP based attacks
	The RFC 931 Authentication Server
	Information dissemination services (finger, e-mail, ...)
	DNS
	FTP
	Network Management
	Remote Booting
	snooping and spoofing on a LAN
	TFTP
	Privileged Ports

and comprehensive defenses based on authentication and encryption.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 18:19:43 GMT
From:      pearce@tycho.yerkes.uchicago.edu (Eric C. Pearce)
To:        comp.protocols.tcp-ip
Subject:   Re: Security Problems in TCP/IP


>	Well, Steve Bellovin of Bell Labs told me about an article he
>had written and was soon publishing that I should read.  I did.  I
>recommend it to your attention.
>
>	It is in ACM Computer Communication Review Vol 19, No. 2,
>April 1989 pg 32 available on your news stands now.  It is entitled
>"Security Problems in the TCP/IP Protocol Suite".

Does anybody know if this paper available on-line anywhere?
--

     - Ecp.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 20:10:56 GMT
From:      rnicovic@polyslo.CalPoly.EDU (Ralph Nicovich)
To:        comp.protocols.tcp-ip
Subject:   TELNET Buffering Woes



I have a buffering problem that I hope someone can help me with,
or perhaps point me in the right direction.

We have several systems running BSD 4.3 unix. A Pyramid is one
that I will use to illustrate the problem, however this occurs
on others. Also for purposes of example I will use the program
"cat" although this is not an exclusive problem of "cat", it is
just a simple example.

A user with a dumb terminal connected to a terminal server (in this
case a U.B. NIU-180) or with a PC connected directly to the Ethernet
TELNETs into the Pyramid which is connected to the Ethernet.
The user then "cat"s a large file to the screen, immediately tries to
abort with a control-c. The output keeps coming for a long time.

I have narrowed down the problem with a lan-analyser. The Pyramid
simply does not stop sending packets. It is my feeling that the "cat"
process has already sent all this data to "TELNET" and although
the control-c stops "cat" immediately, there is no way to flush the
buffers.

This is very disconcerting to the users who are use to a "rs-232"
connection. They don't wish to use "more" as it would not be applicable
in some other scenarios.

Does anyone out there have any Ideas or solutions, or perhaps this
is a "feature" of layered protocols ?
Perhaps a way of limiting the TCP segment size.

BTW- I do not administer the unix machine, only the network.

Ralph Nicovich
Network Engineering
Cal Poly State University, SLO

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 20:28:00 GMT
From:      CARDO@JVNCC.CSC.ORG ("Nicholas P. Cardo")
To:        comp.protocols.tcp-ip
Subject:   Working version of FTP needed.

Hi...

     We are currently running Wollongong's TCP/IP software on our VMS machines.
After several weeks of complaining I was informed that their version of ftp 
cannot transfer a non-structured file ( no records ) unless it is talking
to another VMS machine.  This of course is not very helpful since the files
we need to transfer need to get to a sun.

     The problem is that Wollongong's version uses RMS to open the file with a
variable length record.  This allows a two byte field for storing the record
length which now limits the length of the record.  What they should have done
was to use the QIO system service to extract the information.  Call it a
feature, call it a bug, call it poor implementation, call it poor coding...
whatever.  It still is a problem for us.

     Does anyone out there know of a version of ftp for VMS that does not
have this limitation.

Thanks in advance...

Nicholas P. Cardo

-----------------------------------------------------------------------------
              JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER
                     Systems Programmer, VMS Systems

Nicholas P. Cardo				tel:	(609) 520-2000
Internet: "cardo@jvnca.csc.org"	    	        Bitnet:	"cardo@jvncc"
Address:  665 College Road East, Princeton, NJ 08543
-----------------------------------------------------------------------------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 20:31:45 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re:  in re whoever complained about not fragmenting broadcasts

slevy@POINCARE.GEOM.UMN.EDU ("Stuart Levy") writes:
>> Its a host requirement that broadcasts not be fragmented!
>
>But what's the technical reason for requiring that?

I don't know the reasoning behind the prohibition in the Host
Requirements document, but think about what kinds of problems
fragmented broadcasts might cause.  If a fragment is lost at the
transmitter, for example, then every IP host on the cable has
reassembly buffer space tied up, until the TTL expires.

Also think about what one is trying to accomplish with huge
broadcasts.  Some broadcast protocols (e.g., rwhod) are simply a rotten
idea to start with, and so "my rwhod packets are too big" is not an
excuse.  Most appropriate uses of broadcasting fall into two
categories:  trying to locate something for which you don't know an
address, and trying to spread some information to all (or most) hosts
on the cable.  The former should never require large packets.

If you are stuck with an application that really does require
broadcasting large amounts of information (such as a routing table
protocol), then you are better off breaking the information into
packet-sized chunks at the application level, not the IP
(fragmentation) level.  This allows the receiving application to
compensate for lost packets (for example, to request retransmission,
and/or to combine packets from several transmissions); fragmentation
does not allow this, since the receiving application never sees the
partial data if a fragment is lost.

Note that what I say here about broadcasting probably applies as well
to multicasting.

-Jeff

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 20:37:37 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Security Problems in TCP/IP

In article <PEARCE.89May1131943@tycho.yerkes.uchicago.edu>, pearce@tycho.yerkes.uchicago.edu (Eric C. Pearce) writes:
> >	It is in ACM Computer Communication Review Vol 19, No. 2,
> >April 1989 pg 32 available on your news stands now.  It is entitled
> >"Security Problems in the TCP/IP Protocol Suite".
> 
> Does anybody know if this paper available on-line anywhere?

Given that the paper has been published, I tend to prefer that people
go to the original -- if I just wanted to send out copies, I'd post
all my musings to netnews.  (Actually, I do that as well....)  Journals
do exist for a reason, after all.  And I'll use this as an occasion
to plug ACM in general, and SIGCOMM in particular...

However -- if for some reason you can't get hold of the printed
copy, send me email and I'll mail you a PostScript version.  (Actually,
the PostScript version is the original; no pieces of mashed tree pulp
were ever sent by me to the editor, Craig Partridge.)  Or rather, I
will as soon as the routing tables here are a bit more stable (to say
nothing of more accurate); our move to an NSF regional network went
smoothly, but not perfectly....


		--Steve Bellovin
		smb@ulysses.att.com

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 21:20:44 GMT
From:      neeraj@matrix.UUCP (neeraj sangal)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   RFC 1001/1002 based Netbios


	We have recently implemented Netbios on TCP/IP according to
RFC1001 and RFC 1002.  The RFCs describe three type of nodes: B, P and M.
The operation of B nodes is limited to a single broadcast and they use
broadcasts for name service.

	In order to operate in a general internet and to minimize broadcast
activity on the network, the RFCs define P type nodes which use a name server
and a datagram distribution server. (M is a hybrid of P and B type nodes).

	All of the current implementations that we know of implement B type
nodes only.  Is there anyone on the network who has implemented these RFCs
completely?  We are interested in testing our P and M nodes against those
implementations.  Please mail all responses directly to me.


Neeraj Sangal
Matrix Computer Systems, Inc.
uunet!matrix!neeraj

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 22:22:57 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: human factors aspects of echo delay

I'm not sure where I picked up this figure (probably psychology readings
for a course or something similar), but as I remember, the basic "cycle
time" of conscious processing is about 1/20th of a second, i.e. events
occurring at 50ms intervals are greater can be perceived as separate
events, whereas events occurring at shorter intervals are perceived
as simultaneous, depending somewhat on what kinds of events are being
correlated.  For example, a video terminal running at 300 baud in
full duplex gives most people the illusion that the letters are appearing
as they type (66ms).  However, motor skills (such as tracking moving
objects) involve much more fine-grained timing (hmm... hardware buffers :-)?)
For example, animation at 60 or 120 frames/sec will look much smoother and
more "realistic" than at 30 frames/sec, even if there's no consciously
perceptible flicker...

Part of the point of this is that how fast the feedback needs to be depends
a lot on what you're feeding back.  Keystrokes can probably get by with
50-80ms.  Rubber-band lines need to be 15-30ms, and so on.

--
Amanda Walker
InterCon Systems Corporation
amanda@lts.UUCP / lts!amanda@uunet.uu.net

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 22:52:32 GMT
From:      subbu%hpindaw@HP-SDE.SDE.HP.COM (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   An IP Bug in 4.3 BSD.


The prespecified timestamp option of IP is supposed to be type 3 (as per
RFC 791) but is declared as 2 in 4.3 BSD!!! 

Or is it a typo in RFC 791? :-)

Am I missing something?

FIX:
---
In the file ip.h, change the line

#define IPOPT_TS_PRESPEC	2

to

#define IPOPT_TS_PRESPEC	3

and recompile the stuff.
--
-Subbu
email: {...hplabs!hpindlm!subbu}
voice: (408)447-2693

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 23:11:14 GMT
From:      ykluger@HAWK.ULOWELL.EDU (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   Test Suite for an IP router

Hi,

We are looking into writing a test suite for an IP router. It occurred
to me that such a program must have been written by somebody somewhere
(probably more than once). Does anybody know of something of that
nature that is available for public use?

What we need is a program that can run under UNIX, which provides some
way of control of the different tests to be run, and which tests IP
fragmentation, IP options, ICMP invocations, etc. (there is a lot more
ofcourse).

Thank you

Yoav Kluger.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 May 89 23:14:00 GMT
From:      wunder@HP-SDE.SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: vendor implementations


   I'm looking around for TCP/IP implementations for the following system
   and was wondering if anyone would care to share knowledge and/or
   experiences. The systems are H/P 1000, ...

Hewlett-Packard now sells FTP and Telnet for the HP 1000.  It is a
separate product from the NS Services (HP-proprietary stuff).  I think
that the plan is to include Telnet and FTP in the NS product for all
customers as part of release 5.2 in late 1989.  Supported systems
will get that update.  If you need it *now*, you can order ARPA/1000.

Here are the basics, from a information sheet that I have.  I'll mail
the whole thing to Chris VandenBerg, these are just the highlights for
any other HP 1000 users out there.

      ARPA/1000 provides basic multi-vendor networking for the HP1000, for
      users who don't need all the power of NS/1000 or who need additional
      services or links not currently in NS. It provides file transfer (FTP)
      and virtual terminal (TELNET), using TCP/IP over Ethernet and 802.3
      LANs. Address resolution using ARP and PROBE is provided.  It does NOT
      include SMTP, UDP, Berkeley Sockets, or Berkeley Services. It also does
      NOT work over X.25 or point-to-point links.

      The only required software will be release 5.1 of RTE-A, VC+, and
      LAN/1000 Link. You will need at least 1.5 Mb of RAM.

The product manager is Mike Cohen (Mike_Cohen%1b%hp6600@hp-sde.sde.hp.com).
If you need more info than your local field office can give you, contact
Mike.

Walter Underwood

PS: It has been great to see HP come around to TCP/IP during the last
four years.  When I started work here, HP had a TCP/IP transport with
proprietary services, and no (zero) products with the normal ARPA
services (Telnet, FTP, and SMTP).  Pretty grim.  Now we have products
or commitments for every computer we make (except for the HP-41
calulator).  The transport guys are implementing VJ TCP, we'll be
shipping a supported nameserver, sendmail/MX, and so on.  There is
more work to do, but it is really a tremendous turnaround in four
years.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 02:37:25 GMT
From:      jom@belltec.UUCP (Jerry Merlaine)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1101

I would like to store and retrieve the public X.25 vendor (Datex-P/
Tymnet/Telenet etc.) X.25 address, or the dial-in SL/IP phone number, 
or the PTP dial-in number of a particular host via the Domain Name System.

How can I do this via RFC1101?  The info retrieved would need the
X.25 address/phone# and some marker that says how to start up host numbers
and routing.  For example, POTS=415-555-1212,BOOTPSERV might mean that
I dial the number, we both start SL/IP, and I expect it to be my BOOTP server.
(Let's just ignore passwords for now...)  How would I get this string?

Thanks,
Jerry O. Merlaine
pacbell.com!belltec!jom

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 May 89 8:53:54 EDT
From:      Charles Lynn <clynn@BBN.COM>
To:        Ralph Nicovich <unmvax!polyslo!rnicovic@ucbvax.berkeley.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  TELNET Buffering Woes
There are sugestions in the soon-to-be Host Requirements RFC which
deal with this problem. Another technique which was implemented in
a telnet server was to provide a hook so that TCP knew the baud
rate of the user's terminal.  I.e., when the user said something
like "terminal speed 9600", the telnet server was notified by the
OS, and in turn notified TCP.  TCP then generated packets (er..
"segments") at the "right" rate. Maybe such techniques are now
covered by "slow start".
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 12:53:54 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

There are sugestions in the soon-to-be Host Requirements RFC which
deal with this problem. Another technique which was implemented in
a telnet server was to provide a hook so that TCP knew the baud
rate of the user's terminal.  I.e., when the user said something
like "terminal speed 9600", the telnet server was notified by the
OS, and in turn notified TCP.  TCP then generated packets (er..
"segments") at the "right" rate. Maybe such techniques are now
covered by "slow start".

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 15:26:53 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

> A user with a dumb terminal connected to a terminal server (in this
> case a U.B. NIU-180) or with a PC connected directly to the Ethernet
> TELNETs into the Pyramid which is connected to the Ethernet.
> The user then "cat"s a large file to the screen, immediately tries to
> abort with a control-c. The output keeps coming for a long time.

The problem here is not with the remote machine, but with the local
telnet implementation.  The way that things should work is:
	User types ^C
	Local telnet translates that to, and sends, IAC IP,
		and then sends IAC DO TIMING-MARK and begins to
		flush all output.
	Local telnet receives IAC WILL/WONT TIMING-MARK, and
		resumes terminal output.

The problem is that many telnet implementations are very dumb.  They
are not doing local recognition of the interrupt character, and thus
they don't know when to send the DO TIMING-MARK and start output flushing.

The 4.3 telnet has an option "localchars" which when enabled causes
telnet to do the above stated procedure.

			Dave Borman, dab@cray.com

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 15:43:50 GMT
From:      rnicovic@POLYSLO.CALPOLY.EDU (Ralph Nicovich)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

Dave,
I apreciate your responce about my buffering problems.
You seem to have the best insite of those that responded.

My terminal server (an ungerman -bass NIU card) is configurable
to understand special Telnet commands. i.e. I can set it up
so that when the user types a ^C the server will send a interupt
process with a "PUSH" or urgent flag. This is not to say that
the terminal server knows to stop output until it receives another
flag from the server.

I observe with a packet monitor that the INTERUPT PROCESS is sent
and data keeps coming (for miniutes). Would this be considered
normal ? Does the terminal client have to handle all this or
should the server function on the host at least flush a few characters ?

Ralph Nicovich
Cal Poly State University, SLO

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 15:51:50 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  in re whoever complained about not fragmenting broadcasts

Host requirement?  Am I missing something I've looked through the Host
Requirements doc of April 6, 89, the last I retrieved and I see no
prohibition on fragmented broadcasts (not that it isn't a bad idea).
I looked through the Internet layer especially the sections on
Fragmentation, reassembly and Broadcasts and I can't find it.

-Ron

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 16:09:24 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   ICMP_UNREACH_PORT

Whilst doing some load-testing of our in-house net, I noticed some
surprising behavior; I'd be interested in some expert comments.

First the configuration:  Several Sun 3's running SunOS 4.0.1,
connected by an UltraNet (our product, but basically irrelevant to the
question).

Next the situation:  We seemed to be having some troubles with the
checksum hardware on one of our cards (in a diskless Sun 3/140, to be
specific), resulting in excessive discarding of datagrams.  To test
it, I started up a process on another Sun which sent a steady stream
of 8K UDP datagrams to a random port on the 3/140.  Since I was
interested in datagrams tossed by the card rather than the SunOS
kernel, I did not bother having anybody do a "recvfrom" on the 3/140
(in other words, the datagrams would be tossed by the 3/140's UDP).
[By the way, the UltraNet MTU is larger than 8K, so these datagrams
are legal.]

Okay, the strangeness:  Looking at counters, I noticed that not only
did the 3/140 receive (say) 854 datagrams, it also SENT exactly 854
datagrams.  It didn't take too much detective work to figure out what
the outgoing datagrams were -- they were ICMP messages with Type 3,
Code 3: "Destination Port Unreachable".  My question is "Why?"

I realize this behavior is perfectly LEGAL (since the ICMP spec [RFC
792] says "If ... the IP module cannot deliver the datagram because
the ... process port is not active, the destination host may send a
destination unreachable message to the source host."), it just seemed
strange to see 4.3 BSD actually doing it.

First of all, I'm a great believer in the idea of "if something weird
happens, build a datagram describing it and launch it towards some
logging host, then forget it."  But if that host's logging program
isn't up, this is going to result in DOUBLE the network traffic (at
least in number of datagrams).  No great "overload" problem, of
course, but it does seem silly, particularly since (for UDP datagrams,
at least) the original sending host isn't really going to be able to
DO anything with the information.

And second, what is IP doing talking about ports anyway???  I mean,
ports are upper layer artifacts, no?  According to my trusty grep, the
word "port" does not even APPEAR in the IP spec (RFC 791)!  But then,
the ICMP spec DOES say "If ... the IP module cannot deliver the
datagram because the ... process PORT is not active" so  SOMEBODY sure
expects IP to be in the port business!  (The spec also mentions ports
in a couple of other places, but they don't seem to be particularly
relevant.)

Actually, what is happening in 4.3 BSD is that UDP is turning around
and causing its ICMP to send the ICMP_UNREACH_PORT message.  Nothing
illegal about this, of course, but it does get us back to the previous
question: why bother?  (The UDP action is in udp_usrreq.c and is
prefaced by the comment "don't send ICMP response for broadcast
packet" -- I would ask why EVER send it?!  Also I note that TCP does
not seem to ever send an ICMP_UNREACH_PORT.)

Anyway, any thoughts from all the IP/ICMP/BSD gurus out there?

  Wayne Hathaway            
  Ultra Network Technologies     domain: wayne@Ultra.COM
  101 Daggett Drive            Internet: ultra!wayne@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!wayne
  408-922-0100

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 17:51:38 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

> My terminal server (an ungerman -bass NIU card) is configurable
> to understand special Telnet commands. i.e. I can set it up
> so that when the user types a ^C the server will send a interupt
> process with a "PUSH" or urgent flag. This is not to say that
> the terminal server knows to stop output until it receives another
> flag from the server.
>
> I observe with a packet monitor that the INTERUPT PROCESS is sent
> and data keeps coming (for miniutes). Would this be considered
> normal ? Does the terminal client have to handle all this or
> should the server function on the host at least flush a few characters ?
>
> Ralph Nicovich
> Cal Poly State University, SLO


Let's take the simple case, a terminal connected to a machine, running
telnet to another machine.  When data is being sent from an application
through a telnet connection, there are several places where output can
be buffered:
	1) in the terminal driver on the server machine, waiting
	   for the telnet deamon to read it.
	2) In the telnet deamon itself
	3) In the kernel, on the socket queue for the telnet connection,
	   waiting to go out.
	4) On the client, in the kernel, on the socket queue, waiting
	   for the client telnet to read the data
	5) In the terminal output queue on the client.

Probably the most complete and quickest method of flushing data in a
TELNET stream would be:
	1. Client sends IAC IP, IAC DM, IAC AO, IAC DO TIMING-MARK.
	   The IAC DM is the Telnet "Synch", and is sent in urgent mode.
	   The IAC AO is sent just for good measure.
	2. Client begins to throw away output.  The terminal output queue
	   is flushed (#5 above), and we then continue reading from the
	   TCP connection and throwing away data (#4 above) scanning the
	   data looking for TELNET commands.
	3. Servers gets put into urgent mode, and starts flushing input,
	   looking for interesting commands, or end of urgent data.
	4. Server get IAC IP, and generates an interrupt.  The interrupt
	   should cause the operating system to flush the data in the
	   output queue of the terminal (#1 above).  The deamon should
	   toss any data it has read from the terminal but not processed
	   yet (#2 above), and toss any data that it has buffered up to
	   write to the socket, but has not written yet. (Also #2 above.
	   Flushing the output side could be tricky, because there may
	   be TELNET commands already imbedded in the output buffer that
	   we still need to send...)  Possibly the telnet deamon could
	   tell the kernel to toss any data that it has buffered up but
	   has not sent yet over the telnet connection, (#3 above) but
	   this would not be wise because you would lose any TELNET
	   commands that happened to be in that section of data.
	5. Server gets IAC DM, and goes out of urgent mode.
	6. Server gets IAC AO, and does most of the stuff already
	   mentiond in step 4.
	7. Server gets IAC DO TIMING-MARK, and sends IAC WILL/WONT
	   TIMING-MARK.
	8. Client goes into urgent mode, scanning for TELNET special
	   characters.  Since we are already throwing away data, this
	   doesn't really change anything.
	9. Client gets IAC DM, and goes out of urgent mode.  Client
	   still throws away output.
	10.Client gets IAC WILL/WONT TIMING-MARK and resumes normal
	   terminal output.

So, the bottom line is that the server side should flush any data
data buffered in #1 and part of #2 before it ever gets sent. You
can't do anything about #3, that data has to go across the telnet
connection.  Item #4 and #5 should be cleaned out by the client
side.

Hopefully this answers the questions about flushing the output
stream on a Telnet connection.

		-Dave Borman, dab@cray.com

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 18:26:35 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI

Nice metaphor ... BUT everybody knows why Presentation is there (where
everybody = all Old Network Boys, who, because they understand both Telnet
and how the NVT notion was used in FTP, readily grok doing virtualization/
devirtualization in a modular fashion, even if they don't think it should
be a mandatorily separate layer that mechanizes it [and given things like
the Common ASE, neither, apparently, do some key New Network Kids]).  The
real Mystery--mayhap the Sin Against the Holy Spirit (of Layering, i.e.)--
is still Session ... unless the story that "there were some guys left over
who needed a committee" is true, in which case Sloth, Avarice, Gluttony,
and probably others all apply.

    cheers, map
-------

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 19:43:27 GMT
From:      pvm@VENERA.ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1101

In general, the DNS philosophy for associating new forms of "host
addresses" with hosts names is to enter new data (in the form of RRs)
either with existing IN class information or in a new class.  For
example, the Chaos class was defined to use existing host names and a
new address format in Chaos class RRs.

For example, if we wanted to be able to look up phone numbers given host
names, we might define them as being carried in a TXT RR, or define a
new RR type of, say, PHONE, analogous to the A RR (these RRs would be
stored at the host name).  If we wanted to look up host names from a
phone number, we would need something like the IN-ADDR.ARPA tree (Which
we might be able to get along without, just as we get along without such
a directory in the real world).  From experience, there's a fair amount
of work involved in standardizing the data (e.g. include area code?,
international code?, extensions?), especially if you want an Internet
standard.

RFC 1101 doesn't specifically address (pardon me) this isssue, except to
provide an solution for a different problem and general thoughts.  RFC
1101 deals with the specific question of mapping between network names
and IP network numbers (part of every IP address), and some general
thoughs about mapping between arbitrary things (relevant to the reverse
mapping, a la in-addr.arpa).

Namedroppers is probably a better list for this, and I'm sure there
is a lot of discussion about similar issues in its archives.

paul

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 20:09:12 GMT
From:      rhorn@infinet.UUCP (Rob Horn)
To:        comp.protocols.tcp-ip
Subject:   Re: interrupt-driven vs. polled I/O performance

In article <25231@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>But the echo delay doesn't need to be kept to a *minimum*, but only
>well below the objectionable level to the human user.
 [...]
>I claim that 100ms for echo is not noticable to a user of a video
>display

I went through this extensively for some CAD/CAM and Command & Control
applications.  The dominant factor was the refresh rate of the CRT and
phosphor decay rate (or their equivalents for non-CRT technologies).
Flicker perception, rate timing, and absolute timing perceptions are
each different and impose different update rate issues.  There is a further
problem with eye-hand coordination if the update lags by more than a few
hundred milliseconds.

Most CRT's refresh near either 15 msec or 30 msec.  Most phosphors are picked
to decay in one to two refresh cycles.  Any delay less than the
refresh rate is impossible to perceive because the refresh rate delay
dominates.  Most people cannot perceive delays of up to 50 msec.
(Fast refresh rates *do* affect the perceived image quality, so the
difference between 15 and 30 msec is still significant.)

Flicker perception is triggered by phosphors that decay too quickly
when compared to refresh rates.  Here, some people will perceive
flicker down even to 15 msec, although after-image effects on the
retina must be considered in the experimental design for measuring
these effects.  

For those who do not know what I mean by rate timing, this is the
timing used in race events where human eye plus stopwatch match the
electronic race timers to within 10-20 msec reliably.  A part of this
is matching the motion of the thing being timed with the finger
pushing the stopwatch.  Unpredictable event timing is much less sensitive.
Rate timing effects are significant when performing full screen
updates.  People will perceive pauses that would go unnoticed during
single character updates.
-- 
				Rob  Horn
	UUCP:	...harvard!adelie!infinet!rhorn
		...ulowell!infinet!rhorn, ..decvax!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 20:17:38 GMT
From:      cfe+@ANDREW.CMU.EDU ("Craig F. Everhart")
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking advice on establishing a LARGE centralized mail system

The CMU installation of the Andrew system, andrew.cmu.edu, supports a
name space of 8500 users.  For an installation of this size, I believe
it to be difficult or impossible to make somebody's unique ID correspond
in a predictable way to their full legal name.  (Some smaller
installations, such as CMU's Computer Science department (cs.cmu.edu)
with maybe 3000 users, feel that they can make the unique ID be the
preferable Firstname.I.Lastname, so Andrew also supports that canonical
format for such installations.)

We tackled the problems of mapping name probes to the space of all names
in a distributed manner, and came up with Andrew's White Pages, a name
lookup service that can match probes using abbreviations, phonetic
heuristics, and the like.  The service runs via AFS on any workstation,
not simply on a mail hub.  We use it for mail delivery, as well, with
results such as:
	- mail delivery to the named user
	- error response generated if the name probe was unique but only a
fuzzy match
	- error response generated if the name probe was ambiguous; possible
matches listed if there aren't more than a given number of them
	- error response generated if no match could be found.
This has been in place for two years or more.  In progress is a
mechanism whereby people can update aspects of their own White Pages
entries automatically, with optional administrative approval.

Integrating larger lists of names, with optional mail deliveries such as
paper campus-mail delivery, is a cute idea.  We haven't pursued it very
hard, but we think it could be fun.

		Craig Everhart
		Andrew message system

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 20:23:06 GMT
From:      gaige@lts.uucp (Gaige B. Paulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet problem

In article <8904262304.AA02429@ucbvax.Berkeley.EDU>, OWEN@DUCVAX.AUBURN.EDU (Larry Owen) writes:
>NCSA Telnet with a "fresh" copy from the distribution diskette (V2.1e), but

I would strongly suggest obtaining a copy of NCSA Telnet for the Macintosh
version 2.2 (or the more recent beta).  This is available at finer FTP sites
everywhere (most notably, FTP.NCSA.EDU [128.174.20.50]).  This should help some.


Gaige
--
Gaige B. Paulsen
Author
InterCon Systems Corporation

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 21:41:11 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

Dave Borman says:

    The problem here is not with the remote machine, but with the local
    telnet implementation.  The way that things should work is:
	    User types ^C
	    Local telnet translates that to, and sends, IAC IP,
		    and then sends IAC DO TIMING-MARK and begins to
		    flush all output.
	    Local telnet receives IAC WILL/WONT TIMING-MARK, and
		    resumes terminal output.

This would work just great except when you are talking to an ITS system
and running EMACS, in which case you want ^C to be passed transparently
through the connection, so that it means "control-meta".  Or when you
are trying to upload a file using the MODEM2 protocol, or etc, etc
This is why the "Telnet Line Mode" specificaion (soon to be an RFC) is
so important - it lets you negotiate which characters are special, and
exactly how they behave, and it lets you turn things on and off...

On the brighter side, I have heard that the "skid" on terminals connected
to properly behaving, well implemented terminal servers/unix hosts is
typically less than 1/2 screenfull.  Unfortunately, properly operating
terminal servers are rare, and properly oeprating hosts are even more
rare. (The case that seems to work well is a cisco terminal server talking
to the rutgers kernal based telnet on a pyramid...)

Bill Westfield
cisco Systems.
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 21:44:07 GMT
From:      mr-frog@fxgrp.UUCP (Dave Pare)
To:        comp.protocols.tcp-ip
Subject:   fragmenting broadcasts

I was the original poster that started this whole mess, and I suspect
if I'd added some context, I could have made things somewhat clearer.
Asking people to comment in an information vacuum was the wrong approach.

So here is some context:

My task is to distribute fairly large volumes of data to sites on
an ethernet.  One central host takes an external data feed, massages
it a bit, and then sends it out on the main wire.  In this application,
each host on the wire is interested in receiving a major portion of
what is being broadcast.  No hosts are uninterested in receiving
these broadcast messages.

The network is being used as a broadcast data distribution mechanism.
My program will be the only broadcaster, perhaps with the exception
of occasional vendor-supported broadcasters like rarpd.

Given that I know what I'm doing, and that every host really and truly
does want to see almost all the data broadcast, can people understand
why I am perturbed by the limitation on the size of my broadcast
transmissions?

I don't dispute that on a general-purpose computing network, it is
best to have the general rabble restrained by rigid host requirements
which limit the ability to do mischief.  I don't believe that I or the
clients who purchase our product fit the above description, and so
in this case I feel frustrated by the restrictions.

So, with all this in mind, do people still maintain that the most
reasonable way for the network to behave is to force my program to
perform the fragmentation/reassembly task in user code?  That means
I have to switch into kernel mode for each 1k packet, instead of
buffering things up and sending 4k, or 8k packets.

Another thing: I've never seen a datagram get lost on a LAN.  They
do get discarded when the receiving process can't drain the receive
buffer space quickly enough, though.

I really don't want to sound like a whiner.  I like UDP.  I'm just
hoping that Someone Who Matters will read this posting, and decide
that the best way to interpret the Host Requirements document is to
have a default setting be "no fragmentation", but allow a kernel
global variable to remove this restriction.

Dave Pare

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 22:07:26 GMT
From:      amanda@lts.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: new terminal names

In article <7080014@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes:
>If you are doing an FTP to foo.bar.edu, how does it help to know that the
>two name servers for bar.edu are a Timex/Sinclair and an IBM Selectric?
>
>Jacob Gore				Gore@EECS.NWU.Edu
>Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

Sigh.  It doesn't.  However, it helps a lot to know that foo.bar.edu
is running UNIX (for example), so that the FTP client can ask for
a long format directory listing, parse it, and find out useful things
like file size, whether or not a given file is really a directory, and
so on.  Since this sort of information is not provided by the FTP spec,
it must be determined in a OS-dependent fashion.  Since the OS involved
cannot usually be determined from the host itself (since most FTP servers
do not conform to the RFC by responding to the SYST command...), it's
very nice to be able to glean this information from the nameserver.

To take another example, it's quite useful for a mail transport program
to be able to find out where to send mail destined for zot.bar.edu,
even (or especially) if there is no direct path between said mail
transport program and zot.bar.edu.

Domain servers provide information about the domain and the hosts therein.
Addresses are part of this information.  Host OS and type information
is part it, too.  So is mail-handling information.

This discussion seems to be approaching ridiculousness...

--
Amanda Walker
InterCon Systems Corporation
amanda@lts.UUCP / lts!amanda@uunet.uu.net

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 22:44:28 GMT
From:      dab@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

> From: dab@opus.cray.com (Dave Borman)  [The other dab.]
> 
> The problem here is not with the remote machine, but with the local
> telnet implementation.  The way that things should work is:
> 	User types ^C
> 	Local telnet translates that to, and sends, IAC IP,
> 		and then sends IAC DO TIMING-MARK and begins to
> 		flush all output.
> 	Local telnet receives IAC WILL/WONT TIMING-MARK, and
> 		resumes terminal output.
>

I disagree; that's not the way things should work.  Typing ^C is likely to
mean any of a number of things depending on what program I'm running at the
time.  The classic example is, of course, Emacs.  To see a much better
solution to this problem see the SUPDUP Local Editing Protocol.  Its
problem is that it's more complicated than anyone wants to implement (and
I'm not sure it's doable at all under UNIX as PTY's work now).  But
everything less that I've heard about is pretty unsuitable.  The protocol
at least needs the ability for the server to set the clients interrupt
characters and to be able to turn it off when the program switchs out of
COOKED mode into RAW or CBREAK mode (to use UNIX terminology).

If someone knows how to pull enough information to do this out of the back
side of a PTY on UNIX then let me know.  I'd like to put the code in my
SUPDUP server (and client too but that's easy, or at least straightforward)
to make it effectively run in line-at-a-time mode for programs running in
COOKED mode.  Then, if I can find someone to hack up GNU Emacs to
understand too...

						David Bridgham

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed 3 May 89 03:44:29-EDT
From:      Norm Schneidewind <NSCHNEIDEWIND@A.ISI.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   9th International Conference on Distributed Computing Systems
For additional information about this conference, please contact the
Program Chairman:
 
Prof. Norman Schneidewind
Naval Postgraduate School
Code 54 Ss
Monterey, CA 93943
408-646-2719/2471 (message)
nschneidewind at a.isi.edu
 
     The 9th International Conference on Distributed Computer Systems
 
                         FINAL PROGRAM
 
                        Conference-at-a glance
 
Pre-Conference Tutorials
------------------------
 
Monday, June 5, 1989
8:30am-5:00 pm
 
Tutorial 1: Fault-Tolerant Computation
 
            Dr. Flaviu Cristian , IBM Almaden Research Laboratory
 
Tutorial 2: Concurrency and Coherency Control for Multi-System
            Transaction Processing
 
            Dr. Alexander Thomasian and Dr. Erhard Rahm,
            IBM Yorktown Heights
 
---------------------------------------------------------------------------
              Tuesday                     Wednesday           Thursday
TIME        June 6, 1989                June 7, 1989        June 8, 1989
---------------------------------------------------------------------------
                                                       
 8:30 am-   PLENARY SESSION         4A. Reliability     8A. Transaction
10:00 am    Keynote Speaker             Models of           Management 
                                        Distributed         and Query
                                        Processing          Processing
                                                       
                                    4B. Distributed     8B. Communication                                               Programming         Network
                                        Languages           Performance
                                        and Tools
      
                                    4C. Real-Time        
                                        Systems        
---------------------------------------------------------------------------
10:00 am-       BREAK                   BREAK               BREAK
10:30 am
-------------------------------------------------------------------------
10:30 am-   1A. Distributed         5A. Fault Tolerant  9A. Replication
12:00 noon      Algorithms              Databases and       Management
                                        File System    
                                        Design         
                                                       
            1B. Distributed OS      5B. Hybercubes      9B. Distributed
                Performance                                 System    
                                                            Performance
 
                                    5C. Formal Models  
                                        and Algorithms   
---------------------------------------------------------------------------
12:00 noon-     LUNCH                   LUNCH               LUNCH
 1:30 pm
---------------------------------------------------------------------------
 1:30 pm-   2A. Backup and          6A. Load Sharing    10A.Fault Tolerance
 3:00 pm        Consistency                                 Distributed
                                                            Algorithms
 
            2B. Distributed         6B. Experimental    10B.Distributed
                Control                 Distributed         Architectures
                                        Systems        
                                                       
                                    6C. Communications 
----------------------------------------------------------------------------
 3:00 pm-       BREAK                   BREAK               BREAK
 3:30 pm
----------------------------------------------------------------------------
 3:30 pm-   3A. Synchronization     7A. Concurrency     11A.Reliable
 5:00 pm                                Control             Distributed
                                                            Protocols
 
            3B. Distributed OS      7B. Panel           11B.Advances in
                Consistency             Discussion:         Distributed
                                        Distributed         Software
                                        Shared Memory       Development
-----------------------------------------------------------------------------
 6:00 pm-                               BANQUET
 8:00 pm                                        
-----------------------------------------------------------------------------
 8:30 pm-       Panel Discussion:       Technical Committee
10:30 pm        Critical Issues for     on Distributed
                the Development of      Processing Meeting
                Next Generation
                Distributed Systems
------------------------------------------------------------------------------
 
Post-Conference Tutorials
-------------------------
 
Friday, June 9, 1989
8:30 am-5:00 pm
 
Tutorial 3: Parallel Processing Networks and Systems
 
            Dr. Howard Jay Siegel, Purdue University
 
Tutorial 4: Distributed Database Management Systems
 
            Dr. Saeed Rahimi, Infospan and University of Minnesota
 
                         FINAL PROGRAM
 
 
TUESDAY, June 6, 1989
 
--------------------------------------
8:30 am - 10:00 a.m. PLENARY SESSION
--------------------------------------
 
Opening Remarks:   Kane Kim, University of
                   California, Irvine
 
Technical Program: Norman Schneidewind,
                   Naval Postgraduate School
 
Presentation of Best Paper Award: Mile Liu,
                   Ohio State University
 
Keynote Speech:    William Wulf,
                   National Science Foundation
 
SESSION 1A: DISTRIBUTED ALGORITHMS
 
Chair: Bezalel Gavish, Naval Postgraduate School and Vanderbilt University
 
A Distributed Algorithm for Minimum Weight Spanning
Trees Based on Echo Algorithms
 
 Mohan Ahuja
 Yahui Zhu
 
Decentralized Evaluation of Associative and
Commutative Functions
 
 Chyuan Samuel Hsieh
 
A Randomized Technique for Remote File Comparison
 
 Daniel Barbara'
 Richard J. Lipton
 
SESSION 1B: DISTRIBUTED OPERATING
            SYSTEM PERFORMANCE
 
Chair: Andre van Tilborg, Office of Naval Research
 
The Design of a High-Performance File Server
 
 Robbert van Renesse
 Andrew S. Tanenbaum
 Annita Wilschut
 
QuickSilver Support for Access to Data
in Large, Geographically Dispersed Systems
 
 Marvin Theimer
 Luis-Felipe Cabrera
 Jim Wyllie
 
Performance Implications of Design Alternatives for
Remote Procedure Call Stubs
 
 Sung K. Chung
 Edward D. Lazowska
 David Notkin
 John Zahorjan
 
SESSION 2A: BACKUP AND CONSISTENCY
 
Chair: C.V. Ramamoorthy, University of California, Berkeley
 
Transparent Concurrent Execution of Mutually
Exclusive Alternatives
 
 Jonathan M. Smith
 Gerald Q. Maguire, Jr.
 
Message-Optimal Incremental Snapshots
 
 S. Venkatesan
 
Simultaneous Regions:  A Framework for the
Consistent Monitoring of Distributed Systems
 
 M. Spezialetti
 J.P. Kearns
 
SESSION 2B: DISTRIBUTED CONTROL
 
Chair: Tom LeBlanc, University of Rochester
 
A Dynamic Information-Structure Mutual Exclusion
Algorithm for Distributed Systems
 
 Mukesh Singhal
 
Detecting Termination of Distributed Computations
by External Agents
 
 Shing-Tsaan Huang
 
Securely Replicating Authentication Services
 
 Li Gong
 
SESSION 3A: SYNCHRONIZATION
 
Chair: Kinji Mori, Hitachi, Ltd., Japan
 
Message Complexity of Simple Ring-based Election
Algorithms - an Empirical Analysis
 
 Friedemann Mattern
 
Optimization And Evaluating Algorithms For
Replicated Data Concurrency Control
 
 Akhil Kumar
 Arie Segev
 
Low Cost Algorithms for Message Delivery in Dynamic
Multicast Groups
 
 Nasr E. Belkeir
 Mustaque Ahamad
 
SESSION 3B: DISTRIBUTED OS CONSISTENCY
 
Chair: Virginia Kobler, U.S. Army 
 
Immediate Ordered Service in Distributed Systems
 
 Phil Kearns
 Brahma Koodalattupuram
 
Linking Consistency with Object/Thread Semantics:
An Approach to Robust Computation
 
 Raymond C. Chen
 Partha Dasgupta
 
Fault-Tolerant Distributed Systems Based on
Broadcast Communication
 
 P.M. Melliar-Smith
 L.E. Moser
 
PANEL DISCUSSION: CRITICAL ISSUES FOR THE DEVELOPMENT OF NEXT-GENERATION 
                  DISTRIBUTED SYSTEMS
 
Chair: Horst Wedde, Wayne State University
 
Members:
 
Bharat Bhargava, Purdue University
Flaviu Cristian, IBM
Hector Garcia-Molina, Princeton University
Gerard LeLann, INRIA, France
Miroslav Malek, University of Texas
Krithi Ramamritham, University of Massachusetts
Andre van Tilborg, Office of Naval Research
 
SESSION 4A: RELIABILITY  MODELS OF
            DISTRIBUTED PROCESSING
 
Chair: Edgar Nett, GMD, FRG
 
On Reliability Modelling of Fault-Tolerant
Distributed Systems
 
 Philip Thambidurai
 You-Keun Park
 Kishor S. Trivedi
 
Fault-Tolerant Extensions of Complete Multipartite Graphs
 
 R. Dawson
 Abdel Aziz Farrag
 
Application of Petri Net Models for the Evaluation
of Fault-Tolerant Techniques in Distributed Systems
 
 Yuan-bao Shieh
 Dipak Ghosal
 Prasad R. Chintamaneni
 Satish K. Tripathi
 
SESSION 4B: DISTRIBUTED PROGRAMMING LANGUAGES AND TOOLS
 
Chair: Gail Kaiser, Columbia University
 
Concert: A High-Level Language Approach to
Heterogeneous Distributed Systems
 
 Shaula A. Yemini
 German S. Goldszmidt
 Alexander D. Stoyenko
 Y.-H. Wei
 Langdon W. Beeck
 
The Camelot Library:  A C Language Extension for
Programming a General Purpose Distributed
Transaction System
 
 Joshua J. Bloch
 
Marionette: a System for Parallel Distributed Programming
Using a Master/Slave Model
 
 Mark Sullivan
 David Anderson
 
SESSION 4C: REAL-TIME SYSTEMS
 
Chair: Alex Stoyenko, IBM
 
Static Allocation of Periodic Tasks with Precedence
Constraints in Distributed Real-Time Systems
 
 Dar-Tzen Peng
 Kang G. Shin
 
Timed Atomic Commitment 
 
 Susan Davidson
 Insup Lee
 Victor Wolfe
 
Verification of finite state real-time distributed processes
 
 J.S. Ostroff
 
SESSION 5A: FAULT TOLERANT DATABASES
            AND  FILE  SYSTEM DESIGN
 
Chair: Gerard LeLann, INRIA, France
 
Generating a Fault Tolerant Global Clock in
a High Speed Distributed System
 
 Yoram Ofek
 
Fault Tolerance in a Very Large Database System:
A Strawman Analysis
 
 Amit P. Sheth
 
An Application of Group Testing to the File
Comparison Problem
 
 Tom Madej
 
SESSION 5B: HYBERCUBES
 
Chair: Charles Vick, Optimization Technology, Inc.
 
Initializing Hypercubes
 
 Howard P. Katseff
 
Programming the Twisted-Cube Architectures
 
 Kemal Efe
 
A New Approach To Hypercube Network Analysis
 
 Bo Jin
 Lan Jin
 
SESSION 5C: FORMAL MODELS AND ALGORITHMS
 
Chair: Krithi Ramamritham, University of Massachusetts 
 
A Shared Dataspace Model of Concurrency
- Language and Programming Implications -
 
 Gruia-Catalin Roman
 H. Conrad Cunningham
 
Analysis of Communicating Processes for non-progress
 
 Wuxu Peng
 S. Purushothaman
 
A Probabilistic Approach to Distributed Clock Synchronization
 
 Flaviu Cristian
 
SESSION 6A: LOAD SHARING
 
Chair: Nader Bagherzadeh, University of California, Irvine
 
Adaptive Load Sharing in Heterogeneous Systems
 
 Ravi Mirchandaney
 Don Towsley
 John A. Stankovic
 
Minimizing Control Overheads in Adaptive Load Sharing
 
 Kemal Efe
 Bojan Groselj
 
Efficient Algorithms for Resource Allocation in 
Distributed and Parallel Query Processing Environments
 
 Peng Liu
 Yasushi Kiyoki
 Takashi Masuda
 
SESSION 6B: EXPERIMENTAL DISTRIBUTED SYSTEMS
 
Chair: Thomas Raeuchle, Honeywell Research
 
A Service Execution Mechanism for a Distributed Environment
 
 Craig E. Wills
 
Transparent Distributed Object Management Under
Completely Decentralized Control
 
 Horst F. Wedde
 Bogdan Korel
 Willie G. Brown
 Shengdong Chen
 
Performance of a Decentralized Knowledge Base System
 
 Craig Lee
 Lubomir Bic
 
SESSION 6C: COMMUNICATIONS
 
Chair: Horst Wedde, Wayne State University
 
Message Ordering in a Multicast Environment
 
 Hector Garcia-Molina
 Annemarie Spauster
 
Some Graph Partitioning Problems and Algorithms
Related to Routing in Large Computer Networks
 
 A. Bouloutas
 P. M. Gopal
 
Intelligent Routers
 
 C. Daniel Wolfson
 Ellen Voorhees
 Maura M. Flatley
 
SESSION 7A: CONCURRENCY CONTROL
 
Chair: Barton Miller, University of Wisconsin
 
Evaluation of Concurrent Pools
 
 C.S. Ellis
 
A Time Out Based Resilient Token Transfer Algorithm
for Mutual Exclusion in Computer Networks
 
 Shojiro Nishio
 K.F. Li
 Eric G. Manning
 
Voting with Bystanders
 
 Jehan-Francois Paris
 
SESSION 7B: PANEL DISCUSSION: DISTRIBUTED SHARED MEMORY
 
Chair: Umakishore Ramachandran Georgia Institute of Technology
 
Members:
 
Larry Wittie, SUNY, Stony Brook
David Jefferson, UCLA
Andrew Black, DEC
Luis-Felipe Cabrera, IBM Almaden
 
SESSION 8A: TRANSACTION MANAGEMENT AND 
            QUERY PROCESSING
 
Chair: John Stankovic, University of Massachusetts
 
Adaptive Transaction Routing in a Heterogeneous
Database Environment
 
 Avraham Leff
 Philip S. Yu
 Yann-Hang Lee
 
Distributed Query Processing in Cronus
 
 Stephen T. Vinter
 Richard Floyd
 Nikanth Phadnis
 
A Model for Concurrent Checkpointing and Recovery
Using Transactions
 
 Pei-Jyun Leu
 Bharat Bhargava
 
SESSION 8B: COMMUNICATION NETWORK PERFORMANCE
 
Chair: Robert Hagmann, Xerox PARC
 
A High Performance Virtual Token-Passing Multiple
Access Method for Multiple-Bus Local Networks
 
 V.V Karmarkar
 J.G. Kuhl
 
Performance Analysis of Synchronous Packet Networks
with Priority Queueing Disciplines
 
 Audrey M. Viterbi
 
Capacity Testing a Hyperchannel-Based Local Area Network
 
 W. Bruce Watson
 
SESSION 9A: REPLICATION MANAGEMENT
 
Chair: Walter Kohler, DEC
 
A Flexible Algorithm for Replicated Directory Management
 
 Sunil Sarin
 Nilkanth Phadnis
 Richard Floyd
 
The Reliability of Regeneration-Based Replica
Control Protocols
 
 Darrell D.E. Long
 John L. Carroll
 Kris Stewart
 
Replicated Transactions
 
 Pui Tony Ng
 Shaw-Ben Shi
 
SESSION 9B: DISTRIBUTED SYSTEM PERFORMANCE
 
Chair: Susan Davidson, University of Pennsylvania
 
Collecting Unused Capacity:  An Analysis of
Transient Distributed Systems
 
 Leonard Kleinrock
 Willard Korfhage
 
Performance Modeling of the Modified Mesh-Connected
Parallel Computer
 
 Chia-Jiu Wang
 Victor Nelson
 C. H. Wu
 
An Analysis of Distributed Shared Memory Algorithms
 
 R. E. Kessler
 Miron Livny
 
SESSION 10A: FAULT TOLERANCE DISTRIBUTED ALGORITHMS
 
Chair: Ralf M. Yanney, TRW Defense Systems Group
 
Reliable Distributed Sorting Through the
Application Oriented Fault-Tolerance Paradigm
 
 Bruce M. McMillin
 Lionel M. Ni
 
On the Design of Resilient Protocols for Spanning
Tree Problems
 
 I. Arieh Cimet
 C. Cheng 
 Srikanta P.R. Kumar
 
Fault-Tolerant Analysis and Algorithms for a Proposed
Augmented Binary Tree Architecture
 
 Bijendra N. Jain
 Ravi Mittal
 Rakesh K. Patney
 
SESSION 10B: DISTRIBUTED ARCHITECTURES
 
Chair: Niraj Sharma, Purdue University
 
Fast Ring:  A Distributed Architecture and Protocol
for Local Area Distributed Processing
 
 Srinivas R. Koppolu
 S. Thanawastien
 Robert R. Henry
 
HPC/VORX:  A Local Area Multicomputer System
 
 R.D. Gaglianello
 B.S. Robinson
 T.L. Lindstrom
 E.E. Sampieri
 
Implementing Location Independent Invocation
 
 Andrew P. Black
 Yeshayahu Artsy
 
SESSION 11A: RELIABLE DISTRIBUTED PROTOCOLS
 
Chair: John A. Rohr, Jet Propulsion Laboratory
 
Distributed Diagnosis of Byzantine Processors and Links
 
 Joel C. Adams
 K.V.S. Ramarao
 
Implementation of the Conversion Scheme in Loosely
Coupled Distributed Computer Systems
 
 S.M. Yang
 K.H. Kim
 
Missing Partition Dynamic Voting Scheme for 
Replicated Database Systems
 
 Ching-Liang Haung
 Victor O.K. Li
 
SESSION 11B: ADVANCES IN DISTRIBUTED SOFTWARE DEVELOPMENT
 
Chair: Charles Graff, U.S. Army
 
An Environment for Prototyping Distributed Applications
 
 James M. Purtilo
 Pankaj Jalote
 
Toolkit for Automated Support of Ada Tasking Analysis
 
 Sol M. Shatz
 D. Moorthi
 K. Mai
 J. Woodward
 
An Approach to Verification of Communication in
Distributed Computing Systems Software
 
 Stephen S. Yau
 Kris W.I. Chen
-------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 03:06:26 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

We've all noticed the problem where you type ^C and output keeps
coming for pages.  You suggest that the local telnet should interpret
the ^C and use timing mark to resynchronize.  That sounds plausible,
but it has a problem that makes many of us unenthusiastic about using
it: the local telnet has to know what interrupt character to use and
when to disable it.  If you run a program on the host system that uses
"raw I/O", you don't want ^C translated into IAC IP.  You want the ^C
interpreted as a normal character.  The proposed linemode telnet will
implement the right handshaking between the host and user telnets to
make this kind of thing work.  But at the moment I don't consider it
safe.  We do what the telnet spec suggests, which is to use the telnet
sync mechanism.  I'll describe this for Unix, but it should work
similarly on other OS's.

  you:            type ^C
  local telnet:   pass ^C to host like any other character
  host telnet:    pass ^C as input to the job like any other character
  OS:		  notice that ^C is an interrupt character. (1) issue
		   interrupt to job (2) notify host telnet that output
		   should be flushed.  (This version of telnetd runs
		   the pty in packet mode, so such notification is
		   actually done.)
  host telnet:    flush all output that has been buffered but not yet
		   sent.  Put telnet sync into the output.  Telnet
		   sync involves an urgent notification, which moves
		   out of band.  The next packet sent from the host
		   to the local telnet should have that bit on.
  local telnet:   when it sees urgent, stop output and flush any
		   pending output.  This should happen out of band.
		   That is, as soon as a packet with urgent arrives
		   from the network, output queued to the tty driver
		   should be flushed, and new output coming from
		   the network should be ignored.  Ignoring continues
		   until the in-band portion of the telnet sync
		   arrives.

The disadvantage compared to your proposal is that you will get a bit
more extra output after you type ^C.  The amount of delay obviously
depends upon your network speed.  If you are working over a satellite
link, you could see *lots* of extra output.  For campus environments
it's not too bad.  The advantage is that the local telnet doesn't have
to know how your OS interprets characters.  On many OS's there are
several characters that should flush output, e.g. ^C, ^O, and ^Y.  And
programs can disable one or more of them.  (Also, it is possible for
programs to invoke the clear output function themselves, without any
particular character being typed.)  Those of us who use Emacs would
certainly not want to see the local telnet turn all three of those
characters into an interrupt!  My guess is that in a campus
environment, your method would work best for half duplex, and this
method for full duplex.  All of the terminal servers I've seen do
implement the local side of telnet sync, so you have to get the host
telnet daemon to handle things right.  I think we've convinced the
right people to get this in 4.4.  (In fact it's possible that it is in
4.3 Tahoe.)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 May 89 09:18:09 CDT
From:      dab@opus.cray.com (Dave Borman)
To:        tcp-ip@sri-nic.ARPA, ultra!wayne@ames.arc.nasa.gov
Subject:   Re:  ICMP_UNREACH_PORT
> ... Since I was
> interested in datagrams tossed by the card rather than the SunOS
> kernel, I did not bother having anybody do a "recvfrom" on the 3/140
> (in other words, the datagrams would be tossed by the 3/140's UDP).
> ...
> Okay, the strangeness:  Looking at counters, I noticed that not only
> did the 3/140 receive (say) 854 datagrams, it also SENT exactly 854
> datagrams.  It didn't take too much detective work to figure out what
> the outgoing datagrams were -- they were ICMP messages with Type 3,
> Code 3: "Destination Port Unreachable".  My question is "Why?"
>
> First of all, I'm a great believer in the idea of "if something weird
> happens, build a datagram describing it and launch it towards some
> logging host, then forget it."  But if that host's logging program
> isn't up, this is going to result in DOUBLE the network traffic (at
> least in number of datagrams).  No great "overload" problem, of
> course, but it does seem silly, particularly since (for UDP datagrams,
> at least) the original sending host isn't really going to be able to
> DO anything with the information.
> ...
> Actually, what is happening in 4.3 BSD is that UDP is turning around
> and causing its ICMP to send the ICMP_UNREACH_PORT message.  Nothing
> illegal about this, of course, but it does get us back to the previous
> question: why bother?  (The UDP action is in udp_usrreq.c and is
> prefaced by the comment "don't send ICMP response for broadcast
> packet" -- I would ask why EVER send it?!  Also I note that TCP does
> not seem to ever send an ICMP_UNREACH_PORT.)
>
>  Wayne Hathaway            

Wayne,
1) TCP doesn't need to send ICMP_UNREACH_PORT.  If a packet comes in
   for a connection that doesn't exist, or a SYN for a port that no
   one is listening on, a RST is sent back to inform the other side.
2) There are UDP applications other than error logging.  TFTP and
   the nameserver are obvious ones.  These applications can benifit
   from getting the ICMP_UNREACH_PORT message, rather than waiting
   around for a reply that will never come.  Since the kernel has
   no idea as to what protocol is using what port, it is better to
   send the ICMP_UNREACH_PORT on all ports, rather than not at all,
   so that the ICMP message will be there if it can be used by the
   remote side.

		-Dave Borman, dab@cray.com
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 07:56:54 GMT
From:      NSCHNEIDEWIND@A.ISI.EDU (Norm Schneidewind)
To:        comp.protocols.tcp-ip
Subject:   9th International Conference on Distributed Computing

For additional information about this conference, please contact the
Program Chairman:
 
Prof. Norman Schneidewind
Naval Postgraduate School
Code 54 Ss
Monterey, CA 93943
408-646-2719/2471 (message)
nschneidewind at a.isi.edu
 
     The 9th International Conference on Distributed Computer Systems
 
                         FINAL PROGRAM
 
                        Conference-at-a glance
 
Pre-Conference Tutorials
------------------------
 
Monday, June 5, 1989
8:30am-5:00 pm
 
Tutorial 1: Fault-Tolerant Computation
 
            Dr. Flaviu Cristian , IBM Almaden Research Laboratory
 
Tutorial 2: Concurrency and Coherency Control for Multi-System
            Transaction Processing
 
            Dr. Alexander Thomasian and Dr. Erhard Rahm,
            IBM Yorktown Heights
 
---------------------------------------------------------------------------
              Tuesday                     Wednesday           Thursday
TIME        June 6, 1989                June 7, 1989        June 8, 1989
---------------------------------------------------------------------------
                                                       
 8:30 am-   PLENARY SESSION         4A. Reliability     8A. Transaction
10:00 am    Keynote Speaker             Models of           Management 
                                        Distributed         and Query
                                        Processing          Processing
                                                       
                                    4B. Distributed     8B. Communication                                               Programming         Network
                                        Languages           Performance
                                        and Tools
      
                                    4C. Real-Time        
                                        Systems        
---------------------------------------------------------------------------
10:00 am-       BREAK                   BREAK               BREAK
10:30 am
-------------------------------------------------------------------------
10:30 am-   1A. Distributed         5A. Fault Tolerant  9A. Replication
12:00 noon      Algorithms              Databases and       Management
                                        File System    
                                        Design         
                                                       
            1B. Distributed OS      5B. Hybercubes      9B. Distributed
                Performance                                 System    
                                                            Performance
 
                                    5C. Formal Models  
                                        and Algorithms   
---------------------------------------------------------------------------
12:00 noon-     LUNCH                   LUNCH               LUNCH
 1:30 pm
---------------------------------------------------------------------------
 1:30 pm-   2A. Backup and          6A. Load Sharing    10A.Fault Tolerance
 3:00 pm        Consistency                                 Distributed
                                                            Algorithms
 
            2B. Distributed         6B. Experimental    10B.Distributed
                Control                 Distributed         Architectures
                                        Systems        
                                                       
                                    6C. Communications 
----------------------------------------------------------------------------
 3:00 pm-       BREAK                   BREAK               BREAK
 3:30 pm
----------------------------------------------------------------------------
 3:30 pm-   3A. Synchronization     7A. Concurrency     11A.Reliable
 5:00 pm                                Control             Distributed
                                                            Protocols
 
            3B. Distributed OS      7B. Panel           11B.Advances in
                Consistency             Discussion:         Distributed
                                        Distributed         Software
                                        Shared Memory       Development
-----------------------------------------------------------------------------
 6:00 pm-                               BANQUET
 8:00 pm                                        
-----------------------------------------------------------------------------
 8:30 pm-       Panel Discussion:       Technical Committee
10:30 pm        Critical Issues for     on Distributed
                the Development of      Processing Meeting
                Next Generation
                Distributed Systems
------------------------------------------------------------------------------
 
Post-Conference Tutorials
-------------------------
 
Friday, June 9, 1989
8:30 am-5:00 pm
 
Tutorial 3: Parallel Processing Networks and Systems
 
            Dr. Howard Jay Siegel, Purdue University
 
Tutorial 4: Distributed Database Management Systems
 
            Dr. Saeed Rahimi, Infospan and University of Minnesota
 
                         FINAL PROGRAM
 
 
TUESDAY, June 6, 1989
 
--------------------------------------
8:30 am - 10:00 a.m. PLENARY SESSION
--------------------------------------
 
Opening Remarks:   Kane Kim, University of
                   California, Irvine
 
Technical Program: Norman Schneidewind,
                   Naval Postgraduate School
 
Presentation of Best Paper Award: Mile Liu,
                   Ohio State University
 
Keynote Speech:    William Wulf,
                   National Science Foundation
 
SESSION 1A: DISTRIBUTED ALGORITHMS
 
Chair: Bezalel Gavish, Naval Postgraduate School and Vanderbilt University
 
A Distributed Algorithm for Minimum Weight Spanning
Trees Based on Echo Algorithms
 
 Mohan Ahuja
 Yahui Zhu
 
Decentralized Evaluation of Associative and
Commutative Functions
 
 Chyuan Samuel Hsieh
 
A Randomized Technique for Remote File Comparison
 
 Daniel Barbara'
 Richard J. Lipton
 
SESSION 1B: DISTRIBUTED OPERATING
            SYSTEM PERFORMANCE
 
Chair: Andre van Tilborg, Office of Naval Research
 
The Design of a High-Performance File Server
 
 Robbert van Renesse
 Andrew S. Tanenbaum
 Annita Wilschut
 
QuickSilver Support for Access to Data
in Large, Geographically Dispersed Systems
 
 Marvin Theimer
 Luis-Felipe Cabrera
 Jim Wyllie
 
Performance Implications of Design Alternatives for
Remote Procedure Call Stubs
 
 Sung K. Chung
 Edward D. Lazowska
 David Notkin
 John Zahorjan
 
SESSION 2A: BACKUP AND CONSISTENCY
 
Chair: C.V. Ramamoorthy, University of California, Berkeley
 
Transparent Concurrent Execution of Mutually
Exclusive Alternatives
 
 Jonathan M. Smith
 Gerald Q. Maguire, Jr.
 
Message-Optimal Incremental Snapshots
 
 S. Venkatesan
 
Simultaneous Regions:  A Framework for the
Consistent Monitoring of Distributed Systems
 
 M. Spezialetti
 J.P. Kearns
 
SESSION 2B: DISTRIBUTED CONTROL
 
Chair: Tom LeBlanc, University of Rochester
 
A Dynamic Information-Structure Mutual Exclusion
Algorithm for Distributed Systems
 
 Mukesh Singhal
 
Detecting Termination of Distributed Computations
by External Agents
 
 Shing-Tsaan Huang
 
Securely Replicating Authentication Services
 
 Li Gong
 
SESSION 3A: SYNCHRONIZATION
 
Chair: Kinji Mori, Hitachi, Ltd., Japan
 
Message Complexity of Simple Ring-based Election
Algorithms - an Empirical Analysis
 
 Friedemann Mattern
 
Optimization And Evaluating Algorithms For
Replicated Data Concurrency Control
 
 Akhil Kumar
 Arie Segev
 
Low Cost Algorithms for Message Delivery in Dynamic
Multicast Groups
 
 Nasr E. Belkeir
 Mustaque Ahamad
 
SESSION 3B: DISTRIBUTED OS CONSISTENCY
 
Chair: Virginia Kobler, U.S. Army 
 
Immediate Ordered Service in Distributed Systems
 
 Phil Kearns
 Brahma Koodalattupuram
 
Linking Consistency with Object/Thread Semantics:
An Approach to Robust Computation
 
 Raymond C. Chen
 Partha Dasgupta
 
Fault-Tolerant Distributed Systems Based on
Broadcast Communication
 
 P.M. Melliar-Smith
 L.E. Moser
 
PANEL DISCUSSION: CRITICAL ISSUES FOR THE DEVELOPMENT OF NEXT-GENERATION 
                  DISTRIBUTED SYSTEMS
 
Chair: Horst Wedde, Wayne State University
 
Members:
 
Bharat Bhargava, Purdue University
Flaviu Cristian, IBM
Hector Garcia-Molina, Princeton University
Gerard LeLann, INRIA, France
Miroslav Malek, University of Texas
Krithi Ramamritham, University of Massachusetts
Andre van Tilborg, Office of Naval Research
 
SESSION 4A: RELIABILITY  MODELS OF
            DISTRIBUTED PROCESSING
 
Chair: Edgar Nett, GMD, FRG
 
On Reliability Modelling of Fault-Tolerant
Distributed Systems
 
 Philip Thambidurai
 You-Keun Park
 Kishor S. Trivedi
 
Fault-Tolerant Extensions of Complete Multipartite Graphs
 
 R. Dawson
 Abdel Aziz Farrag
 
Application of Petri Net Models for the Evaluation
of Fault-Tolerant Techniques in Distributed Systems
 
 Yuan-bao Shieh
 Dipak Ghosal
 Prasad R. Chintamaneni
 Satish K. Tripathi
 
SESSION 4B: DISTRIBUTED PROGRAMMING LANGUAGES AND TOOLS
 
Chair: Gail Kaiser, Columbia University
 
Concert: A High-Level Language Approach to
Heterogeneous Distributed Systems
 
 Shaula A. Yemini
 German S. Goldszmidt
 Alexander D. Stoyenko
 Y.-H. Wei
 Langdon W. Beeck
 
The Camelot Library:  A C Language Extension for
Programming a General Purpose Distributed
Transaction System
 
 Joshua J. Bloch
 
Marionette: a System for Parallel Distributed Programming
Using a Master/Slave Model
 
 Mark Sullivan
 David Anderson
 
SESSION 4C: REAL-TIME SYSTEMS
 
Chair: Alex Stoyenko, IBM
 
Static Allocation of Periodic Tasks with Precedence
Constraints in Distributed Real-Time Systems
 
 Dar-Tzen Peng
 Kang G. Shin
 
Timed Atomic Commitment 
 
 Susan Davidson
 Insup Lee
 Victor Wolfe
 
Verification of finite state real-time distributed processes
 
 J.S. Ostroff
 
SESSION 5A: FAULT TOLERANT DATABASES
            AND  FILE  SYSTEM DESIGN
 
Chair: Gerard LeLann, INRIA, France
 
Generating a Fault Tolerant Global Clock in
a High Speed Distributed System
 
 Yoram Ofek
 
Fault Tolerance in a Very Large Database System:
A Strawman Analysis
 
 Amit P. Sheth
 
An Application of Group Testing to the File
Comparison Problem
 
 Tom Madej
 
SESSION 5B: HYBERCUBES
 
Chair: Charles Vick, Optimization Technology, Inc.
 
Initializing Hypercubes
 
 Howard P. Katseff
 
Programming the Twisted-Cube Architectures
 
 Kemal Efe
 
A New Approach To Hypercube Network Analysis
 
 Bo Jin
 Lan Jin
 
SESSION 5C: FORMAL MODELS AND ALGORITHMS
 
Chair: Krithi Ramamritham, University of Massachusetts 
 
A Shared Dataspace Model of Concurrency
- Language and Programming Implications -
 
 Gruia-Catalin Roman
 H. Conrad Cunningham
 
Analysis of Communicating Processes for non-progress
 
 Wuxu Peng
 S. Purushothaman
 
A Probabilistic Approach to Distributed Clock Synchronization
 
 Flaviu Cristian
 
SESSION 6A: LOAD SHARING
 
Chair: Nader Bagherzadeh, University of California, Irvine
 
Adaptive Load Sharing in Heterogeneous Systems
 
 Ravi Mirchandaney
 Don Towsley
 John A. Stankovic
 
Minimizing Control Overheads in Adaptive Load Sharing
 
 Kemal Efe
 Bojan Groselj
 
Efficient Algorithms for Resource Allocation in 
Distributed and Parallel Query Processing Environments
 
 Peng Liu
 Yasushi Kiyoki
 Takashi Masuda
 
SESSION 6B: EXPERIMENTAL DISTRIBUTED SYSTEMS
 
Chair: Thomas Raeuchle, Honeywell Research
 
A Service Execution Mechanism for a Distributed Environment
 
 Craig E. Wills
 
Transparent Distributed Object Management Under
Completely Decentralized Control
 
 Horst F. Wedde
 Bogdan Korel
 Willie G. Brown
 Shengdong Chen
 
Performance of a Decentralized Knowledge Base System
 
 Craig Lee
 Lubomir Bic
 
SESSION 6C: COMMUNICATIONS
 
Chair: Horst Wedde, Wayne State University
 
Message Ordering in a Multicast Environment
 
 Hector Garcia-Molina
 Annemarie Spauster
 
Some Graph Partitioning Problems and Algorithms
Related to Routing in Large Computer Networks
 
 A. Bouloutas
 P. M. Gopal
 
Intelligent Routers
 
 C. Daniel Wolfson
 Ellen Voorhees
 Maura M. Flatley
 
SESSION 7A: CONCURRENCY CONTROL
 
Chair: Barton Miller, University of Wisconsin
 
Evaluation of Concurrent Pools
 
 C.S. Ellis
 
A Time Out Based Resilient Token Transfer Algorithm
for Mutual Exclusion in Computer Networks
 
 Shojiro Nishio
 K.F. Li
 Eric G. Manning
 
Voting with Bystanders
 
 Jehan-Francois Paris
 
SESSION 7B: PANEL DISCUSSION: DISTRIBUTED SHARED MEMORY
 
Chair: Umakishore Ramachandran Georgia Institute of Technology
 
Members:
 
Larry Wittie, SUNY, Stony Brook
David Jefferson, UCLA
Andrew Black, DEC
Luis-Felipe Cabrera, IBM Almaden
 
SESSION 8A: TRANSACTION MANAGEMENT AND 
            QUERY PROCESSING
 
Chair: John Stankovic, University of Massachusetts
 
Adaptive Transaction Routing in a Heterogeneous
Database Environment
 
 Avraham Leff
 Philip S. Yu
 Yann-Hang Lee
 
Distributed Query Processing in Cronus
 
 Stephen T. Vinter
 Richard Floyd
 Nikanth Phadnis
 
A Model for Concurrent Checkpointing and Recovery
Using Transactions
 
 Pei-Jyun Leu
 Bharat Bhargava
 
SESSION 8B: COMMUNICATION NETWORK PERFORMANCE
 
Chair: Robert Hagmann, Xerox PARC
 
A High Performance Virtual Token-Passing Multiple
Access Method for Multiple-Bus Local Networks
 
 V.V Karmarkar
 J.G. Kuhl
 
Performance Analysis of Synchronous Packet Networks
with Priority Queueing Disciplines
 
 Audrey M. Viterbi
 
Capacity Testing a Hyperchannel-Based Local Area Network
 
 W. Bruce Watson
 
SESSION 9A: REPLICATION MANAGEMENT
 
Chair: Walter Kohler, DEC
 
A Flexible Algorithm for Replicated Directory Management
 
 Sunil Sarin
 Nilkanth Phadnis
 Richard Floyd
 
The Reliability of Regeneration-Based Replica
Control Protocols
 
 Darrell D.E. Long
 John L. Carroll
 Kris Stewart
 
Replicated Transactions
 
 Pui Tony Ng
 Shaw-Ben Shi
 
SESSION 9B: DISTRIBUTED SYSTEM PERFORMANCE
 
Chair: Susan Davidson, University of Pennsylvania
 
Collecting Unused Capacity:  An Analysis of
Transient Distributed Systems
 
 Leonard Kleinrock
 Willard Korfhage
 
Performance Modeling of the Modified Mesh-Connected
Parallel Computer
 
 Chia-Jiu Wang
 Victor Nelson
 C. H. Wu
 
An Analysis of Distributed Shared Memory Algorithms
 
 R. E. Kessler
 Miron Livny
 
SESSION 10A: FAULT TOLERANCE DISTRIBUTED ALGORITHMS
 
Chair: Ralf M. Yanney, TRW Defense Systems Group
 
Reliable Distributed Sorting Through the
Application Oriented Fault-Tolerance Paradigm
 
 Bruce M. McMillin
 Lionel M. Ni
 
On the Design of Resilient Protocols for Spanning
Tree Problems
 
 I. Arieh Cimet
 C. Cheng 
 Srikanta P.R. Kumar
 
Fault-Tolerant Analysis and Algorithms for a Proposed
Augmented Binary Tree Architecture
 
 Bijendra N. Jain
 Ravi Mittal
 Rakesh K. Patney
 
SESSION 10B: DISTRIBUTED ARCHITECTURES
 
Chair: Niraj Sharma, Purdue University
 
Fast Ring:  A Distributed Architecture and Protocol
for Local Area Distributed Processing
 
 Srinivas R. Koppolu
 S. Thanawastien
 Robert R. Henry
 
HPC/VORX:  A Local Area Multicomputer System
 
 R.D. Gaglianello
 B.S. Robinson
 T.L. Lindstrom
 E.E. Sampieri
 
Implementing Location Independent Invocation
 
 Andrew P. Black
 Yeshayahu Artsy
 
SESSION 11A: RELIABLE DISTRIBUTED PROTOCOLS
 
Chair: John A. Rohr, Jet Propulsion Laboratory
 
Distributed Diagnosis of Byzantine Processors and Links
 
 Joel C. Adams
 K.V.S. Ramarao
 
Implementation of the Conversion Scheme in Loosely
Coupled Distributed Computer Systems
 
 S.M. Yang
 K.H. Kim
 
Missing Partition Dynamic Voting Scheme for 
Replicated Database Systems
 
 Ching-Liang Haung
 Victor O.K. Li
 
SESSION 11B: ADVANCES IN DISTRIBUTED SOFTWARE DEVELOPMENT
 
Chair: Charles Graff, U.S. Army
 
An Environment for Prototyping Distributed Applications
 
 James M. Purtilo
 Pankaj Jalote
 
Toolkit for Automated Support of Ada Tasking Analysis
 
 Sol M. Shatz
 D. Moorthi
 K. Mai
 J. Woodward
 
An Approach to Verification of Communication in
Distributed Computing Systems Software
 
 Stephen S. Yau
 Kris W.I. Chen
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 May 89 15:03:29 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   # instructions per packet

    Anyone know how many instructions a DEC LANBridge 100 requires to switch
an Ethernet packet?

Craig
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 May 89 13:06:43 EDT
From:      Alan Personius <TVT@CORNELLA.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP USING FUSION SOFTWARE FOR ROUTING OUT OF SUBNET
Steve,

Sure, especially anything related to what it is and does.........
ALan
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 15:31:05 GMT
From:      droid@earth.cray.com (Andy Nicholson)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP_UNREACH_PORT

> It didn't take too much detective work to figure out what
> the outgoing datagrams were -- they were ICMP messages with Type 3,
> Code 3: "Destination Port Unreachable".  My question is "Why?"

The answer probably is "Because the protocol spec makes it available and
it is probably a good thing to do."  Note that this is more of a
rationalization.  Nowhere that I can think of does the spec say it has
to be done this way.  I would tend to agree that it is probably a good thing
to do.

I find it easy to conceive of an IP implementation on a more advanced operating
system where the IP could receive the ICMP message, make a determination of
the process sending the offending datagram, and asynchronously notify that
process (via a mechanism like signals, and using a signal like SIGPIPE) that
the destination port was not there.  Or the IP could keep a list of
unavailable ports and return a write error to UDP (but only for a short period
of time, as a port may appear later).  There are probably lots of things that
could be done with the message.  It is probably there because it seemed like
"the right thing" to the implementor.

> And second, what is IP doing talking about ports anyway???  I mean,
> ports are upper layer artifacts, no?  According to my trusty grep, the
> word "port" does not even APPEAR in the IP spec (RFC 791)!  But then,
> the ICMP spec DOES say "If ... the IP module cannot deliver the
> datagram because the ... process PORT is not active" so  SOMEBODY sure
> expects IP to be in the port business!  (The spec also mentions ports
> in a couple of other places, but they don't seem to be particularly
> relevant.)

I see you are naive regarding layering of TCP/IP.  They are, but only sometimes.
TCP and UDP protocols make a lot of assumptions about how IP works in order
to gain some performance improvements, like sticking in a partially filled
IP header at the front of the TCP or UDP packet that is passed on to IP.
The fact of the matter is that layering is great from a conceptual view,
but it nukes performance.  Finally, the IP concept of an upper level protocol
port is not the same as the UDP or IP port.  The IP protocol merely makes
the assumption that upper level protocols will have some demultiplexing
mechanism (which they may or may not) and call this the port.  They could
have called this something like endpoint id or demux, or whatever, but port
gets the point across just fine.  Again, although the protocols are layered,
it was pretty much assumed that there was a great likelyhood of finding
TCP and UDP above IP.

> Actually, what is happening in 4.3 BSD is that UDP is turning around
> and causing its ICMP to send the ICMP_UNREACH_PORT message.  Nothing
> illegal about this, of course, but it does get us back to the previous
> question: why bother?  (The UDP action is in udp_usrreq.c and is
> prefaced by the comment "don't send ICMP response for broadcast
> packet" -- I would ask why EVER send it?!  Also I note that TCP does
> not seem to ever send an ICMP_UNREACH_PORT.)

TCP does not send an unreachable port message because it sends a reset segment
instead, as the TCP protocol spec says to.  That is why telnet returns
immediately with "connection refused" if you telnet to a machine that is up
but does not have its telnet server running.

Andy Nicholson			droid@earth.cray.com

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 17:06:43 GMT
From:      TVT@CORNELLA.CIT.CORNELL.EDU (Alan Personius)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP USING FUSION SOFTWARE FOR ROUTING OUT OF SUBNET

Steve,

Sure, especially anything related to what it is and does.........
ALan

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 May 89 17:56:25 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: fragmenting broadcasts

In article <1041@fxgrp.UUCP> mr-frog@fxgrp.UUCP (Dave Pare) writes:
>Given that I know what I'm doing, and that every host really and truly
>does want to see almost all the data broadcast, can people understand
>why I am perturbed by the limitation on the size of my broadcast
>transmissions?

I think you have made a very good case for why you are a special case and
should deliberately exceed the Host Requirements.  I don't think you've
made a particularly good case for a general relaxation of the rules,
given that your situation would seem to be quite unusual.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 17:59:29 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP_UNREACH_PORT

I hold that there is an inherent layering wart in dealing with error
reporting of nonexistent layer-specific address selectors.  You get to
choose the form and location of your wart(s) when you design a protocol
suite, but there will be one somewhere, in some form, if you try to
implement such a function.  The justification for this argument gets
pretty involved; send mail if you want to hear it.  ICMP's approach is
arguably "best" because it provides an optional layer 3 wart which you
may use if you believe it belongs in layer 3, but (since it's optional)
you can implement a layer 4 wart when you design a layer 4 protocol if
you're so inclined, or you can ignore the whole problem by never
reporting such errors.

As for the utility of sending these errors, certainly there is no
knowing in advance whether the recipient will do anything worthwhile
with them, but the forthcoming Host Requirements RFC is attempting to
clarify the issue of service interfaces in such a way that in any
conformant implementation, there will at least be the potential for the
error report to actually be put to use.  For the case of UDP it is
required that the ICMP error be passed back to the application whose
datagram inspired it.  Whether the application makes any intelligent
use of it is an application layer issue.  See sections 3.4 and 4.1.3.3
of the HR RFC draft.  Latest edition of this draft is dated April 17, 1989.

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

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 May 89 18:03:45 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on MIDI?

Has anyone ever played with the idea of doing TCP/IP over MIDI lines?
(MIDI, for those unfamiliar with it, is a 31250 bps asynchronous current-
loop ring network meant for computer control of music hardware; it's a
standard feature on some prominent non-IBM personal computers like the
Atari ST.)  SLIP and friends should be directly applicable.

(Speaking of which, is there any new word on "son of SLIP", or are we
all going to be doomed to using various incompatible hacked-up extensions?)
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 18:40:30 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

In article <8905021526.AA03195@oliver.cray.com> dab@opus.cray.com (Dave Borman) writes:
>The problem here is not with the remote machine, but with the local
>telnet implementation.  The way that things should work is:
>	User types ^C
>	Local telnet translates that to, and sends, IAC IP,
>		and then sends IAC DO TIMING-MARK and begins to
>		flush all output.

How is the local telnet supposed to know that ^C is the appropriate
interrupt character for the remote machine?  Many systems permit the
interrupt character to be set by the user or a program.  I don't think
the TELNET protocol specifies a way to transmit this change to the
client.

Also, the above assumes there's only one kind of interrupt.  On Unix,
there's ^C (interrupt), ^Z (suspend), and ^\ (quit).  They all need
output flushed, but they can't all send IAC IP.

What's really needed is a way to send out-of-band data to the telnet
client, telling it to ignore output until it reads a mark.  Is it
possible to use the URGent flag to implement this?

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 18:52:19 GMT
From:      sob@watson.bcm.tmc.edu (Stan Barber)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Telnet problems with Bridge CS/1's

In article <1805@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes:
>We also have problems with Bridge telnet handling of <CR><NUL>.
>On some versions of their software it is broken.  They know about it
>but refuse to supply fixed software.  More recent versions are capable
>of doing the "right thing".  It is configurable in case you want to do
>the wrong thing.

This is a confusing paragraph. 3com has fixed the problem, but refuse to
supply the software. Is that the point? Perhaps you don't have a service
contract. They are reasonable good about suppling updates if you are on
a service contract.

Most companies will not just give software away (check out Sun's dot-dot
releases), but they will give it to service-contracted sites and usually
sell it to others.

Is this not your experience?

>-- 
>Dan Schlitt                        Manager, Science Division Computer Facility
>dan@ccnysci                        City College of New York
>dan@ccnysci.bitnet                 New York, NY 10031
>                                   (212)690-6868


Stan           internet: sob@bcm.tmc.edu         Baylor College of Medicine
Olan           uucp: {rice,killer,hoptoad}!academ!sob
Barber         Opinions expressed are only mine.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 19:03:29 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   # instructions per packet


    Anyone know how many instructions a DEC LANBridge 100 requires to switch
an Ethernet packet?

Craig

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 20:42:43 GMT
From:      boomer@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re: Some alternatives to OSI

In article <12490838760.31.PADLIPSKY@A.ISI.EDU> PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes:
>Nice metaphor ... BUT everybody knows why Presentation is there (where
>everybody = all Old Network Boys, who, because they understand both Telnet
>and how the NVT notion was used in FTP, readily grok doing virtualization/
>devirtualization in a modular fashion, even if they don't think it should
>be a mandatorily separate layer that mechanizes it [and given things like
>the Common ASE, neither, apparently, do some key New Network Kids]).

Yow! anybody want to diagram that one?

(Talk about groking layered virtualization/devirtualization in a modular
fashion!  Holy parenthesis, batman!)

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 21:08:54 GMT
From:      pritch@tut.cis.ohio-state.edu (Norm Pritchett)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: Seeking advice on establishing a LARGE centralized mail system


I'd like to thank all those who answered my query regarding the
subject of this posting.  For those who wanted me share what I found,
that will be forthcoming -- I still have messages coming in at a
steady rate and I'd like to wait for them to trickle off before I
share. 

From the collective responses I got I was able to devise a pretty good
scheme.  I won't share it yet because some ideas are still being
hashed out among some fellow networking folks on campus but if you are
familiar with DND there's a lot of similarity to that.

In my original posting I (intentionally) didn't present an accurate
idea of the size of userbase we had to address because I didn't want
to disuade some people from responding just because they thought their
system wouldn't work for us.  I mentioned 4 figures or larger in my
message -- what we really need is a scheme that will comfortably
handle a population in excess of 75,000.  If some of you have thought
about trying to develop such a system this large but have been
disuaded for some reason or another (I've heard from a few such
places) I think we've got something for you... stay tuned.
-- 

Norm Pritchett, The Ohio State University College of Engineering Network
Internet: pritchett@eng.ohio-state.edu	BITNET: TS1703 at OHSTVMA
UUCP: pritch@sydney.columbus.oh.us	CCNET: ENG::PRITCHETT (6172::PRITCHETT)

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 21:12:47 GMT
From:      cheng@homxc.ATT.COM (W.CHENG)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: TCP/IP versus OSI

A side note of the TCP/IP vs OSI discussion.  I wonder if someone can
point to me where protocol conversion between IP and ISO CLNP is
discussed or done.  I'm interested in protocol conversion in general but 
IP <--> CLNP in particular.  Any help or info. is very appreciated.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 21:36:27 GMT
From:      mullen@itd.nrl.navy.mil (Preston Mullen)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking advice on establishing a LARGE centralized mail system

The Andrew Message System at Carnegie-Mellon University has a component
called "White Pages" that employs a fuzzy name recognition mechanism.
According to the author, Craig Everhart <cfe+@andrew.cmu.edu>, it
"matches name variants to people's names reasonably well without any
pre-identification of the possible variants of everybody's names."
(By the way, the + in his address is a flag that bypasses the smart
name recognition.)  The Andrew Message System is built on top of the
Andrew File System, but the White Pages name recognition component is
easy to separate out.

When I asked about this in October, I was told that the software is owned
by IBM and that the licensing policy had not yet been determined.

I had hoped (and still hope) to use this kind of name matching in a
general approach like that recently suggested by <mar@ATHENA.MIT.EDU>
in his message to tcp-ip of Mon, 1 May 89 13:28:20 EDT.  One might
want to set things up so that an address with exactly one match on
the wrong component (e.g., first name only) would result in a response
similar to the one sent for ambiguous names; in such a case, it might
be better to force the sender to confirm the intended addressee than
to deliver to the wrong person.

	Preston Mullen
	Laboratory for the Study of Human-Computer Interaction (Code 5530)
	Naval Research Laboratory
	Washington DC 20375

P.S.  There is probably a better mailing list than tcp-ip for this topic,
      but which one?

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 22:50:25 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP_UNREACH_PORT

In article <8905021609.AA00846@lear.ultra.com> wayne@ultra.UUCP (Wayne
Hathaway) writes about not understanding why he got some ICMP port
unreachables.

The system you tested against was behaving quite properly, both
according to the specs and according to the intentions.

The port unreachables aren't meant to go to some logging host, they're
meant to go back to the system that generated the packets that
couldn't be delivered. Port unreachable is an error indication
mechanism so that UDP-based applications can find out that no one was
home on the other side. Otherwise, there's no way for UDP to tell. You
could do this for TCP, too, but TCP explicitly uses the TCP reset
mechanism, instead.

IP doesn't and shouldn't send these messages. The layering works like
this: UDP gets a packet, checks if there's something listening on the
destination port. If there is, it delivers it, no problem. If there
isn't, it asks ICMP to generate a port unreachable message.

IP should send PROTOCOL unreachables. I don't have a copy of the IP
RFC handy, so I'm not going to double check on what the actual text
says.

Anyway, 4.3 is doing things correctly here.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@xx.lcs.mit.edu
"We had some good machines/But they don't work no more" - Shriekback

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 22:53:47 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Follow-up to my ICMP_UNREACH_PORT question

Well, I got several responses to my question the other day of "Why
does UDP bother returning an ICMP_UNREACH_PORT and why does IP care
about ports anyway?"  Some were copied to tcp-ip and (apparently) some
were not, so bits of the following may be obscure.


1) I was in fact aware of TCP's RST; having a catch-all "something is
wrong" built into the protocol does NOT preclude sending additional
information, in this case via ICMP.  Especially since RST means a lot
of things OTHER than "nobody listening on the port" -- check pages
33-37 of RFC 793 some time.  (I'll admit I have trouble seeing how the
information would always get back to the correct user, but then see
item 3 below.)


2) On the other hand, it sure seems to me that the TCP protocol IS the
correct place for the basic RST function, and in fact I would argue
that UDP is the correct place for its equivalent.  In other words, why
didn't the UDP designers include a "UCMP" that operated at the correct
level?  Several commenters alluded to "layering violations" and
"warts" and the like, and it seems to me it basically boils down to a
choice of having a small but more specific wart built into every
protocol or having a small number of big catch-all warts that various
layers may or may not be able to use.  No particular argument as to
which approach is better, just the observation that either one is
likely to get very dirty.

Philosopher A:  Every protocol that provides delivery based on
                something like a port should include some mechanism
                WITHIN THE PROTOCOL for notifying senders of delivery
                errors. 

Philosopher B:  But UDP is a pure datagram protocol; it has no concept
                of notifying senders of ANYTHING.

Philosopher A:  Then why does it try to use ICMP to do something that
                wasn't important enough to include in UDP itself?

Philosopher B:  Because it is there?!?

Hmm ...


3) Several commenters pointed out that what is expected is that the
receiving UDP, noticing that there is nobody to receive the datagram,
sends the ICMP_UNREACH_PORT back to through the various IPs to the
sending UDP, whose responsibility it is to notify the sending
application.  In fact, one person pointed me to section 4.1.3.3 of the
draft Host Requirements RFC, where it states that "UDP MUST pass ICMP
error messages that it receives from the IP layer transparently up to
the application layer."  [Emphasis in the original.]  Here I have a
couple of problems, one minor and one major.

The minor problem:  What does "transparently" mean?  That I must pass
EXACTLY the bits of the ICMP message itself, which would require that
every application be able to parse ICMP messages, or can I translate
it into something more reasonable for my environment (such as a few
coded parameters or an errno or even a signal)?

The major problem:  How on earth is the sending UDP going to know what
application sent the original datagram???  Sure, it has the sending
port number, but what's to stop the following:

    Process A:    socket();
                  bind(local_port_X);
                  sendto(...);         <----|
                  exit();                   |
                                            |
    Process B:    socket();                 |
                  bind(local_port_X);       |
                                            |
Along about now an ICMP_UNREACH_PORT from here comes roaring in --
exactly what does UDP do with it?  Poor Process B is definitely NOT
going to be expecting it, and if (as one commenter suggested) it
generates a SIGPIPE, boy is Process B gonna be surprised!  [A couple
of the comments mentioned this as well.]

Based on this, I would like to recommend that the authors of the Host
Requirements RFC reconsider section 4.1.3.3.  Also they should add
precise definitions of terms like "transparently."


4) Finally, a nit but an important one (if that makes any sense!).  In
one response, ames!earth.cray.com!droid (Andy Nicholson) says "TCP and
UDP protocols make a lot of assumptions about how IP works in order to
gain some performance improvements, like sticking in a partially
filled IP header at the front of the TCP or UDP packet that is passed
on to IP."  I must strongly disagree:  the TCP and UDP *PROTOCOLS* do
NOT make any such assumptions; certain *IMPLEMENTATIONS* may well do
so.  Clearly the idea of preallocated skeleton headers and the like is
implementation, not protocol.


Anyway, an interesting bit of repartee; I think the bottom line is
that error notification is not pretty regardless of how it is done,
and there are arguments to support both sides.  Cheers.


  Wayne Hathaway            
  Ultra Network Technologies     domain: wayne@Ultra.COM
  101 Daggett Drive            Internet: ultra!wayne@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!wayne
  408-922-0100


PS:  Actually, I do have one continuing question:  Could some BSD guru
out there please tell me if the BSD UDP in fact DOES notify anyone
when it gets an ICMP_UNREACH_PORT, and how?  I've got the 4.3 source
but not the familiarity to answer this definitively.  I don't SEE any
such notification, and there is no EPORTUNREACH sys/errno.h, but ...
Thanks!


PPS:  Note that I believe that "PORT unreachable" is fundamentally
different from "HOST unreachable" or "NETWORK unreachable."  For "port
unreachable" the message HAS gotten to the appropriate protocol layer
in the correct host; true peer-to-peer communication IS taking place,
so the peers themselves CAN discuss the error with no outside help.
(As mentioned, whether they SHOULD do so is subject to discussion.)
For the other two, there is NO peer-to-peer communication so any error
reporting MUST involve outside help.  Nuff (too much?) said.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 May 89 23:40:00 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP_UNREACH_PORT

In article <8905021609.AA00846@lear.ultra.com> wayne@ultra.UUCP (Wayne Hathaway) writes:
>And second, what is IP doing talking about ports anyway???

I think that ICMP is providing this as a service to higher-level
protocols that have no way of doing this on their own.  It's not
necessarily a waste of bandwidth; when using an unreliable datagram
protocol, a client is likely to retransmit the operation if it doesn't
get a response.  One ICMP Port Unreachable message is better than a
half dozen retransmitted UDP packets.  Of course, if the protocol is
one-way with no response expected, this is an extraneous packet;
however, that style is generally only used with broadcasts, which also
don't prompt the port unreachable response, so it's probably OK.

>  Also I note that TCP does
>not seem to ever send an ICMP_UNREACH_PORT.)

TCP doesn't need it, because it has its own protocol for indicating an
invalid port (it sends a RST packet).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 02:36:50 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on HP-IL?

Has anyone ever played with the idea of doing TCP/IP over HP-IL?
(HP-IL, for those unfamiliar with it, is a 1 Mbps asynchronous
current- loop ring network meant for small low-power devices such as
the HP-41 calculator; I recently picked up an HP-IL interface for the
IBM-PC.)  SLIP and friends should be directly applicable.

(Henry -- I'm only partially teasing -- it would be an interesting hack --
maybe I could start a competition for the smallest machine on the Internet?
But anyway, Phil Karn's NET would work nicely as a router -- all you would
need is a MIDI packet driver.  Send me a MIDI interface for the PC and
programmer's docs and I'll write one.)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
I'm a right-to-lifer -- everyone has a right to earn a living sufficient to
feed himself and his family.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 02:53:01 GMT
From:      djm@lupine.UUCP (Dave Mackie)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP_UNREACH_PORT


	Well, you are a bit off-base on your description of the ICMP
	error logging mechanism. ICMP messages are logged (at least 
	in BSD) down in the IP/ICMP code itself. There is no network 
	error logger program that listens on a special port for ICMP 
	error messages.

	Also, the information contained in an ICMP Port Unreachable message
	is not useless. The problem is that (at least in BSD again) most 
	applications using UDP simply send their packets out using the 
	sendto() system call and use the parameters of that call to specify 
	the destination. That's great if your application is going to be
	sending packets all over creation and you only want to have the 
	overhead/complexity of a single socket. But that's not always the
	case for many applications. The problem with this approach is that the 
	poor networking code doesn't remember where you sent your packets,
	and therefore can't correlate any incoming ICMP port unreachable 
	messages with your application. So what generally happens is the
	application retransmits it's UDP packets for a while and then
	gives up. All the while the kernel is getting ICMP port unreachable's
	from the other host. This results in extra network traffic, and the 
	user waiting around for the !@#$ application to timeout.

	Now the solution to this situation is to have the application
	do a connect() to the destination. Yes, you can do a connect
	on a UDP socket. It just tells the networking code who you will
	be talking to with this socket, without generating any actual
	network traffic. Then the application can use send() instead of
	sendto(). When it attempts to reach a non-existent service on
	the destination host, it *does* get notification of the ICMP
	port unreachable message, and voila it can stop wasting everybody's
	time, and report the problem to the user. Now obviously this model
	doesn't work for every type of application, but it does for quite
	a few.

	In the case of TCP, the TCP spec gives the implementor a nastier
	more direct way of indicating displeasure about the destination
	port number. It sends a RESET back to the source machine. Now
	that should get it's attention!

						Dave Mackie
						Network Computing Devices
						djm@ncd.com
		

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 May 89 10:39:41 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        dab@vax.ftp.com, tcp-ip@sri-nic.arpa
Subject:   Re:  TELNET Buffering Woes
It's always nice to do some homework, so I finally did some of mine.

The April 17 draft of the Host Requirements document essentially places
the burden onto the server, since different operating systems need
different details.  The client cannot know which choice is correct.

The HR doc specifies that client Telnet SHOULD have the option of
flushing output, after an IP.  (Personally, I believe the SHOULD should
be a MUST; the impact of not having this feature is enormous.)

Unfortunately, the client is the one that must choose what sequence to
send, so the HR recommends that the sequence be user-configurable.

The Choices listed are:

1.  Urgent(IP, AO, DM); that is, Interrupt Process, Abort OUtput, and
Synchronize the output, via the Data Mark;

2.  Urgent (IP, DM), DO TM; the Abort Output is not sent from the server
telnet to its own operating system, but the Data Mark does a degree of
buffer flushing and the Timing Mark request synchronizes.

3.  Both

Seems to me that this is too important an area to leave this fuzzy.  The
pain of having output continue is significant and greatly reduces Telnet's
credibility.  On the other hand, I don't have any suggestion for how
to improve the spec.

Dave
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 06:20:10 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

What Chuck Hedrick described (flush when the OS sees a flushing
character) is what rlogin does now (and has done since 4.2, although
it was buggy then) in BSD.  It does work and does not cause trouble
for Emacs users, nor for those who like the Rand editor, or run
various modem protocols over the network login.  But it is not
as efficient as it might be.

One should be able, with a (relative) minimum of hassle, to emulate
the terminal driver state at the far end of a network link.  This
has been possible in other systems, but not in BSD, because the
PTY driver refuses to cooperate by telling user processes about
state changes.  This is not too hard to fix, and one of these days
it will be fixed.  (As of now it is possible to see state changes,
but only by asking continually---not the nicest thing to do on a
multiprocessing system.)

Chris

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 09:51:24 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on HP-IL?

In article <NELSON.89May3223650@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>(Henry -- I'm only partially teasing -- it would be an interesting hack --
>maybe I could start a competition for the smallest machine on the Internet?
>But anyway, Phil Karn's NET would work nicely as a router -- all you would
>need is a MIDI packet driver.  Send me a MIDI interface for the PC and
>programmer's docs and I'll write one.)

Hey, if my toaster is going to run TCP, then your calculator and
Henry's synth should be able to, too...

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 May 89 19:47:25 -0400
From:      rcoltun@trantor.UMD.EDU (Rob Coltun)
To:        ficc!peter@uunet.uu.net, tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP on MIDI?
> Has anyone ever played with the idea of doing TCP/IP over MIDI lines?

>> MIDI is one-way... 

This is so but from a composition/performance point of view, an N-way 
real-time international performance or jam session (via a higher layer protocol 
that used MIDI) is quite an interesting idea.

---rob
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 13:22:50 GMT
From:      cheng@homxc.ATT.COM (W.CHENG)
To:        comp.protocols.tcp-ip
Subject:   IP <--> ISO CLNP

A question about TCP/IP vs OSI.  I wonder if someone can point to me
where protocol conversion between IP and ISO CLNP is discussed or
done.  I'm interested in protocol conversion in general but  
IP <--> CLNP in particular.  Any help or info. is very appreciated. 

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 13:25:44 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <1989May3.180345.6936@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> Has anyone ever played with the idea of doing TCP/IP over MIDI lines?

MIDI is one-way... there's no return path for acks. Why not just leave the
MIDI adapter out of the loop and run the baud rate up on your RS232 SLIP?

(one reason a fast serial port that can be trivially adapted to MIDI levels
is more useful than a dedicated MIDI port.)
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 13:41:36 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

The usual objection to having ^C send an IAC and cause output flushing
via timing marks is that ^C, like any ascii character, has multiple
context-dependent meanings on the server end.  What I think this
discussion is missing is the observation that much telnet traffic these
days originates not from terminals and RS232-connected devices but from
PCs and workstations running user telnet.  In such environments, it is
fairly easy to have a local key sequence (Hyper-ctrl-C, ^]s iac^M,
PF34, mouse on the interrupt button in your window, or whatever) that
is assigned to generate a telnet interrupt character.  In such an
environment there is no particular need for the new telnet options,
since a user can generate either ^C or IAC; presumably the USER knows
what state her program on the server is in, and so knows what she wants
to send!

My question:  how many server telnets "correctly" (as defined by DAB)
handle receipt of IAC with timing marks?  How many client telnets correctly 
handle generation of timing marks when the user sends IAC?

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 14:00:44 GMT
From:      pearce@tycho.yerkes.uchicago.edu (Eric C. Pearce)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip attacks


We are trying to assess the risks of certain types of network attacks for
our local network.

Several attack strategies based only on the tcp/ip protocol suite were
recently described by Bellovin [ACM Computer Communication Review,
Vol. 19, No. 2, pp 32-48, April 1989].

My question is:  does anyone know of any successful or attempted
attacks on an internet host based on the generic problems with the
tcp/ip protocol suite itself, such as those described by Bellovin?

--

     - Ecp

       Eric C. Pearce, Yerkes Observatory, University of Chicago.
       pearce@tycho.yerkes.uchicago.edu  or  pearce@oddjob.uchicago.edu

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 15:01:10 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  human factors aspects of echo delay

Amanda,

In my obstreperous youth I happened to be a real live disk jockey for
commercial radio working my way through school. We had an initiation
rite for new guys that involved earphones, a tape machine and a live
news broadcast. The victim, wearing cans and listening to himself
on a live broadcast, was switched without warning to a tape playback
delayed maybe 250 milliseconds, which of course instantly discombobulated
him. It happened to me, of course, with my reaction ripping the cans
off my head after stumblebumming the six o'clock news and with the
control-room guys laughing their heads off. My conclusion is that about
250 ms is just about the resonance point of the the human feedback control
system.

Dave

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 15:39:41 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Datagram issues (ICMP Port Unreachable & Fragmentation)

Re: ICMP port unreachable:

It is quite convenient to be able to give up on a domain name lookup or
an NFS mount when you get the ICMP error back indicating that no server
is running.  "Black Hole" style failure modes are a bane to network
maintainers and software support personnel, so we've put considerable
effort into making as many errors as we can visible to the user.

Re: "never seen a datagram lost on a LAN"

I have.  Admittedly, most of them have been due to fast vs. slow network
interfaces, but I also have seen cables swamped by broadcast wars, the
massive collision caused by a whole NFS cluster seeing an RWHO packet at
the same time, Ethernets where the cable was a little out of spec (too long)
where 1 in 10 packets were lost, etc. etc.  If you own the LAN on which
software which expects no datagrams to be lost runs, I suppose it's your
own lookout, but I'd never consider *selling* such a design.

jbvb

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 17:15:25 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  fragmenting broadcasts

Dave,

I think there is probably a bug in the current wording in Section 3.3.3
of the Host Requirements RFC on fragmentation.  It was not meant to
outlaw intentional IP fragmentation in the source host -- but it certainly
did mean to DISCOURAGE it!

I gather your application will be used ONLY across a single Ethernet, with no
gateway hops, in an environment which is sufficiently constrained that
you assume reliable delivery from the link layer.  You're sure no site
will ever try to run it through a gateway (leading to congestive losses).
There is an enormous amount of experience that such ideal enironments
don't last; customers want to use the fact that these are INTERNET
protocols, and your assumptions collapse into a "puddle of glup."
You then discover you have to provide some reliable delivery in the
application, in which case the fragmentation/reassembly needs to be
in the same layer, or performance becomes terrible.

The Host Requirements Working Group would welcome your input on the
wording of the section you are concerned with.  Our mailing list is
ietf-hosts@nnsc.nsf.net.

Bob Braden

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 17:39:41 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

It's always nice to do some homework, so I finally did some of mine.

The April 17 draft of the Host Requirements document essentially places
the burden onto the server, since different operating systems need
different details.  The client cannot know which choice is correct.

The HR doc specifies that client Telnet SHOULD have the option of
flushing output, after an IP.  (Personally, I believe the SHOULD should
be a MUST; the impact of not having this feature is enormous.)

Unfortunately, the client is the one that must choose what sequence to
send, so the HR recommends that the sequence be user-configurable.

The Choices listed are:

1.  Urgent(IP, AO, DM); that is, Interrupt Process, Abort OUtput, and
Synchronize the output, via the Data Mark;

2.  Urgent (IP, DM), DO TM; the Abort Output is not sent from the server
telnet to its own operating system, but the Data Mark does a degree of
buffer flushing and the Timing Mark request synchronizes.

3.  Both

Seems to me that this is too important an area to leave this fuzzy.  The
pain of having output continue is significant and greatly reduces Telnet's
credibility.  On the other hand, I don't have any suggestion for how
to improve the spec.

Dave

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 21:39:23 GMT
From:      bruce@THINK.COM
To:        comp.protocols.tcp-ip
Subject:   IP record route

I was just debugging some routes from our Nearnet gw with the Cisco ping
command, which allows one to turn on IP options like "record route".  

I began just pinging a friendly Sun4 at NRL (on 128.60) without any IP
options on, and the machine was responding fine.  But when I tried it with
record-route on, it stopped responding to any pings for quite a while, even
subsequent ones without record on.  Since I can't seem to reach any
machines on that net after the experiment, I assume the target machine
didn't crash, but it seems as if I might be crashing a gateway along the
way with record-route!

I did this twice with the same results.  I can reach that net again after
about 10 minutes.  If anyone had a couple of unexpected gateway crashes
today, the last about 5pm, this could explain it.

--Bruce Walker (Nemnich), Thinking Machines Corporation, Cambridge, MA
  bruce@think.com, think!bruce, bjn@mitvma.bitnet; +1 617 876 1111

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 21:44:56 GMT
From:      bernsten@phoenix.Princeton.EDU (Dan Bernstein)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   BSD UNIX authd

Does anyone have a working BSD 4.2 or 4.3 authentication daemon?
As per RFC 931, the daemon should accept connections to port 113
(directly or through inetd), read a line of two numbers as in

  6191,23

and output a line like one of

  6191,23:USERID:UNIX:shmoe
  6191,23:ERROR:NO-USER

where ``shmoe'' is the owner (on the client machine) of the connection
between port 6191 on the server and port 23 on the client. (Notes: (1)
The example in the RFC has the client requesting ``23,6191'', which seems
a bit weird. (2) Whitespace can be put anywhere. (3) All of \,: must be
backslash-escaped within the userid. (4) The RFC doesn't specify very
well what a ``line'' is but CR LF is probably safe.)

---Dan Bernstein, bernsten@phoenix.princeton.edu

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 21:55:41 GMT
From:      boomer@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip attacks

In article <PEARCE.89May4090044@tycho.yerkes.uchicago.edu>,
pearce@tycho.yerkes.uchicago.edu (Eric C. Pearce) writes:

>We are trying to assess the risks of certain types of network attacks
>for our local network. [cite's Bellovin article] My question is: does
>anyone know of any successful or attempted attacks on an internet
>host based on generic problems with the tcp/ip protocol suite
>itself, such as those described by Bellovin? 

Whether anyone *has* employed a given attack method is of principle
interest to historians.  It sounds to me like you are trying to design
a network for the future, not than discuss the one of the past.  If
you want a vote on whether people agree that the vulnerabilities he
describes are real, then you have at least one "yes" ballot.

(imagine trying to explain to your employer/users that you decided to
ignore a known weakness simply because you had never heard of anyone
exploiting it...)

ps.  For the rest of the tcp-ip community... it's an excellent paper,
and it isn't very long.  As the add says, "if you only read one paper
this year, make it _Security_Problems_in_the_TCP/IP_Protocol_Suite_,
by S.M. Bellovin in the ACM Computer Communication Review, Vol. 19,
No. 2, pp. 32-48, April 1989."
--
     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   boomer@SPACE.MIT.EDU      77 Massachusetts Ave   37-618   |
     |   (617) 253-7457            Cambridge, MA 02139             |

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 22:46:13 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: human factors aspects of echo delay

Van Jacombson claims 100-200 ms and cites Ben Schneiderman's "Designing the
User Interface" as a reference.

-Ron

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 May 89 22:53:02 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

The IETF Point-to-Point working group has pretty much finished
the protocol.  The RFC was just circulating around the members
for final editorial changes.  It should be publically dissemenated
soon.

I guess I'm not letting too much out of the bag in saying that
it is essentially HDLC framing (using the Addendum 1 Async
stuff for async lines).  It is designed to be used for all
serial point-to-point lines thus replacing slip and higher
speed sync line protocols.  There is a protocol byte (extendable
to two bytes) for demuxing on protocol.  Most of the document
deals with the line initialization stuff like how you decide
on IP addersses between the two side etc...

-Ron

You're not serious about IP over MIDI are you.  It's major drawback
is that MIDI is UNIDIRECTIONAL!  While IP can be done that way, it
makes TCP a little interesting.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 03:18:58 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   FTP continuation lines.

I just had a user complain that his FTP client gets confused now that
I added continuation lines to my version of KA9Q's FTP server.  Are
there FTP clients extant that don't understand continuation lines?

p.s. I'm still looking for FTP clients that do RESTart and MODE B.

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

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 12:12:13 GMT
From:      pnessutt@nis.mn.org (Robert A. Monio)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip attacks

In article <11134@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
>ps.  For the rest of the tcp-ip community... it's an excellent paper,
>and it isn't very long.  As the add says, "if you only read one paper
>this year, make it _Security_Problems_in_the_TCP/IP_Protocol_Suite_,
>by S.M. Bellovin in the ACM Computer Communication Review, Vol. 19,
>No. 2, pp. 32-48, April 1989."

Okay.  I want one.  How may I obtain it??

Please respond via e_mail.  Thanks for your help.

 -Bob


-- 
 Robert A. Monio                     
 National Information Services, Inc.   "The most valuable commodity that I   
 pnessutt@nis.mn.org                    can think of is information."
 ..uunet!rosevax!nis!pnessutt                 -- Gordon Gecko, Wall Street 

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 14:22:00 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

> How is the local telnet supposed to know that ^C is the appropriate
> interrupt character for the remote machine?  Many systems permit the
> interrupt character to be set by the user or a program.  I don't think
> the TELNET protocol specifies a way to transmit this change to the
> client.

The whole idea of the IAC IP and the NVT is that you don't need to know
what the interrupt character on the remote side is.  You type the
interrupt character that is most natural to use on the client side of
the connection, it gets turned into IAC IP, and the server translates
the IAC IP into whatever is appropriate on the server side to cause an
interrupt.  Hence, if you are on your Unix machine, and you telnet to
some machine running foobarOS, you can type ^C and know that you will
interrupt the process on the remote side, regardless of what the
interrupt character on the remote side is.

> Also, the above assumes there's only one kind of interrupt.  On Unix,
> there's ^C (interrupt), ^Z (suspend), and ^\ (quit).  They all need
> output flushed, but they can't all send IAC IP.

Bingo.  You win the prize.  The 4.3BSD telnet uses BRK to send ^\, and
IP to send ^C.  It also has an option on the client side so that you
can tell the client what each character is.

There is a new option, LINEMODE, which add the capablity for both sides
to be in sync as to what character should be used for telnet code.  It
also adds three new new codes, ABORT, SUSP, and EOF, which on a Unix
machine would map to ^\ (quit), ^Z (suspend) and ^D (end-of-file).

You can probably expect to see the new RFC out sometime later this
month, a BSD implementation will also be made available (which I am
currently working on finishing up).  A draft version is available
for anonymous ftp from uc.msc.umn.edu, in pub/linemode.draft  (This
is NOT the final version.  The SLC area is changing).  Watch for
future announcements.

> What's really needed is a way to send out-of-band data to the telnet
> client, telling it to ignore output until it reads a mark.  Is it
> possible to use the URGent flag to implement this?
>
> Barry Margolin
> Thinking Machines Corp.
> 
> barmar@think.com
> {uunet,harvard}!think!barmar

It already exists.  It's called the "Synch" signal in RFC854, see
page 8.  A "Synch" consists of an IAC DM sent in urgent mode, and
causes the reader(client) to discard input (server output) until
it reads the IAC DM.


			-Dave Borman	dab@cray.com

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 May 89 15:53:11 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <May.4.18.53.01.1989.1967@ron.rutgers.edu> ron@ron.rutgers.edu (Ron Natalie) writes:
>You're not serious about IP over MIDI are you.  It's major drawback
>is that MIDI is UNIDIRECTIONAL! ...

So are most ring networks, at the wiring level.  Same solution:  tie the
end back to the beginning.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 16:04:00 GMT
From:      barmar@THINK.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes


    Date: Fri, 5 May 89 09:22:00 CDT
    From: dab@opus.cray.com (Dave Borman)

    > How is the local telnet supposed to know that ^C is the appropriate
    > interrupt character for the remote machine?  Many systems permit the
    > interrupt character to be set by the user or a program.  I don't think
    > the TELNET protocol specifies a way to transmit this change to the
    > client.

    The whole idea of the IAC IP and the NVT is that you don't need to know
    what the interrupt character on the remote side is.  You type the
    interrupt character that is most natural to use on the client side of
    the connection, it gets turned into IAC IP, and the server translates
    the IAC IP into whatever is appropriate on the server side to cause an
    interrupt.  Hence, if you are on your Unix machine, and you telnet to
    some machine running foobarOS, you can type ^C and know that you will
    interrupt the process on the remote side, regardless of what the
    interrupt character on the remote side is.

That is a long-obsolete view of TELNET.  In most cases the user wants a
transparent connection to the remote machine; the local system's
keyboard conventions should be ignored and the user should have the
illusion of being connected directly to the server.  This is the
generally-accepted interpretation of BINARY option when the client is a
terminal emulation application.  If the TELNET client application wants
to be able to permit the user to invoke these IAC operations, that can
be done using some local escape (e.g. ~<char> on Unix, <Network> on
Symbolics Lispms, menus on windowing systems).

    > Also, the above assumes there's only one kind of interrupt.  On Unix,
    > there's ^C (interrupt), ^Z (suspend), and ^\ (quit).  They all need
    > output flushed, but they can't all send IAC IP.

    Bingo.  You win the prize.  The 4.3BSD telnet uses BRK to send ^\, and
    IP to send ^C.  It also has an option on the client side so that you
    can tell the client what each character is.

I thought BRK was obsolete (i.e. "old TELNET").

    > What's really needed is a way to send out-of-band data to the telnet
    > client, telling it to ignore output until it reads a mark.  Is it
    > possible to use the URGent flag to implement this?

    It already exists.  It's called the "Synch" signal in RFC854, see
    page 8.  A "Synch" consists of an IAC DM sent in urgent mode, and
    causes the reader(client) to discard input (server output) until
    it reads the IAC DM.

I thought I remembered it from somewhere.  But since
seemingly-knowledgeable people were proposing more complex things, I
thought I might have been wrong.

                                                barmar

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 17:32:53 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes



	The Choices listed are:

	1.  Urgent(IP, AO, DM); that is, Interrupt Process, Abort OUtput, and
	Synchronize the output, via the Data Mark;

	2.  Urgent (IP, DM), DO TM; the Abort Output is not sent from the server
	telnet to its own operating system, but the Data Mark does a degree of
	buffer flushing and the Timing Mark request synchronizes.

	3.  Both

	Seems to me that this is too important an area to leave this fuzzy.  The
	pain of having output continue is significant and greatly reduces Telnet's
	credibility.  On the other hand, I don't have any suggestion for how
	to improve the spec.

	Dave

Dave,

Unfortunately, there seemed to be cogent arguments for each of the 3 
choices!

   Bob Braden

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 18:11:30 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP record route

In article <8905042139.AA01559@mozart.think.com>, bruce@THINK.COM writes:
> I was just debugging some routes from our Nearnet gw with the Cisco ping
> command, which allows one to turn on IP options like "record route".  
> 
> --Bruce Walker (Nemnich), Thinking Machines Corporation, Cambridge, MA
>   bruce@think.com, think!bruce, bjn@mitvma.bitnet; +1 617 876 1111

Using `ping -R` (derived from the BRL version) is entertaining  and has
been helpful to me in the continuing Butterfly wars.  One can often infer
which version of 4.xBSD networking a system is running by whether it ignores
the RR option when it responds, or does not respond at all.  Unfortunately,
I know of only sgi.sgi.com and brl.mil which answer with routes.  Would it be
possible to compile a list of geograpically dispersed machines (modulo the
network topology) which usefully answer Record-Route Echo-Requests?

Traceroute is handy, but does not satisfy the same needs.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 18:40:19 GMT
From:      melmon@hpindda.HP.COM (Paul Melmon)
To:        comp.protocols.tcp-ip
Subject:   Does anyone use RFC-1038 ??


Hi,

I am looking for information from people who have implemented
RFC-1038 (IP Security Enhancements). Has anyone been able to
use RFC-1038 to pass labels in a multi-vendor environment ??
Are people using RFC-1038 at all ??
Any information would be appreciated.


Paul Melmon
Hewlett-Packard
Information Networks Division
(408) 447-3657

melmon@hpinddf.hp.COM
hplabs!hpda!melmon

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 20:19:41 GMT
From:      lyndon@cs.AthabascaU.CA (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   uucp over ethernet

A number of sites on the internet are advertising "uucp" connections
with other internet sites. My understanding is that they actually
run uucp over ip. I have run across a number of UNIX systems that
have entries for "uucpd" in /etc/services, however there doesn't
seem to be any consistency in the tcp port numbers being used for this
service. Also, the connection protocol doesn't seem to be documented.

I would like to find out what port these sites are using, and what
sort of handshake they go through upon connection, prior to starting
up uucico. Please email and I'll summarize.
-- 
Lyndon Nerenberg   Computing Services   Athabasca University
{alberta,attvcr,ncc}!atha!lyndon  ||  lyndon@nexus.ca

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 21:06:41 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <May.4.18.53.01.1989.1967@ron.rutgers.edu> 
 ron@ron.rutgers.edu (Ron Natalie) writes:
>
>You're not serious about IP over MIDI are you.  It's major drawback
>is that MIDI is UNIDIRECTIONAL!  While IP can be done that way, it
>makes TCP a little interesting.

	All you have to do is explain simplex links to your router.
This isn't so hard.  I have talked to your favorite router vendor
about adding this capability to their product.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 22:19:43 GMT
From:      dab@opus.cray.com (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   IETF TELNET working group


This is an announcement that the IETF (Internet Engineering Task Force)
will be forming a new working group to address the TELNET protocol.

In the last six months to a year, there has been a lot of interest in
the TELNET protocol, a lot of new options have been proposed, and a lot
of discussion has gone into how to make TELNET better.  The purpose of
this working group will be to collect the current uses and wishes for
TELNET, and produce one or more RFCs to address these issues.

One possible outcome from this working group would be to issue a new
RFC on TELNET that would obsolete RFC 854.  Also, some new TELNET
options may be added to fix problems/limitations that people are
currently having with TELNET (an option to allow automatic user
authentication is needed).

This group will have its first meeting at the next IETF meeting (at the
end of July at Stanford).  There will be a mailing list for this working
group, and that is what this message is for.  I hope that a lot of the
discussion will happen over the mailing list, even before the first
meeting of the group.  I am going to start a list of names for the
mailing list.  Send me your name if you want to be on this mailing list.
When the mailing list is formed, you will receive mail about where the
mailing list is located (and there will probably be another announcement
on tcp-ip).  Also, please indicate whether or not you are involved in
the IETF and would be at the next meeting.

Send your requests to dab@cray.com, or, if you don't have nameserver
and MX record support, dab%cray.com@uc.msc.umn.edu.

		-Dave Borman, dab@cray.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 May 89 22:21:21 GMT
From:      d.jba@harald.ruc.dk (Jan B. Andersen)
To:        comp.protocols.tcp-ip
Subject:   Problem with telnetting from NCR Tower w/Exelan to DG AOS/VS host

I have a small problem which only occurs when I telnet to the DG
host from the NCR Tower. Output stops every 1/2 page but I can resume it
by sending any character.

Local telnet-status says:

  .......
  Do suppress go aheads (GAs).
  Remote echo.
  Ascii mode

Changing 'Do suppress...' to 'Do not suppress...' don't help (what GAs mean).

Any ideas?

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 01:50:25 GMT
From:      charles@c3pe.UUCP (Charles Green)
To:        comp.protocols.tcp-ip
Subject:   Is there a wordsize/parity standard for SLIP?

I just finished tying a MightyFrame (5.22 CTIX) to a Gould via SLIP.  To do it,
I have two 'dd' processes hanging off two otherwise-unused ports on the S320:
the port which is the input to one 'dd' and the output to the other is 'stty'ed
to cs8 parenb (for connection to the CT's SLIP side via a 2-inch null modem),
the other port is cs8 -parenb to talk to the Gould, which doesn't use the even
parity that the MightyFrame does.

Though this is less than efficient, without the appropriate source code, I see
no other solution.  But this made me wonder:  Is there a standard for word
size, parity, or number of stop bits on SLIP?  And which of these variations
are out there on what vendor's systems?

I'll be glad to summarize Emailed responses if there's interest...  thanks.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 01:57:13 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   BSD UNIX authd

Amazing --

I wrote the "Authentication Protocol" about 4 years back, mainly as an
intellectual excercise.  I was interested in trying various different
ways of tracking a "user" through a group of networked systems.  I
implemented (in PL1 !) a server and client for Multics, played around
with it for a while, and haven't done anything with it since.  

I've had occassional queries about it, but not in the last 2 years or
so.If I had it to do over again, I would have not bothered to put it
on top of a telnet like connection, or to worry about making it work
from a "telnet foo 113" type connection (the main reason for the wierd
syntax -- I was lazy).  

I'd be interested in finding out if anyone ever implemented this, and
what use they made of it.

Mike

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 04:54:00 GMT
From:      jain@erlang.DEC.COM (Raj Jain, DEC, 550 King St., Littleton, MA 01460)
To:        comp.protocols.tcp-ip
Subject:   New reports on congestion, address caching, and address hashing available

The  following  three  DEC  technical  reports  are   now   available   for
distribution.


DEC-TR-566: `A   Delay-Based   Approach   for   Congestion   Avoidance   in
            Interconnected Heterogeneous Computer Networks,' 16 pages.

DEC-TR-592: `Characteristics of Destination Address  Locality  in  Computer
            Networks:  A Comparison of Caching Schemes,' 14 pages.

DEC-TR-593: `A Comparison of Hashing Schemes for Address Lookup in Computer
            Networks,' 15 pages.

If you would like to receive a copy, please send me a message with  subject
field  containing  the  word DEC-TR along with the report numbers you want.
The message should be simply your US (or foreign) Mail address such that it
can  be  used directly on a mailing label.  Any other words or sentences in
the message will simply delay the delivery.

Softcopies in Postscript are also available but they seem to print only  on
LPS40  printers.   To  receive  softcopies  include  the  word LPS40 in the
subject field.  Please include your US Mailing address anyway.  In case  of
network problems, hard copies will be mailed.

Thanks.

                    Raj Jain
                    Digital Equipment Corp.
                    550 King St.  (LKG1-2/A19)
                    Littleton, MA 01460


Detailed abstracts of the reports are as follows:


                                DEC-TR-566
            A Delay-Based Approach for Congestion Avoidance in
              Interconnected Heterogeneous Computer Networks
                                by Raj Jain

In heterogeneous networks,  achieving  congestion  avoidance  is  difficult
because  the congestion feedback from one subnetwork may have no meaning to
sources on other subnetworks.  We propose using changes in round-trip delay
as an implicit feedback.  Using a black-box model of the network, we derive
an expression for the optimal window as a function of the gradient  of  the
delay-window curve.

The problems of selfish optimum and social optimum are also addressed.   It
is  shown  that without a careful design, it is possible to get into a race
condition during heavy congestion, where each  user  wants  more  resources
than others, thereby leading to a diverging condition.

It is shown that congestion avoidance using round-trip delay is a promising
approach.   The  approach  has  the  advantage  that there is absolutely no
overhead for the network itself.  It is exemplified  by  a  simple  scheme.
The  performance  of  the scheme is analyzed using a simulation model.  The
scheme is shown to be efficient, fair, convergent, and adaptive to  changes
in network configuration.

The scheme as described works only for networks which can be  modeled  with
queueing servers with constant service times.  Further research is required
to extend it for implementation in practical networks.  Several  directions
for future research have been suggested.


                                DEC-TR-592
   Characteristics of Destination Address Locality in Computer Networks:
                      A Comparison of Caching Schemes
                                by Raj Jain

The size of computer networks, along  with  their  bandwidths,  is  growing
exponentially.    To  support  these  large,  high-speed  networks,  it  is
necessary to be able to forward packets in a few microseconds.  One part of
the  forwarding  operation  consists  of  searching through a large address
database.  This problem is encountered in the design of adapters,  bridges,
routers, gateways, and name servers.

Caching can reduce the lookup time if there is a locality  in  the  address
reference  pattern.   Using  a  destination  reference trace measured on an
extended  local  area  network,  we  attempt  to  see  if  the  destination
references do have a significant locality.

We compared the performance of MIN, LRU, FIFO, and random cache replacement
algorithms  and found that the interactive (terminal) traffic in our sample
had quite different locality  behavior  than  that  of  the  noninteractive
traffic.   The interactive traffic did not follow the LRU stack model while
the noninteractive traffic did.  Examples are shown of the environments  in
which  caching  can help as well as those in which caching can hurt, unless
the cache size is large.


                                DEC-TR-593
            A Comparison of Hashing Schemes for Address Lookup
                           in Computer Networks
                                by Raj Jain

The trend  toward  networks  becoming  larger  and  faster,  and  addresses
increasing  in  size,  has impelled a need to explore alternatives for fast
address recognition.  Hashing  is  one  such  alternative  which  can  help
minimize  the  address search time in adapters, bridges, routers, gateways,
and name servers.

Using a trace of address references, we compared the efficiency of  several
different  hashing  functions and found that the cyclic redundancy checking
(CRC)  polynomials  provide  excellent  hashing  functions.   For  software
implementation,   Fletcher  checksum  provides  a  good  hashing  function.
Straightforward folding of address octets using the exclusive-or  operation
is  also  a  good  hashing function.  For some applications, bit extraction
from the address can be used.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 15:27:35 GMT
From:      d.jba@harald.ruc.dk (Jan B. Andersen)
To:        comp.protocols.tcp-ip
Subject:   Problem with telnetting from NCR Tower w/Excelan to DG AOS/VS

I have a small problem with Excelan's telnet for the NCR Tower.
It only occurs when I telnet to a DG machine running AOS/VS.
NCR to Sun's and Vax's works fine, and so does Vax and Mac to DG.

When I do a 'cat', 'ls' or anything else that outputs more than a couple
of lines, output seems to be suspended every 1/2 page, just as if I had
been using 'more' or 'pg'. Pressing SPACE, NL, CR or any other key,
gives me the next 1/2 page. The characters are not used by the DG host,
istead they are put in the normal input buffer and are used as part of
the next command.

Local telnet-status says:

  .......
  Do suppress go aheads (GAs).
  Remote echo.
  Ascii mode

Changing 'Do suppress...' to 'Do not suppress...' don't help
(whatever those GAs are).

Any ideas?

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 16:44:14 GMT
From:      evan@BRAZOS.RICE.EDU (Evan Wetstone)
To:        comp.protocols.tcp-ip
Subject:   Re: IP record route

It has been our experience that sending an ICMP ECHO with IP options turned
on through a Sun (SunOS 3.5 or lower, we haven't tested it with 4.0) that
has two Ethernet interfaces will immediately crash the Sun.  If anyone 
between you and NRL is using a Sun-3 with two interfaces, you probably
crashed it with that ping.....


Evan Wetstone
Networking and Planning
Rice University, PO Box 1892, Houston TX, 77251-1892, (713) 527-6059
evan@rice.edu, evan@rice.bitnet, rice!evan, postmaster@rice.edu

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 18:57:49 GMT
From:      royc@ami.UUCP (roy crabtree)
To:        comp.protocols.tcp-ip
Subject:   Re: human factors aspects of echo delay

In article <01-May-89.183043@192.41.214.2>, amanda@lts.UUCP (Amanda Walker) writes:
[elided]
> time" of conscious processing is about 1/20th of a second, i.e. events
> occurring at 50ms intervals are greater can be perceived as separate
> events, whereas events occurring at shorter intervals are perceived
> as simultaneous, depending somewhat on what kinds of events are being
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> correlated.  For example, a video terminal running at 300 baud in
> full duplex gives most people the illusion that the letters are appearing
> as they type (66ms).  However, motor skills (such as tracking moving

The event sync rate on output must be about 2* the event input rate if more
than one event is to be tracked, or if parallel events are being tracked;
otherwise, a single serial event on output will perceive under _low_stress_
conditions as 'simultaneous' if it within around 1-1.5 input event intervals
after the _end_ of the input event correlated with it.

Several military studies correlate this; sorry, no refs.

> objects) involve much more fine-grained timing (hmm... hardware buffers :-)?)

Yep, may be needed for speed.  Again, the reason is that the event being perceived
is correlated, not against the keyboard input event, but against the eye/screen
coordinative cognition that _follows_ it; since the granularity of the eye is
spatially higher, it tends to be temporally higher as well (udderwise ya caint do
nuthin wid it anyways so why bother seing it?)

> For example, animation at 60 or 120 frames/sec will look much smoother and
> more "realistic" than at 30 frames/sec, even if there's no consciously
> perceptible flicker...

Hurray, Disney!  (Frame rate minimums of 31-36 FPS preferred)

> 
> Part of the point of this is that how fast the feedback needs to be depends
> a lot on what you're feeding back.  Keystrokes can probably get by with
> 50-80ms.  Rubber-band lines need to be 15-30ms, and so on.

This is true.  However, the rates are still too slow, I would think.
The rationale I have is as follows:

	- You can perceive whart you can do.
	- A musician can play (i.e., do) music
	  at tempos of up to 240-300 beats per minute:  5 times per second.
	- The beat may be subdivided 2-4 times (or more!) at those
	  rates for individual notes: 20 times per second (from which
	  comes the 50 millisecond figure)
	- Positive correlative events (things you have to perceive against
	  prior to actions subsequent and dependent on them for correct function
	  or response) usually should have no more that a 5-10% transit
	  delay against the response interval, to avoid upsetting the
	  goal oriented resonse of the operator involved.  This should also
	  apply in terms of a spatial perception sense:  The position of hte
	  item being viewed or tracked or clicked or stretched should be no more
	  5-10% of the _immediate_significant_visual_field_ off in terms
	  of timing.

		So, for character IO, since you do not correlate
		but every so often (you don't read every character!)
		50 msec is probably OK (but better 25!)

		But for rubber band lines, 10-25 msec under rapid mouse
		drag motions.

		And for supercritical events, such as a popdown or "gotcha!"
		notification for mouse clicks or state transition, probably
		3-8 msec is what is needed for "smooth" perception.

If anybody doubts this, try using any old mouse driven terminal with a
polled mouse at 60 Hertz clock rate; it is easily possible to click and
release the mouse in 1/60th of a second:  if you can, then 1/120 of a second
is the basic event rate, and 1/2 that (4 msec) is the minimum to achieve
_perceptibly_continuous_motion_.

> 
> --
> Amanda Walker
> InterCon Systems Corporation
> amanda@lts.UUCP / lts!amanda@uunet.uu.net

roy a. crabtree uunet!ami!royc 201-566-8584

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 May 89 01:13:49 EDT
From:      Bruce Crabill <BRUCE@UMDD.UMD.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP on MIDI?
You can't put MIDI into a ring, all your synthesizers would have a fit.
Yo Ron!  Are you done with my MPU-401 yet?  Time to work on a IBM channel to
MIDI interface...

                                       Bruce
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 May 89 21:21:30 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: fragmenting broadcasts

>Date: Thu, 4 May 89 10:15:25 PDT
>From: braden@venera.isi.edu

...
>I gather your application will be used ONLY across a single Ethernet, with no
>gateway hops, in an environment which is sufficiently constrained that
>you assume reliable delivery from the link layer.  You're sure no site
>will ever try to run it through a gateway (leading to congestive losses).
>There is an enormous amount of experience that such ideal enironments
>don't last; customers want to use the fact that these are INTERNET
>protocols, and your assumptions collapse into a "puddle of glup."
>You then discover you have to provide some reliable delivery in the
>application, in which case the fragmentation/reassembly needs to be
>in the same layer, or performance becomes terrible.

...

>Bob Braden

It's not just only on an Ethernet without ever going through a gateway.
Many people these days bridge ethernets together with low cost bridges
that may drop packets under severe load.  Also, other bridge
ethernets with low speed (56 Kb) serial lines.  I am aware of
certain circumstances where some bridges will drop packets in
bridge queues in cases involving topology changes, and in cases
of congestion.  Also, losses on serial lines between bridges can
also introduce lossage...

So it's any sort of packet switch involved.  Gateways certainly
aren't the only source of packet attenuation!

					Thanks,
					   Milo

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 May 89 21:34:17 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <4076@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>MIDI is one-way... there's no return path for acks. Why not just leave the
>MIDI adapter out of the loop and run the baud rate up on your RS232 SLIP?
>(one reason a fast serial port that can be trivially adapted to MIDI levels
>is more useful than a dedicated MIDI port.)

The one-way issue is solved by forming a ring.  (Although the once-around
delay on the ring will be substantial, which is one reason why I asked if
anyone had tried it yet -- most ring networks I know of run at rather higher
speeds.)

As for RS232, a fully-RS232C-conforming driver cannot in fact run much
faster than 20 kbps (vs. MIDI's 31250) reliably.  Read the fine print about
slew rate.  Older driver chips often don't limit the slew rate properly
and can be pushed to higher rates under good conditions, but newer chips
(like the MAX232) follow the standard.  With short cables and a favorable
phase of the moon they'll sometimes run at 38400, but that's about it.  To
get reliable serial transmission at speeds much higher than MIDI, you need
to abandon RS232 anyway.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 May 89 00:57:50 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with telnetting from NCR Tower w/Excelan to DG AOS/VS

In article <27@harald.UUCP> d.jba@harald.ruc.dk (Jan B. Andersen) writes:
>I have a small problem with Excelan's telnet for the NCR Tower.
>It only occurs when I telnet to a DG machine running AOS/VS.
> ...
>When I do a 'cat', 'ls' or anything else that outputs more than a couple
>of lines, output seems to be suspended every 1/2 page, just as if I had
>been using 'more' or 'pg'...

Almost certainly this has nothing to do with Telnet, but is a feature of
the DG host.  Such built-in terminal paging is not uncommon; a number of
people (myself included) have implemented it on various Unix systems, on
the theory that potentially-valuable output should not run off the screen
without permission.  (Please note:  tcp-ip doesn't seem the right place 
to debate the correctness of this theory.)
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 03:42:56 GMT
From:      paul@UXC.CSO.UIUC.EDU (Paul Pomes, I'm the NRA!)
To:        comp.protocols.tcp-ip
Subject:   Re: Some advice on establishing a LARGE centralized mail system

The Computing Services Office at the University of Illinois at Urbana is
in the process of creating a university-wide mailing system.  The system
is comprised of three pieces.  The largest is the white-pages system
created by Steve Dorner of CSO.  It's based on the CSnet central name
server (qi - Query Interpreter).  Each student and staff member is assigned
a unique alias.  The user is allowed to change the issued alias provided
it remains unique.  Associated with this alias is the user's preferred
email address, office address, home address, phone numbers, etc.  Everything
that is in the paper phone book is also in the qi database.

The user client is a program called ph.  It searches on the unique alias
and can fuzzy match on names.  Providing ancillary information such as
department or curriculum narrows the search.

The second piece is the 5.61+IDA sendmail release.  The ida/cf/Sendmail.mc
has been very slightly modified to invoke a new mailer, phquery, whenever
an address resolves to <name>@uiuc.edu.  This is configured with the
DOMAINMASTER option.

Phquery is the third piece.  It examines its arguments and calls qi to
determine the preferred email address for the supplied name.  At this point,
name can be only the unique qi alias.  This restriction will soon be lifted
to allow phquery to resolve full names (e.g., paul-pomes@uiuc.edu ->
paul@uxc.cso.uiuc.edu), and amateur radio callsigns (e.g., ka9wgn@uiuc.edu ->
phil@vmd.cso.uiuc.edu).  In the case of ambiguous matches, phquery will
return a list of possibilities that includes department and/or curriculum
information that should allow the sender to make the next attempt successful.

Future enhancements include automated printing and campus mailing of
messages to those users w.o. email addresses.

Source for the qi (central server) and ph (user client) can be obtained
via anon-FTP from uxc.cso.uiuc.edu:/net/{ph,qi}.  The phquery code,
when ready, will be included in the /mail/sendmail/uiuc directory.

Sorry, we cannot email this code as it is much too large.  Chocolate chip
cookies with a postpaid tape will work wonders though.

         Paul Pomes

UUCP:     {att,iuvax,uunet}!uiucuxc!paul     ICBM: 40 06 47 N / 88 13 35 W
Internet, BITNET: paul@uxc.cso.uiuc.edu      Phone: 217 359 0881
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801-2987

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 05:13:49 GMT
From:      BRUCE@UMDD.UMD.EDU (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

You can't put MIDI into a ring, all your synthesizers would have a fit.
Yo Ron!  Are you done with my MPU-401 yet?  Time to work on a IBM channel to
MIDI interface...

                                       Bruce

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 05:38:20 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  human factors aspects of echo delay

Dave,

Just to illustrate the amazing adaptability of the human brain, users of the
AMSAT Oscar-13 satellite routinely monitor their own signals coming back
from the satellite as they speak. The round trip delay is just about 1/4
second, the same as your tape-delay trick, since at apogee the satellite is
at about geostationary altitude.

It takes some getting used to (the first night AO-10's transponder switched
on was VERY amusing, to say the least) but it's surprising how quickly you
adapt. Just as I've gotten used to the echo delay over my SLIP line. Not
that I *prefer* it that way, of course...

Phil

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 19:30:02 GMT
From:      bob@tinman.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: human factors aspects of echo delay

Though delayed sidetone (feedback of one's own speech through
headphones) is tough on an individual, delayed full-duplex vocal
transmission causes all sorts of new social conventions to arise.

I've held conversations over circuits that the telephone company
generously routed via satellite, even though the call only went
between Columbus and Boston.  None of the normal socially-induced
timings that we Americans use to decide when the other person is done
speaking seemed to work, because we'd both jump into the silence at
the same time that we heard the other person start speaking.  This
caused lots of awkward backoffs and retries until we figured out what
was happening.  At first, I just figured it was normal east-cost
asocial rudeness :-)

The line quality was good enough that we couldn't tell from the
transmission carrier itself whether the other person had "lifted his
thumb from the mike".  So we both, fairly naturally it turned out,
fell back into the old half-duplex radio conventions of terminating
each thought-chunk with "Over".  This got us through several calls in
the course of a week and finally that vendor's hardware and my
backplane were happy with each other.  The other people in the office
got quite a kick out of overhearing my side of the conversation.

Perhaps this means that interactive clients and servers will need
better characters-per-packet batching algorithms for higher-delay
networks, with local half-duplex feedback and appropriate "I'm done
now" signals on both ends...

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 19:42:26 GMT
From:      bob@tinman.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   MIDI on UDP? (was Re: TCP/IP on MIDI?)

Hmmm... how about encapsulating MIDI on UDP?  Rythm synchronization
could come from the NTP fuzzclocks - lending a new meaning to the term
"chiming".  If mazewar, nntp, nfs, and irc aren't enough to swamp the
NSFnet, perhaps an intercontinental jam session could help :-)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 May 89 22:42:44 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP on MIDI?

The aid in experimentation of TCP/IP over MIDI, I point out that it
is trivial to turn a Sun 3/50 into a MIDI controller.  It turns out
that the serial port controller can be set "close enough" to the
MIDI speed.  ADB your kernel and look at:

	zs_speed+1e?d

This is the EXTB speed.  By default the divisor will be 3 (for 38400).
If you change it to 2, you will get 30720 which is only 1.7% shy of
the desired 31250.  Poke it or change you sources if you've got them
(devsun/zs_async.c).

Then with half a dozen parts, and some simple software you can be
reading/writing MIDI (we did exactly this here).  The biggest weakness
of a Sun as a MIDI controller is the default HZ resolution of 50 Hz.
It is noticeably rough to the ear.

I guess one would have to send IP packets in MIDI System Exclusive
messages.  Anyone thought about ARP yet to map IP addrs to MIDI ports? :-)

- Phil
phil@brl.mil
uunet!brl!phil

ps: My apologies for keeping this discussion going.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 May 89 23:24:28 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Feynman on standardization

From the concluding essay ("The Value Of Science") in Richard Feynman's
last book, "What Do *You* Care What Other People Think?":

	Our responsibility is to do what we can, learn what we can,
	improve the solutions, and pass them on.  It is our respon-
	sibility to leave the people of the future a free hand.  In
	the impetuous youth of humanity, we can make grave errors
	that can stunt our growth for a long time.  This we will do
	if we say we have the answers now, so young and ignorant as
	we are.  If we suppress all discussion, all criticism, pro-
	claiming "This is the answer, my friends; man is saved!" we
	will doom humanity for a long time to the chains of authority,
	confined to the limits of our present imagination...

For some reason this made me think of a number of current standardization
efforts, notably ISO networking, X.400 and sons, and the X/NeWS standards
war.  I can't imagine what the connection could be... :-) :-) :-)
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 May 89 16:20:27 EDT
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        pcip@udel.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Fixed version of NCSA 2.2TN for 3c523 card now available.

There have been many requests for a version of NCSA telnet 2.2D/2.2TN
that would work on PS/2 3C523 cards.  I have found the bug in the 3c523
driver and made available the tn3270 binary via anonymous ftp
from omnigate.clarkson.edu  :/pub/ncsa2.2tn/tn3270.exe.Z

This binary has been tested and does work with the 3c523 card.

This file is also available via E-mail from 

	archive-server@sun.soe.clarkson.edu

	send  ncsa2.2tn Index


The index file has detailed instructions for retrieving this working binary
and reconstructing the uuencoded files.

Sorry for the delay in making this announcement, I was hoping to get in a
major upgrade before wasting network bandwidth with this announcement.

Thanks to everyone who has sent in bug reports etc, keep your complaints
and comments coming. They're helpful.  Also, I have not made available
a fixed version of telbin.exe or ftpbin.exe (no one has expressed an
interest) if there is drastic need for these two programs on your
3c523 equipped machine, please let me know.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 14:13:00 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <1989May6.213417.20756@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> As for RS232, a fully-RS232C-conforming driver cannot in fact run much
> faster than 20 kbps (vs. MIDI's 31250) reliably.  Read the fine print about
> slew rate.

OK, RS-232 style EIA. Something-that-looks-like-RS232 that puts data on pins
2 and 3 of a DB-25. Let's not get too picky about details.

> With short cables and a favorable
> phase of the moon they'll sometimes run at 38400, but that's about it.

The 262000-baud maximum on the Amiga serial port must be an illusion, then.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 14:43:15 GMT
From:      simon@hhb.UUCP (simon chan)
To:        comp.protocols.tcp-ip
Subject:   Ethernet + TCP/IP driver

HELP!HELP!
I need some helps to locate the following items:
	(1) The device independent TCP/IP software driver.
	(I can put in the ethernet layer, and the board control software).
	(2) Company that sell only the TCP/IP package and the hardware 
		controller (with source) for VME and AT type bus 
		system with unknown cpu.
	(3) Company that sell the firmware for this. I have heard that there
		is a company implemented the whole network scheme independent
		to the HOST OS and CPU. 
		I mean the whole thing in the ethernet board's prom and 
		provide only entrance point to the prom.

thanks!
p.s. please include the cost, phone and address if possible.

			Simon Chan
			princeton!hhb!simon
			201-848-8000

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 15:40:53 GMT
From:      balenson@TIS.COM (David M. Balenson)
To:        comp.protocols.tcp-ip
Subject:   Sequence numbers provide security?? (Bellovin's article)


I have read with interest Bellovin's article on "Security problems in the TCP/IP
protocol suite".  However, my interest diminished while reading the first
section on "TCP sequence number prediction".  I don't see the relevance of
this attack to authentication.  My understanding of TCP sequence numbers is that
they are used during connection establishment to guarantee (1) that both the
client and server are ready to transfer data and (2) that they agree on initial
sequence numbers.  Since when are initial sequence numbers supposed to
be used for authenticating the identity of either the client (or server),
anc hence prevent an intruder from impersonating a trusted host?
The entire point of the discussion (and I presume Morris' original article,
which I am trying to track down a copy of) is moot unless one assumes
the ISNs are used for authentication.  Furthurmore, even if I could not
guess the servers ISN, couldn't I still spoof a trusted host by simply
(e.g, on a Sun workstation) configuring my machine to look like (i.e.,
same name, perhaps same IP address) the trusted host?  The key to preventing
(or detecting) spoof attacks is the proper authentication of unique identities,
yet this is not discussed (or mentioned).  So, either I am missing something or
the article is missing something (e.g., a simple statement of assumptions,
up front).  I'd appreciate any clarification anyone can offer.  Thanks.

-David M. Balenson
 Trusted Information Systems, Inc.
 (301) 854-5358

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 18:27:52 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

It certainly seems reasonable to use a special function key or a
two-key sequence to generate telnet IP and do the timing mark dance,
as you have suggested.  That way, you haven't preempted ^C, and it can
be used in Emacs and other programs as normal.  However at least in
BSD Unix, the telnet interrupt option may not always work.  It simply
stuffs a ^C into the terminal input.  If you're in a raw-mode program,
this may well not have the desired effect.  However it's still a
sufficiently useful thing that it makes sense to implement.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 19:26:15 GMT
From:      djm@lupine.UUCP (Dave Mackie)
To:        comp.protocols.tcp-ip
Subject:   Re: Follow-up to my ICMP_UNREACH_PORT question

> PS:  Actually, I do have one continuing question:  Could some BSD guru
> out there please tell me if the BSD UDP in fact DOES notify anyone
> when it gets an ICMP_UNREACH_PORT, and how?  I've got the 4.3 source
> but not the familiarity to answer this definitively.  I don't SEE any
> such notification, and there is no EPORTUNREACH sys/errno.h, but ...

        This isn't pretty! IP receives the ICMP message and eventually
        calls udp_ctlinput(). UDP then use inetctlerrmap[] (ip_input.c)
        to map the ICMP type to a BSD error number. In this case ICMP
        PORT UNREACHABLE gets mapped to ECONNREFUSED. The routine
        in_pcbnotify() then gets called to find the correct pcb to
        deliver the error to. If your just using sendto() then there is
        no pcb with the correct source/destination address pair in the pcb
        list, and so the error message gets dropped.
 
                                                Dave Mackie
                                                Network Computing Devices
                                                djm@ncd.com
 

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 19:28:30 GMT
From:      estrin@OBERON.USC.EDU
To:        comp.protocols.tcp-ip
Subject:   DEC-TR

DEC-TR-566
DEC-TR-592
DEC-TR-593

Deborah Estrin
Computer Science Department mc0782
University of Southern California
Los Angeles, CA 90089

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 19:58:04 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TANDEM Tn3270

Afternoon all,
		Anyone out there in the terminal emulation world know of any
TANDEM systems running TN3270 for their TCP/IP implementation. I'm totally
ignorant of the TANDEM environment but would REALLY appreciate anyone who
could take a moment to educate me. Please respond to me directly and I'll
summarize to the net if things are interesting enough. After all, it's
Monday, a traditionally slow mail day, so we may as well stir up the
tempest in the teapot (:*)
				THanks in advance,
						Chris VandenBerg
						ACC
						chris@salt.acc.com
						805-963-9431

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 20:20:27 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Fixed version of NCSA 2.2TN for 3c523 card now available.


There have been many requests for a version of NCSA telnet 2.2D/2.2TN
that would work on PS/2 3C523 cards.  I have found the bug in the 3c523
driver and made available the tn3270 binary via anonymous ftp
from omnigate.clarkson.edu  :/pub/ncsa2.2tn/tn3270.exe.Z

This binary has been tested and does work with the 3c523 card.

This file is also available via E-mail from 

	archive-server@sun.soe.clarkson.edu

	send  ncsa2.2tn Index


The index file has detailed instructions for retrieving this working binary
and reconstructing the uuencoded files.

Sorry for the delay in making this announcement, I was hoping to get in a
major upgrade before wasting network bandwidth with this announcement.

Thanks to everyone who has sent in bug reports etc, keep your complaints
and comments coming. They're helpful.  Also, I have not made available
a fixed version of telbin.exe or ftpbin.exe (no one has expressed an
interest) if there is drastic need for these two programs on your
3c523 equipped machine, please let me know.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 21:19:30 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes


	    The whole idea of the IAC IP and the NVT is that you don't need to know
	    what the interrupt character on the remote side is.  You type the
	    interrupt character that is most natural to use on the client side of
	    the connection, it gets turned into IAC IP, and the server translates
	    the IAC IP into whatever is appropriate on the server side to cause an
	    interrupt.  Hence, if you are on your Unix machine, and you telnet to
	    some machine running foobarOS, you can type ^C and know that you will
	    interrupt the process on the remote side, regardless of what the
	    interrupt character on the remote side is.

	That is a long-obsolete view of TELNET. 

barry,
	
Oh, really?  That comes as a surprise to me, at least.

   Bob Braden 
   

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 May 89 23:49:23 GMT
From:      ggm@brolga.cc.uq.oz (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1101

From article <8905021943.AA21368@venera.isi.edu>, by pvm@VENERA.ISI.EDU (Paul Mockapetris):
> phone number, we would need something like the IN-ADDR.ARPA tree (Which
> we might be able to get along without, just as we get along without such
> a directory in the real world).  From experience, there's a fair amount
> of work involved in standardizing the data (e.g. include area code?,
> international code?, extensions?), especially if you want an Internet
> standard.

Since the X.500 standards define encodings for many of the real-world data 
types one wants to store in a directory service, and the NS is offering such 
hugely aligned functionality, surely RFC's could be used to define mappings 
from the OSI DS object family into suitable Bind record types?

Existing Bind definitions stay as-is. New ones where possible adopt forms
"compatible" with X.500 defined objects.

Lots of wins from this approach.

Parallel Proposal:  Is anyone going to define "authorised" mappings from
POSIX or other standard unix data structures into ASN.1? There is a huge
crossover period when we can all expect to have to pass data to and from
Internet to OSI aligned systems. One global mapping across all RFC-compliant
systems would aid things hugely here. 

The problem is ASN.1's richness allows more than one form for structured
data. (analogous to choosing arrays or structs or linked lists) Rather than
have two groups define divergent forms for one structure eg stuct passwd,
there should be one RFC-defined mapping, and if possible procedure bindings 
to do en- and de-coding.

I propose ISODE tools to be used, and an RFC to be used to collect
common data structure mappings and their associated coders. 

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

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 00:16:03 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence numbers provide security?? (Bellovin's article)

Being able to predict TCP sequence numbers is relevant because it
allows one to be able to give commands over a one-way link.  This
means that gateways (routers) don't provide as much security as they
seem to.  We've known for a long time that it is easy to fake IP
source addresses.  So at first glance security based on source address
doesn't look very useful.  The counterargument was always "well, sure
they can fake a source address, but the other direction will go back
to the real machine, not the imposter, so the imposter can't get a
real connection going".  If the imposter can guess the sequence number
that the other end is going to use, then it can probably dummy up an
ACK field that will let the connection stay open long enough to send a
command.  I now believe that if you're going to depend upon IP source
addresses (and from a practical point of view that may still be the
only tool some of us have), you should set up your gateways to compare
the claimed IP source address with the actual packet source.  E.g.
Rutgers might set up all exterior gateways to reject packets coming
from the outside with source addresses of 128.6.x.x (our class B
address).  Similarly, the CS department might reject all packets
physically from outside our department with a source address on one of
our departmental networks.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 01:41:50 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence numbers provide security?? (Bellovin's article)

The point of a sequence number attack is to spoof a host *if you can't
hear the return packets*.  For example, suppose we have hosts A and
B on a local net, along with gateway G.  I'm off on attacker host X,
also connected to G but on another LAN:


	A-------G---------B----------C
		|
		|
		|
		|
 X
		|
		|
		|

Suppose I want to talk to A, and impersonate B.  Normally, I can't do that,
since I can't complete the 3-way handshake -- A's replies will go to the
real B.  That is, without a routing attack, I can't persuade A to route
packets to B through G.

With a sequence number attack, though, X doesn't have to hear A's reply.
It can be predicted; thus, the third message of the open sequence can
be sent blind.  Once that's done, A thinks that the connection is open,
and from B.  X can't receive any output from the connection -- but
with the ability to use rsh to execute commands, that hardly matters.

Just rebooting C with B's IP address works on some networks, i.e.,
Ethernet cables and the like.  But there are networks where the IP
address is bound to the switching harware -- such as the ARPANET itself.
There's no way (at the IP level or above) to make the ARPANET IMPs deliver
addressed to B to C instead -- it just isn't wired that way.  But a
sequence number attack, where C claims to be B, will still work.


		--Steve Bellovin

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 02:26:26 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

Gentlemen:

I believe the initial query was how to stop output to the terminal given that
the terminal server interpreted a ^C as an IAC IP.  The fact of the matter is
that a request to interrupt a process at the remote station has little to do
with stopping or terminating the display of data at the local station.

The appropriate action is to enter the sequence, perhaps a ^O, that would be
interpreted by the terminal server as an IAC AO.  The IAC AO is a command to
the TELNET client and server to abort output which is the desired operation.

mcc

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 05:01:20 GMT
From:      carson@tron.UUCP (Dana Carson)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   xyplex terminal servers

We have a Xyplex terminal server in for a while for evaluation.  Does
anyone have any results, opinions, etc. you care to share about them ?
We are interested in both the telnet and the LAT protocols.

Dana Carson
Westinghouse Electronic Systems Group  Mail Stop 1615
UUCP: ...!uunet!umbc3!tron!carson
AT&T: (301) 765-3513
WIN: 285-3513

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 07:58:09 GMT
From:      ianh@merlin.bhpmrl.oz (Ian Hoyle)
To:        comp.protocols.tcp-ip,comp.os.vms,comp.sys.apollo
Subject:   transfer problems with ftp between Apollo & VAX

We have a problem with ftp file transfers between our Apollo (running SR10.1,
BSD4.3) and our VAX (running the Unix connection software under VMS 5.1).

The direction of transfer is from the VAX to the Apollo, and we have replicated
the problem when initiating ftp from both sides.

The file on the VAX is a sequential carriage return/carriage control ascii text
file of size 1498/1500 blocks (VAX terminology for you non-VMS'ites :-)

				BUT

when I transfer the bloody thing it comes up with a different byte count each time.
(whole segments of the file go missing).

??? what is happening ???? I thought that TCP-IP/FTP should NOT allow this
behaviour to occur.

							ian
-- 

                Ian Hoyle
     /\/\       Computer Systems Superintendent
    / / /\      BHP Melbourne Research Laboratories
   / / /  \     245 Wellington Rd, Mulgrave, 3170
  / / / /\ \    AUSTRALIA
  \ \/ / / /
   \  / / /     Phone   :  +61-3-560-7066
    \/\/\/      ACSnet  :  ianh@merlin.bhpmrl.oz.au
                Internet:  ianh%merlin.bhpmrl.oz.au@uunet.uu.net

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 09:32:46 GMT
From:      hans@duttnph.UUCP (Hans Buurman)
To:        comp.protocols.tcp-ip
Subject:   summary of b-net question

Some time ago, I asked about my university's policy regarding their B-net.
The question was whether to go for subnetting or not. This message includes
the summary I promised.

Note that I am not in charge here, I am just a worried user. All responses
I got were in favour of subnetting, although the way things were put varied.
However, the people in charge here had the following arguments:
(in random order)

- Management tools have improved in the same way as clever routers, and we
  are able to track down problems rapidly. We will be able to manage the
  unsubnetted B-net.

- Several protocols are used within faculties. This means that between
  faculties and the backbone we would have to use smart routers, which is
  much more expensive than bridges.

- All protocols are the same up to layer two. The differences are in layer
  three, where ip is just one of the protocols. All investments that are
  done now must be made in anticipation of a coming ISO standard protocol
  for layer three. If we would buy smart routers now, they would be useless
  when we went over to that standard. (I hope I phrase this well, it is not
  an area that I am familiar with. It may be that the European situation
  for standards differs from the American).

As a consequence of this, Delft University has an unsubnetted B-net since
May 1st. The fake-o subnets mentioned below have been implemented. 
So far, things are working well. Some very old tcp/ip implementations
seem unable to cope with the increased traffic (or variety of packets) on
the net. We are working on that.

I would like to thank all those who responded. If nothing else has been
gained, I have learned a lot. The responses are below.

	Hans

-----------------------------------------------------------------------------
Hans Buurman                   | hans@duttnph.UUCP
Pattern Recognition Group      |
Faculty of Applied Physics     | mcvax!hp4nl!dutrun!duttnph!hans
Delft University of Technology | tel. 31 - (0) 15 - 78 46 94
===============================================================================
Question:

My university has recently been appointed a B-class network, and is now
moving towards an unsubnetted B-net. The reason to do things unsubnetted,
I am told, is the fact that there are other protocols than tcp-ip on the
net. I am not sure, but from a unix point if view this looks like an
unpleasant solution. We will have bridges separating busy branches of the
net, but these will be transparent to broadcasts so that these will be seen
everywhere.

I am not a networking wizard, I just use unix machines (suns, mostly)
and like to do NFS mounts between different faculties. Would others
like to comment on our solution or other solutions ? I'll summarise
to the net.

===============================================================================
From: aks@hub (Alan Stebbens) <aks%nowhere@hub.ucsb.edu>

From my point of view, a subnetted Class B network is preferred to
an unsubnetted network.  In case you are not aware of the
distinction, a subnetted network is one where part of the
"official" host portion is used as a "subnet" number.  In the case
of a Class B, where the top 16 bits are the network number, and
the bottom 16 bits are the host number, the host number is further
split into two parts: the subnet number, and the "real" host
number.

In order for this to work, the routing software in IP must be
conditioned to recognized the case of a subnet, using a subnet
mask, usually 0xFFFFFF00, which extracts the complete "network
number", with which routing is performed.  Note that only the
IP-type Ethernet packets are treated this way.  The router
software can either totally ignore other protocols (most do), or
propogate them (most don't).  This is a real win for separating IP
networks from the Ether-hog DECNET.

The reason subnetted networks are preferred to non-subnetted is
that traffic within a subnetted network is contained, unless it
needs to be routed further.  Whereas, in an unsubnetted network,
any traffic to a machine, no matter how logically "close", is
transmitted needlessly to all other networks.

Bridges are useful sometimes, but less so than routers, which can
be implemented with multiple Ethernet interfaces in your
computers.  For example, in the College of Engineering, each of
our file servers (Sun 3/260) is also an IP-packet router with two
Ethernet interfaces.  The clients are all contained within the
subnet, so that all client NFS traffic is "contained" by the
subnetted Ethernet, and no one else suffers the load.  Of course,
cross mounts sometimes brings NFS traffic around to the other
subnets, but the root and swap NFS packets do not ever escape the
subnet. 

Multiple interfaces on Sun 3/260's are *much* cheaper than either
bridges or routers, and a spare Ethernet interface benefits all
such servers.  To provide similar redundancy with bridges and file
servers would require spare Ethernet boards and a spare bridge.

Multiple bridges also must be running the same kind of learning
algorithm or your bridges could cause broadcast explosions or
loops.  If your bridges do not have a learning algorithm, then
they are not as useful, and your network load becomes prohibitive.

Almost all flavors of Unix these days support subnetted IP
networks; their configuration is really pretty easy.

> Would things change very much
> if there were a couple of other protocols on the net ? In our case
> we have at least IBM and DEC protocols that I know of, and maybe
> others.

We have DECNET in Physics, ITP, Geography, and Chemistry (from DEC
VAX/VMS), and XNS (from Ungermann-Bass Net/One), as well as mostly TCP/IP.
The few cases where non-TCP/IP packet-type routing is needed is
taken care of by the appropriate software features in the routers
installed at the various "entry-points" for each department.

Our topology has a "backbone", to which nothing but gateways
(routers) are attached.  Each department specifies and configures
their own router, which makes them responsible for whatever kind of
routing they require.

In the Physics et. al. departments, they have routers which
understand routing for both TCP/IP and DECNET.  In the Engineering
departments, we have placed a router which understands only
TCP/IP, and thus we suffer neither the XNS nor DECNET packets;
Appletalk is supported as "encapsulated-IP".  The only "noisy"
subnet is our backbone Ethernet, a kind of "watering hole" for all
of our subnets.

Our philosophy is that each department routes only the desirable
kinds of packets into their subnets.  Since most departments tend
to be packet-type homogenous, this saves much network bandwidth overall.

The opposing philosophy is to route all kinds of packets
everywhere (via bridges), and let each host choose what kind to
listen to.  Our feeling is that this would tend to waste network
bandwidth within each subnet.

===============================================================================
From: dutrun.uucp!ucbcmsa.bitnet!CLIFF@rutgers.edu (Cliff Frost {415} 642-5360)

Hi,
It would be ridiculously short-sighted to build one gigantic ethernet
segment.  You can, right now, buy routers from Cisco and Proteon that
will route IP, DECNet, XNS, and many other protocols.  Cisco has a router
that will keep up with a LANBridge 100 on ethernet to ethernet packet
pushing.

The Cisco will even 'bridge' DEC's LAT packets and 'route' everything
else.  I don't know if the Proteon's do.

There used to be some semi-reasonable arguments for building one
big (multi-hundreds of hosts) ethernet instead of using routers and
multiple segments.  If there remain *any* reasonable arguments for doing
it I haven't heard them.  The technology has changed dramatically
in the last few months, so what was "common sense" a year ago is not
at all trustworthy today.

Do you really want to deal with broadcast storms on a 10 building
ethernet?

===============================================================================
From: steve@umiacs.UMD.EDU

   Whether or not you do subnetting (or something that looks like it) has
no effect on whether or not other protocols can push packets between cables.
The only thing that matters here is whether or not the boxes that connect
different cables can forward more than just one protocol.

   If you have bridges (or routers that can forward more than one protocol),
your multi-protocol traffic will show up everywhere that it's appropriate.
Bridges have the problem of forwarding too many packets; I don't like to see
broadcasts (or ARP wars, or any other garbage) from networks I don't
control, just because someone has screwed up.  (I do think that bridges are
a good idea inside of a particular administrative domain.)  Still, I suppose
this is a religious issue and, depending on the protocols you use and the
money you have available, you may not have any choice.

   One thing that you can do is allocate 'slushy' subnets.  For each cable
or administrative entity or whatever, allocate some part of the address
space to that cable/entity/whatever.  Then make sure that address in that
area are allocated from within that address space.  You should probably
still leave your netmask at the Class B default (255.255.0.0), and your
broadcast address at the most backward-compatible value possible
(unsubnetted, all-zeroes).  Note that in the latter case, you will have to
set the broadcast address at ifconfig time on newer machines.  It is better
to do that (and, thus, to be compatible with older software that doesn't
know subnetted broadcasts from a hole in the ground) than it is to suffer
from a multi-cable ARP war...

   Let's look at an example.  Consider a fictional clone of umdnet, 128.8.
Let's say that all cables are bridged together, so all traffic is still
seen everywhere, and we don't want to turn on any sort of subnet routing.
Let's assume a 'fake-o' subnet mask of 255.255.255.0.

   We might say, then, that the CS Department gets addresses 128.8.128.1
through 128.8.128.254.  Similarly, the EE folks might get 128.8.133.1
through 128.8.133.254, the campus computing folks might get 128.8.10.1
through 128.8.10.254, and so on.  This way, if you really need to put IP
routers in to replace your bridges, all you have to do is set the subnet
masks to the fake-o value (and, if you desire, change the broadcast
addresses) everywhere, and you're all set.  This is *much* less painful than
changing a few hundred IP addresses.

   I hope this is useful, and I'd be interested in any other comments that
others might have.

===============================================================================
From: hedrick@geneva.rutgers.edu

I agree with you.  Our experience is that it is good to isolate
departments behind a real router.  I would not want to have a
whole campus connected by bridges.  There are routers that can
handle several different protocols.  cisco even has a box that
will act as a router for IP and a bridge for other protocols.
I suggest that you look carefully at what protocols you really
have to support, and choose something that will route IP and
also support the other protocols.

===============================================================================
From: TKSJMI@UBVM.bitnet

 Hi Hans - we use Wellfleet Communications router/bridges with success.
 The boxes can route ip and decnet and bridge everything else, so LAT
 will interoperate in yur environment, too.

 Is Wellfleet in Europe?

 Hope this helps,
 JoAnn

===============================================================================
From: dutrun.uucp!cbmvax!swatsun!pomeranz@uunet.UU.NET (Hal Pomeranz)

I think our situation mirrors your situation (albeit on a smaller
scale), and maybe you can profit from some of what's been going on with
us.  In the middle of last year, we got our official class B status. 
Now we have essentially three different computing groups on our campus:
the CS department (the Sun-3's which I'm helping to run), the
engineering department (which uses Apollo workstations of various
varieties), and the general academic systems (a bunch of VAXes and MicroVAXes).
Now the Suns and the Apollos run TCP/IP and the VAXen are a mixed bag of
DECNet and IP hosts (actually our Suns have a lame version of DECNet, but
we really don't use it).  However, a piece of brain-damage on Apollo's
part has made it necessary for us to subnet the engineering nodes.  Despite
the fact that we have multiple protocols (well, two anyway) running around
on our ethernet, the subnetting has not been a problem.  In addition, our
bridges are NOT broadcast transparent, and we're still OK.  I hope this
helps you convince the powers that be to be somewhat more flexible...

===============================================================================
From: aronson@julessun.nlm.nih.gov (Jules P. Aronson)

Other protocols on the net should not affect the TCP/IP and in particular the
type of TCP/IP network. The decsision to use or not use subnetting rests
entirely on the TCP/IP protocol and on particlular the interaction of
the other systems and gateways on your network which use TCP/IP. Most, if
not all of the current implimentations of TCP/IP handle subnetting.

===============================================================================
From: dutrun.uucp!auspex!bootme!guy@uunet.UU.NET (Guy Harris)

That sounds a bit bizarre.  Considering the addresses in question are IP
addresses, and that all protocols running on top of IP can survive on a
subnetted network as long as the IP implementation can handle it, I
don't see why the existence of other protocols (meaning DECNET or ISO
protocols or XNS or ..., I presume?) should make a difference.

> I believe that there are non-ip protocols on the net, such as an IBM
> protocol (between pcs and mainframes) and an Apollo protocol.
> Unfortunately I cannot name them.
> 
> Could this be correct ?

Yes, there probably are non-IP protocols on the net; however, since
subnetting affects only IP addresses, whether you use subnets or not
shouldn't affect those protocols.  (Now *those* protocols may have their
*own* notion of subnetting, but I presume that'd be independent of IP
subnetting.)

There may well be a problem with subnetting due to those other
protocols; however, I don't see what it would be, since the protocols I
know of that you'd run on the network would either:

	1) run on top of IP, in which case they should, in principle,
	   not care whether the network is subnetted or not - they let
	   IP do the work and care about it

or

	2) not run on top of IP, in which case they shouldn't, in
	   principle, even know whether IP considers the network
	   subnetted or not.

It may be that the IBM protocol is something like NETBIOS on top of IP,
and the IP implementations there may not be able to handle subnetting,
in which case you might not be able to subnet - but that's not because
there are "protocols other than TCP/IP on the net", it's because there
is an IP on the net that can't handle subnetting.

===============================================================================
From: ajw@manatee.cis.ufl.edu

  Our campus network has over 500 nodes in about 50 building at this
time.  I've been the network "project leader", so to speak.  It's not
part of my official duties as manager of the comp. sci. department,
but it's something that I could do.
  There has been alot of pressure from other groups about protocols
and architectures and all that.  However, if I had it to do it "all
over again", in some official capacity, I would not hesitate to
require the following:

1) The official campus protocol is TCP/IP.
2) All connections to a campus backbone(s) are through dedicated
routers (ie. subnetting)
3) Only the official network management team will have access to these
routers.

If you do it this way, you won't be disappointed.  It's just SOOO much
easier.  TCP/IP is available everywhere and can do anything the other
protocols do.  Why fool around with anything else?  If some shop would
like to run, say, Novell, locally, fine.  But I would NOT build
support in for various protocols at the campus layer.  Support just
one between buildings.  And go for subnets.  Absolutely.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 14:26:19 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   Re:  Sequence numbers provide security?? (Bellovin's article)

Although your point on "proper" authentication is well taken, you must be
aware that many networks use a variety of ad hoc mechanisms to
provide security.  The Morris TCP number attack described by Bellovin 
is real  and takes advantage a near deterministic nature of TCP serial
numbers.  Sequence numbers in TCP is part of its reliable mechanism 
but in addition provide a poor man's data origin authentication. 

The point is that you can't trust (what ever that means) the TCP 
sequence numbers to resist an attack; however, in low threat environments 
it can be OK.  In a high threat environment with an attacker willing to do 
the work it takes to subvert TCP sequence numbers, then it's not appropriate 
and you'd want something cryptographically protected.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 14:43:34 GMT
From:      deke@canopus.ee.rochester.edu (Dikran Kassabian)
To:        comp.protocols.tcp-ip,comp.music,rec.music.synth
Subject:   Re: MIDI on UDP? (was Re: TCP/IP on MIDI?)


In article <BOB.89May7154226@tinman.cis.ohio-state.edu> Bob Sutterfield writes:
>Hmmm... how about encapsulating MIDI on UDP?  Rythm synchronization
>could come from the NTP fuzzclocks - lending a new meaning to the term
>"chiming".  If mazewar, nntp, nfs, and irc aren't enough to swamp the
>NSFnet, perhaps an intercontinental jam session could help :-)

Bob,

I see you smiling, but I wonder to what extent you jest.  I have long thought
this to be a very good idea.. at least localized to a single studio (and not
blathering all over the internet :-)

The advantages to encapsulated MIDI on, for example, 802.3 networks would
be many, including speed of transmission, ability to address single devices
uniquely, ease of managing multiple MIDI applications (no MIDI-merge).

I'm absolutely serious, and am working on something along these lines right
now.  I'd be interested in hearing from others with opinions on the usefulness
and viability of such a MIDI networking scheme.

I have expanded the Newsgroups: line to address a slightly wider audience.
(This conversation started in the tcp-ip group)  Undo my dirty work if you wish.


 ------------------------------------------------------------------------
 \\\  Deke Kassabian, URochester Department of Electrical Engineering  \\\
  \\\ deke@ee.rochester.edu                  "I never metacharacter     \\\
   \\\   or ...!rochester!ur-valhalla!deke     I didn't like......"      \\\
    -------------------------------------------------------------------------
		   "Isn't fun the BEST thing to have ?"

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 17:03:34 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence numbers... (Bellovin's article)

In article <May.8.20.16.01.1989.6980@geneva.rutgers.edu> 
hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>...  I now believe that if you're going to depend upon IP source
>addresses (and from a practical point of view that may still be the
>only tool some of us have), you should set up your gateways to compare
>the claimed IP source address with the actual packet source.  E.g.
>Rutgers might set up all exterior gateways to reject packets coming
>from the outside with source addresses of 128.6.x.x (our class B
>address).  Similarly, the CS department might reject all packets
>physically from outside our department with a source address on one of
>our departmental networks.

	Is this filtering fairly efficient on your cisco routers?
Seems to me it would be a one line access list.  Potentially very
efficient.

	I had been thinking that if you implement a spanning tree
router topology on your campus (typical spine with subnet branches)
that you could harmlessly reject all source addresses received at the
subnet gateway that did not originate from that particular attached
subnet using an access list essentially in the same way you filter
from the outside.  Then, with a secure ARP table in your gateway
(possibly built using SNMP?) you could avoid most if not all source
address masquerading.

	Am I missing anything?  Of course, the attacker may now shift
to a routing attack, network management attack, or crack the root
password on the routers, but straightforward source masquerading is
thwarted.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 May 89 18:46:46 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <4106@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> As for RS232, a fully-RS232C-conforming driver cannot in fact run much
>> faster than 20 kbps ... reliably...
>
>OK, RS-232 style EIA. Something-that-looks-like-RS232 that puts data on pins
>2 and 3 of a DB-25. Let's not get too picky about details.

RS423 isn't bad, and is good for higher speeds, but still not blazing.  To
get really high speeds you have to abandon RS232 compatibility completely.
(Even RS423 causes trouble at times, because it is compatible with things
that strictly conform to RS232 but is not compatible with every weird
aberration that sort of worked with RS232.)

>> With short cables and a favorable
>> phase of the moon they'll sometimes run at 38400, but that's about it.
>
>The 262000-baud maximum on the Amiga serial port must be an illusion, then.

No, it's the result of not conforming to the standards, pure and simple.
What is gained is speed; what is lost is reliability and interoperability.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 18:48:02 GMT
From:      stuart@rennet.cs.wisc.edu (Stuart Friedberg)
To:        comp.protocols.tcp-ip
Subject:   BSD and SunOS bug in UDP ICMP_UNREACH_PORT handling

Once upon a time, someone wrote:
> Could some BSD guru  out there please tell me if the BSD UDP in fact
> DOES notify anyone > when it gets an ICMP_UNREACH_PORT, and how?

In article <363@lupine.UUCP> djm@lupine.UUCP (Dave Mackie) replied:
> IP receives the ICMP message and eventually calls udp_ctlinput().  [...]
> The routine in_pcbnotify() is called to find the correct pcb.      [...]
> If you're just using sendto(), the error message gets dropped.

And now I add:
It's even worse than that due to a bug in (or a misuse of) in_pcbnotify().
An error is delivered to all UDP sockets bound to the remote HOST
that generated the ICMP_PORT_UNREACHABLE, no matter which remote PORT
they are bound to.

I once spent 15 minutes setting up by hand a network demo using UDP.
Someone killed one process, and the whole thing unravelled in about 4
seconds due to this bug.   Extremely frustrating!

The bug was present in 4.2 and inherited by 4.3.  It has probably
survived so long because most people don't use UDP, those who use UDP
don't bind to a remote host/port, and those who bind don't test their
code. :-) Many Unix ports based on BSD networking have it; for example,
its present in SunOS's 2.0 through 4.0.1.  I think Mt.Xinu may have
fixed it at one point in their VAX support, but I'm no longer sure.

Stu Friedberg  (stuart@cs.wisc.edu)

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 19:42:48 GMT
From:      bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
To:        rec.music.synth,comp.protocols.tcp-ip,comp.music
Subject:   Re: MIDI on UDP?

In article <2181@valhalla.ee.rochester.edu> deke@canopus.ee.rochester.edu (Dikran Kassabian) writes:
   In article <BOB.89May7154226@tinman.cis.ohio-state.edu> Bob Sutterfield writes:
      ...how about encapsulating MIDI on UDP?...

   ...at least localized to a single studio (and not blathering all
   over the internet :-)

   The advantages to encapsulated MIDI on, for example, 802.3 networks
   would be many, including speed of transmission, ability to address
   single devices uniquely, ease of managing multiple MIDI
   applications (no MIDI-merge).

You will gain all those things from working at the 802.3 level, but
you will remain (as you note) confined to a single studio or to
Ethernets linked by repeaters or bridges.

   I'm absolutely serious, and am working on something along these
   lines right now.

I would strongly encourage you to raise your sights (and protocol
levels) a bit, toward massive musical interconnectivity.  Don't set
off on such an interesting project with such self-limiting plans.
Simply replacing a single MIDI network with something that runs faster
and is more easily configurable won't give you any new capabilities.
Introducing a layer of generalized connectivity below the existing
protocols brings in entirely new possibilities.

Still, I'd love to know what you're up to!

This should probably stay in rec.music.synth, so I'll point followups
over that-a-way.  Sorry to bother the tcp-ip folks with it for even
this long...

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      9 May 89 22:31:40 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP continuation lines.


The latest, greatest versions of ftp and ftpd (for UNIX) can be obtained
from uunet.uu.net in networking/ftp.tar.Z and networking/ftpd.tar.Z

These are newer versions than those on the Berkeley networking tape.
If you are seriously using ftp or running an ftp server (under UNIX),
then you really want to get these versions.

They run on SUN SunOs3.5, SunOS4.0, Sequent Dynix 3.0.12 and most recent
BSD vax/tahoe releases. The portability problems are mainly missing
includes, etc and are quite easy to fix for other systems.

These programs have had a lot of work put into them. Among the many
changes are:
	Fully rfc959 and host requirements draft compliant
	Support for determining system type, restarting
	partial transfers in image or ascii mode, determining the
	size or last modification time of a file (via SIZE and MDTM
	which will be documented in the next version of the FTP rfc)
	ftp automatically puts you into binary mode if the remote
	server is of the appropriate type (no more user complaints
	about getting compressed files in ascii mode). 
	Support for default logins via the .netrc. E.g. you could
	put a line in your .netrc that looked like:
		default anonymous rick@uunet.uu.net
	and ftp would automatically log you in as username anonymous
	with password rick@uunet.uu.net (of course this can be overridden)
	many others.

Sites running ftp archives are especially encouraged to run this version
of ftpd. It's been running on uunet and the ucb machines for weeks and is
stable.

---rick

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 May 89 08:06:12 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   SIGCOMM Award

[Netnews appears to have hiccoughed, so I'm resubmitting this to tcp-ip]


			Call for Nominations

		       1989 ACM SIGCOMM AWARD


    This award is given annually to an individual who  has  made
    outstanding  contributions to the theory or practice of data
    communications, or whose  efforts  have  otherwise  signifi-
    cantly advanced the field.

    The 1989 award, which is the first such award and includes a
    cash  prize,  will  be  presented  at SIGCOMM '89 in Austin,
    Texas, September 19-22.  (The local contact for SIGCOMM  '89
    is Dr. Mohamed Gouda, University of Texas, Austin).

    A nomination for a candidate should include a full  vita,  a
    list  of publications, an essay on the candidate's most not-
    able contributions to the field of data communications,  and
    a  one  sentence  summary  of the candidate's contributions,
    suitable  for  an  award  plaque.   Supporting  letters   of
    endorsement, although not required, are strongly encouraged.
    All nominations will remain confidential.  Candidates do not
    have  to be members of ACM or SIGCOMM.  A description of the
    awards  process  will appear in the July '89  issue  of  ACM  
    SIGCOMM Computer Communication Review.

    Nominations are due by August 4th and should be sent to  the
    SIGCOMM  Executive Board, c/o Craig Partridge,  Bolt Beranek
    and Newman Inc., Mail-Stop 005, 10 Moulton St, Cambridge  MA
    02138. (617-873-2459).

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 04:12:08 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: BSD and SunOS bug in UDP ICMP_UNREACH_PORT handling

In fact, this same bug exists with TCP connections. If for instance,
an ICMP port unreachable is returned from a host for a TCP connection
(some IBM VM systems do this), all TCP connection to that remote host
get ECONNREFUSED dropped into so_error in the PCB.  Now, this doesn't
actually abort the connection; usually the applications choke on the
error returned the next time they reference the socket and close the
connection.  Our quick fix is to ignore port unreachable ICMP messages
for all TCP connections. 

Why return an ICMP port unreachable message (in addition to a TCP reset
segment)?  I'm assured that there is a good reason, and it has something to
do with a security option of some sort.

louie

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 04:28:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence numbers provide security??


Since presumably if someone at node Foo is trying to impersonate someone from
node Bar in establishing a TCP connection with node Dog, the replies will all
actually be sent to Bar (and Foo may never see them), Foo needs to be able to 
guess the initial sequence number node Dog will issue in order to impersonate
Bar.

The article is talking about faking a TCP connection establishment handshake
when all you're able to do is send packets that look like they originated
elsewhere -- if you can intercept all packets destined for the person you
are impersonating, authentication becomes much trickier.


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 12:06:12 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM Award


[Netnews appears to have hiccoughed, so I'm resubmitting this to tcp-ip]


			Call for Nominations

		       1989 ACM SIGCOMM AWARD


    This award is given annually to an individual who  has  made
    outstanding  contributions to the theory or practice of data
    communications, or whose  efforts  have  otherwise  signifi-
    cantly advanced the field.

    The 1989 award, which is the first such award and includes a
    cash  prize,  will  be  presented  at SIGCOMM '89 in Austin,
    Texas, September 19-22.  (The local contact for SIGCOMM  '89
    is Dr. Mohamed Gouda, University of Texas, Austin).

    A nomination for a candidate should include a full  vita,  a
    list  of publications, an essay on the candidate's most not-
    able contributions to the field of data communications,  and
    a  one  sentence  summary  of the candidate's contributions,
    suitable  for  an  award  plaque.   Supporting  letters   of
    endorsement, although not required, are strongly encouraged.
    All nominations will remain confidential.  Candidates do not
    have  to be members of ACM or SIGCOMM.  A description of the
    awards  process  will appear in the July '89  issue  of  ACM  
    SIGCOMM Computer Communication Review.

    Nominations are due by August 4th and should be sent to  the
    SIGCOMM  Executive Board, c/o Craig Partridge,  Bolt Beranek
    and Newman Inc., Mail-Stop 005, 10 Moulton St, Cambridge  MA
    02138. (617-873-2459).

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 12:49:18 GMT
From:      ruseng@iesd.dk (Carsten Ruseng Jakobsen)
To:        comp.protocols.tcp-ip
Subject:   Poor implementation of TCP/IP  or RPC on a SUN3/60 running SUNOS-4.0?


Major change of TCP performance when sending packets with sizes close
to 4096 and 8192 bytes.

While evaluating the performance of SUN-RPC, I detected the TCP
protocol slowing dramatical down when sending packets with sizes close
to the magical 4096 and 8192 bytes. The tests I ran was a simple
RPC-program with a client calling it's server with an array of some
specified size. The server routine was a null routine, doing nothing.
When the array-size was between (4045 - 4952) and (8090 - 8960) the
time used for the communication was 5 - 10 times slower than expected.
It was only the TCP protocol that suddenly had this overhead, the UDP
protocol seemed unaffected, which makes me suspect the implementation
of TCP. I tried to figure out what happened, by monitoring the net
with "traffic". I observed that
 	1] there was NO collisions on the ethernet (10Mbit)
 	2] there were NO errors detected.
 	3] none of the cpu's were working very much
 	4] none of the machines were swapping
 	5] the number of context-switches weren't very high.
 	6] #packets/sec was 25% - 50% of what I saw when
 	   sending eg 512 bytes.

From a profile of the program it can be seen that it is in the
function _write called from write_tcp that 78% of the time is used. In
the "normal" cases i expected 10% there.
 	
The experiment was performed on 3 sun3/60 workstations running
SUNOS-4.0.1. They were totally isolated from anything else in the
world. They were not running yp, neither syslog or cron.  Except from
the operating system, the only processes running was the server and
the client processes.

The tests I performed was to measure the time used for 100 RPC calls.
For each argument size the time for the 100 calls were measured 20
times, and an average calculated. The RPC-call was made using TCP and
UDP protocols. Further was it performed with server and client on the
same machine, and server and client on two different machines.  The
client called the server with an argument of N bytes.  The results I
got was:

-----------------------------------------------------------------------------
argument size|	      T C P         |		   UDP
	N    |	local	   remote   |    local		remote
--------------------------------------------------------------------------
        0    |  6,9	   7,1     |||   5,6		5,8
      512    |  8,2        9,1     |||	 6,7	 	7,6
     1024    | 10,6       11,6     |||   7,9            9,1
     2048    | 14,9       15,7     |||  10,7	       12,8
     4000    | 23,6       24,2     |||  15,6           20,0
*    4096    |174,5      199,8     |||  16,1           20,3
     8000    | 40,2       40,8     |||  26,2           34,5
*    8192    |182,8      199,9     |||  26,8           35,1
             |                     |||  
-------------|---------------------|||-------------------------------------

local = server-process and client-process reside on the same machine.
remote= server and client reside on 2 different nodes.

If you have any suggestions which explains these results, then please *please*
e-mail them to me.
-- 
------------------------------------------------------------------------------
| Carsten Ruseng Jakobsen,ruseng@iesd.dk(uucp), {...}!mcvax!dkuug!iesd!ruseng|
| Systems programmer                                                         |
|                                                                _  /        |
| Department of Mathematics and Computer Science               - / (         |
| Aalborg University (AUC)                                   /  |  \         |
| DENMARK                                                    A  U  C         |
------------------------------------------------------------------------------

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 14:06:52 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <1989May9.184646.2106@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> >The 262000-baud maximum on the Amiga serial port must be an illusion, then.
 
> No, it's the result of not conforming to the standards, pure and simple.
> What is gained is speed; what is lost is reliability and interoperability.

It certainly seems reliable and it interoperates quite happily with RS232 at
RS232 speeds, and with MIDI at MIDI speeds.

The wonderful thing about RS232 is all the subsets :->.

Do you have data to back up this claim about reliability and interoperability,
or do you just have a problem with the Amiga?
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 14:36:38 GMT
From:      sweigert@NADN2.NADN.USNA.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   tcp-ip interest group


  Can you place my E-mail address on the TCP-IP interest group
  so I can recieve mailings via the TCP-IP-RELAY ?  Thank you.

   cheers from 131.121.1.2

  US Naval Academy

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 16:40:38 GMT
From:      douglis@MINT.BERKELEY.EDU (Fred Douglis)
To:        comp.protocols.tcp-ip
Subject:   question about hanging sendmail communication

We're experiencing a problem sending mail to an internet host
(decwrl.dec.com) -- the symptom is that the mailer hangs for a long
time and then complains "reply: read error", apparently in the phase
just after it sends the body of the message.  I heard that about the
same time we started having this problem on Sprite, a small number of
Suns running SunOS 3.2 had the same problem, and I was told that
upgrading the kernel to 3.4 fixed the problem.  This is why I believe
the problem might have something to do with the TCP connection (since
just about everything at user level is the same, but the kernel is
new).

Can anyone possibly shed some light on this?  If anyone else has
experience trouble completing sendmail connections, to decwrl or to
any other hosts, I'd like to hear how they fixed the problem.  I'd be
most grateful for any suggestions.  Please include me directly in any
replies, since I'm not on the mailing list.

Fred Douglis
douglis@sprite.Berkeley.EDU, or douglis%sprite@ginger.Berkeley.EDU

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 19:04:29 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Rick Adams' new ftp and ftpd


Without detracting from the significant effort that Rick has put into
improving the BSD ftp client and server programs, I want to clarify
the situation on FTP restart in his new versions.

The standard FTP restart mechanism defined in RFC-959 requires block
mode, and is NOT implemented in the new ftpd.  Instead, Rick has
defined and implemented a stream-mode restart mechanism, that is not
defined in either RFC-959 or the Host Requirements Draft.  It is
possible that this "stream mode restart" will be added to a future
version of the FTP specification, however it is not currently a part of
any standard.

Bob Braden
Annette DeSchon

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 20:23:17 GMT
From:      dave@jplopto.uucp (Dave Hayes)
To:        comp.sys.apollo,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   SLIP for APOLLO sr9.7 and sr10.x

Has anyone ported a version of SLIP (Serial Line Internet Protocol) to 
the APOLLO for either version sr9.7 or sr10.x? Inquiring minds want to
know. Thanks in advance for the replies, please followup to comp.sys.apollo
or my e-mail box. 

============================================================================
Opinions expressed here are my own and not necessarily those of my employer. 
=-=-=-=-=-=-=-=-=-=-=-=-=<<<<<([Dave Hayes])>>>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=
dave%jplopto@jpl-mil.jpl.nasa.gov | Jet Propulsion Laboratory   M/S 300-329                
{cit-vax,ames}!elroy!jplopto!dave | 4800 Oak Grove Drive Pasadena, CA 91109   
BIX:  dhayes                      | (818) 354-1910
      "Real insight is the ability to respect relative truth without 
     damaging oneself by refusing to realize that it may be superceded"
============================================================================

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 May 89 22:22:30 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Rick Adams' new ftp and ftpd


	The standard FTP restart mechanism defined in RFC-959 requires block
	mode, and is NOT implemented in the new ftpd.  Instead, Rick has
	defined and implemented a stream-mode restart mechanism, that is not
	defined in either RFC-959 or the Host Requirements Draft.  It is
	possible that this "stream mode restart" will be added to a future
	version of the FTP specification, however it is not currently a part of
	any standard.

Those waiting for block mode or block mode restart in ftpd are
advised not to hold their breath. (The "standard" FTP restart mechanism
is clearly inadequate.)

In the mean time, restart works fine in stream mode for both image
and ascii. I expect it to be running on most of the major unix based sites
providing anonymous ftp access.

You can think of it as another non-standard service that everyone
provides (e.g. rlogin, rsh, rcp)

--rick

(Following are my proposed changes to rfc959. They have been
submitted as suggested changes, but have not been officially approved
in any way.)


	Change section 3.5 ERROR RECOVERY AND RESTART

From:
 The restart procedure is defined only for the block and compressed
 mode of data transfer. It requires the sender...

To:
 The restart procedure is defined only for the block, compressed
 and stream mode of data transfer. Block and compressed mode
 require the sender...

	Insert into section 3.5 ERROR RECOVERY AND RESTART

STREAM MODE transfers with FILE STRUcture may be restarted even though
no restart marker has been transfered in addition to the data itself.
This is done by using the SIZE command followed by the RESTART (REST)
command.

When using TYPE ASCII or IMAGE, the SIZE command will return the number
of bytes that would actually be transferred if the file were to be sent
between the two systems. I.e. with type IMAGE, the SIZE normally would
be the number of octets in the file. With type ASCII, the SIZE would be
the number of characters in the file INCLUDING any characters that
would be inserted during the CR-LF expansion.


	Insert into Section 4.1.3 FTP Service Commands


MODIFCATION TIME (MDTM)

This command returns the time the file named in its argument field
was last modified. The time is returned in ISO 3307 "Representation
of the Time of Day" format. This format is YYYYMMDDHHmmSS or
YYYYMMDDHHmmSS.xxx, where
	YYYY	is the year
	MM	is the month (01-12)
	DD	is the day of the month (01-31)
	HH	is the hour of the day (00-23)
	mm	is the minute of the hour (00-59)
	SS	is the second of the hour (00-59)
	xxx	if present, is a fractional second and may be any length
Time is expressed in UTC (GMT), not local time.

SIZE OF FILE (SIZE)

This command returns the size of the file named in its argument field.
The value returned is in a format suitable for use with the RESTART (REST)
command. This format will change depending on the current MODE and
TYPE of the connection. E.g. For mode stream and type image, it would
be a count of the number of octets that would be transferred with the
RETREIVE (RETR) command. This command is normally used
in conjunction with the RESTART (REST) command.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 00:25:32 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   FDDI/Soderblum(?)

As I understand it, most companies in the IEEE 802.5 Token Ring business
have payed outrageous sums of money to a Swiss man named Soderblum (sp?)
for licenses on supposedly patented technology.  Given that the MAC
layer of FDDI is essentially taken directly from IEEE 802.5, I'm curious
if this issue has been raised?  Does anyone know?

Drew

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 00:31:41 GMT
From:      NSCHNEIDEWIND@A.ISI.EDU (Norm Schneidewind)
To:        comp.protocols.tcp-ip
Subject:   Registration Information for Distributed Computing Conference


     The 9th International Conference on Distributed Computer Systems
 
     Marriott Hotel - Newport Beach, California, 92660 - June 5-9, 1989
 
     For  additional  information,  or to receive a copy of program and
     registration forms, contact the Program Chairman:
 
     Prof. Norman Schneidewind
 
     nschneidewind at a.isi.edu
 
     Code 54 Ss
     Naval Postgraduate School
     Monterey, CA 93943
 
     408-646-2719/2471
 
                         FINAL PROGRAM
 
                        Conference-at-a glance
 
Pre-Conference Tutorials
------------------------
 
Monday, June 5, 1989
8:30am-5:00 pm
 
Tutorial 1: Fault-Tolerant Computation
 
            Dr. Flaviu Cristian , IBM Almaden Research Laboratory
 
Tutorial 2: Concurrency and Coherency Control for Multi-System
            Transaction Processing
 
            Dr. Alexander Thomasian and Dr. Erhard Rahm,
            IBM Yorktown Heights
 
---------------------------------------------------------------------------
              Tuesday                     Wednesday           Thursday
TIME        June 6, 1989                June 7, 1989        June 8, 1989
---------------------------------------------------------------------------
                                                       
 8:30 am-   PLENARY SESSION         4A. Reliability     8A. Transaction
10:00 am    Keynote Speaker:            Models of           Management 
            Dr. William Wulf,           Distributed         and Query
            National Science            Processing          Processing
            Foundation                                 
                                    4B. Distributed     8B. Communication                                               Programming         Network
                                        Languages           Performance
                                        and Tools
      
                                    4C. Real-Time        
                                        Systems        
---------------------------------------------------------------------------
10:00 am-       BREAK                   BREAK               BREAK
10:30 am
-------------------------------------------------------------------------
10:30 am-   1A. Distributed         5A. Fault Tolerant  9A. Replication
12:00 noon      Algorithms              Databases and       Management
                                        File System    
                                        Design         
                                                       
            1B. Distributed OS      5B. Hybercubes      9B. Distributed
                Performance                                 System    
                                                            Performance
 
                                    5C. Formal Models  
                                        and Algorithms   
---------------------------------------------------------------------------
12:00 noon-     LUNCH                   LUNCH               LUNCH
 1:30 pm
---------------------------------------------------------------------------
 1:30 pm-   2A. Backup and          6A. Load Sharing    10A.Fault Tolerance
 3:00 pm        Consistency                                 Distributed
                                                            Algorithms
 
            2B. Distributed         6B. Experimental    10B.Distributed
                Control                 Distributed         Architectures
                                        Systems        
                                                       
                                    6C. Communications 
----------------------------------------------------------------------------
 3:00 pm-       BREAK                   BREAK               BREAK
 3:30 pm
----------------------------------------------------------------------------
 3:30 pm-   3A. Synchronization     7A. Concurrency     11A.Reliable
 5:00 pm                                Control             Distributed
                                                            Protocols
 
            3B. Distributed OS      7B. Panel           11B.Advances in
                Consistency             Discussion:         Distributed
                                        Distributed         Software
                                        Shared Memory       Development
-----------------------------------------------------------------------------
 6:00 pm-                               BANQUET
 8:00 pm                                        
-----------------------------------------------------------------------------
 8:30 pm-       Panel Discussion:       Technical Committee
10:30 pm        Critical Issues for     on Distributed
                the Development of      Processing Meeting
                Next Generation
                Distributed Systems
------------------------------------------------------------------------------
 
Post-Conference Tutorials
-------------------------
 
Friday, June 9, 1989
8:30 am-5:00 pm
 
Tutorial 3: Parallel Processing Networks and Systems
 
            Dr. Howard Jay Siegel, Purdue University
 
Tutorial 4: Distributed Database Management Systems
 
            Dr. Saeed Rahimi, Infospan and University of Minnesota
 
-----------------------------------------------------------------------------
 
Conference and Tutorial Registration Fees
 
(`Members' refers to IEEE or Computer Society of IEEE members)
 
Advance Registration Fees - Until May 15, 1989
 
Conference Only:
 
Members = $ 210  Non-Members = $ 265  Students = $ 60
 
Tutorials Only (per tutorial):
 
Members = $ 160  Non-Members = $ 200  Students = $ 160
 
Registration Fees - After May 15, 1989
 
Conference Only:
 
Members = $ 250  Non-Members = $ 315  Students = $ 70
 
Tutorials Only (per tutorial):
 
Members = $ 190  Non-Members = $ 240  Students = $ 190
 
If attending both the conference and tutorial(s), add appropriate
fees for total registration fee.
-------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 08:26:13 GMT
From:      dsweiger@trwind.ind.TRW.COM (Dave Sweigert)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP list


  Please remove this address from the TCP-IP-RELAY
  interest group.  Thank you very much.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 13:13:08 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   Most stupid 'mail' question of the year ?

May I ask your indulgence for  this little request for information about
the  DDN mail  protocols  :  both RFC821  and  RFC822  limit the  usable
character set  to '128  ASCII characters'.  For RFC821,  this limitation
concerns  not only  the  envelope, but  also the  content  which is  not
interpreted at all,  except for looking for the 'CRLF  . CRLF' sequence.
For RFC822,  the limitation concerns not  only the header, but  also the
body which is not interpreted in any way.

Given the fact that TCP offers full octet transport, my stupid questions
are :

1- Are the limitations still specified (in order words, has there been a
   relaxation at some later time)?

2- If question 1 yields a  'yes', are those limitations in fact enforced
   by the implementations?

3- If question 2 also yields a 'yes',  why is it that one may not use an
   8 bit alphabet derived by extension from ASCII for mail (did somebody
   say 'ISO8859' out there ?) ?

I really hope I have overlooked  something, and would be delighted to be
corrected by anyone who knows better than me. Thanks.

Alain FONTAINE                       +--------------------------------+
Universite Catholique de Louvain     | If your mail software barks at |
Service d'Etudes Informatiques       | my address, you may try :      |
Batiment Pythagore                   |                                |
Place des Sciences, 4                |     FNTA80@BUCLLN11.BITNET     |
B-1348 Louvain-la-Neuve, BELGIUM     +--------------------------------+
phone +32 (10) 47-2625

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 15:08:21 GMT
From:      brian@ronin.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip
Subject:   WIN/TCP tcp/ip routines for VMS


Has anyone out there in net-land had any success calling
any of the routines provided by WIN/TCP for VMS?

Whenever I try to call bind or connect I get uerrno = 22
[EINVALARG] and vmserrno = 32944. The vmserrno is supposed to 
be listed "in the documentation about the QIO system service
in the VMS System Services manual and the VMS I/O manual, Part I"
but I couldn't find any mention of it in our VMS 4.4 docs
(we're running 4.7).

If anyone has had any luck getting bind or connect to work
from WIN/TCP please send me mail and I'll buy you lunch
if you can tell me what I'm doing wrong.

Regards,

Brian.



-------------------------------------------------------------------------
Brian Wolfe                    Internet: BAW@um.cc.umich.edu
Systems Analyst                UUCP:     {ucbvax,uunet}!umix!hfhrv!brian
Henry Ford Hospital
Detroit MI 48202
(313)-876-7461
-------------------------------------------------------------------------

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 May 89 16:51:57 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <4135@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> No, it's the result of not conforming to the standards, pure and simple.
>> What is gained is speed; what is lost is reliability and interoperability.
>
>It certainly seems reliable and it interoperates quite happily with RS232 at
>RS232 speeds, and with MIDI at MIDI speeds...
>Do you have data to back up this claim about reliability and interoperability,
>or do you just have a problem with the Amiga?

I don't have anything in particular against the Amiga; I do have a serious
dislike for people who violate standards simply because they think they can
improve on them.  What matters is not whether it usually works, but whether
it is *guaranteed* to work, even with strange new equipment.  Believe me,
some nominally RS232-compatible equipment is *very* strange.  If you run
in a forgiving environment with hardware that is known to work well with
the Amiga's non-standard "RS232" interface, you'll probably never have
any trouble.  Things change when, for example, you are selling the things
and have customers complaining that their XYZ Computer Company Weirdobox
doesn't work with their "RS232 compatible" Amiga.  Or when you're trying
to push the limits on things like timing and cable length.  Then less-than-
complete compliance with standards can be very significant.

This probably doesn't belong in tcp-ip any more, so I've pointed followups
to sci.electronics.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 17:38:29 GMT
From:      desnoyer@Apple.COM (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/Soderblum(?)

In article <YYOB=wS00UoJM0j0oe@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:
>As I understand it, most companies in the IEEE 802.5 Token Ring business
>have payed outrageous sums of money to a Swiss man named Soderblum (sp?)
>for licenses on supposedly patented technology.  Given that the MAC
>layer of FDDI is essentially taken directly from IEEE 802.5, I'm curious
>if this issue has been raised?  Does anyone know?
>
>Drew

Yup. FDDI comes under his patent. The kicker is that his percentage
applies to the SYSTEM cost, which is a powerful incentive to package
token-ring products as separate add-ons, rather than building them in. 

				Peter Desnoyers

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 May 89  22:08:02 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Routing with redundant connections
My question is the route that packets will follow in this situation:

         Ethernet A (full RIP)
     -----------------------------
          |             |
          |             |
       |-----|       |-----|
     --|     |--   --|     |-- T1 C
     --|  1  |--   --|  2  |--
       |-----|       |-----|
          |             |
          |             |
     -----------------------------
       Ethernet B (default routes)

The idea is that there are 2 or more routers (Proteon p4200 and/or
cisco AGS) connected to 2 Ethernets.  Each router also has some T1
lines.  The routers exchange full RIP routing information on Ethernet
A. They send only default routes on Ethernet B, which has workstations,
PCs, and other machines on it.

The machines on Ethernet B get their default route by either having the
IP address of a single router in their configuration (e.g., PCs), or by
listening to the default RIP routes (e.g., Unix workstations).  Either
way, each machine uses one and only one of the routers as its default.

Now suppose that a machine on Ethernet B is using Router 1 as its
default and sends a packet that must go out T1 line C. Will Router 1
give the sending machine a redirect to Router 2?  My understanding is
that a redirect is normally sent only if the packet has to be sent out
the same interface that it arrived on.  This would not be the case here
since Router 1 will send the packet to Router 2 via Ethernet A, while
it came in from Ethernet B.

When a packet comes back in response, it will arrive via Router 2.
Will the receiving machine then update its ARP cache to point to Router
2 instead of Router 1?

If I configure the machine on Ethernet B and the routers to use proxy
ARP, I presume that both routers would answer and it would be
unpredictable as to which router would be used.

If I were to change RIP to OSPFIGP (when that becomes available) would
the answers be any different?

Thanks for thinking about this.
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 18:59:09 GMT
From:      naftoli@aecom.YU.EDU (Robert N. Berlinger)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <1989May5.155311.17997@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <May.4.18.53.01.1989.1967@ron.rutgers.edu> ron@ron.rutgers.edu (Ron Natalie) writes:
> >You're not serious about IP over MIDI are you.  It's major drawback
> >is that MIDI is UNIDIRECTIONAL! ...
> 
> So are most ring networks, at the wiring level.  Same solution:  tie the
> end back to the beginning.

MIDI devices often don't expect to hear their own traffic -- devices can
feedback.

To the general idea, MIDI over IP seems a more likely (and desirable)
situation, and would be fairly easy to implement.
-- 
Robert N. Berlinger		    |Domain: naftoli@aecom.yu.edu        
Supervisor of Systems Support	    |UUCP: {uunet}!aecom!naftoli
Scientific Computing Center	    |CompuServe: 73047,741 GEnie: R.Berlinger
Albert Einstein College of Medicine |Pan: berlinger  AppleLink: U0995

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 20:20:41 GMT
From:      mehls@nixbln.UUCP
To:        comp.protocols.tcp-ip
Subject:   tn3270 wanted





i post this for a friend without usenet-access:

----------------------------------------------------------
is there anybody, who knows where one can get
a public-domain version of telnet including
tn3270.
???????
from : jens mohrmann

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

thanks in advance


(please send answers to uunet!linus!nixbur!mohrmann.bln 
 or unido!nixpbe!mohrmann.bln from europe)

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 May 89 23:02:09 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   FDDI/Soderblom answer

The answer seems to be that Soderblom does indeed want royalties on FDDI
technology.  From a knowledgeable source:
> Soderblom's patent claims fundamental concepts of token ring networks,
> and he asserts that IEEE 802.5 and FDDI incorporate aspects of his
> patent.  He wants royalties on any device incorporating these token
> rings.  The royalties are not prepaid by the chip vendors (TI for
> 802.5, AMD for FDDI).

Drew

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 02:08:02 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Routing with redundant connections

My question is the route that packets will follow in this situation:

         Ethernet A (full RIP)
     -----------------------------
          |             |
          |             |
       |-----|       |-----|
     --|     |--   --|     |-- T1 C
     --|  1  |--   --|  2  |--
       |-----|       |-----|
          |             |
          |             |
     -----------------------------
       Ethernet B (default routes)

The idea is that there are 2 or more routers (Proteon p4200 and/or
cisco AGS) connected to 2 Ethernets.  Each router also has some T1
lines.  The routers exchange full RIP routing information on Ethernet
A. They send only default routes on Ethernet B, which has workstations,
PCs, and other machines on it.

The machines on Ethernet B get their default route by either having the
IP address of a single router in their configuration (e.g., PCs), or by
listening to the default RIP routes (e.g., Unix workstations).  Either
way, each machine uses one and only one of the routers as its default.

Now suppose that a machine on Ethernet B is using Router 1 as its
default and sends a packet that must go out T1 line C. Will Router 1
give the sending machine a redirect to Router 2?  My understanding is
that a redirect is normally sent only if the packet has to be sent out
the same interface that it arrived on.  This would not be the case here
since Router 1 will send the packet to Router 2 via Ethernet A, while
it came in from Ethernet B.

When a packet comes back in response, it will arrive via Router 2.
Will the receiving machine then update its ARP cache to point to Router
2 instead of Router 1?

If I configure the machine on Ethernet B and the routers to use proxy
ARP, I presume that both routers would answer and it would be
unpredictable as to which router would be used.

If I were to change RIP to OSPFIGP (when that becomes available) would
the answers be any different?

Thanks for thinking about this.

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 10:17:00 PST
From:      art@sage.acc.com
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   more RS-232

>In passing, please note that the Amiga does not violate standards more
>than the average RS232 interface.  It simply omits the slew rate limiting
>capacitors on the RS232 drivers, just like 30-70% of the other RS232
>"compatible" devices out there.  And of course the baud rate generator can
>be set to some interesting values.
>
>Yes, reliablity in a general sense does suffer.  Depending on the FCC
>treatment in the particular unit and the cable length, it may or may not
>go that fast.  No promises...
>
>Really there's no great problem with 38.4K local/direct connections,
>but sadly, a lot of the common things like terminals, terminal programs
>and dumb protocols can't seem to keep up.  The world is overfull of
>terminals that won't display as fast at 9600 BPS without flow control
>no matter how fast you set the bit rate to.

This discussion has nothing to do with TCP, but I imagine it's of some
interest to the readership.

We have run RS-232 up to over 200Kbps IN THE LAB, but the real world of
connecting everything together can be MUCH LESS FORGIVING.

As a person who has fought with the crosstalk that high slew rates can
generate in some cabling, I fully appreciate the need for slew rate
control. 26 conductor flat ribbon cable (used with press-on connectors)
is very popular and very susceptible to crosstalk.  Other cabling
can range from poor to very good.

If you are going to violate the specs, know exactly what you are doing,
(i.e. know something about the transmission line characteristics) and
don't be suprised if you still get bit.

There is nothing quite as aggravating as something that ALMOST always works.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+


-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 03:17:10 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on MIDI?

In article <1989May11.165157.23656@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
> In article <4135@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >> No, it's the result of not conforming to the standards, pure and simple.
 ...
> >It certainly seems reliable and it interoperates quite happily with RS232 at
 ...
> >or do you just have a problem with the Amiga?
 ...
> I don't have anything in particular against the Amiga; I do have a serious
> dislike for people who violate standards simply because they think they can
> improve on them.  What matters is not whether it usually works, but whether
> it is *guaranteed* to work, even with strange new equipment.

In passing, please note that the Amiga does not violate standards more
than the average RS232 interface.  It simply omits the slew rate limiting
capacitors on the RS232 drivers, just like 30-70% of the other RS232
"compatible" devices out there.  And of course the baud rate generator can
be set to some interesting values.

Yes, reliablity in a general sense does suffer.  Depending on the FCC
treatment in the particular unit and the cable length, it may or may not
go that fast.  No promises...

Really there's no great problem with 38.4K local/direct connections,
but sadly, a lot of the common things like terminals, terminal programs
and dumb protocols can't seem to keep up.  The world is overfull of
terminals that won't display as fast at 9600 BPS without flow control
no matter how fast you set the bit rate to.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 04:35:25 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  human factors aspects of echo delay

Phil,

For my second trick, I was expected to read a live, one-minute commercial
spot during a one-minute network spot and make the ends come out so you
didn't know the network spot was there. The Mutual Broadcasting System
may not be thought of in the same breath as "Auntie" BBC, but you sure
learned some strange skills working that network. 'Nuff said; I seem to
remember from various studies of teleconferencing systems that in the
order of 100 ms is the most demanding regime for echo cancellors, room
accoustics and discombobulated broadcasters.

Dave

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 04:42:20 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  human factors aspects of echo delay

Bob,

On occasional travel overseas I often happen onto satellite circuits with
quirky societal behavior as you describe. Like you, my correspondents have
learned to live with half-duplex radiospeak with very happy results. I have
my wife trained so well that I can phone home with a position report from
a Paris streetside telephone and get all the data across before the first
frank has expired. Discipline, all it takes is discipline.

Dave

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 08:50:41 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing with redundant connections


Roger, No redirects will be sent by the routers to the hosts since the next 
hop will not be on the same net (ethernet B).  

The ARP's that will occur won't change the next hop.  With some effort, and
possibly breaking the hosts view of what the real subnet mask is on the B
cable, proxy arp might work, but I think it's a gross hack in this
case and you'd be better off without it.

When OSPF comes along, it's not really any different, but you can instead
run full OSPF routing on Ethernet B, and if you do that, you'll get the
redirects as you want.  This isn't a big deal, since most of the time you go
to a 2 net structure like you describe is to reduce broadcast traffic
on a LAN with hosts on it, or because you worry about some host there injecting
foul routing information in the system.

OSPF addresses these problems by Multicasting on broadcast LAN's, like Ethernet,
and thus hosts won't hear it unless they are a part of that multicast
group.  Also, misconfigured hosts won't be sending back ICMP noise at the routers
since they won't be hearing the multicasts.  It also means that even if they
run gated or RIP, they still won't be having to digest full routing info.
That way you can use RIP on the cable to lead hosts to a default router,
and run OSPF between the routers with full routing info flowing via
multicasts...

Even if a 'enemy' OSPF router were present on that cable, he
still wouldn't be able to inject unwanted routing info into the system
because OSPF supports authentication across all router adjacencies.  Thus
the 'enemy' router won't be believed by router 1 or router 2.  And thus you 
won't have coincidentally colocated routers fouling your routing domain.

If you are worried about loading on ethernet B, OSPF will also allow you
to load balance across ethernet A and B (equal cost multipath support is built
in to the protocol, though a particular router implementation (e.g. BSD Unix)
may not implement it).  If you are load balancing across A and B, then
one of the next hops will be on the same net, and the routers should issue
redirects as appropriate...  OSPF is most topologies will generate a lot
less routing traffic than RIP anyway.

Even if you don't like SPF routing algorithms, OSPF's multicasting and
router authentication are really nice things to have.  It's too bad it's
taken this long for a standard IP routing protocol to incorporate these
features.  The technology to do it has been with us for some time.  Better 
late than never though!

						Thanks,
						   Milo

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 13:46:56 GMT
From:      rlfink@ux3.lbl.gov (Robert Fink)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/Soderblum(?)

Though many folk assume the Soderblom patent pervails in all of these
cases, it is still not clear.  It is the case that Soderblom tries to
get FDDI manufacturers to pay the license.  Some (many) pay as it is
currently easier to do so than fight it.  Others may yet fight it, or,
may not.

Bob Fink
Lawrence Berkeley Lab

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 13:53:25 GMT
From:      keith@fstohp.crd.ge.com (Keith D Gregory)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: UDP Connections on LOOP interface

I was wondering about the reliability of UDP connections on the LOOP interface
(127.0.0.1).  Common sense says that the packets should be delivered without
loss, unless some internal queue limit is overflowed.

I tested the basic hypothesis by sending 1.5 million packets of varying sizes
between two processes.  I then tested an internal queueing limit by creating
a socket, forking, and letting the parent sleep while the child send a small
number of packets.  Regardless of packet size, 3 packets would be queued -
any additional packets would be dropped.

So, obviously this is not a valid technique for high transmission densities.
Given low densities, however, it would be a useful replacement for msgsnd(2)
et al, especially since it would allow me to use select(2).

So, if anyone out there is able to authoritatively say yea or nay, please do.
As a note, I do not have the "real Berkeley manuals", so would be unable to
refer to such.

Thanks,
-kdg
-------

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 14:28:10 GMT
From:      berliner@prisma.UUCP (Brian Berliner)
To:        comp.protocols.tcp-ip
Subject:   Please add me to the tcp-ip list


Thanks,

Brian Berliner
Prisma, Inc.
berliner@prisma.com

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 15:02:10 GMT
From:      djw@bbn.com (David Waitzman)
To:        comp.protocols.tcp-ip
Subject:   Software patents in Fri NY Times (re: FDDI patents)

In the Friday, May 12, 1989 New York Times there is a
(disturbing) article on software patents.  The article begins
on the first page.

-david

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 15:26:05 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re:  human factors aspects of echo delay

And lest we forget, the main reason Ethernet-as-a-packet-voice-PBX didn't
fly so well was that to get good efficiency you need to bundle up several
milliseconds of speech per packet. [256 data bytes per packet means a 36ms
delay *minimum*, plus elastic buffer delay.] As long as all parties to the
conversation were on the same network *and* all had "4-wire" phones, it worked
just fine, even with a 100ms round-trip time, since there were no echos.
[Note that you did *not* have any delay in your own sidetone!]

But when a call had to go "off net" to a phone "out there" somewhere, the
inevitable imbalances in the 2-wire/4-wire hybrids exposed the delay to
the parties on the packet-voice side [the party on the 2-wire analog side
never heard the problem], and the packet-phone users started getting echo
with delays right in that most irritating range!

[Given recent advances in adaptive echo-cancellation processors, and also
with end-to-end ISDN coming, maybe it's time to try "EtherPBX" again...]


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 16:42:38 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FDDI/Soderblom answer

Drew,

If I understand the issues here, I should not plan to incorporate FDDI
or IEEE 802.5 chips into my experimental high-speed network research
plans on pain of paying royalities on the value of the entire system.

Dave

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 18:17:00 GMT
From:      art@sage.acc.com
To:        comp.protocols.tcp-ip
Subject:   more RS-232


>In passing, please note that the Amiga does not violate standards more
>than the average RS232 interface.  It simply omits the slew rate limiting
>capacitors on the RS232 drivers, just like 30-70% of the other RS232
>"compatible" devices out there.  And of course the baud rate generator can
>be set to some interesting values.
>
>Yes, reliablity in a general sense does suffer.  Depending on the FCC
>treatment in the particular unit and the cable length, it may or may not
>go that fast.  No promises...
>
>Really there's no great problem with 38.4K local/direct connections,
>but sadly, a lot of the common things like terminals, terminal programs
>and dumb protocols can't seem to keep up.  The world is overfull of
>terminals that won't display as fast at 9600 BPS without flow control
>no matter how fast you set the bit rate to.

This discussion has nothing to do with TCP, but I imagine it's of some
interest to the readership.

We have run RS-232 up to over 200Kbps IN THE LAB, but the real world of
connecting everything together can be MUCH LESS FORGIVING.

As a person who has fought with the crosstalk that high slew rates can
generate in some cabling, I fully appreciate the need for slew rate
control. 26 conductor flat ribbon cable (used with press-on connectors)
is very popular and very susceptible to crosstalk.  Other cabling
can range from poor to very good.

If you are going to violate the specs, know exactly what you are doing,
(i.e. know something about the transmission line characteristics) and
don't be suprised if you still get bit.

There is nothing quite as aggravating as something that ALMOST always works.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<art@sage.acc.com>	Santa Barbara Street			|
|	(805)963-9431		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 May 89 20:44:56 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.music,rec.music.synth
Subject:   Re: MIDI on UDP? (was Re: TCP/IP on MIDI?)

You do not want to implement MIDI on an unreliable network.  You get great
phenomena such as stuck notes.  That's why lots of midi auxillaries have
the ability to generate the "ALL NOTES OFF" code.

-Ron

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      13 May 89 19:23:40 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 wanted

In article <7000001@nixbln> mehls@nixbln.UUCP writes:

>is there anybody, who knows where one can get
>a public-domain version of telnet including
>tn3270.
>???????
>from : jens mohrmann

Why not simply post the whereabouts of this utility?  I am interested
in getting it too!



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

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 May 1989 11:18-EDT
From:      CERF@A.ISI.EDU
To:        balenson@TIS.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Sequence numbers provide security?? (Bellovin's article)
David,

The sequence numbers on TCP are intended to support sequenced,
non-duplicative data delivery from source to sink. The 3-way handshake is
supposed to help filter out accidental spoofing caused by old
duplicate connection initiation sequences or other old data
packets. This is a sort of suthentication, but by no means proof
against active spoof attacks of the sort envisioned by Bellovin.

Authentication in the sense of source/sink identity is surely not
the province of the sequence number/IP address mechanisms since
they are obviously penetrable in the absence of cryptographic
mechanisms.

I think Bellovin was focusing more on data integrity and on
the ease with which one might fool an innocent TCP implementation,
not so much to argue that the TCP sequence number and 3-way
handshake were bad but that something in addition was needed to
deal with authentication of origin.

Vint
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      14 May 89 15:18:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Sequence numbers provide security?? (Bellovin's article)

David,

The sequence numbers on TCP are intended to support sequenced,
non-duplicative data delivery from source to sink. The 3-way handshake is
supposed to help filter out accidental spoofing caused by old
duplicate connection initiation sequences or other old data
packets. This is a sort of suthentication, but by no means proof
against active spoof attacks of the sort envisioned by Bellovin.

Authentication in the sense of source/sink identity is surely not
the province of the sequence number/IP address mechanisms since
they are obviously penetrable in the absence of cryptographic
mechanisms.

I think Bellovin was focusing more on data integrity and on
the ease with which one might fool an innocent TCP implementation,
not so much to argue that the TCP sequence number and 3-way
handshake were bad but that something in addition was needed to
deal with authentication of origin.

Vint

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      14 May 89 16:33:30 GMT
From:      brock@brock.cs.unc.edu (J. Dean Brock)
To:        comp.protocols.tcp-ip
Subject:   Soderblom and token ring

There's a brief article (3 pages) by Olof Soderblom in the Winter 88
issue of Connect, "A 3Com Publication".  (Someone gave me a copy --
got no idea how one is usually obtained.)

I infer that he believes that any network based on "the technique of
arranging terminals in series around a closed transmission ring and
arbitrating access to the ring by circulating a message indicating
when it is free" (Sonderblom's words) relates to his patent.

He states that the token ring was conceived in 1967 and the first
token ring was the Svenska Handelsbanken (a Swedish bank) network
connecting 2,500 terminals at 500 branch office.  That ring
came operational in the early 1970's.  IBM was the prime network
contractor for the Svenska Handelsbanken network.

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 01:26:36 GMT
From:      farber@pcpond.UUCP (David J. Farber)
To:        comp.protocols.tcp-ip
Subject:   Re: Soderblom and token ring



Yes, Sonderblom claims that his patents cover  most  varients  of
the  "  token  loop"  technology.  His basic application was as a
terminal control loop. It was only in a much latter USA patent  (
if  my memory serves me late 1970s) that he added claims to cover
a loop with completely decentralized control. The initial patents
did not cover that. To my knowledge the DCS (Distributed Computer
System) underlieing token ring was the first operational ring  to
have  fully  decentralized  control (and the operating system was
one of the first fully distributed fault tolerent  message  based
systems) dated in the 1970 - 1974 time frame.

Dave

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 01:44:43 GMT
From:      farber@pcpond.UUCP (David J. Farber)
To:        comp.protocols.tcp-ip
Subject:   Re: Soderblom and token ring

BTW my signature line is:
---------------
David J. Farber; Prof. of CS and EE, Director - Distributed Systems Labs.
University of Pennsylvania/200 South 33rd Street/Philadelphia, PA  19104-6389
Comm: 215-898-9508 (office), 215-274-8192 (fax); 302-740-1198 (cellular)  

"Mathematics and science are the study of what IS; Computer science is
the study of what can be DONE."

"The fundamental principle of science, the definition almost, is this:
the sole test of the validity of any idea is experiment." -- Richard P. Feynman

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 02:04:19 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Rick Adams' new ftp and ftpd

In article <8905102222.AA17256@uunet.UU.NET> rick@UUNET.UU.NET (Rick Adams) writes:

   Those waiting for block mode or block mode restart in ftpd are
   advised not to hold their breath. (The "standard" FTP restart mechanism
   is clearly inadequate.)

You can start breathing again.  I have such a beast, hacked into the
BSD4.3 Tahoe ftpd.  I looked at hacking block mode into the client,
but the client's code is a real mess.

Why bother if I don't have a client?  Because I have convinced Phil
Karn's TCP/IP client and server to do block mode restart.

Send mail if you're insterested (as my daughter pronounces it :-).

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 May 89 10:09:02 PST
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        munnari!otc!metro!bunyip!brolga!ggm@uunet.uu.net (George Michaelson)
Cc:        tcp-ip@sri-nic.arpa, pvm@venera.isi.edu
Subject:   Re: RFC 1101
>Since the X.500 standards define encodings for many of the real-world data 
>types one wants to store in a directory service, and the NS is offering such 
>hugely aligned functionality, surely RFC's could be used to define mappings 
>from the OSI DS object family into suitable Bind record types?

>Existing Bind definitions stay as-is. New ones where possible adopt forms
>"compatible" with X.500 defined objects.

>Lots of wins from this approach.

Right.  I think the Internet should adopt/steal the parts of X.400,
X.500 etc., etc. worth adopting/stealing now or in the future, in whole
or in part.  The rest is for further study/not worth stealing.

paul

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 May 89 13:04:22 CST
From:      WANG <IIIG002%TWNMOE10.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   request information for RFC's public domain software
Dear all,

    I am looking for the Public Domain source code of implemented RFC1001 and
RFC1002.  Could anyone tell me where I can get it?

Thanks for your help.......

                              kevin wang
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 14:07:47 GMT
From:      boomer@athena.mit.edu (Don Alvarez)
To:        comp.protocols.tcp-ip
Subject:   Re: Soderblom and token ring

In article <8124@thorin.cs.unc.edu> brock@brock.cs.unc.edu (J. Dean Brock) writes:

>[article by Olof Soderblom] states that the token ring was conceived in 1967
>and the first token ring [...] came operational in the early 1970's.

Sounds to me like the 17 year life-time for patents is about to make this
a non-problem.  If "early 1970's" = 1972, then 1972+17 = 1989.

					-Don Alvarez
--
+ -------------------------------------------------------------------------- +
|  Don Alvarez           M.I.T. Center For Space Research   (617) 253-7457   |
|  boomer@SPACE.MIT.EDU  coming soon: Princeton University Dept. of Physics  |
 + -------------------------------------------------------------------------- +

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 14:48:51 GMT
From:      keith@fstohp.crd.ge.com (Keith D Gregory)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: UDP Connections on LOOP interface

joshua@atherton.com (Joshua Levy) writes:
>What about the relative speeds?  Do you have any idea how fast msgsnd
>is compared to socket(127.0.0.1)?  If so, I'd like to know.  Thanks.

The raw numbers I generated (all times in milliseconds):

   Method: UDP on 127.0.0.1
      Number of packets: 1000
      Maximum time:        39.956
      Minumim time:         3.788
      Average time:         4.064

   Method: Sys5 Message
      Number of packets: 1000
      Maximum time:       163.764
      Minumim time:         2.966
      Average time:        35.344

---------------------------------------------------------
The test programs were almost identical: a single program
which fork()'d, the child wrote a bunch of packets, the
parent tried to read them.  The packets themselves contained
the current time from gettimeofday(2), which was compared to
the time after the read.

The message version used blocking read/write (msgrcv, msgsnd).
The UDP version used blocking write (sendto), and non-blocking 
read (recvfrom), initiated by a select().  To avoid queue
overflow, the UDP version slept 1 second between sends (the
select() was around to notify me if packets got lost - none
did).

The machine is an HP9000/360 (68030 @ 25MHz), running HP-UX
6.2.  A few users at the time, doing the sorts of things that
users do.

Anyone that wants the source code should mail me directly,
at 'keith%fstohp@crdgw1.ge.com'.

-kdg

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 14:53:06 GMT
From:      rlfink@ux3.lbl.gov (Robert Fink)
To:        comp.protocols.tcp-ip
Subject:   Re:  FDDI/Soderblom answer


Dave,

I asked one of the FDDI committee folk about the issue of who pays licenses on
the patent relative to FDDI.  His answer was that it is the end equipment
manufacturer (board, router, bridge) that uses FDDI that would pay Soderblom,
which is why AMD has not (he thinks) paid any license fees (they are not
the end equipment supplier).  In addition, the value of the system as a
base for the fees has been ignored in the industry as a whole as unrealistic.

Also, whether Soderblom should/will be paid anything depends on legal issues
not yet addressed in courts.  It has been easier for many to simply pay than
worry about the larger cost of fighting.  This may not remain the case.

Bob Fink

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 15:10:37 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   minimum length ethernet packet

DEC has established a facility in St. Louis to test and integrate
various security components into a system for the USAF Military
Airlift Command.  (The end result of this effort is to be a system that
provides Multilevel Security.)  One of the components being tested is
the Xerox Encryption Unit (XEU).  The XEU is designed to be installed
in the drop cable between a processor and the transceiver, as
illustrated below.

      Thicknet or Thinnet ----| MAU |----------              
                                 |<----802.3                     
                                 |                               
                              | XEU |                            
                                 |<----802.3
                                 |
                          | DECserver 100 |

One of the problems discovered by DEC is that the XEU will not forward
short packets; as reported by DEC: "The XEU's will not forward a short
ethernet packet.  During power-up and self-testing, many devices
(including DECserver 100's) create a 32 byte packet (36 bytes with
CRC).  This packet is transmitted to the network.  The device expects
to receive the packet back from the network.  This is how the device
determines that the network is operational.  Although the Ethernet
Version 2 specification and the  IEEE 802.3 specification state that
the minimum length of a data packet is 64 bytes, it is quite common in
the industry to use a smaller packet for network verification
testing.  Actually, the LANCE chip set which is one of the most
common ethernet chips in the world implements this test.  Most network
vendors using the LANCE chip perform this minimum length packet test of
the network. [...]  For the terminal server to properly start up, this
packet must be passed through the XEU and back to the terminal
server."

Questions/Comments

I don't have the LANCE spec sheet, but it seems to me the chip set
should be passive with respect to packet length; that it is the 
responsibility of the driver routine to insure proper packet length.

"Most network vendors ... perform this minimum length packet test ..."
Is that true? It would imply Xerox should have done a better job
checking the compatibility of the XEU.

Any advice or comments would be appreciated.  Regards - Craig

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 15:27:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/Soderblom answer


>>Written 11:42 am  May 12, 1989 by Mills@UDEL.EDU in comp.protocols.tcp-ip:
>Drew,
>
>If I understand the issues here, I should not plan to incorporate FDDI
>or IEEE 802.5 chips into my experimental high-speed network research
>plans on pain of paying royalities on the value of the entire system.
>
>Dave

  It seems silly for anyone with a patent to try to *hinder* people from
developing new technology that they might be able to collect royalties on!
If Soderblom was smart, he'd *subsidize* research based on his patent, so
that he'll get that much more dough in a few years.
  I say write the guy a nice letter to the effect "hey buddy, how'd you like
the high-speed network of the future to be based on your stuff? Have I go
a deal for you....."


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 17:30:26 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Re: FDDI/Soderblum(?)


*Though many folk assume the Soderblom patent pervails in all of these
*cases, it is still not clear.  It is the case that Soderblom tries to
*get FDDI manufacturers to pay the license.  Some (many) pay as it is
*currently easier to do so than fight it.  Others may yet fight it, or,
*may not.

*Bob Fink
*Lawrence Berkeley Lab


the problem here is that this creates a precedence for him to
collect.  "pay me, Froboz pays me, and so does Blaknatz. i'll sue,
you know". then they pay, and pretty soon, everyone pays, because
everyone else is paying. can you imagine a world where every ethernet
board had a royality paid on it? or every RS232 port?


stev knowles
ftp software
stev@ftp.com

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 18:40:17 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Soderblom and token ring

Dave,

You missed "Engineering is the art of DOING IT."

What are you suggesting we DO?

Dave

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 19:04:22 GMT
From:      IIIG002@TWNMOE10.BITNET (WANG)
To:        comp.protocols.tcp-ip
Subject:   request information for RFC's public domain software

Dear all,

    I am looking for the Public Domain source code of implemented RFC1001 and
RFC1002.  Could anyone tell me where I can get it?

Thanks for your help.......

                              kevin wang

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 May 89 23:23:52 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  minimum length ethernet packet

Runt Ethernet packets are a problem for a number of Ethernet
implementations.  There is in fact a very good reason why the spec
includes a minimum length; it's needed to insure that all stations
detect a collision during packet reception.  Without it, a collision
that is noticed at one end of a cable may not be noticed at the other
end.

If DEC is in fact generating short packets, then they are in violation
of both the 802.3 and Ethernet specs.  I expect they will lose a few
major RFPs as their competitors point out that they are not meeting the
requirements.  Unless, of course "Everybody does it".

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 00:48:10 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   CCITT 1988 Blue Books

FYI:
Omnicom is now shpping many of the CCITT 1988 Blue Books, and if you
order before Sept. 1, they are offering a 20% discount.  You can the
full set (60 volumes) for (only) $2000.  You can also get special
"package deals" on ISDN ($600), OSI/MHS, Signalling Systems ($510),
Office Automation ($179) and Data Networks ($200).  For more info
contact Omnicom at 1-800-666-4266.

Drew

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 08:21:43 GMT
From:      chris@yarra.oz.au (Chris Jankowski)
To:        comp.protocols.tcp-ip
Subject:   What is Ethernet type code 8035 hex?


I am chasing an elusive delay problem when using PC-NFS telnet.
The PC broadcasts an Ethernet packet with type code field set to 8035 hex.
(It does that three times in 3.5s intervals - doing nothing in between, hence
the delay.)
	Questions:
1. What is Ethernet type code 8035 hex?
   (Analysing other packets I could find that type code 0800 hex points to IP,
    and 0806 hex means ARP)
2. What document or standard defines relation between values in this field 
    and higher level protocols?

Chris Jankowski   chris@yarra.oz.au
Pyramid Technology Australia - Melbourne

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 14:09:19 GMT
From:      igb@Fulcrum.BT.CO.UK (Ian G Batten)
To:        comp.protocols.tcp-ip,comp.misc
Subject:   RFC 865 ``Quote of the Day'' (Port 17)

How many systems on the internet support RFC 865, the ``Quote of the
Day'' protocol?  I've just (for fun!) put the recent alt.sources cookie
program up on this port, using a line or two line patch to the 4.3bsd
uucpd program.  (As I have this ported to all my System Five machines to
run uucp, this means it works well).

ian


-- 
Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 14:11:47 GMT
From:      bud@ut-emx.UUCP (C. E. Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: FDDI/Soderblum(?)

In article <8905151730.AA06800@vax.ftp.com> stev@VAX.FTP.COM writes: >
>the problem here is that this creates a precedence for him to
>collect.  "pay me, Froboz pays me, and so does Blaknatz. i'll sue,
>you know". then they pay, and pretty soon, everyone pays, because
>everyone else is paying. can you imagine a world where every ethernet
>board had a royality paid on it? or every RS232 port?  
>

Ethernet is patented.  Xerox has two patents on the system from 1975.
The IEEE802.3 specs note that "The Xerox Corporation has assured the
IEEE that it is willing to grant a license under these patents on
reasonable and nondiscriminatory terms and conditions to anyone
wishing to obtain such a license."

I assume Xerox decided to let the technology out without hassling
anyone for royalties.  I've never heard of someone getting an Ethernet
license from Xerox.  Does anyone bother to do so, one wonders?

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 14:41:13 GMT
From:      nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   A pox on FTP clients!

A pox on anyone who failed to implement continuation lines in their
FTP clients!  And a warning on anyone who tries to use them in their
FTP server -- don't!
-russ

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 15:21:12 GMT
From:      rbj@DSYS.ICST.NBS.GOV (Root Boy Jim)
To:        comp.protocols.tcp-ip
Subject:   Reconciling /etc/hosts, yp, and named?

? From: steve@umiacs.umd.edu (Steven D. Miller)

?    It seems to me that the following combinations of DNS/YP/host table usage
? are valid:

? 	1) You're using the domain name system.  In this case, *all* host
? 	lookups should go through the DNS.  The only exception here is that
? 	at boot time, you'll need to be able to fall back on the host table
? 	so that you can do a host name lookup to configure your network
? 	interface.  Other than that, you *never* fall back on the host
? 	tables, as host table information is out-of-date, wrong, and won't
? 	be around for too much longer.  I'd rather have no answer than a
? 	wrong one, though I suppose this is something of a religious issue.

True. I would like to add one more belief to our religion. I would
caution against using the host tables even to bring the network up.
First, consider a gateway, with two interfaces with two different
IP addresses but only one name. You obviously can't do:

	ifconfig ie0 foo.bar.com
	ifconfig ie1 foo.bar.com

Now perhaps one could (and should?) define a foo-gw.bar.com address, but
the order of addresses in /etc/hosts will determine which IP address is
returned first, so you really need three names, especially if you are
using the same host table on multiple hosts on multiple subnets. Simpler
to just use one name, and use naked IP addresses on the ifconfigs.

Now consider a host on an subnet with only one gateway to the rest of
the would. It needs a `route add default <gateway> 1' line. Again,
the order of the entrys in the host table will determine which IP
address is returned first. Another good place to use IP addresses.

? 		(Note that it's important for your customers to be able to
? 		purge YP entirely from their systems without causing any
? 		catastrophes.)

This is an important point. So far, Sun has amazingly shown great
restraint in not forcing YP down everyone's throat. As far as I know,
YP has nothingh to do with the Arpanet Reference Model. It is a
proprietary service, an RFC has not been written for it, and there is
no mention in any of the host requirements for or of it.

True, it is found in other vendor's implementations of NFS; Sequent,
for example, has all the YP stuff in it's NFS librarys. It is my
belief that for such vendors it is easier to just take the whole
package than to split off just the good parts. Besides, they paid
for it anyway, and too much software is better than not enuf,
especially if you can throw the excess away.

However, there remains a significant number of people out there (Steve
and myself, among others) which are constitutionally opposed to YP.
We will certainly not use it in its current form and may never use it
in any form whatsoever.

? 	-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

ESIG2WIDE.

	Root Boy Jim is what I am
	Are you what you are or what?

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 15:52:02 GMT
From:      ames.arc.nasa.gov!lamaster@ames.arc.nasa.gov  (Hugh LaMaster)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Freed BSD networking code

I have heard and seen references to "freed" versions of BSD code, which don't
have AT&T code in them.  Could someone post some ftp-able sites where such
code lives.  I am particularly interested in finding an open source
for "telnet" and other networking code.

  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117       
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 17:15:03 GMT
From:      guru@FLORA.WUSTL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   ICC'90 - Session on High Speed Internetworking and Gateway Arch


I am considering organizing a technical session for SUPERCOMM ICC'90
on "High Speed Internetworking and Gateway Architectures". The
conference will be held in Atlanta Georgia during April 16-19 1990.
I am enclosing the note that I sent to conference organizers about
this session and details about the conference. 

If you decide to submit a paper to this session,

- mention on the title page Computer Communications Technical Session,
  High Speed Internetworking and Gateway Architecture as the name of
  the session, and my name as the name of the session chair. 
- send a copy of the paper to me as well as to the conference chairman
  as described in the following note. 

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899 
(314) 889-4621

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


				   
		      High Speed Internetworking
		      and Gateway Architectures
				   
			  Dr. Guru Parulkar
		       Dept of Computer Science
		  Washington University in St. Louis

This session will serve as an excellent platform for presenting
research on the issues related to the next generation of internetworking
and gateway architectures. A new model for internetworking has been
motivated in part by recent work on high speed packet switching and in
part by the limitations of ARPA Internet model in supporting
guaranteed levels of performance to a number of applications.

The work on high speed packet switching is expected to lead to the
development of large public networks capable of supporting
applications ranging from low speed data to voice, high speed data and
video.  If such networks are to realize their full potential, they
must be designed to operate in an environment that includes networks
with widely varying characteristics. The internet model based on the
ARPA Internet has worked well for internetworking of the first
generation networks, but is not appropriate for the internetworking of
newer high speed networks for a variety of reasons.  Thus, there is a
need to address the issues related to the interplay of component
networks' diversity and our ability to support a variety of
applications with guaranteed levels of performance in the next
generation internet.

Some of the topics that will be covered by papers in this session
include: 

- model for the next generation internet: connectionless and
 connection-oriented transport facility, addressing model, diversity
 of component networks, functionality expected of component networks,
 routing model, etc.

- design and specification of a connection-oriented internet protocol
  which can work well with the emerging high speed networks as well as
  with the existing neworks.

- design of gateway architectures for high speed networks based on the
  lessons of high speed packet switches  

- resource management in an internet of diverse networks to provide
  variable grade performance with guarantees


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


			   SUPERCOMM ICC'90
	      International Conference on Communications
		    Georgia World Congress Center
			   Atlanta, Georgia
			  April 16-19, 1990


			   CALL FOR PAPERS
		      SILVER ANNIVERSARY OF ICC
		    FIRST COLOCATED ICC/SUPERCOMM

The conference will be held in Atlanta, Georgia from April 16,1990 to
April 19, 1990. It will combine the traditional strong technical
program of ICC and the exhibition and seminar program of SUPERCOMM in
one location for the first time. The combined strength of these two
conferences promises to provide an unparalleled opportunity for
interaction for professionals from the telecommunications industry.
Papers for the ICC'90 technical program are invited on the following
or related topics.

	  COMMUNICATIONS -- FOUNDATION FOR THE 21ST CENTURY

INTELLIGENT NETWORKS	

Architecture, switching, user control, evolution, network management,
optical networks, services, monitoring, adaptive architectures, ISDN,
standards.

VISUAL INFORMATION

Image representation, source coding and compression, storage,
interactive video, two-way video, broadband ISDN, HDTV, fiber to the
home. 

ACHIEVVING THE POTENTIAL OF INFORMATION EXPANSION: PRODUCTS AND
SERVICES FOR COPING WITH EXPONENTIAL INFORMATION GROWTH

microwave, satellite, cellular, specialized radio, fiber, survivable
systems, secure systems, rural applications, basic exchange
telecommunications radio, compact antennas, specialized services. 

		      SCHEDULE AND INSTRUCTIONS

COMPLETE MANUSCRIPT DUE         JULY 1, 1989
NOTIFICATION OF ACCEPTANCE      OCTOBER 15, 1989
CAMERA READY COPY DUE           DECEMBER 15, 1989

The title page of the manuscript must include the names of all
authors, the complete address and telephone number of all authors,
designation of the managing author, and a 100 word abstract of the
paper. Please indicate any technical committee interest area. All
pages should show the title of the paper and the managing author's
name. Six double-spaced copies of the manuscript in English should be
sent to the ICC/SUPERCOMM'90 TECHNICAL PROGRAM CHAIRMAN at the address
given below: outside North America also please send one additional
copy to the appropriate REGIONAL REPRESENTATIVE listed below. The
length of the manuscript should be limited to what you expect to
constitute five pages of the conference proceedings. The conference
will be in English. 

ICC/SUPERCOMM'90                  EUROPE, AFRICA, & MIDDLE EAST   
TECHNICAL PROGRAM CHAIRMAN	  Dr. Frederico Tosco             
Prof. Aubrey M. Bush		  CSELT                           
24N73 Southern Bell Center	  Via Reiss Romoli 274            
675 West Peachtree Street NE	  I-10148 Torino, Italy           
Atlanta, GA 30375 USA		  Phone +39 11 21691              
Phone 404-894-2942		  FAX   +39 112169520             
FAX   404-894-8363		  Telex 220539 CSELTI             

CENTRAL & SOUTH AMERICA           ASIA & PACIFIC                      
Prof. Jose Roberto B. de Marca 	  Prof. Shigeo Tsujii                 
CETUC-PUC/Rio			  Faculty of Engineering              
22453 Rio de Janerio - RJ	  Tokyo Institute of Technology       
Brazil 				  2-12-1, Ookayama. Meguro-ku         
Phone +55 21 529-9450		  Tokyo. 152. Japan                   
Telex 21 31048 PUC BR		  Phone TOKYO 03 (726) 1111 ext 2503  
				  FAX   Tokyo 03 (729) 0685           









 

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 17:32:25 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.protocols.pcnet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Multicast source addresses

I'm currently in a discussion with two vendors (who shall
remain nameless); one makes a brouter and another sells
a network management software package.  The software not
only recognizes 802.3 format packets (and not "Ethernet")
but also - get this - sets the multicast bit in the MAC
level source address.  Unfortunately, the brouter notices
this and drops the packet.  I know at least one bridge
that will *learn* the multicast address (which could
result in defeating that multicast address - I didn't
check).

I would like the brouter to be a bit more lenient (i.e.
forward the packet as appropriate but don't learn the
multicast source address) and the software vendor to
fix the code (let "Blue Book" Ethernet - type field in
bytes 12-13 be supported, not just 802.3 - length in
bytes 12-13 . . .) and don't set that multicast bit
in the source address.

Could people send me the names of LAN software that
they have found that puts a multicast/broadcast
in the MAC level source address?  I know of two, and
one was just recently fixed.  Thanks much.

  Dave Wiltzius (wiltzius@lll-lcc.llnl.gov)
  Lawrence Livermore Nat'l Lab

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 18:09:00 GMT
From:      barr@frog.UUCP (Chris Barr)
To:        comp.protocols.tcp-ip
Subject:   FDDI/Soderblum(?)

In article <2621@helios.ee.lbl.gov>, rlfink@ux3.lbl.gov (Robert Fink) writes:
> Though many folk assume the Soderblom patent pervails in all of these
> cases, it is still not clear.

As I understand it, this Swedish engineer patented the TOKEN RING.  Some
vendors (e.g. from '76 to (present?), Prime Computer) have been selling
token rings while fending off patent infringement lawsuits from 
Soderblum(sp?).  IBM pays royalties.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 19:01:31 GMT
From:      djl@mips.COM (Dan Levin)
To:        comp.protocols.tcp-ip
Subject:   BOOTP Policy Question


I have a question about bootp policy.  If a client sends a bootp request
packet with a boot file specified, the server has two choices if it
recognizes the internet address of the requestor (ie. has that client
in his bootptab file) but does not have the requested file (ie. neither
the file nor the file.hostname exists on that server).

The server can either ignore the request, on the logic that the client
knows what is best, and if he asked for a file by name, I should only
answer if I have that particular file.

Or the server can reply, but replace the requested file name with the
file specified for that host in the bootptab file, on the logic that
since I know who this guy is (he is in my bootptab) so I will offer to
boot him with the file that I DO have.  I will leave the choice of
using my file or someone elses up to him, but I will at least have made
him the offer.

Which policy should the robust server support?  The RFC is ambiguous
on this issue.

-- 
			***dan

{decwrl,pyramid,ames}!mips!djl         djl@mips.com (No, Really! Trust Me.)

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 19:52:17 GMT
From:      mwn@mike.ufnet.ufl.edu (Michael Nora)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Ethernet type code 8035 hex?

Ethernet type code 8035 is Reverse ARP - your machine knows it's Ethernet
address, and is asking a server who knows about him to provide him with an IP
address.
--
     Michael Nora       | Internet:  mwn@mike.ufnet.ufl.edu
 University of Florida  | UUCP:  uhmmm .. beats the hell outa me ???
 Data & Video Network   | MaBellNet:  (904) 335-8312 {or 8300}

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 20:43:34 GMT
From:      glass@mica.berkeley.edu
To:        comp.protocols.tcp-ip,comp.sys.apple,comp.protocols.nfs
Subject:   TCP/IP, NFS for Mac

I'm compiling a list of vendors who make TCP/IP and/or NFS implementations
for the Macintosh. I know that Apple itself has announced a Mac TCP/IP,
but don't know if it's shipping, or for which OS (Mac OS or A/UX). I don't
know of any NFS implementations yet.

Please send e-mail if you have more information. Be sure to specify which
operating system each product runs on, as an A/UX product isn't much
use to those who need to run the Mac OS, and vice versa!

Thanks,
Brett Glass

============================================================================
"One of the nicest things about mathematics, or anything else you might
 care to learn, is that many of the things which can never be, often are."
                                      Norton Juster, "The Phantom Tollbooth"
============================================================================

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 20:47:39 GMT
From:      rbj@DSYS.ICST.NBS.GOV (Root Boy Jim)
To:        comp.protocols.tcp-ip
Subject:   Impact of BSD on the Internet

Gentle{,wo}men,

	I am writing a paper on various distributed facilities. I am
interested in the impact that Berkeley UNIX has made on the Internet
and the ARM. It is obviously a great one, and I am well aware of the
fact that UCB was funded by DARPA to develop a TCP/IP suite. I am
also dimly aware of the fact that there used to be something called
NCP that was floating around in the Version 6 days and presumably
had some relation to BBN. I also know that DEC 10's and 20's were
a big part of the (D)ARPANET. Please fill me in on some of the details
before Berkeley entered the scene. Now is the time to wax prolific!
Thank you.

	Root Boy Jim is what I am
	Are you what you are or what?

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      16 May 89 22:53:02 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

/ comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 /
>So far, Sun has amazingly shown great
>restraint in not forcing YP down everyone's throat.

They do force it if you are their customer.  Their setup scripts tipically
give you three choices:
	1. YP server
	2. YP client
	3. not networked at all

On most of their machines, you can do without YP, but it takes a lot of
work to strip off all the stuff that refers to it, replace the libraries
with BIND versions, etc.

The 386i cannot be used without YP at all.

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 00:06:15 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: minimum length ethernet packet

In article <8905151510.AA00477@mitre.arpa> mckee@MITRE.MITRE.ORG (H. Craig McKee) writes:

>
>Questions/Comments
>
>I don't have the LANCE spec sheet, but it seems to me the chip set
>should be passive with respect to packet length; that it is the 
>responsibility of the driver routine to insure proper packet length.

Remember that Ethernet is half-duplex.  A station cannot send and receive
at the same time.  To be able to do so, Ethernet chips would have to be
more complicated than they are.  And their DMA circuitry would have to
be able to support twice the data rate.  The LANCE chip has enough ram 
in its Silo to receive the first 32 bytes of a packet when it is in 
loopback mode.  Basicly, the test is to send a runt 32 byte packet and 
then read what is in the Silo to see if it is what was sent.

A problem with this test is that the interface can't determine if a
failure might be due to faulty hardware or because the runt suffered
a collision.  Perhaps this is part of the reason that the spec sheet
encourages that the test be run several times in case of a failure
before declaring the hardware nonfunctional.

>"Most network vendors ... perform this minimum length packet test ..."
>Is that true? It would imply Xerox should have done a better job
>checking the compatibility of the XEU.

I sorta doubt that this statement is true.  I have a handly little
transceiver cable breakout box that I can use to open the collision
sense pair in the transceiver cable.  What I've found is that most
vendors ignor a missing heartbeat.  I think that, except for DEC,
most vendors are pretty sloppy about looking for errors.

Still I think that if Xerox is going to stick something in the transceiver
cable, they need to provide the local echo "just like a transceiver."
I agree that it sounds like they didn't do their homework.

>Any advice or comments would be appreciated.  Regards - Craig

++++++++++ Please include standard disclaimer here +++++++++++++++++

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 00:17:58 GMT
From:      dfc@hpindda.HP.COM (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Ethernet type code 8035 hex?

>1. What is Ethernet type code 8035 hex?

RARP - Reverse Address Resolution Protocol. Packets go out saying, "This
is my Ethernet address. What's my IP address? RARP server, please respond."

A PC is likely to send a fair number of those packets. It'll be an especially
large number over time if there's no server on the LAN to respond.

Don Coolidge

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 02:03:54 GMT
From:      rhorn@infinet.UUCP (Rob Horn)
To:        comp.protocols.tcp-ip
Subject:   Re: Feynman on standardization

In article <1989May7.232428.14416@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>For some reason this made me think of a number of current standardization
>efforts, notably ISO networking, X.400 and sons, and the X/NeWS standards
>war.  I can't imagine what the connection could be... :-) :-) :-)

Equally apropo, from _Homilies for Humble Standards_, Douglas Ross,
CACM, V19, No 11, Nov 1976:

1. {\em Pro}posed standards can be very beneficial; {\em Im}posed
standards will be a disaster.

2. Standards are not only meaningless, they are actually {\em
dangerous}, if their proper use cannot be understood by those affected
by them.

3. The most important part of a standard is its {\em applicability
clause}, which exactly specifies when {\em not} to use it.

4. Standard{\em ized} methods can become standard methods only when
accepted in use.

5. Standards exist only to {\em serve the needs} of a {\em
non}standard world.  Standards cannot create a standard world.

6. {\em Compatibility} is more achievable than {\em conformability},
and is usually all that is needed.

% from later in the article, not listed as a homily

Humble standards --- those which do not attempt to impose or create
impossible, unacceptable, or impractical levels of standardization ---
are achievable.

The entire original article is well worth repeated reading.  A dozen
years have not improved the general state of standardization efforts
at all.
-- 
				Rob  Horn
	UUCP:	...harvard!adelie!infinet!rhorn
		...ulowell!infinet!rhorn, ..decvax!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 02:40:16 GMT
From:      jnc@proteon.com (J. Noel Chiappa)
To:        comp.protocols.tcp-ip
Subject:   Re:  [RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU: Routing with redundant connections]


 	This is a bit of a tricky subject. The specs as written say that a
Redirect is only sent when the next hop is on the same net, not if there is
a 'better' first hop. To make your case even more plain, assume that network
A is something high speed like an FDDI backbone, so that it makes sense for
the preferred path from Router 1 to Router 2 to be network A.
	RFC-1009 states that: "A gateway will generate an ICMP Redirect if
and only if ... the next-hop gateway is on the same (sub-)network as the
source host." The ICMP RFC (RFC 792) says more or less the same thing: "If
[the next-hop gateway] and the [source host] are on the same network, a
Redirect message is sent".

	However, the real intent of the Redirect was to handle cases "when
the gateway can direct the host to send traffic on a shorter route", to use
the RFC-792 language. As I recall (and my memory of this is dim, since it
was 10 years ago now that we did ICMP :-), the algorithm specified above was
added to provide a concrete example of what to do. It was definitely pointed
out at the time that cases like the one you pointed out existed, but I don't
think we were trying to outlaw that.
	One problem was that all the existing 'gateways' at that time had
routing tables which couldn't *tell* you things like 'Oh, even though some
other gateway is the best next hop for you, and on a different net, there's
this gateway on the source host's net that would be a better first hop for
it'. The case you listed is fairly simple, but suppose your Router 2 is
actually several routers, one connected to network B, one connected tot he
serial link to the destination, and one connected to A, connected in a row
by links of various kinds. It might be legit for 1's best route to C to be
over network A.
	Fixing this kind of thing in general for Vector Distance algorithms
have required a separate routing table be kept per interface, using only
routing info coming in through that interface. Doing it in Link State
algorithms is also some work; you basically have to calculate separate trees
with each attached network as the source node, and see if the first hop to a
given destination is through you or not.
	Also, one nice thing about the way the spec is currently done is
that it's cheap to do the Redirect test; you only need to check more
thoroughly those packets which are being sent out the same interface they
came in on, which should happen rarely and be fast to do.

	However, the next revision of the Router RFC might want to state
that you can provide a Redirect to a host on the same net as the router if
the best first hop for the final destination is not this router but another
one on the same net, and give the more restrictive wording as the default
algorithm.

	Noel

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 03:10:08 GMT
From:      hutton@SCUBED.COM (Thomas Hutton)
To:        comp.protocols.tcp-ip
Subject:   error "No Buffer Space"


In attempting to use a microvax running ultrix 2.X as a gateway into the 
internet, I have recently been getting lots of "No buffer space available"
messages.  At first I thought I was running out of mbuf's but this dosent
seem to be the case.  Does anyone know what I can bump in this ultrix version
to improve this case.  (It recently got worse once we started using LAT
to this system)
 netstat -m
986/1248 mbufs in use:
        65 mbufs allocated to data
        7 mbufs allocated to packet headers
        57 mbufs allocated to socket structures
        74 mbufs allocated to protocol control blocks
        773 mbufs allocated to routing table entries
        6 mbufs allocated to socket options
        4 mbufs allocated to interface addresses
0/128 mapped pages in use
284 Kbytes allocated to network (43% in use)
0 requests for memory denied

adb /vmunix /dev/kmem 
nbuf/D
_nbuf:
_nbuf:          818

Thanks,
Tom Hutton
hutton@scubed.com

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 03:57:47 GMT
From:      milne@ics.uci.edu (Alastair Milne)
To:        comp.protocols.tcp-ip
Subject:   Re:  TELNET Buffering Woes

dab@opus.cray.com (Dave Borman) writes
>The problem here is not with the remote machine, but with the local
>telnet implementation.  The way that things should work is:
>	User types ^C
>	Local telnet translates that to, and sends, IAC IP,
>		and then sends IAC DO TIMING-MARK and begins to
>		flush all output.
>	Local telnet receives IAC WILL/WONT TIMING-MARK, and
>		resumes terminal output.
>
>The problem is that many telnet implementations are very dumb.  They
>are not doing local recognition of the interrupt character, and thus
>they don't know when to send the DO TIMING-MARK and start output flushing.

    Sorry if this has already been covered, but: Does anybody know if Sun's
    version of telnet for PC-NFS 3.0 on the IBM PC/PS-2 has such problems?
    While I haven't tried breaking a long unwanted stream with ^C (haven't had
    to yet, fortunately) this telnet is often subject to sudden delays of from
    1 to maybe 8 seconds, during which there is no activity at all, and then a
    rush to catch up.  In our whole department, we seem to be the only ones
    suffering this delay, and I think we're the only ones using PC-NFS.

    Any insights or prior experience with this problem would be welcome.


    Thanks,
    Alastair Milne,
    Educational Technology Center,
    Dept of ICS
    UCalif. Irvine

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed May 17 12:40:55 1989
From:      microsoft!randyd@beaver.cs.washington.edu
To:        uw-beaver!tcp-ip@sri-nic.arpa
Subject:   Joining the Internet
I'm not sure where to ask this, but what is the procedure for obtaining
Internet connectivity?  Is the procedure ad-hoc?  Do you tie in through
a regional network? If so, which one? What sort of fees are charged?

Thanks for any pointers,
Randy Day
microsoft!randyd@uw-beaver.cs.washington.edu

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      17 May 89  14:20 EST
From:      hs@relay.proteon.com
To:        tcp-ip@sri-nic.arpa, hs@relay.proteon.com
Subject:   Token Ring Patent
          Unfortunately, I know quite a bit about the Soderblom
          patent. It was first issued in the fall of 1981 after much
          consideration at the Patent Office. The senior patent in
          this area is Farmer and Newhall (AT&T). During the '70's,
          there were several interferences between the claims of
          Soderblom and those of Farmer and Newhall.  The Farmer and
          Newhall design, patented in 1971, was used by Dave Farber to
          help in the creation of the UC Irvine Ring (If I'm wrong,
          Dave, Please correct me). Then, Jerry Saltzer, Dave Clark,
          Ken Pogren and a bunch of people here at Proteon used the UC
          Irvine Ring to help in the creation of ProNET-10.

          Proteon never expected patent problems. In fact, in 1982, I
          presented details of our design at IEEE Headquarters in NYC
          to many AT&T employees including Bob Lucky. We joked about
          the fact that I was using BSTJ figures for my presentation,
          thus bringing new meaning to the phrase "not invented here".
          The Soderblom patent applied to systems which consisted of a
          master and a plurality of terminals. Farmer and Newhall was
          the senior patent when it came to closed loop operations.

          In 1983 or maybe 84, Soderblom presented at IEEE802.5. We
          were well aware of the Soderblom position. IEEE staff were
          also involved. We went ahead on the basis that Soderblom
          would provide licenses in a nondiscriminatory way. We also
          had a good idea of the probable terms for such a license.

          Since that time, the Patent Office has allowed a reissue of
          the Soderblom patent. The reissue has much more general
          claims. Many organizations filed objections which were
          brushed aside by the patent Office. That's why he has
          general coverage of a 1967 idea until 1998. His patents have
          run out elsewhere in the world. Don't blame Olaf.

          Many of us object to the whole procedure. That is, Was the
          token ring a new concept or an" old combination" in 1967?
          Many of us object to the details of the legal rangling.
          Nonetheless many of us have signed up simply because the
          patent office has spoken. In all cases, the exact terms of
          the license are covered by a non disclosure clause.

          It is also clear that some have chosen not to sign a
          license with Soberblom. It is expected that someone will
          take this to court for resolution.  Time will tell.

          Howard Salwen, Chairman-Founder
          Proteon, Inc.
          hs@relay.proteon.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 10:11:57 GMT
From:      tom@rsp.UUCP (Thomas Ruf)
To:        comp.protocols.tcp-ip
Subject:   Re: minimum length ethernet packet

In article <8905151510.AA00477@mitre.arpa>, mckee@MITRE.MITRE.ORG (H. Craig McKee) writes:
> .....             During power-up and self-testing, many devices
> (including DECserver 100's) create a 32 byte packet (36 bytes with
> CRC).  This packet is transmitted to the network.  The device expects
> to receive the packet back from the network.  This is how the device
> determines that the network is operational. ..............
> .....
> I don't have the LANCE spec sheet, but it seems to me the chip set
> should be passive with respect to packet length; that it is the 
> responsibility of the driver routine to insure proper packet length.

The LANCE is a half duplex device, which is sufficient for normal Ethernet
operation. If you want to perform an external loopback test, as DEC
does it during power-up, you need full duplex. Therefore, the LANCE
has a special "external loopback test mode" which allows simultaneous
send and receive operation. However, due to the size of the fifo,
the packet length is limited to 36 bytes.

Thomas
-- 
Thomas Ruf				Schneider & Koch GmbH
{uunet,mcvax}!unido!rsp!tom		West-Germany

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 11:32:10 GMT
From:      doug@ICASE.EDU (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   wy60 termcap

I apologize for this request on this mailing list, but I'm in a bit
of a bind.  Does anyone have a termcap entry for a Wyse 60 termninal
for a Sun (OS3.5)?

Please mail it directly to me, so that this list isn't further cluttered.

Thanks in advance.

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

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 May 89   11:03 MEZ
From:      MAIER%EDVZ.UNI-SALZBURG.ADA.AT@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   protocol types

Is there a document containing a list of all protocol types used in
TCP/IP protocols (for example ARP requests: 0806).

Franz Maier                      MAIER@EDVZ.UNI-SALZBURG.ADA.AT
EDVZ, Univ.Salzburg
Austria
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 13:36:29 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  [RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU: Routing with redundant connections]

*From: jnc@proteon.com (J. Noel Chiappa)

*	RFC-1009 states that: "A gateway will generate an ICMP Redirect if
*and only if ... the next-hop gateway is on the same (sub-)network as the
*source host." The ICMP RFC (RFC 792) says more or less the same thing: "If
*[the next-hop gateway] and the [source host] are on the same network, a
*Redirect message is sent".


*	Noel

it all depends on how you interpret the line above. it doesnt say
something to the effect of "using the same interface", it says "is on
the same subnet".  both routers *are* on the same subnet as the host,
regardless of the routing of packets between the two routers. the
routers *should* send the ICMP redirect. now, this may be hard for
the router in question to know (that the second router is also on
the subnet that the host is on), but this is something that needs to be
dealt with in the routing protocols.


this may, ofcourse, not be in keeping with the "spirit" of the above lines,
but seems to me to be a reasonable interpretation. so i must be missing
something . . . . . .


stev knowles
stev@ftp.com
ftp softwar

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 13:42:32 GMT
From:      dab@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   BOOTP Policy Question

I'd say the server shouldn't reply if it doesn't have the requested file.
Not only does the client knows best, but there is likely to be another
bootp server that has the boot load that the client is looking for.

						David Bridgham

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 15:43:47 GMT
From:      MAIER@EDVZ.UNI-SALZBURG.ADA.AT
To:        comp.protocols.tcp-ip
Subject:   protocol types


Is there a document containing a list of all protocol types used in
TCP/IP protocols (for example ARP requests: 0806).

Franz Maier                      MAIER@EDVZ.UNI-SALZBURG.ADA.AT
EDVZ, Univ.Salzburg
Austria

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 16:19:11 GMT
From:      doug@csd4.milw.wisc.edu (Doug Tiarks)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   sendmail hanging during SMTP session



Awhile back douglis@MINT.BERKELEY.EDU (Fred Douglis) reported a
problem with sendmail:

>>We're experiencing a problem sending mail to an internet host
>>(decwrl.dec.com) -- the symptom is that the mailer hangs for a long
>>time and then complains "reply: read error", apparently in the phase
>>just after it sends the body of the message.  I heard that about the
>>same time we started having this problem on Sprite, a small number of
>>Suns running SunOS 3.2 had the same problem, and I was told that
>>upgrading the kernel to 3.4 fixed the problem.  This is why I believe
>>the problem might have something to do with the TCP connection (since
>>just about everything at user level is the same, but the kernel is
>>new).

We are apparently seeing this problem from the other side.
Occasionally sendmail will go to sleep (waiting for input ?) during a
SMTP session with another host which is trying to deliver a message to
us.  This occurs at different stages (HELO, MAIL FROM, DATA) of the
SMTP session.  Sendmail eventually times out, but the host on the
other end apparently makes multiple tries during the timeout period
with the same result.  We're running v5.61 of sendmail with some fixes
from comp.bugs.4bsd under 4.3bsd-tahoe on a tahoe machine.

Anyone experiencing similar problems? Anyone know of a fix?



	Doug Tiarks
	UW-Milwaukee Computing Services Div.

	Internet: doug@csd4.milw.wisc.edu
	UUCP: {uwvax, uwmacc}!uwmcsd1!doug

--

	Doug Tiarks
	UW-Milwaukee Computing Services Div.

	Internet: doug@csd4.milw.wisc.edu
	UUCP: {uwvax, uwmacc}!uwmcsd1!doug

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 May 89 00:02:15 PDT
From:      melohn@Eng.Sun.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?
In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
>/ comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 /
>They do force it if you are their customer.  Their setup scripts tipically
>give you three choices:
>	1. YP server
>	2. YP client
>	3. not networked at all

This is misleading; the installation procedure used in the current
versions of SunOS allow you to choose one of the following options for
YP: server, master, client, or none. Independent of this choice is the
configuration option for network interface.

>On most of their machines, you can do without YP, but it takes a lot of
>work to strip off all the stuff that refers to it, replace the libraries
>with BIND versions, etc.

Again, under current versions of the operating system, all that is
required is the replacement of the shared library with one linked with
the resolver routines. Such a library is available for FTP from
several Internet sources, and in tape form from the US answer center.

>The 386i cannot be used without YP at all.

The above does not refer to the sun386i.
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 May 89 17:28:15 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/Soderblom answer

In article <93400021@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes:
>  I say write the guy a nice letter to the effect "hey buddy, how'd you like
>the high-speed network of the future to be based on your stuff? Have I go
>a deal for you....."

This assumes that he is rational about such things.  Particularly in legal
matters, assuming that people are rational is seldom wise.

"If you don't want to know the answer, don't ask the question."
-- 
Subversion, n:  a superset     |     Henry Spencer at U of Toronto Zoology
of a subset.    --J.J. Horning | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 17:56:19 GMT
From:      scotth@grebyn.COM (Scott Hutchinson)
To:        comp.protocols.tcp-ip
Subject:   Re: protocol types

In article <8905171543.AA05494@ucbvax.Berkeley.EDU> MAIER@EDVZ.UNI-SALZBURG.ADA.AT writes:
>
>Is there a document containing a list of all protocol types used in
>TCP/IP protocols (for example ARP requests: 0806).
>

	Can you be more specific?  I believe IEEE would have some stuff
on it, if not then some of the vendors maybey?  what exactly do you
need?

					-Scott Hutchinson

-- 
----------------------------------------------------------------------------
Standard Disclamers:  These opinions are mine, they do not reflect on my
                      Company at all.
I can be reached at scotth@grebyn.com or scotth@grebyn.uucp

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 18:39:01 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   sendmail 5.61 vs the nameserver

I recently installed sendmail 5.61, and after a week of incredibly bad
performance, went back to 5.60 while I figure out what's going wrong.

The problem was that our throughput dropped tremendously.  We have only
a Vax-750, which you might optimistically rate at .75 MIP, and the new
sendmail seemed to make the system run quite a bit slower.

I suspect that it is 5.61's interaction with the nameserver that causes
this.  We have it configured with the NO_WILDCARD_MX option set, which
causes it to do a C_ANY call on the nameserver instead of a C_CNAME.  I
believe the theory behind doing this was that by making such a call, the
local nameserver would cache all the data for the hostname being looked
up, which would save a second reference across the internet for the
common case where an MX lookup is followed by an A lookup for the same
host.

However, this also causes WKS, HINFO, and every bloody thing else known
about that host to get transferred too, and we have observed that the
memory working set of the bind nameserver with 5.61 was much larger than
with 5.60 which didn't do C_ANY.  In fact, it got larger than our
available physical memory, which means that the poor little 750 was
paging for a good percentage of the mail passing through.

I have yet to try 5.61 with the C_ANY disabled, as it took us several
days to recover from the previous misadventure and I'm not anxious to go
through that again.

Does anyone have any ideas about this sort of interaction?  Or is there
simply some bugfix for 5.61 that'll correct this situation?

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD C-010, La Jolla, CA 92093 USA
			brian@ucsd.edu ucsd!brian BRIAN@UCSD

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 20:12:04 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: FDDI/Soderblum(?)

In article <13082@ut-emx.UUCP> bud@emx.UUCP (C. E. "Bud" Spurgeon) writes:
+---------------
| Ethernet is patented.  Xerox has two patents on the system from 1975.
+---------------

Quite true. One is on collision detection (any form of CSMA/CD), and the
other is on repeaters which know about collision detection. Also note that
1975 + 17 = 1992. That is, they're still in force.

+---------------
| The IEEE802.3 specs note that "The Xerox Corporation has assured the
| IEEE that it is willing to grant a license under these patents on
| reasonable and nondiscriminatory terms and conditions to anyone
| wishing to obtain such a license."
| I assume Xerox decided to let the technology out without hassling
| anyone for royalties.  I've never heard of someone getting an Ethernet
| license from Xerox.  Does anyone bother to do so, one wonders?
+---------------

Well, *honest* people did & do!  ;-}   After all, I would say the terms
are quite "reasonable and nondiscriminatory" -- a $1000 one-time license
fee per patent per manufacturer (i.e. $2000 total).

+---------------
| In article <8905151730.AA06800@vax.ftp.com> stev@VAX.FTP.COM writes: >
| >                   ...   can you imagine a world where every ethernet
| >board had a royality paid on it? or every RS232 port?  
+---------------

Yes, and Ethernet wouldn't have succeeded nearly as well. Thankfully,
Xerox wanted Etehrnet to succeed more than they wanted to grub a few
bucks. As a result, they probably sold a *lot* more Ethernet components
than they would if it had been more restricted.

Though note, at one point, the patent license fee for building *anything*
that sat on a DEC Unibus was $100 or 10% of retail (whichever was less)
*per copy*, that is, per board that plugged into a Unibus. The add-on
market grumbled, but paid. There was a thriving market in Unibus peripherals...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 20:16:11 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: A pox on FTP clients!

In article <8905161441.AA27428@sun.soe.clarkson.edu>,
nelson@clutx.clarkson.edu writes:
+---------------
| A pox on anyone who failed to implement continuation lines in their
| FTP clients!  And a warning on anyone who tries to use them in their
| FTP server -- don't!    -russ
+---------------

Oops! We'd better hurry and go rip the "HELP" command out of all
those FTP servers out there... ;-}  ;-}


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 21:17:43 GMT
From:      rbj@DSYS.ICST.NBS.GOV (Root Boy Jim)
To:        comp.protocols.tcp-ip
Subject:   Reconciling /etc/hosts, yp, and named?

? / comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 /
? >So far, Sun has amazingly shown great
? >restraint in not forcing YP down everyone's throat.

? They do force it if you are their customer.  Their setup scripts tipically
? give you three choices:
? 	1. YP server
? 	2. YP client
? 	3. not networked at all

? On most of their machines, you can do without YP, but it takes a lot of
? work to strip off all the stuff that refers to it, replace the libraries
? with BIND versions, etc.

Well, yes and no. We run SunOS 3.5 with the 4.0 nameserver kit. All this
does is give you an MX sendmail that talks to the name server and a new
libresolv.a and netdb.h to build against. Actually, everything else
looks in /etc/hosts. If it's not there, you can use nslookup to find
the IP address and use the dotted notation raw. I haven't built any
kernels recently, but I seem to remember setup also giving you the
choice of not using YP at all.

? The 386i cannot be used without YP at all.

Hey, I was only talking about real Suns :-)

? Jacob Gore				Gore@EECS.NWU.Edu
? Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

	Root Boy Jim is what I am
	Are you what you are or what?

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      17 May 89 21:23:27 GMT
From:      mwn@mike.ufnet.ufl.edu (Michael Nora)
To:        comp.protocols.tcp-ip
Subject:   Re: protocol types

In article <8905171543.AA05494@ucbvax.Berkeley.EDU> MAIER@EDVZ.UNI-SALZBURG.ADA.AT writes:

>Is there a document containing a list of all protocol types used in
>TCP/IP protocols (for example ARP requests: 0806).

I've got a fairly current list of both ethernet types codes and
manufacturer address prefixes I'll post to the net if anyone is interested.
(I tried mailing them to the requester, but mail to foreign contries never
works for me).

--
     Michael Nora       | Internet:  mwn@mike.ufnet.ufl.edu
 University of Florida  | UUCP:  uhmmm .. beats the hell outa me ???
 Data & Video Network   | MaBellNet:  (904) 335-8312 {or 8300}

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 04:47:46 PDT (Thursday)
From:      Armstrong.WBST128@Xerox.COM
To:        tcp-ip@sri-nic.Arpa
Subject:   Re: What is Ethernet type code 8035 hex?

Ethernet type 8035 hex is officially registered to Stanford University,
with Dave Cheriton as the contact.

Note that it is (unfortunately) fairly common to have people building
Ethernet applications without registering their Ethernet type.  Such people
guessing at an unused type often clash with officially registered types.
Hence, these packets from your PC may have nothing to do with Stanford or
Cheriton.  Should this turn out to be true, and you discover the vendor
using 8035 hex, they should be strongly encouraged to obtain a registered
type.

Good luck!

Cheers,
    Susie
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 May 89 07:47:03 EDT
From:      dvaughan@wnyosi7.arpa (Dave Vaughan)
To:        tcp-ip@sri-nic.arpa
Cc:        dvaughan
Subject:   ANSI T1LB168

Has anyone heard of an ANSI standard T1LB168 titled "Principles of
Architecture and Protocols for Interfacing between Operating
Systems and Network Environments"?  If so, can you give me a brief
background.  Also is there a copy on-line somewhere?  Thanks.

					David Vaughan
					Dept. of Navy

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 12:13:55 GMT
From:      mankin@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: error "No Buffer Space"

>In attempting to use a microvax running ultrix 2.X as a gateway into the 
>internet, I have recently been getting lots of "No buffer space available"
>messages.  At first I thought I was running out of mbuf's but this dosent
>seem to be the case.
 
> netstat -m
>986/1248 mbufs in use:
>        65 mbufs allocated to data
 
>0 requests for memory denied

Tom,

The 65 mbufs allocated to data leads to a guess that your
MicroVax is running a DDN X.25 connection to a PSN net.
You should check whether your link to the PSN is running
and whether it's congested.  The message "No buffer space 
available" is a translation of the error number ENOBUFS.  
Besides covering cases of mbuf exhaustion, which as you say is
not the case here, ENOBUFS is returned through IP and TCP if the
network output queue overflows, which it may be doing because
the path is congested.

Allison

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 15:33:05 GMT
From:      bbn.com!mckenzie@bbn.com  (Alex McKenzie)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Impact of BSD on the Internet


Dear Root Boy Jim:

I'm writing in response to your message to the tcp-ip list titled
"Impact of BSD on the Internet".

1.  There was indeed a thing called NCP around in the early days of the
    ARPANET.  NCP was the acronym for Network Control Protocol, and it
    was the official host-to-host protocol from 1970 through 1982 (the
    official cutover data from NCP to TCP was January 1, 1983).  NCP had
    nothing to do with BBN;  it was developed by a committee of network
    host organizations called the Network Working Group (NWG), the first
    chairman of which was Stephen Crocker of UCLA.  I believe the first
    mention of NCP in the public literature was a paper by Stephen Carr,
    Stephen Crocker, and Vinton Cerf at the 1970 Spring Joint Computer
    Conference titled "Host-Host Communication Protocol in the ARPA
    Network."

2.  The first TCP/IP implementation for UNIX was written by BBN with
    Defense Communications Agency (DCA) funding.  It was written for
    UNIX Version 6 by Michael Wingfield and was completed by March 15,
    1979 (see IEN 93*).  Another early TCP implementation for UNIX
    Version 6 was written by Digital Technology Incorporated at about
    the same time.

    BBN also wrote the first TCP for Berkeley UNIX, with DARPA funding.
    The project was led by Rob Gurwitz and is described in IEN 168
    (January 1981) as being "designed for the VAX, running VM/UNIX, the
    modified version of UNIX 32/V developed at the University of
    California, Berkeley." As might be expected in a TCP project carried
    out by BBN, performance was optimized for the characteristics of
    wide-area networks.  The folks who were both starting SUN
    Microsystems and also directing the development of Berkeley UNIX
    wanted a TCP implementation optimized for LANs, and were successful
    in having the BBN TCP implementation removed from BSD releases and
    replaced with their own implementation which was so optimized.

3.  TENEX was a paged, virtual memory, time sharing system for the DEC
    PDP-10 computer which was developed by BBN to support AI research.
    It used paging hardware designed and built by BBN.  The development
    was funded by ARPA and TENEX became operational in early 1969.  It
    is described in a paper by Bobrow, Burchfiel, Murphy, and Tomlinson
    in Communications of the ACM, Volume 15, Number 3 (March 1972).
    TENEX served as the basis for DEC's TOPS-20 operating system.

    DEC PDP-10s generally, and TENEX specifically, were by far the
    single most popular "server" computers during the first several
    years of the ARPANET.  (In those days ARPANET hosts were commonly
    characterized as "users" or "servers"; a server provided file
    storage and cycles, while a user system primarily provided access to
    the network.) For example, in December 1970, according to a quick
    count I just made, 10 of the 20 ARPANET servers were PDP-10s and in
    June 1975, 23 of 47 servers were PDP-10s.  Although I do not have a
    breakdown of operating systems in use on these PDP-10s, I believe
    that over 3/4 of the DEC-10s on the ARPANET at any time were running
    TENEX.  Other popular operating systems for the PDP-10 were DEC's
    10/50 system and MIT's Incompatible Timesharing System (ITS).

I hope this information is helpful.
Alex McKenzie

* IENs are available online from the ARPANET Network Information Center
  at SRI-NIC.ARPA
 
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 May 89 19:45:28 EDT
From:      Boots Cassel <cassel%villanova.edu@RELAY.CS.NET>
To:        tcp-ip%sri-nic.arpa@RELAY.CS.NET, performance%cs.wisc.edu@RELAY.CS.NET
Cc:        austing%tove.umd.edu@RELAY.CS.NET, lcrum%odin.wright.edu@RELAY.CS.NET, drine%gmuvax.bitnet@RELAY.CS.NET, asood%gmuvax.bitnet@RELAY.CS.NET, jehn%dayton.bitnet@RELAY.CS.NET, taylor%csvax.csc.lsu.edu@RELAY.CS.NET, friedman%cis.temple.edu@RELAY.CS.NET, friedman%templcis.bitnet@RELAY.CS.NET, pegotty%acmvm.bitnet@RELAY.CS.NET, walker%mimsy.umd.edu@RELAY.CS.NET, cassel@RELAY.CS.NET, austing%tove.umd.edu@RELAY.CS.NET, drine%gmuvax.bitnet@RELAY.CS.NET, asood%gmuvax.bitnet@RELAY.CS.NET, schultz%gmuvax2.gmu.edu@RELAY.CS.NET, youman%mdf.mitre.org@RELAY.CS.NET, miller%wmcs.wm.edu@RELAY.CS.NET, friedman%cis.temple.edu@RELAY.CS.NET, friedman%templcis.bitnet@RELAY.CS.NET, walker%mimsy.umd.edu@RELAY.CS.NET, pegotty%acmvm.bitnet@RELAY.CS.NET, cassel@RELAY.CS.NET, cs_hwang%swtexas.bitnet@RELAY.CS.NET, rsb%bashful.aca.mcc.com@RELAY.CS.NET, i01bailey%etsu.bitnet@RELAY.CS.NET, cs_hazlewood%swtexas.bitnet@RELAY.CS.NET, cs_mccabe%swtexas.bitnet@RELAY.CS.NET, potter%emx.utexas.edu@RELAY.CS.NET, meggen%trinity.bitnet@RELAY.CS.NET, ndale%ratliff.utexas.edu@RELAY.CS.NET, austing%tove.umd.edu@RELAY.CS.NET, friedman%cis.temple.edu@RELAY.CS.NET, friedman%tmplcis.bitnet@RELAY.CS.NET, pegotty%acmvm.bitnet@RELAY.CS.NET, walker%mimsy.umd.edu@RELAY.CS.NET, cassel@RELAY.CS.NET
Subject:   Call For Participation
                      ACM Computer Science Conference
                           Call for Participation

The ACM Computer Science Conference provides a forum for the transfer
and exchange of information in three contexts:

      * Between experts or specialists in one area of computer science
and others whose specialties are marginally related or somewhat
affected by results in the first area.  Communication is between
researchers in different, though possibly overlapping domains.  SURVEY
PAPERS of some depth are suitable submissions.

      * Among specialists in areas of computer science either too new
or too narrowly focused to have its own conference.  The CSC provides
an opportunity for such researchers to meet and for others to hear of
their work.  RESEARCH PAPERS, POSTER SESSION participation, and birds
of a feather sessions in the specialty area are complemented by other
CSC events: the TURING lecture, ACM awards, EXHIBITS by publishers and 
vendors of computing hardware and software, and the employment
register.

       * Finally, the CSC is an opportunity to gain exposure to
current research in a number of CS areas, for general interest and
knowledge updating.  


                 ACM  CSC   1990
                February 21-23, 1990
                Sheraton Washington Hotel
                Washington,  DC
 
               Preconference Tutorials:  February 20
 

General Chairman:  David Rine     drine@gmuvax  (bitnet)
Program Chairman:  Arun Sood      CSC90@gmuvax   
Exhibits Chairman: Keith Milller  miller@wmcs.wm.edu

               Conference Theme:  Cooperation

The three conference theme days will feature invited speakers, panels,
refereed papers, and poster sessions emphasizing the topic areas: 
 
               Cooperation Among Processing Units
(Hybrid Computers, Neural Networks, Distributed Operating Systems,
Distributed Optimization, Distributed Database, Computer Complexity of
Distributed Systems, Parallel Architectures)

                 Cooperation Among Technologies
(Hardware/Software Engineering, Telecommunications/Computers,
Theory/Practice, Languages, Biology/Computer Science)

                   Cooperation Among Disciplines
(Human Machine Interfaces, Visualization in Scientific Computing,
Opto-electronics, VLSI and Software Engineering, Factory of the
Future, Robotics and Artificial Intelligence, CAD/CAM, System
Engineering, Computers in Medicine)

Important dates:
Papers (5 copies <= 20 pages, double spaced, 12 pt.) August 15, 1989
Acceptance Notice:  November 1, 1989
Camera Ready Copy: December 1, 1989

The Program Committee will select outstanding papers to be considered
for expansion into CACM or one of the other ACM publications
(depending on subject).

Research abstracts and short reports suitable for poster session:
Camera ready form (12 pt font, single column 4.2" wide 250 words) must be
received by November 15, 1989.  Notice of review decision by December 15.

The SIGCSE (Computer Science Education) Technical Symposium will be
held in conjunction with the CSC, February 23-24, 1990.  For further
information, contact Dr. Richard Austing: austing@tove.umd.edu

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 16:17:00 GMT
From:      phil@ux1.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: sendmail hanging during SMTP sessio


> We are apparently seeing this problem from the other side.
> Occasionally sendmail will go to sleep (waiting for input ?) during a
> SMTP session with another host which is trying to deliver a message to
> us.  This occurs at different stages (HELO, MAIL FROM, DATA) of the
> SMTP session.  Sendmail eventually times out, but the host on the
> other end apparently makes multiple tries during the timeout period
> with the same result.  We're running v5.61 of sendmail with some fixes
> from comp.bugs.4bsd under 4.3bsd-tahoe on a tahoe machine.
> 
> Anyone experiencing similar problems? Anyone know of a fix?

I have been seeing this happen occaisionally on several hosts receiving mail
from IBM VM SMTP.  Some cases have been verified as having well over 100
destination addresses, one per line, in the RFC822 To: field.  Attempts to
send the same mail to other hosts running sendmail 5.61 also resulted in
sendmail getting hung.  Another version of sendmail delivered the mail, but
inserted a blank line after the 100 or so To: addresses it was parsing.

You might experiment with that to see if that is causing the same kind of
hangup in sendmail.

--phil howard--  <phil@ux1.cso.uiuc.edu>

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 16:26:10 GMT
From:      galbp!wittsend.LBP.HARRIS.COM!mhw@gatech.edu  (Michael H. Warfield (Mike))
To:        tcp-ip@sri-nic.arpa
Subject:   Re: A pox on FTP clients!
In article <8905161441.AA27428@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>A pox on anyone who failed to implement continuation lines in their
>FTP clients!  And a warning on anyone who tries to use them in their
>FTP server -- don't!

	Yeah.  I agree with this, sort of.  Anyone who claims to have
implimented an ftp client but didn't include support for continuation lines
obviously didn't finish the job or didn't know what the h*ll he was doing.
As far as the server goes though, how would you propose to support the "HELP"
command without continuation lines??  Since that particular protocol command
depends on continuation lines in it's response, any ftp client that does not
support continuation lines either can't support the remote help function or
is flat out BROKE (I opt for the latter).  Any reasonable server should
support the "HELP" command, and as such must use continuation lines.
(BTW: I've done implimentations of both client and server).

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 16:29:34 GMT
From:      edguer@charlie.CES.CWRU.Edu (Aydin Edguer)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Ethernet type code 8035 hex?

8035 is an RARP packet.
 > 2. What document or standard defines relation between values in this field 
 >    and higher level protocols?
The document you are looking for is RFC 1010 - Assigned Numbers.
In this document you will find a section ETHERNET NUMBERS OF INTEREST (pg 13).
This is just the list of the ethernet types assigned by XEROX at the time (May
1987).  There are other, unassigned types in use.
-- 
Aydin Edguer		+1 216 368 6123		edguer@alpha.ces.cwru.edu
Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 16:57:58 GMT
From:      tpc@bnr-fos.UUCP (Tom Chmara)
To:        comp.protocols.tcp-ip
Subject:   Paranoia:  fragmentation of UDP packets at user level?

I'm writing YAMI (Yet Another Message Interface) to use unconnected datagram
sockets on a SUN (OS 4.0.1) workstation.
	I suddenly realized that I wasn't sure whether a UDP packet HAD to
be returned in its entirety in response to a recv() or read() call.
That is, is there any possibility that a read() of a UDP packet could result
in a --partial-- read being returned?
	I *think* UDP is all-or-nothing (witness the checksum):  if you get it,
you get ALL of it; otherwise, you don't get it.  (you can, of course, get
clones..  but that's another issue).  RFC 768 suggests this type of interface
with IP, but it doesn't seem to require it.
	I sure hope I'm right; I'd hate to have to figure out a way of
regaining synchronization on a UDP channel...

Thanks for your time...
	---tpc---

-- 
I am sole owner of the above opinions. Licensing inquiries welcome.
------------------------------------------------------------------------
Tom Chmara			UUCP:  ..utgpu!bnr-vpa!bnr-fos!tpc
BNR Ltd.  			BITNET: TPC@BNR.CA

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 17:31:24 GMT
From:      jordan@cs.columbia.edu (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

Root Boy Jim <rbj@DSYS.ICST.NBS.GOV> writes:

	Simpler to just use one name, and use naked IP addresses on the
	ifconfigs.

The DNS was created to make things easier.  Using IP addresses doesn't
make things easier.  If you have two IP addresses on the same machine,
name them uniquely and put the following data into your database:

foo		IN	A	128.253.5.1
		IN	A	128.253.6.1
foo-gw		IN	A	128.253.6.1

That way, if I ask for "foo", I get two addresses to try.  If I ask for
foo-gw, I get the right one.  Your hostname (for any kind of external
identification) should be "foo" -- the only problem this leaves us is
what to do about the reverse lookup.  Possibilities include returning
"foo" for either address (good for continuity), or returning the
interface-specific name (good for troubleshooting and correctness).

/jordan

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 17:37:30 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

/ comp.protocols.tcp-ip / melohn@ENG.SUN.COM (Bill Melohn) / May 18, 1989 /
> In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
> >They do force it if you are their customer.  Their setup scripts tipically
> >give you three choices:
> >	1. YP server
> >	2. YP client
> >	3. not networked at all
> 
> This is misleading; the installation procedure used in the current
> versions of SunOS allow you to choose one of the following options for
> YP: server, master, client, or none. Independent of this choice is the
> configuration option for network interface.

I apologize.  I have only dealt with 4.0.1 on the 386i.

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 18:02:56 GMT
From:      mo@prisma.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Feynman on standardization

In fact, life is much worse.

Vendors have discovered that standards can be used to directly
manipulate market share.  This is certainly NOT "standards
in the service of the users."

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 19:14:48 GMT
From:      rds95@leah.Albany.Edu (Robert Seals)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   NCSA telnet for PC question

[Sorry for the crossposting; not sure where this should go.]

I finally got my WD8003 board. I set it up at 0xd000 and stealing
interrupt 3; I told it to use 32k. I hooked it up, and started
telnet, and...

it worked!

But I notice that both the PC and Mac versions are VERY slow to
build their connections. Is there a reason for this, and a
corresponding way to speed it up?

And ftp didn't work, so I gotta work on that one...any suggestions,
or a more concise explanation of how it all works than is included
in the distribution would be greatly appreciated.

rob

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 20:26:41 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 wanted

You may obtain tn3270 (not exactly public domain, rather a "public
service distribution") from ucbarpa.berkeley.edu, directory pub/tn3270.

The alternative method for obtaining the sources is to send a check
for $100.00 (US) payable to "the Regents of the University of California"
to:
	Campus Software Office
	295 Evans Hall
	UC Berkeley, CA  94720

and enclose a note asking for tn3270.  It comes (these days) on a Sun
tape cartridge.

(Note that this is, not surprisingly, a Berkeley Unix version.)

Greg Minshall				Kinetics, a division of Excelan
...!ucbvax!unisoft!kinetics!minshall	1-415-947-0998

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 May 89 06:30:24 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        pcpond!farber@louie.udel.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Token Ring Patent
What goes around, comes around.

It was interesting to note that while the MIT-derived work on the ring
went from distribute processing, with process names, over to more
independent networking, with host names, the folks at Sytek, developing
NetBios for IBM, put process names back in.

Dave
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      18 May 89 23:45:28 GMT
From:      cassel@villanova.EDU (Boots Cassel)
To:        comp.protocols.tcp-ip
Subject:   Call For Participation


                      ACM Computer Science Conference
                           Call for Participation

The ACM Computer Science Conference provides a forum for the transfer
and exchange of information in three contexts:

      * Between experts or specialists in one area of computer science
and others whose specialties are marginally related or somewhat
affected by results in the first area.  Communication is between
researchers in different, though possibly overlapping domains.  SURVEY
PAPERS of some depth are suitable submissions.

      * Among specialists in areas of computer science either too new
or too narrowly focused to have its own conference.  The CSC provides
an opportunity for such researchers to meet and for others to hear of
their work.  RESEARCH PAPERS, POSTER SESSION participation, and birds
of a feather sessions in the specialty area are complemented by other
CSC events: the TURING lecture, ACM awards, EXHIBITS by publishers and 
vendors of computing hardware and software, and the employment
register.

       * Finally, the CSC is an opportunity to gain exposure to
current research in a number of CS areas, for general interest and
knowledge updating.  


                 ACM  CSC   1990
                February 21-23, 1990
                Sheraton Washington Hotel
                Washington,  DC
 
               Preconference Tutorials:  February 20
 

General Chairman:  David Rine     drine@gmuvax  (bitnet)
Program Chairman:  Arun Sood      CSC90@gmuvax   
Exhibits Chairman: Keith Milller  miller@wmcs.wm.edu

               Conference Theme:  Cooperation

The three conference theme days will feature invited speakers, panels,
refereed papers, and poster sessions emphasizing the topic areas: 
 
               Cooperation Among Processing Units
(Hybrid Computers, Neural Networks, Distributed Operating Systems,
Distributed Optimization, Distributed Database, Computer Complexity of
Distributed Systems, Parallel Architectures)

                 Cooperation Among Technologies
(Hardware/Software Engineering, Telecommunications/Computers,
Theory/Practice, Languages, Biology/Computer Science)

                   Cooperation Among Disciplines
(Human Machine Interfaces, Visualization in Scientific Computing,
Opto-electronics, VLSI and Software Engineering, Factory of the
Future, Robotics and Artificial Intelligence, CAD/CAM, System
Engineering, Computers in Medicine)

Important dates:
Papers (5 copies <= 20 pages, double spaced, 12 pt.) August 15, 1989
Acceptance Notice:  November 1, 1989
Camera Ready Copy: December 1, 1989

The Program Committee will select outstanding papers to be considered
for expansion into CACM or one of the other ACM publications
(depending on subject).

Research abstracts and short reports suitable for poster session:
Camera ready form (12 pt font, single column 4.2" wide 250 words) must be
received by November 15, 1989.  Notice of review decision by December 15.

The SIGCSE (Computer Science Education) Technical Symposium will be
held in conjunction with the CSC, February 23-24, 1990.  For further
information, contact Dr. Richard Austing: austing@tove.umd.edu

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 01:30:56 GMT
From:      farber@pcpond.UUCP (David J. Farber)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring Patent


Howard,

I just wanted to elaborate a  bit  on  the  early  days  of  ring
technology.  The Newhall/Farmer Ring developed at Bell Labs was a
central station  ring  where  the  control  station  generated  a
bipolar violation to act as a control token. When we realized (at
Irvine during the DCS Project) that rings were the thing, we  did
not  like either the control station or the hack of using bipolor
violations. We thus developed the notion of the fully distributed
ring control which has been the feature of all modern token rings
as well as the message format that is essentially  that  used  in
current   rings.   I   should  add  that  we  actually  used  the
"destination" address as a process name of processes that  should
receive  the message. That is why we decided to allow the message
to be removed by only the source ring  interface  (in  retrospect
that was a great idea for high speed ).

We did the original token ring for dcs at 2.7 megabits per second
and  the  received  a  contract from Darpa to design a modernized
version -- called the LNI. We did a prototype that almost  worked
(it  was  big!!) and then passed it on to MIT. MIT hired you guys
to continue the development and thus the Proteon token  ring  was
born.  (You  did  a  lot more that just finish the testing -- you
redesigned a lot of it -- wish you  had  left  the  process  name
structure in though).

Big credit is owed to proteon for keeping the faith  about  rings
before IBM "discovered the token ring".

Dave

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 03:52:41 GMT
From:      lyle@hpindda.HP.COM (Lyle Weiman)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/Soderblom answer

The response which the IEEE 802 committee got from these guys was
(this is my recollection and interpretation) that the original patent
rights had been sold to some sort of holding company, which obtains
revenues from the royalties.  They engaged the services of a lawyer,
by the way, who easily handled the collective umbrage of over a hundred
engineers (I think maybe the talent to do that goes with the territory,
or something).  In any case, over the years the stories that I have
heard was that this company would fight very hard in court to defend
this patent.   I didn't get the impression that the motivation was
at all altruistic.

(the opinions expressed above are solely mine)

--lyle

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 03:59:24 GMT
From:      gore@eecs.nwu.edu (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

>Root Boy Jim <rbj@DSYS.ICST.NBS.GOV> writes:
>
>	Simpler to just use one name, and use naked IP addresses on the
>	ifconfigs.

/ comp.protocols.tcp-ip / jordan@cs.columbia.edu (Jordan Hayes) / May 18 1989 /
>The DNS was created to make things easier.  Using IP addresses doesn't
>make things easier.  If you have two IP addresses on the same machine,
>name them uniquely and put the following data into your database:
>
>foo		IN	A	128.253.5.1
>		IN	A	128.253.6.1
>foo-gw		IN	A	128.253.6.1

For ifconfig's???

In order for this to work, the name server has to be running on THIS
machine, and you have to be able to launch it before you do the ifconfigs.
It seems that it's much easier to start up network programs after the
network interfaces are configured.

IP numbers may not "make things easier", but they are predictable.  I think
they are reasonable names for specific interfaces.

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,chinet,att}!nucsrl!gore

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 10:38:00 EST
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   DEC-VAX - ALL-IN-1 - MAILER
Andrews AFB

                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      19-May-1989 10:11am EST
                                        From:      Mr Rodney A McDaniel 
                                                   MCDANIEL 
                                        Dept:      HQ AFSC/SCXP
                                        Tel No:    981-7909/AV 858
                                        Owner:     Mr Rodney A McDaniel  *

TO:  _MAILER!                             ( _DDN[TCP-IP-RELAY@SRI-NIC.ARPA] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: DEC-VAX - ALL-IN-1 - MAILER



TO: TCP-IP@SRI-NIC.ARPA

*************ATTENTION DEC-VAX - ALL-IN-1 - EXPERTS******************

Problem:  Presently, I am a user on a DEC-VAX host computer 
connected to Milnet, which uses VMS 4.7., and ALL-IN-1, version 
2.2 for electronic message processing.  This works fine except 
for one "small problem" the MAILER function for ALL-IN-1, is not 
both "UPPER" and "lower" case sensitive when a user types in an 
E-mail address and the ALL-IN-1 converts the address for SMTP.
In the world of DDN and etc, host computers have mailbox user 
names that will only be accepted in either "UPPER" or "lower" 
case as described in Mil-Std 1781, 4.1.3 Mail Syntax.
Does anyone in this great big world have a solution for the 
ALL-IN-1, version 2.2 software, so a user can type a MAILER 
address in either "UPPER" or "lower" and the address is converted 
for SMTP exactly as typed????

Please send all replies direct to: MCDANIEL@HQAFSC-VAX.AF.MIL

Thanks,

Mr. McDaniel
HQ Air Force Systems Command
Andrews AFB Maryland
DSN 858-7909
COMM (301) 981-7909


------
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 14:13:00 PDT
From:      "Chris Taylor" <chris@CalState.EDU>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Addition to List
Please add my name to the TCP-IP list.
Thanks,
Chris Taylor
chris@calstate.edu

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 13:30:24 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring Patent

What goes around, comes around.

It was interesting to note that while the MIT-derived work on the ring
went from distribute processing, with process names, over to more
independent networking, with host names, the folks at Sytek, developing
NetBios for IBM, put process names back in.

Dave

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 15:38:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   DEC-VAX - ALL-IN-1 - MAILER

Andrews AFB

                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      19-May-1989 10:11am EST
                                        From:      Mr Rodney A McDaniel 
                                                   MCDANIEL 
                                        Dept:      HQ AFSC/SCXP
                                        Tel No:    981-7909/AV 858
                                        Owner:     Mr Rodney A McDaniel  *

TO:  _MAILER!                             ( _DDN[TCP-IP-RELAY@SRI-NIC.ARPA] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )


Subject: DEC-VAX - ALL-IN-1 - MAILER



TO: TCP-IP@SRI-NIC.ARPA

*************ATTENTION DEC-VAX - ALL-IN-1 - EXPERTS******************

Problem:  Presently, I am a user on a DEC-VAX host computer 
connected to Milnet, which uses VMS 4.7., and ALL-IN-1, version 
2.2 for electronic message processing.  This works fine except 
for one "small problem" the MAILER function for ALL-IN-1, is not 
both "UPPER" and "lower" case sensitive when a user types in an 
E-mail address and the ALL-IN-1 converts the address for SMTP.
In the world of DDN and etc, host computers have mailbox user 
names that will only be accepted in either "UPPER" or "lower" 
case as described in Mil-Std 1781, 4.1.3 Mail Syntax.
Does anyone in this great big world have a solution for the 
ALL-IN-1, version 2.2 software, so a user can type a MAILER 
address in either "UPPER" or "lower" and the address is converted 
for SMTP exactly as typed????

Please send all replies direct to: MCDANIEL@HQAFSC-VAX.AF.MIL

Thanks,

Mr. McDaniel
HQ Air Force Systems Command
Andrews AFB Maryland
DSN 858-7909
COMM (301) 981-7909


------

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 17:34:09 GMT
From:      prue@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  sendmail hanging during SMTP session

Doug,

Jim Guyton at Rand described this same problem to me.  He
and I did some poking around and found that somewhere between here 
(Southern Calif.) and decwrl.dec.com, someone is clobbering packets larger 
than somewhere in the 1000-->1100 byte range.  We can ping all day with 
packets less than 1000 and get good reliablility but 1100 or more 
fails consistently.

Walt Prue

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 17:40:43 GMT
From:      ldk@udev.cdc.com (ld kelley x-2046)
To:        comp.protocols.tcp-ip
Subject:   Does anyone know of a rarpd daemon thats PD?


Thanks,
larry


-------------------------------------------------------------------------------
Larry D. Kelley         |      Internet:  ldk@udev.cdc.com
Control Data Corporation|      uucp:      {uunet}!shamash!punjab!raistlin!ldk
4201 Lexington Ave No.  |      AT&T:	  01-612-482-2046

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 21:11:40 GMT
From:      pprindev@wellflt.UUCP (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   IP options...

I remember some discussion about a set of tools for network
diagnostics that included the ability to specify (in symbolic
form) sets of options from the command level.  VJ comes to
mind, as does the name "traceroute".  Can someone send me
some pointers on how to find this (where to ftp it from)?

Thanks,

-Philip

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 21:13:00 GMT
From:      chris@CALSTATE.EDU ("Chris Taylor")
To:        comp.protocols.tcp-ip
Subject:   Addition to List

Please add my name to the TCP-IP list.
Thanks,
Chris Taylor
chris@calstate.edu

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      19 May 89 23:24:25 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: error "No Buffer Space"

From article <8905170310.AA19561@SCUBED.COM>, by hutton@SCUBED.COM (Thomas Hutton):
> 
> In attempting to use a microvax running ultrix 2.X as a gateway into the 
> internet, I have recently been getting lots of "No buffer space available"
> messages.  At first I thought I was running out of mbuf's but this dosent
> seem to be the case.  Does anyone know what I can bump in this ultrix version
> to improve this case.  (It recently got worse once we started using LAT
> to this system)

Possibly (probably?) you are running out of buffers in your output queue
for one of your network interfaces.  This is the famous field
ifp->if_snd.ifq_maxlen, which defines how many packets may be on an
interface at a time.  You should look in if_de.c, or whatever interface
there is.  There is at least one variant of netstat (with the "-i" flag)
which shows the current (and maximum) queue length, as well as adb macros
(in /usr/lib/adb?) which will show that information.

Hope this helps.

Greg Minshall				Kinetics, a division of Excelan
...!ucbvax!unisoft!kinetics!minshall	1-415-947-0998

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 02:16:08 GMT
From:      melohn@ENG.SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
>/ comp.protocols.tcp-ip / rbj@DSYS.ICST.NBS.GOV (Root Boy Jim) / May 16, 1989 /
>They do force it if you are their customer.  Their setup scripts tipically
>give you three choices:
>	1. YP server
>	2. YP client
>	3. not networked at all

This is misleading; the installation procedure used in the current
versions of SunOS allow you to choose one of the following options for
YP: server, master, client, or none. Independent of this choice is the
configuration option for network interface.

>On most of their machines, you can do without YP, but it takes a lot of
>work to strip off all the stuff that refers to it, replace the libraries
>with BIND versions, etc.

Again, under current versions of the operating system, all that is
required is the replacement of the shared library with one linked with
the resolver routines. Such a library is available for FTP from
several Internet sources, and in tape form from the US answer center.

>The 386i cannot be used without YP at all.

The above does not refer to the sun386i.

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 02:39:07 GMT
From:      hs@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   Token Ring Patent


          Unfortunately, I know quite a bit about the Soderblom
          patent. It was first issued in the fall of 1981 after much
          consideration at the Patent Office. The senior patent in
          this area is Farmer and Newhall (AT&T). During the '70's,
          there were several interferences between the claims of
          Soderblom and those of Farmer and Newhall.  The Farmer and
          Newhall design, patented in 1971, was used by Dave Farber to
          help in the creation of the UC Irvine Ring (If I'm wrong,
          Dave, Please correct me). Then, Jerry Saltzer, Dave Clark,
          Ken Pogren and a bunch of people here at Proteon used the UC
          Irvine Ring to help in the creation of ProNET-10.

          Proteon never expected patent problems. In fact, in 1982, I
          presented details of our design at IEEE Headquarters in NYC
          to many AT&T employees including Bob Lucky. We joked about
          the fact that I was using BSTJ figures for my presentation,
          thus bringing new meaning to the phrase "not invented here".
          The Soderblom patent applied to systems which consisted of a
          master and a plurality of terminals. Farmer and Newhall was
          the senior patent when it came to closed loop operations.

          In 1983 or maybe 84, Soderblom presented at IEEE802.5. We
          were well aware of the Soderblom position. IEEE staff were
          also involved. We went ahead on the basis that Soderblom
          would provide licenses in a nondiscriminatory way. We also
          had a good idea of the probable terms for such a license.

          Since that time, the Patent Office has allowed a reissue of
          the Soderblom patent. The reissue has much more general
          claims. Many organizations filed objections which were
          brushed aside by the patent Office. That's why he has
          general coverage of a 1967 idea until 1998. His patents have
          run out elsewhere in the world. Don't blame Olaf.

          Many of us object to the whole procedure. That is, Was the
          token ring a new concept or an" old combination" in 1967?
          Many of us object to the details of the legal rangling.
          Nonetheless many of us have signed up simply because the
          patent office has spoken. In all cases, the exact terms of
          the license are covered by a non disclosure clause.

          It is also clear that some have chosen not to sign a
          license with Soberblom. It is expected that someone will
          take this to court for resolution.  Time will tell.

          Howard Salwen, Chairman-Founder
          Proteon, Inc.
          hs@relay.proteon.com

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 03:09:05 GMT
From:      dvaughan@WNYOSI7.ARPA (Dave Vaughan)
To:        comp.protocols.tcp-ip
Subject:   ANSI T1LB168


Has anyone heard of an ANSI standard T1LB168 titled "Principles of
Architecture and Protocols for Interfacing between Operating
Systems and Network Environments"?  If so, can you give me a brief
background.  Also is there a copy on-line somewhere?  Thanks.

					David Vaughan
					Dept. of Navy

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 03:09:45 GMT
From:      root@unix.sri.com  (Chris Barr)
To:        tcp-ip@sri-nic.arpa
Subject:   FDDI/Soderblum(?)
In article <2621@helios.ee.lbl.gov>, rlfink@ux3.lbl.gov (Robert Fink) writes:
> Though many folk assume the Soderblom patent pervails in all of these
> cases, it is still not clear.

As I understand it, this Swedish engineer patented the TOKEN RING.  Some
vendors (e.g. from '76 to (present?), Prime Computer) have been selling
token rings while fending off patent infringement lawsuits from 
Soderblum(sp?).  IBM pays royalties.
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 03:27:33 GMT
From:      netnews@ieeupdb.UUCP (Usenet News Administrator)
To:        comp.sources.wanted,comp.mail.sendmail,comp.os.vms,comp.sys.att,comp.protocols.tcp-ip
Subject:   Sendmail for sys 5 AT&T needed !


We are working to implement sendmail on an etherogeneus network which
includes UNIX AT&T System V ver. 3.0 , BSD 4.2 and a couple of VAX VMS
machines .
The net is based on TCP-IP services .
We encounter some difficulties tryng to compile the available sendmail
software ( ver 5.59 ) .
Can anybody advise us on a more recent version compatible vith AT&T
System V and DEC-VMS ?
Thanks 

We had posted this a while ago and we got only one answer , the one
that follow , I am sure there is something better around there .
( I hope to find a porting of IDA-Sendmail .... but I usually am not so 
lucky )

The place is ucsd.edu (128.54.16.1 ) , the file is pub/sendmail.cpio.Z
the way to reach it is by anonymous ftp . That porting is for an at&t
3b2 running sys v r3.1 and using a win/3b from the wollongong group .

Thanks a lot again !!!

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 03:34:00 GMT
From:      Armstrong.WBST128@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: What is Ethernet type code 8035 hex?


Ethernet type 8035 hex is officially registered to Stanford University,
with Dave Cheriton as the contact.

Note that it is (unfortunately) fairly common to have people building
Ethernet applications without registering their Ethernet type.  Such people
guessing at an unused type often clash with officially registered types.
Hence, these packets from your PC may have nothing to do with Stanford or
Cheriton.  Should this turn out to be true, and you discover the vendor
using 8035 hex, they should be strongly encouraged to obtain a registered
type.

Good luck!

Cheers,
    Susie

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 03:51:42 GMT
From:      randyd@microsoft.UUCP
To:        comp.protocols.tcp-ip
Subject:   Joining the Internet

I'm not sure where to ask this, but what is the procedure for obtaining
Internet connectivity?  Is the procedure ad-hoc?  Do you tie in through
a regional network? If so, which one? What sort of fees are charged?

Thanks for any pointers,
Randy Day
microsoft!randyd@uw-beaver.cs.washington.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 04:30:59 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Impact of BSD on the Internet



Dear Root Boy Jim:

I'm writing in response to your message to the tcp-ip list titled
"Impact of BSD on the Internet".

1.  There was indeed a thing called NCP around in the early days of the
    ARPANET.  NCP was the acronym for Network Control Protocol, and it
    was the official host-to-host protocol from 1970 through 1982 (the
    official cutover data from NCP to TCP was January 1, 1983).  NCP had
    nothing to do with BBN;  it was developed by a committee of network
    host organizations called the Network Working Group (NWG), the first
    chairman of which was Stephen Crocker of UCLA.  I believe the first
    mention of NCP in the public literature was a paper by Stephen Carr,
    Stephen Crocker, and Vinton Cerf at the 1970 Spring Joint Computer
    Conference titled "Host-Host Communication Protocol in the ARPA
    Network."

2.  The first TCP/IP implementation for UNIX was written by BBN with
    Defense Communications Agency (DCA) funding.  It was written for
    UNIX Version 6 by Michael Wingfield and was completed by March 15,
    1979 (see IEN 93*).  Another early TCP implementation for UNIX
    Version 6 was written by Digital Technology Incorporated at about
    the same time.

    BBN also wrote the first TCP for Berkeley UNIX, with DARPA funding.
    The project was led by Rob Gurwitz and is described in IEN 168
    (January 1981) as being "designed for the VAX, running VM/UNIX, the
    modified version of UNIX 32/V developed at the University of
    California, Berkeley." As might be expected in a TCP project carried
    out by BBN, performance was optimized for the characteristics of
    wide-area networks.  The folks who were both starting SUN
    Microsystems and also directing the development of Berkeley UNIX
    wanted a TCP implementation optimized for LANs, and were successful
    in having the BBN TCP implementation removed from BSD releases and
    replaced with their own implementation which was so optimized.

3.  TENEX was a paged, virtual memory, time sharing system for the DEC
    PDP-10 computer which was developed by BBN to support AI research.
    It used paging hardware designed and built by BBN.  The development
    was funded by ARPA and TENEX became operational in early 1969.  It
    is described in a paper by Bobrow, Burchfiel, Murphy, and Tomlinson
    in Communications of the ACM, Volume 15, Number 3 (March 1972).
    TENEX served as the basis for DEC's TOPS-20 operating system.

    DEC PDP-10s generally, and TENEX specifically, were by far the
    single most popular "server" computers during the first several
    years of the ARPANET.  (In those days ARPANET hosts were commonly
    characterized as "users" or "servers"; a server provided file
    storage and cycles, while a user system primarily provided access to
    the network.) For example, in December 1970, according to a quick
    count I just made, 10 of the 20 ARPANET servers were PDP-10s and in
    June 1975, 23 of 47 servers were PDP-10s.  Although I do not have a
    breakdown of operating systems in use on these PDP-10s, I believe
    that over 3/4 of the DEC-10s on the ARPANET at any time were running
    TENEX.  Other popular operating systems for the PDP-10 were DEC's
    10/50 system and MIT's Incompatible Timesharing System (ITS).

I hope this information is helpful.
Alex McKenzie

* IENs are available online from the ARPANET Network Information Center
  at SRI-NIC.ARPA
 

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 04:34:04 GMT
From:      root@unix.sri.com  (Aydin Edguer)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: What is Ethernet type code 8035 hex?
8035 is an RARP packet.
 > 2. What document or standard defines relation between values in this field 
 >    and higher level protocols?
The document you are looking for is RFC 1010 - Assigned Numbers.
In this document you will find a section ETHERNET NUMBERS OF INTEREST (pg 13).
This is just the list of the ethernet types assigned by XEROX at the time (May
1987).  There are other, unassigned types in use.
-- 
Aydin Edguer		+1 216 368 6123		edguer@alpha.ces.cwru.edu
Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      20 May 89 04:40:41 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: A pox on FTP clients!

In article <8905161441.AA27428@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>A pox on anyone who failed to implement continuation lines in their
>FTP clients!  And a warning on anyone who tries to use them in their
>FTP server -- don't!

	Yeah.  I agree with this, sort of.  Anyone who claims to have
implimented an ftp client but didn't include support for continuation lines
obviously didn't finish the job or didn't know what the h*ll he was doing.
As far as the server goes though, how would you propose to support the "HELP"
command without continuation lines??  Since that particular protocol command
depends on continuation lines in it's response, any ftp client that does not
support continuation lines either can't support the remote help function or
is flat out BROKE (I opt for the latter).  Any reasonable server should
support the "HELP" command, and as such must use continuation lines.
(BTW: I've done implimentations of both client and server).

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      21 May 1989 15:35-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Armstrong.WBST128@XEROX.COM
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: What is Ethernet type code 8035 hex?
> Ethernet type 8035 hex is officially registered to Stanford University,
> with Dave Cheriton as the contact.
>
> Note that it is (unfortunately) fairly common to have people building
> Ethernet applications without registering their Ethernet type.  Such people
> guessing at an unused type often clash with officially registered types.
> Hence, these packets from your PC may have nothing to do with Stanford or
> Cheriton.  Should this turn out to be true, and you discover the vendor
> using 8035 hex, they should be strongly encouraged to obtain a registered
> type.

The Reverse Address Resolution Protocol (RARP) was developed at Stanford,
using Stanford's Ethertype 8035.  That Ethertype is now the standard for
RARP, wherever it is used.  It is not surprising that a PC would be
issuing RARP packets.  If it turned out to be using 8035 for some other
purpose, that would indeed be a no-no.

Steve Deering
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      21 May 89 16:25:28 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: FDDI/Soderblum(?)

Yes, Xerox owns the Ethernet patent.  Two of their scientists, Dave Boggs
and Bob Metcalfe, did the original work and, as with all employers,
assigned the patent rights to the company.  Xerox chose to license
the Ethernet technology to any party for $1,000.00 as a onetime fee.
Make as many copies as you like.  That's pretty "reasonable and nondiscrimin-
atory" I would say.
Dan
-------

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      21 May 89 19:35:00 GMT
From:      MOSS@cs.umass.EDU ("Eliot Moss, GRC A351B, x5-4206  21-May-1989 1431")
To:        comp.protocols.tcp-ip
Subject:   Early token rings

Just a little bit of history that may interest a few folks ...

Back in 1973 or so a PhD student named Dan Jackson at MIT developed a 7 Mbit
(originally designed to be 10 Mbit, but some of the components available
were not quite fast enough) ring net, having seen Farber's work. This was
done in the EECS department's Digital Systems Lab under the supervision of
Prof. Hoo-Min Toong. By sometime in 1975 the net was working reliably in the
lab over twisted pair, sending data between homebrew Intel 8080 systems.

This ring featured distributed control. Any node could become the "Ring
Master", delivering timing from its quartz clock and handling any drift of
the phase of the signal as it returned to the master. The current
transmitter was termed the "Ring Lord" (I guess Dan like Tolkien). My
connection was that I worked hourly supervising construction (wire wrap) and
testing of the boards. My wife helped draw many of the schematics. My
recollection is that this effort significantly predated the ring over in the
Lab for Computer Science, which evolved into the Proteon product. Last I
recall, Dan was working for Tektronix in Oregon.

Does anyone out there recall any more of this effort? Was it ever published?
(Remember, I was just an hourlyundergraduet employee...)

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

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      21 May 89 23:14:04 GMT
From:      "Juan_Navarro.XOSMAR"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: sendmail hanging during SMTP session

Doug-
	When I was connecting our (XEROX's) TCP/IP gateway to Sun OS3.x (.2 or .5)
we were having the same problem. We fixed it by adding a E=\r\n at the end
of the Mtcp or Mether line in the sendmail.cf file.   I forget where this
is documented, but it works. You then need to kill and restart your
sendmail daemon.   Example:

	Mtcp, P=[IPC], F=mDFMueXL, S=14, R=14, A=IPC $h, E=\r\n
					or
	Mether, P=[IPC], F=mDFMueXL, S=11, R=21, A=IPC $h, E=\r\n

Good Luck.

//juan

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 04:31:09 GMT
From:      casey@lll-crg.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   PROBLEM(Sun PC NFS 3.0; broadcast pings; DEC LanBridge 100s) + FIX


  I know that the subject of broadcast pings (ICMP_ECHO packets sent to
the broadcast address) is controversial: whether to respond or not to
respond?  Nevertheless, it's at least known what the general form of an
ICMP_ECHOREPLY packet should be if one is sent.  Sun's PC NFS 3.0 now
implements ICMP and responds to broadcast pings, but does so with an
illegal [I think] ethernet packet.

  In the process of creating the reply packet, PC NFS 3.0 simply swaps
the source and destination ethernet and IP addresses.  Apparently it
never occurred to the engineers that their code might find itself
responding to an ICMP packet that wasn't explicitly directed at
themselves.  The reply packet to a broadcast ping has a source ethernet
address of ff:ff:ff:ff:ff:ff and a source IP address of the local IP
broadcast address.  [I.e. the packet has absolutely no identifying marks
on it whatsoever.  You can't tell where it came from.  We had to resort
to binary search, physically partitioning one of our ethernets ...]

	[As far as I'm aware, an ethernet packet with a source address
	equal to the ethernet broadcast address is illegal.  (I think
	that's true about any multicast address, but I'll wait for
	someone to respond to Dave Wiltzius message on that issue.)]

  These packets cause DEC LanBridge 100s with revision 2.0 PROMs to
``learn the broadcast address'' which eventually partitions your network
as ARPs start failing, etc.  As far as I know these packets don't cause
any other problems.

  A fix is available from Sun for this problem.  Sun worked with us to
come up with the fix and has been very helpful.  The fix will be released
as part of a general upgrade called PC NFS 3.0.1 (or was it 3.1?)
sometime in the June/July time frame (from what I've been told).  If you
can't wait for that, you should contact Sun and ask about the 3.0.0.8
BETA version.  The bug fix for this particular problem is associated with
problem number 289928.

Casey

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 16:33:00 EDT
From:      "13513::DBURKE" <dburke%13513.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Hitchhikers guide to Internet
Date sent:  22-MAY-1989 16:30:12 

Can anyone tell me where to find the above paper? (anonymous FTP)

Thanks!
Dave

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

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 May 1989 18:03-EDT
From:      CERF@A.ISI.EDU
To:        root@UNIX.SRI.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Impact of BSD on the Internet
Dear Root Boy Jim:

Alex McKenzie has done his usual thorough job of describing some
of the early history of the ARPANET. My recollection is that the
BSD work was specifically supported by Duane Adams, then a member
of the staff at DARPA's Information Processing Techniques Office.
His interests were less networking than operating system development,
though having such systems work in a networked environment was
high on the priority list.

The BSD implementation for UNIX, coupled with its easy availability
and the proliferation of UNIX-supporting hardware as well as LANs,
sparked the rapid growth of the Internet Protocols. Initially, Digital
VAX equipment dominated the Internet - the PDP-10's had largely
been supplanted by the KL-20's and the Tenex operating system 
replaced by TOPS-20, which incorporated a lot of what BBN had
done with Tenex and the Internet protocols. [You might say that
the network vaxed prolific in those days - late 1970's early
1980's]. 

Since then, new UNIX engines have emerged (e.g. SUN, PC versions
on the 386 series machines, supercomputer versions) which adopted
the Internet protocols because they are both widely available and 
used.

Vint Cerf

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 14:13:25 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Joining the Internet

In article <8905171944.AA22934@beaver.cs.washington.edu> 
randyd@microsoft.UUCP writes:
>I'm not sure where to ask this, but what is the procedure for obtaining
>Internet connectivity?  Is the procedure ad-hoc?  Do you tie in through
>a regional network? If so, which one? What sort of fees are charged?

	The arpanet is dead.  The application specific networks are
looking to connect to the NSF sponsored Internet.  (The ad hoc
voluntary networks like uucp and fidonet are alive and kicking
independently and doing just fine.)  Then there is BITnet and CSnet.

	Given that, I would think that folks like you would look to
your local NSF-sponsored-regional network.  In Wash state, I believe
that is Northwestnet.  Following is an article I posted to info-nets a
while back, telling how to find out which regional is your regional.
Of course, you can join any regional you like, it's just that line
charges are a killer.  :-)

	What do you pay?  That depends on how far your regional has
gotten toward self-sufficiency.  :-)  It will be a mix of dues,
service fees tied to bandwidth (approx), and line charges (the killer
cost).  All regionals are trying to grapple with the complex issues of
cost recovery, so you have to ask for a quote, consider options, and
be prepared for costs to go up or down in future.

------------------------
To: info-nets@think.com
Subject: NSF database update

	Someone asked for how to join the Internet a while back.  I
said something about a site.contacts file.  Now there is something
better. 
	From the latest link letter, a description of new services
from the NSF database of backbone and regionals:
---------------------------------------------------------------------

 Vol. 2   No. 1                                         15 April 1989
 
                       T H E  L I N K  L E T T E R 
 
                    The Merit/NSFNET Backbone Project
 
 
           UPDATES TO THE NSFNET-IS REMOTE QUERY DATABASE
 
 The 19 December 1988 issue of the Link Letter provided
 information on the NSFNET Information Services remote query
 database. Recently, NSFNET Information Systems has put in place
 several enhancements to that system. The CONTACTS command has
 been expanded and the TOPOLOGY command has been added.
 
 An overview of the changes is given below; those who wish to
 obtain the complete documentation by remote query may do so by
 sending electronic mail to either:
 
    nis-info@nis.nsf.net (Internet/NSFNET)  or
    nis-info@merit (the Bitnet address).
 
 The subject field of the message is ignored and the text of the
 message text should contain only the word HELP. The server will
 return information on all the commands currently available.
 
 The Contacts Command
 
 The CONTACTS command retrieves information on administrative,
 technical, or user contacts for a given site. The syntax for the
 first line of the message to the server is given below. Note
 that options which appear in angle brackets (< >) must be
 supplied. 
      CONTACTS <nettype> <netname/number> 
 
 Where the five options for nettype are:
 AS (autonomous system number) 
 IP (IP address of a connected net)
 NET (name or location of a connected net)
 NSS (a Nodal Switching Subsystem number or name)
 
 Multiple AS, IP, NET, or NSS nettypes (or a combination of any
 of these) can be included in a single search. For example:
     contacts net utah or xerox
 will return contact information for any nets with the name or
 location of either "utah" or "xerox." Note that commands are not
 case sensitive.
 
 The Topology Command
 
 The TOPOLOGY command has been added to the server to supply
 network topology information. The syntax of this command is:
 
      TOPOLOGY <nettype>-<format> <value>
 
 Valid choices for nettype and the value expected are: 
 AS = an AS
 GATE = a gate IP 
 NSS = an NSS number 
 NET = a net IP 
 
 Valid format choices and their output are:
 " " (NULL) = full configuration information
 AS = GATE and NSS information 
 COMP = NET and AS numbers in a computer-readable format.
 GATE = AS and NET information.
 NET = NET name, location and AS information for each net.
 
 Requests for further information about these upgrades may be
 sent to userhelp@nis.nsf.net (Internet/NSFNET) or
 userhelp@merit (Bitnet).
 
------------------------------------------------------------------ 

Here is what I got from a request for "contacts net nysernet":

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

>From NIS-INFO@NIS.NSF.NET Wed May 10 10:12:10 1989
Return-Path: <NIS-INFO@NIS.NSF.NET>
Received: from nis.nsf.net by bu-it.BU.EDU (5.58/4.7)
	id AA23659; Wed, 10 May 89 10:12:08 EDT
Message-Id: <8905101412.AA23659@bu-it.BU.EDU>
Received: from MERIT.BITNET by NIS.NSF.NET ; Wed, 10 May 89 10:17:45 EDT
Received: by MERIT (Mailer X1.25) id 0076; Wed, 10 May 89 10:17:44 EDT
Date:     Wed, 10 May  89 10:17:44 EDT
From: Remote SPIRES <NIS-INFO@MERIT>
To: KWE@bu-it.bu.edu
Subject:  contacts net nysernet
Status: R

Result:   Result 2 Records
Database: TOPOLOGY - Merit-NSFNET Information Server




NSS CONTACT INFORMATION - NSS #10 -- CNSF/NYSERNet

Administrative Contact(s):
  Callinan, Craig          607/255-5060            craig@devvax.tn.cornell.edu
    Cornell Theory Center
    265 Olin Hall, Ithaca, NY   14853
  Brim, Scott          607/255-8686                 swb@tcgould.tn.cornell.edu
    Cornell Theory Center
    26 Olin Hall, Ithaca, NY   14853
  Schrader, William L.          212/395-4480
    NYSERNet, Inc.
    1094 Avenue of the Americas, New York, NY   10036
  Mandelbaum, Richard          716/275-2917               rma@cs.rochester.edu
    University of Rochester
    Administration Bldg., Rochester, NY   14627

Technical Contact(s):
  Honig, Jeffrey C          607/255-8686            jch@tcgould.tn.cornell.edu
    Cornell Theory Center
    265 Olin Hall, Ithaca, NY   14853-5201
  Schoffstall, Martin L.          518/283-8860           schoff@nisc.nyser.net
    NYSERNet NISC
    Rensselaer Technology Park, Troy, NY   12180
  Fedor, Mark          518/283-8860                       fedor@nisc.nyser.net
    NYSERNet NISC
    Rensselaer Technology Park, Troy, NY   12180


MIDLEVEL CONTACT INFORMATION - 128.145 -- NYSERNET
    NYSERNET Network Information Center

Technical Contact(s):
  Schoffstall, Martin Lee          518/276-2654
    NYSERNET Network Information Center, Troy, NY   12810


MIDLEVEL CONTACT INFORMATION - 130.117 -- NYSER2
    NYSERNET Inc., Rensselaer Technology Park, Troy, New York

Technical Contact(s):
  Schoffstall, Martin Lee          518/276-2654
    NYSERNET Inc., Troy, NY   12180

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

	I think you people ought to find this service useful.  It's
mail based, so it should work for all of you.

	Enjoy.  :-)

	Kent England, Boston U

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 14:33:18 GMT
From:      bownesrm@beowulf.UUCP (Mr Mojo Risen')
To:        comp.protocols.tcp-ip
Subject:   Slip for SunOS 3.5


	Cany anyone tell me anything about bringing up SLIP on 3.5?
	I can't seem to find any pointers in what meager documentation I have.

	Much thanks,
			bob
-- 
"Reading legal mush can turn your brain to guacamole"
Bob Bownes, aka iii, aka captain comrade doktor bobwrench
3 A Pinehurst Ave,	Albany, New York, 12203, (518)-482-8798 voice 
bownesrm@beowulf.uucp {uunet!crdgw1,rutgers!brspyr1}!beowulf!bownesrm

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 15:40:30 GMT
From:      doug@csd4.milw.wisc.edu (Doug Tiarks)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   sendmail hanging followup



I've gotten a number of replies on my sendmail posting. Thanks to all
who responded. From what I've gathered it appears that the problem is
not with sendmail itself, but is a manifestation of a problem on
part of the Internet.   There is a gateway which is clobering packets
greater than about 1k. This would cause sendmail to hang when
attempting to deliver messages > 1k because the packets with the message
couldn't get through. I'm not sure which hosts this affects, but the
problem is being worked on. 

On a related note phil@ux1.cso.uiuc.edu  mentions:
>I have been seeing this happen occaisionally on several hosts receiving mail
>>from IBM VM SMTP.  Some cases have been verified as having well over 100
>destination addresses, one per line, in the RFC822 To: field.  Attempts to
>send the same mail to other hosts running sendmail 5.61 also resulted in
>sendmail getting hung.  Another version of sendmail delivered the mail, but
>inserted a blank line after the 100 or so To: addresses it was parsing.

There is a problem in sendmail v5.61 that causes it to hang on
large headers (such as a large To: field). The problem and a fix were
posted on comp.bugs.4bsd. If anyone is interested in it let me know.



	Doug Tiarks
	UW-Milwaukee Computing Services Div.

	Internet: doug@csd4.milw.wisc.edu
	UUCP: {uwvax, uwmacc}!uwmcsd1!doug


--

	Doug Tiarks
	UW-Milwaukee Computing Services Div.

	Internet: doug@csd4.milw.wisc.edu
	UUCP: {uwvax, uwmacc}!uwmcsd1!doug

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 20:32:14 GMT
From:      narten@CS.PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: sendmail hanging followup

> There is a gateway which is clobering packets greater than about 1k.
> This would cause sendmail to hang when attempting to deliver messages
> > 1k because the packets with the message couldn't get through. I'm
> not sure which hosts this affects, but the problem is being worked on.

Without suggesting that this unnamed gateway exhibits reasonable
behavior, let me point out that any TCP implementation that blindly
sends out packets larger than 576 bytes in size is asking for trouble
because no host or gateway is required to be able to *accept*
datagrams larger than 576 bytes in size.  The TCP layer should divide
data generated by the application into reasonably-sized TCP segments.
(Thus, large sendmail writes aren't your problem.)  Current wisdom
suggests that 576 bytes is an upper limit on the size of IP datagrams
that a host should send in the absense of explicit information that
larger packets won't cause problems.  (See Mogul and Kent's 1987
SIGCOMM paper "Fragmentation Considered Harmful" for more details on
the evils of large packets.)

So, if your sending TCP is generating 1000 byte packets to send across
the Internet, your TCP/IP implementation needs work.

Thomas Narten

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 20:33:00 GMT
From:      dburke%13513.decnet@NUSC-NPT.NAVY.MIL ("13513::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Hitchhikers guide to Internet

Date sent:  22-MAY-1989 16:30:12 

Can anyone tell me where to find the above paper? (anonymous FTP)

Thanks!
Dave

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

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 20:52:39 GMT
From:      mason@dsg.Stanford.EDU (Tony Mason)
To:        comp.protocols.tcp-ip
Subject:   VMTP (RFC 1045) Release announcement


The second release of the UNIX VMTP implementation (corresponding to RFC-1045)
is now available for the Sun-3, Sun-4, Vax, and DECstation 3100 via anonymous
FTP from gregorio.stanford.edu.

There is a vmtp.README file in the directory vmtp-ip on Gregorio which
describes the full distribution (it is distributed with individual pieces
containing the architecture specific sections.)

For those unfamiliar with VMTP here is a brief description of its salient
features:

    - VMTP is a transport level protocol.  This implementation uses the
      Berkeley socket abstraction in 4.3 and 4.3 derived systems.

    - VMTP is a reliable transport protocol providing support for
      "transactions"  rather than UDP's datagrams and TCP's connected
      streams.   It is designed to optimize performance of modern RPC style
      protocols, a service not well filled by either TCP or UDP.

    - VMTP provides real-time capabilities (elimination of checksumming on
      data or on the entire packet,) idempotent responses (e.g. responses
      from a time server,) and high-throughput rates requiring minimal 
      packet exchanges. 

Additional information about VMTP is available in RFC-1045, as well as via
the vmtp-ip mailing list (vmtp-ip@gregorio.stanford.edu.  Add/drop requests
to vmtp-ip-request@gregorio.stanford.edu.)

Tony Mason
Distributed Systems Group
Stanford University
mason@pescadero.stanford.edu

May 22, 1989

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 21:12:45 GMT
From:      PROOME@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for ATT 3B systems


We are looking for some information regarding ATTs policy on TCI/IP distribution
to universities and other educational institutes. Specifically, we want
to purchase TCP/IP for our ATT 3B systems. We feel that we are getting the
short end of the  ATT pricing stick, thus, we would like to know if there is an
alternative source to a version of TCP/IP for the ATT 3B system. In addition,
we would also like to know if anyone else has bought TCP/IP for the 3B from 
ATT and, if so, what was the price discount you received. 

Any information would be of considerable help.

Thanks, (please reply directly)


Peter Roome  ! Programming Manager      ! CCnet:    SITVXC::PROOME
             ! Stevens Inst. of  Tech.  ! BITnet:   PROOME@SITVXC
             ! Hoboken, NJ 07030        ! INTERnet: PROOME@VAXC.STEVENS-TECH.EDU
------------

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      22 May 89 22:03:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Impact of BSD on the Internet

Dear Root Boy Jim:

Alex McKenzie has done his usual thorough job of describing some
of the early history of the ARPANET. My recollection is that the
BSD work was specifically supported by Duane Adams, then a member
of the staff at DARPA's Information Processing Techniques Office.
His interests were less networking than operating system development,
though having such systems work in a networked environment was
high on the priority list.

The BSD implementation for UNIX, coupled with its easy availability
and the proliferation of UNIX-supporting hardware as well as LANs,
sparked the rapid growth of the Internet Protocols. Initially, Digital
VAX equipment dominated the Internet - the PDP-10's had largely
been supplanted by the KL-20's and the Tenex operating system 
replaced by TOPS-20, which incorporated a lot of what BBN had
done with Tenex and the Internet protocols. [You might say that
the network vaxed prolific in those days - late 1970's early
1980's]. 

Since then, new UNIX engines have emerged (e.g. SUN, PC versions
on the 386 series machines, supercomputer versions) which adopted
the Internet protocols because they are both widely available and 
used.

Vint Cerf

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 May 89 07:57:06 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        rws@expo.lcs.mit.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  SO_KEEPALIVE considered harmful?
The use of Keepalives is terrible, but sometimes necessary.  The key
word, here, is "sometimes".

The "terrible" is due to the fact that they add traffic to the net.  An
important point to keep in mind, with TCP connections, is that they may
span the globe, over thin wires.  Extra traffic can have a very serious
effect.  Further, they scale poorly.  The incremental traffic from one
connection may not be onerous, but what about 1000 connections?  Lastly,
of course, there is the small fact that there may be a charge for those
extra packets, such as may happen if one of the links along the path
is over a public X.25 network.

If the group proposing the use of Keepalives has already gone through the
exercise of convincing themselves that critical functionality will be
lost if they are not used, then I hope the next question was/is how
to minimize their use.

Dave
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 May 89 12:41:15 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        rws@expo.lcs.mit.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: SO_KEEPALIVE considered harmful?

> I have a random question that I hope this illustrious audience can answer
> definitively for me (or else point me to a definitive source).  Is the BSD
> notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to
> the TCP specification?  If so, is its use to be encouraged?  Specifically,
> it has been suggested that in the X Window System world, X libraries
> should automatically be setting SO_KEEPALIVE on connections to X servers.  Is this
> a reasonable thing to do?

Oh what fun!  Keepalive wars return....

Well, I'm a firm hater of keep-alives, although Mike Karels has persuaded
me that in the current world they are a useful tool for catching clients
that go off into hyperspace without telling you.  I have lots of fellow
travellers (actually, I'm probably a fellow traveller with Phil Karn,
president of the "I hate keep-alives" party), witness the current host
requirements text, which is appended.

Craig

	Implementors MAY include "keep-alives" in their TCP           |
	implementations, although this practice is not universally    |
	accepted.  If keep-alives are included, the application MUST  |
	be able to turn them on or off for each TCP connection, and   |
	they MUST default to off.                                     |

	Keep-alive packets MUST NOT be sent when any data or          |
	acknowledgement packets have been received for the            |
	connection within a configurable interval; this interval      |
	MUST default to no less than two hours.                       |

	An implementation SHOULD send a keep-alive segment with no    |
	data; however, it MAY be configurable to send a keep-alive    |
	segment containing one garbage octet, for compatibililty      |
	with erroneous TCP implementations.                           |


	DISCUSSION:                                                   |
	     A "keep-alive" mechanism would periodically probe the    |
	     other end of a connection when the connection was        |
	     otherwise idle, even when there was no data to be sent.  |
	     The TCP specification does not include a keep-alive      |
	     mechanism because it could:  (1) cause perfectly good    |
	     connections to break during transient Internet           |
	     failures; (2) consume unnecessary bandwidth ("if no one  |
	     is using the connection, who cares if it is still        |
	     good?"); and (3) cost money for an Internet path that    |
	     charges for packets.                                     |

	     Some TCP implementations, however, have included a       |
	     keep-alive mechanism. To confirm that an idle            |
	     connection is still active, these implementations send   |
	     a probe segment designed to elicit a response from the   |
	     peer TCP.  Such a segment generally contains SEG.SEQ =   |
	     SND.NXT-1.  The segment may or may not contain one       |
	     garbage octet of data.  Note that on a quiet             |
	     connection, SND.NXT = RCV.NXT and SEG.SEQ will be        |
	     outside the window.  Therefore, the probe causes the     |
	     receiver to return an acknowledgment segment,            |
	     confirming that the connection is still live.  If the    |
	     peer has dropped the connection due to a network         |
	     partition or a crash, it will respond with a reset       |
	     instead of an acknowledgement.                           |

	     Unfortunately, some misbehaved TCP implementations fail  |
	     to respond to a segment with SEG.SEQ = SND.NXT-1 unless  |
	     the segment contains data.  Alternatively, an            |
	     implementation could determine whether a peer responded  |
	     correctly to keep-alive packets with no garbage data     |
	     octet.                                                   |

	     A TCP keep-alive mechanism should only be invoked in     |
	     network servers that might otherwise hang indefinitely   |
	     and consume resources unnecessarily if a client crashes  |
	     or aborts a connection during a network partition.       |

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 May 89 14:03:13 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        prisma!mo@uunet.uu.net, uunet!ahwahnee.Stanford.EDU!dcrocker@uunet.uu.net
Cc:        mo@uunet.uu.net, rws@expo.lcs.mit.edu, tcp-ip@sri-nic.arpa
Subject:   Re: SO_KEEPALIVE considered harmful?
I tried to avoid saying that keepalives should be prohibited, except,
perhaps, from an aesthetic point of view.  Since aesthetics often are
altered by reality, it is no great concession to acknowledge the 
occasional need for the mechanism.

My point was that they are dangerous and therefore should be used VERY
judiciously.  Craig's note puts this point forward in more detail.

It is worth adding that the excessive use of keepalives has removed a
feature that used to be in TCP and has been recently re-documented by
Bob Braden:  TCP used to be remarkably robust against temporary
outages.  If you were willing to wait, so was TCP.  Now, an outage of
a very short time -- on some implementations, as short as 1-2 minutes --
will abort the connection.

Dave
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 12:04:55 GMT
From:      rws@EXPO.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE considered harmful?

I have a random question that I hope this illustrious audience can answer
definitively for me (or else point me to a definitive source).  Is the BSD
notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to
the TCP specification?  If so, is its use to be encouraged?  Specifically,
it has been suggested that in the X Window System world, X libraries
should automatically be setting SO_KEEPALIVE on connections to X servers.  Is this
a reasonable thing to do?

[If this is a totally inappropriate forum for this question, I apologize.]

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 12:47:11 GMT
From:      stephan@kulcs.uucp (Stephan Biesbroeck)
To:        comp.protocols.tcp-ip
Subject:   Dividing Class B number in subnets, Routing Problem


We are planning to build a university-wide (=city-wide) network. 
We have an official class B IP-number.
I'd like to divide the IP-number in subnet numbers with a certain
flexibility e.g. giving a great department a subnet number of 21 bits
(= 11 bits left for further subnetting or for their hosts) and giving
a smaller department a subnet number of 25 bits (=7 bits left for further
subnetting or for hosts).
The division should also be hierarchical : all the subnets connected 
to the same router at the backbone have subnet numbers that start with
the same bits.

MY PROBLEM IS THE ROUTING. 
In Comer's book "Internetworking with TCP/IP", there is a paragraph
about routing with subnets (16.10 p.202) : about the routing table :
"each entry contains one additional field that specifies the subnet mask
used with the network in that entry:
     (subnet mask, network addreess, next gateway)

!!BUT, in a lot of implementations (UNIX BSD 4.3, SunOS, ...), there is
no place for a subnetmask for each entry in the routing table. 
The subnet mask is only specified for the interface. But it is possible
that my interface has a subnet mask of 25 bits, and I want to direct
to a subnet with a subnet mask of 21 bits.
How can I solve this ?

I hope my problem is clear (it's hard to explain in a few words).
Anyone who can give some help ?? Also other tips about dividing
a class B address in subnet numbers are welcome.

----------------------------------------------------------------------------
Stephan Biesbroeck                        Katholieke Universiteit Leuven
Tel : +32/16/20.06.56(x3602)              Dept. of Computer Science
telex : 23674 KULEUV B                    Celestijnenlaan 200A
fax : +32/16/20.53.08                     B - 3030 Leuven
email : stephan@cs.kuleuven.ac.be         Belgium
        stephan@blekul60.BITNET
        stephan@kulcs.UUCP
----------------------------------------------------------------------------

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 13:38:40 GMT
From:      nrm1838@dsacg1.UUCP (James D. Cassell)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Printing with PC-NFS

We are using a TCP-IP package from SUN, PC-NFS, to allow our pcs to access
our UNIX BSD minicomputers.  We are having a problem directing print back
to the pc's slave printer.  Seems like no matter what we do the print is
sent to the screen; anybody have any ideas?
-- 
Jim Cassell              {uunet!gould,cbosgd!osu-cis}!dsacg1!jcassell 
Defense Logistics Agency Systems Automation Center | 614-238-9971
DSAC-RMA, P.O. Box 1605, Columbus, OH 43216        | Autovon 850-
All views expressed are mine, I think

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 14:57:06 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  SO_KEEPALIVE considered harmful?

The use of Keepalives is terrible, but sometimes necessary.  The key
word, here, is "sometimes".

The "terrible" is due to the fact that they add traffic to the net.  An
important point to keep in mind, with TCP connections, is that they may
span the globe, over thin wires.  Extra traffic can have a very serious
effect.  Further, they scale poorly.  The incremental traffic from one
connection may not be onerous, but what about 1000 connections?  Lastly,
of course, there is the small fact that there may be a charge for those
extra packets, such as may happen if one of the links along the path
is over a public X.25 network.

If the group proposing the use of Keepalives has already gone through the
exercise of convincing themselves that critical functionality will be
lost if they are not used, then I hope the next question was/is how
to minimize their use.

Dave

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 16:41:15 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: SO_KEEPALIVE considered harmful?


> I have a random question that I hope this illustrious audience can answer
> definitively for me (or else point me to a definitive source).  Is the BSD
> notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to
> the TCP specification?  If so, is its use to be encouraged?  Specifically,
> it has been suggested that in the X Window System world, X libraries
> should automatically be setting SO_KEEPALIVE on connections to X servers.  Is this
> a reasonable thing to do?

Oh what fun!  Keepalive wars return....

Well, I'm a firm hater of keep-alives, although Mike Karels has persuaded
me that in the current world they are a useful tool for catching clients
that go off into hyperspace without telling you.  I have lots of fellow
travellers (actually, I'm probably a fellow traveller with Phil Karn,
president of the "I hate keep-alives" party), witness the current host
requirements text, which is appended.

Craig

	Implementors MAY include "keep-alives" in their TCP           |
	implementations, although this practice is not universally    |
	accepted.  If keep-alives are included, the application MUST  |
	be able to turn them on or off for each TCP connection, and   |
	they MUST default to off.                                     |

	Keep-alive packets MUST NOT be sent when any data or          |
	acknowledgement packets have been received for the            |
	connection within a configurable interval; this interval      |
	MUST default to no less than two hours.                       |

	An implementation SHOULD send a keep-alive segment with no    |
	data; however, it MAY be configurable to send a keep-alive    |
	segment containing one garbage octet, for compatibililty      |
	with erroneous TCP implementations.                           |


	DISCUSSION:                                                   |
	     A "keep-alive" mechanism would periodically probe the    |
	     other end of a connection when the connection was        |
	     otherwise idle, even when there was no data to be sent.  |
	     The TCP specification does not include a keep-alive      |
	     mechanism because it could:  (1) cause perfectly good    |
	     connections to break during transient Internet           |
	     failures; (2) consume unnecessary bandwidth ("if no one  |
	     is using the connection, who cares if it is still        |
	     good?"); and (3) cost money for an Internet path that    |
	     charges for packets.                                     |

	     Some TCP implementations, however, have included a       |
	     keep-alive mechanism. To confirm that an idle            |
	     connection is still active, these implementations send   |
	     a probe segment designed to elicit a response from the   |
	     peer TCP.  Such a segment generally contains SEG.SEQ =   |
	     SND.NXT-1.  The segment may or may not contain one       |
	     garbage octet of data.  Note that on a quiet             |
	     connection, SND.NXT = RCV.NXT and SEG.SEQ will be        |
	     outside the window.  Therefore, the probe causes the     |
	     receiver to return an acknowledgment segment,            |
	     confirming that the connection is still live.  If the    |
	     peer has dropped the connection due to a network         |
	     partition or a crash, it will respond with a reset       |
	     instead of an acknowledgement.                           |

	     Unfortunately, some misbehaved TCP implementations fail  |
	     to respond to a segment with SEG.SEQ = SND.NXT-1 unless  |
	     the segment contains data.  Alternatively, an            |
	     implementation could determine whether a peer responded  |
	     correctly to keep-alive packets with no garbage data     |
	     octet.                                                   |

	     A TCP keep-alive mechanism should only be invoked in     |
	     network servers that might otherwise hang indefinitely   |
	     and consume resources unnecessarily if a client crashes  |
	     or aborts a connection during a network partition.       |

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 16:59:51 GMT
From:      pritch@cheops.cis.ohio-state.edu (Norm Pritchett)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Centralized mail systems summary (LONG)

A few weeks ago I posted a query to find out what people are doing
with centralized mail systems.  I promised to followup with a summary
of the responses and to let you know what we were going to do at Ohio
State.  The latter will be in my next posting.  Below are a summary of
responses.  I will mention a contact name for each of the mail systems
listed below but it might not be a person involved with that project -
merely a user who described the mail system to me.

1) Sun Microsystems.  Of the ones described to me this appears to be
the most well known -- I received messages from 5 people plus Sun
about it.  Contact: Bill Melohn <melohn@eng.sun.com>.

	At Sun we have managed to do this for our some 10,000
	employees. We currently use a two-tier method of resolving
	names from a unix user name (like "melohn") to <first initial
	of first name><lastname> (ie "bmelohn") syntax. This alias in
	turns points to the username@mailboxhost for the user. When
	conflicts occur in the scheme, we make the alias a pipe to a
	shell script called ambigmail, which sends mail back to the
	sender with the various GCOS field entries that match the
	ambig alias.

	We are in the process of enhancing this scheme by making the
	second alias from above reference a username@Area, which would
	allow us to distribute the alias expansion to a series of
	mailhosts for each area.

	For mail destined for the Internet, we rewrite outgoing mail
	headers to be user@Sun.COM; eventually this function will be
	done on an area basis, with outgoing mail messages that look
	like user@Area.Sun.COM (as mine does today).

2) UC Davis.  Contact: jcgargano@ucdavis.edu (Joan Gargano).

	I am in charge of our mailname system at U.C. Davis.  We have
	about 20,000 faculty and staff, and 20,000 students.  I
	maintain a database of over 20,000 mailnames, first initial,
	middle initial, last name, for faculty and staff which I
	constructed from the payroll files.  We have had a number of
	collisions which I have resolved by altering the middle
	initial of one of the names.  Stanford uses a similar system.

	You may query our database by using whois:

	There is a directory that is accessible via the whois program.
	We have added to the whois program to search our local
	database through the program or through electronic mail.

3) Purdue University.  Contact Dave Stevens (dls@alecto.cc.purdue.edu) .

	We've just started work on what we call campus-wide electronic
	mail.  We intend to use name server MR records and Profile for
	the white pages service.  We're thinking about using NeXT work
	stations in a distributed model.

4) Proteon Inc.  Contact Alan Marshall <acm@proteon.com>.

	I can recommend CCMail as the product to work with pc
	networks.  This is connectable to SMTP mail via a public
	domain translator that I have written.  It is available from
	monk.protoen.com as arpagw.arc in the /ftp/pub directory.
	There is another implementation done from my implementation by
	Mike Morse (mmorse@nsf.com) that uses about 10k users in the
	system.  He would be a good one to talk with about your needs.
	I have some code from him too and he has said to make it
	available.  Perhaps there is a more current version that would
	help.

5) MIT.  Contact Mark Rosentein <mar@athena.mit.edu>.

	We've been thinking of tackling this problem here at MIT.  Our
	initial planning is as follows:

	*  The full name of every member of the MIT community will be known to
	   the mail hub.  Mail sent to someone's full name will result in:

	1) The mail is delivered if the name is unique and the person
	   has a mailbox 
	2) An error response is generated saying "[full name] does not
	   have an electronic mail address, please send mail to MIT
	   Room ..., Cambridge MA 02139"
	3) An error response is generated saying "[full name] is
	   ambiguous, please choose one:" followed by a list of people
	   giving the name, title, address, and a unique email
	   identifier.
	4) An error response saying "addressee unknown".

	*  Every member of the MIT community will be given a unique
	   identifier for email purposes.  For most active email users, this
	   will be their login name.  For other people and those with name
	   conflicts, it will be their initials and a number, similar to the
	   NIC's whois database.

	This information will be kept up-to-date by Moira, the Athena
	Service Management System, and regularly updated on the mailhub.
	Users will be allowed to update some of their own information,
	and to become unlisted if they want to. 

	Moira currently contains all of the necessary information for the
	students here at MIT, only the staff and remaining faculty must
	be added.  The primary development effort will be modifications
	to the mail hub. 

6) NCR. Contact Matt Costello <Matt.Costello@sandiego.nr.com>

	Well, I can help out some on this.  I designed the system in use
	throughout NCR and it conforms to your requirements.  There are
	~1300 people with email addresses in San Diego.  I believe Dayton
	(Galactic Headquarters) has around 6000 email addresses in it. 

	What I did was to create a database external to the mail system
	and then have the mail router look up certain addresses in this
	external database.  Any mail addressed to the domain name, or
	having a period in the username will be looked up in this
	database.  The database format is a rolodex(tm) format.  My entry
	is simply

	name	Matthew Costello
	phone	2926
	dept	4796
	email	mattc@ncr-sd

	This database format is simple to manipulate and edit using the
	standard unix tools, but there are also 7 programs (rolo,
	roloeach, roloedit, roloenter, rolorev, rolorpt & rolosort) that
	handle it more efficiently.  The command rolo(1) is used to look
	up the local portion of the name using a fuzzy matching
	technique, so the following will all find my entry and get my
	mail to me:
		matthew.costello
		matt.costello
		costello		I'm the only Costello in San Diego
		pat.costello
		m.castelli
		
	[ Accepting the last two was a mistake.  It would be better to
	fail and then [ return the close matches. 

	Because of the fuzzy matching the search must be linear through
	the whole file.  To compensate our mail router is able to cache
	found addresses in a separate file so they only get looked up
	once.  I would recommend using an "initial substring match" which
	is amenable to indexing. 

	-- 
	Matt Costello       <matt.costello@SanDiego.NCR.COM>      (CSNET)
	+1 619 485 2926     uunet!ncrlnk!ncr-sd!mattc
	---
	Matt Costello       <matt.costello@SanDiego.NCR.COM>      (CSNET)
	+1 619 485 2926     uunet!ncrlnk!ncr-sd!mattc

7) Universite Catholique de Louvain.  Contact Alain FONTAINE
  <FNTA80@BUCLLN11.BITNET>. 

	We have established an unified address scheme here. But we did
	not find any way to allow external correspondants to send mail to
	an individual when only knowing his name, *and* avoid clashes...
	This seems theoretically impossible. The sender must *know* and
	*specify* some more information to garantee uniqueness.  So the
	addresses used are of the form :
	personal-identifier@unit.ucl.ac.be, where 'unit' is the
	standardized three or four letter sigle of the laboratory or
	service in which the person can be found.  Of course, it is
	difficult for an external correspondant trying to contact
	somebody for the first time to guess the 'unit' to be used. On
	the other hand, clashes are a very low probability event, since
	units never count more than 50 persons. 

	Implementation : the DNS would be a marvelous tool for this,
	since each unit could have and manage its own name server. Halas,
	(one of my favorite gripes), the arbitrary division of mail
	addresses into a local and a domain part makes it impossible to
	use the DNS down to the individual level. So the current
	situation is that one centralized machine contains a centralized
	database of mail routing information, and nearly all
	domain-addressed mail goes physically (uh, should we say that
	about zeroes-and-ones on wires and disks and ...) through that
	machine. 

8) Carnegie-Mellon University.  Contact Craig Everhart
  <cfe+@andrew.cmu.edu>. 

	Andrew supports 8500 user names reasonably gracefully, though
	we've given up on making login-names guessable; too many
	collisions.  Instead, we use a White Pages service to map name
	probes to mailboxes, letting it handle any collisions. 

	  My free advice to you would be to forget making names unique;
	they never will be.  Make login-names unique and provide simple
	ways to map from person-names to login-names (and use them for
	delivering incoming mail).  MCI Mail, with a cast of many hundred
	thousand, did the same thing; everybody's mailbox is a number. 

9) University of Illinois at Urbana.  Contact Paul Pomes
  <Paul@uxc.cso.uiuc.edu>. 

	The Computing Services Office at the University of Illinois at
	Urbana is in the process of creating a university-wide mailing
	system.  The system is comprised of three pieces.  The largest is
	the white-pages system created by Steve Dorner of CSO.  It's
	based on the CSnet central name server (qi - Query Interpreter).
	Each student and staff member is assigned a unique alias.  The
	user is allowed to change the issued alias provided it remains
	unique.  Associated with this alias is the user's preferred email
	address, office address, home address, phone numbers, etc.
	Everything that is in the paper phone book is also in the qi
	database. 

	The user client is a program called ph.  It searches on the
	unique alias and can fuzzy match on names.  Providing ancillary
	information such as department or curriculum narrows the search. 

	The second piece is the 5.61+IDA sendmail release.  The
	ida/cf/Sendmail.mc has been very slightly modified to invoke a
	new mailer, phquery, whenever an address resolves to
	<name>@uiuc.edu.  This is configured with the DOMAINMASTER
	option. 

	Phquery is the third piece.  It examines its arguments and calls
	qi to determine the preferred email address for the supplied
	name.  At this point, name can be only the unique qi alias.  This
	restriction will soon be lifted to allow phquery to resolve full
	names (e.g., paul-pomes@uiuc.edu -> paul@uxc.cso.uiuc.edu), and
	amateur radio callsigns (e.g., ka9wgn@uiuc.edu ->
	phil@vmd.cso.uiuc.edu).  In the case of ambiguous matches,
	phquery will return a list of possibilities that includes
	department and/or curriculum information that should allow the
	sender to make the next attempt successful. 

	Future enhancements include automated printing and campus mailing
	of messages to those users w.o. email addresses. 

	Source for the qi (central server) and ph (user client) can be
	obtained via anon-FTP from uxc.cso.uiuc.edu:/net/{ph,qi}.  The
	phquery code, when ready, will be included in the
	/mail/sendmail/uiuc directory. 

	Sorry, we cannot email this code as it is much too large.
	Chocolate chip cookies with a postpaid tape will work wonders
	though. 

10) University of Virgina.  Contact Tom Sigmon <tms@virgina.edu>


	I am responding to the request in BIG-LAN regarding
	university-wide electronic mail networks.  We here at the
	University of Virginia have created such an environment that
	addresses most of the points that were brought up.  Our
	electronic mail environment currently encompasses over 300
	machines (not PCs, etc.) having many different mailers running on
	many different operating systems.  I'll try to summarize the
	basic points here and if there are follow-up questions, I'd be
	happy to address them. 

	   - we use domain addresses only.  If a user wants to send mail
	to someone on a non-domain network, then they must use an
	appropriate "pseudo-domain" within a domain address.  For
	example, sending mail to someone on Bitnet would require an
	address of the form "user@host.bitnet".  Likewise, sending mail
	to someone on a UUCP host requires an address of the form
	"user@host.uucp" (our mailers figure out the best path to the
	target host). 

	- third-level domains within the "virginia.edu" domain are named after
	departments or other University organizations (usually using
	the standard registrar's designation)

	- departments create whatever fourth-level domains or machine
	names (the usual case) that they desire

	- we here in the Academic Computing Center created and maintain
	a database of every faculty, staff, or student associated with
	the University.  The basic data comes from the registrar's database
	and the payroll database from our administrative computing center.

	- as part of this database, we automatically create unique mail ids
	for every single person associated with the University.  These ids
	are also (conveniently) used as the login id on most machines.  The
	format of this unique id is as follows:  person's initials optionally
	followed by a 2-character suffix whose first character is a digit and
	whose second character is alphabetic.  For instance, my mail/login id
	is simply my initials, "tms".  All other people who have the same
	initials as me have a suffix on their mail id, e.g., tms2x, tms4g, etc.
	Obviously, the choice of format and a priori creation of unique
	mail/login ids is the most controversial part of our environment.
	There are advantages and disadvantages of this system which I won't
	go into unless someone is interested.

	- since all of these mail ids are unique, they can be considered to be
	"aliases" in the "virginia.edu" domain.  We support the notion of
	"registration" which creates a mapping between a person's unique
	mail id (in the virginia.edu domain) and the actual account and domain
	where that person reads his mail.  For example, all mail sent to
	"tms@virginia.edu" will be delivered to the place where I actually
	read my mail which is "tms@boole.acc.virginia.edu".  Thus, no one
	needs to know the details of exactly where I read my mail. Every system
	in our environment allows users to set/change their registration
	since it is done via a mail message to one of our main mail servers.
	Most systems wrap a shell script around this registration process
	so that it is very easy for the user to register or make changes.

	- the above "registration" process is very important for mail coming
	to users from networks that don't support domain names (e.g., Bitnet
	and UUCPnet) as well as to present one "name" for the University to
	the outside world.  In these cases, if a user is not registered, then
	our mail servers would not know where to actually deliver the person's
	mail *especially* since we want to present one "name" to the outside
	world (i.e., it shouldn't be necessary for anyone to know the full
	domain name in order to send mail to someone at the University, nor
	should they need to know the internal network configurations, etc.).
	For example, the University has one name/address on both Bitnet and
	UUCPnet.  We are "virginia" on both networks, so someone on Bitnet can
	send mail to me as "tms@virginia" without regard to the actual machine
	I use to read my mail, and likewise, someone on UUCPnet can send mail to
	me as "...!virginia!tms" without regard to the actual machine I use to
	read my mail.

	- we also support user-created aliases at the virginia.edu level.  If
	a user does not like their automatically created unique mail id or
	would simply prefer to have other aliases, then they can request the
	creation of such aliases.  For example, in addition to sending mail
	to me as "tms@virginia.edu", people can also send mail to me as
	"sigmon@virginia.edu" or "9240615@virginia.edu" (which is my phone
	number).  The only restriction that we place on these user-created
	aliases is that they (obviously) must be unique, can not conflict
	with the regular expressions that describe our automatically-generated
	ids (so that they don't preempt future automatically-generated ids),
	and that they be "reasonable" (e.g., we don't allow people to be
	MickeyMouse, nor GeorgeBush, etc.).

	- of course, none of the above prohibits users from having aliases
	in other domains.  The Academic Computing Center administers ids and
	aliases at the virginia.edu level for the entire University.  Departments
	are free to have their own aliases in their own domains (except that
	mail coming from non-domain-based networks can't access them for obvious
	reasons).

	- the University telephone book has a section that lists the electronic
	mail ids and aliases for all registered mail users at the University.
	In addition, we support a "whois" capability on many of our machines
	that allows users to interactively query our database to determine
	mail ids, phone numbers, department affiliations, etc.

	Hope this helps others establish university-wide mail networks.
	I'm happy to provide more detail or answer questions, just send
	me mail! 

11) Stanford University.  Contact Bob Morgan <morgan@jessica.stanford.edu>.

	Yes, assigning what we have come to call a "unique-id" to a
	campus-full of people is a tricky issue.  We have made a few
	abortive attempts at campus-wide mail delivery
	(unique-id@stanford.edu), but have run into the twin problems of
	a) choosing the unique-id, and b) letting people update their
	unique-id/actual-mailbox mapping without involving great piles of
	paper/bureaucracy/our time. 

	Right now we generate unique-ids for use with a phone-book-type
	service (based on Whois, RFC 912), using the following algorithm,
	moving down the list in case of name clash:

	1) first-initial/last-name (rmorgan), or
	2) first-initial/middle-initial/last-name (rlmorgan), or
	3) as-many-initials-as-necessary/last-name (rlfmorgan), or
	4) as-many-letters-of-first-name-as-necessary/last-name (robmorgan),
	or
	5) first-name/middle-initial/last-name (robertlmorgan), or
	6) 5) with digits as necessary appended (robertlmorgan3).

	(If you have a Unix "whois" client, you can bang our server with:
	  > whois -h argus.stanford.edu some-string)

	Looking through our 153 Smiths, I see no uses of rule #6, about 5
	cases where #5 was used, and several instances of repeated
	application of #4 (dasmith, davsmith, davismith, davidsmith).  I
	suspect that if we started using this for actual mail delivery
	(or, even more so, for Kerberos-style principal ids), some people
	would complain and insist on choosing their own.  The question
	then becomes, how do you decide what's reasonable?  If Joe
	Student wants to be known as "donaldkennedy" (SU's president), is
	that OK?  Part of the problem is that if these things are
	assigned immediately when people arrive (as they must be) then
	people will be stuck with something before they know what it's
	about (as with real names, I suppose). 

	No solutions, just more questions,

12) Dartmouth University.  Contact Steve Campbell
  <Steve.Campbell@dartmouth.edu>. 

	Dartmouth has a scheme much like the one you describe, called the
	Dartmouth Name Directory.  The DND is a database of about 13,000
	names with corresponding nicknames, password, paper-mail address,
	phone number, department (or undergraduate class), and e-mail
	address.  Mail addressed to Joe.Blow@dartmouth.edu goes to Joe
	Blow's preferred e-mail address, as it is recorded in the DND. 

	People are uniquely identified by the tokens in their name -- the
	name space is small enough that first name + middle initial +
	last name is unique in all but a very few cases.  Those people
	have their middle names entered also.  The names, nicknames, and
	departments are all lookup keys and partial matches are
	supported.  So you can mail to me with
	"James.W.Matthews@dartmouth" (my full name), "James W M"
	(abbrieviating the last name) or "Jim Matthews" (matching my last
	name and a nickname).  Only one token match must be exact. 

	If there are multiple matches a bounce message is generated,
	listing the matches (as long as there are fewer than fifteen or
	so).  So it is fairly easy to refine an address to the required
	precision. 

	The DND is seeded by the personnel and registration systems, and
	several fields (paper mail address, e-mail address, phone number,
	and nicknames) are user-maintained.  The default e-mail address
	is our paper mail system -- messages are printed out and hand
	delivered. 

13) "Track".

	I suggest you consider a software distribution to control the
	mail software.  See _1989 USENIX Software Mangement Workshop
	Proceedings_ for a good discussion or two or three on some
	software called Track. 

14) UCSD. Contact Brian Kantor <brian@ucsd.edu>.

	UCSD has such a mail system.  You may query it over the net to
	see what it looks like with the 'whois' command; try
		whois -h ucsd.edu smith
		whois -h ucsd.edu jsmith
	and variations along that line.

	The software to implement this is available in our anonymous FTP
	directory; take file pub/mailreg.tar.Z.  Caveat Emptor: the
	software is continuously being refined and is not documented. 
	
15) University of Kent at Canterbury.  Contact <sjl@ukc.ac.uk>.

	We operate an unified mail system for some 4000 staff and
	students. We use a centralised admin server which allocates a
	unique userid for each user.  In addition it will allocate a
	login (also unique) for the machines they require. 

	On top of the admin server we run a mail database system
	(original designed at Edinburgh University). The user interface
	to this is the mailhost program.  the user may nominate any
	machine he can log into as his mail machine. He does this by
	typing "mailhost -c". At night all the machines swap lists of
	users. Each entry in the list has a date stamp, if this stamp is
	later than the local machines recorded gate stamp for the user
	the entry is updated. 

	An extension to this is being worked on at the moment which
	allows psuedo domains. A group of workstations (typically) have a
	pseudo domain centered on their fileserver. This is still
	experimental. 

	The system has been in use for about three years now with no
	problems. 


16) UMCP.  Contact Mark Feldman <feldman@umd5.umd.edu>.

	   I know of a few places that do this sort of thing.  First,
	there's the UMAIL project here at UMCP.  One can send mail to
	various user names at host umail.umd.edu, and the mail gets
	delivered, even if the user doesn't have a computer account
	anywhere.  (In that case, mail gets printed out and sent via
	campus mail.) I am by no means fully up on the details of this
	system; you might talk to Mark Feldman (feldman@umd5.umd.edu) to
	get more information.  He may not be the right contact, but he
	can probably name the right people if asked. 

	...
	
Contact Steve <steve@umiacs.umd.edu>

	   Third, I'm implementing something that, while it doesn't do
	everything, does most of what you want (and which can be extended
	to do more).  Basically, it's an automatic method of generating a
	'global' mail address database, made from the union of the
	password and alias files for a particular department.  Getting
	all such files for a whole campus would be hard, but there's also
	a facility for getting just another department's global database
	and merging it in with others.  There's a concept of
	locality-of-reference, too; if I send mail to 'root', I get the
	UMIACS root, even though there's a 'root' in the CS Department's
	imported information.  This locality can be guaranteed either
	manually or automatically. 

	   If extended with some software to generate full-name addresses
	(First.MI.Last), and some software to handle duplicates
	differently, my code would probably do everything you need.  The
	only hitch is that the stuff I've written is not yet in extensive
	use (so I'd bet it has, er, misfeatures), and it's essentially
	undocumented.  If you want a copy of the code as it stands, I
	could provide one.  It's solid (it's even been Saberized), but
	it's definitely in need of some major cleaning up... 

17) ATT Private Mail Exchange.  Contact Rod Hart <hart@cp1.cp.bell-atl.com>.

	Look into the AT&T Private Mail Exchange System (PMX). My
	organization is in the process of installing one right now to
	solve a similar problem. We need x.400 in order to tie the
	various user groups (ie. DG, Proffs, Wang, PC, and of course
	Unix) together as well as document conversion. 
-=-

Norm Pritchett, The Ohio State University College of Engineering Network
Internet: pritchett@eng.ohio-state.edu	BITNET: TS1703 at OHSTVMA
UUCP: pritch@sydney.columbus.oh.us	CCNET: ENG::PRITCHETT (6172::PRITCHETT)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 17:02:52 GMT
From:      hrp@boring.cray.com (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE considered harmful?

Here are a couple of relevant extracts from section 4.2.3.5 of the 17
May draft of the Requirements for Internet Hosts RFC:

                 A "keep-alive" mechanism would periodically probe the    |
                 other end of a connection when the connection was        |
                 otherwise idle, even when there was no data to be sent.  |
                 The TCP specification does not include a keep- alive     |
                 mechanism because it could:  (1) cause perfectly good    |
                 connections to break during transient Internet           |
                 failures; (2) consume unnecessary bandwidth ("if no one  |
                 is using the connection, who cares if it is still        |
                 good?"); and (3) cost money for an Internet path that    |
                 charges for packets.                                     |

[ . . . ]

                 A TCP keep-alive mechanism should only be invoked in     |
                 network servers that might otherwise hang indefinitely   |
                 and consume resources unnecessarily if a client crashes  |
                 or aborts a connection during a network partition.       |

Bob Braden points out that one of the design goals of TCP/IP was and
is robustness in the face of errors: even if a few gateways melt down,
the TCP connections that had been using them should pick up where they
left off when new routes materialize.  Keepalives are explicitly
designed to avoid this.

The pros and cons, however, are subject to some disagreement.

--
Hal Peterson			Domain:  hrp@cray.com
Cray Research			Old style:  hrp%cray.com@uc.msc.umn.edu
1440 Northland Dr.		UUCP:  uunet!cray!hrp
Mendota Hts, MN  55120  USA	Telephone:  +1 612 681 3145

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 20:23:09 GMT
From:      kay@warwick.UUCP (Kay Dekker)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   RDP info/source wanted

I'm looking for the source to the Reliable Datagram Protocol (RDP) for
BSD Unix.  Apparently RDP runs over UDP retaining the datagram format
but guaranteeing reliable delivery.

I've heard mention that it was posted to comp.sources.unix, or some
other group, but I've been unable to find any information on it.
If anyone has any information on the package, or any similar package,
or the source, could they please mail the address in the Reply-To:
field in the header of this article.

							Vato.
the Crisco Kid: nasty pinko faggot agnostic pervert punk.  csx043@uk.ac.cov.cck

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 20:26:15 GMT
From:      nick@toro.UUCP (Nicholas Jacobs)
To:        comp.protocols.tcp-ip
Subject:   TCP Port question

In RFC 1010, there is a list of officially defined ports used by TCP
(and by UDP wherever possible). I am writing a server process which
hangs on a "well-known" port which can supply both the official ports
(given a port name or number) and to which locally defined ports can be
added to dynamically (thus programs can ask this process to generate
new port numbers).

I have 2 questions:
	1) Is this service already defined (and thus I should simply
	   mimic its behavior)?
	2) Failing that, is there a port that is recommended for this
	   service (I am planning on using IPPORT_RESERVED+1)?

We are are running Excelan's TCP/IP on NCR Towers running SysV.1 and 2.
These machines are running on Ethernet LANs and are not attached to
the Internet in any way whatsoever...
Please email me any recommendations.

Thanks,

Nicholas Jacobs
UUCP: ...!uunet!toro!nick Internet: toro!nick@uunet.uu.net
AT&T: (212) 236-3230

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 20:34:12 GMT
From:      mo@prisma.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

If Keepalives are not (judiciously!) used, how does one transparently
discover that the other end of the connection has died a horrible,
sudden death?

One can argue whether this is a transport or session function, but
the ability to lose one end of the connection while the passive
end just hangs forever is NOT a feature.

	-Mike

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 21:02:32 GMT
From:      jmh@ns.network.com (1606)
To:        comp.protocols.tcp-ip
Subject:   KeepAlive

Given that most extended networks are not 100% reliable, some form
of keepalive is needed to detect loss of connectivity.

If I have a telnet connection to a host, and then the network fails,
I would appreciate it if the remote host knew this and could
undertake appropriate cleanup activities.

The key question is how often KeepAlive signals should be sent, and
what interval without any should result in declaring the connection
dead.

As a separate issue, the TCP implementation of keepalive signals
is sufficiently confused and inconsistent as to make it an undeirable
solution to the problem.

Joel M. Halpern
Network Systems Corporation
jmh@nsco.network.com

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 21:03:13 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

I tried to avoid saying that keepalives should be prohibited, except,
perhaps, from an aesthetic point of view.  Since aesthetics often are
altered by reality, it is no great concession to acknowledge the 
occasional need for the mechanism.

My point was that they are dangerous and therefore should be used VERY
judiciously.  Craig's note puts this point forward in more detail.

It is worth adding that the excessive use of keepalives has removed a
feature that used to be in TCP and has been recently re-documented by
Bob Braden:  TCP used to be remarkably robust against temporary
outages.  If you were willing to wait, so was TCP.  Now, an outage of
a very short time -- on some implementations, as short as 1-2 minutes --
will abort the connection.

Dave

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 May 89 21:36:28 GMT
From:      ANNABLE@THORIN.HSCSA.UTEXAS.EDU (conni annable)
To:        comp.protocols.tcp-ip
Subject:   Zenix tcp

One of our folks has a loaner 386 box running zenix and would like to
have ftp and telnet capability for it. He will have the box on loan
(and evaluation) for some 3 or 4 months and therefore does not want to 
pay a great deal (read nothing) for these capabilities. He has available
3com 3C501 cards. Does anyone know of a free or near-free product that
will help him out?

thanks,
conni annable            annable@thorin.hscsa.utexas.edu
network manager
University of Texas Health Science Center at San Antonio
(512) 567-2091

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 00:07:51 GMT
From:      mikes@zephyr.ENS.TEK.COM (Mike Skrydlak)
To:        comp.protocols.tcp-ip
Subject:   ncsa telnet (pc) ftp bug ?


Just with ftp. No problem with telnet. And just when I ftp to vms through
the DEC Ultrix IP/Decnet gateway. If I ftp to unix, or to vms directly,
no problem. The problem: when I do ls or dir, the display comes to my pc
screen looking like LF is missing after CR. I tried uncommenting a line
in config.tel concerning crnul, no effect. Help, anyone ?

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 00:08:58 GMT
From:      deanr@lakesys.UUCP (Dean Roth)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for Sun 386i


One of my engineers is asking for Van Jacobson's
"tcpdump" program for Sun 386i (SunOS 4.0).
How can I get a copy? Is it free or cost $? Is it
public domain? 

Please note, I cannot ftp from anywhere, and only
have UUCP/email access.  Please email your response
to avoid net clutter and I will summarize if
anyone else is interested.


deanr@lakesys.lakesys.com
deanr@lakesys.UUCP

Dean A. Roth
Director of Software Engineering
Merge Technologies, Inc.
P.O. Box 27366
Milwaukee, WI 53227
(414) 256-5360

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 00:10:19 GMT
From:      tozz@hpindda.HP.COM (Bob Tausworthe)
To:        comp.protocols.tcp-ip
Subject:   subnet mask problem

I have a question concerning subnet masks. Normally, the masks I have 
seen are a sequence of 1's followed by a sequence of 0's, something like:
255.255.0.0. This corresponds to the high order portion of the IP address
denoting the network number, and the low order portion denoting the subnet
and host number portions.

However, because the algorithm for using masks is to perform a logincal AND 
and test for equality, technically 255.255.0.255 could be used as a mask.
Or could it?

1) is a mask such as 255.255.0.255 even legal (i.e. conform to specifications)

2) does anybody know of a network user whose mask is of the form above.

			     tozz@hpda.hp.com

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 00:43:42 GMT
From:      todds@cognos.UUCP (Todd Sandor)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Ethernet type code 8035 hex?

In article <2818@yarra.oz.au> chris@yarra.oz.au (Chris Jankowski) writes:
>
>1. What is Ethernet type code 8035 hex?
It is the RARP, for Reverse Address Resolution Protocol, see below--this
was from the net.
Future publications of this information will probably be as a TCP/IP
Internet RFC, rather than email to this mailing list. If you wish
to comment on the format in which this data should be presented,
or if you wish to be placed on a private mailing list for these
updates, please send me mail at Urbaniak@BBN.COM, or US Mail at

	Bolt, Beranek & Newman, Inc.
	10 Fawcett Street
	Cambridge, MA 02138
	attn: Walter Urbaniak, MS021
 Some Known Ethernet and IEEE802.3 "Type" Fields		3/16/89

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-088A	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 for IP
1600	VALID system protocol *
5208	BBN Simnet Private %
6000	DEC unassigned, experimental
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV, DNA Routing
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC), System Communication Architecture (SCA)
6008	DEC unassigned (AMBER?)
6009	DEC unassigned (MUMPS?)
6010-6014	3Com
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
7020-7029	LRT
7030	Proteon
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8008	AT&T
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
802E	Tymshare
802F	Tigan
8035	Reverse Address Resolution Protocol (RARP)
8036	Aeonic Systems
8038	DEC LanBridge Management
8039	DEC unassigned (DSM/DTP?)
803A	DEC unassigned (Argonaut Console?)
803B	DEC unassigned (VAXELN?)
803C	DEC unassigned (NMSV? DNA Naming Service?)
803D	DEC Ethernet CSMA/CD Encryption Protocol
803E	DEC unassigned (DNA Time Service?)
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned (NetBios Emulator?)
8041	DEC unassigned (MS/DOS?, Local Area System Transport?)
8042	DEC unassigned
8044	Planning Research Co.
8046	AT&T
8047	AT&T
8049	ExperData
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
805D	Evans & Sutherland
8060	Little Machines
8062	Counterpoint Computers
8065	University of Massachusetts, Amherst
8066	University of Massachusetts, Amherst
8067	Veeco Integrated Automation
8068	General Dynamics
8069	AT&T
806A	Autophon
806C	ComDesign
806D	Compugraphic
806E-8077	Landmark Graphics
807A	Matra
807B	Dansk Data Elektronik
807C	Merit Internodal (or Univ of Michigan?)
807D-807F	Vitalink
8080	Vitalink TransLAN III Management
8081-8083	Counterpoint Computers
809B	EtherTalk (AppleTalk over Ethernet)
809C-809E	Datability
809F	Spider Systems
80A3	Nixdorf Computers
80A4-80B3	Siemens Gammasonics
80C0-80C3	DCA (Digital Comm. Assoc.) Data Exchange Cluster
80C6	Pacer Software
80C7	Applitek
80C8-80CC	Intergraph
80CD-80CE	Harris
80CF-80D2	Taylor Instrument
80D3-80D4	Rosemount
80DD	Varian
80DE-80DF	Integrated Solutions Transparent Remote File System (TRFS)
80E0-80E3	Allen-Bradley
80E4-80F0	Datability
80F2	Retix
80F3	AppleTalk Address Resolution Protocol (AARP)
80F4-80F5	Kinetics
80F7	Apollo
80FF-8103	Wellfleet
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8130	Waterloo Microsystems
8131	VG Laboratory Systems
8137	Novell (old)
8138	Novell
8139-813D	KTI
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
9003	Bridge Communications
FF00	BBN VITAL-LanBridge cache wakeups %
-- 
Todd Sandor             Voice: (613) 738-1338 ext 2704     P.O. Box 9707
Cognos Incorporated     FAX: (613) 738-0002                3755 Riverside Dr.
uucp: todds@cognos || uunet!mitel!scs!cognos!todds         Ottawa, Ontario
Steady as she goes!                                        CANADA  K1G 3Z4

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 02:37:13 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re:  SO_KEEPALIVE considered harmful?

| From: dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
| 
| If the group proposing the use of Keepalives has already gone through the
| exercise of convincing themselves that critical functionality will be
| lost if they are not used, then I hope the next question was/is how to
| minimize their use.

  I think that the big problem that Robert may be trying to deal with is
server crashes.  (Correct me if I'm totally off the deep end Robert.)
Currently, when an X.V11R3 server crashes or simply exits for normal
reasons and there are still clients using it, those clients will
(typically) lay around forever because they never try to contact the
server on their own and they never receive anything from the [now
defunct] server.  [One exception to this is the "xperfmon" client which
periodically attempts to update a system statistics display.  When the X
server disappears, xperfmon starts gobbling up reams of CPU time, not
recognizing the closed connection for what it is.  But this is just a
coding error.]

  I would say that any X client which only tries to use its connection to
the server in response to input from the server should run with
keep-alives on the connection.  Otherwise it will never exit.  I'm
constantly having to go around killing off abandoned xterms because some
people just can't remember to terminate all their client before shutting
down their server.

Casey

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 10:58:57 -0500
From:      "Paul Pomes (I'm the NRA!)" <paul@uxc.cso.uiuc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Hitchhikers guide to Internet
The HGI is available for anon-FTP from uxc.cso.uiuc.edu (128.174.5.50)
in the file /pub/hgi.me .  A line printer formatted version is in /pub/hgi.txt .

/pbp
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 10:23:52 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        kay@warwick.uucp
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: RDP info/source wanted

> 
> I'm looking for the source to the Reliable Datagram Protocol (RDP) for
> BSD Unix.  Apparently RDP runs over UDP retaining the datagram format
> but guaranteeing reliable delivery.
> 
> I've heard mention that it was posted to comp.sources.unix, or some
> other group, but I've been unable to find any information on it.
> If anyone has any information on the package, or any similar package,
> or the source, could they please mail the address in the Reply-To:
> field in the header of this article.

Kay:

    RDP does not run over UDP.  RDP is a separate transport protocol,
that does reliable delivery of datagrams.  In general, it is more accurate
to think of it as a TCP that preserves record boundaries, than as a UDP
that has been made reliable.  In particular, RDP is a connection-oriented
protocol, not connection-less.

    It is described in RFC 908.  I have an implementation which was originally
based on RFC 908 but then upgraded somewhat based on experience.  (In
particular, the checksum algorithm had a severe byte-order bias that caused
RDP to run 2 or more times slower on machines that had the wrong byte sex).

    This implementation is available for experimental use by (free) license
from BBN.  Note that as with many licensing procedures, it can take some time
to get through all the paperwork.  Drop me a note if you are interested.

Craig
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 04:17:08 GMT
From:      toddpw@tybalt.caltech.edu (Todd P. Whitesel)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Port question

In article <364@toro.UUCP> nick@toro.UUCP (Nicholas Jacobs) writes:
>In RFC 1010, there is a list of officially defined ports used by TCP
>(and by UDP wherever possible). I am writing a server process which
>hangs on a "well-known" port which can supply both the official ports
>(given a port name or number) and to which locally defined ports can be
>added to dynamically (thus programs can ask this process to generate
>new port numbers).
>
>I have 2 questions:
>	1) Is this service already defined (and thus I should simply
>	   mimic its behavior)?
>	2) Failing that, is there a port that is recommended for this
>	   service (I am planning on using IPPORT_RESERVED+1)?

1) yes, it's in RFC 1078 (TCPMUX).
2) i'm not sure, see 1078.

one thought on 1078 as I remember it: using TCP for a simple transaction like
the port server is overkill when using UDP would require a simple two packet
exchange process.

Has anyone actually implemented something like this or do we have to wait until
BSD does it?

Todd Whitesel
toddpw @ romeo.caltech.edu
toddpw @ caltech.bitnet
toddpw @ CITDEIMO

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 07:02:56 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip,comp.sys.super,comp.unix.cray
Subject:   Benchmarking NFS, X-windows and TCP/IP generally

I am interested in any attempts to benchmark NFS performance. What about
networks with higher speeds than ethernet: e.g. the channel link from
a Cray to a Sun?

I am also interested in any ideas on how to benchmark X-windows performance
(I presume that server speeds are the limiting factor here and there is
no point going into the speed of the client, particularly if the client is
on a supercomputer).

Attempts to benchmark the performance of TCP/IP implementations is
also of interest.

In each case the questions are: Are there published results? Or are
there available benchmark suites?

Bob Smart <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 16:42:40 -0400
From:      "Alan R. Hill" <ahill@BBN.COM>
To:        Charles Spurgeon <spurgeon@sirius.cc.utexas.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Small TTL values evaporate in large networks
Charles,
	Was there any evidence that the hop that dropped the packet
after its TTL expired informed the source of its action?

Alan
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 12:48:56 GMT
From:      rws@EXPO.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   re: SO_KEEPALIVE considered harmful?

Thanks for all the responses so far, I think I get the picture.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 13:47:12 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: sendmail hanging followup

One consideration that hasn't been discussed is what TCP MSS options are
sent when the connection is opened, and how the two hosts are supposed to
deal with them.  I have some recent experience with IBM VM systems which
request 1460 byte MSS regardless of whether the connection is on the local
subnet, or routed via a gateway.  If your host's TCP/IP is just accepting
and using the requested MSS (or min(1024, FRN_MSS), as Unices tend to), this
could be the problem.

FTP's TCP requests a 512-byte MSS when the connection is routed via a
gateway, and uses min(512, FRN_MSS) on the transmit side (a relatively
recent change; I used to just do what they told me, but 'they' were all
too frequently broken).

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

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 19:04:25 EST
From:      Mark Powers <MP14STAF%MIAMIU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Hitchhikers guide to Internet
>Date sent:  22-MAY-1989 16:30:12
>
>Can anyone tell me where to find the above paper? (anonymous FTP)
>
>Thanks!
>Dave
>

Hitchhikers guide is available via anonymous ftp from uxc.cso.uiuc.edu
I got it yesterday...

Could someone tell me what word processor to use to format it ?

                              Mark
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 14:23:52 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: RDP info/source wanted


> 
> I'm looking for the source to the Reliable Datagram Protocol (RDP) for
> BSD Unix.  Apparently RDP runs over UDP retaining the datagram format
> but guaranteeing reliable delivery.
> 
> I've heard mention that it was posted to comp.sources.unix, or some
> other group, but I've been unable to find any information on it.
> If anyone has any information on the package, or any similar package,
> or the source, could they please mail the address in the Reply-To:
> field in the header of this article.

Kay:

    RDP does not run over UDP.  RDP is a separate transport protocol,
that does reliable delivery of datagrams.  In general, it is more accurate
to think of it as a TCP that preserves record boundaries, than as a UDP
that has been made reliable.  In particular, RDP is a connection-oriented
protocol, not connection-less.

    It is described in RFC 908.  I have an implementation which was originally
based on RFC 908 but then upgraded somewhat based on experience.  (In
particular, the checksum algorithm had a severe byte-order bias that caused
RDP to run 2 or more times slower on machines that had the wrong byte sex).

    This implementation is available for experimental use by (free) license
from BBN.  Note that as with many licensing procedures, it can take some time
to get through all the paperwork.  Drop me a note if you are interested.

Craig

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 19:59 EDT
From:      "John L. Jamison x8508" <JAMISON%campus.swarthmore.edu@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   TALK for VMS requested

  Anybody have a Tcp/ip TALK program which runs under VMS? I could really
use this program.  We're not on the Internet yet, so I can't FTP!

Thanks alot,

John Jamison
Swarthmore College CC
jamison@campus.swarthmore.edu

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 May 89 20:01 EDT
From:      "John L. Jamison x8508" <JAMISON%campus.swarthmore.edu@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   TALK for VMS requested

  ANybody have a Tcp/ip TALK program for VMS? I could really use it.
We're not on the Internet so anonymous FTP cannot help.

Thanks alot,

John Jamison
Swarthmore College CC
jamison@campus.swarthmore.edu
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 16:36:22 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SO_KEEPALIVE considered harmful?


I don't believe anyone has advocated that keep-alives are a bad thing...
indeed, they appear to be a necessity in an imperfect world.  The
controversy (for the past 10 years, at least!) is whether or not they
belong in TCP.  The decision of the TCP/IP developers was that 
keepalives ought to be in the application layer, not the transport layer.

Each application has its own parameters for keepalive.  Furthermore,
cautious application implementors may already have application-level
keepalives, and economy of protocol mechanism argues for having the
functionality at only one level.  On the other hand, one can (and
some people do) argue that economy of mechanism requires that TCP
provide a keepalive mechanism that may be invoked and parametrized
by an application.  The Host Requirements RFC explicitly allows that. 

Bob Braden

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 16:53:16 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  subnet mask problem


	However, because the algorithm for using masks is to perform a logincal AND 
	and test for equality, technically 255.255.0.255 could be used as a mask.
	Or could it?

	1) is a mask such as 255.255.0.255 even legal (i.e. conform to specifications)

Yes. Please see Section 1.1.4 of RFC-1009, "Requirements for Internet
Gateways".

Bob Braden

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 18:02:27 GMT
From:      amanda@intercon.UUCP (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet mask problem

In article <6200023@hpindda.HP.COM>, tozz@hpindda.HP.COM (Bob Tausworthe) writes:
> 1) is a mask such as 255.255.0.255 even legal (i.e. conform to specifications)

A subnet mask can be any combination of 32 bits and still be legal.  However,
there do exist a number of IP implementations that can only handle masks
with contiguous '1' bits, or worse, contiguous '255' bytes.

These implementations are broken.

--
Amanda Walker <amanda@intercon.UUCP>
InterCon Systems Corporation

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 18:15:44 GMT
From:      spurgeon@SIRIUS.CC.UTEXAS.EDU (Charles Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Small TTL values evaporate in large networks

Here's one for the ``Netstoppers Notebook.''

We've recently resolved a number of mail failures at UTexas by
noticing that the TCP in older UNIX boxes (BSD 4.2, SunOS 3.2) was
setting the TTL to 15 in outgoing packets.

The network path to some sites at MIT consists of 17 hops from Austin
and the TTL was expiring before the packet got to the destination
address!  This kept the mail from getting through.  If you notice
consistent mail failures to a distant address you might want to check
on the outgoing TTL.  It appears that BSD 4.3 sets the TTL to 30 in
outgoing TCP.

While cognizant of the need to keep TCP segment lifetimes on a short
chain one does wonder what a good value for the TCP TTL might be?
With hop counts of around 20 already being seen, the new ``standard''
of 30 doesn't inspire confidence...

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 19:37:39 GMT
From:      mre@beatnix.UUCP (Mike Eisler)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

In article <8905231205.AA00500@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU writes:
>I have a random question that I hope this illustrious audience can answer
>definitively for me (or else point me to a definitive source).  Is the BSD
>notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to
>the TCP specification?  If so, is its use to be encouraged?  Specifically,
>it has been suggested that in the X Window System world, X libraries
>should automatically be setting SO_KEEPALIVE on connections to X servers.

When we brought up X on our BSD systems we tested it against a Visual Graphics
640 X-term. xterm was set up to spawned by init. When the Visual was powered
off during a connection a new x-term wouldn't get respawned. Analysis
of the BSD client showed the old x-term connection intact, and the xterm
process waiting for a message from the Visual which it would never get. We
figured KEEP alives would solve the problem and put them into the X
library. We found that this cured the problem when the Visual was powered
off for a long time; the KEEP alives eventually timed out waiting for a
response.

But for a quick power-off/power-on, KEEPs didn't help. KEEPs are
implemented as 1 byte segments countaining rcv_next-1,snd_una-1 as the
ACK and SEQ number values (i.e., a 1 byte segment that the segment's
receiver has already acknowledged, containing an ACK sequence # for a
byte that the segment's sender has already received).  The Visual is
listening for a X connection, and as expected responds with a 0 byte
reset, using rcv_next-1 as the SEQ number value.  After getting the
reset, BSD resets the KEEP alive timer because it has "proof" that the
connection is no longer idle. BSD then proceeds to follow instructions
of section 9.2.15.2 "Reset processing" in MIL-STD-1778 (12 Aug 83):

	" ... A reset is valid if its sequence number is in the connection's
	receive window. ... "

Well rcv_next-1 is not in the xterm client's window, so the reset is
tossed, *after* the KEEP timer was reset. So the BSD client sends
another KEEP a few seconds later and the process repeasts itself.  So
we don't get a connection reset, and we don't even get a connection
timeout as a consolation prize.  I suppose we could have "fixed" the
BSD code to not reset the KEEP timer on resets, but we wanted to have
something that would work in the field on existing versions of our
O/S.  We hacked xterm to send send the NOP request of the X protocol to
the server every so often and this has the desired effect (I'm putting
on my asbestos suit now...) of getting the immediate reset from the
Visual, *within* the client's window. The KEEP alive feature doesn't
seem that well thought out. Nor does server crash recovery seem well
thought out in X.
	-Mike Eisler (uunet,sun}!elxsi!mre

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 20:15:00 GMT
From:      phil@ux1.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?


>	     A TCP keep-alive mechanism should only be invoked in     |
>	     network servers that might otherwise hang indefinitely   |
>	     and consume resources unnecessarily if a client crashes  |
>	     or aborts a connection during a network partition.       |

Even this should be unnecessary for servers that have a specific timeout,
e.g. FTP or SMTP will drop on you if you are idle too long.


--Phil howard--  <phil@ux1.cso.uiuc.edu>

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 20:21:00 GMT
From:      phil@ux1.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: KeepAlive


> If I have a telnet connection to a host, and then the network fails,
> I would appreciate it if the remote host knew this and could
> undertake appropriate cleanup activities.

Perhaps what might be needed is a RAYT (Reverse Are You There) command,
which is sent from server to client, and the client say YIAH (Yes I Am Here)
back to the server.  AYT already suffices the other way.

--Phil howard--  <phil@ux1.cso.uiuc.edu>

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 20:35:38 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Xerox document on XNS

I am looking for:

	 Internet Transport Protocols, Xerox Corporation document XSIS-028112

Anyone know where it is available and any costs!

					Thanks,

						Mark
------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	alias!mark@utcsri.uucp

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 20:42:40 GMT
From:      ahill@BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: Small TTL values evaporate in large networks

Charles,
	Was there any evidence that the hop that dropped the packet
after its TTL expired informed the source of its action?

Alan

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 21:35:26 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Re: Small TTL values evaporate in large networks

Neither value is correct.  It is clearly called out in RFC 793 (TCP)
to be sixty (60).  To quote:

  TCP/Lower-Level Interface

    The TCP calls on a lower level protocol module to actually send and
    receive information over a network.  One case is that of the ARPA
    internetwork system where the lower level module is the Internet
    Protocol (IP) [2].

    If the lower level protocol is IP it provides arguments for a type
    of service and for a time to live.  TCP uses the following settings
    for these parameters:

      Type of Service = Precedence: routine, Delay: normal, Throughput:
      normal, Reliability: normal; or 00000000.

      Time to Live    = one minute, or 00111100.

        Note that the assumed maximum segment lifetime is two minutes.
        Here we explicitly ask that a segment be destroyed if it cannot
        be delivered by the internet system within one minute.

Thus, neither 4.2bsd (15) nor 4.3bsd (30) is correct.  (Why fix a bug
with another bug?)

You can do a quick check by examining the value of TCP_TTL in
/usr/sys/netinet/tcp_timer.h, but there is no guaruntee that your
vendor compiled the kernel using this file.

In SunOS 3.5.2, the value has been increased to 30, which is not so
bad a bug.

The TTL was still 15 on Ultrix-32 V2.2.  I reported it in SPR
487999/ICA-16612.  I got patches for three kernel files.  I presume
that it is fixed in V3.0.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 23:59:00 GMT
From:      JAMISON@campus.swarthmore.EDU ("John L. Jamison x8508")
To:        comp.protocols.tcp-ip
Subject:   TALK for VMS requested


  Anybody have a Tcp/ip TALK program which runs under VMS? I could really
use this program.  We're not on the Internet yet, so I can't FTP!

Thanks alot,

John Jamison
Swarthmore College CC
jamison@campus.swarthmore.edu

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 00:01:00 GMT
From:      JAMISON@campus.swarthmore.EDU ("John L. Jamison x8508")
To:        comp.protocols.tcp-ip
Subject:   TALK for VMS requested


  ANybody have a Tcp/ip TALK program for VMS? I could really use it.
We're not on the Internet so anonymous FTP cannot help.

Thanks alot,

John Jamison
Swarthmore College CC
jamison@campus.swarthmore.edu

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 00:04:25 GMT
From:      MP14STAF@MIAMIU.BITNET (Mark Powers)
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers guide to Internet

>Date sent:  22-MAY-1989 16:30:12
>
>Can anyone tell me where to find the above paper? (anonymous FTP)
>
>Thanks!
>Dave
>

Hitchhikers guide is available via anonymous ftp from uxc.cso.uiuc.edu
I got it yesterday...

Could someone tell me what word processor to use to format it ?

                              Mark

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 03:56:08 GMT
From:      pozar@hoptoad.uucp (Tim Pozar)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   need neophyte docs


    Once upon a time, I had a doc titled "Introduction to the
Internet Protocols".  There was no author mentioned but it was
apperently written and/or stored at Rutgers.  If any one has a
copy, could you please send it along?  

	  Thanks much...
	    Tim

-- 
 ...sun!hoptoad!\                                     Tim Pozar
                 >fidogate!pozar               Fido:  1:125/406
  ...lll-winken!/                            PaBell:  (415) 788-3904
       USNail:  KKSF / 77 Maiden Lane /  San Francisco CA 94108

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      25 May 1989 1137-PDT (Thursday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        mcvax!prlb2!kulcs!stephan@uunet.uu.net  (Stephan Biesbroeck)
Cc:        almquist@jessica.Stanford.EDU, tcp-ip@sri-nic.arpa
Subject:   Re: Dividing Class B number in subnets, Routing Problem
Stephan,
> In Comer's book "Internetworking with TCP/IP", there is a paragraph
> about routing with subnets (16.10 p.202) : about the routing table :
> "each entry contains one additional field that specifies the subnet mask
> used with the network in that entry:
>      (subnet mask, network addreess, next gateway)
>
> !!BUT, in a lot of implementations (UNIX BSD 4.3, SunOS, ...), there is
> no place for a subnetmask for each entry in the routing table. 
> The subnet mask is only specified for the interface.

	Hosts don't need to know anything about subnets other than the
subnet masks of any directly connected subnets.  Therefore, a subnet
mask per interface is fine for hosts (unless you run subnets with
different subnet masks on the same cable).

	Routers, on the other hand, have a lot more problems when a
network uses more than one subnet mask.  Traditionally, IP routing
protocols have not included subnet masks in routing updates, though this
is changing.  Traditionally, IP routing software has assumed that any
net has a single subnet mask.  This is also changing.

	The description in Comer's book reflects current theory, but
multiple subnet masks on a single network is an area where current
practice has not yet caught up with the theory.  It is only fairly
recently that the Internet protocol powers that be have come to
seriously address the issue.  And yes, it can work, and will be part of
future TCP/IP standards.

	However, unless you really enjoy being on the leading edge, I
would recommend that you stick to a single subnet mask for your network.
Make each subnet fairly small (7 or 8 bits of host field), and just give
out more than one subnet number to larger departments.

						Philip

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 04:59:07 GMT
From:      hagiwara@ws.sony.junet (Takashi Hagiwara)
To:        comp.protocols.tcp-ip
Subject:   RFC:"TCP/IP over HDLC" is available ?

Does anyone know that the status of the RFC "TCP/IP over HDLC (LAPB)" ?
Thank you very much in advance.
					
				Takashi Hagiwara
				(Hagiwara%WS.Sony.Juent@UUNET.UU.NET)
=======================================================================
Workstation Div.  Supermicro Systems Gp.  Sony Corporation 
=======================================================================

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 May 89 10:14:16 EDT
From:      Nick Felisiak <nick@spider.co.uk>
To:        craig <@spider.co.uk:craig@nnsc.nsf.net>
Cc:        tcp-ip <@spider.co.uk:tcp-ip@sri-nic.arpa>
Subject:   re: SO_KEEPALIVE considered harmful?
> 
> 
> > I have a random question that I hope this illustrious audience can answer
> > definitively for me (or else point me to a definitive source).  Is the BSD
> > notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to
> > the TCP specification?  If so, is its use to be encouraged?  Specifically,
> > it has been suggested that in the X Window System world, X libraries
> > should automatically be setting SO_KEEPALIVE on connections to X servers.  Is this
> > a reasonable thing to do?
> 
> Oh what fun!  Keepalive wars return....
> 
> Well, I'm a firm hater of keep-alives, although Mike Karels has persuaded
> me that in the current world they are a useful tool for catching clients
> that go off into hyperspace without telling you.  I have lots of fellow
> travellers (actually, I'm probably a fellow traveller with Phil Karn,
> president of the "I hate keep-alives" party), witness the current host
> requirements text, which is appended.

[deleted for brevity]

We have added a couple of configuration options to our TCP package which
allows the system administrator to supress keepalive on specified subnets.
This is particularly useful for (public, chargeable) X.25 connected interfaces
where the keep-alives may be the only thing holding a connection open for
a long time.  In this way, an application may turn on keepalive and get it
for local (free) net connections but not for remote (expensive) ones.

No flames about layering, please!

Nick Felisiak			nick@spider.co.uk
Spider Systems Ltd		+44 31 554 9424
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 May 89 13:04:25 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        barmar@think.com
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: SO_KEEPALIVE considered harmful?

>>It is worth adding that the excessive use of keepalives has removed a
>>feature that used to be in TCP and has been recently re-documented by
>>Bob Braden:  TCP used to be remarkably robust against temporary
>>outages.  If you were willing to wait, so was TCP.  Now, an outage of
>>a very short time -- on some implementations, as short as 1-2 minutes --
>>will abort the connection.
> 
> I dispute this claim.  TCP is only robust against temporary outages if
> you don't try to use the connection during that period.  For instance,
> if I'm using telnet, the connection will stay alive during outages if
> I don't type anything to the client or the host doesn't try to send
> any output.  If either end tries to use the connection, and the outage
> is longer than the TCP acknowledgement timeout, then the connection
> will die.  If I happen to know that the network is having trouble I
> won't type anything, but how often is this the case?  What it mostly
> means is that a temporary outage after I go home won't break my
> connections.

... or a connection that encounters a temporary outage during lunch
or while you are working in another window.

In fact, telnet is one of the cases where I really hate keep-alives.
I used keep a half-dozen telnet connections suspended from various
windows on my workstation most of the day, and flit from one machine
to another as work dictates.  NFS has radically reduced my need to do
this, but I still keep three telnet connections around all the time.
(Some last for weeks of intermittent use).  And I don't care if the
gateway was down last night, or during lunch time...

Craig
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 May 89 13:32:04 PDT
From:      braden@venera.isi.edu
To:        barmar@think.com, tcp-ip@sri-nic.arpa
Subject:   Re: SO_KEEPALIVE considered harmful?

	I dispute this claim.  TCP is only robust against temporary outages if
	you don't try to use the connection during that period.  For instance,
	if I'm using telnet, the connection will stay alive during outages if
	I don't type anything to the client or the host doesn't try to send
	any output.  If either end tries to use the connection, and the outage
	is longer than the TCP acknowledgement timeout, then the connection
	will die. 
	
Barry,

Sorry, but Dave Crocker is perfectly correct.  The behaviour that you
describe is a property of many current-generation LAN-oriented TCP's
[a transparent euphemism], but not of the original research TCP's that
were WAN-oriented ... nor even of a TAC.  A host implementation that
follows the Host Requirements RFC can behave like a TAC for Telnet
connections: tell the user when it is retransmitting excessively, but DO
NOT CLOSE the connection.  Let the user decide when to give up.  I
don't think we users should accept anything less of our communication
software.

Bob Braden
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 May 1989 13:35:14 PDT
From:      Mark Crispin <MRC@CAC.Washington.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Keepalive madness!
     Now that I've had a few more minutes to think it over, I think that Barry
Margolin's suggestion is the right one, and it should go into the host
requirements RFC.  We could make the rate less often (e.g. 5 minutes) and
require that the retransmission period be a certain minimum (24 hours).  In
return, application-level timeouts can be banned except for administrative
purposes (e.g. a site that limits ANONYMOUS FTP access to 30 minutes).

-- Mark --

-------
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 May 89 19:26:46 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        barmar@think.com, tcp-ip@sri-nic.arpa
Subject:   Re: SO_KEEPALIVE considered harmful?
THe issue of aborting a connection, due to a retransmission timeout, is the choice of the application.  Telnet could, as easily, decide to
keep trying.

Dave
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 13:24:54 GMT
From:      spurgeon@SIRIUS.CC.UTEXAS.EDU (Charles Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Small TTL values evaporate in large networks

>	Was there any evidence that the hop that dropped the packet
>after its TTL expired informed the source of its action?
The folks who originally saw the problem reported ICMP messages, so
I guess the answer is ``yes.''

Running ``traceroute'' gave us a fairly good set of replies as well,
although a trace of the route to ``life.ai.mit.edu'' showed 15 hops to
the last gateway seen, but only 13 hops back.  

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 14:08:19 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: subnet mask problem

In article <6200023@hpindda.HP.COM> tozz@hpindda.HP.COM (Bob Tausworthe) writes:

>However, because the algorithm for using masks is to perform a logincal AND 
>and test for equality, technically 255.255.0.255 could be used as a mask.
>Or could it?
 
>1) is a mask such as 255.255.0.255 even legal (i.e. conform to specifications)

	From RFC 950 (p6):

:      For example, on a Class B network with a 6-bit wide subnet field,
:      an address would be broken down like this:
:
:                           1                   2                   3
:       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |1 0|        NETWORK            |  SUBNET   |    Host Number    |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:      Since the bits that identify the subnet are specified by a
:      bitmask, they need not be adjacent in the address.  However, we
:      recommend that the subnet bits be contiguous and located as the
:      most significant bits of the local address.

	So yes it is legal, but no it is not a good idea per the
recommendation.  You may even cause serious network problems due to bugs
in some vendors implimentations.  A while back, VAX's managed to send a
mangled subnet mask in reply to an Address Mask ICMP which resulted in
interesting effects in SUN systems.  It even resulted in a new term in
our vocabulary - Broadcast Storm :-).

	Some vendors of tcp/ip code for PC's (Hi FTP) specify the subnet
in their configuration as "n" bits, where n is the number of bits in the
subnet field.  This software obviously is only going to work where the
subnet mask is contiguous and adjacent to the network address.  The
alternative to all of this is proxy arp, where these hosts don't even
know they are subneting.  The subneting is handled and hidden by your routers.
I don't know of ANY routers that will handle obscure subnet like what you're
asking about though, but that certainly doesn't mean there aren't any!  I won't
get into any arguments over who is broke or who is supporting what
recommendations, after all we still got vendors out there that don't even
support subnetting outside of proxy arp!

---
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 14:17:50 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: KeepAlive

I suppose that if you were using a TELNET connection to a remote host, and
you really cared to detect that the network failed, you could periodically
have your TELNET client send TELNET  NOP sequences on the connection.  If the
remote host crashed or the path disappeared, this would cause the otherwise
idle TCP connection to start retransmitting the TELNET NOP.

Of course, I really only care that the network is working or not if I'm trying
to get work done.  In that case, the connection isn't idle and all this is moot.

Louis Mamakos
Univ of Maryland

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 14:56:24 GMT
From:      dsmith@oregon.uoregon.edu (Dale Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  sendmail hanging during SMTP session

While we are on the subject of mail, is anyone else having terrible
trouble delivering mail to the UK? I have have had consistent problems
for some time now (6 weeks?).  I ignored it for awhile, but this
discussion got me to poking about and it looks like someone between me
and nsfnet-relay.ac.uk is dropping packets longer than 500 bytes or so. 
Note that the packets are not getting fragmented, they are getting
dropped.

Now, I could crank down the MTU on my mail host, but I also use it for
all kinds of other things and that would kill me for performance.  Any
advice? Pointers? Anyone who has no trouble willing to act as a mail
forwarder for me for .uk mail?

At the end of this message is a traceroute between myself and
nsfnet-relay.ac.uk. (128.86.8.6).

Thanks,

Dale Smith
Asst Dir of Network Services	Internet: dsmith@oregon.uoregon.edu
University of Oregon		BITNET: dsmith@oregon.bitnet
Computing Center		UUCP: ...hp-pcd!uoregon!dsmith
Eugene, OR  97403-1212		Voice: (503)686-4394

----------------------------------------------------------------------
hogg# traceroute 128.86.8.6
traceroute to 128.86.8.6 (128.86.8.6), 30 hops max, 38 byte packets
 1  uo-gw.uoregon.edu (128.223.20.1)  20 ms  0 ms  20 ms
 2  192.33.18.10 (192.33.18.10)  500 ms  200 ms  180 ms
 3  192.31.215.10 (192.31.215.10)  560 ms  560 ms  380 ms
 4  129.101.101.10 (129.101.101.10)  1260 ms  580 ms  980 ms
 5  192.31.216.10 (192.31.216.10)  1000 ms  640 ms  660 ms
 6  192.35.180.3 (192.35.180.3)  700 ms  2500 ms  2020 ms
 7  129.140.70.14 (129.140.70.14)  400 ms  400 ms  460 ms
 8  129.140.71.6 (129.140.71.6)  440 ms  1200 ms  460 ms
 9  129.140.81.7 (129.140.81.7)  500 ms  740 ms  480 ms
10  129.140.72.17 (129.140.72.17)  560 ms  1100 ms  740 ms
11  * * *
12  ford-gateway.csc.org (128.121.54.73)  600 ms  680 ms  580 ms
13  128.121.54.78 (128.121.54.78)  580 ms  740 ms  540 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * NSFNET-RELAY.AC.UK (128.86.8.6)  1600 ms  1660 ms

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 16:32:31 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

In article <8905250638.AA21706@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>It is worth adding that the excessive use of keepalives has removed a
>feature that used to be in TCP and has been recently re-documented by
>Bob Braden:  TCP used to be remarkably robust against temporary
>outages.  If you were willing to wait, so was TCP.  Now, an outage of
>a very short time -- on some implementations, as short as 1-2 minutes --
>will abort the connection.

I dispute this claim.  TCP is only robust against temporary outages if
you don't try to use the connection during that period.  For instance,
if I'm using telnet, the connection will stay alive during outages if
I don't type anything to the client or the host doesn't try to send
any output.  If either end tries to use the connection, and the outage
is longer than the TCP acknowledgement timeout, then the connection
will die.  If I happen to know that the network is having trouble I
won't type anything, but how often is this the case?  What it mostly
means is that a temporary outage after I go home won't break my
connections.

TCP's robustness is still a good idea.  It's nice to be able to swap
Ethernet cables without causing all the network connections to die.
But in my experience (which, I admit, isn't all that extensive), any
connection that dies for more than a minute or two probably isn't
going to come back.

What I mostly care about, though, is that the other end definitely has
reinitialized, e.g. it has crashed and been rebooted.  If it's a
telnet server that crashed I can do this by typing into the client,
which will provoke a reset, and the client will abort.  But if it's
the telnet client or an X server that died, there's often no way to
force the other end to try to send something so it will get a reset.

I think the right solution is a compromise.  What's needed is a way to
send a segment with infinite (or near-infinite, e.g. hours or a day)
retransmissions and slow retransmit rate (one to two minutes).  This
would allow idle connections to stay up across most network failures,
but they will die within a minute or so of the other end rebooting.
And, of course, it should be optional, so that applications that
perform frequent output of their own need not compound their network
use (although since keepalives need only be sent when there are no
normal packets in the retransmit queue, any application whose output
rate is higher than the keepalive rate will never invoke the keepalive
mechanism).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 18:14:35 GMT
From:      zdwcv@dcatla.UUCP (Wm. C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet mask problem

In article <6200023@hpindda.HP.COM> tozz@hpindda.HP.COM (Bob Tausworthe) writes:
>
>1) is a mask such as 255.255.0.255 even legal (i.e. conform to specifications)
>
>2) does anybody know of a network user whose mask is of the form above.
>
>			     tozz@hpda.hp.com


RFC950 clearly states that subnet bits need not be contiguous. However, I 
have not seen any networks that have been configured to use non-contiguous
masks. 

I have been looking at a situation where a host sends a bogus ICMP mask 
reply. The device who is looking to resolve his network mask sees this
reply and trusts it. This device then can't talk to his own local network,
because he has accepted a bogus network mask. A human looking at address
masks can probably decide whether or not a particular mask is bogus or not.
For instance, a mask reply on a class C network of 101.214.1.77 is obviously
bogus. Is there an algorithm for determining whether to trust a mask response?


The obvious solution to this problem{is to shoot the person who wrote 
the code that returns the bogus mask  but this is not very  pratical (|-)).

What I would like to do is use some code that throws away the obviously 
bad responses. Is there an algorithm in use to do this ?


Bill VerSteeg

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 18:37:00 GMT
From:      almquist@JESSICA.STANFORD.EDU (Philip Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Dividing Class B number in subnets, Routing Problem

Stephan,
> In Comer's book "Internetworking with TCP/IP", there is a paragraph
> about routing with subnets (16.10 p.202) : about the routing table :
> "each entry contains one additional field that specifies the subnet mask
> used with the network in that entry:
>      (subnet mask, network addreess, next gateway)
>
> !!BUT, in a lot of implementations (UNIX BSD 4.3, SunOS, ...), there is
> no place for a subnetmask for each entry in the routing table. 
> The subnet mask is only specified for the interface.

	Hosts don't need to know anything about subnets other than the
subnet masks of any directly connected subnets.  Therefore, a subnet
mask per interface is fine for hosts (unless you run subnets with
different subnet masks on the same cable).

	Routers, on the other hand, have a lot more problems when a
network uses more than one subnet mask.  Traditionally, IP routing
protocols have not included subnet masks in routing updates, though this
is changing.  Traditionally, IP routing software has assumed that any
net has a single subnet mask.  This is also changing.

	The description in Comer's book reflects current theory, but
multiple subnet masks on a single network is an area where current
practice has not yet caught up with the theory.  It is only fairly
recently that the Internet protocol powers that be have come to
seriously address the issue.  And yes, it can work, and will be part of
future TCP/IP standards.

	However, unless you really enjoy being on the leading edge, I
would recommend that you stick to a single subnet mask for your network.
Make each subnet fairly small (7 or 8 bits of host field), and just give
out more than one subnet number to larger departments.

						Philip

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 19:09:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Port question


::Written 11:17 pm  May 23, 1989 by toddpw@tybalt.caltech.edu:
::
::In article <364@toro.UUCP> nick@toro.UUCP (Nicholas Jacobs) writes:
::>In RFC 1010, there is a list of officially defined ports used by TCP
::>(and by UDP wherever possible). I am writing a server process which
::>hangs on a "well-known" port which can supply both the official ports
::>(given a port name or number) and to which locally defined ports can be
::>added to dynamically (thus programs can ask this process to generate
::>new port numbers).
::>
::>I have 2 questions:
::>	1) Is this service already defined (and thus I should simply
::>	   mimic its behavior)?
::>	2) Failing that, is there a port that is recommended for this
::>	   service (I am planning on using IPPORT_RESERVED+1)?
::
::1) yes, it's in RFC 1078 (TCPMUX).
::2) i'm not sure, see 1078.
::
::one thought on 1078 as I remember it: using TCP for a simple transaction like
::the port server is overkill when using UDP would require a simple two packet
::exchange process.
::
::Has anyone actually implemented something like this or do we have to wait 
::until BSD does it?
::
::Todd Whitesel
::toddpw @ romeo.caltech.edu
::toddpw @ caltech.bitnet
::toddpw @ CITDEIMO

This brings up that problem that RFC1078 in almost impossible to understand
unless you already know what it does. It says "then the service begins" --
but is it still on Port 1? Or does the service implicitly set up a different
port number? Does this mean only one thing can be happening on Port 1 at any
time? Sounds like a shabby multiplexer if it only multiplexes one thing at a
time....


-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 20:25:39 GMT
From:      MRC@CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?


     I like Barry Margolin's suggestion a lot.  I am responsible for several
servers which have autologout timers *solely* to handle the case of a client
getting rebooted with no mechanism for the server to get a reset.  It has been
shown to be virtually impossible to pick a timer value short enough to be of
use (particularly if a resource is locked up while the server lives) yet long
enough to live across some of the delays and temporary outages we see on the
operating network.

-- Mark --

-------

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 20:35:14 GMT
From:      MRC@CAC.WASHINGTON.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Keepalive madness!


     Now that I've had a few more minutes to think it over, I think that Barry
Margolin's suggestion is the right one, and it should go into the host
requirements RFC.  We could make the rate less often (e.g. 5 minutes) and
require that the retransmission period be a certain minimum (24 hours).  In
return, application-level timeouts can be banned except for administrative
purposes (e.g. a site that limits ANONYMOUS FTP access to 30 minutes).

-- Mark --

-------

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 May 89 03:44:00 PDT
From:      cire|eric <cire@cisco.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Token Ring Mac Addresses



I and some of my colleagues have been working with various protocols
running across Ethernet/IEEE 802.3 and Token Ring.  Because of the different
transmission orders we've run into an interesting problem of integrating
networks consisting of these two media.  I'm wondering if others out
there have run into the problem and what if anything has been done.  In
particular I'm interested in any established conventions set by oh DEC
or perhaps Xerox.

On Ethernet and IEEE 802.3 media data is transmitted MSByte to LSByte but
the first bit transmitted is the least significant.  On Token Ring
media the bytes are shipped out in the same order but the transmission
starts with the most significant bit.  In either case the very first
bit transmitted is the Individual/Group (multicast) bit and the next
bit is the Universal/Local address administration bit.

If for example I'm working with DECNet I would have the Ethernet address
AA00.0400.06CC assigned to one of my nodes.  If this address were used
on a Token Ring it would be multicast.  One possibility is to swap each
byte.  Thus the above address becomes 5500.2000.6033.  Perhaps that is why
AA was chosen.  Similar problems present themselves for XNS.

Any thoughts will be appreciated.  Please mail directly to me and I will
summarize to the net.  Please do not respond directly to this list.  It
already deal with a lot of traffic.

-c
cire|eric

Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 22:18:05 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

In the context of crashes/reboots, the TCP Initial Sequence Number magic
is SUPPOSED to save you from "embarrassment" (or so it says here).

In the context of Telnet, periodic phoney traffic is completely counter to
the desire/necessity for certain Hosts to abort inactive connections (lest,
e.g., a terminal be borrowed by an unauthorized user when the authorized
user broke coffee too long)--unless, of course, such traffic is never "seen"
by the relevant timer-outer.

    cheers, map
    Past President, IHK-A's
    (unless Phil Karn started agitating against 'em before I wrote
    what became p. 151 of The Book)
-------

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 22:33:30 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.super,comp.unix.cray
Subject:   Re: Benchmarking NFS, X-windows and TCP/IP generally

In article <5362@ditmela.oz>, smart@ditmela.oz (Robert Smart) writes:
> ... Attempts to benchmark the performance of TCP/IP implementations is
> also of interest. ...
> 
> Bob Smart <smart%ditmelb.oz.au@uunet.uu.net> or <uunet!munnari!ditmelb!smart>

In order to reduce peace and tranquillity, and to spread the pernicious
single-number-benchmark disease endemic to CPU architecture and system
implementation discussions, we are considering including the source to a
TCP benchmark in a future release.  This would allow everyone to have
numbers to support their wrong opinions.  It would also allow customers to
make insignificantly more rational decisions.  For example, some still
think that an application-process-to-process TCP through-put of
200KBytes/sec over an unloaded ethernet between real computers is more
than slow, or that 350KB/sec is as much as mediocre.  Or that 20 1500Byte
UDP packets per second is a significant system load.

The idea is to allow vendors, customers, and other interested parties to
try the same simplistic test on lots of machines.  Dhrystones are bad,
wrong, and so forth, but they seem a lot better than the current lack of
the state of the art in networking.  It can be argued that the popularity
of CPU benchmarks in recent years has caused faster systems to appear.
The benchmarks have made statements like "my system is faster" somewhat
testable, and required a little more creativity from sales critters.

If we can get permission from the author, we are considering Mike Muuss's
TTCP.

Is there a better choice?  Other comments?

Vernon Schryvers
Silicon Graphics
vjs@sgi.com

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 22:40:49 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

>>It is worth adding that the excessive use of keepalives has removed a
>>feature that used to be in TCP and has been recently re-documented by
>>Bob Braden:  TCP used to be remarkably robust against temporary
>>outages. [...]
 
>I dispute this claim.  TCP is only robust against temporary outages if
>you don't try to use the connection during that period.

TCP becomes quite robust against all outages (whether or not the
connection is idle) once you make a very simple change: get rid of TCP
level timeouts!

I feel very strongly that TCP should *never* just give up on its own
accord; that decision belongs to the application. And, in the event the
application is an interactive one, the decision to abort should be left
to the human user. If he's willing to wait, why shouldn't the system let
him? (The only case when TCP should abort a connection on its own is
when it has clear proof that the other end has crashed, i.e., by
receiving a valid RST.)

Users of my TCP/IP package on amateur packet radio occasionally report
cases of FTP transfers that resume automatically after network outages
lasting for *days* (e.g., those due to crashes of network nodes in
remote locations that require manual resets).  They are most happy to do
without TCP give-up timers, as long as TCP backs off its retransmissions
to avoid channel congestion.

Phil

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      25 May 89 22:53:00 GMT
From:      barmar@THINK.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?


    Date: Thu, 25 May 89 13:32:04 PDT
    From: braden@venera.isi.edu


    Sorry, but Dave Crocker is perfectly correct.  The behaviour that you
    describe is a property of many current-generation LAN-oriented TCP's
    [a transparent euphemism], but not of the original research TCP's that
    were WAN-oriented ... nor even of a TAC.  A host implementation that
    follows the Host Requirements RFC can behave like a TAC for Telnet
    connections: tell the user when it is retransmitting excessively, but DO
    NOT CLOSE the connection.  Let the user decide when to give up.  I
    don't think we users should accept anything less of our communication
    software.

RFC-793, which defines TCP, says, "If data is not successfully delivered
to the destination within the timeout period, the TCP will abort the
connection."  I can believe that the Host Requirements RFC changes
"abort the connection" to "signal an error", but this contradicts your
claim that original TCPs were more forgiving.

Also, how is a TELNET server or xterm client supposed to tell the user
when it is retransmitting excessively?  Its communication path to the
user is the failing connection.  Sure, it could put something in a
system log or write a message to the system console, but how is the
operator (if there is one) supposed to know why the remote machine isn't
responding?

                                                barmar

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 May 89 06:28:24 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        jupiter!karn@bellcore.com, tcp-ip@sri-nic.arpa
Subject:   Re: SO_KEEPALIVE considered harmful?
Phil,

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

Dave
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 02:26:46 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

THe issue of aborting a connection, due to a retransmission timeout, is the choice of the application.  Telnet could, as easily, decide to
keep trying.

Dave

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 04:13:52 GMT
From:      pa2183@sdcc15.ucsd.edu (John Clark)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC-NFS VAX and 3-Com (a marriage made in H***)


	I am trying to get info and experiences in hooking up the
	following components.

		A PC network using 3-Com's 3-Plus and 3-Server-3
		network system.

		A micro-VAX 3600 system.

	I would like to have a seamless connection from the PC's to
	the vax, i.e. mount vax filesystems as PC drives. This would
	suggest using NFS. Is it possible to get PC-NFS, VAX, and
	the 3-Com stuff to all play in the same band. Or must I junk
	the 3-Com server and put NFS everywhere?

	Thanks John Clark

	pa2183@sdcc15.ucsd.edu

	Disclamer: I didn't buy the 3-Com system I just inherited
	it.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 May 89 10:57:55 EDT
From:      "Jay Elinsky" <ELINSKY%YKTVMX.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   sendmail hanging followup
James B. VanBokkelen writes:

>              ...I have some recent experience with IBM VM systems which
>request 1460 byte MSS regardless of whether the connection is on the local
>subnet, or routed via a gateway. ...

Actually, our VM and MVS TCP/IP programs let you specify the MSS separately
for each route, if desired.  So if some networks are reachable through
gateways that are known to accept large packets, you can tell our TCP to
use large packets for better performance and efficiency. (TCP still respects
the MSS offered by the other end, of course).  Or you can specify the default
size of 576, or even 512 like FTP Software's TCP does, if you aren't sure
that some or all routes can handle larger packets.  If James' recent
experience with an IBM VM system is the one that I remember, the customer's
TCP/IP configuration did specify a larger size for the route through ARPAnet.
I suggested that they use the default size for the route, and I assume that
that fixed the problem.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 07:32:50 GMT
From:      harish@guille.ece.orst.edu (Harish Pillay)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Running Vega VGA+WD8003+SU-PC/IP

Hello netters,

    I am trying to install a WD8003E net card on a Wyse286 AT to run 
    Stanford University's PC/IP version 3.0.  So far it hasn't been a 
    complete success.
    
    The system has the following:

     a) Wyse pc286 with 640 KB ram, pheonix bios 2.75G, 10MHz clock
     b) Vega VGA card (version 1.47): switch - NFFFNF (123456, N=on, F=off)
     c) Microsoft bus mouse: Primary Inport, Int 2
     d) Harddisk controller card (40 MB)

    I've set up the net card as follows:

     a) I/O = 300h
     b) Wait-state set as PC AT (8-16MHz) - W1's pin 2 open
     c) IRQ 3
     d) Thin Ethernet (W4 closed)
     e) W3 set to thin ethernet 
     f) loaded net_wd.exe in config.sys after customizing it

    After booting up, running tcpip.exe hangs the machine (it's well hung, 
    i.e. it's not warm-bootable).  I know the card works (tested on our 
    other machines, not all true-blue ATs, but works on all of them).
    I set the RAM buffer address to D000, D400, D800 and DC00 and none
    worked.

    When I took out the Vega card, set the W3 to all open (ie standard
    ethernet), and used a monochrome card, SU-PC/IP worked (ie tcpip.exe
    ran).  I used an EGA card from an IBM AT and that configuration 
    worked also.  All the RAM buffer addresses above worked.

    I have successfully used an Ungermann Bass UBNet card with the 
    Vega card. So I know that net cards can be used on the pc.
    Setting the W3 closed and using either the monochrome or EGA card,
    left the machine well hung when tcpip.exe was run.

    There obviously is a conflict between the Vega card and WD8003E 
    though I just can't figure what it is.  I've tried all reasonable 
    jumper settings on both boards to no avail.  I'm currently assuming 
    that there is no problem with the Wyse motherboard.  Maybe I'm wrong 
    here.  I don't have another Wyse machine to test on.

    I need to use the Vega VGA card and for where the pc is going to be
    used, there is only a thin ethernet connection.  I can't use the 
    other machines at this location because of logistics.

    Has anyone encountered this situation, or am I the only one?

    Thanks.

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

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 May 89 11:44:04 EDT
From:      heker@jvnca.csc.org (Sergio Heker)
To:        tcp-ip@sri-nic.arpa
Cc:        jvncnews@jvnca.csc.org, jvnctech@jvnca.csc.org
Subject:   JvNCnet funding
To the internet community:

The following message was sent by Dr.Doyle Knight, President of the Consortium
for Scientific Computing (CSC).  The John von Neumann National Supercomputer
Center (JvNC) is a project of CSC.


						-- Sergio
----

> From KNIGHT1D@jvncc.csc.org Fri May 26 11:23:00 1989
> Received-Date: Fri, 26 May 89 11:22:58 EDT
> Date: Fri, 26 May 89 11:20 EDT
> From: KNIGHT1D@jvncc.csc.org
> Subject: Include this in your message today
> To: HEKER@jvnca.csc.org
> X-Vms-To: HEKER
> 
> From:	IN%"steve@note.nsf.gov"  "Stephen Wolff" 26-MAY-1989 10:15
> To:	KNIGHT1D@JVNCC.CSC.ORG
> Subj:	Re: Incident with NYSERNET
> 
> Return-path: <steve@note.nsf.gov>
> Received: from note.nsf.gov by jvncc.csc.org via TCP; Fri May 26 10:15 EDT
> Date: Fri, 26 May 89 9:13:41 EDT
> From: Stephen Wolff <steve@note.nsf.gov>
> Subject: Re: Incident with NYSERNET
> To: KNIGHT1D@JVNCC.CSC.ORG
> Message-ID:  <8905260913.aa25305@note.nsf.gov>
> 
> 
> Doyle -
> 
>   This note will confirm your earlier conversations with this office.
>   
>   NSF has made no plans to shut down JVNCNET.
>   
>   As you know, the JVNCNET Phase II award of $500,000 was made to CSC on
>   March 13th of this year; it is the first part of a continuing commitment by
>   the Foundation of nearly $1.5 million to JVNCNET extending into 1991.
>   
>   -s
>   
	
-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 10:44:00 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Token Ring Mac Addresses




I and some of my colleagues have been working with various protocols
running across Ethernet/IEEE 802.3 and Token Ring.  Because of the different
transmission orders we've run into an interesting problem of integrating
networks consisting of these two media.  I'm wondering if others out
there have run into the problem and what if anything has been done.  In
particular I'm interested in any established conventions set by oh DEC
or perhaps Xerox.

On Ethernet and IEEE 802.3 media data is transmitted MSByte to LSByte but
the first bit transmitted is the least significant.  On Token Ring
media the bytes are shipped out in the same order but the transmission
starts with the most significant bit.  In either case the very first
bit transmitted is the Individual/Group (multicast) bit and the next
bit is the Universal/Local address administration bit.

If for example I'm working with DECNet I would have the Ethernet address
AA00.0400.06CC assigned to one of my nodes.  If this address were used
on a Token Ring it would be multicast.  One possibility is to swap each
byte.  Thus the above address becomes 5500.2000.6033.  Perhaps that is why
AA was chosen.  Similar problems present themselves for XNS.

Any thoughts will be appreciated.  Please mail directly to me and I will
summarize to the net.  Please do not respond directly to this list.  It
already deal with a lot of traffic.

-c
cire|eric

Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 11:43:56 GMT
From:      db@helium.east.sun.com (David Brownell)
To:        comp.protocols.tcp-ip
Subject:   Re: Reconciling /etc/hosts, yp, and named?

In article <7080016@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
>/ comp.protocols.tcp-ip / melohn@ENG.SUN.COM (Bill Melohn) / May 18, 1989 /
>> In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:

	[ someone said, "Sun doesn't ** make ** you run YP" ]

>> >They do force it if you are their customer.  Their setup scripts tipically
>> >give you three choices:
>> >	1. YP server
>> >	2. YP client
>> >	3. not networked at all
>> 
>> This is misleading; the installation procedure used in the current
>> versions of SunOS allow you to choose one of the following options for
>> YP: server, master, client, or none. Independent of this choice is the
>> configuration option for network interface.
>
>I apologize.  I have only dealt with 4.0.1 on the 386i.

Actually, it's slightly misleading even on the Sun386i packaging of SunOS,
though the point that you weren't originally intended to network it without
YP is correct.  (No flames please; I really didn't like this, and this
restriction ** is ** being removed in the next release.)

The first choice is "yp master" (with extra services to maintain YP
remotely); slaves have to be set up separately.  Also, the only way a yp
master is different from a non-networked system is that the non-networked one
uses the internal loopback network for all its network traffic, not an
Ethernet ... they're both YP masters.

The reason behind this was to simplify things so that there would be just a
single straightforward way to administer things.  That's still something
that'd be great to see, but it can't be done with the existing YP protocols.
One of the main reasons is that YP doesn't have the kind of support that the
name server does, allowing multiple domains to chat with one another.  You
really ought to be able to set up a machine as a domain all by itself and
then use standard protocols to talk between domains, or to cooperatively
construct larger domains from sets of smaller ones.

I for one really look forward to using something that looks more like X.500
than YP, but that's a ways off into the future.  Even then, I suspect that
different sorts of applications will still need different ways to manipulate
their own naming/configuration data.

    David Brownell			dbrownell@sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA
    David Brownell			dbrownell@sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 12:07:40 GMT
From:      davecb@yunexus.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

In article <20761@news.Think.COM> barmar@kulla.think.com.UUCP (Barry
Margolin) writes: TCP's robustness is still a good idea.  It's nice
| to be able to swap Ethernet cables without causing all the network
| connections to die.  But in my experience (which, I admit, isn't all
| that extensive), any connection that dies for more than a minute or
| two probably isn't going to come back.  [...]

  Actually the connection might well come back: I had a crossbar switch
that timed me out every so often, assuming that I don't leave the terminal
for substantial periods without disconnecting it.  (This is silly, but not
unreasonable for a device which thinks its switching telephone voice lines).
  After I got back to the terminal controller I could then reconnect
to my process.

  Keepalives would be more secure in such a situation (anyone could
pretend to be me if the tty server disconnected), but would tend to
cause me to lose work-in-process...
  Methinks that a facility for polling a connection makes sense, as
well as one to send "reset the poll clock, if any" (keepalives redux)
would be useful.  As does Barry, I'd propose they be optional.  I'd also
propose that
	1) if one exists, so must its complement
	2) they be composed out of existing facilities, as were
	  keepalives, and
	3) they be distinguishable from any other facility (unambiguous).

--dave
  

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 13:28:24 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

Phil,

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

Dave

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 14:57:55 GMT
From:      ELINSKY@YKTVMX.BITNET ("Jay Elinsky")
To:        comp.protocols.tcp-ip
Subject:   sendmail hanging followup

James B. VanBokkelen writes:

>              ...I have some recent experience with IBM VM systems which
>request 1460 byte MSS regardless of whether the connection is on the local
>subnet, or routed via a gateway. ...

Actually, our VM and MVS TCP/IP programs let you specify the MSS separately
for each route, if desired.  So if some networks are reachable through
gateways that are known to accept large packets, you can tell our TCP to
use large packets for better performance and efficiency. (TCP still respects
the MSS offered by the other end, of course).  Or you can specify the default
size of 576, or even 512 like FTP Software's TCP does, if you aren't sure
that some or all routes can handle larger packets.  If James' recent
experience with an IBM VM system is the one that I remember, the customer's
TCP/IP configuration did specify a larger size for the route through ARPAnet.
I suggested that they use the default size for the route, and I assume that
that fixed the problem.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 15:06:47 GMT
From:      holmes@wdl1.UUCP (Randy D Holmes)
To:        comp.protocols.tcp-ip
Subject:   Re: Dividing Class B number in subnets, Routing Problem



   Stephan,
      I understand your problem, we were faced with it a while back.
      Based on our experience I recommend you avoid using different 
      sized subnets if at all possible. If you haven't already read
      RFC950 "Internet Standard Subnetting Procedure" you should.
      Here is an important point stated in the RFC

     ...
        For example, the Internet address might be interpreted as:
 
            <network-number><subnet-number><host-number>
 
         where the <network-number> field is as defined by IP [3], the
         <host-number> field is at least 1-bit wide, and the width of the
         <subnet-number> field is constant for a given network.  No further
         structure is required for the <subnet-number> or <host-number>
         fields.  If the width of the <subnet-number> field is zero, then
         the network is not subnetted (i.e., the interpretation of [3] is
         used).
     ...

     In other words what you want to do is non-standard.

     Having said that, if you still want to go ahead, heres what we 
     did. Our class B network uses 3-bit subnetting at the top level,
     2 of those subnets are further subnetted to 8-bit subnets. Because
     of the RFC950 requirement to have subnet widths fixed for a given
     network, we were NOT able to do this using one gateway (we use
     cisco gateways). We have one gate way configured to do 3-bit
     subnetting, and one to do 8-bit subnetting, they are separated by
     a serial link and there are more gateways on both sides of this link.
     Immediate problems arise if you try to do dynamic routing. All the
     gateways on the 8 bit side send routing info for all the 8-bit 
     subnets they know about, but the 3-bit gateway just sees this as
     several routes to 2 3-bit subnets, often with the routing information
     conflicting. i.e. an 8-bit subnet which is 2 hops from the 3-bit gateway
     looks like the SAME subnet which is one hop away, and both routes use the
     same first hop. Also, and I'm a little less clear on this one, the
     3-bit gateway and the 8-bit gateway seem to argue over who has the correct
     subnet mask, and eventually ignore each other. Going the other way,
     hosts 128.5.192.2, and 128.5.193.2 are both on 3-bit subnet 128.5.192,
     however all of the 8-bit subnetted gateways think these are separate
     8-bit subnets, and DON'T know how to get to 128.5.193.2. 
     Our final solution was to turn off the dynamic routing on the 3-bit 
     gateway, and make all of its routes static. We also had to enter 32
     static  routes on the 8-bit gateway for EACH 3-bit subnet in use on the
     other side of the 3-bit subnet gateway.

     The bottom line is, we are working, and working quite well. But
     because we are doing things in a non-standard way we have an
     administrative headache on our hands, and a large portion of
     our down time has been attributed to this problem. Also we only
     have 2 sizes of subnets, you seem to propose at least 3. I should
     also mention that steps are being taken to eliminate this kludge in
     our network.

     I am sending this message not as a solution to your problem, but
     as an argument against doing what you propose.

     I hope this helps.


     Randy    holmes@wdl1.fac.ford.com

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 15:07:53 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

Sigh.  The Tenex TCP of ages ago certainly allowed the user timeout to
be set infinite, by specifying a value of 0.  If there are older ones
than that, I don't think they can be much older!  I think the claims
about the old TCP's having this capability are grounded in fact.

However, it just may be that Bob & Dave fell into a trap here.  I
almost wrote the message they both wrote, but went off to check RFC 793
and I did not locate any text stating that an RFC 793 conformant TCP
necessarily has to provide any particular range of user timeout
settings, except that the default is five minutes.  And I was just SURE
it was there.  Oops.  The designers probably had it so firmly in their
minds from prior discussions that they forgot to write it down explicitly.

THAT sounds like a job for **!!HOST REQUIREMENTS MAN!!**

However**2, TCP is ALSO specified in MIL-STD-1778, and it DOES have an
explicit requirement for the TCP to allow the upper layer to choose
whether a user timeout should result in a notification to the upper
layer or should cause the TCP to abort the connection.  This is
referred to in many places but the most coherent description is in
section 9.2.9.  For your convenience, I've appended it below.

Sad to say, there are (other) inconsistencies within the MIL-STD and
between it and the RFC.  The MIL-STD, section 9.4.4.7, sets the default
timeout as 120 unidentified units.  Obviously 24ths of a minute... etc.

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

-------

[MIL-STD-1778]

9.2.9  ULP timeout and ULP timeout action.  The timeout allows a ULP to
set up a timeout for all data submitted to the TCP entity.  If some
data is not successfully delivered to the destination within the
timeout period, the state of ULP_timeout_action is checked.  If
ULP_timeout_action is 1, the TCP entity will terminate the connection.
If it is 0, the TCP entity informs the ULP that a timeout has occurred,
and then resets the timer.  The timeout appears as an optional
parameter in the open request and the send request.  Upon receiving
either an active open request, or a SYN segment after a passive
request, the TCP entity must maintain a timer set for the interval
specified by the ULP.  As acknowledgments arrive from the remote TCP,
the timer is cancelled and set again for the timeout interval.  As
parameters of the SEND request, timeout and timeout_action can change
during connection lifetime.  If the timeout is reduced below the age of
data waiting to be acknowledged, the event dictated by
ULP_timeout_action will occur.  The implementor may choose to allow
additional options when informing the ULP in case of a timeout; for
example, informing the ULP only on the first timeout.

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 15:51:19 GMT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   JvNCnet II status


     Status of the JvNCnet Phase II and Network Implementation
                          May 25th, 1989
                               by
                           Sergio Heker
                     Director for Networking



The JvNC has made significant progress in the establishment of Phase 
II of the JvNCnet.  In March 1989, the NSF announced a three year 
award to the JvNC to establish JvNCnet Phase II.  Early in March 
1989, we conducted a series of meetings to inform the members 
of the JvNCnet community of the plans for development of JvNCnet 
Phase II .  These meetings were very successful.  We hosted more 
than one hundred people from academic and industrial institutions, 
as well as representatives from the National Science Foundation, 
the New Jersey Commission on Science and Technology and the New 
Jersey Department of Higher Education.  Since then the following 
progress has been made:

%	The following institutions have been connected to JvNCnet 
	Phase II:

	Rutgers University
	New Jersey Institute of Technology
	University of Medicine and Dentistry of New Jersey
	Stevens Institute of Technology
	Bell Laboratories
	Bell Core
	Princeton University
	Institute for Advanced Study
	Siemens Research
	NORDUnet
	JANET

%	The following institutions are scheduled for connection to the 	
	JvNCnet Phase II network:

	Squibb & Sons
	New York University *
	Montclair State College *
	Brown University *
	American Mathematics Society
	University of Rhode Island
	University of Pennsylvania *
	Penn State University *
	Wesleyan University *

	* presently connected to the JvNCnet network

%	More than ten additional institutions are completing contracts 	
	and will be scheduled for installation in the near future.  
%	Discussions are in progress with additional sites.
%	Maintenance agreement signed with Rochester Telephone (RCI)
 	to support the JvNCnet
%	All backbone circuits ordered and scheduled for installation in 
	June 1989
%	All Cisco routers for the BNSs ordered and received at JvNC are
 	undergoing tests
%	All the Datatel CSU/DSUs for the BNSs ordered and waiting for delivery
%	All the additional equipment for the BNSs ordered and waiting to be 
	shipped
%	Implementation meetings with RCI are being held once every two weeks
%	Operations meetings with RCI are being held once every two weeks
%	Implementation of a JvNCnet "all nodes" meeting three times a year 
	approved
%	Regional to Regional backup/backdoors being discussed with PREPnet 
	and NEARnet
%	Exploration to access other Federal Agency Networks
%	Recommendations to Case/Datatel for their CSU/DSUs have	been accepted 
	by DATATEL and will be a standard offering
%	Establishment of the Network Information Services within the JvNC 
	Network Department
%	The Network Information Center On Line (NICOL) facility to access to 
	on line network documentation such as JvNCnet documentation, RFCs, 
	IDEAS, maps, contacts, etc
%	Incorporation of two additional people to the JvNCnet staff (total
	of nine people approved, eight people are currently hired).


For more information on the JvNCnet please send mail to 
"JvNCnet-nic@jvnca.csc.org".


-----------------------------------------------------------------------------
|		John von Neumann National Supercomputer Center		    |
|  Sergio Heker				tel:	(609) 520-2000		    |
|  Director for Networking		fax:	(609) 520-1089		    |
|  Internet: "heker@jvnca.csc.org"	Bitnet:	"heker@jvnc"		    |
-----------------------------------------------------------------------------

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 16:37:51 GMT
From:      geoff@USAFA.AF.MIL (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   pcnfsd for 4.3 system

Is there a version of pcnfsd for a socket based system.  I am trying
to bring it up on my Gould (oops Encore) system.

	geoff

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 17:50:59 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: subnet mask problem



	For instance, a mask reply on a class C network of 101.214.1.77 is obviously
	bogus. Is there an algorithm for determining whether to trust a mask response?

...
	Bill VerSteeg

Bill,

The IETF Host Requirements Working Group pondered this problem, and
here is the best we could come up with (from Section 3.2.2.9 of the
Host Requirements/Communication Layers RFC draft):

    It is recommended that the host make the following "sanity
    check" on any address mask it installs: the mask MUST NOT be
    all 1 bits, and it MUST be either zero or else the 8 highest-
    order bits MUST be on.
    
Your example would in fact fail this check, but lots of bogus
masks would pass.  We too would like to know of any better ideas.

Bob Braden

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      26 May 89 23:47:25 GMT
From:      karn@THUMPER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

Dave,

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

Much of my animosity toward keepalives came from trying to make a Sun
workstation work properly over SLIP links and amateur packet radio. I
finally replaced the TCP object modules provided by Sun with ones
compiled from Van's latest TCP, which I had already edited to disable
keepalives.  Works like a charm.

At the last InterOp, I sat next to Dave Borman in a panel session on TCP
performance. Between us, we represented a "dynamic range" of about 6
orders of magnitude in TCP transfer rates (1200 bps amateur packet radio
to 500 Mbps between Crays). This is an exceptional achievement for a
single networking protocol, but it was possible only because TCP was
designed from the beginning to scale well over a wide network
performance range.

But broken mechanisms like keepalives threaten this. We need a big red
warning light that will flash whenever someone proposes to put an fixed
time interval into a protocol spec, because you can't scale protocols
that have arbitrary timers.

Phil

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      27 May 89 01:01:00 GMT
From:      barr@frog.UUCP (Chris Barr)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE considered harmful?

In support of 'no timeouts at TCP layer':

The first explanation I ever heard of TCP/IP was that it was designed 
(for DOD) to survive battle conditions where connections were expected to 
break and later be restored.

I then used someone's Telnet which broke a session after 15 minutes
without keystrokes.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      27 May 89 01:10:34 GMT
From:      budden@manta.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip,comp.sys.super,comp.unix.cray
Subject:   Re: Benchmarking NFS, X-windows and TCP/IP generally

Vern Schreyer proposed to distribute TCP/IP benchmarks to disturb
the peace and tranquility.  Not a bad idea, stirring the pot like
that, but maybe we can tune it a little...

How about distributing some sort of benchmark program that guages
degree of conformance to standard and degree of interoperability?

I agree that the traditional benchmark, that counts some isolated
speed metric, is wide of the mark and tends to trivialize arguments.
Perhaps we can ask a better question.

Rex Buddenberg

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 May 89 14:39:56 EDT
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        Mike Skrydlak <tektronix!zephyr!mikes@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  ncsa telnet (pc) ftp bug ?
What version of ftpbin and telbin are you using?

We had a similar problem here, using telbin to connect to a vax 3500 running
cmu-tek-tcp.  The problem showed up when users went to change their passwords.
The would get "invalid password" or something like that when entering the
new password. Turns out that cmu-tcp was negotiating BINARY telnet option, the
PC says 'ya, sure' but then didn't correctly implement binary EOL syntax.

The quickest fix we came up with is for telbin to say 'no binary mode' unless
connected to a 3270 type machine. (So, version 2.2C is broken, and tries binary
mode, and 2.2D says no to binary mode, but if it said yes, it'd still
be broken).

Ftpbin strips off incoming telnet options and discards them. Perhaps
(I have no idea why this would happen) your vax is sending a DO Binary option on
the ftp control channel. If the PC ignores it, and never answers,
what does the vax do?

The CRNUL option only effects what is sent to a host system when <RETURN> is pressed
on the PC keyboard while using telbin or tn3270. (2.2TN).


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 May 89 18:39:56 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  ncsa telnet (pc) ftp bug ?

What version of ftpbin and telbin are you using?

We had a similar problem here, using telbin to connect to a vax 3500 running
cmu-tek-tcp.  The problem showed up when users went to change their passwords.
The would get "invalid password" or something like that when entering the
new password. Turns out that cmu-tcp was negotiating BINARY telnet option, the
PC says 'ya, sure' but then didn't correctly implement binary EOL syntax.

The quickest fix we came up with is for telbin to say 'no binary mode' unless
connected to a 3270 type machine. (So, version 2.2C is broken, and tries binary
mode, and 2.2D says no to binary mode, but if it said yes, it'd still
be broken).

Ftpbin strips off incoming telnet options and discards them. Perhaps
(I have no idea why this would happen) your vax is sending a DO Binary option on
the ftp control channel. If the PC ignores it, and never answers,
what does the vax do?

The CRNUL option only effects what is sent to a host system when <RETURN> is pressed
on the PC keyboard while using telbin or tn3270. (2.2TN).


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
| Network Engineer       Clarkson University              (315)268-2292

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      27 May 89 21:43:45 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Port question

In article <93400022@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes:
>This brings up that problem that RFC1078 in almost impossible to understand
>unless you already know what it does. It says "then the service begins" --
>but is it still on Port 1? Or does the service implicitly set up a different
>port number? Does this mean only one thing can be happening on Port 1 at any
>time? Sounds like a shabby multiplexer if it only multiplexes one thing at a
>time....

That's like assuming that there can only be one TELNET session at a
time because it there's only one port 23.  The TCPMUX server can
handle any number of connections, because they'll each come from a
different remote host and/or remote port.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      28 May 89 02:17:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   ARP/IP-address battles

Consider what happens when an standard 4.xBSD systems receives an ARP
packet announcing its IP address and a strange etheraddress.  The system
prints one message and otherwise ignores the theft of its name.  Third
parties on the ethernet notice the new (IP,ether) pair, and redirect all
traffic for the victim to the thief.  This means that when you bring up a
machine with a duplicate IP address, you often get no messages, and things
appear to work, on the naughty machine.  Meanwhile, the victim burps and
behaves as if the rest of the world disappeared.  Eventually, as arp caches
are refilled both machines will print messages, on the order of 0.1
msg/minute.  This makes it hard for the knowledgeable to discover which
machine is the thief and hard for the uninitiated to figure out what
happened.

We are thinking of changing this in a future release of IRIX (UNIX for the
IRIS--love those AT&T lawyers who hog the real name).  The new behaviour uses
a neat hack figured out by someone here.  He has modified the arp code to
save the bogus entry in the victim's cache, and then do an ordinary
arpwhohas after a short wait.  The result is a steady stream of messages on
both consoles.  The desired end of making the damage equal for victim and
thief is achieved.  He also found that if the wait is short enough, TCP
connections tend to stay up for the victim, making it a lot easier to poke
around on BIND/YP servers for typos, or to sendmail to third parties to ask
for help.

There are two obvious questions.  Is this a No-No?  What is a reasonable
"short wait"?  For the first, I admit that it does generate a little
traffic, but know of no laws it breaks.  For the second, we have found 1
second too short, generating too many console messages.

This change is also a trivial security improvement, making it a little
harder to spoof a host, since the victim's complaints are now rather shrill.

Does anyone have any comments or suggestions?


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      28 May 89 03:14:24 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   ARP/IP-address battles

Consider what happens when an standard 4.xBSD systems receives an ARP
packet announcing its IP address and a strange etheraddress.  The system
prints one message and otherwise ignores the theft of its name.  Third
parties on the ethernet notice the new (IP,ether) pair, and redirect all
traffic for the victim to the thief.  This means that when you bring up a
machine with a duplicate IP address, you often get no messages, and things
appear to work, on the naughty machine.  Meanwhile, the victim burps and
behaves as if the rest of the world disappeared.  Eventually, as arp caches
are refilled both machines will print messages, on the order of 0.1
msg/minute.  This makes it hard for the knowledgeable to discover which
machine is the thief and hard for the uninitiated to figure out what
happened.

We are thinking of changing this in a future release of IRIX (UNIX for the
IRIS--love those AT&T lawyers who hog the real name).  The new behaviour uses
a neat hack figured out by someone here.  He has modified the arp code to
save the bogus entry in the victim's cache, and then do an ordinary
arpwhohas after a short wait.  The result is a steady stream of messages on
both consoles.  The desired end of making the damage equal for victim and
thief is achieved.  In addition, he was surprised to find that if the wait
is short enough, TCP connections tend to stay up for the victim, making it
a lot easier to poke around on BIND/YP servers for typos, or to sendmail to
third parties to ask for help.

There are two obvious questions.  Is this a No-No?  What is a reasonable
"short wait"?  For the first, I admit that it does generate a little
traffic, but know of no laws it breaks.  For the second, we have found 1
second too short, generating too many console messages.

This change is also a trivial security improvement, making it a little
harder to spoof a host, since the victim's complaints are now rather shrill.

Does anyone have any comments or suggestions?


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      28 May 1989 14:23-EDT
From:      CERF@A.ISI.EDU
To:        voder!pyramid!nsc!icldata!altos86!elxsi!beatnix!mre@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: SO_KEEPALIVE considered harmful?
When TCP was first designed, and for all subsequent versions, it was
thought inappropriate to impose any kind of semantics on the logical
connections extablished by TCP. In particular, no sense of absolute
timeout for the severing of a connection was desired. We thought that
such notions of "impatience" or "time to give up" ought to be the
choice of the upper level protocol using TCP as the basis merely for
reliable delivery.

A part of this view stemmed from the fact that the networks over which
TCP had to function, for the DoD applications we had in mind, were
potentially very unpredictable as to loss and delay. Mobile packet
radio systems had to function under jamming and radio shadow effects,
for instance. TCP never unilaterally severed connections but only
reported failure to achieve positive acknowledgement after a time
which could be controlled by the application or upper-level protocol.
It was up to the application to decide whether to sever the connection
and, even then, the choice to do so gracefully or abruptly was also
left to the application.

The use of a feature (X-level NOP) to test the liveness of a TCP
connection is consonant with the model against which the TCP was
designed. 

Vint Cerf
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      28 May 89 18:23:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

When TCP was first designed, and for all subsequent versions, it was
thought inappropriate to impose any kind of semantics on the logical
connections extablished by TCP. In particular, no sense of absolute
timeout for the severing of a connection was desired. We thought that
such notions of "impatience" or "time to give up" ought to be the
choice of the upper level protocol using TCP as the basis merely for
reliable delivery.

A part of this view stemmed from the fact that the networks over which
TCP had to function, for the DoD applications we had in mind, were
potentially very unpredictable as to loss and delay. Mobile packet
radio systems had to function under jamming and radio shadow effects,
for instance. TCP never unilaterally severed connections but only
reported failure to achieve positive acknowledgement after a time
which could be controlled by the application or upper-level protocol.
It was up to the application to decide whether to sever the connection
and, even then, the choice to do so gracefully or abruptly was also
left to the application.

The use of a feature (X-level NOP) to test the liveness of a TCP
connection is consonant with the model against which the TCP was
designed. 

Vint Cerf

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      28 May 89 20:46:15 GMT
From:      ulmo@ssyx.ucsc.edu (Brad Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: KeepAlive

> If I have a telnet connection to a host, and then the network fails,
> I would appreciate it if the remote host knew this and could
> undertake appropriate cleanup activities.

Personally as a user, I would >not< appreciate it!
I've lost work because of this, however the situation probably
deserves explaining:  I was using a CISCO terminal server,
which routed packets through two other CISCO gw machines to the
destination host and back.  Because of a fault in the routings,
the network disappeared for about 10 minutes.  I certainly lost
a lot more than I appreciated, and walked off mumbling things about
how CISCO really OUGHT to have implemented user-settable preferences
for this type of thing.

(An interesting side note:  the only successful routing I found
to the host was manually:  I telned'd to the first gw machine,
then to the second, then to the destination host -- this was the
only configuration which I could get to work, but it did!
This thank god has since been fixed.)

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      28 May 89 23:23:44 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Host Requirements

The answer is probably somewhere in the clutter in my office or residing under
some obtuse name in a indeterminate directory on disk; however, what is the
RFC number for the Host Requirements document?  If not released and/or not
available at SRI-NIC, where can I obtain a copy of the current draft?

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 May 89 07:04:24 PDT
From:      jqj@hogg.cc.uoregon.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Re: dividing class B number into subnets
>	The description in Comer's book reflects current theory, but
>	multiple subnet masks on a single network is an area where current
>	practice has not yet caught up with the theory.  It is only fairly
>	recently that the Internet protocol powers that be have come to
>	seriously address the issue.  And yes, it can work, and will be part of
>	future TCP/IP standards.

Philip Almquist provides an excellent overview of current thinking on
networks with multiple subnet masks.  One further point, though, is
that even current theory is not completely uniform.  Various different
recent RFCs reflect a different understanding of what multiple subnet
masks really means.  For example, early drafts of the OSPFIGP spec
included only a subnet length associated with each subnet route,
implying that the subnet part could be variable but must be adjacent to
the network part; the current version includes a fully general subnet
mask for each subnet.  On the other hand, RFC1101, which specifies how
subnet masks are described in the domain name system, has what to me
seems like a very strange (i.e. wrong) model of subnet masks where the
subnet mask is associated not with the subnet but with its
superordinate number space.

As a test of the complexities of multiple subnets, consider the following
(legal, but quite odd) subnetting scheme:

Suppose network 128.223.0.0 (class B) is subnetted into 3 subnets, each
with 14 bits of host number and 2 bits of subnet number, but with 3
different subnet masks:
	  subnet 1:  mask ff.ff.c0.00	number 128.223.128.0 (80.df.80.00)
	  subnet 2:  mask ff.ff.a0.00	number 128.223.32.0 (80.df.20.00)
	  subnet 3:  mask ff.ff.60.00	number 128.223.64.0 (80.df.40.00)
i.e. the 3 high bits of the 3rd octet of addresses are 10x, 0x1, and
x10 respectively, where x is part of the host number on that subnet.
This is a legal, though non-hierarchical subnet configuration.
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      29 May 89 02:43:49 GMT
From:      cjsv@csadfa.cs.adfa.oz (Christopher JS Vance, RODOS group)
To:        comp.protocols.tcp-ip
Subject:   Re: re: RDP info/source wanted

From article <8905271757.AA10293@ucbvax.Berkeley.EDU>, by craig@NNSC.NSF.NET (Craig Partridge):
>     This implementation is available for experimental use by (free) license
> from BBN.  Note that as with many licensing procedures, it can take some time
> to get through all the paperwork.  Drop me a note if you are interested.

I am interested in RDP, since we are investigating such protocols with a
distributed OS we are designing.

--
Computer Science, Univ. of New South Wales, ADFA Canberra ACT 2601, AUSTRALIA
phone: +61 62 68 8176; fax: +61 62 68 8581; telex: ADFADM AA62030

cjsv@cs.adfa.oz.au		(domain)
cjsv%cs.adfa.oz@munnari.oz.au	(dumb)
uunet!cs.adfa.oz.au!cjsv	(uucp)

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      29 May 89 09:15:37 GMT
From:      toddpw@tybalt.caltech.edu (Todd P. Whitesel)
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers guide to Internet

In article <8905280753.AA16640@ucbvax.Berkeley.EDU> MP14STAF@MIAMIU.BITNET (Mark Powers) writes:
>Could someone tell me what word processor to use to format it ?
>
>                              Mark

It should be already formatted for a standard 80-column printer. I forget if it
has form feeds or spacing, so try printing it on an 80 by 66 printer and see
what happens.

toddpw

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 May 89 08:17 B
From:      <HEEMSTRA%HGRRUG5.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   script facilities in NCSA telnet



 Hi there,

    Has anyone ever heard of the existance of script facilities for NCSA's
 telnet, or maybe even adjusted his/her own version of NCSA's TCP/IP version
 to support such a feature ???

    If so, I would surely like to know where and how to get this modification,
 if possible; we would like to do some performace testing on our PC network,
 and for this we want to use telnet sessions, but this needs some kind of
 script facility.

    Thanks in advance,

 Mente H. Heemstra
 City University of Groningen
 Netherlands
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      29 May 89 10:17:00 GMT
From:      HEEMSTRA@HGRRUG5.BITNET
To:        comp.protocols.tcp-ip
Subject:   script facilities in NCSA telnet




 Hi there,

    Has anyone ever heard of the existance of script facilities for NCSA's
 telnet, or maybe even adjusted his/her own version of NCSA's TCP/IP version
 to support such a feature ???

    If so, I would surely like to know where and how to get this modification,
 if possible; we would like to do some performace testing on our PC network,
 and for this we want to use telnet sessions, but this needs some kind of
 script facility.

    Thanks in advance,

 Mente H. Heemstra
 City University of Groningen
 Netherlands

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      29 May 89 14:54:39 GMT
From:      tpc@bnr-fos.UUCP (Tom Chmara)
To:        comp.protocols.tcp-ip
Subject:   Reliable datagram service available?

We've identified a requirement for a reliable communications mechanism within
the UNIX environment, but can't accept the timeout restrictions for TCP
(we did some cocktail-napkin math, and came up with something like 45s to
detect that your destination isn't responding, and 6m to detect that he's gone
away).  As well, we may need HUNDREDS of connections from one process, and
that sort of blows the old "32/64/80 connections per process" out of the water.

According to the manual pages, UDP can drop, duplicate, and/or resequence
packets without warning (sounds reasonable for datagram).  Datagram offers us
the opportunity to maintain our "HUNDREDS" of clients, but is particularly
unfriendly, as we now have to maintain our OWN resequencing/retransmission
mechanisms in the application.

Does anyone know of any
	a) free
	b) $$
software which implements reliable datagram service, something like the
	SOCK_SEQPACKET
(sequenced, reliable, two-way connection-based byte stream for fixed-length
 datagram)
described in the literature?  Something which isn't quite this reliable is
also, obviously, worth investigating, as it's pretty much got to be better
than this (we're looking at bloody stop-and-wait, right now...yes, we're
desperate...)

The software would ideally run in any HP/SUN/4.3 environment, but then, we
can't have everything...
	
Please email; I will post a summary in a few weeks' time...

	Thanks for your time...
		---tpc---
-- 
I am sole owner of the above opinions. Licensing inquiries welcome.
------------------------------------------------------------------------
Tom Chmara			UUCP:  ..utgpu!bnr-vpa!bnr-fos!tpc
BNR Ltd.  			BITNET: TPC@BNR.CA

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      29 May 89 19:59:46 GMT
From:      jsm@phoenix.Princeton.EDU (John Scott McCauley Jr.)
To:        comp.protocols.tcp-ip
Subject:   Small TTL values evaporate in large networks (actually IPTTLDEC)

A similar problem: at least one BSDish implementation of TCP I've seen
had IPTTLDEC set to 5, not 1. (IPTTLDEC apparantly is the number that gets
subtracted from a packet's TTL when the machine forwards the packet -- it
also serves as the minimum ttl value that a packet can have before sending an
ICMP TTL_EXCEEDED message I think.)

This wasn't too much of a problem as the machine wasn't a gateway. However,
another machine on the local net was sending out broadcast packets with a
TTL of 3 (don't know why), so the first machine was the only machine on
the net sending out ICMP TTL_EXCEEDED messages.

I did a binary patch to change IPTTLDEC to 1 (in two places) and the
problem went away.

	Scott

-- 
Scott McCauley, jsm@phoenix.princeton.edu (INTERNET)
Home:	(609) 683-9065
Office: (609) 243-3312   (FTS 340-3312)
Fax:	(609) 243-2160   (FTS 340-2160)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 04:41:35 GMT
From:      brian@ucsd.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Small TTL values evaporate in large networks

The new Wollongong/AT&T WIN TCP/IP version 3.0 for the 3B series of
computers arrived with its TTL set to 0xf - 15, in other words.  Luckily
it's a parameter you can set (and the documentation includes telling you
how to do it).

Hmm. I just noticed that our copy sat on the AT&T loading dock for 15 days -
I wonder if that TTL value also applies to delivery time?  Maybe I'd
better NOT set it to 60 or I'll have to wait two months for the next
one....			:-)
	- Brian

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 10:32:00 EST
From:      yurcik@lcp.nrl.navy.mil
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   ACM Meeting to discuss Fiber LANs
******************************************************************************
		       WASHINGTON DC SIGCOMM

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

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

DATE:		  Wednesday, June 28, 1989

TIME:		  1.00 PM to 5:00 PM

PLACE:		  Naval Research Laboratory
		  Building 222 Auditorium
		  Washington D.C. 20375-5000
	
RESERVATIONS:	  RSVP with Bill Yurcik, "yurcik@lcp.nrl.navy.mil" or 
	          (202) 767-3903.  All attendees *MUST* RSVP by COB 
		  June 26th because names must be left at the guard posts for 
		  entry onto the base.  For security reasons, non-US citizens 
		  and foreign nationals might not be able to attend if special 
		  arrangements are not made in advance.

- - - - - - -  - - - - - - - - - AGENDA - - - - - - - - - - - - - - - - - - - - 

INTRODUCTION  : Greeting/Groundrules

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

Panel will consist of the following companies:

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

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

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

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



Directions and further details will be forwarded upon request.
*******************************************************************************

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 05:56:31 GMT
From:      eugene@eos.UUCP (Eugene Miya)
To:        comp.protocols.tcp-ip,comp.sys.super,comp.unix.cray
Subject:   Re: Benchmarking NFS, X-windows and TCP/IP generally

In article <822@manta.NOSC.MIL> budden@manta.nosc.mil.UUCP (Rex A. Buddenberg) writes:
>How about distributing some sort of benchmark program that guages
>degree of conformance to standard and degree of interoperability?

Benchmarking:
I am working on this, but I could use some help..... 8)  It ain't easy, but
I've made some progress in the past couple of weeks.  Could use some I/O
help [not just NFS] 8).

Actually what you want is typically called a test suite rather than a
benchmark.  You know functional testing and benchmarking are never
included in the same breath, yet they are both "testing." [Generalization
right?]

You know, benchmarks are those programs which every manufacturer considers
harmful.

On a different note it will be interesting to see if UNICOS (tm CRI) goes to
Cray Computer Corp. or stays with CRI.  Why just think of the internal
network which has to be divided up !!!...  Anyway before you post
a follow up, consider editing the newsgroups for the specific topic.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 09:48:03 GMT
From:      frank@tubkom.UUCP (Frank Ruge)
To:        eunet.general,comp.protocols.tcp-ip
Subject:   Gesucht : Doku fuer KA9Q-Internet-Package, Installation unter UNIX Sys5


Habe das Internet-Package bekommen, suche jetzt jedoch
Informationen zur Installation unter UNIX System 5.

 1. Wie wird die Ethernetkarte eingebunden ?
 2. Sind andere Dinge zu beachten ?
 3. Gibt es eine neuere Dokumentation als die von 12/88 ?


 Falls dort drauszen jemand irgendwas weisz, schicke er doch
 bitte Infos zur Installation.


 With many Thanks

			Frank

 email : frank@tubkom.uucp

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 14:07:02 GMT
From:      mo@prisma.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE considered harmful?

I hear you, Bob, but I,  for one, don't think it reasonable
for every applications protocol developer to have to
reinvent all the common stuff of doing keep-alives at the
applications level.  According to the advertising copy,
TCP provides reliable virtual circuits.  In my book, knowing
that the other end has croaked is part of the definition
of "reliable."  Since this is mechanism that is going to 
have to be reinvented by lots of protocols, it makes sense
to get it right ONCE so people don't have to (1) reinvent 
all the bugs and (2) can just use it for what they really
want to be doing.  The notion that protocols are only
designed by "mavens" is long dead, and rightly so.

	-Mike

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 15:32:00 GMT
From:      yurcik@LCP.NRL.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   ACM Meeting to discuss Fiber LANs

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

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

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

DATE:		  Wednesday, June 28, 1989

TIME:		  1.00 PM to 5:00 PM

PLACE:		  Naval Research Laboratory
		  Building 222 Auditorium
		  Washington D.C. 20375-5000
	
RESERVATIONS:	  RSVP with Bill Yurcik, "yurcik@lcp.nrl.navy.mil" or 
	          (202) 767-3903.  All attendees *MUST* RSVP by COB 
		  June 26th because names must be left at the guard posts for 
		  entry onto the base.  For security reasons, non-US citizens 
		  and foreign nationals might not be able to attend if special 
		  arrangements are not made in advance.

- - - - - - -  - - - - - - - - - AGENDA - - - - - - - - - - - - - - - - - - - - 

INTRODUCTION  : Greeting/Groundrules

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

Panel will consist of the following companies:

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

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

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

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



Directions and further details will be forwarded upon request.
*******************************************************************************

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 15:59:13 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   keep-alive

I can detect loss of connectivity real easily.  Just type a character.
If the connection won't work, it will time out, or get an immediate
TCP reset. 

However, I have no desire to watch my Telnet windows just go *pop*
just because there was a lack of connectivity for thirty seconds.
This happens quite often in the real world, like when one route goes
away, and the routing protocols have to re-settle.  In the interim,
the keepalives will cause ICMP error messages to be sent (which
routers *must* send to meet RFC 1009), and the connection will be
gratuitously shot.

Keep-alives are, from my point of view, keep-deads.  They guaruntee
that the my connection *will die* any time there is any momentary
network outage.  Keep-alives are absolutely contrary to the robustness
principle.  (See TCP RFC.)

In my experience, keep-alives kill far more live connections than dead
ones. 

If we're going to retain the stupid idea of keep-alives, lets add a
session protocol to TCP-IP to put the connection back together after
the keep-alive kills it.  However, since I doubt many people want to
add a session protocol to TCP, I'd rather kill keep-alives.

Let's quit trying to bend over backwards to make the TCP/IP specs
match the 4.xBSD implementations.  They were experimental, and not
fully conformant to the specs.  They were optimized for a local
network, not an Internet.  The specs work, lets meet them.  Fix the
code.


If you want the server Telnet host to be able to clean up your
connection, many systems have inactivity timers, which can kill it for
you.  Please don't break our TCP protocol because of a limitation in
some other operating system.

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 16:31:17 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: subnet mask problem

Long ago, we let users type in the raw, seething subnet mask itself
(255.???.???.???), but they got it wrong a lot of the time, and since
there are many PCs, the effect was large.  We decided to make it
easier on them (and their network administrators), and enhanced the
configuration code to just ask for the number of subnet bits (a much
simpler question to ask/answer), while deriving the actual mask from
the number of bits and the IP address in use.  The underlying IP
module uses the mask itself, not the number of bits.

If anyone *needs* non-contiguous masks, it would take about an hour
for someone equipped with our developer's kit to write a program that
set the mask itself.  If they were a little more patient, we'd do
it for them (might take a release cycle).

Summary: we feel we must weigh flexibility against complexity here.

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

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 16:41:46 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Host Requirements


Merton,

The host requirements RFC still lives in the same place, but it
recently underwent mitosis.  Use anonymous FTP to host venera.isi.edu
and fetch the pathnames:

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

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

The L files contain the link, IP, and transport layers, while the U files
contain the application and support programs.

There has long been a plan to make this document available from the NIC
as an Internet-draft, but it has not happened yet.

Bob Braden

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 16:48:53 GMT
From:      indra@amdcad.AMD.COM (Indra Singhal)
To:        comp.protocols.tcp-ip
Subject:   Anyone used Mitek soln. for TCP/IP<->SNA on MVS ?


We recently heard about a solution from MITEK that provides TCP/IP to SNA
connectivity on MVS. I do not have much detail about the product at this time.
Has anyone in net-land heard/used this product ? How well does this product
support NFS?

Any information (repeat: ANY) will be appreciated. Please email your replies.

Thanks.
--
-- 
Indra K. Singhal either:  indra@amdcad.AMD.COM
		     or:  {ames decwrl gatech pyramid sun uunet}!amdcad!indra
		     or:  MS 167; AMD; 901 Thompson Place; Box 3453; Sunnyvale, CA 94088
		     or:  (408) 749-5445(w)                  

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 16:55:11 GMT
From:      ml@gandalf.UUCP (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   IP addresses on multiple interfaces


I have a question regarding the Berkeley networking code.
If a host has multiple interfaces (each with its own IP address), is the
  IP address in the source field always that of the interface, if the
  data originated on that host.  Consider a host with two interfaces
  en0 and en1.  Interface en0 has an address of 134.22.80.6, interface
  en1 has an address of 134.22.32.1, both having netmasks of 255.255.240.0.
  If someone TELNETs out of the host to an address on the 134.22.32.xxx subnet,
  will the source address be 134.22.32.1, or 134.22.80.6 (address of the first
  interface configured)?
Inquiring minds want to know.
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml@gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 17:54:15 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   bridges & address filtering

i'd like to get people's opinions, theories, and war stories on the
subject of bridging and address filtering.  some bridges do address
filtering with hardware, others use software (hash tables, lookup tables).

what sort of advantages and disadvantages do you expect with each 
technique?  we'd be interested to hear from you whether you are a
bridge designer or a bridge user...

thanks...

steve elias
chipcom corp.


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

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 17:59:34 GMT
From:      LVARIAN@pucc.Princeton.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Xerox document on XNS

>I am looking for:
>
>	 Internet Transport Protocols, Xerox Corporation document XSIS-028112
>
>Anyone know where it is available and any costs!

Mark,  My most recent copy of the Xerox Systems Institute Literature
Catalog (from early 1988) lists the Internet Transport Protocols as
document XNSS 028112 and gives a price of $20.
  US Mail address:                    Telephone:
    Xerox Corporation                   (408) 737-4652
    475 Oakmead Parkway
    Sunnyvale, CA 94086
    Attn: Xerox Systems Institute
    MS: SVHQ 4

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 01:52:35 GMT
From:      marque!lakesys!deanr@csd4.milw.wisc.edu  (Dean Roth)
To:        tcp-ip@sri-nic.arpa
Subject:   tcpdump followup

I recently inquired about tcpdump for Sun's 386i.
It is not available at this time, but if you have a
Sun 3 you may want to know:


> From: Jeffrey C Honig <uwmcsd4!sonne.tn.cornell.edu!jch>

> Tcpdump only works under SunOS 3.[345].  The source is available for
> anonymous FTP (from ftp.ee.lbl.gov if you can find someone to get it to
> you) if you want to try to port it to SunOS 4.0, but you first need a
> fixed nit interface for SunOS 4.0.  Basically you are pretty much out of
> luck until tcpdump is ported to use a generic 'enet' driver that will be
> distributed with it.  There has not been any word on when this will be
> completed though. 


It looks like the time has come to buy an Ethernet monitor, since
I need DECnet support as well as TCP/IP (and maybe other protocols).
My options seem to be software for PC's in the $500 - $1200 range, or
a $12,000 - $15,000 "system".  Any suggestions/recommendations?

Dean Roth
deanr@lakesys.lakesys.com
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 07:45:00 EDT
From:      "NRL::COHEN" <cohen%nrl.decnet@nrl3.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Sys Admin needed
A part-time system administrator is needed for a system of 7 Unix computers
(5 Sun 4's, a Stellar, and a Multiflow).  Extensive experience not required,
but not knowledge of Unix and Fortran, and a desire to learn and work with an 
exciting solid state physics group is necessary.  Call Ron Cohen at
(202) 767-3934.  The position is as a contractor at the Naval Research 
Laboratory, Washington D.C. 20375-5000.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 06:16:00 GMT
From:      zweig@m.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   TCP socket ambiguity?


  Since a gateway may have two IP address -- say 100.100.100.100 for one
network and 101.101.101.101 for the other network it's connected to -- I
don't see what the "right way" to describe an endpoint of a TCP connection is.
  To read RFC 793 very literally, it would seem that port <100.100.100.100,42>
ought to specify a different socket/enpoint than <101.101.101.101,42>. But
they obviously both refer to "TCP port 42" on the gateway machine....
  If the answer is "different", would any implementations that assumes they're
the same because there is only one machine involved please raise their hands?
  If the answer is "same", would any implementations that assumed than
different <IP-address, port-#> pairs need to specify different endpoint please
say so?

-Johnny Confused

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 07:34:30 GMT
From:      chris@yarra.oz.au (Chris Jankowski)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC-NFS bug (long). Was: What is Ethernet type code 8035 hex?

Some time ago I posted a question about Ethernet type code 8035 (hex).
Thanks again to all who responded. It helped me to track down a bug in PC-NFS.
The bug is described below. Hope that does not waste news bandwidth. 
Is that a known bug? Has anybody encountered the problem? Is my analysis 
correct? Your comments are much appreciated. 

 
		A PC-NFS bug.
		=============

1. Conditions to recreate:
--------------------------

	- "A" class addressing Internet network.
	- YP not used.
	- RARP not used.
	- name server not used.
	- subnetting not used
	- Ethernet network (as oposed to SLIP).
	- PC-NFS 3.0

2. Description of the problem as seen by users.
-----------------------------------------------

Telnet terminal sessions with a UNIX host are run on PC/AT class of computers.
The program used on PCs is TELNET being part of PC-NFS Rel. 3.0 package from
Sun Microsystems.

Users of such sessions experience delays (screen freezes) of about 11 seconds
during which no information is sent from the host. During this time the user
can still key in some input but only to the point when the input buffer on
the PC gets full (8 characters).
After about 11 seconds normal work resumes ie. output is again sent from the
host and input is processed (including characters accumulated in the buffer).
The delays seem to happen at random and are experienced at a rate of a few 
per day per user.

Apart from the random delays there is also a situation when the delay happens
always but exactly once. It is after rebooting of a PC when either starting
a telnet session or when executing NET NAME command - whichever comes first.
Starting of consecutive telnet sessions and/or executing NET NAME commands
does not cause the delay.


3. Results of investigation.
----------------------------

The problem seems to manifest itself only if A class Internet addressing is
used eg. 125.30.1.1 for a host and say 125.30.1.20 for a PC.
The problem is not experienced when the network is either B or C class.
Also if a network is class A all PCs on it experience the problem regardless
of which host they have a telnet session with.
Other hardware/software dependencies have been eliminated by swapping 
equipment between networks, networks partitioning etc.

As the exact nature of the problem was a complete mystery an Isolan
Monitor was used to capture all Ethernet packets with either source
address or destination address fields equal to Etharnet address of a PC.
Fortunately it was known that the delay happens always after rebooting
of a PC when starting the first telnet session. Therefore it was easy
to start capturing there.

The following table lists all captured packets ( "A" class network,
start of the first telnet session after rebooting of the PC):
All packets are sent one after another within the resolution of the Isolan
Monitor clock (.005s) unless specifically noted.
 ------------------------------------------------------------------------------
Packet|Ether.|Ether.|Ether.|       Packet type, contents and comments
#     |source|dest. |type  |
      |addr. |addr. |code  |
------------------------------------------------------------------------------
1.    | PC   | bcast| 806  | ARP request
                             PC to the world: Send me Ethernet address of the
                             host having Internet address such and such.
------------------------------------------------------------------------------
2.    | host | PC   | 806  | ARP response
                             Host to PC: This is my Ethernet address.          
------------------------------------------------------------------------------
3.    | PC   | host | 800  | IP; TCP options (window size) negotiation. 
------------------------------------------------------------------------------
4.    | PC   | bcast| 8035 | RARP request 
			     PC to the world: send me my Internet address !??
                             This packet does not make much sense in the
                             context. The PC already knows its Internet
                             address. Moreover RARP has been specifically
                             disabled in NFSCONF program - so it is 
                             unreasonable to expect RARP support on the network
                             - in fact RARP should not be used at all.
                             The silliest thing is that the RARP packet itself
                             already contains both Internet and Ethernet
                             addresses of both the PC and the host in proper
                             fields.
------------------------------------------------------------------------------
5.    | host | PC   | 800  | IP; TCP options (window size) negotiation. 
                             The host responds to the packet #3.
------------------------------------------------------------------------------
6.    | PC   | bcast| 8035 | RARP request 
			     PC to the world: send me my Internet address !??
                             This packet is an exact copy of packet #4 and is
                             sent 3.5 seconds after packet #4.
                             Apprently the PC times out after not getting any
                             response to its RARP request (no wonder - RARP
                             is not used on the network) and resends the packet.
                             We start seeing where the delay comes from.
------------------------------------------------------------------------------
7.    | host | PC   | 800  | IP           
                             TCP options (window size) negotiation.            
                             The packet is a copy of TCP packet #5 and is sent
                             5.8s after packet #5.
                             The host responds to the packet #3 again as it
                             has not received any confirmation that its 
                             previous packet (#5) was received by the PC.
------------------------------------------------------------------------------
8.    | PC   | bcast| 8035 | RARP request 
			     PC to the world: send me my Internet address !??
                             This packet is an exact copy of packets #4 and #6
                             and is sent 3.5 seconds after packet #6 . The total
                             delay is now up to 7 seconds.
------------------------------------------------------------------------------
9.    | PC   | host | 800  | IP             
                             After another 3.5 seconds (10.5 in total) the
                             PC times out for the third time and all of the
                             sudden it drops the idea of getting its Internet
                             address from the network and acknowledges the TCP
                             window size negotiation packet sent by the host
                             so long ago.
------------------------------------------------------------------------------
10.   | host | PC   | 800  | IP             
                             TCP packet, telnet protocol - option negotiation
                             begins: do option 18hex.
------------------------------------------------------------------------------
 Just for comparison the following table outlays what happens on a C class
network when beginning the first telnet session after rebooting of the PC.
All packets are sent one after another within the resolution of the Isolan
Monitor clock (.005s) unless specifically noted.

------------------------------------------------------------------------------
Packet|Ether.|Ether.|Ether.|       Packet type, contents and comments
#     |source|dest. |type  |
      |addr. |addr. |code  |
------------------------------------------------------------------------------
1.    | PC   | bcast| 806  | ARP request
                             PC to the world: Send me Ethernet address of the
                             host having Internet address such and such.
------------------------------------------------------------------------------
2.    | host | PC   | 806  | ARP response
                             Host to PC: This is my Ethernet address.          
------------------------------------------------------------------------------
3.    | PC   | host | 800  | IP           
                             TCP options (window size) negotiation.            
------------------------------------------------------------------------------
4.    | PC   | bcast| 800  | IP           
                             UDP packet                            
                             contains the following string: PC-NFSxxxxxxxxxx
                             where xxxxxxxx is a hex number.
                             My guess is that it is an attempt to detect another
                             copy of NFS with the same serial number on the
                             network and therefore violating the terms of the
                             PC-NFS licence.
------------------------------------------------------------------------------
5.    | host | PC   | 800  | IP           
                             TCP options (window size) negotiation.            
                             The host responds to the packet #3.
------------------------------------------------------------------------------
6.    | PC   | host | 800  | IP             
                             TCP 
                             Acknowledgement of packet #5.
------------------------------------------------------------------------------
7.    | host | PC   | 800  | IP             
                             TCP packet, telnet protocol - option negotiation
                             begins: do option 18hex.
------------------------------------------------------------------------------

Here everything goes smoothly.

After finding that those are RARP packets which were causing the delay
at the beginning of the first telnet session after the PC being rebooted
it was easy to check whether the same packets are present during the
random delays. And indeed this is the case. Precise trigger for the
random delay happenning is still unknown - the PC knows its Internet
address all the time after all. But the pattern is clear - it is very likely
that the same code path is followed.

At this point it is rather obvious that this must be a bug in
the PC-NFS code. Hopefully it is documented precisely enough to enable
the developers to fix it.

What makes me think that this must be a bug is that no software vendor 
would let you to bypass all antipirating devices so carefully designed
into their product just by specifying a particular type of network
addressing. (;-))

Chris Jankowski     chris@yarra.oz.au     chris@yarra.oz
Pyramid Technology Australia - Melbourne

Append your favourite disclaimer here:

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 11:20:22 GMT
From:      ee@atbull.UUCP (Erwin Eder )
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.unix.i386
Subject:   Repost and summary : diskless workstations (long)


Original Subject: Booting diskless PC/AT-workstations from UN|X via ethernet


This is a complete list of all answers :

+++++++++++++++++++++ My request was: ++++++++++++++++++++++++++
+ >
+ >Can anybody out there help me with the following questions :
+ >
+ >	Configuration :
+ >		o) UNIX mini with SYS-V,TCP-IP, NFS
+ >		o) Diskless PC/AT-style workstations
+ >
+ >	Questions :
+ >		1) Is it possible to boot MS-DOS on the PC's
+ >		   from the UNIX mini via ethernet?
+ >		2) What is the hardware/software needed
+ >			a) on the UNIX mini ?
+ >			a) on the pc workstation ?
+ >
+ >Please e-mail me your comments.
+ >
+ >				Many thanx in advance
+ >					Erwin Eder
+ >
+ >
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

------------------------------------------------------------
Here is a complete list of answers to my request:
------------------------------------------------------------

RE:> From: Brad Clements <tuvie!omnigate.clarkson.edu!bkc>
RE:> 
RE:> You can obtain a BootP server via anonymous ftp from
RE:> 	lancaster.andrew.cmu.edu  from pub/bootp.2.0.tar
RE:> 
RE:> 
RE:> Here at Clarkson, we have developed an EPROM for Micom Interlan NI5210's
RE:> that allow them to boot from any unix system running BootP and tftp.
RE:> This software could easily support other types of ethernet cards, its
RE:> quite modular. On the 5210 version, it also checks the ethernet card
RE:> and reports on shorts or opens in the ethernet line and how far away
RE:> they are.  
RE:> 
RE:> Unfortuneately the client software is not freely distributable. Clarkson
RE:> intends to sell Eproms, or license the software  for a small fee.
RE:> 
RE:> We based the client code on stanford's client bootp for sun machines,
RE:> which you can get from safe.stanford.edu  in the file  pub/bootp.client.shar
RE:> 
RE:> Hope this helps.
RE:> 
RE:> 
RE:> | Brad Clements          bkc@omnigate.clarkson.edu        bkc@clgw.bitnet 
RE:> | Network Engineer       Clarkson University              (315)268-2292

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

RE:> From: <tuvie!cs.williams.edu!rbw>
RE:> 
RE:> The card has to take over the boot sequence, interposing itself twixt
RE:> the floppy check and the hard disk boot.  IBM did this with the PCNetwork
RE:> cards, and the TRN II cards, but I haven't heard of anyone doing it for 
RE:> ethernet.
RE:> 
RE:> -Rich

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

RE:> From: <tuvie!belltec!lance>
RE:> 
RE:> Hello!
RE:> 
RE:> A Seagate 20MB hard disk lists for around $200 US.  Every PC/AT comes with a 
RE:> hard disk controller.  Ethernet/NFS does not have the guaranteed, consistent
RE:> performance of even a slow disk like the Seagate.  
RE:> 
RE:> Conclusion: Diskless workstations are obsolete, except for secure environments.
RE:> 
RE:> Diskless workstations were a great idea 5 years ago, and if you're paying
RE:> list prices for SUN Micro hardware, they're still cost-effective.  But,
RE:> the big SUN users are now shopping for cheap third-party SCSI hard disks
RE:> for their large diskless workstation clusters, to free up the Ethernet for
RE:> real work.
RE:> 
RE:> There is a distribution of the BOOTP protocol.  This has a UNIX server program
RE:> for downloading images, and several clients in C for VMEbus cards.  It should
RE:> be a simple programming exersize to port this into a PC-AT Ethernet card
RE:> boot ROM.
RE:> 
RE:> Streamlined Networks is a UNIX Network software developer.  We have TCP/IP
RE:> and NFS products for UNIX and XENIX on 386 machines.  If you would like to
RE:> discuss this further, please send me mail or fax.
RE:> 
RE:> Thank You,
RE:> 
RE:> Lance Norskog
RE:> VP Engineering
RE:> Streamlined Networks
RE:> P.O. Box 14763
RE:> Fremont, CA  94539
RE:> 
RE:> uunet!belltec!lance
RE:> phone: USA 415-659-1450
RE:> fax: USA 415-659-9765

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

RE:> From: <tuvie!ihlpf!trdill>
RE:> 
RE:> I think you should be able to do this. My experience has been
RE:> with Cimlinc Unix workstations and more recently Sun
RE:> workstations, but I think the general principles should work
RE:> for your situation.
RE:> 
RE:> All the steps require that you have one of the systems up and
RE:> running and that you can connect to it via the network.
RE:> 
RE:> 1. Get the Internet number from the source (working system).
RE:> 	Unix command netname,hostid, whatever based on Unix
RE:> 	version idiosyncracy.
RE:> 2. At some point (called prom monitor on the systems I
RE:> serviced) you should be able to modify the boot source
RE:> address. This is some register that holds the source address
RE:> for the boot device (floppy,hard disk,magtape,network). You
RE:> will need to know what to change this to so that the source is
RE:> the network.
RE:> 
RE:> 3. The systems I serviced then prompted for the
RE:> Internet/ethernet number of the source machine. with this
RE:> entered the down machine pulled boot off the source machine.
RE:> If you wanted to go from there you could boot in any number of
RE:> diagnostics or disk maintenance type things. This was
RE:> accomplished by entering the internet/ethernet number followed
RE:> by a colon and the path to the fiel that you needed.
RE:> 
RE:> 
RE:> Again my experience has been primarily with Cimlinc and Sun
RE:> workstations but I see no reason why something like this could
RE:> not be done with your PC's.

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

############################################################

Comments :

o) I have no access to anonymous FTP from here (sigh)
o) Harddisks may be cheap, but in an industrial environment
   they would not survive for a long time.
o) Many thanx to everyone who sent me his ideas/solutions

Please send me more e-mail concerning this topic.

-- 
+---/~~~~\---------------+--------------------------------------------+
|  /      \  <-- this is |  and this    uunet!mcvax!tuvie!atbull!ee   |
|   \____/       a tree. |  is me -->     In-Real-Life Erwin Eder     |
+-----||-----------------+--------------------------------------------+

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 11:45:00 GMT
From:      cohen%nrl.decnet@CCF3.NRL.NAVY.MIL ("NRL::COHEN")
To:        comp.protocols.tcp-ip
Subject:   Sys Admin needed

A part-time system administrator is needed for a system of 7 Unix computers
(5 Sun 4's, a Stellar, and a Multiflow).  Extensive experience not required,
but not knowledge of Unix and Fortran, and a desire to learn and work with an 
exciting solid state physics group is necessary.  Call Ron Cohen at
(202) 767-3934.  The position is as a contractor at the Naval Research 
Laboratory, Washington D.C. 20375-5000.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 13:00:31 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   tcpdump (more info)


tcpdump is available in source from ftp.ee.lbl.gov by anonymous ftp,
but unless you have a Sun-3 with SunOS3.5 it is un-useable.  If you
have SunOS4.0 you will need to do two things:

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

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

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

More Notes...

 1) Sun's NIT interface cannot always report on its outgoing traffic,
    so don't think something is wrong if you don't see any.

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


Have Fun!

Micky Liu

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

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 14:23:28 GMT
From:      davids@stsci.EDU (David Silberberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Hitchhikers guide to Internet

In article <8905280753.AA16640@ucbvax.Berkeley.EDU>, MP14STAF@MIAMIU.BITNET (Mark Powers) writes:
> >Date sent:  22-MAY-1989 16:30:12
> >Can anyone tell me where to find the above paper? (anonymous FTP)
> 
> Hitchhikers guide is available via anonymous ftp from uxc.cso.uiuc.edu

Which file is it?

David

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 15:10:15 GMT
From:      walter@focsys.UUCP (WalteR Steinemann)
To:        comp.sources.wanted,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   RPC Library sources for System V

Has anybody out there ported the Sun RPC 3.9 code (which was posted to
comp.sources.unix for 4.[23]BSD) to System V?  
Does anyone know if there is any other RPC library source code freely 
available? If not, is there a binary available?

I need the library to build an NFS daemon for Interactive 386/ix 1.0.6,
so that I can get my DOS machines running NFS (from FTP Inc.).

Any help would be appreciated.

WalteR
-- 
Walter R. Steinemann -- Focus Automation Systems -- Waterloo, Ontario
                        watmath!focsys!walter       (519) 746-4918

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 17:17:10 GMT
From:      ian@lassen.wpd.sgi.com (Ian Clements)
To:        comp.protocols.tcp-ip
Subject:   tcp for the HP3000


 Does anyone know of an alternative to Wollongong's TCP for the HP-3000?
If you do, I'd like to hear about it.  

 E-mail please.  If there is enough interest, I'll post a summary.

	Cheers,

	Ian

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 17:36:41 GMT
From:      rds95@leah.Albany.Edu (Robert Seals)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Another NCSA telnet question (I rtfm already)


Well, ncsa telnet is sure neato, but I am having one real big
problem. I am unable to transfer certain files from the remote machine
to my PC. I can send from the PC to the remote machine, and it seems
that small files will go back, but usually, it says "150 Opening
connection\n" and then sits there doing nothing. File transfer is
enabled, and the standalone ftp did the same kind of
thing. My machine is a 386 with the WD8003; the remote machine is
a uVaxII with Ultrix 1.2.

(I just tested the same thing connected to a Unisys 7000 (CCI 6/32) with
4.3-tahoe, and it worked. Darn. Well, does this mean that Ultrix is the
stinker?)

rob

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 18:40:42 GMT
From:      dklann@heurikon.UUCP (David Klann)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Router Info Request

I suspect that this is an often asked question, but here goes anyway...

	Background:
Our company is setting up a new network configuration.  Part of that new
network involves two geographically separate offices.  Our intention is
to set up a leased line between the two offices for purposes of data
communication.  There will exist in each office Ethernet-based networks
communicating via TCP/IP and NFS or RFS (undecided).  We need a way to
connect the networks over the leased data line.

	Questions:
My understanding is that a pair of routers on each end is the way to go.
Is that correct?
What kind of router hardware/software is available?
What brand of router hardware/software is good?
What brand of router hardware/software is inexpensive?
Are there other alternatives?

Any and all help is appreciated.  Please e-mail responses, and I'll
summarize to the net if appropriate.

Thanks!
David Klann
Heurikon Corporation
<backbone>!uwvax!heruikon!dklann             Thank God, it's finally RAINING!

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 18:41:45 GMT
From:      kennyl@pitstop.West.Sun.COM (Ken Lopez)
To:        comp.protocols.tcp-ip
Subject:   Need Opinion on Terminal Server

I need opinions on the following product. Below, I will list
its features. Please be as critical as possible! Many thanks
in advance...

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize
in advance. :)

********************************************************************

Here is Product A:

16 or 32 RS232-C serial ports, 1 parallel port, 1 Ethernet
connector to transceiver.

	o UNIX Interface: Powerful UNIX-style interface with
	built-in "help" facility and job control.

	o "rlogin", "telenet": Full 4.3 bsd TCP/IP networking code
	including "telnt" daemon and name server support.

	o IP Routing: Supports subnets, gateways, Internet and
	ARPAnet access.

	o Central Administration: System administration of all
	hardware from one central computer allows software updates
	quickly and efficiently.

	o Modems: Autobaud, dial in/out, rotaries, flow-control.

	o Printers: Parallel or serial support with "print"
	daemon and spooler.

	o High-availability: Autoreboot from redundant boot servers.

	o Security: Individual, port, and custom password security
	and port tapping.

	o Debugging: Including self-diagnosis,"tap", "ping" and others.

	o Easy Cabling: DB9, DB25, modular telco or direct connect.

	o High-speed: 300 to 38,400 Baud...can repaint 24X80 terminal
	in 0.5 seconds.

	o Comprehensive SL/IP implementation provides alternative
	methods for boot loading and internet access. Any number of 
	hardware ports cab be configured as SL/IP interfaces.

	o Multiple Sessions: 8 sessions per port lets each user access
	multiple hosts simultaneously.

	Processor: Type 32-bit NS32016
	           Watchdog timer

	LAN interface: Type IEEE 802.3 and Rev 2.0
		       Ethernet compatible
		       Intel 82586

	Serial Line Interface:	Ports 16 or 32, RS232 or RS423
				Connector Type 50 pin Telco
				Flow control bidirectional
					hardware (DTR/CTS)
					software (XON/XOFF)

	Modem Control:	2 lines (DTR/DCD) for each port

	Line Speed:	Selectable for each port
			from 75 to 38.4 Kbps

	Parallel Printer Port:	Connector type 25-pin female
				Interface Centronics compatible

	Power	AC voltage	110V/220V
		Frequency	60Hz/50Hz
		Current		2A

	Physical Dimensions	Height	5.25" w/o feet
					5.50" w/feet
				Depth	19.0"
				Weight	23 lbs.

	Environment:	Operating Temperature	10-40  degrees C
						50-104 degrees F
			Humidity		60 degrees noncondensing
			Heat Dissapation	511 BTU/hour
Newsgroups: comp.newprod
Subject: Terminal Server
Reply-To: kennyl@pitstop.UUCP (Ken Lopez)
Distribution: usa
Organization: Sun Microsystems, Inc., Mountain View, CA.
Keywords: terminal server

I need opinions on the following product. Below, I will list
its features. Please be as critical as possible! Many thanks
in advance...

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize
in advance. :)

********************************************************************

Here is Product A:

16 or 32 RS232-C serial ports, 1 parallel port, 1 Ethernet
connector to transceiver.

	o UNIX Interface: Powerful UNIX-style interface with
	built-in "help" facility and job control.

	o "rlogin", "telenet": Full 4.3 bsd TCP/IP networking code
	including "telnt" daemon and name server support.

	o IP Routing: Supports subnets, gateways, Internet and
	ARPAnet access.

	o Central Administration: System administration of all
	hardware from one central computer allows software updates
	quickly and efficiently.

	o Modems: Autobaud, dial in/out, rotaries, flow-control.

	o Printers: Parallel or serial support with "print"
	daemon and spooler.

	o High-availability: Autoreboot from redundant boot servers.

	o Security: Individual, port, and custom password security
	and port tapping.

	o Debugging: Including self-diagnosis,"tap", "ping" and others.

	o Easy Cabling: DB9, DB25, modular telco or direct connect.

	o High-speed: 300 to 38,400 Baud...can repaint 24X80 terminal
	in 0.5 seconds.

	o Comprehensive SL/IP implementation provides alternative
	methods for boot loading and internet access. Any number of 
	hardware ports cab be configured as SL/IP interfaces.

	o Multiple Sessions: 8 sessions per port lets each user access
	multiple hosts simultaneously.

	Processor: Type 32-bit NS32016
	           Watchdog timer

	LAN interface: Type IEEE 802.3 and Rev 2.0
		       Ethernet compatible
		       Intel 82586

	Serial Line Interface:	Ports 16 or 32, RS232 or RS423
				Connector Type 50 pin Telco
				Flow control bidirectional
					hardware (DTR/CTS)
					software (XON/XOFF)

	Modem Control:	2 lines (DTR/DCD) for each port

	Line Speed:	Selectable for each port
			from 75 to 38.4 Kbps

	Parallel Printer Port:	Connector type 25-pin female
				Interface Centronics compatible

	Power	AC voltage	110V/220V
		Frequency	60Hz/50Hz
		Current		2A

	Physical Dimensions	Height	5.25" w/o feet
					5.50" w/feet
				Depth	19.0"
				Weight	23 lbs.

	Environment:	Operating Temperature	10-40  degrees C
						50-104 degrees F
			Humidity		60 degrees noncondensing
			Heat Dissapation	511 BTU/hour
Newsgroups: comp.newprod,comp.protocols.tcp-ip,biz.comp.hardware
Subject: Need Opinions on Terminal Server
Reply-To: kennyl@pitstop.UUCP (Ken Lopez)
Distribution: usa
Organization: Sun Microsystems, Inc., Mountain View, CA.
Keywords: Terminal Server

I need opinions on the following product. Below, I will list
its features. Please be as critical as possible! Many thanks
in advance...

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize
in advance. :)

********************************************************************

Here is Product A:

16 or 32 RS232-C serial ports, 1 parallel port, 1 Ethernet
connector to transceiver.

	o UNIX Interface: Powerful UNIX-style interface with
	built-in "help" facility and job control.

	o "rlogin", "telenet": Full 4.3 bsd TCP/IP networking code
	including "telnt" daemon and name server support.

	o IP Routing: Supports subnets, gateways, Internet and
	ARPAnet access.

	o Central Administration: System administration of all
	hardware from one central computer allows software updates
	quickly and efficiently.

	o Modems: Autobaud, dial in/out, rotaries, flow-control.

	o Printers: Parallel or serial support with "print"
	daemon and spooler.

	o High-availability: Autoreboot from redundant boot servers.

	o Security: Individual, port, and custom password security
	and port tapping.

	o Debugging: Including self-diagnosis,"tap", "ping" and others.

	o Easy Cabling: DB9, DB25, modular telco or direct connect.

	o High-speed: 300 to 38,400 Baud...can repaint 24X80 terminal
	in 0.5 seconds.

	o Comprehensive SL/IP implementation provides alternative
	methods for boot loading and internet access. Any number of 
	hardware ports cab be configured as SL/IP interfaces.

	o Multiple Sessions: 8 sessions per port lets each user access
	multiple hosts simultaneously.

	Processor: Type 32-bit NS32016
	           Watchdog timer

	LAN interface: Type IEEE 802.3 and Rev 2.0
		       Ethernet compatible
		       Intel 82586

	Serial Line Interface:	Ports 16 or 32, RS232 or RS423
				Connector Type 50 pin Telco
				Flow control bidirectional
					hardware (DTR/CTS)
					software (XON/XOFF)

	Modem Control:	2 lines (DTR/DCD) for each port

	Line Speed:	Selectable for each port
			from 75 to 38.4 Kbps

	Parallel Printer Port:	Connector type 25-pin female
				Interface Centronics compatible

	Power	AC voltage	110V/220V
		Frequency	60Hz/50Hz
		Current		2A

	Physical Dimensions	Height	5.25" w/o feet
					5.50" w/feet
				Depth	19.0"
				Weight	23 lbs.

	Environment:	Operating Temperature	10-40  degrees C
						50-104 degrees F
			Humidity		60 degrees noncondensing
			Heat Dissapation	511 BTU/hour
Newsgroups: comp.newprod
Subject: Terminal Server
Reply-To: kennyl@pitstop.UUCP (Ken Lopez)
Distribution: usa
Organization: Sun Microsystems, Inc., Mountain View, CA.
Keywords: terminal server

I need opinions on the following product. Below, I will list
its features. Please be as critical as possible! Many thanks
in advance...

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize
in advance. :)

********************************************************************

Here is Product A:

16 or 32 RS232-C serial ports, 1 parallel port, 1 Ethernet
connector to transceiver.

	o UNIX Interface: Powerful UNIX-style interface with
	built-in "help" facility and job control.

	o "rlogin", "telenet": Full 4.3 bsd TCP/IP networking code
	including "telnt" daemon and name server support.

	o IP Routing: Supports subnets, gateways, Internet and
	ARPAnet access.

	o Central Administration: System administration of all
	hardware from one central computer allows software updates
	quickly and efficiently.

	o Modems: Autobaud, dial in/out, rotaries, flow-control.

	o Printers: Parallel or serial support with "print"
	daemon and spooler.

	o High-availability: Autoreboot from redundant boot servers.

	o Security: Individual, port, and custom password security
	and port tapping.

	o Debugging: Including self-diagnosis,"tap", "ping" and others.

	o Easy Cabling: DB9, DB25, modular telco or direct connect.

	o High-speed: 300 to 38,400 Baud...can repaint 24X80 terminal
	in 0.5 seconds.

	o Comprehensive SL/IP implementation provides alternative
	methods for boot loading and internet access. Any number of 
	hardware ports cab be configured as SL/IP interfaces.

	o Multiple Sessions: 8 sessions per port lets each user access
	multiple hosts simultaneously.

	Processor: Type 32-bit NS32016
	           Watchdog timer

	LAN interface: Type IEEE 802.3 and Rev 2.0
		       Ethernet compatible
		       Intel 82586

	Serial Line Interface:	Ports 16 or 32, RS232 or RS423
				Connector Type 50 pin Telco
				Flow control bidirectional
					hardware (DTR/CTS)
					software (XON/XOFF)

	Modem Control:	2 lines (DTR/DCD) for each port

	Line Speed:	Selectable for each port
			from 75 to 38.4 Kbps

	Parallel Printer Port:	Connector type 25-pin female
				Interface Centronics compatible

	Power	AC voltage	110V/220V
		Frequency	60Hz/50Hz
		Current		2A

	Physical Dimensions	Height	5.25" w/o feet
					5.50" w/feet
				Depth	19.0"
				Weight	23 lbs.

	Environment:	Operating Temperature	10-40  degrees C
						50-104 degrees F
			Humidity		60 degrees noncondensing
			Heat Dissapation	511 BTU/hour

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 19:55:17 GMT
From:      srb@beta.lanl.gov ( Steve Berger )
To:        comp.protocols.tcp-ip
Subject:   Opinions wanted on TCP/IP software


We are in the process of gathering materials for implementing an Ethernet
network.

I'm gathering info on various Ethernet boards for PC's as well as 
various software packages that exist.

I think we will mainly be interested in some sort of TCP/IP stuff so that
we can do ftp, telnet, rlogin,  type stuff.

I would appreciate input from anyone that is currently using something
they like, or has used something they think I should avoid.

Any information is appreciated.

Steve Berger

srb@lanl.gov

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 21:59:00 GMT
From:      bierma@NPRDC.NAVY.MIL (Larry Bierma)
To:        comp.protocols.tcp-ip
Subject:   tcpdump for SunOS4.0?

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

--Larry		ARPA: bierma@nprdc.navy.mil
		UUCP: ucsd!nprdc!bierma
		PSTN: (619) 553-7915

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 22:43:45 GMT
From:      robert@ms.uky.edu (Robert Lee)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering

We've had some experience with bridges at UK.  For the most part we use
them to isolate the various ethernets on campus from the broadband backbone.
Currently we use the UB-DLB and LAN-100 bridge, the latter had a bug.
if someone used a destination address of all 1's FFFFFFFF the routing table
would get trashed.  It turned out the LAN-100 was using FFFFFFFF as the
terminating entry for the routing table...  We also use the 
UB DLB(Data link bridge) with no problems.  We have a limited set of
management capability for these bridges and would like to have much more.

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

For example here are some things I would like to be able to do with
a bridge.

1) Be able to tell the bridge to disconnect from a ethernet for a time
   or until I tell it to turn its packet forwarding back on.
2) Be able to tell the bridge to forward all the packets it sees.
3) Programmable filters that don't degrade packet forwarding to any high 
   degree.
4) A extensive set of statistical variables.  Like # packets/sec. Collision
   etc etc.  Also it would be nice if these results could be put into
   a file that can be processed with statistical programs like SAS or SPSS.
5) Bridges usually only look at the ethernet address header and
   not what type of packet it is.  It would be nice if there was a facility
   that allow the bridge to forward based on packet types.  I can do
   this to some extent with filters now.

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

Robert Lee
SYSBOB@UKCC
University of Kentucky

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      31 May 89 23:56:40 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: bridges & address filtering

The LANBridge learning of the broadcast address is a bug.  It
showed up in later releases and hopefully has been fixed by now.

You are certainly learning all the instances where a router
would be much handier for you than a bridge.  You might call
up Cisco and Proteon and get them to do a song and dance for
you.

-Ron

END OF DOCUMENT