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
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
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
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

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
>
>	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.

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"
-----------------------------------------------------------------------------


-----------[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
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

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).
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,
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
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
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.

stream on a Telnet connection.

-Dave Borman, dab@cray.com


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 May 89 18:26:35 GMT
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

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

>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
--
Rob  Horn
...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

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
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
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,

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

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

SESSION 3B: DISTRIBUTED OS CONSISTENCY

Chair: Virginia Kobler, U.S. Army

Immediate Ordered Service in Distributed Systems

Phil Kearns
Brahma Koodalattupuram

An Approach to Robust Computation

Raymond C. Chen
Partha Dasgupta

Fault-Tolerant Distributed Systems Based on

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
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

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

Analysis of Communicating Processes for non-progress

Wuxu Peng
S. Purushothaman

A Probabilistic Approach to Distributed Clock Synchronization

Flaviu Cristian

Ravi Mirchandaney
Don Towsley
John A. Stankovic

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

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

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
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

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

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

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
> 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

Program Chairman:

Prof. Norman Schneidewind
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,

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

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

SESSION 3B: DISTRIBUTED OS CONSISTENCY

Chair: Virginia Kobler, U.S. Army

Immediate Ordered Service in Distributed Systems

Phil Kearns
Brahma Koodalattupuram

An Approach to Robust Computation

Raymond C. Chen
Partha Dasgupta

Fault-Tolerant Distributed Systems Based on

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
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

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

Analysis of Communicating Processes for non-progress

Wuxu Peng
S. Purushothaman

A Probabilistic Approach to Distributed Clock Synchronization

Flaviu Cristian

Ravi Mirchandaney
Don Towsley
John A. Stankovic

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

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

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
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

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

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

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
> 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
>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.

>--
>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
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

>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.

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

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

? 		(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

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

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
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

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
--
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.

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:

>
>
>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.

++++++++++ 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

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
...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

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.

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
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).

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
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).

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
>>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

>
>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.

simply some bugfix for 5.61 that'll correct this situation?

Brian Kantor	UCSD Office of Academic Computing
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
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
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
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
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
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

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
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 ) .
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
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
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
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

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
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
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?)
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)
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


-----------[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,

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
>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,

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
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.


-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      24 May 89 16:53:16 GMT
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".


-----------[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
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

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,
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

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
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

--
>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:
>
> !!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
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.

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
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.


-----------[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
:      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
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
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

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:
>
> !!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
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
::>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

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
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

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

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
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
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

%	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
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).

"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
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
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.


-----------[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
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
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).

| Network Engineer       Clarkson University              (315)268-2292

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 May 89 18:39:56 GMT
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).

| 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
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
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
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
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
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
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
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


-----------[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.

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.

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...

---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

- - - - - - -  - - - - - - - - - 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

- - - - - - -  - - - - - - - - - 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
the number of bits and the IP address in use.  The underlying IP
module uses the mask itself, not the number of bits.

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
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.


-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      30 May 89 16:48:53 GMT
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?

Thanks.
--
--
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
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
"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
filtering with hardware, others use software (hash tables, lookup tables).

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:> 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:>
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:> 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.

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

############################################################

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

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize

********************************************************************

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.

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
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
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

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize

********************************************************************

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.

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
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
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

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize

********************************************************************

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.

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
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
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

Kenny   sun!maui!kennyl

PS If I have posted this to the wrong newsgroup I apologize

********************************************************************

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.

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
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.
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