The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for September 1988 (364 messages, 177832 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/09.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 Sep 88 04:45:56 GMT
From:      schacht@tgate.UUCP (Bryan Schacht)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: RUNNING FTP IN BATCH MODE

The Excelan FTP package already comes with a batch file that will keep
executing FTP after each session.  Just type ftpserv to use this batch file.
On my system, it is located in the c:\xln\bin directory.

Bryan Schacht
TransGate
hplabs!felix!tgate!bryan

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Sep 88 13:11:15 EDT
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        BILLY@venera.isi.edu
Cc:        pcip@louie.udel.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Microsoft 3Comm MAC Spec available via FTP
The 5/14/88 spec Billy has is v1.0.1, which I am informed is the current
version.  It is also available for anonymous FTP from vax.ftp.com, under
the file name:

	pub/ndis-mac.v101.txt

My file is only 174K long, and ends on page 88, followed by 11 pages of notes
about changes since v1.0 (3/2/88).  I won't mail it to you either.

James VanBokkelen
FTP Software Inc.
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 09:17:12 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one Host.

In article <24663@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
> 	Seems to me that name server lookup can handle this
> transparently, so long as the resolver in the client telnet takes
> reasonable actions on the response received.
> 
> 	This is the same situation as a multi-homed host and I believe
> the name server is set up to handle this with multiple records for a
> single host.  Name servers return all addresses listed for a given name.
> The ... telnet client would need to be smart enough to try all returned
> names before giving up on the connection request.

  4.3BSD and later telnet does this (99% assurance - I'd look, to verify
this absolutely, but my ARPANET connection has gone down).  If you simply
do the equivalent of:

	a.b.c.d		terminal-server
	r.s.t.u		terminal-server

and then do "telnet terminal-server", you get the correct response.
If your telnet client doesn't do this, you can grab the latest telnet
client sources from ucbarpa (again this is an "I believe - I hate it when
I can't check things).

Casey

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Sep 88 16:02:24 -0400
From:      Buz Owen <ado@VAX.BBN.COM>
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARMY.MIL>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Host-down redirects?
I believe you could use 1822L logical addressing for this purpose, by arranging
that only one host enables a particular logical address at a time -- i.e.  when
backing up some other host.  Of coure you have to using 1822l headers, and be
willing to change your host addresses, both possibly formidable obstacles.  Buz
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 09:41:00 GMT
From:      WANCHO@SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Host-down redirects?

Monday evening SIMTEL20 came back online after being down for 18 days
awaiting air conditioner repair.  During the downtime, we activated
duplicate logins on our sister site in St. Louis.  However, unless our
users happened to call in or paid attention to previous announcements
to check the signon banner at the St. Louis host, they had no way of
knowing to try the alternate host.  That was one problem - admittedly
one of having our users know our SOP.

The other problem was that some, possibly critical or time-critical
mail was eventually returned to the sender during that interval.  And,
as far as I know, there is no "automatic" redirection possible.  Or is
there?

What I have in mind is that, given that I could have made the St.
Louis host think that its alias was SIMTEL20.ARMY.MIL (and the older
SIMTEL20.ARPA) via a quick modification to the hosts tables, would it
have been (and is it) possible to have gotten our PSN to redirect
connection requests intended for our downed host to the St. Louis
host for the duration of the downtime?  If not, why not?  For those of
us who take the requirement for mandatory Continuity of Operations
Plans (COOP) seriously, such a feature would close the gap and make it
reasonable to implement when needed.

Note: I am aware of the clever solution to this problem implemented at
BRL, but I'm not prepared to move off the backbone at this time (due
to our heavy traffic which would probably swamp most gateways) to take
advantage of that route.

--Frank

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Sep 88 16:21:23 -0400
From:      Craig Partridge <craig@SH.CS.NET>
To:        wancho@simtel20.army.mil
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Host-down redirects?


> The other problem was that some, possibly critical or time-critical
> mail was eventually returned to the sender during that interval.  And,
> as far as I know, there is no "automatic" redirection possible.  Or is
> there?

Frank:

    Automatic redirection is possible using MX RR's in the domain name
system. The feature was included for just this problem.

    Quite simply, you make your backup host a backup mail exchanger (MX).
Then whenever your primary host is down, mail gets delivered to your
backup.  For short term outages, your backup machine simply waits for
your primary to come up again, then forwards the mail on.  But when
the primary is going to be down for a long time, you can reconfigure
your mailer to have the backup actually deliver the mail sitting in
its queues.

Craig
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Sep 88  18:29:32 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Multiple TCP/IP servers on one host
I'd just like to say that multiple terminal servers on one host will be
a problem for us too.  Right now we have a host that has about 700
async dial ports.  We expect that network access will begin to supplant
modem access in the near future, as we get our network connections in
gear.  Even a cisco ASM with 96 ports (the biggest terminal server that
I know of) wouldn't be enough.  Even if it were compatible with our
host, which it isn't.

The solution using the domain name system sounds best because it
doesn't require changing all the Telnet implementations on the
Internet.  If the choosing is done in the name server (which seems
necessary to avoid changing all the Telnets), then it is necessary to
set the time to live to a small value, so that the random response
won't be cached and reused many times.  This increases the number of
name server requests, but nothing is perfect.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 18:31:52 GMT
From:      harkin@hpindda.HP.COM (Art Harkin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for HP 3000/935 and associated questions

/ hpindda:comp.dcom.lans / jja@tut.fi (Ahola Jari) /  5:57 pm  Aug 29, 1988 /

>	I'd like to hear comments from those of you who are familiar
>	with the software (hardware?) from the Wollongong Group for
>	the HP 3000 series, if such a thing even exists. The problem
 ...
>	Question: Has the Wollongong group anything to offer (or some other
>	party) to provide the following services between Sun/HP 3000 ?
 ...
>  	-jja
 ...

> Jari 'jja' Ahola	  | Tampere University of Technology, CS dept.
> Opiskelijankatu 16 A 12 | P.O. Box 527, 33101 Tampere, Finland
> 33720 Tampere		  | Tel (intl) 358 31 162708 (work)/358 31 174009 (home)
> Finland. Puh. 931-174009| Net address: jja@tut (UUCP)  AHOLA@FINTUTA (BITNET)

Yes, there is a product from Wollongong for the 3000: "WIN/TCP for MPE/V".
It supports Telnet, FTP, SMTP (ARPA Services) which run on top of TCP/IP.
HP references this product, but it is not an HP product and is supported
by The Wollongong Group. Below is the information to contact Wollongong for
more details and sales information:     

For Jari in Finland it is:  Jertec Oy
			    Nihtisillankuja 5
			    02630 ESPOO
			    Tel: 90 527 11
			    Fax: 90 520 871
			    Tlx: 123265 JERC SF

In USA:    MAIN OFFICE			EAST COAST OFFICE
	   The Wollongong Group		The Wollongong Group
	   1129 San Antonio Road	7799 Leesburg Pike
	   PO Box 51860			Suite 1100
	   Palo Alto, CA 94303		Falls Church, VA 22042
	   (415) 962-7200		(703) 847-6340

DISCLAIMER: This is not an official statement of Hewlett Packard Corp., and
does not necessarily reflect the views of HP.  It is provided completely
without warranty of any kind. Contact The Wollongong Group for any sales or
support help.

Art Harkin
Network Support Center
Hewlett Packard Corporation

PHONE: (408) 447-3598 
UNIX: harkin@hpindda.HP.COM

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 20:02:24 GMT
From:      ado@VAX.BBN.COM (Buz Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: Host-down redirects?

I believe you could use 1822L logical addressing for this purpose, by arranging
that only one host enables a particular logical address at a time -- i.e.  when
backing up some other host.  Of coure you have to using 1822l headers, and be
willing to change your host addresses, both possibly formidable obstacles.  Buz

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 20:21:23 GMT
From:      craig@SH.CS.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Host-down redirects?



> The other problem was that some, possibly critical or time-critical
> mail was eventually returned to the sender during that interval.  And,
> as far as I know, there is no "automatic" redirection possible.  Or is
> there?

Frank:

    Automatic redirection is possible using MX RR's in the domain name
system. The feature was included for just this problem.

    Quite simply, you make your backup host a backup mail exchanger (MX).
Then whenever your primary host is down, mail gets delivered to your
backup.  For short term outages, your backup machine simply waits for
your primary to come up again, then forwards the mail on.  But when
the primary is going to be down for a long time, you can reconfigure
your mailer to have the backup actually deliver the mail sitting in
its queues.

Craig

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 20:53:01 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

I would like to invoke Robert's Rules and move that this discussion be closed.
The discussion has degenerated to the point that it is only fanning *flames*
between proponents of T4/IP and TCP/IP and does not increase the understanding
or appreciation of either the ISO OSI Reference Model or the TCP/IP protocol
suite.  The simple answer to the question is that TCP/IP does conform to the
model.

Those of us who purvey services, equipment, and systems to DoD are well aware
that OSD (Office of the Secretary of Defence) has mandated the use of the ISO
protocol suite for interoperability between the US and its allies.  The only
thing that seems to be worth discussing is interoperability between the ARPA
and ISO protocol suites.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 21:20:48 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   It's in print, so it must be true...

Just when you think Padlipsky and Karn have hit the depths of extremism,
here we have something from the other side of the spectrum:

Reading from the Opinions section of Network World, August 29, 1988 on
page 27, from an article entitled "The long, bumpy migration path to
OSI":

    "OSI, on the other hand is significantly superior to TCP/IP in every
    way: at every protocol layer, in every class of protocol and in
    every application, the richness of OSI application-layer protocols
    is evident to every user."

The author's name is Jeff Horn, he is a consultant with Network
Strategies, Inc., a communications consulting firm in Fairfax, VA.

Phil -- I encourage you to send a nasty letter to either the author or
Network World.  This is the second time in one week when I've read an
article claiming the technical superiority of OSI over TCP/IP at every
layer.  The last article I read said that "OSI was significantly faster
than TCP/IP".

Have fun,

/mtr

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 22:27:16 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Options Commonly Supported


	Bill Barns from MITRE <barns@gateway.mitre.org> and Craig
Partridge <craig@NNSC.NSF.NET> from BBN both pointed me toward the
upcoming Host Requirements RFC.  This is exactly what I was looking
for.  This RFC looks like the be all and end all of the definitive
state of the RFCs related to implementations of telnet (and everything
else :-).  I was looking for a "state of telnet" document to help me
determine the strengths and weaknesses of commercial telnet terminal
servers. [Perhaps the authors won't like me using this RFC for that
purpose, we'll see what they say when they publish it.]  I was finding
it quite difficult to figure out the mass of RFCs related to telnet.
I basically wanted an analytically defined checklist to run through
when checking out a telnet implementation to make sure that there were
no glaring weaknesses in a particular implementation.

	We'll see if this new RFC won't handle this purpose when it is
published.  Meanwhile, there is no need for anyone else to write such
an evaluation guide.  (Thank goodness!)

	Kent England, BU

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 22:29:32 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP servers on one host

I'd just like to say that multiple terminal servers on one host will be
a problem for us too.  Right now we have a host that has about 700
async dial ports.  We expect that network access will begin to supplant
modem access in the near future, as we get our network connections in
gear.  Even a cisco ASM with 96 ports (the biggest terminal server that
I know of) wouldn't be enough.  Even if it were compatible with our
host, which it isn't.

The solution using the domain name system sounds best because it
doesn't require changing all the Telnet implementations on the
Internet.  If the choosing is done in the name server (which seems
necessary to avoid changing all the Telnets), then it is necessary to
set the time to live to a small value, so that the random response
won't be cached and reused many times.  This increases the number of
name server requests, but nothing is perfect.

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 88 22:29:49 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   TOS field in IP packet

I'm curious about a packet that shows up every so often on the LANL Internet.

The ones I caught were ICMP ECHO requests.  What was curious about
them was the Type of Service field.

In one case the TOS field was '11111110' which maps to

	Precedence == Network Control
	Delay == Low
	Throughput == High
	Reliablility == High
	Reserved bit 6 == on
	
Now, I can understand how a particular implimentation would like to
have low delay, high throughput and high reliability  -  wouldn't we
all.   I also understand that setting more than two of these is
considered excessive.

However, as I understand it TOS is not something that is actually offered
by vendors now or understood to well by the Internet in general.

I next, asked the owner of the machine to do a few more echo's,  The TOS
field varied.  The machine is a SUN with IPC board running 3.5.  

Another interesting fact is that the VMS system running Wollengong
TCP/IP software responded with ROUTINE precedence.  I tried the same thing
with a BSD4.3 system and it also returned
the packet, but with the same TOS bits.  In either case I would think
the responder should drop the packet because of the bit set in the reserved
field.

I assume that some coder forgot to clear the TOS field.

One questions are:  Are those reserved bits still reserved and supposed
to be zero?  And if the are reserved and non-zero, should we drop the packet.


Phil Wood,  cpw@lanl.gov 

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 00:32:04 GMT
From:      jom@belltec.UUCP (Jerry Merlaine)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   DS1/DDS PC Boards

Dear Friends,

Are there PC (8- or 16-bits) boards on the market that somehow connect 
up to AT&T's DDS (56 kbit) or DS1 (1.5 mbit, not really aka T1) services?
Are they certified by AT&T? Are there any packet interchange standards here?
Besides SL/IP :-) ?  I know about the trick where inverted HDLC signals
pass DS1 signal specs.  Any further comments on this?

Companies, addresses, phone numbers, product propaganda cheerfully accepted.

Jerry O. Merlaine
Bell Technologies
330 Warren Avenue
Fremont, CA  94539
(415) 659-9097

Oh, what a beautiful moooooooorniiiiinnnngggg,
Oh, what a beautiful daaaaaaaaayyyyyyy!

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 02:16:00 GMT
From:      WANCHO@SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   host-down redirects?

Bob,

Most of our users exchange mail with other MILNET hosts.  I suspect
about 95-99% of those hosts still run off of the NIC hosts table, as
we currently do.  When we are all forced to use domain resolvers, then
your suggested solution would appear the way to go.

--Frank

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Sep 88 10:48:44 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARMY.MIL>
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Host-down redirects?

     ... SIMTEL20 came back online after being down for 18 days ...  activated
     duplicate logins on our sister site ...

Logical addressing is what you might use to direct connections to an alternate
server.

1. Since tac connections are probably still done numerically by your users,
you could educate them about opening connections by name if the name server
version of TACACS is running.

2. For long-term (more than a week) outage, you could try changing your host
table entry at your domain name server (or the NIC).  Even hosts that use the
NIC host table should eventually get the address change.

3. On an arpanet (e.g. the Milnet), the PSN's support logical addressing,
both for X.25 and for 1822-AHIP.  Your name server and host tables identify
your address as a 'logical' one, such as 26.64.0.99, and you then can tell
any one (or more) of your hosts to come up with that address.  The problem
with this solution is that there are no hosts that implement 1822-AHIP
logical addressing.

4. If you were on an ethernet, you'd get logical addressing for free, and
your host would have to act as multiple addresses on a single interface.

     ... the clever solution to this problem implemented at BRL ...

Was this using ethernet addressing?

Yours for logical networking,
Mike
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 06:21:25 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: wanted - Nameserver binaries for an ULTRIX 2.0

In article <8808231849.AA06055@beast.DDN.MIL>, stjohns@BEAST.DDN.MIL (Mike St. Johns) writes:
> The subject says it all - I've got the named/domaind stuff from
> Berkeley, but since I've got a binary only system - I've got some
> trouble even getting the libraries built!

You shouldn't need more than a binary system.  I'd be glad to move this
to private mail and discuss exactly what's going wrong and what could
be causing it.  I know of at least one Ultrix 2.x machine with a
nameserver running on it, so it certainly ought to be possible.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 06:32:00 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

> [A disadvantage of the BSD networking model is that] a connection may
> proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K
> bytes of) data before the application-level peer (process) is even
> created.  [...] What if X were to place a "collect" call to such an
> implementation and send data; then the receiver process start up and
> decides it doesn't want to accept the call.  Who pays for the bytes?

Presumably in an environment where the notion of a "collect" call makes
sense, one doesn't use this model.  It would be fairly easy to add such
capability to BSD.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Sep 1988 13:36 EST
From:      Suresh Konda <KONDA@VM.CC.PURDUE.EDU>
To:        tcp-ip@sri-nic.arpa
I would appreciate receiving mail etc. concerning tcp/ip.  Thank you.

Suresh L. Konda
Krannert School of Management
Purdue University
West Lafayette, IN 47907
317 494-4513
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Sep 88  12:43:31 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Milking machines
Since the topic of communications servers has come up, it seems like a
good time to throw out my request for recommendations.  We currently
have a Bridge CS/1 with 32 ports that is hooked up to our IBM mainframe
as a milking machine.  We are talking 37x5 async ports, not protocol
converters.  Our biggest complaint about the Bridge CS/1 is that it
does not negotiate the Telnet echo option correctly.  It says that it
will echo and then expects the host to do it.  The problem is that our
host does not echo, so the user must manually turn on echoing at their
end.  The other problem with the CS/1 is that it is only 32 ports.  We
will need a lot more in the future.  The CS/1 can be configured with 64
ports, but then does not provode all the modem control signals that we
need.  So far, 3Com/Bridge has not been very responsive in coming up
with a solution to the echo problem.

The cisco ASM communications server sounded attractive because it
supports up to 96 ports and they say that they do the echo negotiation
properly.  So we got one in to test and found out in trying to figure
out how to configure it that it does not support all of the necessary
modem control signals.  We need DSR and DCD to come up at the start of
a connection and go down at the end.  A connection must be broken when
the host lowers DTR.  And CTS must be lowered when the communications
server can't accept more data from the host (our host doesn't support
XON/XOFF flow control).  Unfortunately, the cisco box can't do flow
control on CTS when it is doing the other modem control signals.  So we
sent it back.

So, does anyone have any recommedations for other communications
servers for us to look at?  We need lots of ports, proper echo
negotiation, support for break signals, and full modem control,
including hardware flow control.  Don't tell me to junk the mainframe.
:-)
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Sep 88  13:55:01 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Multiple TCP/IP servers on one host
> I'd just like to say that multiple terminal servers on one host will be
> a problem for us too.  Right now we have a host that has about 700
> async dial ports.  We expect that network access will begin to supplant
> modem access in the near future, as we get our network connections in
> gear.  Even a cisco ASM with 96 ports (the biggest terminal server that
> I know of) wouldn't be enough.  Even if it were compatible with our
> host, which it isn't.
>
> The solution using the domain name system sounds best because it
> doesn't require changing all the Telnet implementations on the
> Internet.  If the choosing is done in the name server (which seems
> necessary to avoid changing all the Telnets), then it is necessary to
> set the time to live to a small value, so that the random response
> won't be cached and reused many times.  This increases the number of
> name server requests, but nothing is perfect.

After further reflection, I think that I did not phrase this very well.
What I should have said is that it would be useful if the domain name
server could be told to somehow vary (i.e., randomly or cyclically) the
order of the addresses in its responses to queries.  Combined with a
short TTL, this should tend to spread the load over all the servers for
the large host, instead of filling the first server to capacity before
going on to the next.  There's an implicit assumption here that given a
list of addresses for a host that are all on the same network number,
that most Telnet implementations would tend to try them in the order in
which they appear in the list.  Please correct me if that is wrong.

I also wonder if the ability to try multiple addresses is common in
Telnet implementations, especially those for MS-DOS.
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 12:43:05 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Host-down redirects?

I am one of the (probably many) people who agree with the need for 
a COOP.  It is my imperfect understanding that the PSNs can, or will,
support logical adressing.  Specifically, two or more PSN ports can have
the same name, or, a single port can have two or more names.  Such a
capability would have made things easy for you.  Regards - Craig

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 13:10:52 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Host-down redirects?


   Date: Thu, 01 Sep 88 16:02:24 -0400
   From: Buz Owen <ado@VAX.BBN.COM>

   I believe you could use 1822L logical addressing for this purpose,
   by arranging that only one host enables a particular logical
   address at a time -- i.e.  when backing up some other host.  Of
   coure you have to using 1822l headers, and be willing to change
   your host addresses, both possibly formidable obstacles.  Buz

NO! NO! NO!   If *everyone* on the Milnet had a capability for logical
addressing, and a defined mapping between an IP address and a logical
address, this would work.  However, we've still got a substantial
community of subscribers who use 1822; those who use X.25 have both
the capability and the defined mappings.  Eventually, we hope to
modify the 1822 interface to conform to the 1822L bit mappings and to
allow a vanilla 1822 host to specify a logical address without having
to change its programming.  That's a ways in the future - lots of
other things have priority.

Mike

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 14:48:44 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Host-down redirects?


     ... SIMTEL20 came back online after being down for 18 days ...  activated
     duplicate logins on our sister site ...

Logical addressing is what you might use to direct connections to an alternate
server.

1. Since tac connections are probably still done numerically by your users,
you could educate them about opening connections by name if the name server
version of TACACS is running.

2. For long-term (more than a week) outage, you could try changing your host
table entry at your domain name server (or the NIC).  Even hosts that use the
NIC host table should eventually get the address change.

3. On an arpanet (e.g. the Milnet), the PSN's support logical addressing,
both for X.25 and for 1822-AHIP.  Your name server and host tables identify
your address as a 'logical' one, such as 26.64.0.99, and you then can tell
any one (or more) of your hosts to come up with that address.  The problem
with this solution is that there are no hosts that implement 1822-AHIP
logical addressing.

4. If you were on an ethernet, you'd get logical addressing for free, and
your host would have to act as multiple addresses on a single interface.

     ... the clever solution to this problem implemented at BRL ...

Was this using ethernet addressing?

Yours for logical networking,
Mike

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 15:27:38 GMT
From:      jgh@root.co.uk (Jeremy G Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

I asked:
> The BSD listen(2) syscall (on a socket) provides for the specification
> of a queue of pending connection requests.  So does the TLI T_LISTEN function.
 
> What are the pros and cons of this functionality?  Is it merely a matter
> of the cost of copying a protocol control block versus the cost of opening
> and initialising one?  Or is there also a functional benefit?

My thanks to everybody who replied, both here and by mail.  Several people
pointed out that I said t_listen when I should have said t_bind - sorry,
my fingers were running faster than my brain....

However, nobody has answered the question that I was trying to ask.  I can't
have made a good job of the question :-)

Why does this connection queue have to be handled by the kernel?  Why couldn't
the application just open and initialise for listening (not in the BSD syscall
sense)  as many transport endpoints as it's queue needs to be long?

Opinions, anybody?

Jeremy
-- 
Jeremy Harris			jgh@root.co.uk

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 16:43:31 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Milking machines

Since the topic of communications servers has come up, it seems like a
good time to throw out my request for recommendations.  We currently
have a Bridge CS/1 with 32 ports that is hooked up to our IBM mainframe
as a milking machine.  We are talking 37x5 async ports, not protocol
converters.  Our biggest complaint about the Bridge CS/1 is that it
does not negotiate the Telnet echo option correctly.  It says that it
will echo and then expects the host to do it.  The problem is that our
host does not echo, so the user must manually turn on echoing at their
end.  The other problem with the CS/1 is that it is only 32 ports.  We
will need a lot more in the future.  The CS/1 can be configured with 64
ports, but then does not provode all the modem control signals that we
need.  So far, 3Com/Bridge has not been very responsive in coming up
with a solution to the echo problem.

The cisco ASM communications server sounded attractive because it
supports up to 96 ports and they say that they do the echo negotiation
properly.  So we got one in to test and found out in trying to figure
out how to configure it that it does not support all of the necessary
modem control signals.  We need DSR and DCD to come up at the start of
a connection and go down at the end.  A connection must be broken when
the host lowers DTR.  And CTS must be lowered when the communications
server can't accept more data from the host (our host doesn't support
XON/XOFF flow control).  Unfortunately, the cisco box can't do flow
control on CTS when it is doing the other modem control signals.  So we
sent it back.

So, does anyone have any recommedations for other communications
servers for us to look at?  We need lots of ports, proper echo
negotiation, support for break signals, and full modem control,
including hardware flow control.  Don't tell me to junk the mainframe.
:-)

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 18:36:00 GMT
From:      KONDA@VM.CC.PURDUE.EDU (Suresh Konda)
To:        comp.protocols.tcp-ip
Subject:   (none)

I would appreciate receiving mail etc. concerning tcp/ip.  Thank you.

Suresh L. Konda
Krannert School of Management
Purdue University
West Lafayette, IN 47907
317 494-4513

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 18:53:44 GMT
From:      philipp@MOE.MCRCIM.MCGILL.EDU (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Mike (or anyone else),

	Care to set me straight on X.25 and its place in the ISORM?
I have always found this a dilema.  If you use the D-bit (end-to-end
delivery confirmation), it becomes a transport protocol (or tries to
be anyway).  But in other respects, it is deficient as a transport
protocol: for example, it provides no transport level addressing;
sessions must use the network level addressing and "hints" in the
call request user data field (sigh).

	As for its network (and data link) layer, it provides services
that should be going on at the transport layer, such as acknowledgement
and flow-control.  So aesthetically, how does it "stack up"?

Thanks,

-Philip

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 18:58:04 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   It's in print, so it must be true...


Does anyone know who edits/funds/controls Network World? They've been
shoving anti-TCP articles on their front pages since their first
issue. These are definitely folks with a (blind) mission. Murdoch?
Jim and Tammy?

	-Barry Shein, ||Encore||

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 88 20:45:31 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Marshall--

So impressed am I by your philosophical breakthrough that I can't
bring myself to wait to find Phil Karn's offending msg (which doesn't seem
to have shown up on the "bulletin board" through which I read TCP-IP yet)
before congratulating you on it.  By dismissing any objections about what's
wrong and assuring the objectors that they don't understand what's right,
you've hit upon an extremely powerful concept:

       The Whole Has Nothing To Do With The Sum Of Its Parts

Profound.

I now understand that if you gild the ricebowl heavily enough, it doesn't
matter at all that the top few coils of clay were intertwined rather than
slavishly stacked one on the other according to the pious precepts of
Pottery.  TWHNTDWTSOIP, after all.  And what a relief:  No more worries
about the Session functionality that ought to be performed AFTER the
Presentation functionality on the way into the Host but BEFORE it on
the way out--in, say, multi-cast teleconference settings--for me.  No
more nagging doubts over whether the Common Application Service Element
isn't just a way of evading the n-entities/n-1 entitites prescription
when certain Presentation functionality needs to be performed DURING
Application functionality rather than before or after (depending on
whether you're going into or out of the Host), nor over whether the
Association Control Service Element isn't just a euphemism for doing
Session functionality IN the Applications layer, either.  Those weren't
Epicycles, they were just irrelevancies, and I'll never have to say
"It should be Layer [sic] 5-7" again.

Silly me, ever to have thought that what's obviously a hammer was a
Swiss Army knife, or that if you have to drive screws with a hammer it's
at least better than attempting to drive screws with a kinky Slinky.
Yup.  I've seen the light.  No more vain exercises in technoaesthetic
criticism or fruitless demands for philosophical consistency instead of
political compromise for me.  Why, since you've assured me that The Whole
Has Nothing To Do With The Sum Of Its Parts, I've even come to realize
that as many as five of the seven apples in your little barrel can be
rotten and you can still have ... applesauce!

     dazzled cheers, map
-------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 88 03:45:39 GMT
From:      dave@arnold.UUCP (Dave Arnold)
To:        comp.protocols.tcp-ip
Subject:   sendmail and SMTP

Hello,

I want to run SMTP on System V.  Is this possible?
Do I need sendmail?  If so, just what does sendmail
give me that smail doesn't?

Why do I ask?  We are running VAX/VMS with Micom-Interlan
TCP/IP package which includes SMTPD hooked-up on a LAN
with Digital Sound Voice servers running a variant of System V.1.
It just isn't clear to me how you can get SMTP running on System V,
and how sendmail fits in to the picture.

For those of you brave enough to reply... Thanks!
-- 
Dave Arnold
dave@arnold.UUCP	{cci632|uunet}!ccicpg!arnold!dave

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 88 17:29:56 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Michael --

    In some dusty file on me in Washington, D.C., there is a directive
which states:

	DO NOT ALLOW THIS PERSON NEAR NUCLEAR WEAPONS.

It is in circumstances like this that I can appreciate why this is so.
Otherwise, I would certainly have atomized you by now!

From Karn's perspective (in a message which you admit you hadn't seen),
he asserted that you do not need a session layer and that the
presentation layer should be application-specific.  This points
precisely to my hammer and nail analogy:

You TCP/IP purists are so convinced that you have the world's most
wonderful transport protocol (which is probably true, certainly it is true
in comparison to TP4) that you have spent relatively little time on the
things that go above TCP.  Yes, you have applications, and yes they work
(fairly well, given their limited scope), but there is very little
unified thought behind them other than that age-old maximum, "Use TCP raw".

The OSI people are miles ahead of your ARMites in this regard.  There is
where the "whole picture" I was referring to is, rather than what you
took out of context.

With regards to those little nagging questions you have.  Now I must
congratulate you for having left your ARMrest in even considering such
issues.  You are showing quite a bit of profound thinking.  I happen to
disagree myself with the way some of the upper-layers of OSI is
arranged.  Regardless, at least they have a framework, it does work
(at least I use it quite heavily and it works for me), and we can learn
from that.

I'd comment on the rest of your message, but I will wait until after
you've read Karn's original message.  No point in attacking you unjustly...

/mtr

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 05:13:05 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   It's in print, so it must be true...

Hmm - I've noticed the balance swinging in recent issues - but you've
got to realize they write for the *commercial* world, and since no
*big* vendor has embraced TCP/IP (touched, yes, embraced no) they have
little interest in covering it.  Also, from my one brush with the
reporters, these are NOT network guru type people - these are
journalists specializing in technical reporting.

Mike

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 06:13:00 GMT
From:      brennan@merk.UUCP (Rich Brennan)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?


>map: Tastes Great!
>mtr: Less Filling!
>map: It's a floor wax!
>mtr: It's a desert topping!
>map: It's a candy mint!
>mtr: It's a breath mint!

etc.
etc.
etc.

  Into which "reference model" do you think this "discussion" fits?

The Lite Beer RM:

	Rodney Dangerfield: I back the "ARM" because it doesn't get
		any respect.
	Bob Eucher: I favor the OSIRM because the government put it in
		the "front row".

The World Wrestling Federation RM:

	Hulk Hogan: Oh yeah? Well I bet my 7 layer RM could just crush
		your RM.
	Andre the Giant: Think so?!?!? My RM will hit your RM so hard your
		whole protocol stack will die!


The Three Stooges RM:

	Moe: "Spread out!
	Larry: Hey Moe, leave him alone!
	Moe: C'mere, porcupine, I'll tear your tonsils out!


(just kidding, fellas :-)
Rrrrrrich.
-- 
...!{uunet,linus!alliant}!merk!root			Rich Brennan

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 06:46:05 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun netstat traffic for DECNet

In article <530@suned1.UUCP> efb@suned1.UUCP (Everett F. Batey II) writes:
>Is there any experience using Sun network tools, traffic, netstat, etc to
>monitor and diagnose DECNET or DEC LAT, DEC PCSA?  Do any of the Sun 
>services know how to identify the DEC protos?

Etherfind in SunOS 4.0, and etherfind and traffic shipped with Sunlink
DNI 5.0 understand DECnet packets, and will display what DECnet node
address they are from. LAT (definetly) and PCSA (presumably) are DEC
propritary protocols which these tools do not handle.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 12:06:00 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        news.groups,comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.lans,comp.unix.wizards
Subject:   Proposed creation of comp.protocols.nfs

A number of people on the NFS mailing list (nfs@bcm.tmc.edu), together
with a few who are effectively out of reach of it, have proposed
that a newsgroup comp.protocols.nfs be created to provide a broader
forum for discussion of NFS, RPC/XDR and related issues. For instance,
I'd like to see discussions which include such things as FTAM, Greenberg &
Keene's NFILE, RFS, Domain, and the Andrew file system. A quick scan of
comp.protocols, comp.dcom, selected comp.sys groups and comp.unix
showed 19 articles with a subject field which included "[Nn][Ff][Ss]",
with a further 6 in comp.sys.sun (sun-spots). (We expire "comp." after
14 days.) Together these would suggest that comp.protocols.nfs would have
an acceptable traffic level. For now, I see no need to make it a
moderated group.

As usual, please mail comments to me. I'll summarize to the net and (if
the response is positive) issue a call for votes. Please mail
directly, rather than using 'r': my Usenet path is usually horribly
circuitous...

Geoff

PS Various terms used above are trademarks, and the appropriate
squiggles, superscript microcharacters and attributions should be understood.

-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |Did you remember to stick your disclaimer |
UUCP:{hplabs,decwrl...}!sun!garnold|stamp here to qualify for your free gift? |
ARPA:geoff@sun.com                 +------------------------------------------+

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 12:52:12 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        news.groups,comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.lans,comp.unix.wizards
Subject:   Re: Proposed creation of comp.protocols.nfs

Re-reading my posting, I feel a clarification is in order. I would
expect the primary purpose of comp.protocols.nfs to be discussions
of practical NFS issues, including bugs, product availability, proposed
enhancements, interoperability, etc., Comparative discussions of various
distributed file systems would definitely be of secondary importance. (For
people who want to relive the NFS vs. RFS flame wars of a year or two
back, I'm sure somebody has archived them.)

Here are some of the NFS-related topics recently posted to the net:
	Update on "NFS and TCP/IP for the Mac"
	A NFS file server on the IBM PC
	NFS security
	QEMM, and DesqVIEW, and PC-NFS, and findings...
	Problems with groups under PC-NFS
	NFS for IBM PC (*not* PC-NFS)
	Integrating Apollo into Sun NFS
	NFS, A/UX and the Mac II
	MacNFS's file mapping.
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:geoff@sun.com                 +------------------------------------------+

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 14:59:00 GMT
From:      nick@tarantula.spider.co.UK (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

In  <13887.589071350@twg.com>, : Marshall Rose <mrose@twg.com>
responds to Phil Karn

> 
> Phil, you make me sad.  But now I will make you angry!
> 
> Neither you nor I are unbiased observers.  In as much as you have given
> your slanted view (i.e., no need for session, presentation should be
> application-specific, etc.), I might as well give my slanted views.

[ Most deleted for brevity, etc]

> The problem is that you snipe at the parts you don't like, rather than
> trying to appreciate the entire picture.  On the whole, OSI has a lot of
> good points going for it, even though some of the actual parts are
> pretty lousy.
> 
> /mtr
> 
The problem I (and I suspect, a lot of the TCP community) have, is that
the ISO group have wantonly re-invented, or changed layers which work
perfectly well - the change of the Ethernet type field being a classic example.

There is a lot good about some of the higher level stuff - but there's a lot
bad as well.

TCP satisfies most of the requirements of an international
standard - it works, and it's non-proprietary.  It has a shortcoming in that
its network layer does not fit in with the c 1920 style of communication
understood and supported by most of the PTTs.

ISO has made a lot of people a lot of bucks running seminars; it has yet to
make anyone a worthwhile communication service.

Meanwhile, the PR engine has managed to give it enough momentum that millions
of Pounds/Dollars are being spent discarding working systems in favour of
(as yet) unproven ideas.

Sorry if this is a bit strong, but it is late on a Friday ... ah well.


Usual disclaimers apply - I'm sure the company line is different.

Nick Felisiak	(nick@spider.co.uk)  (nick%spider.co.uk@uunet.uu.net)

Spider Systems Ltd
Edinburgh
Scotland

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 15:03:56 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   A 'horror story' for the books

Ok, maybe this one should have been obvious.  But if it hadn't been
for Doug Kingston giving me a short list of things to check over I
would've been a *lot* longer in finding the problem.  (*Thanks*!)

The short description is that a number of applications (ftp, smtp, etc)
stopped working between some of our machines after switching our
vaxen over to Ultrix v2.2 (from MtXinu 4.3bsd + NFS -- a step backward
if you ask me, but it's a looong story).  A question to the mmdf
mailing list (at the time I knew only that smtp didn't work) elicited
a reply from Doug that he thought it was more likely TCP/IP differences
and to check things like trailers and MSS ...  A check found that sure
'nuff we had some machines with trailers and some without.  Switching
off trailers on the interface made the applications work again.

I've got a couple of questions for the assembled experts:

1. Why did things continue to sort-of work between the conflicting
   machines?  I haven't looked at the code yet, but my understanding
   of the rfc is that ALL packets will be trailer-ified when going
   out a trailer link (or on 4.3bsd, out a trailer link AND when
   the host in question negotiated trailer use).  If ALL the packets
   were trailer-ified then the hosts would be seeing data where they
   were expecting header data and get all confused.
2. Why does Sun not recommend trailers?  Do they use a different
   page size than vaxen?  Or is it -- in general it's not good to
   use trailers on machines other than vaxen or it's not good to use
   trailers in a mixed environment?
3. Is there any financial aid and/or cheaper rates for a student
   who wants to attend Interop '88?

The following is the long version.  It's the report which I wrote up
for all the networking people on campus.



- Date:     Thu, 1 Sep 88 17:11:33 EDT
- From:     David Herron E-Mail Hack <david@ms.uky.edu>
- To:       uk-net-people@ms.uky.edu
- Subject:  trailers
- Message-ID:  <8809011711.aa06222@g.e.ms.uky.edu>
- 
- Oooo boy, the tiny things that'll cause problems ...
- 
- We've had a confusing problem over here since converting to Ultrix,
- that some of the programs would work to/from Ultrix machines and other
- times they wouldn't.  Like, an outgoing smtp connection would work fine
- until it sent out that trailing '.' whereupon it would hang.
- 
- Some asking around led to a suggestion to check trailers, MSS (Max
- Segment Size) and a few other options.  Some checking around in the
- code of the affected programs revealed no non-portable code which
- Ultrix broke.  Ultrix was, fortunately, enough alike (still) BSD that
- things worked as they did under BSD.  Albeit with an older technology
- of TCP/IP.  Eventually I ended up at the trailers suggestion.
- 
- What's a trailer?  Well, all it says in the manual page is some
- mumbling about changing the layout of IP packets to reduce the amount
- of copying that's involved.  They are documented in RFC893, and related
- rfc's are 984 & 894 which cover the details of doing IP across ethernet
- like mediums.
- 
- The trailer idea is to fix the size of the data portion of the IP
- packet at some multiple of the page size of your machine.  Since the
- idea was originally developed at UCB for 4.2, the size is 512 bytes or
- some multiple (The page size on a Vax).  The information which would
- normally be at the head of the packet (IP header information like
- to/from addresses, packet size & etc) are moved to the end and are now
- called 'trailers'.  There is also two other things added to the trailer;
- a protocol type field and a trailer length field.
- 
- Unfortunately they didn't do anything intelligent originally like
- negotiate use of trailers on a per host basis.  Instead trailers
- are either on or off on a per interface basis, and is done at
- boot time when ifconfig is run.  UCB's next version did do
- negotiation as part of ARP but in the meantime the 4.2 version
- of TCP/IP became part of many systems, many of which we have
- here on our ethernet.
- 
- Looking at the various manual pages I have access to:
- 
- 	4.3bsd		negotiable per host (default=trailers)
- 	WIN/TCP		non-negotiable (default=trailers)
- 	sun v3.4	non-negotiable.  also 'not recommended'
- 			because it's host dependant. (default=trailers)
- 	ultrix 2.2	non-negotiable (default=trailers)
- 
- Some of our machines had trailers turned off and some had them turned
- on.  Brian had thought it wasn't important because it was negotiated
- and turned them on ... oh well.  
- 
- One thing I'm not sure about is why things sort-of worked ... between
- two non-negotiating hosts which disagreed over the trailer issue there
- shouldn't have been *any* communication, because they disagree over
- where the 'header' information is to be kept.  Probably there is something
- else going on as well, but I'm not sure what.
- 
- For now we've turned off trailers on all of our machines.  Would the rest
- of you look into your configurations and tell me which ones can do trailers
- to begin with, and which ones can negotiate it.  (The negotiation is part
- of the ARP protocol).  This is another of those TCP/IP options which needs
- to be agreed upon across our whole ethernet.  er.. Well ... if someone were
- to have an IP gateway between their net and the campus net, they would be
- able to do what they want on their net.
- 
- Maybe we want to run with trailers on everywhere.  But we need to make
- sure that it makes sense for all the machines...
- --
- <---- David Herron -- The E-Mail guy                         <david@ms.uky.edu>
- <---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
- <---- Problem: how to get people to call ...; Solution: Completely reconfigure 
- <---- your mail system then leave for a weeks vacation when 90% done.
-- 
<---- David Herron -- The E-Mail guy                         <david@ms.uky.edu>
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- Problem: how to get people to call ...; Solution: Completely reconfigure 
<---- your mail system then leave for a weeks vacation when 90% done.

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 88 15:33:42 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        news.groups,comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.lans,comp.unix.wizards
Subject:   Re: Proposed creation of comp.protocols.nfs

I didn't know there *was* an nfs mailing list ...

I'll support creation of the newsgroup and like the name ... when
does the voting start?
-- 
<---- David Herron -- The E-Mail guy                         <david@ms.uky.edu>
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- Problem: how to get people to call ...; Solution: Completely reconfigure 
<---- your mail system then leave for a weeks vacation when 90% done.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 88 02:32:16 GMT
From:      alan@metasoft.UUCP (Alan Epstein)
To:        comp.protocols.tcp-ip
Subject:   EtherNet cabling recommendations wanted

we are about to run a thin-net cable across the street from
our server to link a client workstation. the distance is
approximately 400' through a narrow conduit, then another
150' or so, via the telephone switching center. the other
end also passes the telephone switching room, but is much
shorter (30').

what type of cable would be practical, and what might be
optimal. i would assume we need shielded coaxial, but does
it have to be extra shielded? what might this type of cable
cost? i've heard the name beldon, but don't know what
that is or whether we need it?

any suggestions?

PLEASE SEND REPLIES VIA E-MAIL.

thanks.

-----------------------------
Alan Epstein
Meta Software Corp                   UUCP:  ...bbn!metasoft!alan
150 Cambridgepark Dr        Internet/ARPA:  alan%metasoft@bbn.com
Cambridge, MA 02140  USA
-----------------------------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Sep 88 08:49:02 CDT
From:      Ron Briggs <ZRON%UTDALVM1.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: ANNEX II Terminal Server Experiences?

      I don't know, to be honest. It's probably a I seeing we have had it
for a year. John might know.
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Sep 88 15:07:45 -0400
From:      "Alan R. Hill" <ahill@CC5.BBN.COM>
To:        Brian Ruptash <mmm!com50!dpmizar!bar@UMN-CS.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Test Specifications
Brian,
	As you may recall, I mentioned at the meeting that BBN has
a very flexible capability of testing host implementation of a variety
of protocols.  BBN has the NVLAP tests but cannot implement them immediately
because we do not have the requisite operating system they require.  We
do have the DDN X.25 certification tests and we have applied with DCA
and NBS for certification licensing.  If you have any interest in our
capabilities, please let me know.

Regards,
Alan
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 13:49:02 GMT
From:      ZRON@UTDALVM1.BITNET (Ron Briggs)
To:        comp.protocols.tcp-ip
Subject:   Re: ANNEX II Terminal Server Experiences?


      I don't know, to be honest. It's probably a I seeing we have had it
for a year. John might know.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 15:43:39 GMT
From:      billn@kinetics.UUCP (Bill Northlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

In article <8809012053.AA08613@ETN-WLV.EATON.COM> mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes:
>I would like to invoke Robert's Rules and move that this discussion be closed.
>The discussion has degenerated to the point that it is only fanning *flames*

I vote nay.  Lots of stuff on the net (uucp, anyway) may be drivel, but
a spirited exchange between map and mtr is worth a few extra hittings of the
space bar to me.  

>... OSD (Office of the Secretary of Defence) has mandated the use of the ISO
>protocol suite for interoperability between the US and its allies.

They mandated use of Ada about 10 years ago...
/billn

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 16:04:34 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   trailers and their subtleties

Trailers only happen when the amount of data is a multiple of the page
size of the machine (512 bytes on a VAX).  This is because their
(alleged) benefits have to do with replacing mbuf copies with dinking
the memory management to copy pages on the VAX.  These benefits only
accrued if all of the data was page aligned and page length.

Most packets are not 512 bytes of data, so you open the connection,
give the command (maybe do a more on telnet), and wham!, you die the
trailer death.

Sun does not reccomend trailers because they don't even offer their
(alleged) benefits on a Sun.  They depended on the fact that a VAX has
two memory maps.  One is the CPU memory management.  The other one is
the Unibus map, which mapped pages (512 bytes) in Unibus slave address
space to pages in main memory.  This gave them the precision needed to
play the page alignment games.

The Sun DVMA system does DMA through the same MMU as the CPU uses.
This is cheaper (Sun always designs hardware to a price), but not as
flexible.  Moreover, the routines in the VAX that did the page based
hacking (if_rubaget, if_wubaput) aren't even there on the Sun.  This
is because all of their Ethernet devices have either been memory
mapped (the 3Com and Sun/Intel Multibus boards), or DMA using kernel
virutal addresses (all of the on-CPU Ethernets).  The VAX routines
eased writing Unibus network drivers.  (Unfortunately, their absence
on the Sun makes writing VMEbus DMA device drivers rather nasty.)
Sun uses different strategies than page dinking to speed copying,
namely enormous mbufs with an mbuf free upcall.

When a Sun gets a trailer, it has to copy the blasted trailing header
back to an mbuf at the front of the chain.  It is distinctly slower to
receive trailers on a Sun.

Trailers are best disabled.  They cause too many problems, and there
are disagreements on whether the performance advantages on the VAX are
real or were measurement artifacts.  The hosts RFC will cover
trailers.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 17:04:01 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

In article <8809021858.AA14697@bu-cs.bu.edu>
 bzs@BU-CS.BU.EDU (Barry Shein) writes:
>
>Does anyone know who edits/funds/controls Network World? They've been
>shoving anti-TCP articles on their front pages since their first
>issue. These are definitely folks with a (blind) mission. Murdoch?
>Jim and Tammy?
>
>	-Barry Shein, ||Encore||

	Hmm, I hadn't really noticed any trends.  Seems to me I've
read about as many "TCP/IP taking networking world by storm!" articles
as I have "SNA taking networking world by storm!" and "OSI predicted
to take networking world by storm very soon!" articles.  I have
noticed a lot of NSFnet bashing this summer, but also elsewhere, so it
isn't limited to NW.

	I think CW Communications started Network World as a spinoff
from ComputerWorld, although I find no trace today of CW in the NW
copyright box on page 2.

	I wouldn't expect to find a conspiracy within NW, just a lot
of harried, overworked, underpaid, and inexperienced editors and
reporters and contributors, all trying to fill up a lot of pages with
text and advertising.  And that's the crux of the whole problem.  Not
enough time and money to do a really top-notch job.  Of course, by way
of disclaimer, this problem is by no means limited to NW, it affects
all the publications that work the same way- free distribution paid
for by advertising.  (ConneXions is an example of a counter-trend and
you can see the difference in number of pages, subscription cost per
page, quality, and accuracy.  But no one is getting rich either in NW
or ACE.)

	An awful lot of the stuff you read is just regurgitated press
releases dressed up with a few quick phone calls and enough editing to
fit the article in the space available.  As long as you use the
information therein according to the source, NW can be a useful tool
for getting the word on new product introductions, upcoming
conferences, results of standards committee meetings, and of course
the advertising pages which announce new products and offerings in a
slightly more transparent way.

	I sympathize with the staff at NW, but I don't excuse the
sloppiness.  My feelings are that if we could address the issue of
copyright and compensation for electronically distributed
information and electronic distribution of formatted graphics and
text, ala Postscript (tm), we could solve the problems of narrow-cast
publishing by moving to electronic publishing.  Until that day, I am
thankful to be a part of the Internet newsreading public.

	Those that I do feel are culpable abusers of the public trust
are those columnists that write about issues that affect sales of
their books and software.  The issue of computer viruses is a case in
point. I feel that publications should screen their columnists, no
matter how well known and popular, and avoid publishing authors in the
context of regular columns who have products to sell, with sales that
can be affected by what they say in their columns.

	If you disagree, I think it would be interesting to track some
of these anti-TCP articles in NW and elsewhere and see if we can spot
a trend.  By way of example, a while back a series of little
news-spots and pie charts started appearing in Data Communications, NW
and probably elsewhere, all attributed to one source about how
token-ring networks were surpassing Ethernet networks in various
measures.  All calculated to give the impression that a) either
Ethernet was dead and you better install TR or b) TR was socially
acceptable :-)  Anyone remember seeing these?  This is a PR campaign
originating from one single source with a particular agenda in mind.
Is this insidious?  No more than what the White House does to the
White House press corps.  I don't blame the media for parroting, I
just try to figure out who is behind some of what I read and then
apply the appropriate derating factors.

	If anyone has any similar stories they recall seeing, post
something.  Maybe we can figure out if anyone in particular has a
hidden agenda going.  Perhaps there is a contributor or editor at NW
that has a parrot on his shoulder.  Once you know the name and
affiliation of the parrot, the game's up.

	Kent England, BU

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 18:49:04 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Re:  TOS field in IP packet

I don't recall seeing any response to this, and the subject is of current
interest to me.  I am working up an analysis of options for dealing with
certain kinds of potential "requirements" for network usage accounting
and one of the approaches to be considered for internetwork reverse
charging might involve using one of the two reserved bits to which you
refer.  I believe they are still officially reserved and supposed to be
0.  I have contributed to appropriate people the thought that it would
be a good thing for a TCP/IP implementor to make provision for setting
and reading the two reserved bits even before any meaning is defined for
them.  It's just as important to have it be settable at TCP/application
interface level as at IP/transport interface.  One should also consider
the possibility that the reserved TOS bits may require a negotiation
analogous to precedence.

If anyone out there is working in the same problem domain I am, or can
point me to such people, please drop me a note.  I am especially
interested in finding out about anything in the OSI arena subsequent to
the Accounting Management Service Definition, TC97/SC21 N981 (alias
TC97/SC21/WG4 N117).  I've already queried the ISO mailing list but no
news so far...

Bill Barns / MITRE / barns@gateway.mitre.org / (703) 883-6832

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Sep 88 00:57 CST
From:      Derek Andrew <ANDREW%SASK.USask.CA@CORNELLC.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: EtherNet cabling recommendations wanted
We run Beldon 9907 and are happy.

derek andrew

From:   IN%"TCP-IP@SRI-NIC.ARPA"  6-SEP-1988 19:43
To:     'Derek Andrew' <ANDREW@SASK.USask.CA>
Subj:   EtherNet cabling recommendations wanted

Received: from ADMIN.BYU.EDU by SASK.USask.CA; Tue, 6 Sep 88 19:43 CST
Received: by BYUADMIN (Mailer X1.25) id 8208; Tue, 06 Sep 88 11:27:08 MDT
Date: Mon, 5 Sep 88 02:32:16 GMT
From: Alan Epstein <metasoft!alan@BBN.COM>
Subject: EtherNet cabling recommendations wanted
Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN.BITNET>
To: 'Derek Andrew' <ANDREW@SASK.USask.CA>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments: Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
X-To:         tcp-ip@sri-nic.arpa

we are about to run a thin-net cable across the street from
our server to link a client workstation. the distance is
approximately 400' through a narrow conduit, then another
150' or so, via the telephone switching center. the other
end also passes the telephone switching room, but is much
shorter (30').

what type of cable would be practical, and what might be
optimal. i would assume we need shielded coaxial, but does
it have to be extra shielded? what might this type of cable
cost? i've heard the name beldon, but don't know what
that is or whether we need it?

any suggestions?

PLEASE SEND REPLIES VIA E-MAIL.

thanks.

-----------------------------
Alan Epstein
Meta Software Corp                   UUCP:  ...bbn!metasoft!alan
150 Cambridgepark Dr        Internet/ARPA:  alan%metasoft@bbn.com
Cambridge, MA 02140  USA
-----------------------------
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 19:07:45 GMT
From:      ahill@CC5.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: Test Specifications

Brian,
	As you may recall, I mentioned at the meeting that BBN has
a very flexible capability of testing host implementation of a variety
of protocols.  BBN has the NVLAP tests but cannot implement them immediately
because we do not have the requisite operating system they require.  We
do have the DDN X.25 certification tests and we have applied with DCA
and NBS for certification licensing.  If you have any interest in our
capabilities, please let me know.

Regards,
Alan

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 88 20:23:21 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Philip--

Many thanks for the great straight-line (which came at a particularly
good time, since I'm enjoying a temporary remission from the smoking-ban-
engendered chemical lobotomy at the moment, owing to the finally decent
weather where I am, which means I don't come back in from taking the
medication of choice for my condition more tired than when I went out,
for a delightful change).

How do _I_ think X.25 "stacks up" against the ISORM _aesthetically_, you
ask?  I don't.  I think it throws up.

Turning from the aesthetic to the technical, you do seem to me to be on
the right track in noting that the "D" bit is rather L4-ish, or at least
not very L3-ish.  The other alphabits (M and Q, as I recall) are also
hard to swallow.  Indeed, despite the ISORM's stated precept that protocols
must be peer to peer, the D bit seems to allow a given Host ("DTE") X.25
protocol interpreter to interact with the remote Comm Subnet Processor
("DCE") X.25 PI, the M and Q bits allow it to interact with the remote
Host/DTE X.25 PI, and most of everything else allows/requires it to interact
with the proximate CSNP/DCE's X.25 PI--always assuming I've remembered
aright which is DTE and which DCE.  That situation, as I've observed in
passing elsewhere, sure looks like a POLY-PEER to me.

So there's no need to get into any lawyering over whether X._7_5 is or
isn't "Open", or to dredge up any of the other X.25-X.75 inelegancies,
to conclude that X.25 does not instantiate ISORM principles at all
scrupulously.  The poly-peerage alone is evidence enough.  (More
technoaesthetic points on the topic can be found in RFC 874, or even
in Chapter 9 of _The Elements of Networking Style_, where you not only
get the Cover Cartoon and Prefatory Afterthoughts that don't come with
the RFC, but you'll also get a useful suggestion as to how to visualize
a poly-peer that I really shouldn't mention in "public".)

Nor should the disparity be surprizing, viewed historically.  To the
best of my knowledge, belief, and personal recollection, the claims that
X.25 "is" ISORM L3-1 were advanced eight or so years ago by the ISORMites
(i.e., those panacea pedlars whose "ricebowl" was going to be the ISORM--
not to be confused with the ISORMists, who, even if I find them to be
backing the wrong horse [or the wrong end of the horse, if you prefer], do
seem to be trying to work within the international standards bodies to do
networking rather than ricebowl-gilding).  The idea was to support their
claim that the ISORM Suite was "nearly here" by pointing to the "already
here" L3-1.  (They did, as a matter of fact, have me fooled for a year
or two.)  The key fact is that the ISORM is the product of the International
Standards Organization, whereas the X.25 stuff comes from CCITT, an entirely
different body which consists of representatives of "the PTTs" (or Postal,
Telephone, and Telegraph state monopolies [in most parts of the world]).

More some other time.  I must go raise my norepinephrine levels now.
Perhaps somebody else can take up the tale of how ISO and CCITT currently
stand in their attempts to reconcile the ISORM and X.25; all I "know"
about it is that some ISORMist friends told me a year or three ago that
it had been deemed politcially desirable to (appear to, at least) do so.

   grateful cheers, map
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 08:22:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re: Multiple TCP/IP servers on one host
There seems to be some convergence on the use of the domain name service
ip address list, as a means of accessing multiple interfaces (with one 
interface per milking machine) to the same service host.  A couple of
notes, however, have mentioned reliance on a feature that is not
supported:  having the domain name service select which ip address to 
give you, thereby having the DNS do the randomization necessary to give
load-leveling.

Selection of the "correct" IP address must be done by the client (e.g.,
telnet).  The DNS has no way of knowing what use you will put the information
to and it has no way of distinguishing multiple milking machines from
multiple connections to different parts (i.e., different networks) on
an internet.

Dave

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Sep 88 09:30:34 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   last call....

    As an experiment, the next issue of ACM SIGCOMM Computer Communication
Review is including technical reports in its listing of recently published
works on computer networking.

    The next issue of CCR is going to press next week.  Anyone who has
published a technical report on computer networking *since July 1st*
that would like to have that technical report listed in the CCR bibliography
should send me an e-mail citation of the report by Friday the 9th.
The citation should include author's names, title, issuing department
and/or university, and a brief abstract.

Thanks,

Craig Partridge
craig@nnsc.nsf.net
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 06:57:00 GMT
From:      ANDREW%SASK.USask.CA@CORNELLC.CCS.CORNELL.EDU (Derek Andrew)
To:        comp.protocols.tcp-ip
Subject:   RE: EtherNet cabling recommendations wanted

We run Beldon 9907 and are happy.

derek andrew

From:   IN%"TCP-IP@SRI-NIC.ARPA"  6-SEP-1988 19:43
To:     'Derek Andrew' <ANDREW@SASK.USask.CA>
Subj:   EtherNet cabling recommendations wanted

Received: from ADMIN.BYU.EDU by SASK.USask.CA; Tue, 6 Sep 88 19:43 CST
Received: by BYUADMIN (Mailer X1.25) id 8208; Tue, 06 Sep 88 11:27:08 MDT
Date: Mon, 5 Sep 88 02:32:16 GMT
From: Alan Epstein <metasoft!alan@BBN.COM>
Subject: EtherNet cabling recommendations wanted
Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN.BITNET>
To: 'Derek Andrew' <ANDREW@SASK.USask.CA>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments: Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
X-To:         tcp-ip@sri-nic.arpa

we are about to run a thin-net cable across the street from
our server to link a client workstation. the distance is
approximately 400' through a narrow conduit, then another
150' or so, via the telephone switching center. the other
end also passes the telephone switching room, but is much
shorter (30').

what type of cable would be practical, and what might be
optimal. i would assume we need shielded coaxial, but does
it have to be extra shielded? what might this type of cable
cost? i've heard the name beldon, but don't know what
that is or whether we need it?

any suggestions?

PLEASE SEND REPLIES VIA E-MAIL.

thanks.

-----------------------------
Alan Epstein
Meta Software Corp                   UUCP:  ...bbn!metasoft!alan
150 Cambridgepark Dr        Internet/ARPA:  alan%metasoft@bbn.com
Cambridge, MA 02140  USA
-----------------------------

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 13:30:34 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   last call....


    As an experiment, the next issue of ACM SIGCOMM Computer Communication
Review is including technical reports in its listing of recently published
works on computer networking.

    The next issue of CCR is going to press next week.  Anyone who has
published a technical report on computer networking *since July 1st*
that would like to have that technical report listed in the CCR bibliography
should send me an e-mail citation of the report by Friday the 9th.
The citation should include author's names, title, issuing department
and/or university, and a brief abstract.

Thanks,

Craig Partridge
craig@nnsc.nsf.net

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 15:22:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

There seems to be some convergence on the use of the domain name service
ip address list, as a means of accessing multiple interfaces (with one 
interface per milking machine) to the same service host.  A couple of
notes, however, have mentioned reliance on a feature that is not
supported:  having the domain name service select which ip address to 
give you, thereby having the DNS do the randomization necessary to give
load-leveling.

Selection of the "correct" IP address must be done by the client (e.g.,
telnet).  The DNS has no way of knowing what use you will put the information
to and it has no way of distinguishing multiple milking machines from
multiple connections to different parts (i.e., different networks) on
an internet.

Dave

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 16:36:28 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Marshall--

"I would certainly have atomized you by now!"  you say?  How scholarly.
Even if Robert's Rules did apply here, I'd have a final point of personal
privilege coming, so I'll ignore Merton Campbell Crockett, smile most
aprreciatively at Rich Brennan, and go along with Bill Northlich.  Indeed,
just to demonstrate that threats of nuclear retaliation don't intimidate
me, I must go one more round, even though I do believe that if you'd read
my last msg more carefully you'd have felt like the atomizee rather than
the atomizer.  I, after all, wasn't the one who said "OSI (levels 3&4) is
still quite silly at times" and "some of the actual parts are pretty lousy"
while complaining about those who weren't "trying to appreciate the entire
picture"; I merely called you on it.

Phil Karn's msg--which I presume is what made you "sad", not Phil himself,
even making due allowances for your rhetorical practices (which do take me
back to the old days when I was teaching Freshman Comp. and the book called
them Propaganda Techniques)--turned out to be no surprize when I saw it.
My reading of it is that he deplores the hypocrisy of those ISORMites who
tout The RM in public while the protocol designers flout it in private, as
I deplore it too, of course.  Why else would his climactic paragraph say
"But does ISO ever revise its preconceived ideas and admit its mistakes?
Of course not.  It just covers them over with ever more paper and
ad[vertizing] hype[rbole]."?

(Note, by the way, that it's a PT to say I "admit" I hadn't read it when
I sent my last msg.  Actually, I SAID I hadn't read it.  Nor did I need to,
since I could deal perfectly well with your response on its own demerits,
given that what you'd said about there being problems with some of the
constituents but "TCP extremists" [another PT] didn't understand the
whole led directly to my apparently too effective restatement.  [In case
you're wondering, yes, sarcasm is viewed unfavorably by some observers,
but I don't account it an out-and-out Propaganda Technique like, say, the
mud-slinging "extremists" bit.  But, then, it's been a long time since I
studied such things and it would only use up too much of my norepinephrine
reserves if I worried about them any more.]  And while I'm parenthesizing,
I should also mention that I have tried to be quite scrupulous about not
accusing you of using questionable linguistic ploys _consciously_; I
merely note that for whatever reason your msg to me was rife with them,
and, indeed, rather hope it wasn't being done consciously.)

I don't see Phil saying We've Got the Only Answer, even if he did
omit the implicit "joke" symbol after the billboard line, and I'm certain
I haven't, despite your infelicitous hammer metaphor.  What _I'm_ saying
is that it's intellectually dishonest to claim that The RM Is The
Only Answer with one side of the mouth and ignore its stated precepts
with the other side of the mouth.  Yet that's what the ISORMites are
doing.  (I still cherish hopes that you yourself are an ISORMist, by
way, even if I've never gotten a [presumably jocular] death
threat from an ISORMist--or even an ISORMite, come to think of it--
before.)

Whatever useful stuff is being attempted at Layer [sic] 5-7 by the
ISORMists, it seems quite clear to me that it's being done despite,
not because of, the RM, with it's stated adherance to rigidly hierarchical,
5<->6<->7 layering/strait-jacketing.  Nor, as best I can determine, are the
appeals to "CASE" and "ACSE" being made just because the particular, current
Session and Presentation Standards are tainted apples at best; rather, it
seems to be because you _do_ need certain Session and Presentation
functionality "right now" in certain Application settings.  (With my
usual luck, the one _Connexions_ I can't find is the one the Index tells
me has your piece on "Applications in an OSI Framework" in it, so I can't
offer you your own words, but I do recall thinking that it was still more
evidence for my years-old "Layer [sic] 5-7" complaint when I read it.)

There is, I submit, a legitimate technical interest in whether there are
_correctable_ flaws inherent in The RM, no matter who has or hasn't
embraced The RM as a matter of organizational/governmental policy.
Do you suppose we can discuss without propaganda the question of whether
or not the L5-6-7 separation _ought_ to be viewed as mandatory, both
ways (i.e., both into the Host from the net and on up, and out of the
Host from the user/Application PI and on down), in which I for one
have a long-abiding technical interest, and leave emotionalism for
some other time?  Or is my asking that just opening the door for a
non-nuclear threat like (shudder) immersion in the sauce of rotten apples?

(Jocularly intended sarcasm aside, I'm really not convinced it's worth
the norepinephrine depletion to me if we can't raise the level of debate
a few notches.  Wanna try a round or two with above-the-belt blows only,
if only for the sake of novelty?  Or shall we let it go--each, I daresay,
quite convinced that he has "won"?)

    nonetheless, cheers, map
-------

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 16:38:00 GMT
From:      mark@psauly.UUCP (marco graziano)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on STREAMS

Pisa 9/7/88

I am interested in TCP/IP implementations using the STREAMS mechanism.
In particular, is there any person or company, besides Wollongog Group,
that sells or gives such implementations ?
I am also interested in getting in touch with anybody willing to discuss
this subject.
			Marco Graziano.

---------------------------
Marco Graziano
Olivetti Systems & Networks
via Palestro 30
56100 Pisa - Italy
oliveb!psauly!mark@sun.com
--------------------------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 16:55:27 GMT
From:      jackson@manta.NOSC.MIL (William N. Jackson)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Request for SUN's RPC Library for VAX/VMS


I was wondering if anyone has ported the SUN RPC Library to VAX/VMS, using
the VAX C compiler and WIN/TCP networking libraries.  I would appreciate
getting a copy of the modified sources to the RCP library.  

Please respond to:

jackson@manta.nosc.mil      (via e-mail)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 18:53:15 GMT
From:      ferencz@cwsys3.cwru.Edu (Don Ferencz)
To:        comp.sys.att,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Need help with TCP/IP broadcast address

Hi there.

I have a rather specific problem dealing with the following variables
(those of you without any of these can safely go on):

We have the Wollongong group's Enhanced TCP/IP Package (WIN-3B) installed
on three AT&T 3B2/310 computers here in our department.  They are
networked with the campus Ethernet connection; and then on out to the
world.

The problem I have is trying to set the default broadcast address
with this particular version of TCP/IP -- the "ifconfig" does _NOT_
support the "broadcast" parameter; thus I am left to programming my own
"sockets" utility to change the default broadcast.  I have no
experience in sockets; however, I have succeeded in opening the
socket to perform an ioctl() to the "ni" driver.  Each SIOCGIFBRDADDR
(for Socket IO Configuration InterFace Get BRoaDcast ADDRess, I assume) fails
with the generic "Invalid Argument", errno = 22.  Is anyone
familiar with this particular package, and its caveats?  Has anyone
got an easier way to change the broadcast address?

This is _quite_ a special interest concern, I'm sure, so just
mail me.  Thanks in advance!

===========================================================================
| Don Ferencz                       |  "All the world's indeed a stage\   |
| ferencz@cwsys3.cwru.EDU           |   And we are merely players\        |
| Dept of Systems Engineering       |   Performers and portrayers"        |
| Case Wetsren Reserve University   |     -- Rush                         |
===========================================================================

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 21:26:36 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

Kent,

No trends to report in Network World, but I second some of your
comments.  Couple months back, NW published a front page article
on SAFENET.  The reporter interviewed (now retired) Cdr Marc
Poland who was the Navy's program manager for the standardization
effort.  The reporter went away with a manuscript that he and I had
written, in anticipation of such events.  The reason the article was
tolerably accurate was that I read an awful lot of what I had
written!  A lot of cut & paste going on.

The current issue (arrived today) has an article on comparing
throughput for various LANs.  I thought I understood the issue,
and can explain it to others.  But after reading this hack job,
I'm not so sure....:-)

Rex Buddenberg

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 88 22:16:15 GMT
From:      kerr@oodis01.ARPA (Grant Kerr)
To:        comp.protocols.tcp-ip
Subject:   Tandem 6530 terminal thru DDN TAC?

Are you aware of anyone who is using Tandem 653X asynchronus terminal 
and dialing into a DDN TAC and connecting successfully to a Tandem host
computer?  Please let me know if you know someone who is doing this or knows
what the TAC @ commands are that will allow this to function properly.  

Thanks.  (Is there a better group than tcp-ip to ask this in?)
-- 
Grant Kerr
Control Data Corporation 
INTERNET: kerr@oodis01.arpa
UUCP: ames!lll-tis!oodis01!kerr

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 08:10:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Multiple TCP/IP Servers
Darren,  your suggestion for the use of alternate, parallel routes is
well-taken; however, the accepted means of getting different routing
services from the network involves two actions by the sending host:

1.  If the sending host is multiply-connected, then different interfaces may
be used to start the packet on its way;

2.  For step #1 and again for use by every IP router, the sending application
should specify a level of service, which should be translated by the sending
host into the IP TOS field.  Therefore, network transmission software does
not need to look up into higher layers.

The catch, of course, is that the TOS field is not in general use by
sending software and is not in general use by routing software, although
there is increasing pressure on the vendor community to start setting and
paying attention to the field.

Dave

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 09:20:00 PST
From:      <art@acc.arpa>
To:        "mcvax!ukc!stc!root44!jgh" <mcvax!ukc!stc!root44!jgh@uunet.uu.net>
Cc:        tcp-ip@sri-nic.arpa
Subject:   RE: Re: Call queueing

>Why does this connection queue have to be handled by the kernel?  Why couldn't
>the application just open and initialise for listening (not in the BSD syscall
>sense)  as many transport endpoints as it's queue needs to be long?
>
>Opinions, anybody?

At least for BSD, the kernel will not allow more than one listening socket
to be bound to a particular local endpoint address, but the server wants to
be able to open multiple connections which refer to the same local endpoint
address.  To deal with this, the kernel accepts multiple connections and
queues them at the listening socket.  When an accept system call is issued,
an open connection is associated with a new socket which is then returned
to the user.  One can think of the new socket a "clone" of the listening
socket.

To allow multiple listening sockets to be bound to the same endpoint address
opens up a bunch of ambiguity problems.
(TCP doesn't know if identical services are available on all those sockets)

						Art Berggreen
						art@acc.arpa

------
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 01:37:59 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Mike --

I am willing to give up my humorous metaphors and remarks regarding
nuking you, if you are willing to talk in plain simple english in each
and every message you send in the future.  Frankly, I get a headache
trying to read your messages!  Needless to say, this does not make me
particularly receptive to your arguments, which may, for all I know,
might be quite reasonable and sane.  Unfortunately on the average I
refer to a dictionary 3 times in the course of an hour when reading just
ONE of your messages.

The problem, as far as I can tell, is that you arguing against opponents
who do not read this list.  As surprising as it may seem, I am a
moderate, and am viewed as somewhat heretical by the OSI community by
even suggesting that the lessons learned in the Internet might be applicable.
My favorite line which came up in a conversation back in April at an OSI
tutorial:

	"The Internet was an interesting experiment, but X.25 is the
	 only real networking solution".

Yes, I thought it was funny too.  Even more funny considering the person
who gave the tutorial deeply believed this.  I was tempted to refer
everyone to your book, particularly later on when the speaker said one
didn't need something like TCP over a LAN, but alas, I could not
remember the full title of your tome (too many big words, you know), so
I did not speak up.

Now, at this point I guess I should respond, point by point to your
message.  But frankly, who cares?  I don't understand half the arguments
you make, due to your use of excessively obscure english.  I guess I can
not just see your "larger picture".  This isn't a personal attack, but I
hope you take it personally(!) and clean-up your writing style so more of
us can understand what you are trying to say.

With regards to who's atomized who:  I have received (privately) one
message congratulating me on stomping you with my last message.
Although this is not conclusive proof, it is good for my ego.

Your turn (and please try to avoid using words which aren't found in my
Webster's abridged dictionary, thanks).

/mtr

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 02:46:08 GMT
From:      dagg@lace.lbl.gov (Darren Griffiths)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

In article <8809080134.AA05073@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
>There seems to be some convergence on the use of the domain name service
>ip address list, as a means of accessing multiple interfaces (with one 
>interface per milking machine) to the same service host.  A couple of
>notes, however, have mentioned reliance on a feature that is not
>supported:  having the domain name service select which ip address to 
>give you, thereby having the DNS do the randomization necessary to give
>load-leveling.
>
>Selection of the "correct" IP address must be done by the client (e.g.,
>telnet).  The DNS has no way of knowing what use you will put the information
>to and it has no way of distinguishing multiple milking machines from
>multiple connections to different parts (i.e., different networks) on
>an internet.


I have missed some of the recent discussions on this list, so I haven't seen 
any of the previous messages you are referring to, but it sounds like you are
talking about something similar to one of my pet nags about routing (I know 
there are a lot of different nags about routing, but this is my favorite).  In 
many cases there are different paths to the same host, either via backup 
redundant links or because of longer hops through the network.  Usually the 
gateways know about these different paths and take the fastest (determined by 
the metric) and leave the other path untouched.  This other path may be idle 
and quite useful, there are two ways of making use of this path.  

  1)  If the second path was 25% of the speed of the first path then 25% of
      the packets could be sent that way.  This would likely mean that 
      packets would be arriving in different orders than they were sent but
      if the two end sides were running the Van Jacobsen/Mike Karels code
      I believe this wouldn't be to much of a problem.  If they weren't running
      this code you may lose more than you gain due to retransmits.

  2)  The second thing that can be done is a little nicer.  The gateways could  
      look in to the tcp packets and send some of the stuff through one route
      and some through another.  For example, SMTP connections do not always
      need to be taking up bandwidth on a high speed link when they could be
      using a slower backup link leaving the high speed connections for 
      interactive users.  Real people tend to be a lot more impatient than
      computers (although real people are also a lot slower at many things.)

  Cheers,
    --darren


-------------------------------------------------------------------------------
Darren Griffiths                                          DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division                

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Sep 88 11:37:44 CDT
From:      "Joseph P. Thomas" <jpt@uc.msc.umn.edu>
To:        tcp-ip-RELAY@SRI-NIC.ARPA (Jack F. Vogel)
Subject:   Re: telnet server code
> 
> I have been experimenting with the KA9Q TCP/IP package both under DOS
> and under SCO Xenix. So far I have a variant of the package running as
> a background FTP and SMTP server under Xenix. The biggest limitation
> of the package for serious server usage is the lack of a Telnet server.
> Could some kind soul out there point me at some existing telnet code
> that I could access to integrate into the KA9Q stuff; it would make life
> much easier. If anyone else is interested in this package under Xenix 
> send me some email and I can let you know the details.
> 
> 
> 				Please email and I will summarize should
> 					interest warrant it.
> 
> 					  Thanks so much,
> 
> -- 
> Jack F. Vogel
> Turnkey Computer Consultants, Costa Mesa, CA
> UUCP: ...{nosc|uunet}!turnkey!jack 
> Internet: jack@turnkey.TCC.COM
> 


	I was wondering if you could send me info on the changes you made ( or
a diff listing ). Thanks.

Joseph Thomas
Minnesota SuperComputer Center, Inc
Internet: jpt@uc.msc.umn.edu ( 128.101.1.3 / 10.2.0.94 )

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 15:23:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  TCP/IP on STREAMS
For any questions, regarding WIN/TCP for Streams, Wollongong's Unix
System V Release 3 (Streams) TCP/IP product, please send messages to
me.

Dave Crocker
VP, Engineering
The Wollongong Group

(dcrocker@twg.com)

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Sep 88  13:47:49 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Multiple TCP/IP servers on one host
> There seems to be some convergence on the use of the domain name service
> ip address list, as a means of accessing multiple interfaces (with one
> interface per milking machine) to the same service host.  A couple of
> notes, however, have mentioned reliance on a feature that is not
> supported:  having the domain name service select which ip address to
> give you, thereby having the DNS do the randomization necessary to give
> load-leveling.
>
> Selection of the "correct" IP address must be done by the client (e.g.,
> telnet).  The DNS has no way of knowing what use you will put the information
> to and it has no way of distinguishing multiple milking machines from
> multiple connections to different parts (i.e., different networks) on
> an internet.
>
> Dave

While it's not there now, one could imagine a domain name server having
the feature of optionally randomizing the addresses for a host with
multiple addresses.  This would need to be indicated in the data base
somehow, as it might not be desirable for every host.  The person
making the entry in the data base presumably knows what it is for.

I suspect that most Telnet clients do not now randomly select from a
list of addresses.  They probably try them in the order in which they
appear, with the possible exception of prefering addresses on the same
network as themselves.  It this is true, then something has to be
changed if there is to be load balancing.  There are a lot fewer domain
name server implementations than Telnet client implementations.
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 12:09:44 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.protocols.tcp-ip
Subject:   Re: Call queueing

In article <628@root44.co.uk> jgh@root44.UUCP (Jeremy G Harris) writes:
>I asked:
>> The BSD listen(2) syscall (on a socket) provides for the specification
>> of a queue of pending connection requests.  So does the TLI T_LISTEN function.
 
>> What are the pros and cons of this functionality?  Is it merely a matter
>> of the cost of copying a protocol control block versus the cost of opening
>> and initialising one?  Or is there also a functional benefit?
>
>Why does this connection queue have to be handled by the kernel?  Why couldn't
>the application just open and initialise for listening (not in the BSD syscall
>sense)  as many transport endpoints as it's queue needs to be long?

How about this:

A server process S is doing accept. It implements a highly available server.
For speeding things up, it forks of a process for every client.
A client A connects to the socket, and while S is forking, closing the second
socket, and doing the next accept, two client processes B and C have attempted
to connect.

Without a queue, what would happen ? One of the connects could be remembered,
while the second one certainly is forgotten by the kernel that the server runs
on.

Since we're talking about TCP, which is supposed to be reliable, the client
which was forgotten will retry the attempt to connect (after a LONG timeout),
and then probably the connection will be made.

The time interval between the two accept in S is probably small. Therefore,
this situation will not happen very frequently. Still, adding a small
queuing function in the kernel on the accepting side would remove the problem
alltogether.

How about letting the server do a new system call? (Let's call it `listen')
This should eliminate the problem completely.

Disclaimer : I can't claim that this is really the way the listen system call
was invented. I only think this is its only use.

	Danny Backx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Danny Backx
 Tel: +32 16 200656 x 3544              |        Katholieke Universiteit Leuven 
 Fax: +32 16 205308                     |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@blekul60.BITNET         |        Belgium     

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 13:04:20 GMT
From:      km@emory.uucp (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   Route and Gateway Tools?

Here is the motivation for this ill defined question. Our connection to
the Internet is via Suranet, which is itself connected with a Proteon
ring. There are apparently both official and unofficial gateways to
other components of the Internet. When the official one goes down the
Internet looks partitioned to us. However, during these down periods
our next door neighbor on the ring still gets connectivity apparently
by using some other gateway (not local to his site).

I am wondering what tools are available for tracking routes.  We would
like to see how our neighbor manages to get out when we can't. In
general are their any Unix host based programs that can track packets?
Is there a host based program that can broadcast a request of the sort
"which gateways know how to get to XXX"?
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {decvax,gatech}!emory!km     UUCP 
Dept of Math and CS | km@emory                     NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 14:09:19 GMT
From:      dougm@violet.ICO.ISC.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on STREAMS

In reply to your message of Wed, 7 Sep 88 17:38:00 +0100
-------
> Pisa 9/7/88
 
> I am interested in TCP/IP implementations using the STREAMS mechanism.
> In particular, is there any person or company, besides Wollongog Group,
> that sells or gives such implementations ?
> I am also interested in getting in touch with anybody willing to discuss
> this subject.
>                       Marco Graziano.

There are several.  Interactive Systems, Lachman Associates and Streamlined
Networks also have versions.  I am most familiar with Interactive's version
(running on 386/ix) and would be willing to discuss the subject with you.

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

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 15:10:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP Servers

Darren,  your suggestion for the use of alternate, parallel routes is
well-taken; however, the accepted means of getting different routing
services from the network involves two actions by the sending host:

1.  If the sending host is multiply-connected, then different interfaces may
be used to start the packet on its way;

2.  For step #1 and again for use by every IP router, the sending application
should specify a level of service, which should be translated by the sending
host into the IP TOS field.  Therefore, network transmission software does
not need to look up into higher layers.

The catch, of course, is that the TOS field is not in general use by
sending software and is not in general use by routing software, although
there is increasing pressure on the vendor community to start setting and
paying attention to the field.

Dave

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 17:20:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   RE: Re: Call queueing


>Why does this connection queue have to be handled by the kernel?  Why couldn't
>the application just open and initialise for listening (not in the BSD syscall
>sense)  as many transport endpoints as it's queue needs to be long?
>
>Opinions, anybody?

At least for BSD, the kernel will not allow more than one listening socket
to be bound to a particular local endpoint address, but the server wants to
be able to open multiple connections which refer to the same local endpoint
address.  To deal with this, the kernel accepts multiple connections and
queues them at the listening socket.  When an accept system call is issued,
an open connection is associated with a new socket which is then returned
to the user.  One can think of the new socket a "clone" of the listening
socket.

To allow multiple listening sockets to be bound to the same endpoint address
opens up a bunch of ambiguity problems.
(TCP doesn't know if identical services are available on all those sockets)

						Art Berggreen
						art@acc.arpa

------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 17:58:34 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   listen

> My thanks to everybody who replied, both here and by mail.  Several people
> pointed out that I said t_listen when I should have said t_bind - sorry,
> my fingers were running faster than my brain....
> 
> However, nobody has answered the question that I was trying to ask.  I can't
> have made a good job of the question :-)
> 
> Why does this connection queue have to be handled by the kernel?  Why couldn't
> the application just open and initialise for listening (not in the BSD syscall
> sense)  as many transport endpoints as it's queue needs to be long?
 
> Jeremy Harris			jgh@root.co.uk

Well, I'm not an expert, but it would seem to me that moving into
the individual process wouldn't do much more than increase the amount of
work that has to be done.  Right now the functionality is such that a
fixed number of pending connections may be queued up, on the grounds that
they will be quickly handled by the application (normally by forking a
child to do the work).  However, once the queue is exhausted, the system
must refuse the connection to any subsequent clients.  If the queue were
being handled in the process area, the operating system would have to

	A) do more work to decide the state of the socket in the process
	B) have additional protocol between the kernel and process to back
		up into the kernel in order to create the new socket for
		the process through the accept() call
	and,
	C) have some method to back up into the kernel whenever the queue
		filled, so that the refusal could be sent to the client

Seems like a whole lot more work for the kernel than just queueing pending
connection requests.

Joel A. Mussman
CONTEL Federal Systems

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 18:17:51 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

In article <957@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes:
>
>I have missed some of the recent discussions on this list, so I haven't seen 
>any of the previous messages you are referring to, but it sounds like you are
>talking about something similar to one of my pet nags about routing (I know 
>there are a lot of different nags about routing, but this is my favorite).  In 
>many cases there are different paths to the same host, either via backup 
>redundant links or because of longer hops through the network.  Usually the 
>gateways know about these different paths and take the fastest (determined by 
>the metric) and leave the other path untouched.  This other path may be idle 
>and quite useful, there are two ways of making use of this path.  
>
	When you say "different paths" do you mean alternate routes to
the same address or alternate addresses to the same host (which is the
subject of the thread)?  In the first case, you as a user don't care
what paths your datagrams take so long as they get there quickly.
However, load sharing is done by ciscoIGRP and is proposed in Moy's
Open SPF IGP protocol draft for equal-cost routes.

	Presumably, the untouched routes are being used by other
datagram streams.

	If you mean alternate addresses to the same host, that won't
work for a telnet stream, will it?  How would a router know anything
about relationships between IP addresses?

>  2)  The second thing that can be done is a little nicer.  The gateways could  
>      look in to the tcp packets and send some of the stuff through one route
>      and some through another.  For example, SMTP connections do not always
>      need to be taking up bandwidth on a high speed link when they could be
>      using a slower backup link leaving the high speed connections for 
>      interactive users.  Real people tend to be a lot more impatient than
>      computers (although real people are also a lot slower at many things.)
>

	One set of warnings: "stateful routers" and "router crash".
But what you are suggesting could be a Type of Service kind of thing.
Better than having the router decide, the application can tell the
router about what it wants in the way of security, delay, bandwidth,
etc.

	Kent England, BU

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 18:34:31 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Route and Gateway Tools?

In article <3170@emory.uucp> km@emory.uucp (Ken Mandelberg) writes:
>
>I am wondering what tools are available for tracking routes.  We would
>like to see how our neighbor manages to get out when we can't. 

	The short, funny, and sad answer is "ping, telnet, friends,
guest accounts on critical routers, and backdoors".

>In general are their any Unix host based programs that can track packets?
>Is there a host based program that can broadcast a request of the sort
>"which gateways know how to get to XXX"?

	SNMP will help equalize the situation, if your neighbors and
regional will let you peek.  A ping with record route option will tell
you how your packets are getting there and back, but won't find you a
backdoor.

	There are good reasons for backdoor, unadvertised routes
between nets.  Perhaps your neighbor, for one of several good reasons,
does not want to allow your traffic to transit his net to get out to
the backbone.  Backdoor routes are such *because* they cannot be found
from where you are. Otherwise, they are regular routes.

	I might suggest that if you are responsible for networking at
Emory that you begin to get yourself a backdoor around or to SURAnet
by working with your neighbors.  That's the way it's done.  Another
tack, complain like hell to SURAnet when you lose your connection.

	Your neighbor isn't cheating.  He's just got some insurance
and you can get some too.

	Kent England, BU

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 19:35:55 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Birds of a Feather - IP Security Option - Interop 88


I've scheduled a BOF session covering the IP security option, the IP
Extended Security option, general implementation hints, and general
security issues.  The session will be at 5pm on Wed the 28th.  ACE
will have a schedule up listing times and rooms for the various BOFs.

I'd like to have everyone who is attending the conference, who is also
in the process of implementing the IPSO show up so we can see if there
are any issues to resolve.  Thanks, Mike

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 21:20:22 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Hey, Michael and Marshall, I'd love to see you two duke it out (Or violently
agree) on the Layer 5-7 "in ain't the same as out" issue that surfaced in
the recent messages.  I'll even put up with some of Michael's verbal
meanderings out of eleemosynary feelings.

Dan
-------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 21:45:22 GMT
From:      cperry@BERT.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

Kent,

OK, here goes.  

If what you read on the front page of your favorite trade rag doesn't 
smell quite right, it's probably a result of one of three things:
naivete, bandwagon-ism or profiteering.  Unfortunately you're not sure
which, though the result is the same:  you're mis-informed by somebody
who should've known enough to write a balanced news story.  Although most
reporters who write for the trade press are conscientious, there are
enough sloppy ones and enough drum-beaters to make reading an occasionally
hazardous activity.  

Usual disclaimers.

Regards,

Chris Perry

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 21:45:33 GMT
From:      schoff@NISC.NYSER.NET (Martin Lee Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   multivendor SNMP interoperability success


On the 7th and 8th of September the "Simple
Network Management Protocol" (SNMP, RFC1067) was successfully tested for
interoperability by multiple vendors with multiple implementations.

Additionally, the
Structure of Management Information (SMI, RFC1065) and the Management
information Base (MIB, RFC-1066) were rigoursly (and successfully) tested for
interoperability.

Users can now be confident that both Network Management Stations (NMS) and
the imbedded agent/servers in terminal-servers, gateways, hosts, etc will
uniformly interoperate.

This SNMP "Connectathon" was held at NYSERNet's headquarters in Troy, NY.


Martin Lee Schoffstall
Director of Technology
NYSERNet INC

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 88 22:23:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP on STREAMS

For any questions, regarding WIN/TCP for Streams, Wollongong's Unix
System V Release 3 (Streams) TCP/IP product, please send messages to
me.

Dave Crocker
VP, Engineering
The Wollongong Group

(dcrocker@twg.com)

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 00:11:53 GMT
From:      charles@iconnect.UUCP (Charles Seybold)
To:        comp.protocols.tcp-ip
Subject:   Inquiry: Network Research Corp. Fusion TCP/IP product


Network Research Corporation (Oxnard CA) sells a TCP/IP product
called "Fusion". The product is described as a full implementation 
of Internet Protocol suite. I am interested in comments from anyone
who has evaluated  Fusion software. 
In particular, how is the reliability, compatibility, and performance.


Charles Seybold
InterConnections Inc.
1-800-527-6553
uunet!amc!iconnect!charles

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 12:20:22 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?



	[]


	Does anyone remember the original Saturday night live shows?
	The ones where Jane Curtin and Chevy Chase did their version
	of point-counterpoint?


	"Chevy, you arrogant male *#***"
	"Jane, you ignorant slut"

	The current religious wars bring that to mind!


			`		Larry Backman
					Interlan, Inc.

	

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 13:44:48 GMT
From:      IGJM400@INDYCMS.BITNET (Gary McCabe)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

ISORMite, ISORMist, TCP/ist, ....Hmmmmm

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 14:03:38 GMT
From:      cel%heart-of-gold@MITRE-BEDFORD.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: multivendor SNMP interoperability success


	Marty,

	Congratulations on your successful interoperability demonstration.
It represents a major step toward achieving interoperable network management
in the Internet.

	Lee LaBarre

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 14:19:35 GMT
From:      pete@NCSC.ARPA (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Bridge FTP modification


Has anyone been able to effect direct PC-to-PC file transfer, that is,    
without going through a third party intermediary (server or host), using
FTP on the Bridge PCS/1 Ethernet product?  The interface comes with standard 
TCP/IP running TELENT & FTP, as well as a VT100 Emulator and NetBIOS Interface.
If anyone has been able to do this, via 'fooling' the system or by modifying
the actual source code, please e-mail me, it would be tremendously appreciated.

Pete Fernandez
Naval Coastal Systems Center
Computer-Aided Engineering Technology Branch
Panama City, FL 32407

pete@ncsc.arpa
(904)234-4120

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 15:12:30 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

In article <12429004411.28.LYNCH@A.ISI.EDU> LYNCH@A.ISI.EDU (Dan Lynch) writes:
>Hey, Michael and Marshall, I'd love to see you two duke it out (Or violently
>agree) on the Layer 5-7 "in ain't the same as out" issue that surfaced in
>the recent messages.  
>
>Dan
>-------

	I agree with Dan.  If map and mtr could turn this discussion
around and try to find some common ground and consensus between their
two opposing viewpoints, I wonder if they wouldn't have the start of a
new model that might take this discourse up to another plateau?

	The only thing good about the ISORM, or the TCP/IP model, is
that it gives us a map (no pun :-) and a glossary for conversing about
protocols.  Neither model seems entirely adequate.  Network
management, for example, seems to have broken both models.  [no
flames, please].  Thankfully, that doesn't stop the implementors or
protocol-builders.

	I think the considerable expertise of Padlipsky, Rose, Karn,
et al could make some progress along these lines and transform this
discussion from a memorable summer diversion into the beginning of
something new.  How about it?  We need some common ground.

	[Let's see; where did I put my Kevlar flak jacket and fire
extinguisher?] 

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 15:21:37 GMT
From:      tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti)
To:        comp.protocols.tcp-ip
Subject:   tn3270 on SUNos 4.0

Hi!
I'm posting this article for a friend here who has no access to 'news'.
He has a sun4 running sunos 4.0 (all the 4.3 bsd stuff).  He's trying
to get tn3270 (the telnet for emulating ibm 3270 type terminals) to 
work.  He says that it compiles ok using the makefile for 4.3 bsd.  But
when he tries to run it, he gets a segmentation fault when the software
appears to be trying to make a connection.  Has anyone out there got
any suggestions, or run into this problem before?  Thanks in advance!
                                             - Tom Corsetti

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 16:23:12 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Marshall--

Gee, since you put it that way I guess I shouldn't even "invoke cloture";
how about I'll just call a halt?

   'bye, map

P.S.  If enough onlookers send private msgs requesting it I'll type in
what my wrap-up msg would have been and send it back to them, also
in private.
-------

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 16:58:33 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

You're leaving out stupidity and arrogance.

I once talked to a "reporter" for Computer Decisions about the TCP/IP
fiber optic network we were running (this was 1983 or 84 and there
wasn't much fiber around).

Among other things, I said that we were running Sun 3/160
workstations.

I also asked to see a copy of his article before publication so I could
correct any technical errors he might have made.

The arrogant twit gave be a big speech about how he was a
"professional" and did not tolerate "censorship" of his "work".

Well, it seems that Mr. Professional wasn't very smart and had never
heard of Sun 3/160s. So he "corrected" me in the article and when it
was published we ended up running a network of IBM 360s.

(I got calls from people trying to sell me IBM services for over a year
after that article).

Moral: Never rely on the information in a trade magazine for any
reason. You MUST verify it yourself if you are doing something that
depends on it.

---rick

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 16:59:36 GMT
From:      zsu@TSCA.ISTC.SRI.COM (Zaw-Sing Su)
To:        comp.protocols.tcp-ip
Subject:   Re: multivendor SNMP interoperability success


Martin,

Who were the participants?  Or, could you tell us more about your
"Connectathon"?

Zaw-Sing

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 18:09:06 GMT
From:      netser@PARIS.ICS.UCI.EDU (UCI ICS Network Services)
To:        comp.protocols.tcp-ip
Subject:   NS.NASA.GOV nameserver problems

The nameserver at NS.NASA.GOV is listed as a root nameserver.  It just happens
to be the fastest one we can reach from here so our nameserver chooses that
one as the place to forward queries.  However, if you try sending a query
to it asking for information about a top level domain that doesn't exist,
you don't get "NXDOMAIN" the way you should.  Instead you get "SERVFAIL"!
This is really messing things up left and right!

I called the person in charge of this system (did "whois ns.nasa.gov") a few
days ago and he recognized that it was wrong and restarted it.  That fixed it
for a while.  Well, it's wrong again.  I have tried calling him again but
the phone just rings.

Does anyone have changes to BIND to make it ignore certain root nameservers?
(I think I'll start working on it.)  Lacking that does anyone know of a way
of crashing someone else's nameserver?

----------------------------------------------------------------------------
Richard Johnson                          netser@ics.uci.edu       (Internet)
UCI ICS Network Services                 ...!ucbvax!ucivax!netser     (UUCP)

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Sep 88 18:22:02 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: trailers and their subtleties

In article <8809061604.AA29996@monk.proteon.com> jas@proteon.COM (John A. Shriver) writes:
>Sun does not reccomend trailers because they don't even offer their
>(alleged) benefits on a Sun.  They depended on the fact that a VAX has
>two memory maps...

They also depended on the fact that a VAX has relatively small pages.
It's impossible for an Ethernet packet to be a multiple of the page size
of any modern Sun.  (Sun 3 pages are 8KB; I think even the Sun 2 used 2KB.)
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 18:23:12 GMT
From:      netser@PARIS.ICS.UCI.EDU (UCI ICS Network Services)
To:        comp.protocols.tcp-ip
Subject:   NS.NASA.GOV is suddenly fixed!

Well, well!!  After their nameserver being screwed up for over 12 hours
suddenly it's fixed!  Gosh, messages to these bboards really do some good! :-)

I'm still interested in fixes to Bind to make it ignore not forward to
a certain nameserver.  That way I'll be prepared for the next time this
happens (in a day or two! :-)  ).

----------------------------------------------------------------------------
Richard Johnson                          netser@ics.uci.edu       (Internet)
UCI ICS Network Services                 ...!ucbvax!ucivax!netser     (UUCP)

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 18:23:37 GMT
From:      schoff@BEAR-MOUNTAIN.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: multivendor SNMP interoperability success


    

Or, could you tell us more about your
    "Connectathon"?

The objective was to test conformance to the SNMP/SMI/MIB specifications
of the various vendor implementations in a concentrated two day affair
with the experts present for consultation.  Most vendors in the spirit
of getting things to work helped each other, this was a good thing.
All APDU types (GET, GET-NEXT, TRAP, SET,...) of SNMP were tested as
appropriate.  In general all network management stations (NMS's)
tested all agent/servers.

Marty

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 18:27:27 GMT
From:      kwe@BU-IT.BU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...


	For another laugh, have a look at the "Networking" page in
last weeks' InfoWorld where someone tries to explain broadcast
storms and black holes...  It's a grin.
	Wonder what people reading this rag think about our nets?

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 20:16:57 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        news.groups,comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.lans,comp.unix.wizards
Subject:   comp.protocols.nfs - CALL FOR VOTES

Since my posting last week suggesting the formation of comp.protocols.nfs,
I've received unanimous support for the idea from dozens of sources, most
saying "...and if you issue a Call for Votes, please treat this as a
YES vote". [To answer the obvious question, I've excluded Sun
respondents from the audit, otherwise things might get skewed.] Anyway,
it seems appropriate to issue a formal call for votes at this point.
Those who have already sent proxies need not re-mail.

Again, please use the sun!garnold or garnold@sun.com addresses rather
than following my Baroque news path.

Thanks.

Geoff Arnold
PC-NFS architect
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:geoff@sun.com                 +------------------------------------------+

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 20:39:00 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Bastard protocol families?

From last week's issue of MacWEEK, in an article discussing Apple's
forthcoming TCP/IP products:

     "Apple's interest in TCP/IP will legitimize the protocol in much
     the same manner that A/UX legitimized UNIX," said Vint Cerf,
     Vice President of ... a nonprofit thinktank in Reston VA.

Here at Sun ECD we all stood aghast at the thought we had been working
with illegitimate protocols. We should all be ashamed at ourselves....
(I blame it all on MAP, actually - we all need to cultivate writing
at 7th grade level, so that people will understand and legitimize our
work. :-)

Of course Vint's comment was (presumably) intended as a way of poking fun
at that section of the Apple community who seem to believe that A/UX did
indeed "legitimize Unix." But how did he manage to keep a straight face
when he said it?
  
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:geoff@sun.com                 +------------------------------------------+

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 88 21:15:34 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Fine.  It's over for now.  By the way, the total is now 6 messages
congratulating me and only 1 with a slightly negative bent.
Again, while not conclusive, it is good for me ego!

/mtr

ps: I liked your last message, no big words!

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 00:11:57 GMT
From:      HOSTMASTER@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   new domain application

The domain application has been updated.  It is still called
NETINFO:DOMAIN-TEMPLATE.TXT.  Please be sure to use this new form when
sending in domain applications.

Thank you.

Michelle Belmonte
DM
-------

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 04:42:10 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Michael:

I didn't hear (read) a second to the motion nor a call for a vote on the
motion.  I might suffer withdrawal symptoms from contrived erudition and
misspelled words should you terminate your exchange of missives at this
instance.  On the basis of the dispatches promulgated by yourself and
Marshall, one can only hope that English (American or British) is a second
language and that you can express yourselves more elegantly in Ada, ALGOL,
BASIC, BLISS (-16 or -32), C, COBOL, FORTRAN, LISP, JOVIAL, SNOBOL, WATFOR,
WATFIV, etc..  I probably should include TECO and any number of assemblers
in the preceding list.

Merton

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 06:13:05 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Kent:

I agree that the ISO OSI model has to be re-examined; however, I doubt that
it has any particular relevance to the discussion of a protocol or any suite
of protocols.  While it is useful to clearly state the logical procedures
that must be performed to establish a link to reliably transfer data between
two (2) points on a network, it is somewhat absurd to codify these logical
procedures as the ISO has done and then attempt to define a suite of protocols
to implement these logical procedures.

I am not stating that there is no need to have a protocol "stack"; however,
I don't understand the apparent, wide-spread belief that each protocol in
the "stack" must be implemented as isolated procedures or separate processes.
From practical experience in implementing message handling and distribution
systems and communication networks, the logical procedures defined in the
OSI model are, by necessity, repeated in each layer of the protocol "stack"
in order to ensure a reliable communication link.

Do you have an extra Kelvar jacket and fire extinguisher?

Merton

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 08:19:11 GMT
From:      rpw3@amdcad.AMD.COM (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: A 'horror story' for the books

In article <10208@s.ms.uky.edu> david@ms.uky.edu (David Herron) writes:
+---------------
| ...  A check found that sure 'nuff we had some machines with trailers
|  and some without.  Switching off trailers on the interface made the
| applications work again. | I've got a couple of questions...
| 1. Why did things continue to sort-of work between the conflicting
|    machines?  I haven't looked at the code yet, but my understanding
|    of the rfc is that ALL packets will be trailer-ified when going
|    out a trailer link...
+---------------

Close. The trailer protocol is only used when the data portion of
the packet is an exact multiple of 512 bytes. The trailer protocol
actually uses a separate Ethernet type field value for each such
multiple of 512.

From 4.3's "vaxif/if_il.c" (the comment marked with [!] has a bug,
it says "first packet" when it should say "first mbuf"):

	/*
	 * Ethernet output routine.
	 * Encapsulate a packet of type family for the local net.
	 * Use trailer local net encapsulation if enough data in first
[!]==>	 * packet leaves a multiple of 512 bytes of data in remainder.
	 */
	iloutput(ifp, m0, dst) {
		...
		off = ntohs((u_short)mtod(m, struct ip *)->ip_len) - m->m_len;
		if (usetrailers && off > 0 && (off & 0x1ff) == 0 &&
		    m->m_off >= MMINOFF + 2 * sizeof (u_short)) {
			type = ETHERTYPE_TRAIL + (off>>9);
			...
		}
		...

This counts the "data" part of the packet only because the headers fit
entirely within the first mbuf, which happens (!) to be the case for all
protocols supported by the standard code ({UDP,TCP}/IP & XNS).

So... if you are doing something with short or odd-sized packets, like
a line-by-line Telnet or *very* small mail, you can still communicate
between a trailer and non-trailer implementation. Plus, you can always
send data from the non-trailer hosts *to* the trailer host, since <ACK>s
are small and thus never get trailerized.

In fact, you should have been able to watch your SMTP mail on a packet
monitor and seen the entire "HELO", etc., dialog go along just fine up
to the point that the trailer-using host blasted its first full-sized
packet at the non-trailer host... whereupon the trailer'd packet would
be periodically retransmitted until the connection timed out.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 16:25:59 GMT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?


Dan,

 hear hear here - lets here a technical discussion - we are computer
 *scientists* are'nt we...

 i dont understand why both iso7498 fans and rfc79? fans are so
 partisan, rather than regarding both worlds as partial solutions to
 be implemented/converged to by vendors, whatever, and getting on with 
 how we could
 both do better next time (being a scientist by training, i dont believe in 
 'getting it right' - see Karl Popper, Objective Knowledge, pp1 to about 800).

 Just how is TP4 'broken' (apart from unreliable close, and packet
 mode rather than byte stream, and a reference number rather than
 ports).

 So whats wrong with CLNP, cept maybe it mandates a few things that
 weren't mandated in IP/ICMP.

 So whats so good about everyone and their brother building wrong
 transaction protocols over UDP because they claim TCP costs too
 much, doesnt do transactions etc

 etc

 etc

 You guys in the US shouldnt have to worry over the X.25 alternative,
 but in Europe, we gonna have hi-speed ISDN to map 7498 into - now
 theres a problem to think about, do we want TP4/CLNP over a reliable
 640 Mbps bit pipe to carry video and bronze-medallion reference
 models, or X25 pkt and LLC levels, or might we want to listen to what 
 the Dave Clarks and Cheritons of the world are messing with...

 i guess marshall is right that ISO represents the Big picture, 
 but its a Cecil B. de Mille picture that lasts about 20 years, except
 for being remembered by a few old dears at xmas - where's the Citezen Kane 
 of protocol architectures
 (ow, mixed metaphors arent part of physics training)


sorry to rant on, i hate working on saturdays

 jon

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 19:02:22 GMT
From:      cperry@BERT.MITRE.ORG (Chris Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Jon,

If I get your drift right, you're saying that X.25/LLC (and 
similar CO networks) aren't sufficient for the B-ISDN of the
future, yes?

What I surmise, particularly from Dave Cheriton's Blazenet writings
and from AT&T/Bellcore's current work on high-speed switching fabrics,
is that we must begin to look at protocol architectures that exploit 
the coming broadband media.  Not just live with multi-megabit
networks, but push them for all they are capable of.  I guess I'm
not sure X.25 is capable of that, nor is a 128-octet LAP.  How we
engineer upper-layer protocols for extraordinarily reliable,
high-volume, low-latency traffic makes for interesting and important
research, seems to me.

Next question is, who's going to pay the bill for building these
behemoths?  (Sorry folks, that's a big word for a big animal.)
And who's going to set an agenda for exploring what we can do with
them?

Regards,

Chris

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Sep 88 17:25:59 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        Dan Lynch <LYNCH@a.isi.edu>
Cc:        tcp-ip@sri-nic.arpa, PADLIPSKY@a.isi.edu, mrose@twg.com
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Dan,

 hear hear here - lets here a technical discussion - we are computer
 *scientists* are'nt we...

 i dont understand why both iso7498 fans and rfc79? fans are so
 partisan, rather than regarding both worlds as partial solutions to
 be implemented/converged to by vendors, whatever, and getting on with 
 how we could
 both do better next time (being a scientist by training, i dont believe in 
 'getting it right' - see Karl Popper, Objective Knowledge, pp1 to about 800).

 Just how is TP4 'broken' (apart from unreliable close, and packet
 mode rather than byte stream, and a reference number rather than
 ports).

 So whats wrong with CLNP, cept maybe it mandates a few things that
 weren't mandated in IP/ICMP.

 So whats so good about everyone and their brother building wrong
 transaction protocols over UDP because they claim TCP costs too
 much, doesnt do transactions etc

 etc

 etc

 You guys in the US shouldnt have to worry over the X.25 alternative,
 but in Europe, we gonna have hi-speed ISDN to map 7498 into - now
 theres a problem to think about, do we want TP4/CLNP over a reliable
 640 Mbps bit pipe to carry video and bronze-medallion reference
 models, or X25 pkt and LLC levels, or might we want to listen to what 
 the Dave Clarks and Cheritons of the world are messing with...

 i guess marshall is right that ISO represents the Big picture, 
 but its a Cecil B. de Mille picture that lasts about 20 years, except
 for being remembered by a few old dears at xmas - where's the Citezen Kane 
 of protocol architectures
 (ow, mixed metaphors arent part of physics training)


sorry to rant on, i hate working on saturdays

 jon
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 20:39:04 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Does TCP/IP "comform" to ISO/OSI?


>   'bye, map
>
>P.S.  If enough onlookers send private msgs requesting it I'll type in
>what my wrap-up msg would have been and send it back to them, also
>in private.

Nah, send it in public, I can't stand the suspense.

	-Barry Shein, ||Encore||

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 88 20:55:18 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   It's in print, so it must be true...


Howsabout all this Computer Virus stuff. I've been called by BU Public
Relations and other media folks in search of an interview from "an
expert" on computer viruses (not my dept.)

Now some guy claims to be selling "vaccines" for computer viruses and
Chicken Noodle News gets out their science editor to write it up as if
it were a medical story that goes alongside the latest AIDS reports.

The guy with the vaccine in a real serious tone tells about how
sometimes the disks get so infected the only thing to do is to throw
them away (no kidding!)

Is this a cargo cult or what?

If anyone has any seriously infected 300MB 5 1/4" drives please wrap
them carefully in plastic (wearing rubber gloves and scrubbing with
Betadine afterwards, to the elbows) and send them to me, I've decided
to open a hospice for them to find peace in their fate.

	-Barry Shein, ||Encore||

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 88 01:54:51 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

In article <8809102055.AA08349@bu-cs.bu.edu> bzs@BU-CS.BU.EDU (Barry Shein) writes:
>Howsabout all this Computer Virus stuff. I've been called by BU Public
>Relations and other media folks in search of an interview from "an
>expert" on computer viruses (not my dept.)

There was someone at the last USENIX with a card that listed his profession
as "cyberimmunologist".


-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 88 02:18:12 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

In article <8809091827.AA04055@buit13> kwe@BU-IT.BU.EDU writes:
>
>	Wonder what people reading this rag think about our nets?

This is the part that should be of concern to all of us in such
rags.  A good reputation takes a long time to build.  One bad
reporting job and you can tear a lot down in one swell foop.
It's in all our interests to counter such inaccuracies best we can.

Rex Buddenberg

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 88 12:34:46 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin[jsw])
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

The primary difference between TCP/IP and ISO/OSI is that ISO/OSI was
designed by a much larger committee.

		--Steve Bellovin

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 88 17:32:23 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP servers on one host

W.r.t. the discussion on having domain servers randomize addresses for the
purpose of load balancing, note that the domain system delegation feature
can be used to good effect.  Authority for single hosts can be delegated
as easily as for groups of them.  It would be easy to write a specialized
nameserver-like program that could randomly select one of a group of addresses.
For that matter, such a gadget could even check with the terminal servers
(or whatever resources) directly and choose one known to be available.
It could be far simpler than a full-fledged name server, just capable of
parsing queries, constructing replies to the ones it knew about and
ignoring the rest.

	Stuart

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 88 20:32:41 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   ICMP's & IP src addrs


I have been playing with `ping' (ECHO,TIME,MASK, & INFO) lately.  I am
seeing different machines respond with different IP src fields (assuming
I was `pinging to broadcast').  

My question then is:
	"Should the src field in the returning IP header be the same
	 address that was in the dst field in the outgoing (requesting)
	 IP packet or should the src field be the IP address of the
	 responding machine?"

Ok, that is a mouth full, so let me give you some more information.

Given the following information:

	Class B address:	129.24
	Net Mask:		255.255.248.0 (0xfffff800)

a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
the src IP address on the packet that is being returned to me and
sometimes the ping yields 129.24.#.# as the src IP address where #.# is
the correct IP address of the responding machine.

What is interesting is that some machines respond using 129.24.15.255
for ECHO/TIME/INFO requests, but use 129.24.#.# for MASK requests.
Some machines use different src IP addresses for different requests.

I can't find an RFC which talks about what src IP address to use when
echoing packets, so if one exists, I would greatly appreciate it if
someone could point me towards it.

Any other information about the "correct" way to handle this would also
be greatly appreciated.

Thanks in advance.....


    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of EECE - Hypercube Project
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |       |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@hc.dspo.gov 
 | /        | /
 @/_________@/

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 01:19:05 GMT
From:      zpovc::hwchoy@UCBVAX.BERKELEY.EDU (Heng-Wah Choy <:hwchoy@zpovc> Singapore SWS)
To:        comp.protocols.tcp-ip
Subject:   Sorry about this, but...

Please ignore this, but I have not received tcp-ip since 2-sep-1988 so
something's gotta be broken...

Cheers,
HW Choy

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 09:31:51 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        kwe@bu-it.bu.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Reference models and Network Management

>     The only thing good about the ISORM, or the TCP/IP model, is
> that it gives us a map (no pun :-) and a glossary for conversing about
> protocols.  Neither model seems entirely adequate.  Network
> management, for example, seems to have broken both models.  [no
> flames, please].  Thankfully, that doesn't stop the implementors or
> protocol-builders.

Kent:

    I don't think network management has broken the models -- my view is
that network management has reminded us that the models are maps, not
prescriptions.

    The key layer/model problem that I see in network management is that
management applications (at whatever layer you put them) expect to be
able to get an information in any network layer -- i.e. strict layering
in which only the N+1 and N-1 layer communicate with the N layer doesn't
hold.  The other thing that network management does is force you to make
the internal workings of the layer visible.  This approach distresses the
folks who liked the black-box approach to layering (well defined interface to
a box you can't peek into) -- but is hardly surprising to implementors.

Craig
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 10:27:13 PDT (Monday)
From:      SSanfilippo.osbunorth@Xerox.COM
To:        PADLIPSKY@A.ISI.EDU
Cc:        tcp-ip@sri-nic.Arpa, thumper!karn@faline.bellcore.COM
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Please add me to the distribution list for your wrap-up message.
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 10:10:23 CDT
From:      Stuart Levy <slevy%uc.msc.umn.edu@ICS.UCI.EDU>
To:        bind@PARIS.ICS.UCI.EDU, netser@PARIS.ICS.UCI.EDU
Cc:        sri-tcp-ip@PARIS.ICS.UCI.EDU
Subject:   Re:  NS.NASA.GOV is suddenly fixed!
If you really wanted to make BIND ignore some name server, you could
just add a host route for the server's address(es) which pointed to
some black hole or other.  At least BSD IP can do that.
I don't know as simply not talking to the system named in the bogus NS RR
would have helped in this case, though -- the damage was done once the
* record was in your own cache.

And as far as I heard the source of the bogon was not found -- it had vanished
from NS.NASA.GOV by the time Milo got the word and looked for it.
Does anybody know where it might have come from?
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 12:51:25 PDT
From:      cire@clash.cisco.com
To:        tcp-ip@sri-nic.arpa
Cc:        "Roger Fajman" <RAF%NIHCU.BITNET@cunyvm.cuny.edu>
Subject:   Re: Multiple TCP/IP servers on one host

Having a domain server randomize the responses for a given host
strikes me as something of a round about way of achieving the
desired solution.  Certainly it will work.  However it seems to be
extending the Domain System in ways it was not intended to go.

I realize there is a desire to use existing protocols and applications
with minimum modifications.  However, perhaps the suggested methods
are not the way to go.  Has anyone experimented with load balancing
protocols?

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 09:52:16 EDT
From:      kwe@bu-it.BU.EDU
To:        kwe@bu-cs.bu.edu, mcc@ETN-WLV.EATON.COM, tcp-ip@sri-nic.ARPA
Cc:        sms@ETN-WLV.EATON.COM
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?
	Merton:

	I did not mean to imply even that the idea of a protocol
"stack" was acceptable to both parties in the debate.  Actually, I
don't mean to limit the discussion to two parties, either.  (Moot,
yes?)

	It is a tenet of the tcp/ip community that RFCs do not (to the
degree possible) define the implementation.  On the other hand, many
RFCs contain pseudocode examples.

	Perhaps the best starting point for the discussion of a new
model is with the successful implementations that work well in spite
of the "official" model.  What can be said about the model that these
protocols actually represent?  Of course, that's the way the tcp/ip
"model" came about.  It wasn't necessary to "codify" something except
in response to another group that said "Here's our model."

	None of what I say is new.  I was thinking that there might be
common ground among the OSI layer model, the tcp/ip articulated model,
and some new elements learned lately to fill in the obvious gaps.
Something that can serve as a vocabulary and grammar, perhaps.

	Kent England, Boston University
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 11:18:38 EDT
From:      David Quarterman <DLQ%UGA.UGA.EDU@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Apollo Domain ring tcp
     We have a domain ring of Apollos with an ethernet card in one of them.
Our desire is to use the ageis tcpip gateway software to connect the machines
on the domain ring to our campus network as a separate subnet.  The machine
that has the ethernet interface is reachable from the outside world and can
reach the world.  The problem is that the machines on the domain ring can't be
reached and even tho they seem to send out packets addressed to the proper
machine on the local net, there seems to be no answer from the local machine.

I would be interested in talking with anyone who has set up this kind of
net with apollo workstations.
                               128.192.1.7
                                --------------------------
      apollo a               apollo b        ethernet   128.192.1.x
         ---------------------------
 128.192.5.2    domain  128.192.5.1

 Thanks in advance.
                               David Quarterman    (Tiger@fevax.uga.edu)
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 07:35:26 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <23634@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
>	"Should the src field in the returning IP header be the same
>	 address that was in the dst field in the outgoing (requesting)
>	 IP packet or should the src field be the IP address of the
>	 responding machine?"

I believe that is should definitely the IP address of the network
interface that the responding machine sends the datagram through. 
-- 
			- john romkey
UUCP: romkey@asylum.uucp		ARPA: romkey@xx.lcs.mit.edu
 ...!ames!acornrc!asylum!romkey		Telephone: (415) 952-9268

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 14:19:11 -0400
From:      dan@WILMA.BBN.COM
To:        Rick Adams <rick@seismo.css.gov>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: It's in print, so it must be true...
> I also asked to see a copy of his article before publication so I could
> correct any technical errors he might have made.

Journalists are essentially never willing to do this, not necessarily
because they are "stupid and arrogant" or even intolerant of
"censorship".  Newspaper/magazine articles somehow always end up being
finished at close to the absolute last possible minute (even for a
monthly).  There's usually just not time for a review by anyone
outside the chain of command.

I think it's better to write some things down--or if it's a phone
interview, which is a particularly good source of misunderstandings,
send something written summarizing the things you said, and let the
journalist know that you're doing it.  For a weekly or monthly, your
mail may well be received in time for the person you spoke with to
correct things like "3/160" vs. "360".  (The editor may change it right
back, of course...)

	Dan Franklin
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 08:09:38 GMT
From:      cattelld@prlhp1.prl.philips.co.uk (cattelld)
To:        comp.protocols.tcp-ip
Subject:   Shutting down sockets - HELP


HELP !  An apparent flaw in BSD sockets (on an Apollo
workstation) is giving me hassle!

If I open a socket and bind an address to it and the program
subesequently crashes, how can I release that address from its
original use so I can reuse it on a subsequent invocation of
the same program ? Currently one crash precipitates another,
or at least prevents the program functioning.

I can't find any command which will do this, and I don't want
to have to shut down the node repeatedly (particularly whilst
debugging).

Alternatively is it possible to force a binding of a socket 
to an apparently used address.

Please post any replies to: cattelld@prl.philips.co.uk

Many thanks,
David Cattell.           

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 17:17:00 PDT
From:      Leo J McLaughlin <ljm@twg.com>
To:        tcp-ip <tcp-ip@louie.udel.edu>

>Is anyone aware of an ad hoc standard for encapsulating IP
>over netware (IPX)?  I know it might sound gross, but it is
>occasionally very useful.  At our site, for instance, netware
>is ubiquitous...

I'll be presenting a paper at the February UniForum titled: "Integrating
Proprietary Networks into IP-based Internets".  Wollongong has supported
a number of experiments in this field. Of these, IP over IPX is the purest
example of network tunneling.

Our experiences have shown us the necessity for an Internet standard for
IP over NetBIOS and IP over IPX.  I've been working on proposals for both
standards; the NetBIOS specifcation was just completed and the IPX
specification is under way.

Comments on the NetBIOS specifcation (and/or IPX when it is finished)
are greatly desired.  Anyone who wishes to recieve a copy should send me
mail at ljm@twg.com.


leo j mclaughlin iii
Project Leader
The Wollongong Group


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Sep 88 14:45:40 EDT
From:      Mills@UDEL.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Timewarp alert
Folks,

The NTP primary time server at NCAR (128.116.64.3) has a stuck clock,
apparently due to failure of a timer module. Until it is fixed, you
may observe blatant silliness in its timestamps, which will appear
to stand still for 30 seconds or so then leap back in synch. The
NTP secondary servers all seem to have detected the lurches and have
tossed NCAR out of their tables. Meanwhile, be advised that both
the ISI (128.9.2.129) and UDel (128.4.0.5) servers are down; however,
the remaining primary servers are surviving.

Remember, time is the only truly persistent state variable.

Dave
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 13:16:07 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   proliferating queues

alternate subject: Does TCP/IP "comform" to ISO/OSI?

> I didn't hear (read) a second to the motion nor a call for a vote on the
> motion.  I might suffer withdrawal symptoms from contrived erudition and
> misspelled words should you terminate your exchange of missives at this
> instance.  On the basis of the dispatches promulgated by yourself and
> Marshall, one can only hope that English (American or British) is a second
> language and that you can express yourselves more elegantly in Ada, ALGOL,
> BASIC, BLISS (-16 or -32), C, COBOL, FORTRAN, LISP, JOVIAL, SNOBOL, WATFOR,
> WATFIV, etc..  I probably should include TECO and any number of assemblers
> in the preceding list.
> 
> Merton

I for one will second the motion, though I'm not sure if we could actually
call for a vote.  I don't really think that a forum on tcp-ip is the place
to attack it.  I'm here because I use tcp-ip (the fact that I like it is
beside the point), and having to wade through language that only a supreme
court justice enjoys is a drag.

Joel

P.S.

SNOBOL is probably the best choice for communications, considering the
rate this is expanding at...

Merton, are the waitresses at Westlake Jack's still as awsome as they used
to be?

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 13:25:09 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple TCP/IP servers on one host

Many ways have been discussed to make a mapping between one logical 
name and many IP addresses. These schemes all rely on having a machine 
resolve a name every time it wishes to open a circuit. Most implementations
have caches, do they not? It seems that for this to work, a resolver would 
need to tell a client "don't cache this response". Then the next time 
a circuit was established, the resolver would be able to look at the 
available resources and determine which IP address to return.
Don't get me wrong, I don't think we should really do this, but if one wanted
to have total control over resource allocation, caching techniques would 
have to be considered.

Bill VerSteeg

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 15:26:29 GMT
From:      ehrlich@blitz (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on SUNos 4.0

In article <57@dftsrv.gsfc.nasa.gov> tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti) writes:
>Hi!
>I'm posting this article for a friend here who has no access to 'news'.
>He has a sun4 running sunos 4.0 (all the 4.3 bsd stuff).  He's trying
>to get tn3270 (the telnet for emulating ibm 3270 type terminals) to 
>work.  He says that it compiles ok using the makefile for 4.3 bsd.  But
>when he tries to run it, he gets a segmentation fault when the software
>appears to be trying to make a connection.  Has anyone out there got
>any suggestions, or run into this problem before?  Thanks in advance!
>                                             - Tom Corsetti

Somewhere in TN3270 a null pointer is being dereferenced.  I do not
remember exactly which module(s) was (were) at fault, but we found it
pretty quickly using DBX.  I will diff what we compiled on our Sun4
against what is running on our VAX and post the diffs if someelse
hasn't already done so.

Dan Ehrlich <ehrlich@blitz.cs.psu.edu> | Disclaimer: The opinions expressed are
The Pennsylvania State University      | my own, and should not be attributed
Department of Computer Science         | to anyone else, living or dead.
University Park, PA   16802            |

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 17:02:38 GMT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: trailers and their subtleties

While we are on the subject of trailers, we recently ran into the following
question.  Right now we have to support trailers on Ethernet, in case
someone else sends them, but what about the IEEE 802.2-based networks?
For example, 802.3 (with the SNAP headers), Token rings, FDDI, etc.
Given the inter-operability problems that trailers have caused in the past,
I would like to say "good riddance" to them on the more modern networks.
What do people think?  Will we be flamed mercilessly again for getting rid
of trailers?  Or flamed mercilessly for propagating them?

	-- Bill Nowicki
	   Sun Microsystems

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 18:56:32 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   NIC host considered hero

Folks,

In response to some UDP Domain Request packets directed to sri-nic.arpa,
I am observing ICMP Source Quench messages from sri-nic.arpa in return.
I assume sri-nic.arpa is full-up with domain requests and is asking
us all to notch back a few decibels. Not many hosts are capable of
such wonderful and intricate response and the implementors are to
be congratulated. The lesson here may be that UDP namecallers should
start thinking about responding to such things, not just TCP clients
which ratchet down on window size.

Dave

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 19:51:25 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host


Having a domain server randomize the responses for a given host
strikes me as something of a round about way of achieving the
desired solution.  Certainly it will work.  However it seems to be
extending the Domain System in ways it was not intended to go.

I realize there is a desire to use existing protocols and applications
with minimum modifications.  However, perhaps the suggested methods
are not the way to go.  Has anyone experimented with load balancing
protocols?

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 22:02:56 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   It's in print, so it must be true...


And, to risk being accused of a keen eye for the obvious, maintain a
sense of humor or don't give interviews unless you're very comfortable
with the interviewer and the possibility of being misquoted or
misunderstood, it's inevitable in my experience.

ComputerWorld interviewed me about some stuff a while back and managed
to botch the organizational tree and which dept was doing what for
whom. I guess it trod on some internal sensitive spots, no one outside
could possibly have spotted the errors and some were quite
understandable. Didn't stop people from appearing at my door, angry,
pointing out that X doesn't work for Y or the Z group doesn't do that!

Of course not, of course they knew I knew, of course they realized the
reporter had filled in various holes by himself, didn't stop the
complaints, as if I had written the article.

Ah well, at least they got almost all the tech stuff right, and that's
what the article was about.

	-Barry Shein, ||Encore||

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 88 22:51:52 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: A 'horror story' for the books

First, thanks to everyone who responded to my posting.  The consensus
was that trailers while on the surface seeming like a good thing are,
in practice, somewhat 'bad' and it's not even clear if they actually
help even in their native environment.  Plus there are cases (Sun's
especially) where they hurt performance because the idea is too Vax
specific and especially too specific to the Vax memory management.

In article <22891@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>In fact, you should have been able to watch your SMTP mail on a packet
>monitor and seen the entire "HELO", etc., dialog go along just fine up
>to the point that the trailer-using host blasted its first full-sized
>packet at the non-trailer host... whereupon the trailer'd packet would
>be periodically retransmitted until the connection timed out.

Well, being able to watch my SMTP mail on a packet monitor assumes the
presence of a packet monitor in the first place.  The closest I have
is tcpdump which, that I know of, does not display the contents of the
packet.  (The joys of living in a poor state at a University which isn't
yet fully up to speed on networking technology & hardware ....)

Anyway.  What I was seeing from the user level was the SMTP conversation
succeeding up to the point where the program had finished sending
all of the DATA section.  Then it went to send the '.' and hung either
in sending the '.' or waiting for the response (depending on the phase
of the moon, I think).  Now possibly the DATA section was being buffered
as much as possible, I don't remember the code that well.  Certainly it
looked to me (at the time) as if the code were hanging because of a
short packet rather than a long one...
-- 
<---- David Herron -- One of the MMDF guys                   <david@ms.uky.edu>
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- 				What does the phrase "Don't work too hard" 
<---- have to do with the decline of the american 'work ethic'?

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 00:25:34 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   History of Internetting Book

Well,  A new book has come out that looks great.  It is a careful selection
of about 40 articles and papers in internetting that have appeared elsewhere
in the past 20 years.  It draws on the experiences of the major networking
protocols:  TCP/IP, DECNET, SNA, PUP and OSI.  The book is about 550
pages and costs $72, with an intor price of $61 if you order before Oct. 26th.
The editor is Craig Partridge of BBN, who is also the new editor of ACM's
SIGCOMM quarterly.  The ordering info is:

"Innovations in Internetworking", ed. C. Partridge.  Published by Artech
House.  ISBN #0-89006-337-0.  You can order by phone (800-225-9977 or
617-769-9750  x4002 in either case) and ask for Artech book 337337.


Happy reading,
Dan
-------

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 04:34:57 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: trailers and their subtleties


     Trailers were a bad idea whose time has passed.  Even under Berkeley
UNIX on a VAX, their home ground, the performance improvement was very
marginal.  

					John Nagle

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 04:44:35 GMT
From:      aad@stpstn.UUCP (Anthony A. Datri)
To:        comp.protocols.tcp-ip
Subject:   Re: Bastard protocol families?

In article <348@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the top) writes:
>     "Apple's interest in TCP/IP will legitimize the protocol in much
>     the same manner that A/UX legitimized UNIX," said Vint Cerf,
>     Vice President of ... a nonprofit thinktank in Reston VA.

This is remarkably similar to the DG ad described in "Soul of a New Machine"
which said something like "IBM says its entry into the minicomputer market
will legitimize it.  The bastards say 'Welcome.'", which I howled over.
Of course, to this day, the best use I've seen for an IBM mini is the
Series/1 at CMU's ITC that works the badge readers and the Coke machine.
Saying that A/UX legitimized unix would be like saying that our sun ipc board
legitimized msdos.....
-- 
@disclaimer(Any concepts or opinions above are entirely mine, not those of my
	    employer, my GIGI, or my 11/34)
beak is								  beak is not
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 05:48:57 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

Kent:

I must admit I don't really understand what you mean by the phrase "articulated
TCP/IP model" and what value it might have were I to understand it.  That does
not imply that I understand the ISO "Open System Interconnect (OSI) model" nor
the "Digital Communication Architecture (DCA) model" fully.  Although I may
have used concepts outlined in each of these models when developing network
software, my approach is governed by my education received from the "Department
of Intuitive Logic, School of Hard Knocks, University of Experience".  Formally,
I have a degree in the weird (social) science of Economics which is concerned
about the utilization of limited resources which definitely influences my view
of the hows and wherefors of networking.

The two (2) figures, below, might be regarded as my models of networking.  The
one on the left the theoretical model.  The one on the right the practical.

          +--------------------+---+       +------------------------+---+  
          |     Application    | M |       |         Application    | M |  
          +-------------+----+-+ a |       |   +-------------+----+-+ a |  
          | Generic Transport  | n |       |   | Generic Transport  | n | 
          +--------------------+ a |       |   +--------------------+ a | 
          |       Network      | g |       |   |       Network      | g | 
          +--------------------+ e |       |   +--------------------+ e | 
          | Specific Transport | m |       |   | Specific Transport | m | 
          +--------------------+ e |       +------------------------+ e | 
          |      Data Link     | n |       |        Data Link       | n | 
          +--------------------+ t |       +------------------------+ t | 
          |     Physical Link  |   |       |       Physical Link    |   | 
          +--------------------+---+       +------------------------+---+ 

What I understand to be the "session layer" is only an aspect of management
which has access to all "layers".  Without management being vertical, what
happens and what stops the no longer necessary activity when the application,
process, or pseudo-process unceremoniously aborts or "core dumps"?

The figure on the left is for the modular architecture and "black box" crowd
that assume memory is cheap and will be cheaper in the future *and* that
time is no consideration because you can always buy a faster engine.  The
figure on the right is for the practical chaps who realize that money does
have a cost and one *does* get stuck with less than optimal equipment for
both the near and far terms.

The "generic transport layer" may or may not exist; however, it is depicted
here to provide a mapping between the local machines representation and that
which is understood by the "network layer".  Also, the "specific transport
layer" may or may not exist; however, it is depicted here to provide a map-
ping between the "network layer" representation and the data representation
that is required to receive or transmit data over a specific communication
link.

In this model the "network layer" is assumed to have a choice of paths and
networks which can be used to communicate with the distant end; hence, the
need for a "specific transport layer".  It is also assumed that the "network
layer" can perform a store and foreward operation between networks without
involving an application process.

In the right hand figure, the vertical added to the "application layer" allows
one to define an "end node" which is technically compliant to the model with-
out having all of the layers.  It also requires well defined interfaces at
each layer because it implies that the "application layer" can enter the
"protocol stack" at any layer.

It doesn't seem to make much sense to allow the "application layer" to go
down to the "physical link layer"; however, I'm sure that someone can provide
a reason why it would be desirable.

If nothing else, the above figure along with the other models might provide
a way to get to a more robust and practical communications model.

Merton

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 10:38:08 GMT
From:      ROBERT@vm1.mcgill.ca (Robert Craig)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...

Even if you write it down, a journalist or editor can
either misunderstand or overlook.  I had one send me
a copy of the article, which I corrected and returned.
We then had a lengthy phone conversation during which I
dictated some quotes.  I had also sent a fair amount of
material to begin with (say 50 pages worth).

Even after all this effort, when the article appeared,
it was only 50% accurate.  I guess journalism is like
baseball: batting .500 is excellent.

Robert.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 13:18:36 GMT
From:      hubcap@hubcap.UUCP (Mike Marshall)
To:        comp.protocols.tcp-ip
Subject:   MVS and TCP/IP...

Greetings:

I'm looking for information about bridge or gateway type hardware
(and the required software) that would allow us to hook our
NAS XL-60 mainframe (IBM-370 type architecture, runs MVS) onto the 
Internet via our campus ethernet (which is mostly SUNS and VAXes).

Thanks for any help...

-Mike Marshall      hubcap@hubcap.clemson.edu      ...!hubcap!hubcap

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 14:35:16 GMT
From:      mikej@cpmain.UUCP (Michael R. Johnston)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP: Help requested

I have been seeing a lot lately about "TCP/IP". I would like to find out
more about it. Is it a stand alone protocol or is some special hardware 
required to impliment it? Could someone direct me to a text that would describe
it in detail?

Thanks in advance.

-- 
                Michael R. Johnston - @NET: mikej@cpmain.uucp
...{cmcl2!phri!,uunet!}dasys1!cpmain!mikej || ...philabs!mergvax!cpmain!mikej

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 16:44:55 GMT
From:      greg@nprdc.arpa (Greg Reynolds)
To:        comp.protocols.tcp-ip
Subject:   Network Security

I am looking for general information on network security. Please send any
references to literature(authors, article names, etc.) via e-mail.  
Also, I am interested in finding out if there are any existing newsgroup(s)
that address this topic. 

Thanks in advance.

Greg Reynolds
greg@nprdc.arpa
!ucsd!nprdc!greg

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 17:44:16 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: trailers and their subtleties

RFC 1042 states:
   Consenting systems on the same IEEE 802 network may
   use this format between themselves.  Details of the trailer
   encapsulation method may be found in [9].  However, all hosts must be
   able to communicate using the standard (non-trailer) method.

If I were you, I would not "consent" to using them so that you don't have to
support them.

Drew

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 19:07:19 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

For those who don't have access to webster...

net> webster eleemosynary
                          "  *      _
el.ee.mos.y.nary \.el-i-'mas- n-.er-e\ adj [ML eleemosynarius, fr. LL 
  eleemosyna alms] : of, relating to, or supported by charity 
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 22:04:49 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  NIC host considered hero

Dave,

To qoute from my favorite (draft) document, the Host Requirements RFC:


 "UDP is almost a null protocol; the only services it provides over IP are
  checksumming of data and multiplexing by port number.  Therefore, an
  application program running over UDP must deal directly with a number of
  the end-to-end communication problems a connection-oriented protocol
  would have handled -- e.g., retransmission for reliable delivery,
  packetization and reassembly, flow control, congestion avoidance, etc."

Yep, all those things!  For "flow control", read "handle Source Quenches".

Bob Braden

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 23:26:31 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  NIC host considered hero

Bob,

I know that you know that I know that. I don't know whether you know
that everybody on this lists knows that we know that. Now everybody
knows everything. Thanks for reminding us all to know that. The reference,
of course.

Dave

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 88 23:52:14 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   BFTP Sources


The sources for the Background File Transfer Program (BFTP), described
in RFC 1068, are now available via anonymous FTP on VENERA.ISI.EDU.
Log in with FTP user name "ANONYMOUS" and password "GUEST".  The file 
is a compressed tar file, and the path name is

	pub/BFTP.1.tar.Z

Please send any comments, questions, or bug reports to Annette DeSchon,
<deschon@isi.edu>.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 01:12:58 GMT
From:      chris@mimsy.UUCP (Chris Torek)
To:        comp.unix.questions,comp.lang.c,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   For non-USENET readers only (Re: subscription request)

I see by the subscription requests that it is time once again for a replay.
Please do not follow up to this article.

Date: 28 Jun 88 23:29:14 GMT

(Apologies to USENET readers, but if I mailed this to the corresponding
ARPA/CS/BIT/...net mailing lists you would see it four times rather than
once.  You can skip the rest of this.)

For those wishing to subscribe to any of the four mailing lists on
which this message is appearing, or for those who are already on such a
mailing list and want to get off it, please do NOT send your requests
to the mailing list itself.  This sends the message on out to every
reader of the list and across some gateway software to USENET; it thus
reaches literally thousands of machines and merely serves to annoy
everyone except those who have control of the mailing list itself.
More importantly, in many cases the mailing list editor (person) does
not read the list itself, and messages to the list are thus worse than
useless.

Please send requests to the -request form of the list.  For instance,
to get on or off the Unix-Wizards list, rather than sending a message
to Unix-Wizards@brl.arpa, send it to Unix-Wizards-Request@brl.arpa.
Remember that mail gets delayed and that people take vacations, and
that mailing list maintenance is often a low priority project; it can
easily take two or three weeks to get action on some request.
Moreover, many lists have local redistribution points, to ease the load
on mailers (using a mail system as a bulletin board has some
drawbacks!).  You should check for a local redistribution list first
before sending mail to the -request address.  Likewise, if you were
added to a local redistribution list, asking the -request address to
remove your name from the list is unlikely to be effective.

BITNET mail is often handled through automatic mail servers located at
specific BITNET redistribution points.  Information as to which lists
are located where, and how to use them, should be available from your
BITNET administrator (I myself have no idea which, where, and how).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 02:44:39 GMT
From:      auerbach@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   TCP for Versados?

I got a phone call today from someone who is looking for TCP/IP on
the Versados operating system.

I can't find anything in the TCP vendors guide.

Does anyone know whether such an animal might be available and where?

Please reply directly to me.

			--karl--

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 03:41:42 GMT
From:      drs@bnlux0.bnl.gov (David R. Stampf)
To:        comp.protocols.tcp-ip
Subject:   Re: Shutting down sockets - HELP

In article <632@prlhp1.prl.philips.co.uk> cattelld@prlhp1.UUCP () writes:
>
>HELP !  An apparent flaw in BSD sockets (on an Apollo
>workstation) is giving me hassle!
>
>If I open a socket and bind an address to it and the program
>subesequently crashes, how can I release that address from its
>original use so I can reuse it on a subsequent invocation of
>the same program ? Currently one crash precipitates another,
>or at least prevents the program functioning.
>

	I'm facing a similar problem currently on Vaxes and Suns, 
so I doubt that it is Apollo specific.  A good approach (I think) is
to have the O/S pick a port for you (bind with an address of INADDR_ANY),
then rendez-vous at a well known port using a datagram approach to exchange
the port to use and prevent tying up a port.

	Sorry this is vague - I'm home and doing this from a very tired
memory.

	< dave stampf

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 03:43:48 GMT
From:      rogerh@arizona.edu (Roger Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

In article <957@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes:
>[...]  In 
>many cases there are different paths to the same host, [...]
>there are two ways of making use of this path.  
>
>  1)  If the second path was 25% of the speed of the first path then 25% of
>      the packets could be sent that way.  [...]
>      if the two end sides were running the Van Jacobsen/Mike Karels code
>      I believe this wouldn't be to much of a problem.  [...]
>
>  2)  The second thing that can be done is a little nicer.  [...]

The first thing (splitting load among routes) would screw up the
Jacobson/Karels improved TCP completely.  They get a big win by
estimating the variance of the round trip time; using alternating
routes for different packets would drive this variance way up, causing
the timeout to be set high, causing long stoppages on lost packets.

Further, their code for calculating optimum window size, which is
pretty subtle, tests for increased available bandwidth by increasing
window size.  I can imagine that this code would get pretty thoroughly
confused if the period of route-switching was near the window size, as
that would cause successive windows to have wildly varying proportions
of samples from the two routes.  The slower route would periodically be
heavily overloaded (when the outstanding  packets in the window
happened to mostly be sent via the slow route) while the faster route
would operate below its optimal point.

Seems like the best way to make use of alternate routes is by
implementing the type-of-service stuff.

				Roger Hayes
				rogerh@arizona.edu

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 05:18:00 GMT
From:      Fitch@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   OSI and TCP Models

>          Perhaps the best starting point for the discussion of a new 
>model is with the successful implementations that work well in spite 
>of the "official" model.  What can be said about the model that these
>protocols actually represent?  Of course, that's the way the tcp/ip 
>"model" came about.  It wasn't necessary to "codify" something except
>in response to another group that said "Here's our model."
 
>          None of what I say is new.  I was thinking that there might be
>common ground among the OSI layer model, the tcp/ip articulated model,
>and some new elements learned lately to fill in the obvious gaps.
>Something that can serve as a vocabulary and grammar, perhaps. 

Kent England's comments reminded me of a few things.  First, models tend to
come in two flavors:  models of perfection and models of reality.  Models
of perfection describe something that is a desirable goal to build to or
provide some common basis of understanding.   Models of reality start with
measurable or observable things and are created as a way to describe what has
been observed and to predict some outcome.

It's sort of a chicken and egg thing.  The ISO OSI model is more like a
model of perfection and if the TCP/IP model came about as Kent implies, then
it is more of the model of the second type.  Neither is right or wrong; but
I think there is an underlying pr[oe]mise as to what one expects from a model.

While I'm at it, may be I'll stir the pot a bit more.  Suppose the OSI
description of the Network layer says it provides protection from
unauthorized disclosure and routing.  Suppose our network protocol NP
provides these services by invoking various key distribution protocols,
address resolution protocols, ... as well as functions actually performed by
the NP protocol itself.  As far as layer N+1 (transport in this example) is
concerned, the Network Layer comes through with the desired services.  But
can we say that NP conforms to the model?  NP is a single protocol.  NP
coupled with address resolution protocols, key distribution, ... perhaps
conforms.  The point is that it is probably not a good or fair
question/statement to say a single protocol conforms to an OSI style model.

As an aside, a few years ago when I was at MITRE, we created a model that
distinguished between user related protocols, management protocols, and 
interface protocols.  This made a three pronged swiss army knife model.
I suppose this means that anyone can create a model and nail it to a church
door, but it's the size of the following that counts.  This probably also
explains why we get religious about models.

--Jack

Fitch@Dockmaster

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 15:02:08 GMT
From:      marcel@hpindda.HP.COM (Marcel Burlet)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Security


Please post a summary to the net.  I sure could use the information as well.

marcel


**************************************************************************
* Marcel Burlet	            | {ucbvax,hplabs}!hpda!hpindlm!marcel [UUCP] *
* Information Net. Div(IND) | marcel%hpda@hplabs.HP.COM       [INTERNET] *
* Hewlett-Packard Co.       | (408) 447-2503                      [AT&T] *
* 19420 Homestead Road,43LN | 1-447-2503                     [HP-TELNET] *
* Cupertino, CA  95014  USA | "What If..."                [HP-TELEPATHY] *
**************************************************************************

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 15:04:14 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  NIC host considered hero

Bob,

See, I planned all this so you could say that. Now, about specific
engeneering principles. See the papers by Ramakrishnan, Jacobson and
Mills in the recent SIGCOMM 88 Symposium and assorted RFCs and archives.
No, I didn't plan all this so I could say that.

Dave

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 15:05:34 GMT
From:      kwe@BU-IT.BU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Reference models and Network Management


	From craig@NNSC.NSF.NET Mon Sep 12 09:45:15 1988
	
	> Network
	> management, for example, seems to have broken both models.
	
	    I don't think network management has broken the models -- 
	network management has reminded us that the models are maps, not
	prescriptions.
	[...]
	strict layering in which only the N+1 and N-1 layer
	communicate with the N layer doesn't hold.

Well, this is semantics but I think that if you say that strict
layering doesn't hold and network management is some kind of vertical
layer (I'm putting words in your mouth, but that seems to be the
standard way to kludge network management into the layered approach)
then the layered model is broken.  In that case, I'm not sure what
practical value I'm supposed to get out of the seven layer model.  If
layers aren't practical, we need another way to talk about the
information that the layered model contains.  For example, we might
need the concept of data link, physical media, subnetwork, network,
internetwork, transport, presentation, application, network management
"agent", ... but let's not pretend that this stuff is layered.  If a
concentric circle diagram with "tunnels" or some kind of flowchart
diagram or a Case diagram presents the particular concept better let's
move to that instead of carrying on this seven layer idolatry any
longer.  Three layers and some tunneling is perfectly OK with me.

Gosh, do I sound like a rabid anti-ISORMist?  No way.  I agree with
Marshall's comments about what OSI people are doing with the
applications.  But when I see significant developments in a >10 year
old transport protocol, I shudder at the thought of the OSI protocols
going through a similar, entirely unnecessary, development cycle.

	Kent England, Boston University

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 16:17:57 GMT
From:      tsmith@USNA.MIL ("Tim G. Smith", Mechanical)
To:        comp.protocols.tcp-ip
Subject:   possible network bogons

I keep gettimg all of this garbage from gated:

> rt_NRupdate: net 238.196.27.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 230.138.135.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 230.186.121.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 237.88.91.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 243.105.147.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 243.104.183.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 226.22.241.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 225.189.166.0 not class A, B or C from 26.1.0.40
> rt_NRupdate: net 226.8.40.0 not class A, B or C from 26.1.0.40

As far as I can tell 26.1.0.40 is bbn-minet-a-gw.arpa. Anyone know who
to ask about this? DCA? The NIC? BBN? Anyone got an email address for
the right person/people to ask about this. 

How about whoever is responsible for that gateway taking a look at
what it is doing. Has there been some change to the core gateways? If
so was there a notice sent out to netland that I missed?

	Tim Smith		
US mail:CADIG mailstop: 11G	E-mail:
	US Naval Academy	internet:tsmith@USNA.MIL
	Annapolis, MD 21402	uucp	:...!uunet!usna!tsmith
MaBell :(301)267-4413
					

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 17:10:34 GMT
From:      NETMGR@NSSDCA.GSFC.NASA.GOV (SPAN Network Info Center  286-7251, 301)
To:        comp.protocols.tcp-ip
Subject:   Forwarding a bounced mail message.

From:	NCF::SYSTEM       30-AUG-1988 15:02
To:	POSTMASTER
Subj:	Mail error notification

Cannot deliver message to following recipients:
CLYNN@g.BBN.COM.
   Reason: EXOS Mail error:  Connection timed out

*** Original message follows: ***

Received: by nssdca id <202008E6051@nssdca.GSFC.NASA.GOV> ;
       Tue, 30 Aug 88 11:37:31 EST
Date: Tue, 30 Aug 88 11:37:14 EST
From: postmaster@nssdca.GSFC.NASA.GOV
Subject:  Re: Call queueing
To: CLYNN@g.BBN.COM
X-VMS-Mail-To: EXOS%"<CLYNN@G.BBN.COM>"
Message-ID: <880830113714.202008E6051@nssdca.GSFC.NASA.GOV>

 *** VMS error in delivery mail, error message follows *** 

EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening 
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: -RMS-E-CRE, ACP file create failed_ADM_US
ER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: -SYSTEM-F-EXDISKQUOTA, disk quota exceededR:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: 
%MAIL-E-OPENOUT, error opening NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded

 *** Original message follows *** 

From : CLYNN@G.BBN.COM
Subject:  Re: Call queueing

Return-path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by nssdca.GSFC.NASA.GOV
          id 202006E5002 ; Tue, 30 Aug 88 11:35:12 EST
Received:  from G.BBN.COM by SRI-NIC.ARPA with TCP; Mon, 29 Aug 88 08:19:55 PDT
Date:  29 Aug 1988 11:18-EDT
Sender:  CLYNN@G.BBN.COM
To:  tcp-ip-request@SRI-NIC.ARPA
Cc:  tcp-ip@SRI-NIC.ARPA
Message-ID:  <[G.BBN.COM]29-Aug-88 11:18:41.CLYNN>
In-Reply-To:  <626@root44.co.uk>

Jeremy,
	As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
	As with all implementations, tradeoffs have been made.  I feel that
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
    1) examining the IP-address identity of the caller before deciding
       ACKnowledge the SYN vs. send a RESET,
          What if X were to place a "collect" call to such an implementation
          and send 4K data; then the receiver process start up and decides
          it doesn't want to accept the call.  Who pays for the 4K bytes?
          (The receiver COULD make the 4K available to the appliaction.)
    2) checking its routing tables and applying administratively specified
       per IP-address source routing, etc.,
    3) selecting initialization parters based on IP-level parameters such as
       TOS and options, or
           Maybe local system has a method for setting the TCP MSS (which
           the spec says has to be in the SYN packet).           
    4) specifying initial TCP-level options, etc.

Charlie

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 17:17:22 GMT
From:      NETMGR@NSSDCA.GSFC.NASA.GOV (SPAN Network Info Center  286-7251, 301)
To:        comp.protocols.tcp-ip
Subject:   Forwarding a bounced mail message.

From:	NCF::EXOS         30-AUG-1988 11:25
To:	POSTMASTER
Subj:	Mail error notification

Cannot deliver message to following recipients:
spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA.
   Reason: EXOS Mail error in following SMTP transaction:
>>> RCPT To:<spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA>
<<< 550 <spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA>... User unknown


*** Original message follows: ***

Received: by nssdca id <2020089C051@nssdca.GSFC.NASA.GOV> ;
       Tue, 30 Aug 88 11:05:38 EST
Date: Tue, 30 Aug 88 11:05:18 EST
From: postmaster@nssdca.GSFC.NASA.GOV
Subject:  Net Help
To: spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA
X-VMS-Mail-To: EXOS%"<spock!a3bee2!omega!grzesiak@yale-bulldog.arpa>"
Message-ID: <880830110518.2020089C051@nssdca.GSFC.NASA.GOV>

 *** VMS error in delivery mail, error message follows *** 

EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening 
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error: -RMS-E-CRE, ACP file create 
failed_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error: -SYSTEM-F-EXDISKQUOTA, disk quota 
exceededR:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error: 
%MAIL-E-OPENOUT, error opening 
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded

 *** Original message follows *** 

From : spock!a3bee2!omega!grzesiak@yale-bulldog.arpa
Subject:  Net Help

Return-path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by nssdca.GSFC.NASA.GOV
          id 20200899002 ; Tue, 30 Aug 88 11:03:43 EST
Received:  from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon, 29 Aug 88 05:52:12 PDT
Received:  by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA06723; Mon, 29 Aug 88 05:26:53 PDT
Received:  from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date:  27 Aug 88 16:42:06 GMT
Organization:  Omega Dynamics , Wallingford Ct.
Message-Id:  <103@omega.UUCP>
Sender:  tcp-ip-request@sri-nic.arpa
To:  tcp-ip@sri-nic.arpa

Hello:
   I have an implementation I'd like to try and have little idea
 about how to go about it. I have a few UNIX boxes , two of which are
 CADMUS 9000's . I have Network cards and drivers for these systems.
 The cards I have are: 3com ethernet and Excelan EXOS 203 (a pair of each).

 What I'd like to know is:
      A) Which of these is a better install?
         (Ease of install , reliable , versatile ,etc)
      B) Can these cards be cheated and how?
         ( Can they be used point to point without tranceivers
            because all I need from them is remote disk mount capability)
      C) If these cards can't be cheated , where can I get thin ethernet
         tranceivers and equipment for these?

    Any help is appreciated - Thank you in advance.....

      John Grzesiak
      Omega Dynamics
      47 Spring Street
      Wallingford Ct 06492.    (203) 284-8530 voice
                               (203) 289-9300 work (9-5 Eastern)
                               (203) 284-3776 guest:guest (computer)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 17:53:54 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on SUNos 4.0

From article <57@dftsrv.gsfc.nasa.gov>, by tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti):
> Hi!
> I'm posting this article for a friend here who has no access to 'news'.
> He has a sun4 running sunos 4.0 (all the 4.3 bsd stuff).  He's trying
> to get tn3270 (the telnet for emulating ibm 3270 type terminals) to 
> work.  He says that it compiles ok using the makefile for 4.3 bsd.  But
> when he tries to run it, he gets a segmentation fault when the software
> appears to be trying to make a connection.  Has anyone out there got
> any suggestions, or run into this problem before?  Thanks in advance!
>                                              - Tom Corsetti

This fix goes in telnet.c (or maybe tn3270.c, if you are using an
older version).  tn3270 (and telnet, for that matter) were using
a "varargs" routine without using the "varargs" mechanism.

Replace the routine "call()" with the code below.

Sorry, about that.

Greg Minshall

----
/*
 * Call routine with argc, argv set from args (terminated by 0).
 */
#include <varargs.h>
static
call(va_alist)
va_dcl
{
    va_list ap;
    typedef int (*intrtn_t)();
    intrtn_t routine;
    char *args[100];

    int argno = 0;

    va_start(ap);
    routine = (va_arg(ap, intrtn_t));
    while (args[argno++] = va_arg(ap, char *))
	;
    va_end(ap);
    return (*routine)(argno, args);
}

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1988 23:21-EDT
From:      CERF@A.ISI.EDU
To:        eagle_snax!geoff@DECVAX.DEC.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Bastard protocol families?
Dear Aghast,

I can't figure out what I could have said that led the reporter
to misquote me that way. Either I said "lobotomize" or I was
trying to say that APPLE's adoption of A/UX and TCP/IP
legitimizes APPLE (!) - in the sense that it makes APPLE's machines
a part of a larger and already communicating community.

Vint
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 88 22:29:53 GMT
From:      eggers@DIRAC.CC.ND.EDU (Mark D. Eggers)
To:        comp.protocols.tcp-ip
Subject:   SGMP confusion

I am trying to implement the latest version of the SGMP code
obtained from clash.cisco.com. I am using this code on a microVAX
running Ultrix V2.2 with p4200 routers running Rev 8.0 of the
router software.

Problem 1

This came when I was compiling the code. There is a call in
sgmp/src/sgmpwatch/main.c on line 121 that goes like this:

nstob(argv[option_count+1],number);

and seems to convert an internet number in dotted decimal notation
to an unsigned int (network or host order address??). I just
commented this line out, and limited the application to only using
host names. Not nice, but it should work.

Problem 2

This comes from my inability (currently) to understand RFC 1028 and
how the variables are specified. On page 13, a generic variable
can be specified in the following manner:

_GW_version_id		01 01 01
_GW_net_if_type_net1	01 03 01 03 01

Now, in the appendix on Proteon variable names, the following
preamble is given:

_GW_impl_Proteon_p4200-R7.4_devpn	01 FF 01 01 04

with the sentence saying 'followed by the name of said network
interface as described above' (page 27). To me, that means the
following construct should be valid.

_GW_impl_Proteon_p4200-R7.4_devpn_net1 01 FF 01 01 04 01

Now later on in the RFC, the variable descriptions keep having
the sentence that has in part 'on the network interface identified
by the initial portion of its name'. Thus, for the not in ring
variable, should the construct be

_GW_impl_Proteon_p4200-R7.4_devpn_net1_not-in-ring 01 FF 01 01 04 01 07

or

_GW_impl_Proteon_p4200-R7.4_devpn_not-in-ring_net1 01 FF 01 01 04 07 01

I know the text seems to state the former, but it doesn't mesh with the
patterns set up on page 13 (at least to me).

A few odds and ends

The sgmp.variables file has dev-pn instead of devpn. The RFC states that
the Proteon variables can change without notice. I assume that
the ftp'ed file is correct? Also, I am running R8.0, so should the
preamble be 01 FF 01 02? And finally - are there different variable
designations for Pronet 4, 10, and 80?

Thanks for putting up with such a long list of confusions.

Mark Eggers, Network Communications Analyst, University of Notre Dame

internet:    eggers@dirac.cc.nd.edu
             cf4a8x@irishmvs.cc.nd.edu
BITNET:      cf4a8x@irishmvs

phone:       (219) 239-7258

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Sep 88 09:04:17 -0400
From:      tmallory@PARK-STREET.BBN.COM
To:        Tait Cyrus <hi.unm.edu!cyrus@HC.DSPO.GOV>
Cc:        tcp-ip@SRI-NIC.ARPA, tmallory@PARK-STREET.BBN.COM
Subject:   Re: ICMP's & IP src addrs


> a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
> the src IP address on the packet that is being returned to me and
> sometimes the ping yields 129.24.#.# as the src IP address where #.# is
> the correct IP address of the responding machine.


Flame:  An ICMP echo to a broadcast address should get no response!  What an
incredibly obnoxious thing to do!

Opinion: If a reply is sent, then the best response is to insert the IP
address of the interface over which the packet was received in the source
address field of the reply.

Tracy Mallory
BBNCC
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 03:21:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Bastard protocol families?

Dear Aghast,

I can't figure out what I could have said that led the reporter
to misquote me that way. Either I said "lobotomize" or I was
trying to say that APPLE's adoption of A/UX and TCP/IP
legitimizes APPLE (!) - in the sense that it makes APPLE's machines
a part of a larger and already communicating community.

Vint

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 11:37:00 PDT
From:      Mohsen Mortazavi <mohsen@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   re:Need help with TCP/IP broadcast address


Version 2.2 of The Wollongong's Group TCP/IP allows you to set the broadcast
address of an interface. The "ifconfig" usage message however did not list
"broadcast" as a vaild parameter. The usage message has now been corrected.
The man page for ifconfig lists broadcast as a vaild parameter.

The default broadcast address for hosts using Version 2.2 (BSD 4.3) is an 
address with the host part of all 1's which is in conformance with RFC 919. 
In 4.2 BSD, the broadcast address was the address with a host par
t of all 0s. 

If you have a mixture of hosts running the 4.2 and 4.3 based TCP/IP, it is best to use a broadcast address with a host part of all 0's which is recognized by
both. In order to do so you need to include an "ifconfig" command in 
/etc/rc2.d/S86win3b to set the broadcast address each time network is started.
You should include the "ifconfig" command after the "inetinit" in this file.
For example, if you have a host with an internet address of 80.0.0.1 you 
should include the following line in S8
6win3b:

	/usr/etc/ifconfig en0 broadcast 80.0.0.0

Where en0 is the interface, and 80 is the network. 

Mohsen Mortazavi
mohsen@twg.com

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 05:13:24 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: It's in print, so it must be true...



I'm the Networking editor for InfoWorld, and I'm glad somebody told me about
this discussion so I could participate.  (I haven't visited this newsgroup
in a while, because I've been too busy.)

In answer to some questions:

yes, Network World is a spinoff of Computerworld.  Forget the editor's name;
he's new.

Regarding  some of the things that have been said, I'm sorry to say
that some are true.  Kent England's description -- we make enough phone calls
to verify the press release and rewrite it -- is true more often than I'd
like to admit.  (Oh, by the way -- InfoWorld is a sister publication of
Computerworld and Network World; we focus on the PC end of things.)  And
yes, reporters sometimes make mistakes; editors sometimes do too -- I can't
tell you how many times a copy editor has pointed to V.22 bis in a story and
said, "Is this right?"

Regarding the InfoWorld article on black holes that somebody was laughing
at -- I was on vacation that week, and the person in charge of the section
that week found himself with a rather sizable hole on the page late on the day
it was supposed to go to the printer.  (We ship pages every day, and most
people have deadlines every day.  I've had weeks where I've written 14 stories.)
Anyway, he researched and wrote that story in less than an hour.  Of course,
it looks it.  But sometimes these things happen.  I'm not trying to justify
errors; just letting you know the background.

Yes, most of the people I know in weekly computer journalism have journalist
backgrounds.  Reporters are paid $20,000-$30,000 per year.  This is riches
compared to what newspapers pay, which is why journalists come to computer
magazines.  But it's shit compared to what engineers and computer scientists
are paid, which is why you don't see too many of them there.  (I'm an
exception; I have a BS in computer science from RPI.  And there's a couple
other real techies here.  But we're definitely the exception.)

Again, I'm not trying to excuse errors.  Errors are inexcusable, and I would
be very glad if you-all told me every time InfoWorld made one.  (I may go slit
my wrists afterwards, though.)  It would make me feel better if you also told
me every time we did something well, too.

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 13:04:17 GMT
From:      tmallory@PARK-STREET.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs



> a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
> the src IP address on the packet that is being returned to me and
> sometimes the ping yields 129.24.#.# as the src IP address where #.# is
> the correct IP address of the responding machine.


Flame:  An ICMP echo to a broadcast address should get no response!  What an
incredibly obnoxious thing to do!

Opinion: If a reply is sent, then the best response is to insert the IP
address of the interface over which the packet was received in the source
address field of the reply.

Tracy Mallory
BBNCC

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 13:12:53 GMT
From:      wrl@FORD-COS2.ARPA (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   Interfacing SUN to AUTODIN.


Has anyone out there ever interfaced a SUN 3 or 4 to the 
Governments "AUTODIN" system ???

I am working on such a project and was wondering if anyone had
already written code in "C" or "ADA" or any other type of code 
that interfaced with SUN OS for controlling of Send/Recv of
message traffic To/Fm the AUTODIN system.

Bill Lewandowski	WRL@FORD-COS2.ARPA
(719) 594-1899

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 13:47:29 GMT
From:      hassler@asd.wpafb.af.MIL (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   Class A Logical Host Addressing

A few quick questions concerning Logical Host addressing:

First, is anyone using this currently? I know of  the  definition
of how it is to be done on the X25 connections to the net.

Furthermore, If a single host has two physical connections to the
net and both use the same logical address, how does the PSN route
traffic between the two links? Is it load balanced?

Barry D. Hassler
Control Data Corporation 
Integration Services Division

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 15:00:19 GMT
From:      mark@psauly.UUCP (marco graziano)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP on STREAMS

Pisa 9/15
First of all let me introduce myself. I am a system software designer at
Olivetti. My group in Pisa, four enthusiastic guys including me,
is currently involved in the development of networking software.
Olivetti produces and sells, among others, 68020 based mini-computers
running a proprietary version of Unix called X/OS.
X/OS is derived from 4.2 BSD and offers some additional features such
as multiprocessor support, NFS, real-time and system V compatibility
(release 2).

Our goal is to have a new implementation of the Internet protocol suite
and of the TLI interface, based on STREAMS. We already have a version
of X/OS including STREAMS and we are investiganting the possibility
of acquiring from third parties STREAMS based TCP-IP components.

We already know of available products by Interactive, Wollongong Group,
Lachman, Spider and Unisoft. We would like to ask some questions about
these or other products we might not know of.

About the architecture, can it be thought of as a set of different
'virtual device drivers' (in the STREAMS terminology) linked together
in a hierarchy reflecting the TCP-IP layers ?
	- If so, what are the real advantages, if any ?
	- Are the different components truly independent from each other ?
	- Can each component be accessed directly, bypassing the components
	  above it ?
	- For example, can one easily link another transport
	  layer driver beside the ones already existing ?
	- How could NFS be integrated in such architecture ?

About the implementation, how heavily do the system V based implementations
use kernel's functions that are not easily mapped to BSD's ?
	- Are the 'device drivers' kept alive by any deamon, or are
	  they initialized by the kernel itself at boot time ?
	- Is there any global data structure/area that is shared by the
	  drivers and, possibly, the kernel ?
	- In particular how are the message buffers passed among the layers
	  and using which structures ?
	- In the system V implementations, has the original kernel to be
	  modified in order to support uniform access to system calls related
	  with either sockets or standard files ?
	- Which methodology and tools have been used to measure the performace ?

I want to thank everybody who answered my previous question and provided me
with very useful information.
Bye, Marco.

---------------------------------
 Marco E. Graziano
 Ing. C. Olivetti & C. SpA
 System & Networks Division
 via Palestro, 30
 56100 Pisa - Italy
 Phone: +39-50-500211
 Email: oliveb!psauly!mark@sun.com
 Fax  : +39-50-47378
---------------------------------

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 17:11:43 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

tmallory@park-street.bbn.com writes:
   > a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
   > the src IP address on the packet that is being returned...

   Flame:  An ICMP echo to a broadcast address should get no response!  What an
   incredibly obnoxious thing to do!

This looked just too tempting, so I headed off to one of our Sun-3/180
servers (SunOS 3.5.1) to see what would happen if I abused its client
subnet (12 Sun3/50 clients) in this way.  The result was just mighty
entertaining - the `packet loss' statistic is easily the best part,
followed closely by the claimed IP address...

Script started on Thu Sep 15 12:06:42 1988
[12] [12:06pm] tree:/dino0/karl> ping -s 128.146.28.255
PING 128.146.28.255: 56 data bytes
64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
^C
----128.146.28.255 PING Statistics----
4 packets transmitted, 48 packets received, -1100% packet loss
round-trip (ms)  min/avg/max = 0/25/40
[13] [12:06pm] tree:/dino0/karl> exit

script done on Thu Sep 15 12:07:01 1988

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 17:36:29 GMT
From:      prue@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

>>  1)  If the second path was 25% of the speed of the first path then 25% of
>>      the packets could be sent that way.  [...]
>>      if the two end sides were running the Van Jacobsen/Mike Karels code
>>      I believe this wouldn't be to much of a problem.  [...]
>
>
>The first thing (splitting load among routes) would screw up the
>Jacobson/Karels improved TCP completely.  They get a big win by
>estimating the variance of the round trip time; using alternating
>routes for different packets would drive this variance way up, causing
>the timeout to be set high, causing long stoppages on lost packets.

I disagree.  The first path is four times as fast but has four times as 
many packets.  The link delay is only 1/4 the second line but the queuing 
delay is four times as great.  The variation of the delivery times for the 
five packets would be less than using a single line.  As the queue sizes go 
up the variation in the network delay goes up.

I do however agree with your other point, type of service routing could 
put the second path to very good use.

Requards,

Walt Prue
Prue@isi.edu

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 17:37:25 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

As long as I was at it, I decided to look at what a large collection
of diverse machines did with pings to .255.  I hit our backbone
ethernet (128.146.8, a little over 100 hosts) with a ping like this,
and the results are:

Responding with 128.146.8.255:
Sun-3/180 (SunOS 3.5.1 [UNIX]).

Responding with their own addresses:
HP-9000 (HP-UX [UNIX]), IBM-RT/PC (Mach), Proteon P4200, BBN Butterfly
(Mach), Pyramid (OSx 4.x [UNIX]), Encore Annex telnet server.

Not responding:
DEC-2060 (TOPS 6.1; responds to direct ping), AT&T 3B2/400 (SysV
Rel3.0 + TWG WIN; responds to direct ping), Kinetics Mac gateways
(KIP; doesn't respond to direct ping), Encore Multimax (Umax 4.2;
responds to direct ping), TI Explorer (Zetalisp; responds to direct
ping), Xerox-1108 (Interlisp; responds to direct ping).

Also, we have one HP-9000 client subnet.  When pinging that subnet's
broadcast addr (128.146.43.255), *only the server* responded - the
rest were silent.  Weird.

--Karl

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 18:37:00 GMT
From:      mohsen@TWG.COM (Mohsen Mortazavi)
To:        comp.protocols.tcp-ip
Subject:   re:Need help with TCP/IP broadcast address



Version 2.2 of The Wollongong's Group TCP/IP allows you to set the broadcast
address of an interface. The "ifconfig" usage message however did not list
"broadcast" as a vaild parameter. The usage message has now been corrected.
The man page for ifconfig lists broadcast as a vaild parameter.

The default broadcast address for hosts using Version 2.2 (BSD 4.3) is an 
address with the host part of all 1's which is in conformance with RFC 919. 
In 4.2 BSD, the broadcast address was the address with a host par
t of all 0s. 

If you have a mixture of hosts running the 4.2 and 4.3 based TCP/IP, it is best to use a broadcast address with a host part of all 0's which is recognized by
both. In order to do so you need to include an "ifconfig" command in 
/etc/rc2.d/S86win3b to set the broadcast address each time network is started.
You should include the "ifconfig" command after the "inetinit" in this file.
For example, if you have a host with an internet address of 80.0.0.1 you 
should include the following line in S8
6win3b:

	/usr/etc/ifconfig en0 broadcast 80.0.0.0

Where en0 is the interface, and 80 is the network. 

Mohsen Mortazavi
mohsen@twg.com

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 18:39:09 GMT
From:      ferencz@cwsys3.cwru.Edu (Don Ferencz)
To:        comp.unix.wizards,comp.unix.questions,comp.protocols.tcp-ip
Subject:   TCP/IP Broadcast Address & Wollongong WIN3B


Hello again.

A short while back I posted a question pertaining to the "broadcast
address" of my particular TCP/IP version - Wollongong's Enhanced
WIN3B running on three AT&T 3B2/310's.  I asked if anyone knew why all of
my attempts to change the broadcast address from a sockets application
(with the SIOCIFGBRDADDR ioctl) were failing with EINVAL.  Well, many
people pointed out what should have been painfully obvious: that
version of TCP/IP is based on BSD4.2 Sockets, which does not support
a change of broadcast address!  However, the #define for
SIOCIFGBRDADDR appears in the header file <ioctl.h>!!!  My thanks
to all who responded, and my condolances to those who had wished to
do the same thing I did.

===========================================================================
| Don Ferencz                       |  "All the world's indeed a stage\   |
| ferencz@cwsys3.cwru.EDU           |   And we are merely players\        |
| Dept of Systems Engineering       |   Performers and portrayers"        |
| Case Wetsren Reserve University   |     -- Rush                         |
===========================================================================

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 18:40:07 GMT
From:      "Steven_S._Kang.ESAE"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Sun's TCP/IP Implementation


	I would like to find more about Sun's implementation of TCP/IP on its
workstations and how it relates to their other network services such as NFS.
Can anyone tell me where and which documents I should get?  Is there a printing
protocol defined within TCP/IP?
Thanks for your help,
Steve

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 20:12:51 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on SUNos 4.0

From article <626@kinetics.UUCP>, by minshall@kinetics.UUCP (Greg Minshall):
>     return (*routine)(argno, args);
 Oops (sigh) that should be
>     return (*routine)(argno-1, args);

Greg Minshall

ps - the symptom with the first "fix" is that "quit" no longer works.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 20:47:20 GMT
From:      lotto@wjh12.harvard.edu (Jerry Lotto)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <21843@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>As long as I was at it, I decided to look at what a large collection
>of diverse machines did with pings to .255.  I hit our backbone...
>Responding with 128.146.8.255:
>Sun-3/180 (SunOS 3.5.1 [UNIX]).

And I am sure that someones bridge will then decide that they know
where "the broadcast address" lives and stop forwarding it.
I have seen this (anti-social) behavior in DEC Lanbridges and it
does not bode well for the network until someone resets the beast.
Takes a while to find if you aren't looking for it.


-- 
Gerald Lotto - Harvard Chemistry Dept.
UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto
ARPA:  lotto@harvard.harvard.edu

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 21:20:05 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <8809151450.AA23101@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes:

>Flame:  An ICMP echo to a broadcast address should get no response!  What an
>incredibly obnoxious thing to do!

What do you mean it should get no response?  It is a legal broadcast
that all machines should reply to.

My reason for pinging to the broadcast address is to aid my network
debugging.  The ping tells me several things.  Which machines are on
our ever expanding net (known and unknown), who is running trailers
(arp table), and the hardware address of many machines.

I especially like it because I can quickly tell what new machines are
on our net by the fact that there is no name associated with the IP
address in the arp table.  If you can tell me a better way to do this,
I am all ears.

>Tracy Mallory
>BBNCC

Tait Cyrus
University of New Mexico
Dept. Electrical and Computer Engineering
cyrus@hi.unm.edu

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 88 21:23:40 GMT
From:      bae@unisoft.UUCP (Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   VMTP availability for BSD 4.3?

Are there any available implementation of VMTP for BSD 4.3?
RFC1045 sketches out a possible socket interface for VMTP
on BSD 4.3 Unix.  Other than Stanford's V related work, there seems
to be little discussion on VMTP work.  Anyone else using VMTP?
Any comments?

/hjb


-- 
=============================================================================
Don't follow leaders; watch the parking meters.

Hwa Jin Bae				bae@tis.llnl.gov	(Internet)

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Sep 88 13:12:15 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: possible network bogons
Sorry, I sent one answer when the question came over the 'gated' list, but
forgot to answer the question to 'tcp-ip'.

    [gated error message ]
     > rt_NRupdate: net 238.196.27.0 not class A, B or C from 26.1.0.40
	...

Speaking for the 'core', of which 26.1.0.40 is a member, those are nets that
someone sent in, and we do not discard.  I think it is not long lived, because
I did not see them in the routing table around 2pm this [wed] afternoon.  This
is some sort of bogus packet that arrived from some other place, and I think
there is not much we can do until we can catch them red handed.

A reasonable place to ask this question is on the mailing list
'egp-people@bbn.com'.  If you wish also to subscribe to the list, send your
request to 'egp-people-request@bbn.com' (no surprise there :-).

Can you say how many times per day you see a particular net?  Does it cause
you to be unable to reach some net you think should reachable?

Mike Brescia
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 08:08:13 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Using alternate equal cost routes effectively


> From: dagg@lace.lbl.gov (Darren Griffiths)
> 
> In many cases there are different paths to the same host, either via
> backup redundant links or because of longer hops through the network.
> Usually the gateways know about these different paths and take the
> fastest (determined by the metric) and leave the other path untouched.
> This other path may be idle and quite useful, there are two ways of
> making use of this path.  
 
> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
> 
> 	When you say "different paths" do you mean alternate routes to
> the same address or alternate addresses to the same host (which is the
> subject of the thread)?  In the first case, you as a user don't care what
> paths your datagrams take so long as they get there quickly.  However,
> load sharing is done by ciscoIGRP and is proposed in Moy's Open SPF IGP
> protocol draft for equal-cost routes.
> 
> 	Presumably, the untouched routes are being used by other
> datagram streams.

  Where can I get a copy of Moy's protocol draft?  I'd be interested to
know if it's anything like a scheme that Mike Karels described to me a
few months back.  (Please forgive me Mike if I butcher this in trying to
explain it.)

  Mike suggested that:

	  When a host H gets a RIP broadcast from gateway G2 advertizing
	a route to a destination D with cost C(G2, D) and H has already
	got a route to D through gateway G1 with cost C(G1, D) == C(G2,
	D), then H should ``throw a die'' to decide whether to switch
	gateways for D.

	  The probability of switching should be very low to minimize
	routing table thrashing and allow timing statistics to develop so
	the new congestion controls wouldn't be defeated.

	  The effect of such a modification of a host's response to RIP
	broadcasts would be to have hosts their routing choices out among
	a set of gateways offering equal cost routes to destinations.  If
	a gateway goes down, all hosts currently using that gateway would
	immediately switch gateways.  If a gateway comes up, hosts will
	slowly start using it.  If a gateway is flakey and doesn't ever
	stay up reliably, almost no hosts will ever try to use it.

  Mike may well have been quoting Moy's idea, but I have no idea since we
were just talking informally.  (Again Mike, please forgive me if I've
butchered this.)

Casey

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 08:18:23 GMT
From:      mccoy@eecs.nwu.edu (Jim McCoy)
To:        comp.protocols.tcp-ip
Subject:   Re: BFTP Sources


Slight correction to the file name fot rhe BFTP sources at
VENERA.ISI.EDU.  After trying to get them with a script, i discovered
that the name is not BFTP.1.tar.Z, but BFTP.2.tar.Z.
			                    ^


					-jim mccoy

------------------------
mccoy@accuvax.nwu.edu
------------------------
"Far too many notes for my taste..."  -Phantom of the Opera

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Sep 88 13:51:19 EDT
From:      Nick Gimbrone <NJG@CORNELLA.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Multiple TCP/IP servers on one host
It seems that the 'right' solution for this problem is for the Domain
Name Server code to provide an exit to order the list of addresses
in any order that might be appropriate for the host in question. The
database only need know which exit subroutine to call for ordering the
list. This exit code may perform any 'sort' that is appropriate for the
exact situation of the host in question. The sorts of decisions might
include considerations of: costs, performance, 'goodness' for reaching
the requester, load, etc (anything you can imagine coding up an
algorithm to do :-).

However, as noted before on the list, caching of previous responses
may make things like load balancing problematic.
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Sep 88 15:56:19 EDT
From:      jose@MCL.UNISYS.COM (Jose Rodriguez)
To:        tcp-ip@sri-nic.arpa
Cc:        jose
Subject:   Questions on IP & 802.2,3 & use or value of streams.



Hi, 

Now that every computer manufacturer must support TCP/IP, people in the
commerical side of my company have asked me two questions, one TCP/IP
related, the other streams related which not having the answers myself,
I would like to ask in this forum:

1) Anyone using IP over 802.2 LLC or 802.3 MAC layers in commerical or
academic products? (Commercial folks are interested in having their
products conform to "standards").

2) What is ATT's streams used for: like Berkeley's sockets, to provide
access to protocol families? Is there a "native" streams protocol or
protocol suite? And more concrete: just like TCP/IP is being or will be
delivered with streams, are there other protocol suits available
(commerically or otherwise) with a streams interface?, say ISO's? 

thanks for your help,

Jose M. Rodriguez
Unisys McLean R&D
jose@mcl.unisys.com


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 16:08:03 GMT
From:      linus!news@gatech.edu  (USENET NEWS)
To:        tcp-ip@sri-nic.arpa
Subject:   Batch Processing -- via SMTP...
-------
    It appears that BATCH processing is something that is missing from the 
network data communications scheme.  There are many users who use remote 
online services to access and retrieve files on a regular basis.  Many of 
those users would be better served if their data needs could be satisfied by 
some sort of batch request.  An example is the way in which one may receive 
copies of RFCs from sri-nic.arpa by sending an E-mail request. 
From: jed@mitre-bedford.ARPA (John E. Daum)
Path: mbunix!jed

    Additionally, a priority mechanism could be of value whereby urgent 
requests for data-extracts/file retrievals could be satisfied before routine 
requests (possibly analogous to some combination of the services from Federal 
Express, UPS, and the US-Mail). 

Benefits

    The user would not have to actively contend for resources on the network 
and destination host.  Thus the retrieval of data would require less user 
time.  Subsequently, the ease of obtaining data improves the flow of 
information. 

ANY COMMENTS

    What are the possibilities for expanding SMTP to provide a mechanism to 
allow batch processing to occur over the network(s)?  

    Are there any Concerns/Technicolor-Herrings re: Security or Host 
Processing Load? 

    Alternatives? 

-------------
John Daum    ARPA: jed@mitre-bedford.arpa               
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 16:17:59 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <23635@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
>In article <8809151450.AA23101@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes:
>
>>Flame:  An ICMP echo to a broadcast address should get no response!  What an
>>incredibly obnoxious thing to do!
>
>What do you mean it should get no response?  It is a legal broadcast
>that all machines should reply to.
>
	No, no, no.  ICMP messages are special, because they are error
messages.  They must be treated carefully and conservatively.  You
should not respond to a broadcast with an ICMP message, even if the
source of the broadcast is an ICMP message.
	I refer you to the upcoming Host Req'ts RFC and/or Bob Braden,
Craig Partridge, et al for further details.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 16:46:13 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <303@wjh12.harvard.edu> lotto@wjh12.UUCP (Jerry Lotto) writes:
>In article <21843@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>>As long as I was at it, I decided to look at what a large collection
>>of diverse machines did with pings to .255.  I hit our backbone...
>>Responding with 128.146.8.255:
>>Sun-3/180 (SunOS 3.5.1 [UNIX]).
>
>And I am sure that someones bridge will then decide that they know
>where "the broadcast address" lives and stop forwarding it.

If an IP bridge does this, then its' implementation of IP/TCP is
hosed.  

The only time we have seen a problem simular to this is when a new
machine was installed and the person installing it mis-typed
and the machine thought it's IP address was broadcast.  This
resulted in all machines sending broadcast packets to this machine.
We noticed this problem when all of our gateways lost all their
routes (routing packets were going to this screwed machine).
Simply pulling this machine off of the net solved the problems.

>I have seen this (anti-social) behavior in DEC Lanbridges and it
>does not bode well for the network until someone resets the beast.
>Takes a while to find if you aren't looking for it.

Huhhh????  A DEC Lanbridge is protocol independent.  I think what you
are refering to is the fact that a DEC Lanbridge (using old proms)
will not forward packets sending to the broadcast address
(ff:ff:ff:ff:ff:ff) iff it has seen this address in the src field
of some other ethernet/802.3 packet.  We have seen this happen and
the result is NO broadcasts get forwarded through the DEC Lanbridge;
i.e. RWHO/ROUTE/etc packets are NOT seen by machines on the other
side of the DEC Lanbridge.

We have yet to find the machine that thinks its' hardware address
is ff:ff:ff:ff:ff:ff, though we are getting new DEC Lanbridge prom
that take care of this problem.

>-- 
>Gerald Lotto - Harvard Chemistry Dept.

Tait Cyrus
University of New Mexico
Dept. Electrical and Computer Engineering
Parallel Processig Research Group
cyrus@hi.unm.edu

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 88 23:21:32 GMT
From:      yba@arrow.bellcore.com (Mark Levine)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP "comform" to ISO/OSI?

In article <8809101902.AA03190@bert.mitre.org> cperry@BERT.MITRE.ORG (Chris Perry) writes:
>What I surmise, particularly from Dave Cheriton's Blazenet writings
>and from AT&T/Bellcore's current work on high-speed switching fabrics,
>is that we must begin to look at protocol architectures that exploit 
>the coming broadband media.
 
>And who's going to set an agenda for exploring what we can do with
>them?

Seems to me you have stated the answer above the question.  The group I work
with, the Integrated Media Architecture Laboratory at Bellcore, is decidedly
in the business of exploring what we can do with BISDN and fast networked
media, not to mention how to construct the network.  There seems to be quite
a bit of interest from people in the telecommunications business now.

By the by, ATT and Bellcore are VERY different organizations, and they aren't
really allowed joint cooperative work as I understand a certain modification of
consent decree (but I am not an official company spokesman, either!).  I know
you did not make it explicit, but they have a "thing" about lumping ATT and
Bellcore work together like that.  We need to look at hardware architectures
for the things connected to those networks at least as hard as the protocols
employed.  I suspect all the manufacturers of that hardware (CPE) will be as
interested in doing their own research as the carriers of the information
between that hardware.

Eleazor bar Shimon, once and future Carolingian
yba@sabre.bellcore.com

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 01:23:10 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

We've certainly been bitten by hosts that respond to broadcasts
inappropriately, so I'm sympathetic with the idea of being very
conservative in responding to ICMP broadcasts.  But let's not go too
far.  Kent England says you are never allowed to respond to a
broadcast by sending an ICMP, even if the source of the broadcast is
an ICMP.  I think what should be said is that you never respond to a
broadcast by sending an ICMP *error* message.  If the original
broadcast is one of the ICMP queries, and the query is well-formed,
you can certainly send the corresponding response.  Otherwise you
couldn't broadcast an ICMP net mask request and expect to get a
response.  I have mixed feelings about broadcast ICMP echo requests.
If you do it very much, it could produce very bad results.  However I
can also think of situations where I would want to be able to do it.
So I'm inclined to say that it should be legal to respond to a
broadcast ICMP echo request.  If the host requirements RFC says what
you said, I think Bob Braden should think again.  Either that or come
up with some other way to find out your net mask...

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 02:11:11 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <24915@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
> 	No, no, no.  ICMP messages are special, because they are error
> messages.  They must be treated carefully and conservatively.

That means my favorite diagnostic tool and stress test will go away:
`ping -f <broadcast>', where 'ping' takes '-f' as 'flood the target at
100 packets/sec.'  (100 p/s * >100 hosts = ?)  Believe it or not, this
can be quite useful for constructive purposes.  Tho it will break my
heart, this tool should go to the same retirement home as the old
Atoms-for-Piece plan for digging a new Panama canal.

The usefulness of the relatively innocuous 'ping <broadcast>' to see
what's there can be duplicated with a small program which sends to all
possible host addresses (paying attention to netmask).  Modern machines
can generate at least a couple hundred packets/sec from user code.  (At
least our's and our competator's are much better than that. :-)  Thus
in any situation where you don't expect too many responses for the test
to social acceptible, it would take the new program only seconds to do
the same thing.

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 02:53:15 GMT
From:      mechtjm@ness386.swbt.COM (Tom Mecke   512+377-5796)
To:        comp.protocols.tcp-ip
Subject:   TCP Network Admin article


	Could some kind soul please e-mail to me the TCP/IP network
administration article posted by the Rutgers CS Department back in
July.  My copy was eaten by a disk crash.

	Thanks in advance.

--
Tom Mecke

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 04:20:02 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs


	 And I am sure that someones bridge will then decide that they know
	 where "the broadcast address" lives and stop forwarding it.
	 I have seen this (anti-social) behavior in DEC Lanbridges and it
	 does not bode well for the network until someone resets the beast.
	 Takes a while to find if you aren't looking for it.


	 -- 
	 Gerald Lotto - Harvard Chemistry Dept.
	 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto
	 ARPA:  lotto@harvard.harvard.edu


Actually, the Lanbridge, as all other bridges, looks at the source and 
destination addresses in the ethernet frame, NOT in the IP header.  So
this particular bug only is triggered by an ethernet frame with a 
source address of FFFFFFFFFFFF.  The Sun's do have an annoying bug when
turning around broadcast pings, but they do send them with the proper
ethernet frame addresses.  I have seen Kinetics Appletalk 'gateways'
fail in such a way as to send ethernet frames with broadcast source addresses,
and this does cause problems on a Rev. E LANBridge.   DEC is working a fix
though, and at least with LANBridges you can use RBMS to reset them 
remotely.... 



					Thanks,
					   Milo

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Sep 88 11:18:25 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Jerry Lotto <lotto@wjh12.harvard.edu>, tcp-ip@sri-nic.arpa
Subject:   Re: ICMP's & IP src addrs
>And I am sure that someones bridge will then decide that they know
>where "the broadcast address" lives and stop forwarding it.
>I have seen this (anti-social) behavior in DEC Lanbridges and it
>does not bode well for the network until someone resets the beast.
>Takes a while to find if you aren't looking for it.

Now wait a minute....It's one thing to reply to the local IP broadcast
address - it's another thing to use the Ethernet broadcast address as
your source address!  DEC Lanbridges don't look at anything higher than
that.  They should ignore multicast/broadcast addresses as a source
address (although I don't really know if they do).

I have enough problems with the ARP storms on my network from good (and
also from incorrect) broadcast addresses.

Doug Nelson
Michigan State University
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Sep 88 19:43:17 PDT
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        tcp-ip-request@sri-nic.ARPA
Subject:   Will the real .... please stand up?
Both Xerox and the IEEE consider it their obligation to protect the
identity of the name of an entity which has been assigned 6 byte
manuf. ids or 2 byte Ethertypes.  They have ignored suggestions that
at least they put a "check mark" on their application form, indicating\
that they are authorized to "release" this information.

In the meantime, I would appreciate hearing from the "owners" of these
manuf ids, seen on various nets:

00001b 000086 0000a9 0000b3 080001 080003
080019 08002e 080036 080036 080046 080067
080087 080090

They ARE shipping hardware, hence ought not be shy about keeping their
intentions secret any longer!!

Tnx in advance..............
Harry
(415) 965-1800  (Network General Corp.)
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 14:24:29 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs


	>Flame:  An ICMP echo to a broadcast address should get no response!  
	>What an incredibly obnoxious thing to do!

	What do you mean it should get no response?  It is a legal broadcast
	that all machines should reply to.

Recall that broadcast was not originally part of the IP design, and indeed
that many media that support IP do not support hardware broadcast.  As such,
it is to be expected that the "proper" behavior of various protocols in
response to broadcasts is not well defined in the specs.  IP broadcast was
added mostly to support the functionality provided by Ethernet broadcast.  In
any CSMA environment (though not on a TR!) a broadcast ICMP echo request is
a VERY BAD idea since it is guaranteed to generate a massive collision as
everyone tries to answer at once.  Designers of broadcast request-response
Ethernet protocols almost always go to great effort to insure that the 
number of legitimate respondents is bounded, and preferably 1 (cf proxy 
ARP).

If the spec doesn't forbid it, it should.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 15:18:25 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

>And I am sure that someones bridge will then decide that they know
>where "the broadcast address" lives and stop forwarding it.
>I have seen this (anti-social) behavior in DEC Lanbridges and it
>does not bode well for the network until someone resets the beast.
>Takes a while to find if you aren't looking for it.

Now wait a minute....It's one thing to reply to the local IP broadcast
address - it's another thing to use the Ethernet broadcast address as
your source address!  DEC Lanbridges don't look at anything higher than
that.  They should ignore multicast/broadcast addresses as a source
address (although I don't really know if they do).

I have enough problems with the ARP storms on my network from good (and
also from incorrect) broadcast addresses.

Doug Nelson
Michigan State University

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 88 17:30:34 GMT
From:      cvincent@cochise.UUCP (Vincent)
To:        comp.protocols.tcp-ip
Subject:   RE: Logical Class A Addressing


    Barry,

    I don't profess to be an expert and may get flamed but here goes:

              LOGICAL HOSTS ON AN ARPANET STYLE CLASS A NETWORK

    As you know, the third field of an Arpanet/Milnet style Class A IP
    address is called the logical field.  The use of this field is very
    controversial.  For the Milnet at least, the NIC has stated that they
    are not authorized to issue logical addresses.  The reason for the
    restriction will become clear later.  In theory and practice, one can
    use this style of address to place several Class A hosts behind a
    single PSN port.  Figure 1 shows three hosts connected to a
    concentrator, an IP router.  In DDN terms, this device is referred to
    as a transparent gateway.  This transparent gateway is in turn
    connected to a single port of a PSN.

                                TO OTHER PSN'S
                             .    ON THE DDN    .
                            /|\                /|\
                             :.....        .....:
                                  :        :
                               [MODEM]  [MODEM]
                                  :        :
                         |=======[16][17][18]======|
                         |                         |                         
                         |         PSN 122         |                         
                         |                         |                         
                         |=====[1][2][3][4][5]=====|
                                     | |    ^------------PSN PORT
                                     | |    
                                     | |
                         |=========[PORT]=========|
                         |                        |                         
                         |  TRANSPARENT GATEWAY   |
                         |                        |                         
                         |=====[2][3][4][5][6]====|
                                :     :     :
                                :  [MODEM]  :
                     ...........:     :     :..........
                     :                :               :
                     :             [MODEM]            :
                     :                :               :
               [-----:----]     [-----+----]    [-----+----]
               |  HOST A  |     |  HOST B  |    |  HOST C  |
               |26.3.2.122|     |26.3.4.122|    |26.3.6.122|
               [----------]     [----------]    [----------]

              LOGICAL HOSTS CONNECTED VIA A TRANSPARENT GATEWAY

                                  Figure 1

    In Figure 1, each host address uses port 3 of PSN 122.  The only
    difference is the logical field.  In this case the three hosts are
    following the standard naming convention starting at number 2 as
    address 0 and 1 are reserved.  The transparent gateway gets its name
    by the fact that it does not disassemble the X.25 packet.  By the use
    of header length information, the gateway looks into the IP header
    and finds the destination IP address.  The gateway examines the
    logical field of the IP address and passes the packet on to the
    proper host.  This is an excellent way to share the bandwidth of a
    single port.  Theoretically the IP address will allow 253 (with
    logical addresses 0, 1, and 255 reserved) hosts behind the router.
    In reality it depends upon the degree of bandwidth required by each
    host.

    
    There are several problems with this arrangement.  First and
    foremost, RFC 1005 (May 1987) contains a suggestions for rearranging
    the 32 bit IP address.  This suggestion, if adopted, would render the
    transparent gateway router useless.  This is why the Milnet manager
    is discouraging the use of this addressing scheme.  Users are not
    restricted from using this field, they are only restricted from being
    published in the NIC's host table.  (for a good horor story, ask Mary
    Stahl at the NIC about a site she worked at where this type of
    address caused many problems.) Without being published in the NIC's
    host table, it is difficult to receive electronic mail without the IP
    address as the distant end will have no way of knowing which PSN and
    port the host is on.  This is not a problem if the DOMAIN server
    system is employed.  The domain server system allows hosts to receive
    mail without being on the NIC's host table (see RFC 1032 through RFC
    1035).  However there are many domains (like mine) which do not
    employ this wonderful and intelligent design.

    > First, is anyone using this currently? I know of the definition
    > of how it is to be done on the X25 connections to the net.

    Currently, the HOST.TXT file shows only 3 of the 1727 Milnet hosts
    using this addressing format.  These three machines are special
    purpose Sun work stations with only a single user per machine.
    There are many others, they just are not published.

    There is another concern with using a transparent gateway.  Some
    gateways may or may not fully participate with the Internet Control
    Messaging Protocol (ICMP) [1].  The ICMP is concerned with network
    flow control.  A transparent gateway which does not fully participate
    with ICMP may choke the PSN, or it may not inform the host that the
    distant end is dead [2].

    Why anyone would want to use this type of gateway is beyond me.  I
    really would like to hear some good reason to use it.  I may not be
    aware of some special feature about remaining a Class A host.  My
    understanding is folks like to use them as they believe this is the
    only way to do X.25 type multiplexing.  However, there are gateway
    devices (like Cisco Systems) which allow the same type of PSN port
    sharing without the use of the logical field.  By changing the hosts
    from Class A to Class B or C, a gateway device can route X.25 packets
    from a single port on the PSN to as many X.25 hosts as the gateway
    can support.  This type of gateway box also gives you EGP and other
    handy services.  All transparent gateway

    > Furthermore, If a single host has two physical connections to the
    > net and both use the same logical address, how does the PSN route
    > traffic between the two links?  Is it load balanced?

    PSN's route X.25 packets and don't care about IP addresses.  Gateways
    and hosts put on the X.25 address for a specific PSN and port.
    Therefore it depends on the IP to X.25 mapping in a given distant end
    gateway and host.  All transparent gateway boxes that I have come in
    contact with do allow for load balanced dual-homing configurations.
    However the load balancing is done for outbound traffic.

                                 REFERENCES

    [1] Comer, Douglas; TCP/IP pg 195
    [2] RFC 1009 "Requirements for Internet Gateways" pg 9.

    Hope this helps Barry,

    Curt Vincent
    Army Computer Engineering Center
    Army Information Systems Engineering Command
    Fort Huachuca, AZ 85613-7300

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

    Disclaimer:  The comments are my own and do not reflect the opinions
    and philosophies of the United States Army Computer Engineering
    Center, or this Command. (Regardless if they are right, or wrong!)

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 88 02:43:17 GMT
From:      hjs@LINDY.STANFORD.EDU (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   Will the real .... please stand up?

Both Xerox and the IEEE consider it their obligation to protect the
identity of the name of an entity which has been assigned 6 byte
manuf. ids or 2 byte Ethertypes.  They have ignored suggestions that
at least they put a "check mark" on their application form, indicating\
that they are authorized to "release" this information.

In the meantime, I would appreciate hearing from the "owners" of these
manuf ids, seen on various nets:

00001b 000086 0000a9 0000b3 080001 080003
080019 08002e 080036 080036 080046 080067
080087 080090

They ARE shipping hardware, hence ought not be shy about keeping their
intentions secret any longer!!

Tnx in advance..............
Harry
(415) 965-1800  (Network General Corp.)

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Sep 88 12:43:08 PDT
From:      satz@clash.cisco.com
To:        eggers@dirac.cc.nd.edu (Mark D. Eggers)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: SGMP confusion
>> This came when I was compiling the code. There is a call in
>> sgmp/src/sgmpwatch/main.c on line 121 that goes like this:
>> 
>> nstob(argv[option_count+1],number);
>> 
>> and seems to convert an internet number in dotted decimal notation
>> to an unsigned int (network or host order address??). I just
>> commented this line out, and limited the application to only using
>> host names. Not nice, but it should work.

I removed some dead code and apparently missed a place. Changing the above
line to the following should do what you want. This change has not been
tested yet.

    *number = dotto32bit(argv[option_count + 1]);

The /etc/sgmp.variables file that is distributed with the RPI tools is not
guaranteed to be correct for anything other then the cisco specific
variables. You should check with your vendor to make sure you obtain their
correct implementation specific variables.

Greg Satz
cisco Systems
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 1988 13:16-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        bridge2!fjd@sun.com (Farokh J. Deboo)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: ICMP's & IP src addrs
According to the draft Host Requirements RFC, a host must silently ignore
ICMP Echo and Timestamp Requests sent to an IP broadcast address.  A host
may (at the implementor's discretion) reply to an Echo or Timestamp Request
sent to an IP multicast address, in which case the IP source address of
the Reply is the address of the interface on which the Request arrived.
By the routing rules in the Host Requirements RFC, that interface is also
the one over which the Reply is sent.

ICMP *error* messages (destination unreachable, redirect, source quench,
time exceeded, parameter problem) must never be sent in response to any
datagram received as a link-level broadcast or as an IP broadcast or
multicast.

Steve Deering
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 88 06:20:32 GMT
From:      fjd@bridge2.UUCP (Farokh J. Deboo)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In this discussion, although we have determined that the  source  address
to  be  used for the ICMP echo response should be the internet address of
the responding interface (as opposed to the destination  address  of  the
original broadcast ICMP echo request), there have been differing opinions
as to whether an echo response should at all be generated to the original
broadcast ICMP echo request.

Can we reach some consensus on this issue, and perhaps issue the  result-
ing statements in an enhanced RFC?  Or is it already part of the Host Re-
quirements RFC (where can I get a copy?).

RFC 792 already states the following about  when  NOT  to  generate  ICMP
responses:

1.   To avoid the infinite regression of messages about messages etc., no
     ICMP (error) messages are sent about ICMP messages.

2.   Also ICMP messages are only sent about errors in  handling  fragment
     zero of fragmented datagrams.

Farokh Deboo (sun!bridge2!fjd)
3Com Enterprise Systems Division
(415) 940-7677
--------------

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 88 15:11:34 GMT
From:      ccc1@cseg.uucp (Chris C. Corke)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Search for TCP-UUCP

I am looking for a UUCP program which will run under TCP-IP on internet, 
instead of via phone line.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Sep 88 23:42:52 PDT
From:      cire@clash.cisco.com
To:        tmallory@park-street.bbn.com
Cc:        Tait Cyrus <hi.unm.edu!cyrus@hc.dspo.gov>, tcp-ip@sri-nic.arpa
Subject:   Re: ICMP's & IP src addrs
>> Subject: Re: ICMP's & IP src addrs 
>> Date: Thu, 15 Sep 88 09:04:17 -0400
>> From: tmallory@PARK-STREET.BBN.COM
>> 
>> Flame:  An ICMP echo to a broadcast address should get no response!  What an
>> incredibly obnoxious thing to do!
>> 
>> Opinion: If a reply is sent, then the best response is to insert the IP
>> address of the interface over which the packet was received in the source
>> address field of the reply.
>> 
>> Tracy Mallory
>> BBNCC


Actually, I've found use for sending out broadcast pings.  It can be
very usefull when you are at a node in an internet that for one
reason or another seems to not hear anymore.  Say you are the net
administrator and don't have a lot of time.  Can anyone hear?  Throw
out a broadcast ping and see what you get back.  The information can
be very useful in a gross sort of way.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 88 19:43:08 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SGMP confusion

>> This came when I was compiling the code. There is a call in
>> sgmp/src/sgmpwatch/main.c on line 121 that goes like this:
>> 
>> nstob(argv[option_count+1],number);
>> 
>> and seems to convert an internet number in dotted decimal notation
>> to an unsigned int (network or host order address??). I just
>> commented this line out, and limited the application to only using
>> host names. Not nice, but it should work.

I removed some dead code and apparently missed a place. Changing the above
line to the following should do what you want. This change has not been
tested yet.

    *number = dotto32bit(argv[option_count + 1]);

The /etc/sgmp.variables file that is distributed with the RPI tools is not
guaranteed to be correct for anything other then the cisco specific
variables. You should check with your vendor to make sure you obtain their
correct implementation specific variables.

Greg Satz
cisco Systems

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 88 20:16:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

According to the draft Host Requirements RFC, a host must silently ignore
ICMP Echo and Timestamp Requests sent to an IP broadcast address.  A host
may (at the implementor's discretion) reply to an Echo or Timestamp Request
sent to an IP multicast address, in which case the IP source address of
the Reply is the address of the interface on which the Request arrived.
By the routing rules in the Host Requirements RFC, that interface is also
the one over which the Reply is sent.

ICMP *error* messages (destination unreachable, redirect, source quench,
time exceeded, parameter problem) must never be sent in response to any
datagram received as a link-level broadcast or as an IP broadcast or
multicast.

Steve Deering

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 08:44:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  WIN/TCP for 3B -- Broadcast
As a follow-up to the note from Don Ferencz, I should note that a 4.3-based
upgrade to the Wollongong TCP/IP for ATT's 3B series (actually for all
Streams-based TCP/IPs) is now in beta with ATT and will shortly be emerging
from their Q/A process.  As with 4.3BSD, this version gives the system 
administrator appropriate controls over the issuance of broadcast
patterns.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Sep 88 10:03:56 -0400
From:      tmallory@PARK-STREET.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        tmallory@PARK-STREET.BBN.COM
Subject:   Re: ICMP's & IP src addrs

Now that the first wave is in, I'd like to amend the following:

>Flame:  An ICMP echo to a broadcast address should get no response!  What an
>incredibly obnoxious thing to do!

My reply was motivated from my position as a user on a single relatively large
ethernet(~500 hosts).  There is no protection from this kind of barrage,
although a single host could, in theory, use almost as much of the network
bandwidth.  If a large percentage of the replying hosts have to ARP for the
sending host's hardware address, then that's a lot of ARP requests for
everyone to process.

I agree that a broadcast ping is a very simple and effective tool for network
administration.  Long before my message reached the rest of the world, I had
received an internal reply to this effect.  Aside from the usual list of
benefits(unlisted hosts, trailer configured hosts, etc.), the reply pointed
out that 'obnoxious' applied to the effects observed by users, and that a ping
at two in the morning was unlikely to bother most people(at least here at
BBN :-).

Some problems: once the network gets large enough, there is a reasonable
chance that not all of the replies will get back(so try a couple of times?).

Also, it is not always possible to guarantee a 'safe' time to use such a tool.
A user wishing to measure inter-machine performance will naturally schedule
his test to run at two in the morning, when traffic is light...  Nor is it
simple, with the advent of work-stations, to prevent almost anyone from
performing the 'what if' ping test.  Many of us remember a much more public
'what if' test of the unix 'rwall' command a few years ago.  Note also that
the ping request can be sent through ip routers, which makes a great burst
traffic generator to stress the routers, but leaves no protection for the poor
users of both the network and the router.

I am therefore arguing in favor of the spirit of the draft Host Requirements
RFC(courtesy Steve Deering):

   According to the draft Host Requirements RFC, a host must silently ignore
   ICMP Echo and Timestamp Requests sent to an IP broadcast address.  A host
   may (at the implementor's discretion) reply to an Echo or Timestamp Request
   sent to an IP multicast address, in which case the IP source address of
   the Reply is the address of the interface on which the Request arrived.
   By the routing rules in the Host Requirements RFC, that interface is also
   the one over which the Reply is sent.

Actually, I don't have a great problem with hosts responding to such a request
if they choose to, but if they do, then I believe it is important that the
source address used be that over which the packet was received, rather than
that over which it sends the reply, since that is the only way to establish
the address that the host thinks it is using on the broadcast network of the
echo request.  (I'll need to read up on the routing rules before I go along
with always replying back out the same interface.)

Tracy Mallory
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Sep 88 12:21:41 -0400
From:      Andy Malis <malis@MACARTHUR.BBN.COM>
To:        " Barry D. Hassler" <hassler@ASD.WPAFB.AF.MIL>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Class A Logical Host Addressing
Barry,

As I believe Mike St. Johns mentioned a in an earlier message,
the PSN's logical addressing capabilities are not currently in
use by the DDN due to required changes to AHIP (1822) host
software.  A possible future PSN development will be to make
logical addressing transparent for AHIP hosts as well as X.25
hosts.

To answer your second question, the criterion used by the PSNs to
choose between multiple available physical mappings for a logical
address is configurable by the network administration on a per-
logical-address basis.  Three alternative criteria are available:
ordered list, closest (via delay-based network routing), and load
leveling (successive Call Requests are distributed through the
list of currently available physical mappings in a round-robin
manner).

In the previous paragraph, "available" means the destination host
port is up and the logical-address-to-physical-port mapping has
been enabled, either explicitly by the host or automatically by
the network when the host last restarted.  Automatic enabling is
itself configurable by the network administration on a per-host-
port basis.

Regards,
Andy Malis
BBNCC PSN Development
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Sep 88 13:14:35 PDT
From:      Richard Fox <rfox@amelia.nas.nasa.gov>
To:        cire@clash.cisco.com, tmallory@park-street.bbn.com
Cc:        <hi.unm.edu!cyrus@hc.dspo.gov>, clash.cisco.Cyrus@com, clash.cisco.Tait@com, tcp-ip@sri-nic.arpa
Subject:   Re: ICMP's & IP src addrs

>> Subject: Re: ICMP's & IP src addrs 
>> Date: Thu, 15 Sep 88 09:04:17 -0400
>> From: tmallory@PARK-STREET.BBN.COM
>> 
>> Flame:  An ICMP echo to a broadcast address should get no response!  What an
>> incredibly obnoxious thing to do!
>> 
>> Opinion: If a reply is sent, then the best response is to insert the IP
>> address of the interface over which the packet was received in the source
>> address field of the reply.
>> 
>> Tracy Mallory
>> BBNCC


Something else I noticed (and I am not sure if it was mentioned) if you ping
a network address all hosts out on the network will respond. So I think
not only should we worry about pinging the broadcast address but we should 
worry about pinging any non-host address.

rich
.

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 06:42:52 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

>> Subject: Re: ICMP's & IP src addrs 
>> Date: Thu, 15 Sep 88 09:04:17 -0400
>> From: tmallory@PARK-STREET.BBN.COM
>> 
>> Flame:  An ICMP echo to a broadcast address should get no response!  What an
>> incredibly obnoxious thing to do!
>> 
>> Opinion: If a reply is sent, then the best response is to insert the IP
>> address of the interface over which the packet was received in the source
>> address field of the reply.
>> 
>> Tracy Mallory
>> BBNCC


Actually, I've found use for sending out broadcast pings.  It can be
very usefull when you are at a node in an internet that for one
reason or another seems to not hear anymore.  Say you are the net
administrator and don't have a lot of time.  Can anyone hear?  Throw
out a broadcast ping and see what you get back.  The information can
be very useful in a gross sort of way.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 10:59:00 EDT
From:      <yurcik@lcp.nrl.navy.mil>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        yurcik
Subject:   Washington DC-area ACM SIGCOMM Meeting
An opportunity to learn what the other side of the fence is up to...

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

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

           X.500, AN EMERGING OSI DISTRIBUTED DIRECTORY STANDARD
	      

DATE:                Wednesday, October 12, 1988

SPEAKER:             Daniel J. Blum, Corporation for Open Systems

TIME:                7:30 P.M.

PLACE:               Corporation for Open Systems
                     1750 Old Meadow Road
                     McLean, VA

                     Directions:  From the Beltway, take route 123 north 
                     toward D.C.  Take the first right onto Old Meadow Road.  
                     COS is in the third building on the right and is brick
                     and smoked glass.  The parking garage is in the rear,
                     and you must enter the building from the rear.  Look for 
                     directions on the door for entry to the building.  Take 
                     the elevator to the fourth floor and look for a sign to 
                     the meeting room.

ADDITIONAL
INFORMATION:         Andrew Partan, "asp@cos.com" (703) 883-2796  
		     Ella Gardner, "gardner@gmuvax.gmu.edu", (703) 790-8920

ABSTRACT:            The 1988 X.500 joint CCITT-ISO OSI Directory Standard is 
                     approaching completion, and products are beginning to 
                     appear on the market.  Daniel J. Blum will describe the 
                     technical content of X.500, its place in the OSI 
                     architecture, and how it will serve other OSI 
                     applications such as X.400.  He will also discuss the 
                     state of X.500 conformance test technology and the 
                     direction of ongoing standards work.

BIOGRAPHY:           Mr. Daniel J. Blum is currently attached to the 
                     Engineering Division at COS where he develops software 
                     for X.400 and other OSI-based software.  Mr. Blum also 
                     tracks X.500 directory issues and serves as the National 
                     Bureau of Standards Implementor's Workshop X.500 SIG 
                     Editor.  Prior to arriving at COS, he was employed at 
                     Dialcom, Inc. where he implemented a directory 
                     service.

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


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Sep 88 15:16:06 PDT
From:      cire@clash.cisco.com
To:        jam@radc-lonex.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: broadcast pings

Okay.  I agree.  Broadcast pings are generally a bad idea and we
should change implementations to ignore them.  Flooding is a bad
idea.

What I was relating earlier was based on past observations of
several production networks I've lived on (not administered).  I
observed that there were situations where an overworked net administrator
needed to establish that some portion of an internet is functional.
This is usually under extreme time pressure.  It is also on an internet
composed primarily of ethernets which grew together in a rather
random fashion.  Under these circumstances perhaps the broadcast
pings are usefull.  On well administered networks where the net
admins are intimately familar with well known hosts on each of the
network components broadcasts would clearly be inappropriate.  What
I was talking about is what I've seen to be more the norm.

Don't get me wrong.  Broadcast Pings and other related phenomena
can be really obnoxious.  I agree with that.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 12:25:28 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   broadcast pings

> tmallory@PARK-STREET.BBN.COM writes:
>
> incredibly obnoxious thing to do!
> 
> Opinion: If a reply is sent, then the best response is to insert the IP
> address of the interface over which the packet was received in the source
> address field of the reply.
> 
 
> cire@cisco.com:
>
> Actually, I've found use for sending out broadcast pings.  It can be
> very usefull when you are at a node in an internet that for one
> reason or another seems to not hear anymore.  Say you are the net
> administrator and don't have a lot of time.  Can anyone hear?  Throw
> out a broadcast ping and see what you get back.  The information can
> be very useful in a gross sort of way.

Gag!  Obnoxious is right, I agree with Tracy.  There really isn't any
need to flood areas of the network like that with potential ping responses.
An administrator should be permanantly imprinted with a copule of
hosts to ping, preferably one on and one off the local node.  That
has always been the quickest way for me to find if the node is down,
or if we just lost both the lines out of it.  Usually the node is down,
ever since BBN 'upgraded' the equipment...

The same stands for broadcast messages on an ethernet off a major internet.
Why bother to decipher the information coming back?  Just hit a host or
two in order to see if your backbone is still operational.  But on a
local ethernet, you aren't dealing with the expense of flooding the area
with packets (unless your net has several thousand computers plugged in...)

The only potential use that I really see for a broadcast ping, and only on
a small local network, is for a facility that wants to keep track of the
current state of each host.  A modified ping program could provide an
up/down display for each computer out there.

Have I missed any other major possibilites?

Joel
jam@radc-lonex.arpa, jam@etn-wlv.eaton.com

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 14:03:56 GMT
From:      tmallory@PARK-STREET.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs


Now that the first wave is in, I'd like to amend the following:

>Flame:  An ICMP echo to a broadcast address should get no response!  What an
>incredibly obnoxious thing to do!

My reply was motivated from my position as a user on a single relatively large
ethernet(~500 hosts).  There is no protection from this kind of barrage,
although a single host could, in theory, use almost as much of the network
bandwidth.  If a large percentage of the replying hosts have to ARP for the
sending host's hardware address, then that's a lot of ARP requests for
everyone to process.

I agree that a broadcast ping is a very simple and effective tool for network
administration.  Long before my message reached the rest of the world, I had
received an internal reply to this effect.  Aside from the usual list of
benefits(unlisted hosts, trailer configured hosts, etc.), the reply pointed
out that 'obnoxious' applied to the effects observed by users, and that a ping
at two in the morning was unlikely to bother most people(at least here at
BBN :-).

Some problems: once the network gets large enough, there is a reasonable
chance that not all of the replies will get back(so try a couple of times?).

Also, it is not always possible to guarantee a 'safe' time to use such a tool.
A user wishing to measure inter-machine performance will naturally schedule
his test to run at two in the morning, when traffic is light...  Nor is it
simple, with the advent of work-stations, to prevent almost anyone from
performing the 'what if' ping test.  Many of us remember a much more public
'what if' test of the unix 'rwall' command a few years ago.  Note also that
the ping request can be sent through ip routers, which makes a great burst
traffic generator to stress the routers, but leaves no protection for the poor
users of both the network and the router.

I am therefore arguing in favor of the spirit of the draft Host Requirements
RFC(courtesy Steve Deering):

   According to the draft Host Requirements RFC, a host must silently ignore
   ICMP Echo and Timestamp Requests sent to an IP broadcast address.  A host
   may (at the implementor's discretion) reply to an Echo or Timestamp Request
   sent to an IP multicast address, in which case the IP source address of
   the Reply is the address of the interface on which the Request arrived.
   By the routing rules in the Host Requirements RFC, that interface is also
   the one over which the Reply is sent.

Actually, I don't have a great problem with hosts responding to such a request
if they choose to, but if they do, then I believe it is important that the
source address used be that over which the packet was received, rather than
that over which it sends the reply, since that is the only way to establish
the address that the host thinks it is using on the broadcast network of the
echo request.  (I'll need to read up on the routing rules before I go along
with always replying back out the same interface.)

Tracy Mallory

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 14:28:45 GMT
From:      cvincent@USACEC.ARPA (Vincent)
To:        comp.protocols.tcp-ip
Subject:   Interfacing SUN to AUTODIN.

Bill,
The Software Development Center Huachuca is working on such a project 
using Unisys 5000/80.  This requires some special hardware such as
a TLC 100 but other than that it is just protocol and format conversion.
Doug Nielsen is a real good P.O.C. dnielsen@huachuca-em.arpa.

Hope this helps.

Curt Vincent

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 14:59:00 GMT
From:      yurcik@LCP.NRL.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Washington DC-area ACM SIGCOMM Meeting

An opportunity to learn what the other side of the fence is up to...

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

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

           X.500, AN EMERGING OSI DISTRIBUTED DIRECTORY STANDARD
	      

DATE:                Wednesday, October 12, 1988

SPEAKER:             Daniel J. Blum, Corporation for Open Systems

TIME:                7:30 P.M.

PLACE:               Corporation for Open Systems
                     1750 Old Meadow Road
                     McLean, VA

                     Directions:  From the Beltway, take route 123 north 
                     toward D.C.  Take the first right onto Old Meadow Road.  
                     COS is in the third building on the right and is brick
                     and smoked glass.  The parking garage is in the rear,
                     and you must enter the building from the rear.  Look for 
                     directions on the door for entry to the building.  Take 
                     the elevator to the fourth floor and look for a sign to 
                     the meeting room.

ADDITIONAL
INFORMATION:         Andrew Partan, "asp@cos.com" (703) 883-2796  
		     Ella Gardner, "gardner@gmuvax.gmu.edu", (703) 790-8920

ABSTRACT:            The 1988 X.500 joint CCITT-ISO OSI Directory Standard is 
                     approaching completion, and products are beginning to 
                     appear on the market.  Daniel J. Blum will describe the 
                     technical content of X.500, its place in the OSI 
                     architecture, and how it will serve other OSI 
                     applications such as X.400.  He will also discuss the 
                     state of X.500 conformance test technology and the 
                     direction of ongoing standards work.

BIOGRAPHY:           Mr. Daniel J. Blum is currently attached to the 
                     Engineering Division at COS where he develops software 
                     for X.400 and other OSI-based software.  Mr. Blum also 
                     tracks X.500 directory issues and serves as the National 
                     Bureau of Standards Implementor's Workshop X.500 SIG 
                     Editor.  Prior to arriving at COS, he was employed at 
                     Dialcom, Inc. where he implemented a directory 
                     service.

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

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 15:16:28 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

It's also entertaining to try, say, telnetting to a local broadcast address.

Does the Host Requirements RFC give any prescription about hosts replying
to ordinary protocol traffic send to a broadcast address or to a link-level
broadcast?  Clearly, UDP broadcasts should be accepted, but what about TCP?

	Stuart Levy, Minnesota Supercomputer Center, slevy@uc.msc.umn.edu

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 15:19:25 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

Do DEC Lanbridges try to look into the packet at IP addresses?  Those x.y.z.255
replies should be coming from all different Ethernet addresses so I wouldn't
expect a MAC bridge to consider them special.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 15:44:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  WIN/TCP for 3B -- Broadcast

As a follow-up to the note from Don Ferencz, I should note that a 4.3-based
upgrade to the Wollongong TCP/IP for ATT's 3B series (actually for all
Streams-based TCP/IPs) is now in beta with ATT and will shortly be emerging
from their Q/A process.  As with 4.3BSD, this version gives the system 
administrator appropriate controls over the issuance of broadcast
patterns.

Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 15:59:00 GMT
From:      yurcik@LCP.NRL.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Washington DC-area ACM SIGCOMM Meeting

An opportunity to learn what the other side of the fence is up to...

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

                       WASHINGTON DC SIGCOMM

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

                            PRESENTS

           X.500, AN EMERGING OSI DISTRIBUTED DIRECTORY STANDARD


DATE:                Wednesday, October 12, 1988

SPEAKER:             Daniel J. Blum, Corporation for Open Systems

TIME:                7:30 P.M.

PLACE:               Corporation for Open Systems
                     1750 Old Meadow Road
                     McLean, VA

                     Directions:  From the Beltway, take route 123 north
                     toward D.C.  Take the first right onto Old Meadow Road.
                     COS is in the third building on the right and is brick
                     and smoked glass.  The parking garage is in the rear,
                     and you must enter the building from the rear.  Look for
                     directions on the door for entry to the building.  Take
                     the elevator to the fourth floor and look for a sign to
                     the meeting room.

ADDITIONAL
INFORMATION:         Andrew Partan, "asp@cos.com" (703) 883-2796
                     Ella Gardner, "gardner@gmuvax.gmu.edu", (703) 790-8920

ABSTRACT:            The 1988 X.500 joint CCITT-ISO OSI Directory Standard is
                     approaching completion, and products are beginning to
                     appear on the market.  Daniel J. Blum will describe the
                     technical content of X.500, its place in the OSI
                     architecture, and how it will serve other OSI
                     applications such as X.400.  He will also discuss the
                     state of X.500 conformance test technology and the
                     direction of ongoing standards work.

BIOGRAPHY:           Mr. Daniel J. Blum is currently attached to the
                     Engineering Division at COS where he develops software
                     for X.400 and other OSI-based software.  Mr. Blum also
                     tracks X.500 directory issues and serves as the National
                     Bureau of Standards Implementor's Workshop X.500 SIG
                     Editor.  Prior to arriving at COS, he was employed at
                     Dialcom, Inc. where he implemented a directory
                     service.

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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 16:21:41 GMT
From:      malis@MACARTHUR.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Class A Logical Host Addressing

Barry,

As I believe Mike St. Johns mentioned a in an earlier message,
the PSN's logical addressing capabilities are not currently in
use by the DDN due to required changes to AHIP (1822) host
software.  A possible future PSN development will be to make
logical addressing transparent for AHIP hosts as well as X.25
hosts.

To answer your second question, the criterion used by the PSNs to
choose between multiple available physical mappings for a logical
address is configurable by the network administration on a per-
logical-address basis.  Three alternative criteria are available:
ordered list, closest (via delay-based network routing), and load
leveling (successive Call Requests are distributed through the
list of currently available physical mappings in a round-robin
manner).

In the previous paragraph, "available" means the destination host
port is up and the logical-address-to-physical-port mapping has
been enabled, either explicitly by the host or automatically by
the network when the host last restarted.  Automatic enabling is
itself configurable by the network administration on a per-host-
port basis.

Regards,
Andy Malis
BBNCC PSN Development

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 17:44:52 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: BFTP Sources


> Slight correction to the file name fot rhe BFTP sources at
> VENERA.ISI.EDU.  After trying to get them with a script, i discovered
> that the name is not BFTP.1.tar.Z, but BFTP.2.tar.Z.
>                                             ^
>                                        -jim mccoy
	
Jim,

As bug fixes or improvements are added to BFTP, I will be advancing
the version number on the BFTP tar file.  (In this case, the path name
on a reference to an include-file was corrected.)  If there is a major 
advance, I'll make an announcement on the tcp-ip list, otherwise you 
should be able to tell whether you've got the latest version by checking
the number.  Sorry about the confusion.

--Annette

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 18:22:41 GMT
From:      rfox@AMELIA.NAS.NASA.GOV (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

We've certainly been bitten by hosts that respond to broadcasts
<inappropriately, so I'm sympathetic with the idea of being very
<conservative in responding to ICMP broadcasts.  But let's not go too
<far.  Kent England says you are never allowed to respond to a
<broadcast by sending an ICMP, even if the source of the broadcast is
<an ICMP.  I think what should be said is that you never respond to a
<broadcast by sending an ICMP *error* message.  If the original
<broadcast is one of the ICMP queries, and the query is well-formed,
<you can certainly send the corresponding response.
<up with some other way to find out your net mask...


By allowing hosts to respond to well formed icmp echo request packets
to the broadcast address you are opening the door to malicious attempts
to swamp a network with data. How so?  Ping the broadcast address with
an icmp packet size of 1K or greater. If your ethernet contains quite
a few hosts (100 maybe???) and they all respond to each packet once
every second thats quite al ot of icmp data being generated every second.
Start 2 pings going and watch out. Or if your ping option has the ability
to generate a ping every 10th of a second your ethernet may find itself
heavily congested if not completely unuasable if hosts respond to
icmp echo requests to the broadcast address. 

I can see some usefulness in allowing some hosts respond but I really
think this is an area where care must be taken in teh hosts requirements doc.


rich

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 18:59:57 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Will the real ... please stand up?

If anyone can identify those manufacturer IDs, we'd like to hear about
them too (they aren't in LANWatch's parser either...).

James VanBokkelen
FTP Software Inc.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 19:44:41 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <Sep.16.21.23.10.1988.10664@athos.rutgers.edu> 
hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>
>I think what should be said is that you never respond to a
>broadcast by sending an ICMP *error* message.  
>[...]
>If the host requirements RFC says what
>you said, I think Bob Braden should think again.  Either that or come
>up with some other way to find out your net mask...

	No, no [again :-].  I'm wrong, you are right.  You state the
restriction correctly above.  I am guilty of fuzzy thinking on that one.

	Whatever one might think about broadcast pings, they are not
against the rules today.  They may just be rather dangerous or
impolite.  Sorry to everyone for the error and any resulting confusion.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 20:29:57 GMT
From:      NETOPRMS@NCSUVM.BITNET (Michael Steele)
To:        comp.protocols.tcp-ip
Subject:   Installing TCP-IP on a CTIX unix system


     I am completely new to this newsgroup and know NOTHING about TCP-IP other
 than it is a protocol used to communicate between different UNIX systems
 typically over Ethernet.  The group I'mm in just aquired a CTIX mini-mainframe
 running UNIX with WEST-coast TCP-IP software.  We are located in Raleigh, NC
 and need the East Coast version.  Supposedly the company or someone is getting
 this for us....but that was a month ago.  Do public domain versions exist of
 this software for our Convergent Technologies system...or where could I
 purchase such a package?

 Also a clarification of WHAT TCP-IP is would be nice.

                           Thanks in advance  Mike
------------------------------------------------------------------------
NETOPRMS@NCSUVM.BITNET  Michael Steele  co-sysop of NCSU Apple Users BBS
10 meg Apple downloads(latest PD software), Tech/Pascal/PCP discussion
919-783-9010 (PC Pursuitable NCRTP)  Call today!  919-783-9010

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 21:57:55 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP's & IP src addrs

Stuart,

Your entertainment is actually an interesting experiment, as I discovered
when I homed a bunch of rascallion fuzzballs on the broadcast address. I
gave the analysis problem to my class on networking as an exercise. Does
the game result in (a) any synchronized connection, (b) more than one
synchronized connection and (c) if so, does any connection last for
a significant time? Think about it.

Dave

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 88 22:16:06 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast pings


Okay.  I agree.  Broadcast pings are generally a bad idea and we
should change implementations to ignore them.  Flooding is a bad
idea.

What I was relating earlier was based on past observations of
several production networks I've lived on (not administered).  I
observed that there were situations where an overworked net administrator
needed to establish that some portion of an internet is functional.
This is usually under extreme time pressure.  It is also on an internet
composed primarily of ethernets which grew together in a rather
random fashion.  Under these circumstances perhaps the broadcast
pings are usefull.  On well administered networks where the net
admins are intimately familar with well known hosts on each of the
network components broadcasts would clearly be inappropriate.  What
I was talking about is what I've seen to be more the norm.

Don't get me wrong.  Broadcast Pings and other related phenomena
can be really obnoxious.  I agree with that.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 00:23:08 GMT
From:      cyrus@hi.unm.edu (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <22185@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes:
>In article <24915@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
>> 	No, no, no.  ICMP messages are special, because they are error
>> messages.  They must be treated carefully and conservatively.
>
>That means my favorite diagnostic tool and stress test will go away:
>`ping -f <broadcast>', where 'ping' takes '-f' as 'flood the target at
>100 packets/sec.'  (100 p/s * >100 hosts = ?)  Believe it or not, this
>can be quite useful for constructive purposes.  Tho it will break my
>heart, this tool should go to the same retirement home as the old
>Atoms-for-Piece plan for digging a new Panama canal.
>
>The usefulness of the relatively innocuous 'ping <broadcast>' to see
>what's there can be duplicated with a small program which sends to all
>possible host addresses (paying attention to netmask).  Modern machines
>can generate at least a couple hundred packets/sec from user code.  (At
>least our's and our competator's are much better than that. :-)  Thus
>in any situation where you don't expect too many responses for the test
>to social acceptible, it would take the new program only seconds to do
>the same thing.

I agree, though there are some problems.  I have a class B address
with a netmask giving me 2k possible addresses.  Assuming 100 p/s,
that is about 20 seconds.  Although this is not a very long period of
time, you would never see this speed because for each IP address,
your machine has to arp the IP address.  Since most IP addresses are
not used, at least on our net at the current time, a lot of time
would be spent waiting for the arp replies.  Besides, I would
probably blow out my machines arp table with 2k entries.

As far as what the correct response to such a "request" should be,
we will have to wait for the new hosts requirements RFC (any ideas
where I can get a copy of the draft???).

>Vernon Schryver -- Silicon Graphics

---
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of ECE - Parallel Processing Research Group
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |       |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@pprg.unm.edu
 | /        | /
 @/_________@/

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Sep 88 08:41:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   IETF Hosts work

>        I refer you to the upcoming Host Req'ts RFC and/or Bob Braden,
>	Craig Partridge, et al for further details.

A point of order here.  Bob Braden of ISI is the editor of the Host
Requirements RFC and should be considered the official contact.  I'm
just one of the members of the working group.

Craig
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Sep 88 09:05:29 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        jed@mitre-bedford.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Batch Processing -- via SMTP....

>    What are the possibilities for expanding SMTP to provide a mechanism to 
> allow batch processing to occur over the network(s)? 

Lots of people already do batch processing with SMTP, and there's actually
a fair amount of literature on it:

    - the MOSIS chip fabrication system (described in an ISI report that
    I'm told is now out of print)

    - the CSNET nameserver has a e-mail component for retrieving entries
    (see Solomon and Landweber's paper in Computer Networks 1982).

    - the netlib system (see Dongarra and Grosse's CACM article in May 1987)
    Note that they claim that the netlib system is the first of its kind --
    which isn't true.  So far as I can tell, MOSIS was the first.

    - the CSNET Info Server (see the paper in Computer Communication Review,
	October 1987)

Based on my experience writing the CSNET Info Server, the problem of doing
batch processing isn't in SMTP itself, but with addressing.  The old saw
of "be liberal in what you accept and conservative in what you send" really
bites automatic mail programs.  Two problems in particular come to mind:

    - Busted return addresses.  Your local mailer accepts messages
    for the batch program which has a bad return address (this is a *good*
    thing to do in general -- if the addressee is a person, better that
    he/she get the message than it be returned to the sender, or, given
    the return address is bad, dropped on the floor).  Unfortunately,
    the batch program, which wants to return information to the sender
    has a request it can't reply to!  (If you allow users to indicate
    third-party addresses in the batch request, this problem gets worse.
    Then, even if we fixed the problem of bad return addresses in
    mailers, users could still specify bad addresses)

    - Mail loops.  Originally, the Info Server put the CSNET postmaster's
    address as the source address in the SMTP envelope, and the Info
    Server's program address in the From: field.  The idea was that
    errors would be returned to the envelope sender (our postmaster)
    but that users that replied to Info Server messages (perhaps with
    a request for more information) would indeed get the Info Server.

    Unfortunately, there are mail systems out there that still reply
    to the From field instead of the envelope sender.  As a result,
    we had some spectacular mail loops between remote mailers, who
    were sending error messages back to the Info Server, and Info Server
    which was happily treating the error messages as requests and
    sending them back to the remote mailer (which promptly sent them
    back to the Info Server).  In fact, in at least one case I
    think we hit a sorceror's apprentice problem with a mailer in
    BITNET -- it sent two error messages, so we'd send two replies,
    so it would send four messages.... (I think we were well over
    twenty messages per volley by the time we caught this).

We might be able to fix the error handling problem through education.
I think we will always have to worry about busted return addresses --
it is too easy to misconfigure a mailer in this world.

Craig
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 03:10:22 GMT
From:      dougm@violet.ICO.ISC.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re: Questions on IP & 802.2,3 & use or value of streams.

In reply to your message of Fri, 16 Sep 88 15:56:19 EDT
-------

> 1) Anyone using IP over 802.2 LLC or 802.3 MAC layers in commerical or
> academic products? (Commercial folks are interested in having their
> products conform to "standards").

I don't know if it is in very wide use, but there are a number of vendors
that support it as an option.

> 2) What is ATT's streams used for: like Berkeley's sockets, to provide
> access to protocol families? Is there a "native" streams protocol or
> protocol suite? And more concrete: just like TCP/IP is being or will be
> delivered with streams, are there other protocol suits available
> (commerically or otherwise) with a streams interface?, say ISO's?

AT&T STREAMS is a framework in which to implement communications protocols.
There is no native Streams protocol.  That is, with a generic base system
you get no communications protocols, just the tools to implement them.  TLI
is the AT&T equivalent to sockets in the V.3 environment.  There has been
much discussion about TLI vs. sockets in this group in the past so I won't
get into that.

There are a number of protocol suites available.  A number of vendors have
TCP/IP implementations.  There are also ISO and XNS implementations that I
know of plus some others proprietary to various vendors.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Sep 88 17:07 EST
From:      "Mark D. Eggers (219) 239-7258"      <CF4A8X%IRISHMVS.BITNET@CORNELLC.CCS.CORNELL.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Network configuration document
I would also like a copy. I only received the third part of
it (subsequently eaten by a power outage/disk crash) via
BITNET.  Sending it to my internet address would probably
work much better.

It is:

eggers@dirac.cc.nd.edu

Thanks - /mde/
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 12:09:08 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: Installing TCP-IP on a CTIX unix system

> typically over Ethernet.  The group I'mm in just aquired a CTIX mini-mainframe
> running UNIX with WEST-coast TCP-IP software.  We are located in Raleigh, NC
> and need the East Coast version.  Supposedly the company or someone is getting
> this for us....but that was a month ago.  Do public domain versions exist of
> this software for our Convergent Technologies system...or where could I
> purchase such a package?


	[]

	Watch out for that WEST-coast TCP; it goes into TIME-WARP state
	east of the Mississippi! -):

					
					Larry Bacman

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 12:41:10 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   IETF Hosts work


>        I refer you to the upcoming Host Req'ts RFC and/or Bob Braden,
>	Craig Partridge, et al for further details.

A point of order here.  Bob Braden of ISI is the editor of the Host
Requirements RFC and should be considered the official contact.  I'm
just one of the members of the working group.

Craig

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 13:05:29 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Batch Processing -- via SMTP....


>    What are the possibilities for expanding SMTP to provide a mechanism to 
> allow batch processing to occur over the network(s)? 

Lots of people already do batch processing with SMTP, and there's actually
a fair amount of literature on it:

    - the MOSIS chip fabrication system (described in an ISI report that
    I'm told is now out of print)

    - the CSNET nameserver has a e-mail component for retrieving entries
    (see Solomon and Landweber's paper in Computer Networks 1982).

    - the netlib system (see Dongarra and Grosse's CACM article in May 1987)
    Note that they claim that the netlib system is the first of its kind --
    which isn't true.  So far as I can tell, MOSIS was the first.

    - the CSNET Info Server (see the paper in Computer Communication Review,
	October 1987)

Based on my experience writing the CSNET Info Server, the problem of doing
batch processing isn't in SMTP itself, but with addressing.  The old saw
of "be liberal in what you accept and conservative in what you send" really
bites automatic mail programs.  Two problems in particular come to mind:

    - Busted return addresses.  Your local mailer accepts messages
    for the batch program which has a bad return address (this is a *good*
    thing to do in general -- if the addressee is a person, better that
    he/she get the message than it be returned to the sender, or, given
    the return address is bad, dropped on the floor).  Unfortunately,
    the batch program, which wants to return information to the sender
    has a request it can't reply to!  (If you allow users to indicate
    third-party addresses in the batch request, this problem gets worse.
    Then, even if we fixed the problem of bad return addresses in
    mailers, users could still specify bad addresses)

    - Mail loops.  Originally, the Info Server put the CSNET postmaster's
    address as the source address in the SMTP envelope, and the Info
    Server's program address in the From: field.  The idea was that
    errors would be returned to the envelope sender (our postmaster)
    but that users that replied to Info Server messages (perhaps with
    a request for more information) would indeed get the Info Server.

    Unfortunately, there are mail systems out there that still reply
    to the From field instead of the envelope sender.  As a result,
    we had some spectacular mail loops between remote mailers, who
    were sending error messages back to the Info Server, and Info Server
    which was happily treating the error messages as requests and
    sending them back to the remote mailer (which promptly sent them
    back to the Info Server).  In fact, in at least one case I
    think we hit a sorceror's apprentice problem with a mailer in
    BITNET -- it sent two error messages, so we'd send two replies,
    so it would send four messages.... (I think we were well over
    twenty messages per volley by the time we caught this).

We might be able to fix the error handling problem through education.
I think we will always have to worry about busted return addresses --
it is too easy to misconfigure a mailer in this world.

Craig

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 17:28:38 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   ICMP's & IP src addrs


   Date: Tue, 20 Sep 88 09:46:36 PDT
   From: nowicki@Sun.COM (Bill Nowicki)

	   Responding with 128.146.8.255:
	   Sun-3/180 (SunOS 3.5.1 [UNIX]).

   Have you tried a more recent release?  The 4.2BSD networking code
   had thousands of bugs, only some of which were fixed by 3.5.1.
   SunOS 4.0.1 is the latest release.

Yup, looks like it's OK in 4.0.  I just tried it on a subnet with 13
3.5.1 3/50s, a 4.0 4/110 and a 4.0 4/something else.  Pinging the
subnet broadcast got me 13 replies at a time.  Although I didn't
actually stare at a lanalyzer in order to see exactly which hosts were
sending what, it's obvious by implication that the 3.5.1 boxes are
guilty and the 4.0 boxes are sane.

--Karl

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 17:35:25 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

Chuck Hedrick writes:

                                    If the host requirements RFC says what
	you said, I think Bob Braden should think again.  Either that or come
	up with some other way to find out your net mask...
	
It doesn't. The current draft is (always) available for anonymous FTP from host
venera.isi.edu with pathname  ietf-hosts.rfc.txt.  

Bob Braden

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 21:52:33 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   What about HP/UX ARP cache and rtnet structure?

From: robert@spam.istc.sri.com ()
Newsgroups: comp.sys.hp
Subject: ARP cache on HP9000/300 & rtnet structure ????
Expires: 
References: 
Sender: 
Reply-To: robert@spam.istc.sri.com ()
Followup-To: 
Distribution: 
Organization: SRI International
Keywords: 

I am engaged in porting some neworking software to an HP9000/300.
The software was written for 4.2/4.3 BSD compatibility, so it will
not port directly to HP/UX 6.01.  Currently I am trying to solve some
of the problems encountered in the port, and as a result I have two
questions for people "in the know":

    (1) I've heard rumor that HP/UX 6.01 has removed the ARP cache
	from the kernel (ie. it is gone from the operating system).
	Is this true?  If so, why was it done?  If so, how often is
	ARPing done, and how/where is the result stored?  If so, will
	the ARP cache ever be put back?

    (2) Since HP/UX 6.01 has removed the rtnet and rthost structures
	from the publically available header files where BSD keeps
	them, and has put them into route.c, I'm wondering if the
	network and host routing tables are exactly the same as under
	4.2 or 4.3 BSD.  If not could someone post what the structure
	is like?

Thanks much.

--------------------------------------------------------------------------
  Robert Allen,
		robert@spam.istc.sri.com,
					    415-859-2143 (work phone, days)
--------------------------------------------------------------------------

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 88 22:07:00 GMT
From:      CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers  239-7258", 219)
To:        comp.protocols.tcp-ip
Subject:   Network configuration document

I would also like a copy. I only received the third part of
it (subsequently eaten by a power outage/disk crash) via
BITNET.  Sending it to my internet address would probably
work much better.

It is:

eggers@dirac.cc.nd.edu

Thanks - /mde/

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Sep 88 08:24:38 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Proteon p4200 Packet Drop Rates
Does anyone have any numbers on packet dropping by Proteon p4200 IP Routers?
Please include a description (brief!) of your environment.

I have set up a test suite of two p4200's, two IBM PS/2 model 60's, and 3
Ethernets:


    PS/2          p4200         p4200          PS/2
      |           |   |         |   |            |
      V           V   V         V   V            V
    ---------------   -----------   ---------------
       Ether              Ether         Ether

Running the MIT/CMU PC/IP Ping between the two PS/2's continuously
I see packet losses (i.e. response timeouts) on the order of 1 in
every 2500 ping requests (or 1 every 5000 packets - 1 packet for the
request, one for the response). There is no other traffic, etc on
the nets at the time of the tests. Is this number high? low? ???

I will be glad to summarize to the net, as well as provide more
quantitative information as I continue the studies.

Thanks
Frank Kastenholz
Atex/Eastman Kodak
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 05:52:49 GMT
From:      dagg@lace.lbl.gov (Darren Griffiths)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

In article <8809151736.AA01161@fji.isi.edu> prue@VENERA.ISI.EDU writes:
>>>  1)  If the second path was 25% of the speed of the first path then 25% of
>>>      the packets could be sent that way.  [...]
>>>      if the two end sides were running the Van Jacobsen/Mike Karels code
>>>      I believe this wouldn't be to much of a problem.  [...]
>>
>>
>>The first thing (splitting load among routes) would screw up the
>>Jacobson/Karels improved TCP completely.  They get a big win by
>>estimating the variance of the round trip time; using alternating
>>routes for different packets would drive this variance way up, causing
>>the timeout to be set high, causing long stoppages on lost packets.
>
>I disagree.  The first path is four times as fast but has four times as 
>many packets.  The link delay is only 1/4 the second line but the queuing 
>delay is four times as great.  The variation of the delivery times for the 
>five packets would be less than using a single line.  As the queue sizes go 
>up the variation in the network delay goes up.
>
>I do however agree with your other point, type of service routing could 
>put the second path to very good use.

The first time I thought out loud about routing through two different paths
I did mention that it may mess up the van/mike tcp code.  Fortunately this 
was at the SIGcomm conference in Stanford and Van wasn't far away.  He 
quickly set me straight and with a little extra thought it is fairly obvious
that the code would stabalize around the acks of the faster line.

A couple of people have mentioned that instead of looking for well known ports
to decide whether to use a fast line or not that the TOS field should be used.
I agree, this would be much better, but I decided to watch a couple of packets
go by on the local LBL net.  I didn't look to long, but I found very few
things actually touch that field.

Another possible thing to do would be to try and figure out which link is the
fastest, if it has one line that is 25% the speed of a second line then the 
router could simply send 25% of the packets down the slow connection and the
rest along the fast connection (perhaps using a random number to see which line
the packet is going to go along.)  I seem to remember that someone wrote a 
paper on this but I can't remember who of the top of my head.

It would be interesting to try different routing algorithms and see which is
the more efficient, with efficient be defined by the perceived throughput to
the user as well as the number of packets going through.  I can think of a
few methods that could be tried:

   1 -  Leave things the way they are, and just taking the fastest path.

   2 -  Choose the path depending on the TOS field, and hope someone uses it.

   3 -  Choose the path based on the port (TELNETs go the fast way, SMTP goes 
        the slow way.)

   4 -  Send a percentage of the packets down one path and the rest down 
        another. 


Can anyone think of any others?  Perhaps when I have some free time I'll do a
couple of tests and see what I come up with.


  Cheers,
     --darren


-------------------------------------------------------------------------------
Darren Griffiths                                          DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division                

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 1988 11:17-EDT
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        Urbaniak@G.BBN.COM
Subject:   ICMP Broadcast
broadcast ICMP echo request is certainly guaranteed to provoke a
massive collision (if many IP implementations respond), but this
is not synonymous with being obnoxious or being a VERY BAD idea.
I think I would call it an unusual, potentially dangerous action.
If viewed as another LAN management tool, it can be useful, as
mentioned, to locate quickly all active IP stations on a
broadcast LAN.  I see this as a useful, off-hours verification
against address assignment databases.  Certainly I would wish to
request users not to issue such broadcasts, but I'm not sure that
users stations should be mandated not to respond to a broadcast
request.  (Being one of many tools, you might conclude that the
safest network behaviour is to constrain the IP behaviour.  But
maybe this is just a user behaviour prophylactic, not a protocol
design goal.  don't you really want an implementation switch:
do/don't respond to IP broadcast ICMP Echo, for individual sites
to set?)

Also, massive LAN collisions are not necessarily to be avoided,
they are to be managed, which might mean avoidance during prime
time to some sites.  Generating a test massive collision with IP
broadcast might tell you how different implementations behave,
which are more/less robust, what the settling time for this
incident is for a given LAN, how your network components are
responding.  My view is that many production LANs permit some wee
hour testing or preventive maintenance and learning on the real
live network.

I'm not sure how much of real LAN management might not be
considered to be "unusual" and "potentially dangerous" from the
perspective of a user who was yet to benefit immediately and
directly.

Walter doc Urbaniak.  Urbaniak@BBN.COM (800 station Ethernet)
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 1988 12:21:06 EDT
From:      Martin Gross <martin@EDN-UNIX.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   ACC 5250 under Ultrix 1.1
  
   Has anyone sucessfully installed an ACC 5250 under Ultrix 1.1 on a
MicroVax II? I'm currently trying and am having no luck configuring
the interface using the acpconfig utility. The program kicks me out
saying that the socket operations are not supported. Any help would 
be greatly appreciated.

                             Thanks,

                                      Martin Gross


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 17:12:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Graziano's Streams Query
Periodically, a query hits this list about Unix Stream and about the
vendors offering TCP implementations for it.  The latest, from
Marco Graziano of Olivetti, asked a broad range of pointed questions and
so, it seems to me, forms a good base for a response that might be of
general interest.

Virtual Device Drivers

Streams uses modules and message-passing, in the kernel, to implement
protocol layers.  (Unless streams is implemented in user space, there is
no such thing as a "streams program" such as FTP or Telnet.  Streams refers
only to the kernel-level protocol core, usually limited to data link, 
network and transport levels, although some higher-level protocols are done
inside streams.)

Communication between modules is STRICTLY message-based.  The only other
access to information, by a module, is to call kernel subroutines.  Modules
may either be single queue in and out (called a "module") or multiple
queues in or out (called "driver").

1.  Advantages:  Streams imposes a discipline which forces highly modular
protocol coding.  That can, of course, create terrible performance, but does
not need to.  The other side of this discipline is that it can allow the
construction of functions which can be mixed and matched.  It also means that
the task of creating protocols (i.e., in separate modules) can be partitioned
among different people easily.  

One of the emerging major benefits of Streams is its utility in a
multi-processor environment.  Properly implemented, streams modules may
operate in DIFFERENT address spaces.  The only shared memory that is needed
is for message-passing and data-buffers.

One of the subtle benefits is portability.  Highly integrated code has a
tendency to bury many of its operating-system-dependent assumptions.  Streams
makes the assumptions clearly defined.  To port streams code, you need only
to create a Streams environment.  (This may turn out to be roughly the same
effort as porting/hacking another implementation, but the process is far
more predicatable and you are left with all of the protocol code being shared
between the original and new implementation.

2.  Are modules truly independent?  Yes!  Except, of course, that they must
agree to the format and rules of messages that are passed.  That is, there
must be a well-defined semantic interface between modules.

3.  Out-of-band access to modules:  Modules are accessible as "devices".
For example, we supply /dev/arp.  You can open it and then do IOCTLs with it.

4.  Support of alternate transports:  You betcha!  TCP and UDP are supported
as co-equals.  Further, we have an OSI TP4. 

5.  NFS integration:  NFS is an example of code above transport level which
resides in the kernel and is part of the Streams environment.  It accesses
UDP via the standard Transport Provider Interface (TPI).  

Access from user programs is via the Transport Library Interfaces.  It gets you
across the user/kernel interface and is competitive with Berkeley sockets
in terms of its role in life.  TLI is user level.  TPI is kernel level.  In
effect, it does for kernel processes what TLI does for user processes.

(By the way, there is at least one NFS that does not use TPI, but I do not
know any other details of its implementation.)


System V implementations able to use BSD kernel functions?  Well, mostly
there is a pretty-good mapping of SVR3/Streams calls to the kernel onto
BSD kernel functions.

1.  Device drivers are, in fact, kept alive by a daemon, typically.  In the
TCP case, the daemon sets up the multiplexed set of stream modules and holds
the file descriptor.

2.  Global data structures:  Basically, these are a no-no.  The only
shared data that is allowed, other than what you would access through standard
kernel functions, is via message-passing.  Keeping stray shared data structures
around leads to tough questions about how the structure will be shared in
a multi-processor environment.  The safest way is to have a query-response
discipline between the module that owns the structure and any that need to
"read" it.

We have recently been embarrassed to find a couple of placess that we commit
this sin-of-sharing.  In both cases, the solutions are conceptually simple,
involve small programming effort, and will not have any performance impact.

3.  Message buffer passing:  This is done via pointer (message block) passing.
Actual data are not passed.  e.g., TCP has a header message block and points
to user data.  IP adds its header message block and points to the TCP mb.
ARP sets up the ethernet header mb and points to the IP mb.  ARP or the
device driver, when they are done with this chain -- Note that this is
a scatter/gather model, which can be quite nice, for some devices -- they
free it.  However, TCP holds on to the data block until it gets an ACK back
for the relevant sequence number.

4.  Kernel modifications required:  Should not be any!  You can hide quite
a bit of convenient non-discipline by adding things to the kernel, but it
is not in the spirit of Streams.  Sockets, in particular, can be emulated on
top of TLI (i.e., within each user's application) with a fair degree of
faithfulness and no meaningful performance impact.  The one exception to this
rosy picture is select(), which currently does not map to poll().  This
required a select() driver.  (In Streams, rather than part of the generic
operating system kernel.)

5.  Performance measurement:  Probably the best answer is to ask for the
next question.  There really are not any serious performance measurement or
instrumentation tools.  You can get information about buffer exhaustion and
can use the strace logging facility to record useful information, but that
seems to be about it.


Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 10:54:12 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

In article <985@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes:
> Another possible thing to do would be to try and figure out which link is
> the fastest, if it has one line that is 25% the speed of a second line
> then the router could simply send 25% of the packets down the slow
> connection and the rest along the fast connection (perhaps using a random
> number to see which line the packet is going to go along.)  I seem to
> remember that someone wrote a paper on this but I can't remember who of
> the top of my head.

  Be careful.  You're making assumptions about the topology of the
redundant paths to your destination.  What happens if the redundant paths
merge at some gateway down the line that is a constriction?

  As an example, at Lawrence Livermore National Laboratory there's a
9600bps line from lll-crg.llnl.gov [128.115.1.1], [26.3.0.21] to the LLNL
PSN [26.X.0.21] and a 56Kbps line from labnet-gw.llnl.gov [128.115.3.1],
[26.6.0.21] to the PSN.  Labnet-gw is on the LLNL Open LabNet and is
accessible at essentially ethernet speeds.  The 9600bps line is a relic
from the bad old days when lll-crg was the LabNet gateway; it's scheduled
for DQing [finally] in a little bit.

  Maybe your argument is correct and the flow would sync around the
throughput available through the ``higher speed'' channel, but I'm not
convinced that the two flows bottling up at the PSN wouldn't develop the
equivalent of turbulence.  I'd have to see the numbers.  Maybe Van could
say something about this.

  At the very least, since the bottleneck is really the PSN which is
attached to other PSNs with 56Kbps trunks, labnet-gw is fully capable of
driving the PSN at maximum.  Any additional flow coming from the 9600bps
is just going to increase the queue lengths unless the PSN does the same
kind of load balancing with any available redundant PSN-PSN paths.

Casey

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 11:18:24 GMT
From:      XBR4DB26@DDATHD21.BITNET (OLAF THUN)
To:        comp.protocols.tcp-ip
Subject:   Problems with FTP-Command "msend"

We have a problem during filetransfer from VAX to Apollo using the
FTP-Command "msend".

Our hard- and softwareconfiguration:

        VAX 8530 (VMS 4.6, CMU_TCP 6.2)
        MICROVAX (CMU_TCP 6.2)
        Apollo DN3000 (Aegis 9.7, TCP/IP 3.1)

Everytime we start a filetransfer from the VAX 8530 or the MicroVAX to the
Apollo with the command "msend /struc=file /type=ascii /noprompt *.*" (about
80 files, each file 1-100 blocks, only ASCII-character) FTP is aborted after
20-30 files with the following error:

        -IPACP-E-CSE- Connection table space exhausted

The filetransfer in the other direction (Apollo->VAX) works without errors.

If there are only a few (1..10) even large (up to 6000 blocks) files they are
transferes without problems.

Can anybody help us?

Thanks


Olaf Thun
Technische Hochschule Darmstadt
Institut fuer Elektrische Energieversorgung
Schlossgraben 1
6100 Darmstadt
West-Germany

Bitnet:  XBR4DB26@DDATHD21.Bitnet

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 12:24:38 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Proteon p4200 Packet Drop Rates

Does anyone have any numbers on packet dropping by Proteon p4200 IP Routers?
Please include a description (brief!) of your environment.

I have set up a test suite of two p4200's, two IBM PS/2 model 60's, and 3
Ethernets:


    PS/2          p4200         p4200          PS/2
      |           |   |         |   |            |
      V           V   V         V   V            V
    ---------------   -----------   ---------------
       Ether              Ether         Ether

Running the MIT/CMU PC/IP Ping between the two PS/2's continuously
I see packet losses (i.e. response timeouts) on the order of 1 in
every 2500 ping requests (or 1 every 5000 packets - 1 packet for the
request, one for the response). There is no other traffic, etc on
the nets at the time of the tests. Is this number high? low? ???

I will be glad to summarize to the net, as well as provide more
quantitative information as I continue the studies.

Thanks
Frank Kastenholz
Atex/Eastman Kodak

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 15:17:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   ICMP Broadcast

broadcast ICMP echo request is certainly guaranteed to provoke a
massive collision (if many IP implementations respond), but this
is not synonymous with being obnoxious or being a VERY BAD idea.
I think I would call it an unusual, potentially dangerous action.
If viewed as another LAN management tool, it can be useful, as
mentioned, to locate quickly all active IP stations on a
broadcast LAN.  I see this as a useful, off-hours verification
against address assignment databases.  Certainly I would wish to
request users not to issue such broadcasts, but I'm not sure that
users stations should be mandated not to respond to a broadcast
request.  (Being one of many tools, you might conclude that the
safest network behaviour is to constrain the IP behaviour.  But
maybe this is just a user behaviour prophylactic, not a protocol
design goal.  don't you really want an implementation switch:
do/don't respond to IP broadcast ICMP Echo, for individual sites
to set?)

Also, massive LAN collisions are not necessarily to be avoided,
they are to be managed, which might mean avoidance during prime
time to some sites.  Generating a test massive collision with IP
broadcast might tell you how different implementations behave,
which are more/less robust, what the settling time for this
incident is for a given LAN, how your network components are
responding.  My view is that many production LANs permit some wee
hour testing or preventive maintenance and learning on the real
live network.

I'm not sure how much of real LAN management might not be
considered to be "unusual" and "potentially dangerous" from the
perspective of a user who was yet to benefit immediately and
directly.

Walter doc Urbaniak.  Urbaniak@BBN.COM (800 station Ethernet)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 16:21:06 GMT
From:      martin@EDN-UNIX.DCA.MIL (Martin Gross)
To:        comp.protocols.tcp-ip
Subject:   ACC 5250 under Ultrix 1.1


  
   Has anyone sucessfully installed an ACC 5250 under Ultrix 1.1 on a
MicroVax II? I'm currently trying and am having no luck configuring
the interface using the acpconfig utility. The program kicks me out
saying that the socket operations are not supported. Any help would 
be greatly appreciated.

                             Thanks,

                                      Martin Gross

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Sep 88 13:18:24 +0200 (Central European Sommer Time)
From:      XBR4DB26%DDATHD21.BITNET@CUNYVM.CUNY.EDU (OLAF THUN)
To:        tcp-ip@sri-nic.arpa
Subject:   Problems with FTP-Command "msend"
We have a problem during filetransfer from VAX to Apollo using the
FTP-Command "msend".

Our hard- and softwareconfiguration:

        VAX 8530 (VMS 4.6, CMU_TCP 6.2)
        MICROVAX (CMU_TCP 6.2)
        Apollo DN3000 (Aegis 9.7, TCP/IP 3.1)

Everytime we start a filetransfer from the VAX 8530 or the MicroVAX to the
Apollo with the command "msend /struc=file /type=ascii /noprompt *.*" (about
80 files, each file 1-100 blocks, only ASCII-character) FTP is aborted after
20-30 files with the following error:

        -IPACP-E-CSE- Connection table space exhausted

The filetransfer in the other direction (Apollo->VAX) works without errors.

If there are only a few (1..10) even large (up to 6000 blocks) files they are
transferes without problems.

Can anybody help us?

Thanks


Olaf Thun
Technische Hochschule Darmstadt
Institut fuer Elektrische Energieversorgung
Schlossgraben 1
6100 Darmstadt
West-Germany

Bitnet:  XBR4DB26@DDATHD21.Bitnet
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 17:50:48 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Installing TCP-IP on a CTIX unix system


 Larry,

Smile when you say "timewarp." I must assume the difference between
the eastern and western versions is that they assume timing is derived
from line-frequency clocks and that the means used by the power grid
east of the Rockies to synchronize is different from that used westward.
In the east, the master clock is controlled manually from a site in Ohio,
while in the west, the system is closed-loop and automatic. My measurements
disclose a factor of ten reduction in jitter and wander of western clocks
with respect to eastern clocks, which show daily excursions up to five
seconds in summertime. I can tell you about Quebec clocks and Texas clocks
and even German clocks, all of which use different mechanisms. I assume
special versions will be produced for these systems as well.

As for me, I'd use NTP and a crystal-derived clock anyway.

Dave

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 19:58:48 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   (none)

From gary Wed Sep 21 12:34:42 1988
Received: by ACC-SB-UNIX.ARPA (5.51/4.7)
	id AA00536; Wed, 21 Sep 88 12:34:35 PDT
Date: Wed, 21 Sep 88 12:34:35 PDT
From: gary (Gary Krall)
Message-Id: <8809211934.AA00536@ACC-SB-UNIX.ARPA>
To: chris
Subject: 4020 Flames
Status: R

Curt,  

I wanted to clear up a few points that were raised in your
recent posting to the tcp-ip discussion list regarding the use
of Transparent Gateways, and their implications on the DDN. 

First off, I thought you did a great job explaining how a
Transparent Gateway works. As you discribed the ACS 4020 uses
the logical host field to map Ethernet hosts onto the DDN. 
    
    >There are several problems with this arrangement.  First and
    >foremost, RFC 1005 (May 1987) contains a suggestions for 
    >rearranging the 32 bit IP address.  This suggestion, if adopted, 
    >would render the transparent gateway router useless.  This is 
    >why the Milnet manager is discouraging the use of this 
    >addressing scheme. 

Before we began work on our Transparent Gateway we held meetings with 
BBN, DCA and consulted with key members of the Internet Activities 
Board to discuss the approach we were considering.  One of the
results of those meeting's was our inclusion in RFC 1009
(Requirements for Internet Gateways) as a viable alternative to
EGP-style gateways. 

The other important point is that RFC's are "Request for Comments"
and it does not necessarily follow that "suggestions" will become
"implementations".  We have a relatively large number of units installed
on the network due to the appeal of this functionality. This being the case
one of the concerns with implementing RFC 1005 is the potential
impact on those sites.  Secondly, it does not necessarily follow that
if RFC 1005 is adopted, "it would render the transparent gateway
router useless."  In fact it might pose some problems in terms of the
number of hosts we can support (which is currently 49) but the utility
of the device is still available.

    >Without being published in the NIC's host table, it is difficult 
    >to receive electronic mail without the IP address as the distant 
    >end will have no way of knowing which PSN and port the host is on.
    >This is not a problem if the DOMAIN system is employed.

Curt, I just did a "whois huachuca-em.arpa" and got host info and an IP
address back from the NIC. This is the electronic mail host for your
site, Ft. Huachuca. We've had a Transparent Gateway operating down there
for about a year and a half now and, as a matter of fact, you are
reading this message courtesy of our unit. I've never had to know the 
IP address, I just specify the name.  The point  is that a)
it is fairly easy to edit host tables both in your local environment
and at the NIC and b) as the NIC does not want to manage all the 
growing host tables the DDN has mandated the use of the Domain system 
which, as you pointed out, alleviates the problem. 

    >First, is anyone using this currently? I know of the definition
    >of how it is to be done on the X25 connections to the net.
 
    >Currently, the HOST.TXT file shows only 3 of the 1727 Milnet hosts
    >using this addressing format.  These three machines are special
    >purpose Sun work stations with only a single user per machine.
    >There are many others, they just are not published.

Please see my previous paragraph and, again, the point is that not
everyone using a ACS 4020 has actually advised the NIC of their
host address simply for the fact that they have a limited community
that needs to send/receive mail or they are using the DOMAIN system.

    >There is another concern with using a transparent gateway.  Some
    >gateways may or may not fully participate with the Internet Control
    >Messaging Protocol (ICMP) [1].  The ICMP is concerned with network
    >flow control.  A transparent gateway which does not fully 
    >participate with ICMP may choke the PSN, or it may not inform 
    >the host that the distant end is dead [2].

I'd like to quote from a paper that Gary Krall, ACC's Director of 
Marketing and Keith McCloughrie, now with The Wollongong Group, wrote
for Connections Magazine awhile ago:

Flow Control
------------

"Data transmission between the ACS 4020 and the DDN-X.25 network is
flow-controlled at both levels 2 and 3 of the DDN-X.25 protocol.  In
contrast, there is no flow-control on transmissions between the ACS
4020 and Hosts on the Ethernet.  This, of course, is typical of an
Ethernet environment and of the datagram concept of an IP-network,
where guaranteed ordered delivery requires the use of an end-to-end
transport protocol (e.g., TCP).  Some assurance, however, is needed that
a) Ethernet Hosts do not repeatedly overrun the ACS 4020 with more
transmissions than the DDN-X.25 network can absorb, and b) there is a
limit to how much Ethernet traffic, the ACS 4020 can send in one burst
to a Host.

These assurances are provided through the availability of a large
amount of buffer space in the ACS 4020, and by the use of flow-
control in the Host's level 4 (and higher) protocols. For example, if
TCP is used for the majority of transmissions, then the end-to-end
flow control on TCP connections provides a window size specifying
the maximum amount of data to be in transmission on each connection.
This window size is dynamically adjusted by the receiving TCP
implementation according to its current buffer space limitations.

In the ACS 4020 to Host direction, the Host's assurance of being able
to take the maximum burst of traffic, is that the size of such a burst
is limited by the aggregate of all window sizes, and that the Host
itself controls these.

In the other direction, the provision of 1.5MByte of buffer space
assures that the ACS 4020 is not repeatedly 
overrun.  With this amount of memory, the capacity to buffer data
which the DDN-X.25 network can not yet absorb is estimated at 400
TCP connections (assuming an average window size of 1KBytes).

Nevertheless, congestion can cause TCP retransmission timers to expire
resulting in additional IP datagrams being received by the ACS 4020.
Correctly implemented TCPs will dynamically respond to this by
slowing their rate of retransmission. However some means of limiting
the number of queued datagrams is required to cater to "rogue" TCP
implementations.  This means is provided for by the use of the
"time_to_live" field in the IP header.  As specified in the IP
specification this field must be decremented every second it is queued
in the ACS 4020, with the datagram being discarded if this field
reaches zero.

As mentioned above, data transmission between the ACS 4020 and the 
X.25 network is flow-controlled at both levels 2 and 3.
Note that flow control at X.25 level 3, provides independent
flow control for each X.25 logical address.  Thus, independent flow
control for individual Ethernet hosts is obtained if a unique X.25 
logical address is assigned for each.  This would prevent one "rogue"
TCP implementation from starving all the others of all service."


    >Why anyone would want to use this type of gateway is beyond me.  I
    >really would like to hear some good reason to use it.  I may not be
    >aware of some special feature about remaining a Class A host.  My
    >understanding is folks like to use them as they believe this is the
    >only way to do X.25 type multiplexing. 

Curt, you have listed many of the disadvantages of Transparent Gateways.
Let me quote again from the same article:

Advantages of Transparent Gateways
----------------------------------

"A Transparent Gateway provides better performance since there is less
overhead traffic on the congested X.25 link. For example; a
Transparent Gateway requires no exchange (i.e. both directions)
of periodic routing table updates and status messages.  It only
requires routing information to be received for destinations currently
being used, and only when routing changes as is the case for
directly attached hosts.

Transparent Gateways provide flow control on a 
source-host/destination-host pair basis rather than on a
destination-host-only basis.  Separate X.25 virtual circuits are
established for each X.25 logical address assigned to one or more
of the Ethernet hosts.  Thus, the use of multiple logical addresses
provides the additional flow control rather than having all packets
lumped into a single virtual circuit as would be established by an
IP Gateway.  Thus, the few packets of an interactive connection from
one Ethernet host would not be delayed by the many packets of a bulk
transfer from another Ethernet host.

Transparent Gateways do not implement any of the current Gateway 
protocols, which are currently under review and are subject to
change (see revised version of RFC 985 and other proposed changes
such as "Son-of-EGP").	

The use of Transparent Gateway's eases the problems associated with 
the increasing number of active networks by not requiring an extra
network number for an isolated Ethernet.

Transparent Gateways will also make it less likely for hosts on
the Ethernet to suffer loss of connectivity to distant networks
due to lack of routing table space, since space will
not be required for a network number for the Ethernet.

Finally, the use of multiple Transparent Gateways between an Ethernet 
and a DDN X.25 network provides the capability to load-level the traffic
being exchanged between the two networks.
This load-leveling occurs as a result of the necessary virtual
circuits between Ethernet hosts and X.25 hosts being spread
across the multiple Transparent Gateways."


   > Hope this helps Barry,
    >Curt Vincent
    >Army Computer Engineering Center
    >Army Information Systems Engineering Command
    >Fort Huachuca, AZ 85613-7300

I guess it's like anything in life, there's really no free lunch. We've
found many applications that are well-suited to the capabilities of
a Transparent Gateway, but it's not a solution for all sites and we 
don't represent it as such. It is, however, a cost-effective way for
many sites to gain connectivity to the resources of the DDN and other
networks.


Chris VandenBerg

Usual disclaimer, discussion (and even flames) welcomed.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 20:14:04 GMT
From:      stevens@hsi.UUCP (Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   UDP max datagram size ?

Is there an agreed upon max datagram size for UDP packets ??
I couldn't find one in RFC 768.  In looking at the systems
I have access to, I see the original 4.3 BSD had a 9,000-byte
limit on transmit which was then reduced to 2,048 with the
4.3 network updates from Berkeley a few months back.  The PC
RT under AIX has a 512-byte limit, while the IBM mainframe
version (FAL) allows up to 2,048.  I'm aware of the performance
penalties once you exceed the network's MTU, but I was
wondering if there was a generally agreed upon maximum
(I'll guess there isn't).

As I recall from a few years ago, isn't this the reason the BSD
rwhod packets have a built in limit of information on up to 41-users.

	Richard Stevens
	Health Systems International, New Haven, CT
	   stevens@hsi.uu.net
           ... { uunet | yale } ! hsi ! stevens

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 21:15:33 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple TCP/IP servers on one host

Routers from cisco Systems have supported load balancing among
equivalent routes for a long time by round robining the packets
among routes.  We also support a "variance" command for specifying
a multiplier that may be applied to consider routes for load sharing.
A variance of 1 implies that we use only the best route, a variance
of 4 implies that we use the best route, and any other routes up to
4 times as bad as the best route.  A route 4 times as bad as the
best route will get 1/4 of the packets...

This works just fine for relatively simple networks, but for very
large networks, there is not enough resolution in routing metrics,
and you tend to use routes that you really wish you hadn't for distant
hosts (this is true even with cisco's IGRP, which has considerably
better resolution than any other routing protocol).  It still seems
to work for relatively small variance values (say, <4).  (What it
boils down to is that it is probably reasonable to use a 200 mS path
instead of a 50 mS path, but not to use a 16 S path instead of a
4 S path.)

Setting the variance to greater than 1 is also a good way to find
bugs in reassembly algorithms, as packets WILL arrive in a different
order than they were sent.

This will not allow a host to pick between several gateways on an
ethernet (it only allows a gateway to pick between several paths).
But current wisdom is that hosts should not know anything about the
internals of routing issues anyway.

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

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 88 23:13:41 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

Stuart,

The Host Requirements draft says a TCP must not (try to) open a
connection to a remote broadcast or multicast address.  I found here at
ISI that when my Sun opens a TCP connection to a broadcast address, the
ISI Symbolics machines crash in an obscure way.  The Operations group was
most unhappy, said it was my fault.

Bob Braden

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 00:05:11 GMT
From:      david@wolfen.cc.uow.oz (David Wilson)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   TCP/IP via SuperMac CommCard on a Mac II

We have the following network in our department:

	===================================================== Ethernet
			|		|		|
		   +--------+	   +--------+	   +--------+
		   | MacII  |	   | KFPS-3 |	   |Sequent |
		   +--------+	   +--------+	   +--------+
			|		|
 --------+-------+-------+-------+-------+------------ Localtalk
		|		|		|
		More macs		   laserwriter

The localtalk for the MacII running A/UX is provided by a SuperMac
CommCard. This allows A/UX users to spool printouts to the laserwriter.
If a mac user on the localtalk network wishes to login to the A/UX
system using telnet he goes via the KFPS-3 onto the ethernet and into
the Mac II.

Question 1:	Has anyone implemented a layer of software that would
		allow the CommCard to appear as though it were an ethernet
		card so that telnets to this machine would not need to
		go out onto the ethernet [and presumably let a MacII
		running A/UX to be networked without an ethernet card].
		This software would encapsulate TCP/IP inside Appletalk
		packets as well as allowing utilities such as ifconfig to
		be used.

Question 2:	If such a layer of software were written, would it then be
		possible for a MAC II with both interfaces to replace the
		KFPS altogether, performing routing between the Localtalk
		and ethernet networks?

David Wilson	Department of Computing Science, University of Wollongong
		david@uowcsa.cs.uow.oz.au

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 00:12:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Graziano's Streams Query

Periodically, a query hits this list about Unix Stream and about the
vendors offering TCP implementations for it.  The latest, from
Marco Graziano of Olivetti, asked a broad range of pointed questions and
so, it seems to me, forms a good base for a response that might be of
general interest.

Virtual Device Drivers

Streams uses modules and message-passing, in the kernel, to implement
protocol layers.  (Unless streams is implemented in user space, there is
no such thing as a "streams program" such as FTP or Telnet.  Streams refers
only to the kernel-level protocol core, usually limited to data link, 
network and transport levels, although some higher-level protocols are done
inside streams.)

Communication between modules is STRICTLY message-based.  The only other
access to information, by a module, is to call kernel subroutines.  Modules
may either be single queue in and out (called a "module") or multiple
queues in or out (called "driver").

1.  Advantages:  Streams imposes a discipline which forces highly modular
protocol coding.  That can, of course, create terrible performance, but does
not need to.  The other side of this discipline is that it can allow the
construction of functions which can be mixed and matched.  It also means that
the task of creating protocols (i.e., in separate modules) can be partitioned
among different people easily.  

One of the emerging major benefits of Streams is its utility in a
multi-processor environment.  Properly implemented, streams modules may
operate in DIFFERENT address spaces.  The only shared memory that is needed
is for message-passing and data-buffers.

One of the subtle benefits is portability.  Highly integrated code has a
tendency to bury many of its operating-system-dependent assumptions.  Streams
makes the assumptions clearly defined.  To port streams code, you need only
to create a Streams environment.  (This may turn out to be roughly the same
effort as porting/hacking another implementation, but the process is far
more predicatable and you are left with all of the protocol code being shared
between the original and new implementation.

2.  Are modules truly independent?  Yes!  Except, of course, that they must
agree to the format and rules of messages that are passed.  That is, there
must be a well-defined semantic interface between modules.

3.  Out-of-band access to modules:  Modules are accessible as "devices".
For example, we supply /dev/arp.  You can open it and then do IOCTLs with it.

4.  Support of alternate transports:  You betcha!  TCP and UDP are supported
as co-equals.  Further, we have an OSI TP4. 

5.  NFS integration:  NFS is an example of code above transport level which
resides in the kernel and is part of the Streams environment.  It accesses
UDP via the standard Transport Provider Interface (TPI).  

Access from user programs is via the Transport Library Interfaces.  It gets you
across the user/kernel interface and is competitive with Berkeley sockets
in terms of its role in life.  TLI is user level.  TPI is kernel level.  In
effect, it does for kernel processes what TLI does for user processes.

(By the way, there is at least one NFS that does not use TPI, but I do not
know any other details of its implementation.)


System V implementations able to use BSD kernel functions?  Well, mostly
there is a pretty-good mapping of SVR3/Streams calls to the kernel onto
BSD kernel functions.

1.  Device drivers are, in fact, kept alive by a daemon, typically.  In the
TCP case, the daemon sets up the multiplexed set of stream modules and holds
the file descriptor.

2.  Global data structures:  Basically, these are a no-no.  The only
shared data that is allowed, other than what you would access through standard
kernel functions, is via message-passing.  Keeping stray shared data structures
around leads to tough questions about how the structure will be shared in
a multi-processor environment.  The safest way is to have a query-response
discipline between the module that owns the structure and any that need to
"read" it.

We have recently been embarrassed to find a couple of placess that we commit
this sin-of-sharing.  In both cases, the solutions are conceptually simple,
involve small programming effort, and will not have any performance impact.

3.  Message buffer passing:  This is done via pointer (message block) passing.
Actual data are not passed.  e.g., TCP has a header message block and points
to user data.  IP adds its header message block and points to the TCP mb.
ARP sets up the ethernet header mb and points to the IP mb.  ARP or the
device driver, when they are done with this chain -- Note that this is
a scatter/gather model, which can be quite nice, for some devices -- they
free it.  However, TCP holds on to the data block until it gets an ACK back
for the relevant sequence number.

4.  Kernel modifications required:  Should not be any!  You can hide quite
a bit of convenient non-discipline by adding things to the kernel, but it
is not in the spirit of Streams.  Sockets, in particular, can be emulated on
top of TLI (i.e., within each user's application) with a fair degree of
faithfulness and no meaningful performance impact.  The one exception to this
rosy picture is select(), which currently does not map to poll().  This
required a select() driver.  (In Streams, rather than part of the generic
operating system kernel.)

5.  Performance measurement:  Probably the best answer is to ask for the
next question.  There really are not any serious performance measurement or
instrumentation tools.  You can get information about buffer exhaustion and
can use the strace logging facility to record useful information, but that
seems to be about it.


Dave Crocker
VP, Engineering
The Wollongong Group

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 02:05:07 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Transparent Gateways

I thought I'd better drop my 2 cents worth in here - maybe it will do
some good.

a) RFC1005 regarding a possible change to the addressing structure of
the C30 networks was distributed for review and comment only.  We've
since decided it was a bad idea and are no longer considering this as
a valid approach to expanding beyond 256 packet switches.

b)  The third octet is, and always has been reserved for logical
addressing - actually local demultiplexing.  It was originally used
for a device called an Arpanet port expander.  This device lives on in
the form of a transparent gateway and the Air Force Concentrator -
both forms of the same basic approach.  Barring a substantial change
in technology in the next 5 years - the third octet will continue to
be reserved for local demultiplexing.

c) ACC is correct - there are a number of transparent gateways in use
on the MILNET.  The only host table registration requirement is for
the device actually connected to the port.  We are discouraging the
host table listing of hosts not actually connected directly to the
Arpanet or the Milnet.

d) I am not aware of the Milnet manager discouraging the use of the
transparent addressing scheme - this is definitely incorrect in face
of the recent award of the Air Force concentrator device contract with
an expected number of connections greater than 200.


I'll go out on a limb far enough to say that the above is official.
If anyone needs formal confirmation of the above - direct a letter to
the DDN Program Manager to the attention of the Technical Manager
asking for clarification.


Mike StJohns
Capt, USAF
Defense Data Network Programs
and all around good-guy!

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Sep 88 08:55:11 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Richard Stevens <hsi!stevens@UUNET.UU.NET>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: UDP [IP] max datagram size ?

>     Is there an agreed upon max datagram size for UDP packets ??

There is an assumption at the IP level that says an IP implementation does not
have to be prepared to reassemble and buffer individual packets of up to 576
octets.  This is listed in RFC791 (IP protocol spec) in the description of the
IP header Total Length field.  "It is recommended that hosts only send
datagrams larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams."  This assurance is only provided
by specifications in higher layer protocols.  Some IP implementations are
capable of reassembling up to the full 64K datagram size without prior
agreement.

For TCP, there is an exchange at the time of opening the connection where the
2 parties can agree on datagram sizes larger (or smaller) than 576, using the
TCP MSS option.  Two hosts on an ethernet may well negotiate for 1024 data
octets.

In answer to your question about UDP, I would have to say that, yes, there is
an agreement on datagram size, but it is specific to the higher layer
protocol.  TFTP uses 576.  Sun NFS uses 8K.  I think you would have to
implement the UDP part of a system so that it would be able to handle whatever
a higher layer would want.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 13:56:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Ethernet Address
>In the meantime, I would appreciate hearing from the "owners" of these
>manuf ids, seen on various nets:
>
>00001b 000086 0000a9 0000b3 080001 080003
				    ^^^^^^
>080019 08002e 080036 080036 080046 080067
>080087 080090
>
>They ARE shipping hardware, hence ought not be shy about keeping their
>intentions secret any longer!!
>
>Tnx in advance..............
>Harry
>(415) 965-1800  (Network General Corp.)

08:00:03:xx:xx:xx belongs to ACC.

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


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 12:55:11 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP [IP] max datagram size ?


>     Is there an agreed upon max datagram size for UDP packets ??

There is an assumption at the IP level that says an IP implementation does not
have to be prepared to reassemble and buffer individual packets of up to 576
octets.  This is listed in RFC791 (IP protocol spec) in the description of the
IP header Total Length field.  "It is recommended that hosts only send
datagrams larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams."  This assurance is only provided
by specifications in higher layer protocols.  Some IP implementations are
capable of reassembling up to the full 64K datagram size without prior
agreement.

For TCP, there is an exchange at the time of opening the connection where the
2 parties can agree on datagram sizes larger (or smaller) than 576, using the
TCP MSS option.  Two hosts on an ethernet may well negotiate for 1024 data
octets.

In answer to your question about UDP, I would have to say that, yes, there is
an agreement on datagram size, but it is specific to the higher layer
protocol.  TFTP uses 576.  Sun NFS uses 8K.  I think you would have to
implement the UDP part of a system so that it would be able to handle whatever
a higher layer would want.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 14:29:52 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

I vote for hosts NOT responding to broadcast ping's.  If you want to find
out who is on your net:

	set networkpart=192.5.16
	@ subnet = 1
	@ maskfactor = 32
	@ host = 1
	@ subnetpart = ( $maskfactor * $subnet )
	while ( $host < $maskfactor )
	@ hostpart = ( $subnetpart + $host )
	set address="$networkpart.$hostpart"
	icmp echo vanilla $address
	@ host = ( $host + 1 )
	end
	
But, if you do respond to broadcasts you better put in the IP address
of the interface the broadcast came in on in your response!

Phil Wood.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 14:55:34 GMT
From:      hakda@erilin.nokia.se (H}kan Danielsson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Exelan question


We have a propriety system (not UNIX) which we intend to connect with an
Ethernet LAN. For this purpose we have installed following hardware and
software from Exelan Inc:

          EXOS 202 Ethernet Front End processor for VMEbus systems with
          firmware version 5.3.

          EXOS 8010 Protocol Module, version 3.2. The host code is not
          ported, because we don't have a C-compiler. Instead we have tried
          to follow the documentation.

When we use the system with heavy load it fails. We have isolated following
strange situation:

2 computers (nodes) are connected. In each node 2 processes are connected via
sockets to processes in the other node:

---------                   ---------
!   A --!-------------------!-- B   !
!       !                   !       !
!   C --!-------------------!-- D   !
---------                   ---------

Each process executes the following sequence (according to the EXOS 8010
documentation:

          SOSOCKET
          SOCONNECT/SOACCEPT
          SOSEND
          SOSEND
          :
          :      until reply code EWOULDBLOCK is returned.
          SOSELECT

which means that all processes are sending data until the Ethernet board
buffers are filled.

Suddenly after a few minutes one or several of the processes gets a signal
(SOSELWAKEUP) indicating that the Ethernet board is ready to accept another
block. The process then enters the following loop:

------->  SOSEND    gets reply code EWOULDBLOCK, indicating that all buffers
!                   are occupied.
!         SOSELECT  gets a reply indicating that the board is ready to accept
!          !        a block.
------------         

This loop suddenly is exited with the indication of a correct SOSEND. I don't
know who has emptied the buffer.

Has anybody had the same or a similar problem? Have we missed some parameter
when we use the Ethernet board or do we have an old software version?

Please reply with email.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 14:58:57 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  UDP max datagram size ?

4.3BSD has a default size limit of 2048 bytes, but this can
be changed with a `setsockopt' call.  Rwhod packets are limited
not by this size, but by the Ethernet MTU, as 4BSD will not
fragment a UDP broadcast packet (unless you tweak your kernel).

Chris

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 16:39:01 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP's & IP src addrs

Try telnet <class B network>.255.255  

I found a connection established as follows (telnet from Sun to ethernet):

SUN 4.0 SUNOS
tcp        0      0  doc.1101               128.165.255.255.telnet ESTABLISHED

VAX 4.3BSD
tcp        0     78  128.165.255.255.telnet doc.1101               ESTABLISHED

Is this predictable?

The connection is stable.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 16:45:35 GMT
From:      murayama@Cs.Ucl.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast pings


I, for one, vote for broadcast/multicast ping.
Broadcast ping is a totally different concept from
ping with a unicast address in the sense that you
don't have to know what objects are there.
It is very tempting to use it for configuration detection.
You can find out not only active objects but also what
shouldn't exist.

Yuko

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 17:24:51 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP's & IP src addrs

Philip,

What usually happens is that, after a glorious flabble of packets, one
of the broadcast clients synchronizes and the others eventually get
reset. This assumes each TCP peer randomizes its initial sequence number.
However, if the clients keep bashing away, eventually they will hear
a data packet without the expected SYN bit set and will send a reset.
Eventually this succeeds and the connection comes bum. I don't understand
how your SUn - VAX connection survived.

Dave

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Sep 88 17:45:35 +0100
From:      Yuko Murayama (+44-1-387-7050 ext.3695) <murayama@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: broadcast pings

I, for one, vote for broadcast/multicast ping.
Broadcast ping is a totally different concept from
ping with a unicast address in the sense that you
don't have to know what objects are there.
It is very tempting to use it for configuration detection.
You can find out not only active objects but also what
shouldn't exist.

Yuko
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 02:37:46 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*02.37.43 FROM: Invalid user/address string
*02.37.43 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 3889; Fri, 23 Sep 88 02:37:44 CST
Received: by BYUADMIN (Mailer X1.25) id 0546; Fri, 23 Sep 88 01:36:08 MDT
Date:         Tue, 13 Sep 88 14:35:16 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     <Parser> W: Invalid RFC822 field -- "(MICHAEL". Rest of header
              flushed.
From:         oliveb!pyramid!prls!philabs!mergvax!cpmain!mikej
              @AMES.ARC.NASA.GOV
To:           jeff consoer <CC57000@SDSUMUS>

I have been seeing a lot lately about "TCP/IP". I would like to find out
more about it. Is it a stand alone protocol or is some special hardware
required to impliment it? Could someone direct me to a text that would describe
it in detail?

Thanks in advance.

--
                Michael R. Johnston - @NET: mikej@cpmain.uucp
..{cmcl2!phri!,uunet!}dasys1!cpmain!mikej || ...philabs!mergvax!cpmain!mikej
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 88 22:03:27 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

Please excuse my previous posting.  The program had one tiny bug which
caused the last host ping'd to be the broadcast address!

The corrected code:

	set networkpart=192.5.16
	@ subnet = 1
	@ maskfactor = 32
	@ host = 1
	@ maxhost = $maskfactor - 1
	@ subnetpart = ( $maskfactor * $subnet )
	while ( $host < $maxhost )
	@ hostpart = ( $subnetpart + $host )
	set address="$networkpart.$hostpart"
	icmp echo vanilla $address
	@ host = ( $host + 1 )
	end
	
Phil Wood.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 04:19:53 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*04.19.50 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 3893; Fri, 23 Sep 88 04:19:40 CST
Received: by BYUADMIN (Mailer X1.25) id 1197; Fri, 23 Sep 88 03:13:31 MDT
Date:         Wed, 14 Sep 88 12:17:22 EST
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
From:         301 SPAN Network Info Center  286-7251
              <NETMGR@NSSDCA.GSFC.NASA.GOV>
Subject:      Forwarding a bounced mail message.
X-To:         tcp-ip@sri-nic.ARPA
To:           jeff consoer <CC57000@SDSUMUS>

From:    NCF::EXOS         30-AUG-1988 11:25
To:    POSTMASTER
Subj:    Mail error notification

Cannot deliver message to following recipients:
spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA.
   Reason: EXOS Mail error in following SMTP transaction:
>>> RCPT To:<spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA>
<<< 550 <spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA>... User unknown


*** Original message follows: ***

Received: by nssdca id <2020089C051@nssdca.GSFC.NASA.GOV> ;
       Tue, 30 Aug 88 11:05:38 EST
Date: Tue, 30 Aug 88 11:05:18 EST
From: postmaster@nssdca.GSFC.NASA.GOV
Subject:  Net Help
To: spock!a3bee2!omega!grzesiak@yale-bulldog.ARPA
X-VMS-Mail-To: EXOS%"<spock!a3bee2!omega!grzesiak@yale-bulldog.arpa>"
Message-ID: <880830110518.2020089C051@nssdca.GSFC.NASA.GOV>

 *** VMS error in delivery mail, error message follows ***

EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error: -RMS-E-CRE, ACP file create
failed_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error: -SYSTEM-F-EXDISKQUOTA, disk quota
exceededR:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
EXOS Mail server: delivery error:
%MAIL-E-OPENOUT, error opening
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181CD74B5.MAI; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded

 *** Original message follows ***

From : spock!a3bee2!omega!grzesiak@yale-bulldog.arpa
Subject:  Net Help

Return-path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by nssdca.GSFC.NASA.GOV
          id 20200899002 ; Tue, 30 Aug 88 11:03:43 EST
Received:  from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon, 29 Aug 88
 05:52:12 PDT
Received:  by ucbvax.Berkeley.EDU (5.59/1.31)
    id AA06723; Mon, 29 Aug 88 05:26:53 PDT
Received:  from USENET by ucbvax.Berkeley.EDU with netnews
    for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
    (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date:  27 Aug 88 16:42:06 GMT
Organization:  Omega Dynamics , Wallingford Ct.
Message-Id:  <103@omega.UUCP>
Sender:  tcp-ip-request@sri-nic.arpa
To:  tcp-ip@sri-nic.arpa

Hello:
   I have an implementation I'd like to try and have little idea
 about how to go about it. I have a few UNIX boxes , two of which are
 CADMUS 9000's . I have Network cards and drivers for these systems.
 The cards I have are: 3com ethernet and Excelan EXOS 203 (a pair of each).

 What I'd like to know is:
      A) Which of these is a better install?
         (Ease of install , reliable , versatile ,etc)
      B) Can these cards be cheated and how?
         ( Can they be used point to point without tranceivers
            because all I need from them is remote disk mount capability)
      C) If these cards can't be cheated , where can I get thin ethernet
         tranceivers and equipment for these?

    Any help is appreciated - Thank you in advance.....

      John Grzesiak
      Omega Dynamics
      47 Spring Street
      Wallingford Ct 06492.    (203) 284-8530 voice
                               (203) 289-9300 work (9-5 Eastern)
                               (203) 284-3776 guest:guest (computer)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 01:19:37 GMT
From:      dji@sbcs.sunysb.edu (the dirty vicar)
To:        comp.protocols.tcp-ip
Subject:   Info about UDP please

Can someone PLEEEEASE tell me where to find info on UDP??  Ok,
well, let's take this a step further.  I'll be writing a program
in which many many processes will be running in parallel on
an internet and will need to communicate small bits of information
to each other at a high rate.  I was thinking of using TCP (not that
I know much of anything about it at this point).  It was suggested to
me that I should use UDP instead.  What do you all think??  In any
case, if you know where the UDP info is (is it in some RFC??), please
let me know.  Responses by mail please.  I'll summarize. Thanks.
--
Dave Iannucci	Computer Science, SUNY at Stony Brook, Long Island, New York
*************	UUCP: {allegra, philabs, <arpa-gateway>}!sbcs.sunysb.edu!dji
* 4 months! *	ARPA-Internet or CSnet: dji@sbcs.sunysb.edu
*************	BITNET: dji%sbcs.sunysb.edu@SBCCVM.BITNET

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 02:06:49 GMT
From:      nak@bridge2.UUCP (N. Arunkumar)
To:        comp.protocols.tcp-ip
Subject:   Birds of a Feather Session on System Load

Subject: Birds of a Feather Session on System Load


A Birds of a Feather session has been scheduled to discuss
System Load - IDEA 0018.

This IDEA proposes a standard for software loading using
IEEE 802.1 System Load Protocol BOOTP/TFTP. 

Multicast booting and booting over gateways will be discussed.

This session will be at 5 pm on Thursday the 29th.
ACE will have a schedule listing times and rooms for all
BOF sessions at the conference.

N. Arunkumar
Inder Sidhu

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Sep 88 09:49:09 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Yuko Murayama (+44-1-387-7050 ext.3695) <murayama@CS.UCL.AC.UK>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: broadcast pings
It seems we have started one of those "tastes great!" - "less filling!"*
arguments again.

Should every station reply to a broadcast of some kind?

 NO: it causes massive collisions.
YES: it helps manage the net by finding formerly unknown stations and
     diagnosing problems caused by heavy bursts of traffic

Perhaps you should put a broadcast detector in your copy of ping, so that it
will only send one packet, instead of one per second, as its default.  The
main point is that you do not want to have the massive collisions occur while
people are really trying to get work done.

Also, I think that the NO answer works best for connection protocols like TCP,
and that the YES answer may be useful for datagram protocols like ICMP/ECHO or
UDP/RWHO.

Mike


*Apologies to people who don't see U.S. television ads; this refers to a
series of commercials for a 'lite' malt beverage which allege there are 2
partisan groups which favor it, for different reasons.  (I could start a whole
new argument about the benefits/curses of beer ... but that belongs on another
mailing list.)
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 13:20:21 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*13.20.18 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0233; Fri, 23 Sep 88 13:20:19 CST
Received: by BYUADMIN (Mailer X1.25) id 6300; Fri, 23 Sep 88 10:17:07 MDT
Date:         Thu, 15 Sep 88 17:37:25 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Karl Kleinpaste
              <triceratops.cis.ohio-state.edu!karl@TUT.CIS.OHIO-STATE.EDU>
Subject:      Re: ICMP's & IP src addrs
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

As long as I was at it, I decided to look at what a large collection
of diverse machines did with pings to .255.  I hit our backbone
ethernet (128.146.8, a little over 100 hosts) with a ping like this,
and the results are:

Responding with 128.146.8.255:
Sun-3/180 (SunOS 3.5.1 [UNIX]).

Responding with their own addresses:
HP-9000 (HP-UX [UNIX]), IBM-RT/PC (Mach), Proteon P4200, BBN Butterfly
(Mach), Pyramid (OSx 4.x [UNIX]), Encore Annex telnet server.

Not responding:
DEC-2060 (TOPS 6.1; responds to direct ping), AT&T 3B2/400 (SysV
Rel3.0 + TWG WIN; responds to direct ping), Kinetics Mac gateways
(KIP; doesn't respond to direct ping), Encore Multimax (Umax 4.2;
responds to direct ping), TI Explorer (Zetalisp; responds to direct
ping), Xerox-1108 (Interlisp; responds to direct ping).

Also, we have one HP-9000 client subnet.  When pinging that subnet's
broadcast addr (128.146.43.255), *only the server* responded - the
rest were silent.  Weird.

--Karl
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 13:20:28 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*13.20.24 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0235; Fri, 23 Sep 88 13:20:20 CST
Received: by BYUADMIN (Mailer X1.25) id 7012; Fri, 23 Sep 88 11:00:09 MDT
Date:         Thu, 15 Sep 88 17:11:43 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Karl Kleinpaste
              <triceratops.cis.ohio-state.edu!karl@TUT.CIS.OHIO-STATE.EDU>
Subject:      Re: ICMP's & IP src addrs
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

tmallory@park-street.bbn.com writes:
   > a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
   > the src IP address on the packet that is being returned...

   Flame:  An ICMP echo to a broadcast address should get no response!  What an
   incredibly obnoxious thing to do!

This looked just too tempting, so I headed off to one of our Sun-3/180
servers (SunOS 3.5.1) to see what would happen if I abused its client
subnet (12 Sun3/50 clients) in this way.  The result was just mighty
entertaining - the `packet loss' statistic is easily the best part,
followed closely by the claimed IP address...

Script started on Thu Sep 15 12:06:42 1988
[12] [12:06pm] tree:/dino0/karl> ping -s 128.146.28.255
PING 128.146.28.255: 56 data bytes
64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=0. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms
^C
----128.146.28.255 PING Statistics----
4 packets transmitted, 48 packets received, -1100% packet loss
round-trip (ms)  min/avg/max = 0/25/40
[13] [12:06pm] tree:/dino0/karl> exit

script done on Thu Sep 15 12:07:01 1988
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 08:55:46 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <8809211159.AA06217@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes:
> [Re: pinging to a broadcast address]
>   If a large percentage of the replying hosts have to ARP for the sending
> host's hardware address, then that's a lot of ARP requests for everyone
> to process.

  Hhmmm, you mean your hosts receive a packet on their ethernets and
don't record the mapping of source ethernet and IP addresses in their ARP
caches?  Doesn't sound like a very good idea to me.  I'd say there's
probably a pretty good chance you're going to have to send a packet back
to any host you receive one from ...

Casey

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 15:15:09 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*15.15.02 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0565; Fri, 23 Sep 88 15:15:18 CST
Received: by BYUADMIN (Mailer X1.25) id 9789; Fri, 23 Sep 88 13:59:46 MDT
Date:         Thu, 15 Sep 88 18:39:09 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Don Ferencz
              <cwjcc!cwsys3.cwru.Edu!ferencz@TUT.CIS.OHIO-STATE.EDU>
Subject:      TCP/IP Broadcast Address & Wollongong WIN3B
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>


Hello again.

A short while back I posted a question pertaining to the "broadcast
address" of my particular TCP/IP version - Wollongong's Enhanced
WIN3B running on three AT&T 3B2/310's.  I asked if anyone knew why all of
my attempts to change the broadcast address from a sockets application
(with the SIOCIFGBRDADDR ioctl) were failing with EINVAL.  Well, many
people pointed out what should have been painfully obvious: that
version of TCP/IP is based on BSD4.2 Sockets, which does not support
a change of broadcast address!  However, the #define for
SIOCIFGBRDADDR appears in the header file <ioctl.h>!!!  My thanks
to all who responded, and my condolances to those who had wished to
do the same thing I did.

===========================================================================
| Don Ferencz                       |  "All the world's indeed a stage\   |
| ferencz@cwsys3.cwru.EDU           |   And we are merely players\        |
| Dept of Systems Engineering       |   Performers and portrayers"        |
| Case Wetsren Reserve University   |     -- Rush                         |
===========================================================================
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Sep 88 17:53:31 -0400
From:      tmallory@PARK-STREET.BBN.COM
To:        Casey Leedom <admin.cognet.ucla.edu!casey@CS.UCLA.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, tmallory@PARK-STREET.BBN.COM
Subject:   Re: ICMP's & IP src addrs

>  Hhmmm, you mean your hosts receive a packet on their ethernets and
>don't record the mapping of source ethernet and IP addresses in their ARP
>caches?  Doesn't sound like a very good idea to me.  I'd say there's
>probably a pretty good chance you're going to have to send a packet back
>to any host you receive one from ...

While it this would help a lot with the traffic associated with the broadcast
pings, recording, or at least checking, the IP/hardware address mapping for
the source of every IP packet received seems wasteful, since it's purpose is
to save an infrequent ARP request.  If I receive 10000 packets from the same
host, I'm not sure I want to check the logical/hardware mapping table every
single time.  Also, there is the problem that the source address in the IP
header may well not match the source hardware address if the packet has been
sent through a gateway.  OK, so you only insert the mapping if the network
number matches the attached network.  But some hosts support multiple network
numbers for the same network, so the packet might still have come from a
gateway...  This gets complicated, and the layering isn't very pretty.  I
don't think many hosts do it, but I'd be happy to hear otherwise.

Tracy

PS: If a host wants to match IP source addresses with particular hardware
addresses for some limited flavor of security, then my main objection is moot.
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 13:49:09 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast pings

It seems we have started one of those "tastes great!" - "less filling!"*
arguments again.

Should every station reply to a broadcast of some kind?

 NO: it causes massive collisions.
YES: it helps manage the net by finding formerly unknown stations and
     diagnosing problems caused by heavy bursts of traffic

Perhaps you should put a broadcast detector in your copy of ping, so that it
will only send one packet, instead of one per second, as its default.  The
main point is that you do not want to have the massive collisions occur while
people are really trying to get work done.

Also, I think that the NO answer works best for connection protocols like TCP,
and that the YES answer may be useful for datagram protocols like ICMP/ECHO or
UDP/RWHO.

Mike


*Apologies to people who don't see U.S. television ads; this refers to a
series of commercials for a 'lite' malt beverage which allege there are 2
partisan groups which favor it, for different reasons.  (I could start a whole
new argument about the benefits/curses of beer ... but that belongs on another
mailing list.)

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 15:47:14 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Interfacing SUN to AUTODIN.

Bill:

I doubt that you can get approval from either DIA or DCA to directly connect
a Sun Workstation to AUTODIN without going through a full accreditation after
"hacking" the Sun operating system to remove all networking code.

You can probably get approval to access AUTODIN through an accredited CSP
(Communication Support Processor) system.  SIMPACT has developed a VME bus
interface and drivers to support the required DDCMP 4.0 or DDCMP/IDHSC II
data link protocol.  ADS which recently has moved from Palo Alto to Mountain
View has developed the required Full Duplex Message Protocol (FDMP) which
provides the transport layer connection to CSP.  More information can be
obtained from Mike Matsumoto at ADS (Advanced Decision Systems).

The hardware and software for the Sun was tested at our facility here in
Westlake Village interfacing to a CSP system through a BR1731 Communication
Control Unit (CCU).  The testing was successful; however, it has not been
installed at a site nor is it currently approved or accredited by either
DIA or DCA.

Merton Campbell Crockett                                 Contel Federal Systems
System Software Manager                 Information Management Systems Division
AN/GYQ-21(V) Program                            31717 La Tienda Drive, Box 5027
01(818)706-5573                               Westlake Village, CA   91359-5027

Internet:  mcc@etn-wlv.EATON.COM     Easynet:   DECWRL::"mcc@etn-wlv.EATON.COM"

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      FRI 23 SEP 1988 22:26:20 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*22.26.17 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 1067; Fri, 23 Sep 88 22:26:50 CST
Received: by BYUADMIN (Mailer X1.25) id 4721; Fri, 23 Sep 88 21:21:35 MDT
Date:         Fri, 16 Sep 88 21:20:02 -0700
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
From:         "NASA ARC NSI Project Office Milo S. Medin"
              <medin@NSIPO.NASA.GOV>
Subject:      Re: ICMP's & IP src addrs
X-To:         Jerry Lotto <lotto@wjh12.harvard.edu>
X-cc:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>
In-Reply-To:  Your message of 15 Sep 88 20:47:20 +0000. <303@wjh12.harvard.edu>


     And I am sure that someones bridge will then decide that they know
     where "the broadcast address" lives and stop forwarding it.
     I have seen this (anti-social) behavior in DEC Lanbridges and it
     does not bode well for the network until someone resets the beast.
     Takes a while to find if you aren't looking for it.


     --
     Gerald Lotto - Harvard Chemistry Dept.
     UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto
     ARPA:  lotto@harvard.harvard.edu


Actually, the Lanbridge, as all other bridges, looks at the source and
destination addresses in the ethernet frame, NOT in the IP header.  So
this particular bug only is triggered by an ethernet frame with a
source address of FFFFFFFFFFFF.  The Sun's do have an annoying bug when
turning around broadcast pings, but they do send them with the proper
ethernet frame addresses.  I have seen Kinetics Appletalk 'gateways'
fail in such a way as to send ethernet frames with broadcast source addresses,
and this does cause problems on a Rev. E LANBridge.   DEC is working a fix
though, and at least with LANBridges you can use RBMS to reset them
remotely....



                    Thanks,
                       Milo

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 21:20:45 GMT
From:      haas@utah-gr.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: Milking machines

Roger Fajman (RAF@NIHCU.BITNET) writes:

> ...We currently have a Bridge CS/1 with 32 ports that is hooked up to our
> IBM mainframe as a milking machine... Our biggest complaint about the
> Bridge CS/1 is that it does not negotiate the Telnet option correctly.  It
> says that it will echo and then expects the host to do it.  The problem is
> that our host does not echo, so the user must manually turn on echoing at
> their end...

We received from 3com/Bridge a model CS/1 running release 20000 of their
TCP software for evaluation.  When I TELNET to it from cs.utah.edu, a
VAX 8600 running 4.3 BSD, the following actual TELNET parameter negotiation
occurs (as observed with an Ethernet monitor):

CS/1: WILL SUPPRESS-GO-AHEAD  DO SUPPRESS-GO-AHEAD  WILL TRANSMIT-BINARY
      DO TRANSMIT-BINARY  WILL ECHO

VAX:  DO SUPPRESS-GO-AHEAD  WILL TERMINAL-TYPE

CS/1: DONT TERMINAL-TYPE

VAX:  WILL SUPPRESS-GO-AHEAD  DONT TRANSMIT-BINARY  WONT TRANSMIT-BINARY
      DO ECHO

VAX:  WONT TERMINAL-TYPE

The TELNET ECHO option negotiated here indicates that the CS/1 end of
the connection will be responsible for any necessary echoing of keystrokes
received from the VAX.  In our configuration, the host which is being
milked by the CS/1 (a Zenith Z-LAN 500 NCU) does the actual echoing, which
is exactly as we want it.  If however we were milking a host which was
not able to echo for some reason, then we would need to be able to tell
the CS/1 to send WONT ECHO in the initial TELNET parameter negotiation,
which would have the effect of forcing the VAX to echo.  In my study of
the User's Guide for the CS/1 I failed to find a way to get the CS/1
to do this (that doesn't mean the CS/1 *can't* do this, of course, just
that I couldn't figure out the magic words :-).

Cheers  -- Walt Haas    haas@cs.utah.ed    utah-cs!haas

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 21:53:31 GMT
From:      tmallory@PARK-STREET.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs


>  Hhmmm, you mean your hosts receive a packet on their ethernets and
>don't record the mapping of source ethernet and IP addresses in their ARP
>caches?  Doesn't sound like a very good idea to me.  I'd say there's
>probably a pretty good chance you're going to have to send a packet back
>to any host you receive one from ...

While it this would help a lot with the traffic associated with the broadcast
pings, recording, or at least checking, the IP/hardware address mapping for
the source of every IP packet received seems wasteful, since it's purpose is
to save an infrequent ARP request.  If I receive 10000 packets from the same
host, I'm not sure I want to check the logical/hardware mapping table every
single time.  Also, there is the problem that the source address in the IP
header may well not match the source hardware address if the packet has been
sent through a gateway.  OK, so you only insert the mapping if the network
number matches the attached network.  But some hosts support multiple network
numbers for the same network, so the packet might still have come from a
gateway...  This gets complicated, and the layering isn't very pretty.  I
don't think many hosts do it, but I'd be happy to hear otherwise.

Tracy

PS: If a host wants to match IP source addresses with particular hardware
addresses for some limited flavor of security, then my main objection is moot.

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 23:09:35 GMT
From:      hans@umd5.umd.edu (Hans Breitenlohner)
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon p4200 Packet Drop Rates

In article <8809211412.AA08336@ucbvax.Berkeley.EDU> KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) asks about packet drop rates for p4200s.

You did not state what software you are running.  If you are running 7.4,
or if you are running 8.0 and did not change the defaults for ARP timers,
the p4200 will flush its ARP entry periodically (I think every 5 minutes),
and in the process of needing to do a new ARP a packet will get lost.
You did not say how fast you were sending packets, but 1 in 5000 sounds
about right for that scenario.

If you are running the level 8.0 software you can use the ENABLE AUTO-REFRESH
command in the ARP configuration section to make this problem disappear.

Other than this I can't think of any reason why you should lose any packets
in your simple setup.

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 88 23:52:56 GMT
From:      gregg@quintus.UUCP (W. Gregg Stefancik)
To:        comp.protocols.tcp-ip
Subject:   SLIP for the Sequent

Does anyone have SLIP running under DYNIX 3.0.12?  I have tried compiling
the SLIP distribution from UUNET, but it dies a horrible death.

Gregg Stefancik
Quintus Computer Systems
sun!quintus!gregg
gregg%quintus.com@sun.com

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 88 05:30:48 GMT
From:      emv@mailrus.cc.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Proteon p4200 Packet Drop Rates

In article <8809211412.AA08336@ucbvax.Berkeley.EDU> KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) writes:
>Running the MIT/CMU PC/IP Ping between the two PS/2's continuously
>I see packet losses (i.e. response timeouts) on the order of 1 in
>every 2500 ping requests (or 1 every 5000 packets - 1 packet for the
>request, one for the response). There is no other traffic, etc on

it could be that the drops are happening on the pc, not at the
proteon.  try it out with the ka9q pinger as well to isolate 
software/hardware differences on the pc end.  Which ether card
are you using?

I trust proteons more than I trust the MIT/CMU PC/IP.

--Ed

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1988 10:45-EDT
From:      CERF@A.ISI.EDU
To:        linus!news@GATECH.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Batch Processing -- via SMTP...
The big problem with batch via SMTP is authenticating that the
sender has privileges to use the target resources - one
presumably doesn't like to leave passwords en clair in SMTP
traffic.

Vint
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Sep 88 14:29:09 PDT
From:      braden@venera.isi.edu
To:        "tcp-ip@SRI-NIC.ARPA"@Sun.COM, bridge2!fjd@Sun.COM
Cc:        bridge2!sjl@Sun.COM
Subject:   Re: ICMP's & IP src addrs
	
	Can we reach some consensus on this issue, and perhaps issue the  result-
	ing statements in an enhanced RFC?  Or is it already part of the Host Re-
	quirements RFC (where can I get a copy?).
	
Anonymous FTP from host venera.isi.edu with pathname:
   pub/ietf-hosts.rfc.txt
   
It is 150+ pages.


Bob Braden
	
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 88 14:45:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Batch Processing -- via SMTP...

The big problem with batch via SMTP is authenticating that the
sender has privileges to use the target resources - one
presumably doesn't like to leave passwords en clair in SMTP
traffic.

Vint

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 88 18:22:47 GMT
From:      dupuy@douglass.columbia.edu (Alexander Dupuy)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast pings


As someone pointed out earlier, if responses to broadcast ICMP packets are
disallowed, we'll have to come up with a new way of determining the network
mask.  But it is true that if all the hosts on a network respond, you have
instant congestion.

Perhaps a compromise is in order.  Leave the requirement that hosts not respond
to broadcast ICMP packets, but make a specific exception for gateways (what
does the gateway requirements RFC say about this?) saying that they may respond
to properly formed broadcast ICMP packets.  Presumably, the number of gateways
on a net is much less than that of hosts, so the congestion problem is not too
great.  And if you have a need to determine your netmask, you ought to have a
gateway on the net (what's the point of subnetting a standalone net?).

Is this too simple to really work?

@alex
-- 
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuy

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 88 19:01:42 GMT
From:      paul@unisoft.UUCP (n)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: TCP/IP via SuperMac CommCard on a Mac II

In article <5298@wolfen.cc.uow.oz> david@wolfen.cc.uow.oz (David Wilson) writes:
>
>The localtalk for the MacII running A/UX is provided by a SuperMac
>CommCard. This allows A/UX users to spool printouts to the laserwriter.
>If a mac user on the localtalk network wishes to login to the A/UX
>system using telnet he goes via the KFPS-3 onto the ethernet and into
>the Mac II.

	I designed the CommCard and did all the software .....

>Question 1:	Has anyone implemented a layer of software that would
>		allow the CommCard to appear as though it were an ethernet
>		card so that telnets to this machine would not need to
>		go out onto the ethernet [and presumably let a MacII
>		running A/UX to be networked without an ethernet card].
>		This software would encapsulate TCP/IP inside Appletalk
>		packets as well as allowing utilities such as ifconfig to
>		be used.

	Yes ... this all works now, 'in the lab', it needs to be 'productised'
	the main piece of work required to be done is to make a 'nice' system
	installation script that is straight forward for even naive users,
	this is VERY difficult, they have to have their hands held through
	IP addresses (and their translations to Appletalk addresses) etc
	(probably the nicest thing about Appletalk is that users don't have
	to do anything like this ... so this is what they expect)

	One nice thing you get from this is the ability to log into A/UX
	over Appletalk using NCSA Telnet using only LocalTalk cabling ....
	this seems to be what most people want ...

>Question 2:	If such a layer of software were written, would it then be
>		possible for a MAC II with both interfaces to replace the
>		KFPS altogether, performing routing between the Localtalk
>		and ethernet networks?

	Yes - this also works, it's not a cost effective replacement for
	a K-box (who wants to buy a Mac II, A/UX and a CommCard, a K-box
	or gatorbox is much cheaper and just sits in the corner out of the
	way).

	I've also done an EtherTalk interface for the CommCard system (using
	the Apple Ethernet board, so you can do gateways but I'm waiting
	for that interface to settle down).


		Paul Campbell	

-- 
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca
	E-mail:		..!{ucbvax,hoptoad}!unisoft!paul  
Nothing here represents the opinions of UniSoft or its employees (except me)
"Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 88 22:59:05 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the tty of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   SLIP for MIPS-M/1000?

Anyone hava SLIP running on a MIPS-M/1000 series machine under
UMIPS-BSD 2.1 (i.e. the MIPS port of 4.3bsd)?

Geoff Goodfellow
Anterior Technology
{ames,decwrl,pyramid,sun,uunet}!fernwood!Geoff
Geoff%fernwood.mpk.ca.us@decwrl.dec.com
-------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 88 02:09:42 GMT
From:      phri!roy@rutgers.edu  (Roy Smith)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: broadcast pings
dupuy@douglass.columbia.edu (Alexander Dupuy) writes:
-> Leave the requirement that hosts not respond to broadcast ICMP packets,
-> but make a specific exception for gateways [...] if you have a need to
-> determine your netmask, you ought to have a gateway on the net (what's
-> the point of subnetting a standalone net?).

	What if your gateway is down?  Just because you're cut off from the
rest of the world doesn't mean you should be prevented from booting your
diskless nodes.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      SUN 25 SEP 1988 13:58:14 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*13.58.10 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0015; Sun, 25 Sep 88 13:58:02 CST
Received: by BYUADMIN (Mailer X1.25) id 3530; Sun, 25 Sep 88 11:40:23 MDT
Date:         Tue, 20 Sep 88 17:07:00 EST
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
From:         "Mark D. Eggers (219) 239-7258"
              <CF4A8X%IRISHMVS.BITNET@CORNELLC.CCS.CORNELL.EDU>
Subject:      Network configuration document
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

I would also like a copy. I only received the third part of
it (subsequently eaten by a power outage/disk crash) via
BITNET.  Sending it to my internet address would probably
work much better.

It is:

eggers@dirac.cc.nd.edu

Thanks - /mde/
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      SUN 25 SEP 1988 13:58:22 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      SUN 25 SEP 1988 14:04:06 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*14.04.01 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0072; Sun, 25 Sep 88 14:03:53 CST
Received: by BYUADMIN (Mailer X1.25) id 3940; Sun, 25 Sep 88 13:01:39 MDT
Date:         Tue, 20 Sep 88 12:09:08 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Larry Backman
              <necntc!dandelion!ulowell!interlan!backman@AMES.ARC.NASA.GOV>
Subject:      Re: Installing TCP-IP on a CTIX unix system
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

> typically over Ethernet.  The group I'mm in just aquired a CTIX mini-mainframe
> running UNIX with WEST-coast TCP-IP software.  We are located in Raleigh, NC
> and need the East Coast version.  Supposedly the company or someone is getting
> this for us....but that was a month ago.  Do public domain versions exist of
> this software for our Convergent Technologies system...or where could I
> purchase such a package?


    []

    Watch out for that WEST-coast TCP; it goes into TIME-WARP state
    east of the Mississippi! -):


                    Larry Bacman
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      SUN 25 SEP 1988 14:23:15 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*14.23.10 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0099; Sun, 25 Sep 88 14:23:13 CST
Received: by BYUADMIN (Mailer X1.25) id 4112; Sun, 25 Sep 88 13:20:58 MDT
Date:         Wed, 21 Sep 88 05:52:49 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Darren Griffiths
              <pasteur!helios.ee.lbl.gov!lace.lbl.gov!dagg@UCBVAX.BERKELEY.EDU>
Subject:      Re: Multiple TCP/IP servers on one host
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

In article <8809151736.AA01161@fji.isi.edu> prue@VENERA.ISI.EDU writes:
>>>  1)  If the second path was 25% of the speed of the first path then 25% of
>>>      the packets could be sent that way.  [...]
>>>      if the two end sides were running the Van Jacobsen/Mike Karels code
>>>      I believe this wouldn't be to much of a problem.  [...]
>>
>>
>>The first thing (splitting load among routes) would screw up the
>>Jacobson/Karels improved TCP completely.  They get a big win by
>>estimating the variance of the round trip time; using alternating
>>routes for different packets would drive this variance way up, causing
>>the timeout to be set high, causing long stoppages on lost packets.
>
>I disagree.  The first path is four times as fast but has four times as
>many packets.  The link delay is only 1/4 the second line but the queuing
>delay is four times as great.  The variation of the delivery times for the
>five packets would be less than using a single line.  As the queue sizes go
>up the variation in the network delay goes up.
>
>I do however agree with your other point, type of service routing could
>put the second path to very good use.

The first time I thought out loud about routing through two different paths
I did mention that it may mess up the van/mike tcp code.  Fortunately this
was at the SIGcomm conference in Stanford and Van wasn't far away.  He
quickly set me straight and with a little extra thought it is fairly obvious
that the code would stabalize around the acks of the faster line.

A couple of people have mentioned that instead of looking for well known ports
to decide whether to use a fast line or not that the TOS field should be used.
I agree, this would be much better, but I decided to watch a couple of packets
go by on the local LBL net.  I didn't look to long, but I found very few
things actually touch that field.

Another possible thing to do would be to try and figure out which link is the
fastest, if it has one line that is 25% the speed of a second line then the
router could simply send 25% of the packets down the slow connection and the
rest along the fast connection (perhaps using a random number to see which line
the packet is going to go along.)  I seem to remember that someone wrote a
paper on this but I can't remember who of the top of my head.

It would be interesting to try different routing algorithms and see which is
the more efficient, with efficient be defined by the perceived throughput to
the user as well as the number of packets going through.  I can think of a
few methods that could be tried:

   1 -  Leave things the way they are, and just taking the fastest path.

   2 -  Choose the path depending on the TOS field, and hope someone uses it.

   3 -  Choose the path based on the port (TELNETs go the fast way, SMTP goes
        the slow way.)

   4 -  Send a percentage of the packets down one path and the rest down
        another.


Can anyone think of any others?  Perhaps when I have some free time I'll do a
couple of tests and see what I come up with.


  Cheers,
     --darren


-------------------------------------------------------------------------------
Darren Griffiths                                          DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      SUN 25 SEP 1988 16:30:52 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*16.30.49 FROM: Invalid user/address string
*16.30.49 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0351; Sun, 25 Sep 88 16:30:42 CST
Received: by BYUADMIN (Mailer X1.25) id 4729; Sun, 25 Sep 88 15:28:51 MDT
Date:         Tue, 13 Sep 88 04:44:35 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     <Parser> W: Invalid RFC822 field -- "(ANTHONY". Rest of header
              flushed.
From:         voder!pyramid!prls!philabs!crpmks!gaboon!stpstn!aad
              @UCBVAX.BERKELEY.EDU
To:           jeff consoer <CC57000@SDSUMUS>

In article <348@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the
 top) writes:
>     "Apple's interest in TCP/IP will legitimize the protocol in much
>     the same manner that A/UX legitimized UNIX," said Vint Cerf,
>     Vice President of ... a nonprofit thinktank in Reston VA.

This is remarkably similar to the DG ad described in "Soul of a New Machine"
which said something like "IBM says its entry into the minicomputer market
will legitimize it.  The bastards say 'Welcome.'", which I howled over.
Of course, to this day, the best use I've seen for an IBM mini is the
Series/1 at CMU's ITC that works the badge readers and the Coke machine.
Saying that A/UX legitimized unix would be like saying that our sun ipc board
legitimized msdos.....
--
@disclaimer(Any concepts or opinions above are entirely mine, not those of my
        employer, my GIGI, or my 11/34)
beak is                                  beak is not
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 88 15:46:15 GMT
From:      XBR1D86Q@DDATHD21.BITNET (FB4-ACCOUNT)
To:        comp.protocols.tcp-ip
Subject:   UCB Remote Lineprinter Protokoll ?

Im am looking for a description of the UCB remote lineprinter protokoll
to talk to a rlprdaemon from a non BSD Unix machine.

[D
Can anyone send me a description of that protokoll or even a
C-program to talk to the rlprdaemon ?

Thanks in advance!

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Sep 88 16:46:15 +0100 (Central European Time)
From:      XBR1D86Q%DDATHD21.BITNET@CUNYVM.CUNY.EDU (FB4-ACCOUNT)
To:        tcp-ip@sri-nic.arpa
Subject:   UCB Remote Lineprinter Protokoll ?
Im am looking for a description of the UCB remote lineprinter protokoll
to talk to a rlprdaemon from a non BSD Unix machine.

[D
Can anyone send me a description of that protokoll or even a
C-program to talk to the rlprdaemon ?

Thanks in advance!

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      MON 26 SEP 1988 02:57:07 CDT
From:      RDMAILER <$EMD000%SDSUMUS@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable Mail

The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP  @SRI-NIC.ARPA

*02.57.05 FROM: Invalid user/address string

-----------------------------  ORIGINAL MESSAGE  -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 1231; Mon, 26 Sep 88 02:57:06 CST
Received: by BYUADMIN (Mailer X1.25) id 6590; Mon, 26 Sep 88 01:53:09 MDT
Date:         Mon, 26 Sep 88 02:04:43 GMT
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments:     Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From:         Ross Patterson
              <elbereth.rutgers.edu!hardees.rutgers.edu!patterso@RUTGERS.EDU>
Subject:      re: Batch Processing -- via SMTP....
X-To:         tcp-ip@sri-nic.arpa
To:           jeff consoer <CC57000@SDSUMUS>

Craig,

   The experience of the BITNET "LISTSERV" mail manager bears out your
observations from the Info server. Many's the time we've wished for an
explicitly defined address to direct errors towards, rather than
relying on the mail system's implementors to grasp the vagueries of
RFC822's From: and Sender:; RFC821's MAIL FROM:, and the interaction
between them all. We've even found some mailers that use Reply-to: as
an error target! LISTSERV has the unenviable status of both a mail
originator (for the discussion groups it manages), and a batch processor
(for the various commands it accepts (subscription requests, file
retrievals, database search, etc.), causing it even further grief.

One mail-based batch processor I'm aware of, which provides access to
an otherwise online computer conference, explicity codes a "Reply-to:
Garbage@Garbage (Don't REPLY to this message)" to avoid the problem.

Ross Patterson
Rutgers University
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 02:04:43 GMT
From:      patterso@hardees.rutgers.edu (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   re: Batch Processing -- via SMTP....

Craig,

   The experience of the BITNET "LISTSERV" mail manager bears out your
observations from the Info server. Many's the time we've wished for an
explicitly defined address to direct errors towards, rather than
relying on the mail system's implementors to grasp the vagueries of
RFC822's From: and Sender:; RFC821's MAIL FROM:, and the interaction
between them all. We've even found some mailers that use Reply-to: as
an error target! LISTSERV has the unenviable status of both a mail
originator (for the discussion groups it manages), and a batch processor
(for the various commands it accepts (subscription requests, file
retrievals, database search, etc.), causing it even further grief. 

One mail-based batch processor I'm aware of, which provides access to
an otherwise online computer conference, explicity codes a "Reply-to:
Garbage@Garbage (Don't REPLY to this message)" to avoid the problem.

Ross Patterson
Rutgers University

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 02:05:22 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.dcom.lans,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Problems with NCSA Telnet 2.2


	I've got a Mac-II with a Kinetics EtherPort-II card.  Using NCSA
Telnet 2.1e, I can connect to hosts on my ethernet without any problems.
Using the same config.tel file, if I try to connect using Telnet 2.2, I get
a "Couldn't connect to: ..." dialog box followed by a "Local host or
gateway not responding" box.  2.2 works fine using the LocalTalk connection
(though a FastPath running kip).  Anybody have any guess what might be
wrong?

	When I run Van Jacobson's tcpdump on a sun, watching the Mac's
ethernet address, what I see is:

Script started on Wed Sep 21 17:04:13 1988
alanine% su
Password:
alanine# tcpdump -e esrc '8:0:14:90:22:88'

17:05:14.97  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2200 0000
17:05:15.37  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2200 0000
17:05:15.77  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2200 0000
17:05:16.17  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2200 0000

17:05:20.77  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:22.27  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:23.75  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:25.25  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000

17:05:49.63  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:51.13  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:52.63  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:05:54.11  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000

17:06:27.17  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:06:28.67  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:06:30.17  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000
17:06:31.65  8:0:14:90:22:88 ff:ff:ff:ff:ff:ff 809b   60: ff4c 0200 2500 0000

^Calanine# ^D  alanine% 
script done on Wed Sep 21 17:12:04 1988

	The first 4 packets came all in a bunch as soon as I launched
Telnet.  After that, I got 4 packets with about 1 second between them each
time I tried to open a connection.  I've manually inserted blank lines to
delimit each set of 4 packets.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 03:47:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Class A Logical Host Addressing


/* Written  8:47 am  Sep 15, 1988 by hassler@asd.wpafb.af.MIL in p.cs.uiuc.edu:comp.protocols.tcp-ip */
/* ---------- "Class A Logical Host Addressing" ---------- */
A few quick questions concerning Logical Host addressing:

First, is anyone using this currently? I know of  the  definition
of how it is to be done on the X25 connections to the net.

Furthermore, If a single host has two physical connections to the
net and both use the same logical address, how does the PSN route
traffic between the two links? Is it load balanced?

Barry D. Hassler
Control Data Corporation 
Integration Services Division
/* End of text from p.cs.uiuc.edu:comp.protocols.tcp-ip */

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Sep 88 13:09:19 -0400
From:      Andy Malis <malis@OAKLAND.BBN.COM>
To:        Bill Barns <barns@GATEWAY.MITRE.ORG>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Multiplexing algorithms for transport connections
Bill,

For IP over DDN Standard X.25, the most efficient (in terms of
PSN and network resources) algorithm is to multiplex all
datagrams to the same network-level destination over the same
X.25 VC, requesting the largest packet size (up to 1024 octets)
supported by your host.  This is the ONLY algorithm allowed by
the old End-to-End, which is still in use on the MILNET.  This
also most closely emulates the network transport of AHIP (1822)
messages, except that the window size is 7 rather than 8.

If you are on a network running the new End-to-End (the ARPANET),
your host is allowed to open more than one Standard connection to
other hosts.  You may wish to have your host measure the average
utilization of its host access line, and if it has a combination
of low access line utilization and a long queue of datagrams to a
particular destination host, then open a second VC to that host.
Note that opening multiple VCs to a destination host only wastes
resources in the PSN, network, and presumably the host, if both
of the above conditions do not apply.

The maximum number of VCs that any host may open at any one time
is configured by the network administration, so opening multiple
VCs to one destination may make it harder for your host to open
VCs to other  destinations without having to clear previously
open VCs.

Also note that the PSN clears Standard X.25 VCs that have been
idle for a period of time.  This period is also configurable by
the network administration.

Regards,
Andy Malis
BBNCC PSN Development
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 1988 13:33-EDT
From:      CERF@A.ISI.EDU
To:        voder!pyramid!prls!philabs!crpmks!gaboon!stpstn!aad@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Bastard protocol families?
What the reporter didn't mention is that I qualified the remark by
saying the the adoption of UNIX and TCP/IP by Apple legitimized these
tools for a community which had not been exposed to them before.

Obviously, TCP/IP and UNIX were considered not only legitimate but 
even de rigeur by the community that developed and propagated them.

Vint Cerf
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 13:27:51 GMT
From:      joe@NCSC.ARPA (DiBella)
To:        comp.protocols.tcp-ip
Subject:   Mailing List


Please add me to your mailing list.

Thanks...

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 1988 17:33-EDT
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Intermetworking books

I just ran across reference to another book on internetting:

Internetworking Computer Systems
John Mcconnell
Prentice Hall, 1988 $46.00

ISBN 0-13-473976-0

I haven't read it, so this is not an endorsement. In fact, has anyone
on TCP-IP read it?

Vint Cerf
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 13:50:21 GMT
From:      barns@GATEWAY.MITRE.ORG (Bill Barns)
To:        comp.protocols.tcp-ip
Subject:   Multiplexing algorithms for transport connections

I would like to hear what algorithms people are using to decide when to
multiplex Transport connections on Network connections.  The case of most
immediate interest to me is TCP/IP over DDN Standard X.25 connections.
As far as I know, there is no standard or published guideline which
would stop me from multiplexing everything (to the same Network-level
destination, of course) on a single X.25 connection; at the other extreme,
I might open a new X.25 connection for each datagram.

The same issue arises with ISO TP over X.25.  Does it follow that the same
algorithm is "best" for both cases?

The case of ISO CLNP over X.25 seems to combine the two cases above.  This
is what I understand GOSIP to specify for the future, so this case is also
interesting.

I've heard that some problems in the ARPANET transition to PSN 7.0 had to
do with this topic.  So I imagine there are some interesting issues
somewhere underlying the decisions an implementor might make, and perhaps
some interoperation problems with some choices.  I'd like to get a handle
on this whole area.  You're all invited to describe the behavior of
existing implementations or your conception of the Right Thing To Do.

Thanks in advance for all info, insights, comments, and suggestions...
Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 14:06:22 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   IP broadcast fragmentation [was: UDP max datagram size ?]

Speaking of fragmenting broadcasts, can anyone explain the rationale for
not doing this?  Is it just BSD IP which refuses to fragment them or is it
widely held to be a Bad Thing?   I don't find mention of fragmentation in
RFC 919.

	Stuart Levy, slevy@uc.msc.umn.edu

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 14:45:55 GMT
From:      ecc@CS.CMU.EDU (Eric Cooper)
To:        comp.protocols.tcp-ip
Subject:   Summary of network performance refs

A number of people asked for a summary of the responses to my request (about a
month ago)  for references to performance studies of networking
implementations.  Thank you to all who responded, and my apologies for the
delay in posting this.

                                                Eric Cooper
                                                Computer Science Department
                                                Carnegie Mellon University
--------
First, let me recommend Jeff Mogul's (mogul@decwrl.dec.com) excellent annotated
bibliography, which he distributed at SIGCOMM:

        @techreport(mogul-bibliography
          ,author="Jeffrey C. Mogul"
          ,title="The Experimental Literature of the {Internet}: An Annotated
Bibliography"
          ,type="Research Report"
          ,number="88/3"
          ,institution="DEC Western Research Laboratory"
          ,month=aug
          ,year=1988
        )

And thanks to John Riedl ({ucbvax,decvax,hplabs}!purdue!riedl or
riedl@mordred.Purdue.EDU) for the following:
--------
Here's a reference to measurements of UDP on Sun 3/50s:

        @InProceedings{ethernet-experiment,
        Author = "Bharat Bhargava and Tom Mueller and John Riedl",
        Title = "Experimental Analysis of Layered {E}thernet Software",
        BookTitle = "Proc of the ACM-IEEE Computer Society 1987
Fall Joint Computer Conference",
        Month = oct,
        Year = 1987,
        Address = "Dallas, Texas",
        Pages = "559--568"
}

Another paper I've co-authored contains measurements of two
multicasting implementations that we did (one a kernel-level
simulation, and one using Ethernet hardware multicast), and a
comparison of local-only communications methods with using UDP
locally:

@TechReport{raid-network-experiments,
        Author = "Bharat Bhargava and Enrique Mafla and John Riedl and
Bradley Sauder",
        Title = "Implementation and Measurements of an Efficient
Communication Facility for Distributed Database Systems",
        Institution = "Purdue University",
        Month = jun,
        Year = 1988,
        Number = "CSD-TR-783",
        Note = "Submitted for publication"
}

Lazowska et. al. discuss communications performance as a side issue:

@Article{file-access-performance,
        Author = "Edward D. Lazowska and John Zahorjan and David R.
Cheriton and Willy Zwaenepoel",
        Title = "File Access Performance of Diskless Workstations",
        Journal = tocs,
        Year = 1986,
        Month = aug,
        Volume = 4,
        Number = 3,
        Pages = "238--268"
}

Zwaenepoel implements blast, stop-and-wait, and sliding window data
transfer protocols on Suns.  His measurements are non-standard in that
he avoids crossing the kernel/user boundary, but he has some
interesting things to say:

@InProceedings{large-transfers,
        Author = "Willy Zwaenepoel",
        Title = "Protocols for Large Data Transfers over Local
Networks",
        BookTitle = "Proceedings of the 9th Data Communications
Symposium",
        Address = "Whistler Mountain, British Columbia, Canada",
        Month = sep,
        Year = 1985,
        Pages = "22--32"
}


I'm pretty sure that the V article in the March CACM makes some
mention of Unix datagram performance.  At the least, I'm pretty sure
they mention a Unix implementation of VMTP:

@Article{V-cacm,
        Author = "David R. Cheriton",
        Title =  "The V Distributed System",
        Year = 1988,
        Month = mar,
        Volume = 31,
        Number = 3,
        Journal = cacm
}

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 16:44:02 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

>>Now wait a minute....It's one thing to reply to the local IP broadcast
>>address - it's another thing to use the Ethernet broadcast address as
>>your source address!  DEC Lanbridges don't look at anything higher than
>>that.  They should ignore multicast/broadcast addresses as a source
>>address (although I don't really know if they do).
>>
>Doug Nelson
>Michigan State University

If you have LANBridges with version 2 of their software then it is
true that they can be got into the state where no broadcasts go
through (but multicasts are OK).
This bug was not in version 1.0. Of course, both versions had bugs if
you use RBMS to change costs of lines, bridges etc.
The broadcast problem certainly is provoked if the LANBridge sees a
packet whose source address is ffffffffffff. To clear it the bridge
has to be reinitialised.
The symptoms are obvious: new tcp/ip connections fail, but old
connections, plus ones where the ethernet address is already in cache,
continue to work, as does DECNET. Thus, all the people with Vaxstations
do not want the Ethernet touched, for fear that their station will need
rebooting, but all the TCP/IPersons want it fixed. How to become
unpopular in one easy lesson!
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 17:09:19 GMT
From:      malis@OAKLAND.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiplexing algorithms for transport connections

Bill,

For IP over DDN Standard X.25, the most efficient (in terms of
PSN and network resources) algorithm is to multiplex all
datagrams to the same network-level destination over the same
X.25 VC, requesting the largest packet size (up to 1024 octets)
supported by your host.  This is the ONLY algorithm allowed by
the old End-to-End, which is still in use on the MILNET.  This
also most closely emulates the network transport of AHIP (1822)
messages, except that the window size is 7 rather than 8.

If you are on a network running the new End-to-End (the ARPANET),
your host is allowed to open more than one Standard connection to
other hosts.  You may wish to have your host measure the average
utilization of its host access line, and if it has a combination
of low access line utilization and a long queue of datagrams to a
particular destination host, then open a second VC to that host.
Note that opening multiple VCs to a destination host only wastes
resources in the PSN, network, and presumably the host, if both
of the above conditions do not apply.

The maximum number of VCs that any host may open at any one time
is configured by the network administration, so opening multiple
VCs to one destination may make it harder for your host to open
VCs to other  destinations without having to clear previously
open VCs.

Also note that the PSN clears Standard X.25 VCs that have been
idle for a period of time.  This period is also configurable by
the network administration.

Regards,
Andy Malis
BBNCC PSN Development

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 17:33:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Bastard protocol families?

What the reporter didn't mention is that I qualified the remark by
saying the the adoption of UNIX and TCP/IP by Apple legitimized these
tools for a community which had not been exposed to them before.

Obviously, TCP/IP and UNIX were considered not only legitimate but 
even de rigeur by the community that developed and propagated them.

Vint Cerf

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 20:41:25 GMT
From:      irab@amtfocus.UUCP (Ira Brenner)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need TCP/IP support for 3C505 card

After many a days effort spent trying to get my PC's up on my network,
I am looking for some new information. We currently have a TCP/IP net
with many different systems up and operational. Unfortunately we can
not seem to get our PC's working correctly. We have 3Com 3C505 boards,
about a year old, and Wollongong Groups WIN/PC product for software.
The problem is the WIN/PC software (at least the revision level we're
at) does not seem to support the 3C505 properly. I am not writing this to 
flame on Wollongong specifically, but their help in this situation has 
left much to be desired. Anyway, the real question is: are there any other 
software packages, possibly public domain, that will support the 3C505? 
Any info would be greatly appreciated.
						Thanks,
						 Ira

UUCP:{gatech, chinet, clyde}!mcdchg!amtfocus!irab

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 21:33:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Intermetworking books


I just ran across reference to another book on internetting:

Internetworking Computer Systems
John Mcconnell
Prentice Hall, 1988 $46.00

ISBN 0-13-473976-0

I haven't read it, so this is not an endorsement. In fact, has anyone
on TCP-IP read it?

Vint Cerf

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 21:44:39 GMT
From:      dfc@hpindda.HP.COM (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: What about HP/UX ARP cache and rtnet structure?

Please see my response in comp.sys.hp

Don Coolidge

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 88 22:17:48 GMT
From:      ejf@well.UUCP (Erik James Freed)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   TCP-IP libraries for Macs and ATs


 I am sure that this is an old topic but due to my only recent interest
in this I am looking to find out what TCP-IP libraries are available that
run on Pcs and Macs. I would be very appreciative of some pointers to
where to find out more... Thanks in advance.


		Erik Freed
		UUCP:well!ejf
		(415) 461-5400

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 02:04:37 GMT
From:      bae@unisoft.UUCP (Hwa Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions on IP & 802.2,3 & use or value of streams.


> 1) Anyone using IP over 802.2 LLC or 802.3 MAC layers in commerical or
> academic products? (Commercial folks are interested in having their
> products conform to "standards").

There are a few such products including one from us.  Usually it is
done by using a 802.2 LLC header with DSAP and SSAP value 170 and 
Control value 3 (unnumbered info.) along with a SNAP header to indicate
ethernet type field since the 802.3 doesn't have a type field, with
Protocol Id equal to 0.

> 2) What is ATT's streams used for: like Berkeley's sockets, to provide
> access to protocol families? Is there a "native" streams protocol or
> protocol suite? And more concrete: just like TCP/IP is being or will be
> delivered with streams, are there other protocol suits available
> (commerically or otherwise) with a streams interface?, say ISO's?

STREAMS provides a general environment to implement a networking protocol
or device drivers.  Several implementations use STREAMS different ways to
implement TCP/IP.  Some are straight ports of 4.3 BSD TCP/IP with additional
code for multiplexing modules at TCP and IP levels.  At LLC level these
implementations usually use another module that understand M_PROTO messages
of various kinds that sort of simulates (implements) 802.2 like services
to be used by upper layer module (IP multiplexor).  Others (like ours)
work different way but in general STREAMS implementations do try to follow 
the "standard" stacks as closely as possible for better or worse.  
There are some interesting issues involved in optimizing flow control 
algorithms with STREAMS based protocol implementations.

/hjb
-- 
I only speak for myself.
Hwa Jin Bae				bae@tis.llnl.gov	(Internet)
UniSoft					bae@unisoft.UniSoft	(smail uucp)
Emeryville, CA				...!uunet!unisoft!bae	(plain uucp)

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Sep 88 08:46:43 -0400
From:      ulana@ulana.b.mitre.org
To:        tcp-ip@sri-nic.ARPA
Cc:        ulana@ulana.b.mitre.org
Subject:   U.S. Air Force Award of the ULANA Contract


     The Electronic Systems Division (ESD) of the U.S. Air Force 
is pleased to announce the award of the Unified Local Area 
Network Architecture (ULANA) contracts.  The ULANA contracts 
consist of a integration and test contract to be managed by ESD 
at Hancsom AFB, MA, along with an Indefinite Delivery/Indefinite 
Quantity (ID/IQ) contract to be managed by Air Force 
Communication Command (AFCC) Engineering Installation Division 
(EID) at Tinker AFB, OK.  Two awards have been made: one to 
Electronic Data Systems (EDS) Corp of Bethesda, MD; and one to 
TRW Information Networks Division of Torrance, CA.

     ULANA represents a major advance in Air Force networking as 
it establishes an Air Force standard for Local Area Networks.  
The ULANA program is providing the vehicle to purchase the 
components and engineering services to assist in integration, 
while the computer systems and LAN media will be provided under 
existing AF contracts.  

     The ULANA program will provide a full range of LAN equipment 
for Air Force use.  Over 200 different LAN components and related 
engineering services with a maximum value of approximately $150 
million will be orderable under the ULANA contracts.  

     The ULANA program will provide standardized Local Area 
Networking components based on the IEEE 802.3 standard and the 
DoD suite of protocols (TCP/IP, Telnet, FTP, SMTP, UDP, ICMP) The 
components available from the ULANA contract will minimize 
"unique" LAN implementations within the Air Force and permit 
interconnectivity between Air Force standard computer systems.  

     The computer systems that will be supported include Amdahl/
IBM with MVS, IBM with VM, Sperry 1100 with OS 1100, DEC Vax/
MicroVax with VMS, Zenith Z-150, Z-200, Z-248, IBM XT, IBM AT 
Sperry PC40 with MS DOS and Xenix, Cromemco CS-220 with UNIX, 
Gould 9050 with UTX 32, Honeywell with GCOS and NCR WS3000/
Burroughs XE520 with CTOS/BTOS.  

     Other equipment provided under the ULANA contract include 
terminal servers, bridges, DDN gateway, LAN encryption and 
media attachment units.  The media supported by the ULANA 
components include baseband (both 10base2 and 10base5), dual 
cable broadband, single cable broadband, fiber, and twisted pair.  

     The initial test and integration contracts will be conducted 
at a testbed located at Gunter AFB, Alabama.  The test phase will 
last eight months during which an Approved Products List (APL) 
will evolve.  After the products have been qualified and placed 
on the APL, the components will then be orderable through the EID 
by Air Force users.  The dual award will provide a much larger 
selection of similar components to better fit each user's needs.
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 03:45:20 GMT
From:      casey@admin.cognet.ucla.edu (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP's & IP src addrs

In article <8809270020.AA01343@ucbvax.Berkeley.EDU>
 tmallory@PARK-STREET.BBN.COM writes:
> In some article or another I write:
> >   Hhmmm, you mean your hosts receive a packet on their ethernets and
> > don't record the mapping of source ethernet and IP addresses in their ARP
> > caches?  Doesn't sound like a very good idea to me.  I'd say there's
> > probably a pretty good chance you're going to have to send a packet back
> > to any host you receive one from ...
> 
>   Also, there is the problem that the source address in the IP header may
> well not match the source hardware address if the packet has been sent
> through a gateway.  OK, so you only insert the mapping if the network
> number matches the attached network.  But some hosts support multiple
> network numbers for the same network, so the packet might still have come
> from a gateway...  This gets complicated, and the layering isn't very
> pretty.  I don't think many hosts do it, but I'd be happy to hear
> otherwise.

  No, you're right.  And me a proponent of lazy evaluation to boot ...
And I should know better than to get snide on TCP-IP.  Actually I wasn't
really trying to be snide, but it came out that way.  Sorry.

  But, while I'm here talking about when to put entries into your ARP
cache, I'd like to describe an interesting experience I had today and see
if anyone can explain it:

  Lawrence Livermore National Laboratory has recently joined the BARRNET,
a regional NSFNET centered in the Bay Area in California.  Other members
currently include UC Berkeley, NASA Ames Research Center, Stanford, UC
Davis, and several others.  LLNL is tied into the BARRNET at two points,
UCB and NASA ARC:

	Lawrence Livermore National Laboratory
		LLNL.Gov
		NET-LLL-LABNET
		128.115

	University of California, Berkeley
		Berkeley.Edu
		NET-UCB-ETHER
		128.32

	NASA Ames Research Center
		ARC.NASA.Gov
		NET-AMES-NET
		128.102

  When I look at typical host at LLNL, mozart.llnl.gov [128.115.12.1], a
Sun 3/180 running SUN OS 3.4, I see a route to UCB-ETHER via
BARRNET-GW.llnl.gov [128.115.1.100], but no ARP cache entry for
BARRNET-GW.  Now:

  From UCB (vangogh.berkeley.edu):
	I can ping mozart.
	I can talk to the name server on mozart.
	I can telnet to the SMTP server on mozart.
	I can't telnet or rsh to mozart.
		Symptoms:  telnet goes into a connected state (at least
		it said it did) and then hangs.  No login prompt,
		nothing.  I had to escape out (^]) and quit the session.
		rsh just hangs but allows ^C's to abort it, so it hasn't
		entered a fully connected state with the remote rshd.

  On mozart.llnl.gov:
	I can ping UCB (vangogh.berkeley.edu).

  After all that testing, there's still no entry for barrnet-gw in
mozart's ARP cache.  If I ping barrnet-gw from mozart or attempt to
telnet to UCB from mozart, an entry for barrnet-gw is now in mozart's ARP
cache and suddenly telnet's from UCB to mozart work!  SUN OS 3.5 doesn't
seem to have this problem ...  Opps, nope.  Read the following paragraph.

  Unfortunately, I can't get this to happen consistently.  For instance,
I just deleted the entry for barrnet-gw from mozart's ARP cache and was
able to successfully telnet in from UCB.  I've done this three times now
in the last five minutes and I'm beginning to doubt my memory of the
first series of test this afternoon ...

  Does anyone have any idea what's going on?

Casey

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 06:23:47 GMT
From:      pf@gouldfr.UUCP (Pierre Francois Monet)
To:        comp.protocols.tcp-ip
Subject:   KA9Q under XENIX SCO &/or SYS5


Does anybody has ported the package from KA9Q under XENIX or a SYS5
system ?

If yes I would apreciate to get the Makefile and the modification to
do this port .

We are running version 871225.30 or 871225.31

Many thanks

Pierre-Francois MONET
FC1BQP
email : ...!inria!gouldfr!pmonet
tel   : (1) 34 60 61 01   work
	(1) 69 40 24 68   home
packet: F6ABJ-1@F1BQP

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Sep 88 16:57:51 PDT
From:      krm@wsc-sun.com (Keith Michaels)
To:        tcp-ip@sri-nic.arpa
Subject:   Shutting down sockets - RESPONSE
Re: Hung sockets on Apollo and VAX.

The following program releases socket connections that are left over
after a network application crashes on a VAX running Wollongong TCP/IP.
You have to know the INET: device name assigned to it -- this can sometimes 
be determined by checking the owning PID in SHOW DEV/FULL INET:.
This also seems to clean up the Apollo side at the other end of the link,
but I don't know how to do the equivalent operation from the Apollo.

/* Release unused INET: devices under Wollongong TCP/IP for VAX/VMS */
/* K. Michaels, BCS 27-Sep-1988 */

#include <stdio.h>
#include <ssdef.h>
#include <iodef.h>
#include <descrip.h>
main(ac,av)
int ac;
char *av[];
{
	int i;
	unsigned short iosb[4], chan;
	char idev[16];
	$DESCRIPTOR(idev_dsc,idev);
	if(av[1] == NULL) do {
		printf("inet device name: ");
		if(gets(idev) == 0) exit(SS$_NORMAL);
		} while (strlen(idev) == 0);
	else
		strcpy(idev,av[1]);
	idev_dsc.dsc$w_length = strlen(idev);
	i= sys$assign(&idev_dsc,&chan,0,0);
	if((i & 1) == 0) exit(i);
	i = sys$qiow(0,chan,IO$_SETCHAR,iosb,0,0,&0,0,0,0,0,0);
	if((i & 1) == 0) exit(i);
	if((iosb[0] & 1) == 0) exit(iosb[0]);
	sys$dassgn(chan);
	exit(SS$_NORMAL);
}
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 12:46:43 GMT
From:      ulana@ulana.b.mitre.ORG
To:        comp.protocols.tcp-ip
Subject:   U.S. Air Force Award of the ULANA Contract



     The Electronic Systems Division (ESD) of the U.S. Air Force 
is pleased to announce the award of the Unified Local Area 
Network Architecture (ULANA) contracts.  The ULANA contracts 
consist of a integration and test contract to be managed by ESD 
at Hancsom AFB, MA, along with an Indefinite Delivery/Indefinite 
Quantity (ID/IQ) contract to be managed by Air Force 
Communication Command (AFCC) Engineering Installation Division 
(EID) at Tinker AFB, OK.  Two awards have been made: one to 
Electronic Data Systems (EDS) Corp of Bethesda, MD; and one to 
TRW Information Networks Division of Torrance, CA.

     ULANA represents a major advance in Air Force networking as 
it establishes an Air Force standard for Local Area Networks.  
The ULANA program is providing the vehicle to purchase the 
components and engineering services to assist in integration, 
while the computer systems and LAN media will be provided under 
existing AF contracts.  

     The ULANA program will provide a full range of LAN equipment 
for Air Force use.  Over 200 different LAN components and related 
engineering services with a maximum value of approximately $150 
million will be orderable under the ULANA contracts.  

     The ULANA program will provide standardized Local Area 
Networking components based on the IEEE 802.3 standard and the 
DoD suite of protocols (TCP/IP, Telnet, FTP, SMTP, UDP, ICMP) The 
components available from the ULANA contract will minimize 
"unique" LAN implementations within the Air Force and permit 
interconnectivity between Air Force standard computer systems.  

     The computer systems that will be supported include Amdahl/
IBM with MVS, IBM with VM, Sperry 1100 with OS 1100, DEC Vax/
MicroVax with VMS, Zenith Z-150, Z-200, Z-248, IBM XT, IBM AT 
Sperry PC40 with MS DOS and Xenix, Cromemco CS-220 with UNIX, 
Gould 9050 with UTX 32, Honeywell with GCOS and NCR WS3000/
Burroughs XE520 with CTOS/BTOS.  

     Other equipment provided under the ULANA contract include 
terminal servers, bridges, DDN gateway, LAN encryption and 
media attachment units.  The media supported by the ULANA 
components include baseband (both 10base2 and 10base5), dual 
cable broadband, single cable broadband, fiber, and twisted pair.  

     The initial test and integration contracts will be conducted 
at a testbed located at Gunter AFB, Alabama.  The test phase will 
last eight months during which an Approved Products List (APL) 
will evolve.  After the products have been qualified and placed 
on the APL, the components will then be orderable through the EID 
by Air Force users.  The dual award will provide a much larger 
selection of similar components to better fit each user's needs.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 15:26:35 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.dcom.lans,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Problems with NCSA Telnet 2.2 (solved)


	I couple of days ago I reported that I was having trouble with NCSA
telnet.  The basic symptoms were that 2.1e worked fine over the ethernet,
and 2.2 worked fine over LocalTalk, but not over the ethernet.  Gaige
Paulsen pointed out the problem.  I needed to put "hardware=ether" line in
my config.tel file.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 17:41:42 GMT
From:      spector@suvax1.UUCP (Mitchell Spector)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP using Telebit Trailblazers?


   Does anyone know of an implementation of TCP/IP over telephone
lines using Telebit Trailblazers?

   I will summarize any e-mail responses to the net.

-- 
Mitchell Spector
Dept. of Computer Science & Software Engineering, Seattle University
UUCP path: ...!{uw-beaver!uw-entropy, uunet!pilchuck}!thebes!suvax1!spector
Internet address: spector%suvax1%thebes.thalatta.com@entropy.ms.washington.edu

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 18:07:13 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   How to order my Internet Bibliography

Yesterday on TCP-IP, Eric Cooper kindly recommended my recent report,
"The Experimental Literature of the Internet: An Annotated Bibliography".
DECWRL Research Report 88/3.

I've already received numerous requests for this document; to forestall
a further flood I suggest that rather than contacting me, you order it
directly, via the magic of electronic mail.  For order information, send
a message to
	wrl-techreports@decwrl.dec.com
or
	decwrl!wrl-techreports
Your message should have the word "help" on the Subject: line.  You'll
receive a lengthy description of how to order WRL Reports, either in
hardcopy (by US mail) or PostScript form (by electronic mail).  You
will also find out how to get onto our mailing list.

Since decwrl.dec.com is a busy machine, don't expect an immediate reply.
Since decwrl.dec.com is, after all, a machine, if you can't figure out
how to deal with it, I'm willing to help solve problems if you've already
tried reading the instructions.

-Jeff

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 20:51:00 GMT
From:      berger@clio.las.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP support for 3C505 card


I think NCSA Telnet 2.2 supports that card, though I've had some
problems getting it to work on some of my machines.  The software
is free, so it doesn't cost you anything to try.  Version 2.1
works fine but doesn't support a wide variety of ethernet boards.

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

			berger@clio.las.uiuc.edu
			{convex | pur-ee}!uiucuxc!clio!berger

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 22:36:57 GMT
From:      john@polyof.UUCP ( John Buck )
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Need TCP/IP support for 3C505 card

In article <157@amtfocus.UUCP>, irab@amtfocus.UUCP (Ira Brenner) writes:
>  ... We have 3Com 3C505 boards,
> about a year old, and Wollongong Groups WIN/PC product for software.
> The problem is the WIN/PC software (at least the revision level we're
> at) does not seem to support the 3C505 properly. I am not writing this to 
> flame on Wollongong specifically, but their help in this situation has 
> left much to be desired. Anyway, the real question is: are there any other 
> software packages, possibly public domain, that will support the 3C505? 

Yes, but I don't know if your luck with FTP Software, Inc. is going to
be much better!  We recently got a 3Com-523 (Micro-channel) card for
our new PS2 system.  We had an AT with a 3C505, and upgraded.  I called
FTP Inc. and asked to order the version for the 523...  They said I could
upgrade my old software for the new software for a reasonable price.
The lady told me she would ship it "right away".  That was over a month
ago.  I called FTP today, and they said that their latest product
is "on hold".  She did not know "when it would be released for shipment."
I find this very annoying, and hard to believe!  (How can they not
know when a release is going to be ready?)  However, we have been using
their older version, 1.16, and it works fine with a 3C505.  If you
plan on ordering it from them, however, be prepared to wait a loooooooooong
time, as their shipment/release policies seem lacking.
I can not comment on the 3C523 software yet, as we (obviously) do not
have it.

BTW, if you can wait for your software, FTP can be reached at: 617-868-4878

john@polyof.poly.edu [128.238.10.100]
john@polygraf.bitnet

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 88 23:27:33 GMT
From:      thadani@xyzzy.UUCP (Usenet Administration)
To:        comp.protocols.tcp-ip
Subject:   Re:  Graziano's Streams Query

In article <8809260302.AA11541@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
>One of the emerging major benefits of Streams is its utility in a
>multi-processor environment.  Properly implemented, streams modules may
>operate in DIFFERENT address spaces.  The only shared memory that is needed
>is for message-passing and data-buffers.

    This suggests that a Streams module may be written in
    a special way to run in a multi-processor environment, whereas
    perhaps it is the implementation of the Streams facility that would 
    most require careful design for multi-processor operation.  The
    modules themselves should be oblivious to the nature of the cpu/s,
    especially if the advantages of standardization are to be maintained
    (given that the existing Streams specification from AT&T do not 
    allow for multi-processor operation).

    It would be interesting to know of approaches taken to implement
    Streams for multi-processor operation.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Sep 88 07:27:44 PDT
From:      Sol Lederman <SOL@SRI-NIC.ARPA>
To:        dji@sbcs.sunysb.edu
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Info about UDP please
Dave,

The UDP specificiation is in RFC-768. It is available from the SRI-NIC.ARPA
host via the file transfer program (FTP). Within FTP log in as user ANONYMOUS
with password GUEST. Retrieve the file RFC:RFC768.TXT. The TCP specification,
which will be helpful in understanding how TCP and UDP differ as transport
protocols, is in RFC-793. The file to retrieve is RFC:RFC793.TXT. A third
useful file to retrieve is RFC:RFC-INDEX.TXT. It provides RFC titles and
corresponding RFC numbers, among other things. (You do need to know what
acronyms stand for to make the best use of the index. (TCP = Transmission
Control Protocol, UDP = User Datagram Protocol.)) One other source of
information about the two protocols, and about TCP/IP in general, is Doug
Comer's new book, Internetworking with TCP/IP, 1988, Prentice Hall, ISBN
0-13-470154-2.

If you have any questions about acquiring NIC documents, or if you need
help retrieving files via FTP, or if you would like more pointers to TCP/IP
information feel free to contact NIC@SRI-NIC.ARPA.

Sol/NIC

p.s. TCP-IP-REQUEST is the NIC mailbox for administration of the list. (I.e.
messages asking to be placed on or removed from the tcp-ip list go to that
address.) Messages intended for the entire readership go to 
TCP-IP@SRI-NIC.ARPA.
-------
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Sep 88 08:12:46 MDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        topolcic@vax.bbn.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  New IETF working group
...[ST is currently being implemented in the Butterfly Internet Gateway.
Conferencing may become more popular and include other media as ST is brought
up in a larger number of gateways.]...

Why would you have to implement ST in a Gateway?  Or, are is IP on the
way out?  Or, are we talking, implementing TOS?
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 88 15:40:00 GMT
From:      joel@VAX.FTP.COM (Joel Gartland)
To:        comp.protocols.tcp-ip
Subject:   (none)


Hey,
	I've just started working with rlogin and encountered a small problem
that i believe is quite simple, and is probably caused by my not too sizable
knowledge of rlogin. The problem is thus: I am rlogin-ing to a few hosts and
some of them, after they've been sent the username for server & client, term
type and baud rate, are sending the sequence 0x80, 0x90, 0xA0, each in separate
packets.
	I figure that their sending these values is correct, but what are the
significance of these values? Any help or pointers toward current, correct
documentation of rlogin is greatly appreciated. 

				Thanks very much,
						 Joel Gartland
						 FTP Software

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 88 17:07:00 GMT
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   ARP Problems

Hello-


I am trying to get CMU V6.3 running on a MicroVAX II VMS 4.7. I can not
TELNET to any other node on the network except the MicroVax itself.

The next step was to enable NETLOG and set the ARP,PHY and IP flags to see what
was going on. It appears that ARP is receiving the Ethernet address of the
node I want to TELNET to. However, the received Ethernet address of the node
I want to TELNET to, is NOT associated with the proper internet address. As
shown below, the destination Ethernet address is being associated with
an internet address of 0.0.0.0! Any help would be greatly appreciated.

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


	Example:

	$ netstat/arp

	CIDX  DEV	IP Address	Physical Address
	  0    0         0.0.0.0	AA-00-04-00-63-04
		         192.12.216.4   00-00-00-00-00-00

	(192.12.216.4 is the destination internet address and AA-00-04-63-04
	 is the destination Ethernet address)


	$ ty inet$log

11:22:27.23 Logging enabled

11:22:27.27 Log event mask set to 00000007

11:22:28.17 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:29.72 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:29.73 IPrecv: S=192.12.216.4,D=192.12.216.5,HL=5,PR=17,TL=72,ID=4367,
FL=0,FR=0
	    IPrecv: HDR=00039D50,DATA=00039D64

11:22:29.75 XE IP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:29.75 IPrecv: S=192.12.216.4,D=192.12.216.5,HL=5,PR=17,TL=72,ID=4368,
FL=0,FR=0
	    IPrecv: HDR=0003A1C0,DATA=0003A1D4

11:22:29.76 XE ARP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:30.63 XE IP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:33.09 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:33.85 IPSend: S=192.12.216.5,D=192.12.216.4,HL=5,PR=6,TL=44,ID=61,FL=0,
FR=0
	    IPSend: HDR=00032A34,DATA=00032A48

11:22:33.86 ARP RQ XMIT: IP=192.12.216.4, PHY=31-32-2E-32-31-36

11:22:33.86 XE ARP xmit: IP=0.0.0.0, PHY=FF-FF-FF-FF-FF-FF

11:22:33.89 IPSend: S=192.12.216.5,D=192.12.216.5,HL=5,PR=17,TL=71,ID=59,FL=0,
FR=0
	    IPSend: HDR=00032CA4,DATA=00032CB8

11:22:33.89 IPsend: route is 0.0.0.0

11:22:33.90 IPrecv: S=192.12.216.5,D=192.12.216.5,HL=5,PR=17,TL=71,ID=59,FL=0,
FR=0
	    IPrecv: HDR=00032CA4,DATA=00032CB8

11:22:34.75 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:34.76 IPrecv: S=192.12.216.4,D=192.12.216.5,HL=5,PR=17,TL=72,ID=4372,FL=0
,FR=0
	    IPrecv: HDR=0003AF10,DATA=0003AF24

11:22:34.77 XE IP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:34.78 IPrecv: S=192.12.216.4,D=192.12.216.5,HL=5,PR=17,TL=72,ID=4373,
FL=0,FR=0
	    IPrecv: HDR=0003B380,DATA=0003B394

11:22:34.84 XE ARP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:35.54 XE IP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:38.00 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:38.88 IPSend: S=192.12.216.5,D=192.12.216.5,HL=5,PR=17,TL=71,ID=60,FL=0,
FR=0
	    IPSend: HDR=00034024,DATA=00034038

11:22:38.89 IPsend: route is 12.26.3.0

11:22:38.90 IPrecv: S=192.12.216.5,D=192.12.216.5,HL=5,PR=17,TL=71,ID=60,FL=0,
FR=0
	    IPrecv: HDR=00034024,DATA=00034038

11:22:39.10 IPSend: S=192.12.216.5,D=192.12.216.4,HL=5,PR=6,TL=44,ID=62,FL=0,
FR=0
	    IPSend: HDR=000353A4,DATA=000353B8

11:22:39.11 ARP RQ XMIT: IP=192.12.216.4, PHY=00-00-00-00-00-00

11:22:39.12 XE ARP xmit: IP=0.0.0.0, PHY=FF-FF-FF-FF-FF-FF

11:22:39.77 XE IP receive: IP=0.0.0.0, PHY=00-DD-00-DB-BD-00

11:22:39.77 IPrecv: S=192.12.216.4,D=192.12.216.5,HL=5,PR=17,TL=72,ID=4376,
FL=0,FR=0
	    IPrecv: HDR=0003C0D0,DATA=0003C0E4

11:22:40.46 XE IP receive: IP=0.0.0.0, PHY=AA-00-04-00-D3-04

11:22:40.63 Logging disabled

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

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 88 19:58:35 GMT
From:      tim@hoptoad.uucp (Tim Maroney)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   Re: TCP-IP libraries for Macs and ATs

In article <7219@well.UUCP> ejf@well.UUCP (Erik James Freed) writes:
>
> I am sure that this is an old topic but due to my only recent interest
>in this I am looking to find out what TCP-IP libraries are available that
>run on Pcs and Macs. I would be very appreciative of some pointers to
>where to find out more... Thanks in advance.
>
>		Erik Freed
>		UUCP:well!ejf
>		(415) 461-5400

Sun/TOPS has got both.  I wrote "TOPS TCP/IP" for the Macintosh last year,
and it should theoretically be available through the TOPS Developer Program.
Brent Noorda did some TCP/IP work on the PC as well, but I don't think it's
been broken out of his terminal program for others to use.  Sun used another
PC TCP/IP for their earlier client-only MS-DOS version of NFS; I don't know
about its availability.

Apple has announced they will have a TCP/IP, as reported in a recent MacWeek.
It was developed by the University of Michigan, primarily.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"The time is gone, the song is over.
 Thought I'd something more to say." - Roger Waters, Time

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 88 22:11:13 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   revised protocol bibliography available

The DDN Network Information Center has revised its bibliography of recent
articles and books pertaining to TCP and IP, X.25, the Transport Protocol
(TP-4), OSI and other standards. The bibliography was compiled as a background
reading list for vendors.  The bibliography cites articles, mostly from the
open literature, representing a variety of viewpoints.  It has not been
sanctioned by any government agency, nor does it contain references to the
Requests for Comments (RFCs).  The NIC does not provide copies of these
articles because they are readily available in the open literature.  The NIC
has copies of the DDN Protocol Handbook, the RFC index, RFCs and the OSD
(Office of the Secretary of Defense) directives pertaining to the DoD protocol
suite.

The bibliography is available via FTP (host: sri-nic.arpa, username:
anonymous, password: guest, filename: netinfo:protocols-dod.bib (text
version), netinfo:protocols-dod.ps (postscript version)). Either version may
be retrieved by electronic mail. To get the text version, for example, send a
message to SERVICE@SRI-NIC.ARPA with the words SEND NETINFO PROTOCOLS-DOD.BIB
in the subject line.

Contact NIC@SRI-NIC.ARPA if you have questions or comments or telephone
800-235-3155.
-------

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 88 23:09:10 GMT
From:      wcs@alice.UUCP (Bill Stewart)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans,comp.sys.hp,comp.protocols.iso
Subject:   Wanted: SLIP oer 9600-baud modems

I'm interested in connecting two distant TCP/IP sites with some kind
of 9600 baud modem connection or possibly x.25.  I assume the simplest
is to use slip over 9600 baud modems, but this may not be realistic.

What I've got for hardware is a couple of HP 800-series computers and
Telebit original-Trailblazer modems; I'd like to minimize additional
purchases, and working over dialup would be nice but not critical.
Has anybody tried this, and has it worked?

Thanks;  Bill Stewart, ho95c.att.com!wcs AT&T Bell Labs Room 2G218, Holmdel NJ

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 00:57:00 GMT
From:      ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre)
To:        comp.protocols.tcp-ip
Subject:   Re:  NIC host considered hero

In article <8809132204.AA01771@braden.isi.edu> braden@VENERA.ISI.EDU writes:
>Dave,
>
>To qoute from my favorite (draft) document, the Host Requirements RFC:
>
>
> "UDP is almost a null protocol; the only services it provides over IP are
>  checksumming of data and multiplexing by port number.  
And am I still correct in assuming Sun doesn't even do half of those?
(Or is UDP checksumming for NFS back in SunOS 4.0?)

-- 
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 02:26:00 GMT
From:      Fitch@DOCKMASTER.ARPA
To:        comp.protocols.tcp-ip
Subject:   Tuning TWG TCP For Hyperchannel

We are developing a system that uses Wollongong's TCP on Hyperchannel
that needs to do many large file transfers.  The hardware is VAX,
running VMS.  Has anyone experimented with tuning either the driver to
Hyperchannel, TCP parameters, VMS parameters, ...  to speed things up?
Initial tests indicate that the TCP-to-Hyperchannel is the limiting
factor.  We're only interested in file transfers, so only FTP
performance is an issue.

Any and all sage advice welcome.  Seeing as this may be esoteric, please
respond directly (Fitch -at Dockmaster.arpa) and I'll summarize if it
ends up looking interesting.  Thanks.

--Jack

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 02:38:43 GMT
From:      mbb@trotter.usma.edu (MAJ Mark B. Bilodeau)
To:        comp.bugs.sys5,comp.protocols.tcp-ip
Subject:   TCP/IP/TELNET Problem on SYSV

REQUEST FOR HELP WITH TCP/IP WIN/3B.

Recently we have installed a small LAN consisting of 4 3b2s interconnected
by a DECNet DELNI and standard 3b2 ethernet cards and drop cables.
At first all appears to be well.  Telnet, ftp, tftp, etc. all work.
"rcp -r" dies every so often but other than that no problems.  The uucp 
utilities do not work as they do not recognize the network.  In order to
resolve this problem, I modified the sources to the utilities by:
1) defining TCP, 2) changing the include files to the directories used in
this version, 3) set the master to use service 'telnet' with login nuucp
rather than service 'uucp', and 3) setting the 'e' protocol to use the
standard system calls to read and write when the interface is TCP.  Upon
testing, this setup works for SMALL files (< 1024 bytes).  However, on
large files (>1024 bytes) uucico hangs.  The master is waiting for a 'C'
message and the receiver is waiting for the last bytes of the files.
Diging through the debugging files leads me to believe that the last byte
of every uucp packet (1024 byte block) is being lost.  I've dumped the
write buffer to a file just prior to the write call on the socket and all
1024 bytes look good.  On the other side just after the read from the socket
I've dumped the the packet to a file only to find that the last byte of
the buffer is what should be the first byte of the next 1024 byte block.

I would appreciate any and all help with this problem.  I can be reached at
the above email address or mbb@westpoint.arpa.

	Thanks In Advance,
	Mark

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Sep 88 10:46:43 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        topolcic@LABS-N.BBN.COM
Subject:   ST in gateways
In a message sent yesterday, C. Philip Wood asked Claudio Topolcic "Why
would you have to implement ST in a Gateway? Or, is IP on the way out?
Or, are we talking, implementing TOS?" Claudio is away for two weeks, so
I'll try a partial answer for him.  

ST is a protocol at the same level as IP, so a gateway can run them in
parallel; IP is not "on the way out".  

ST is a protocol which tries to provide a "guaranteed" amount of
bandwidth with low variance in delay to a user (the word is in quotes
because no guarantee is absolute); it was developed in the DARPA
Wideband Satellite network to match the characteristics of voice and
video conferencing better than IP did. ST deals not only with the
individual datagrams of a conference, but also with the "setup" when the
desired bandwidth is specified and the participants are identified.
With today's Internet topology including LANs, MANs and WANs with data
rates equal to or better than the WidebandNet, it is desirable to try to
extend the ability to participate in voice/video conferences to systems
not directly connected to WidebandNet but connected indirectly via
networks of appropriate capacity (especially LANs, today).  This
requires that ST protocol be implemented in the gateways interconnecting
the participating networks

It might be possible to implement similar functionality with TOS, but
probably not as efficiently.  The ST protocol makes use of the fact that
the datagrams of a conference are logically related and their timing is
somewhat predictable.  It allows feedback to the ST users when their
requests for bandwidth cannot be satisfied.  It provides for minimizing
the transmission of datagrams to multiple participants by carrying out
the dispersion/duplication as far down the pipe as possible.  All of
this is hard to do with stateless processing of IP, even with TOS.

Finally, ST has several years of experimental experience behind it and
is now serving as the basis for regular conferences.  Extension beyond
WidebandNet is an immediate need.  Nothing being done now will preclude
any type of TOS implementation, or even its possible use in the future
for conferencing.

Alex McKenzie

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 14:46:43 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   ST in gateways

In a message sent yesterday, C. Philip Wood asked Claudio Topolcic "Why
would you have to implement ST in a Gateway? Or, is IP on the way out?
Or, are we talking, implementing TOS?" Claudio is away for two weeks, so
I'll try a partial answer for him.  

ST is a protocol at the same level as IP, so a gateway can run them in
parallel; IP is not "on the way out".  

ST is a protocol which tries to provide a "guaranteed" amount of
bandwidth with low variance in delay to a user (the word is in quotes
because no guarantee is absolute); it was developed in the DARPA
Wideband Satellite network to match the characteristics of voice and
video conferencing better than IP did. ST deals not only with the
individual datagrams of a conference, but also with the "setup" when the
desired bandwidth is specified and the participants are identified.
With today's Internet topology including LANs, MANs and WANs with data
rates equal to or better than the WidebandNet, it is desirable to try to
extend the ability to participate in voice/video conferences to systems
not directly connected to WidebandNet but connected indirectly via
networks of appropriate capacity (especially LANs, today).  This
requires that ST protocol be implemented in the gateways interconnecting
the participating networks

It might be possible to implement similar functionality with TOS, but
probably not as efficiently.  The ST protocol makes use of the fact that
the datagrams of a conference are logically related and their timing is
somewhat predictable.  It allows feedback to the ST users when their
requests for bandwidth cannot be satisfied.  It provides for minimizing
the transmission of datagrams to multiple participants by carrying out
the dispersion/duplication as far down the pipe as possible.  All of
this is hard to do with stateless processing of IP, even with TOS.

Finally, ST has several years of experimental experience behind it and
is now serving as the basis for regular conferences.  Extension beyond
WidebandNet is an immediate need.  Nothing being done now will preclude
any type of TOS implementation, or even its possible use in the future
for conferencing.

Alex McKenzie

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Sep 88 23:01:39 PDT
From:      "David Cheriton" <cheriton@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   ST in Gateways
I regard ST as a rather unfortunate direction unless I am missing something.
First, it totally violates the IP architecture by putting a network-oriented
virtual circuit protocol in place of internetwork datagrams.  This has been
done with almost no critical discussion and review outside of BBN to my
knowledge.  Informal comments made to me suggest that there are about 3-4
people in the known universe than understand ST, and not much enlightment
to be gained from the confusing out-of-date RFC.

Second, ST people seem to claim that there is some magic that makes it
"more efficent" yet I know of no evidence to this effect. For example,
Mackenzie's claimed advantage in multi-site delivery can be equally
well provided (I conjecture) using the IP multicast extension.  And, as he
admits, the ST guarantees are no guarantee.  I believe that IP multicast
and a good TOS implementation could do just as well.

In general, the Internet can be viewed as a large experiment to evaluate the
feasibility using internet datagrams for a wide range of services.  Given the
fields in IP packets and header-only checksums, and reading the documents, it
is clear that the developers of IP intended try to handle video-like traffic
as well as file transfer, etc.  Too bad the ST money wasnt used to explore
than ambition rather than recapitulating to the X.25 camp.

Thus, courtesy of the ST effort, we have the video conferencing wedded to
an anti-IP protocol (I claim),  we have been deprived of the experiment of
building video conferencing on top of IP, and we have the IP performance
on the wideband network treated as a second-class citizen, getting twice
the delivery time as ST packets.  I also regard it as a very unheathy
situation that ST (to my knowledge) only runs on BBN's proprietary
gateways and regard that as a significant reason why conferencing is less
available in the Internet world than seems appropriate, given its availability
in the commercial world.

In summary, I would love either for me to be corrected or the situation with
ST to be corrected.
David Cheriton
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 19:15:56 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: mysterious 0x80... bytes from rlogin servers

These bytes are sent as urgent (in 4BSD, `out of band') data, and
are intended to act as control operations.  The bits are defined
as follows:

#define	TIOCPKT_FLUSHREAD	0x01	/* flush packet */
#define	TIOCPKT_FLUSHWRITE	0x02	/* flush packet */
#define	TIOCPKT_STOP		0x04	/* stop output */
#define	TIOCPKT_START		0x08	/* start output */
#define	TIOCPKT_NOSTOP		0x10	/* no more ^S, ^Q */
#define	TIOCPKT_DOSTOP		0x20	/* now do ^S ^Q */
#define	TIOCPKT_WINDOW		0x80	/* can use new window size protocol */

The window size protocol consists of having the rlogin client send window
size changes as the sequence 0xff, 0xff, 's', 's', <rows>, <columns>,
<x-pixels>, <y-pixels>, where <> quantities are two bytes in network
(BigEndian) order.

There is (as yet) no way to send 0xff bytes when using the window size
protocol, but obviously one of (0xff <something other than 0xff>) or
(0xff 0xff <something other than `ss'>) will be used.  I favour 0xff 0x00
myself...

Chris

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 20:40:17 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.windows.news
Subject:   Hello from INTEROP88

I love a trade show that I can walk into almost any booth and
get logged in at reasonable speed to my home machine.  One
neat experiment was that The Wollongong Group provided a Sun
3/60C for a public mail reading terminal.  It was lacking a
windowing system, so I decided to see if I could start up NeWS
on it.  In order to do that, I NFS mounted the /usr partition
from a Rutgers machine and Symlinked /usr/NeWS to the appropriate
directory.  This worked amazingly well.

(The guys from the Apple booth thought that NeWS was pretty neat,
I showed them how to change the menus by just editing the user.ps
file.)

-Ron

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 21:36:58 GMT
From:      mailrus!emv@husc6.harvard.edu  (Edward Vielmetti)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: uunet catch-22: help!
In article <10551@bellcore.bellcore.com> evan@ctt.UUCP (Evan Bigall) writes:
>In article <25193@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.UUCP (Mike Khaw) writes:
>>Since a couple of days ago (Sep. 27th-ish), uunet has not been accepting
>>mail from our sendmail (connection times out) but ftp and telnet continue
>>to work (though telnet to port 25 times out).  Has anyone else had this
>>problem?
>I have been having the same problem.  I thought it might be that the machine

ditto problem here, though the asynch connection between umix and uunet
has been quite reliable.  from the ping data, which shows lots of dropped
packets and widely variable times (from 1000 ms to 13000 ms) and 
occasional 'network unreachable' errors, I'd conclude that the
poor arpanet imp at the center for seisic studies is completely
saturated, and it's dropping packets left and right.
I'd appreciate it if someone closer to the action bore this
out.

I would hope that uunet is scheduled to be moved network-wise
onto the NSFnet backbone and off of the old arpanet....
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 21:59:58 GMT
From:      koehn@gumby.cs.wisc.edu (Brad Koehn)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   Lightspeed Pascal 3D Libraries

I am having problems using Lightspeed Pascal (tm)'s 3D librarie. Specifically,
how do you open it up? Every time I try the compiler sends me a "Type
incompatibility between an actual and formal parameter." I tried every
parameter available, including the ones supplied by LightSpeed.

Thanks.
Brad Koehn, U of WI.
My opinions (and ignorances) are my own.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 88 23:09:37 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   SLIP MTU "violation" - does anyone? does anyone care?

In working on the SLIP driver for SunOS 4.0 (yeah, streams, right...)
I decided to enforce the 1006 byte MTU on input, and found
a buggy SLIP client that would occasionally send slightly overlength
packets. On checking back, I found that the "generic" SLIP
driver cares not a jot or a tittle for such things, and will
cheerfully keep stuffing an infinite amount of unterminated
data into the mbuf chain. 

My question is, will enforcing the 1006 byte MTU break anything
out in netland (other than the already-identified buggy client,
now fixed)?

Geoff
-- 
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ 
PC Distrib. Sys. (home of PC-NFS)  |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:geoff@sun.com                 +------------------------------------------+

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Sep 88 08:29:44 -0400
From:      Andy Malis <malis@OAKLAND.BBN.COM>
To:        Edward Vielmetti <mailrus!emv@HUSC6.HARVARD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@OAKLAND.BBN.COM
Subject:   Re: uunet catch-22: help!
Edward,

> I'd conclude that the
> poor arpanet imp at the center for seisic studies is completely
> saturated, and it's dropping packets left and right.

> I would hope that uunet is scheduled to be moved network-wise
> onto the NSFnet backbone and off of the old arpanet....

Please note that ARPANET PSNs (IMPs) do not drop packets or
messages, no matter how congested they or the network become.
Rather, they use flow control if necessary to push back on hosts
and gateways, which then drop packets.

Also note that uunet.uu.net is not on the ARPANET, but on
ccs-ether.  A likely candidate for investigation might be
trivia.css.gov, the gateway between the ARPANET and css-ether.

If you are experiencing poor service from the ARPANET, please
call the BBNCC customer support hotline, 1-800-492-4992 outside
of Massachusetts, and ask to be transferred to the ARPANET NOC.
The NOC answers this line directly on nights and weekends.  If
you are calling from Mass., or want to call the NOC directly, the
number is (617) 873-3070.

Regards,
Andy Malis
BBNCC PSN Development
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Sep 88 08:43:22 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Edward Vielmetti <mailrus!emv@HUSC6.HARVARD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: uunet catch-22: help!

     ... poor arpanet imp at the center for seisic studies is completely
     saturated, and it's dropping packets left and right.

I am surprised to hear any indication that imps drop packets.  They are set up
with some strong anti-congestion measures, like host input blocking and
end-to-end flow control.  In the RFCs, and in my experience, it is the
gateways which find that they MUST drop packets, because they have no way to
prevent hosts from overdriving them.  I have seen occasional packets dropped
in the arpanet, but usually on the scale of 1 in 10,000, and if I had the
smarts to act on the 'packet lost' reply code, I could have retransmitted the
packet rather than forcing the poor source host transport layer (TCP) do it.

In the course of a recent week, 9/12-9/18, with 21 underpowered lsi11
gateways, about 100,000,000 packets were handled, with about 3% dropped
because the source tried to reach an unreachable net (or host on an arpanet
(little-a)), and another 3% dropped for saturation reasons.  During a 7 day
period there are some very slack times, but during a peak 15 minute period,
one of the Milnet-Arpanet (big-A) gateways handled 42 packets per second and
dropped 20%.  I interpret this as an indication that the Milnet or Arpanet was
holding the gateway off, and the gateway had to drop the extra packets.

Yours for nicer hosts,
Mike

disclaimer: while I work for the company that does the Arpanet imps, I am in a
different group.  My imp experience is only from the gateways attaching to
them.
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 09:23:00 PDT
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Graziano's Streams Query
In reply to the note from:

Usenet Administration <rti!xyzzy!thadani@mcnc.org>
Organization: Data General Corporation, Research Triangle Park, NC
Message-Id: <1247@xyzzy.UUCP>

stating:

    This suggests that a Streams module may be written in
    a special way to run in a multi-processor environment, whereas
    perhaps it is the implementation of the Streams facility that would 
    most require careful design for multi-processor operation.  The
    modules themselves should be oblivious to the nature of the cpu/s,
    especially if the advantages of standardization are to be maintained
    (given that the existing Streams specification from AT&T do not 
    allow for multi-processor operation).

What you are assuming in fact OUGHT to be true and, given
a strictly-conformant implementation, it ALMOST is true.  There
are two issues:

1.  Some streams-based products are not fully conformant.  To be fully
conformant, the inter-module communication must be through the
message-passing mechanism.  In fact, some streams-based TCP/IP
implementations have modules that share subroutines and data
structures directly.

Given conformance, then all inter-module multi-processor coordination
is, in fact, handled by the streams environment, rather than any of the
streams modules.

2.  However, streams modules may, also, make direct calls to subroutines
that are part of the operating system kernel.  (Does this open the door
to being incompatible from one o/s to another?  You betcha!)  That is,
streams modules get service from two places:  one is the streams
environment and the other is the operating system kernel.

This latter source can be the cause of having to modify the modules,
themselves, to coordinate multi-processor situations.  If two modules
may access the same operating system kernel service at the same time,
the they must have lock/unlock code added.  (Obviously, minimizing or
eliminating such o/s accesses is preferred.)


Dave

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Sep 88 9:50:08 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ST in Gateways
I am not interested in getting into a flame war, but I think I should
comment on a few points in Dave Cheriton's message.

I think I can reasonably claim to be one of the developers of IP (Vint,
care to comment?) and of course we tried to handle many types of
traffic.  But I don't think that means that other experiments aren't
also appropriate.  I think I can also claim to be one of the developers
of TCP, and assert that the existence of TCP does not make experiments
with UDP, NETBLT, or VMTP inappropriate.  I see no difference between
the two cases.

No "magic" is claimed for ST.  I tried to sketch out the perceived
advantages of ST, at least in the environment in which they were
developed.  If your engineering judgment leads you to the conclusion
that I'm wrong, fine, but please don't assert that the claims are for
magic.  By the way, my previous message may have somewhat blurred the
distinction between the ST protocol, which is at the same level as IP,
and the "stream" facility of the WidebandNet, which is closer to the
"link" level.  But the two interact, and I don't think any blurring of
the distinction is very relevant to this discussion.

BBN has worked closely with other interested parties in the DARPA packet
voice and video conferencing experiments for many years, particularly
Lincoln Labs, SRI, DCEC, and ISI.  The ST protocol design effort was led
by Jim Forgie at Lincoln Labs, and did not include significant input
from anyone at BBN.  The ST design grew out of problems uncovered during
a large number of experiments with packet voice using datagram service
conducted by Lincoln Labs in the 1970's (see "Experience with Speech
Communication in Packet Networks"; C. Weinstein and J. Forgie; IEEE
Journal on Selected Areas in Communication; Volume SAC-1, Number 6;
December 1983).

BBN makes no proprietary claims for ST, nor does ST currently run on any
gateways made by BBN.  It is hard for me to understand why the ST R&D
effort should be called "very unhealthy" just because it is not (yet)
widespread.  Packet switching software once ran on only Honeywell 516
computers programmed by BBN programmers.  IP gateway code once ran on
only DEC PDP-11s. From today's perspective I don't think there are many
who would characterize either of these things as unhealthy. I don't see
the difference.

Finally, Claudio Topolcic's message, which precipitated this discussion,
was an announcement to the IETF that greater community involvement in
the issue of ST in gateways _was_ being actively sought, through the
formation of a new group.  Perhaps that forum is the best place for
these discussions to continue.

Alex McKenzie
 
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 11:17:49 GMT
From:      lepreau@utah-cs.UUCP (Jay Lepreau)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Cc:        donn, emv@mailrus.cc.umich.edu
Subject:   Re: uunet catch-22: help!

Edward Vielmetti writes:
	from the ping data, which shows lots of dropped
	packets and widely variable times (from 1000 ms to 13000 ms) and 
	occasional 'network unreachable' errors, I'd conclude that the
	poor arpanet imp at the center for seisic studies is completely
	saturated, and it's dropping packets left and right.
	I'd appreciate it if someone closer to the action bore this
	out.

We have the same problem and at first I suspected the same cause but
it's definitely not that.  We had similar horrible ping times, until
I changed our routing tables to route to uunet directly through our
attached Arpanet interface, and have had consistent  ping times of about
600ms.  However, we still can't complete a connection to port 25, but
can to other ports.  Mail sent in a loop thru other seismo sites and
then thru uunet back to us does get through. So there is some
interaction between the network or client host name and the sendmail
server.  I've tried from elsewhere on the net also, to no avail.

We've tried to contact Rick Adams but he's away (probably at Interop)
and know of no other phone numbers.  This is a big problem and a Bad
Thing.  I have started other phone tracers which may come through
today.   Guess will start packet tracing if things don't get better
soon.  Rich Salz, I dunno why you insist on being so coy about who
runs things at uunet when there's a legitimate problem like this.
Meanwhile, the network has tons of mail being sent back to users since
this has now been going on for more than 3 days.

Jay Lepreau

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 12:43:26 GMT
From:      jost@tunscs.UUCP (Allan Jost)
To:        comp.protocols.tcp-ip,comp.dcom.modems,comp.dcom.lans,comp.sys.hp,comp.protocols.iso
Subject:   Re: Wanted: SLIP oer 9600-baud modems

I have a similar requirement here, except that we are running Ultrix on
a couple of Microvaxen.  The two sites I want to interconnect are
just down the street from each other, and there is a 9600 baud
asynch line in place between them.  Has anyone successfully
installed and used SLIP under Ultrix?

Allan Jost
Technical University of Nova Scotia

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 13:29:53 GMT
From:      verber@tut.cis.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   Re: TCP-IP libraries for Macs and ATs


Apple is showing their new TCP/IP drivers at inter/op.  They are not
the U of Mich drivers.  They were written inside Apple.  They look
pretty good and use some of the ideas that Jacobson (sic) of Berkeley?
did to BSD TCP/IP.

Cheers,
Mark

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 14:46:10 GMT
From:      jack@turnkey.TCC.COM (Jack F. Vogel)
To:        comp.protocols.tcp-ip
Subject:   Re: Need TCP/IP support for 3C505 card

In article <157@amtfocus.UUCP> irab@amtfocus.UUCP (Ira Brenner) writes:
>Anyway, the real question is: are there any other 
>software packages, possibly public domain, that will support the 3C505? 
>Any info would be greatly appreciated.
 
Ira,	As far as I know the current version of KA9Q will support the
3Com board, I have not used it that way but seem to recall that there
was a compile-time option for doing so. I believe the MIT PC/IP package
may also support the card but am less certain about that. Both of these
packages are public domain. If you are unable to locate a site that has
these packages, drop me a note and I can give you information about how
to anonymous-uucp them from turnkey.

						Good Luck,


-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack@turnkey.TCC.COM

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Sep 88 21:58:31 PDT
From:      DDN Reference <NIC@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        nic@SRI-NIC.ARPA
Subject:   correction to recent bibliography message
Dear TCP-IP reader,

It has been brought to my attention that my message on the tcp-ip mailing list
did not correctly give the syntax for retrieving the revised NIC DDN protocol
bibliography by electronic mail. Following is the correct syntax for the
subject line of a request to SERVICE@SRI-NIC.ARPA :

     SEND NETINFO:PROTOCOLS-DOD.BIB    for the ASCII text version
     SEND NETINFO:PROTOCOLS-DOD.PS     for the postscript version

If you requested the bibliography and got a response of "Invalid command or
File not found." then you will be receiving the bibliography (in the form
you requested) in a message that will immediately follow this one.

My apologies for any inconvenience you may have experienced.

Sol/NIC
-------
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 18:38:05 GMT
From:      rsalz@bbn.com (Rich Salz)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Re: uunet catch-22: help!

In <5756@utah-cs.UUCP>, lepreau@cs.utah.edu (Jay Lepreau) writes:
>  Rich Salz, I dunno why you insist on being so coy about who
>runs things at uunet when there's a legitimate problem like this.
I don't publish people's phone numbers without their prior permission.
SRI-NIC lists Rick Adams as the contact person, along with a phone.
If you have the problem of not being able to maintain SMTP connections,
then you have the means to work on a solution -- the NIC whois database...
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 19:38:36 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Van's algorithm on STREAMS

I hope someone on the net can answer my question !!

I am curious how much was improved on STREAMS implementation after
Van Jacobson's congestion enhancement plus his header-prediction changes.

Could you give me the actual number when you do "ftp" with binary mode ?

Thanks,
    
That's all now !!

Kwang Sung
Sr. Software Engineer
ARIX Corp.
408-922-1822

UUCP: ...!sun!aeras!smaug!kwang

Bye !!
 

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 88 22:47:17 GMT
From:      tim@hoptoad.uucp (Tim Maroney)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac
Subject:   Re: TCP-IP libraries for Macs and ATs

In article <23036@tut.cis.ohio-state.edu> verber@tut.cis.ohio-state.edu (Mark
A. Verber) writes:
>Apple is showing their new TCP/IP drivers at inter/op.  They are not
>the U of Mich drivers.  They were written inside Apple.

According to a source at Apple who was kind enough to write me, the Apple
TCP/IP implementation was done by Ungermann-Bass.  My UofMich speculation was
based on what Martin Haeberli told me in 1987, which seemed to be corroborated
by recent trade press reports.  I know, it was stupid to believe the trade
press, sorry....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Strong men tremble when they hear it.
 They've got cause enough to fear it;
 It's even blacker than they smear it!
 No one mentions -- my name." - Bill Sykes, "Oliver"

END OF DOCUMENT