The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Oct 90 14:55:35 CDT
From:      darrel beach <beach@ddnuvax.af.mil>
To:        tcp-ip@nic.ddn.mil
Cc:        beach@ddnuvax.af.mil
Subject:   TCP/IP for DEPCA boards
Another plea for info...
  
   Can anyone point me to drivers, software, vendors to let me run
TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
cards.  Packet drivers compatible with NCSA, KA9Q, or even a commercial
package would be appreciated.

Thanx in advance...
Darrel Beach
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Oct 90 15:34:00 EDT
From:      Tom Seto <Seto%UNCAMULT.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   TCP/IP products

Hello.  We are currently putting together a RFP to obtain more computing
power of the UNIX variety.  While we were reviewing the various aspects
of the request, a question came up:  Is there a measure for the
"Goodness" of a particular tcp/ip product, ie how well does it conform
to the standards, how well does it perform, etc?  We have in the passed
tossed a package from one vendor and purchased one from another on our
VAX/VMS.  The UNIX systems presumably comes with a tcp in the system,
but is there anyway to measure whether a vendor has done a particularly
good or bad job of it?  I would also welcome comments regarding products
that are out there, especially products that come with a particular
brand of hardware.

Thanks for your time.

          Tom Seto
          Mgr, Data Comm
          ACS
          U of Calgary
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 90 13:55:07 GMT
From:      mailrus!sharkey!cfctech!alexb@uunet.uu.net  (Alex Beylin)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP, IP Routers and Named Pipes

A project have come up around here that require multiple
PCs to get dial-in access to the TCP/IP network.  One of the 
major requirements is support for Named Pipes down to the PC.
Current plan is to use SLIP and a router with dial-in ports.

Would someone care to recommend a PC package that would do good
SLIP emulation and a router that would be suitable for this job?

Comments, suggestions are most welcome.

Thanks in advance,

-- Alex


 Alex Beylin, Unix Specialist   | +1 313 948-3386
 alexb@cfctech.cfc.com          | Chrysler Financial Corp.
 sharkey!cfctech!alexb          | MIS, Distributed Systems
 ATT Mail ID: attmail!abeylin   | Southfield, MI 48034
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 90 15:19:10 GMT
From:      bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!ultra!wayne@bloom-beacon.mit.edu  (Wayne Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
Thanks to all who responded to my "Question on forwarding broadcasts"
posting.  Two quickies.

One, I apologize for over-simplifying the picture.  In the real life
situation both hosts do in fact have other network connections, so
they really SHOULD be forwarding packets.  If I had drawn a couple
more lines it would have been clearer.

But mostly, I should have read RFC 1009 more carefully, 'cause sure
enough, there it is right on page 36:

      In general, a gateway must not forward a datagram which
      arrives via local network broadcast, and must not send
      an ICMP error message when dropping the datagram.  A
      discussion of the rules will be found in Appendix A;
      see also [50].

(Interesting that this specific situation does NOT seem to be
mentioned anywhere in Appendix A, however!)

Now the only question is when the support for the above requirement
(that is, Data Link telling IP whether a packet arrived via broadcast
or multicast) will get out in the various host implementations.  And
THAT is what I should/would have asked, if I had read RFC 1009 better!

Anyway, apologies for the wasted net bandwidth on red herrings.  Now,
about the REAL question ... ?

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Oct 90 03:49:22 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        tcp-ip@nic.ddn.mil
Subject:   Maintainability of TELNET Sessions Over Marginal Circuits
A site that I'm involved with has an interesting problem involving TELNET,
specifically, and TCP/IP, in general, over encrypted and/or marginal links.
I'm interested in comments from this group that might suggest a solution
to this problem.

For want of a better description, the organization of this network might
be described as a WAN.  It consists of a number of LANS each of which has,
at least, one router with, at least, two direct links to other LANS.  Each
of the links is encrypted.  The purpose of multiple direct links is to pro-
vide redundant paths to a central system that provides a common database
and a common set of services for the workstations on each of the LANS.

When the user wishes to make use of the central system, the user establishes
a TELNET connection to the central system through a process that also provides
an emulation of a terminal supported by the central system.

They had expected the router on loss of a circuit (loss of crypto synch)
to switch over to an alternate circuit and maintain the TELNET connection.
When they brought up the first LAN, they encountered two problems--the link
was of poorer quality than they had thought and continually looses synch
and the router did not switch circuits as they thought it would.  When the
TELNET connection is re-established, they are not reconnected to their pre-
vious session.

When crypto synchronization is lost, random data will appear on the circuit
until both crypto units detect the loss of synchronization and have re-synched.

The questions:

  1.  Do routers generally have the capability to re-route traffic over
      an alternate circuit?
  2.  How robust is IP in dealing with corrupted data streams when crypto
      synch is lost in the header?  In the body?
  3.  How robust is TCP in dealing with corrupted data streams?
  4.  Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
      alleviate problems?

Any comments would be appreciated.

Merton

,
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 90 17:08:58 GMT
From:      kdb@macaw.intercon.com (Kurt Baumann)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: MAC MS-MAIL to SMTP gateway?

In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer)
writes:
> I thought the GatorMail products were software to run on the GatorBox.  Am I
> mistaken?  Hard to believe that products designed for a GatorBox would run
> on Kinetics-oops-Novell-oops-Shiva FastPath.

I might be mistaken, but they do sell it as a seperate product.  The last
I knew it ran with any AppleTalk-IP gateway product.  Course this might have
changed as well.  Anyone listening from Cayman, Brad?

Kurt
--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 01:31:00 GMT
From:      adelphi!news@uunet.uu.net  (News Feed)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom

In article <NELSON.90Sep28233146@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
> 
>     [2] I have also been advised that, lacking copyright registration, all
>     that I could accomplish is to force you to stop distributing the driver,
>     which you have already agreed to do.
> 
> --
> --russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
> It's better to get mugged than to live a life of fear -- Freeman Dyson


I myself hold 3 copyrights on software I developed for the printing
industry dealing with CAM and I remember posing the following question
to my lawyer:


How long do I have to register my copyright, and when does the copyright
take effect?  According to him and the form TX as well as the related booklet on
filing form TX from the Library of Congress, you have up to 2 years
to file your copyright registration, and the code that comes off ones pen
is copyright by him/her, as long as it is not a work for hire or contracted
oherwise.  The implied registration covers the period before registration.

As a matter of fact my lawyer told me, and I did in all cases,
to just file the docuemtation and a binary listing of the code, thus
leaving the source to be considered "trade secret".  He stated this
gives better protection.

My point is, why is the above listed driver not copyright in the same manner.
I certainly am confused now.  Can anyone state the facts?  I hate to
see people get burned like that.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 01:41:47 GMT
From:      brooks@apple.com  (Kevin Brooks)
To:        tcp-ip@nic.ddn.mil
Subject:   HP TCP/IP router/bridge?

Does anyone know of a bridge or router that will allow HP hosts running
TCP/IP which speak IEEE style packets (802.2 encapsulated) to
communicate with ethernet style IP implementations?  Do most of the
router/bridge vendors support both IEEE and ethernet style IP packets?

Thanks in advance
Kevin

-- 
  Kevin Brooks 			A/UX Specialist, Apple Computer	   
  UUCP: {mtxinu,sun,nsc,voder}!apple!brooks
  APPLELINK: AUX.DUDE@applelink.apple.com
  Internet: brooks@apple.com
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 01:48:56 GMT
From:      news@ncsuvx.ncsu.edu  (Shahrooz A Alavi)
To:        tcp-ip@nic.ddn.mil
Subject:   >>> Internetworking with TCP/IP book FOR SALE <<<

	NEW "Internetworking with TCP/IP.  Principles, Protocols and Arch." 
	by D Comer [Prentice Hall]

	$35 (includes shipping)

	Send me an email with your daytime mailing address and I will
	send it to you UPS/COD.
	-----------------------------------------------------------
	S. Alavi    (919) 467-7909          ssa@eceugs.ece.ncsu.edu
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Oct 90 09:21:09 -0400
From:      H. Craig McKee <mckee@chance.mitre.org>
To:        mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Maintainability of TELNET Sessions Over Marginal Circuits
>When they brought up the first LAN ... the link was of poorer quality 
>than they had thought and continually looses [crypto] synch ....

Is the link protocol synchronous (eg, HDLC) or asynchronous (start/
stop bits)?  My experience with synchronous links is that a crypto like
the KG-84 rarely looses synch (because modem clock recovery circuits are
generally very good).  For some cryptos there is a mode of operation
called CTAC that is self-synchronizing; it does not require loss-of-
synch logic in another box.  The site can get expert advice from
their cryptologic support center or the National Security Agency.

  >2.  How robust is IP in dealing with corrupted data streams when crypto
  >    synch is lost in the header?  In the body?
  >3.  How robust is TCP in dealing with corrupted data streams?

Corrupted data will be detected and discarded by error detection 
logic at the link, IP, and TCP layers.

  >4.  Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
  >    alleviate problems?

Give it a try; it's not a good hack, but I've done some bizarre things 
when trying to get a circuit up.  

Regards - Craig
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Oct 90 11:39:51 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        darrel beach <beach@ddnuvax.af.mil>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for DEPCA boards
I'm posting to the list because this question gets asked awfully frequently:

DEC's PCSA and DECNet/DOS products currently use a hardware-independent
interface-sharing driver spec called "DLL".  It is documented in the
VaxMate Tech Ref.  DEC supplies DLL drivers for various interfaces
(theirs and 3Com's, I think) with PCSA and DECNet/DOS, and a number of
other board vendors (e.g.  Western Digital, Interlan that I know of)
also offer DLL drivers for their own boards.  FTP's PC/TCP (part PC-223)
and Wollongong's WIN/PC can use DLL drivers.

In addition, DEC has or will soon release an NDIS driver for the DEPCA.
If you have this, you can use it with our freeware NDIS to Packet Driver
adapter module (in pub/packet.driver/NDIS on vax.ftp.com, I won't mail
it to you) and any of the TCP/IPs that support the Packet Driver (PC/TCP,
WIN/PC, BWTCP, PCIP, KA9Q, NCSA, CUTCP, PCRoute, etc.).

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

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 05:22:52 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for DEPCA boards
In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:

      Can anyone point me to drivers, software, vendors to let me run
   TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
   cards.  Packet drivers compatible with NCSA, KA9Q, or even a commercial
   package would be appreciated.

Not yet, but the picture is coming into focus.  We've gone from
"Digital refuses to release programming information" (that was just a
rumor) to "How may I help get you the information you need to write a
packet driver?"

Maybe in a couple of months...

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Oct 90 15:23:14 MDT
From:      <wbaggett@NMSU.Edu>
To:        tcp-ip@sri-nic.arpa
subscribe Tim Baggett
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 12:23:34 GMT
From:      ingr!b11!usenet@uunet.uu.net  (Usenet Network)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
in article <1990Oct1.135507.27559@cfctech.cfc.com>, alexb@cfctech.cfc.com (Alex Beylin) says:
> 
> Would someone care to recommend a PC package that would do good
> SLIP emulation and a router that would be suitable for this job?

---

The company I work for sells PC/NFS.  I do not have experiance with 
the product over serial lines, but PC/NFS (from Sun) does support SLIP.

SUN US SALES is listed as:
1-800-821-4643

For routers see cisco or there are terminal servers that support SLIP.
I worked for an outfit that sold cisco and the company I work for now
sells the Encore Annex II.  

cisco
415-326-1941

encore (terminal server with slip) 
617-460-0500

NOTE: I am not endorsing these products, but they are worth investigation.



-- 
      *  John E. Allen - Intergraph Corporation -  (205) 730-8627  *
      *                   System Sales Support                     *
      *           ingr!b23b!allen!jallen@uunet.uu.net              *  
      **************************************************************
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 13:28:35 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu  (Hugh Fader)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a program like telnet, but driven by a script?

I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
I am running a Sun Sparcstation and can communicate with the VAX using
telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
solution to my problem would be a telnet-like program which accepts a
script containing expect/send pairs much like UUCP and some PC
communications programs. Does such a program exist?

I would also appreciate any suggestions of alternate solutions.

Thanks in advance.

--
Hugh Fader
hugh@slee01.srl.ford.com
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 14:20:36 GMT
From:      pacbell.com!pacbell!varian!vaxwaller!phil@ucsd.edu  (Phil Newton)
To:        tcp-ip@nic.ddn.mil
Subject:   HOW CAN I GET ON THE INTERNET???
I am interested in finding out HOW to gain access to the Internet.

Would anyone out there who knows how to so this please let me know, too?

Thanks in advance for your assistance!


-- 

Philip T. Newton     (415)945-2272
Varian Instruments   2700 Mitchell Drive   Walnut Creek, CA.  94598
{zehntel,pacbell,lll-winken}!varian!phil
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 17:51:49 GMT
From:      prang!marciano@lll-winken.llnl.gov  (marciano pitargue)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP comparison
>Something?              Vitalink ( I think it's a repackaged HP product )
...
>-- 
>Per Andersson (perand@admin.kth.se, perand@stacken.kth.se)
>Trying a new job at Bofors Electronics,
>still reading news at the Royal Institute of Technology
>Time, got the time tick tick tickin' in my head - Joe Jackson

it's called the Wan Manager.  it's is _not_ a repackaged HP product.

/marciano					marciano@vitalink.com
						vitam6!marciano@uunet.uu.net
						...uunet!!vitam6!marciano

disclaimer:  noun.  1. a denial or disavowal of legal claim:  relinquishment of
or formal refusal to accept an interest or estate.  2. a writing that embodies
a legal disclaimer.
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 18:25:41 GMT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Router scorecard V1.6


                              CAVEATS
                              -------

    The following scorecard tries to compare various  multi-protocol
routers.   The  current  scorecard  mainly  contains information for
cisco and  Wellfleet but  any other vendor is welcome  to  send me a
complete set of  manuals for their  equipment so that  I can analyze
and update the scorecard.

    The fact of  the matter is  that certain features  and "gotchas"
only appear when testing the actual equipment.  I hope that the user
population of multi-protocol routers  will assist me in  making this
scorecard as comprehensive as possible so that people who follow  do
not have to go through what I have gone through.

    It was  difficult to  decide whether  to include  future release
notes  in  this  scorecard.   I  trust  the  user  population in the
Internet to take each promise for a "future feature" with a grain of
salt  and  to  keep  watch  on  the  vendors that indeed they follow
through with their  promises.  All too  often vendors state  certain
features will be available in a certain release and sometimes  their
deadlines slip.   It is  advised that  people should  not base their
decisions on the future release notes. [That was a long caveat].

    If you  have comments,  suggestions, additions,  or subtractions
or corrections, please send them to:

HANK@VM.TAU.AC.IL   or   HANK@TAUNIVM.BITNET    (but not to both!)

    The  scorecard will  be updated on a monthly basis.  This report
may be freely reproduced as long as nothing is altered or removed.

    If you read this report  and are not connected to  the Internet,
you can send your comments to:

Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

    [The above employer has nothing to do with this scorecard so  if
something bothers you about it, I take full responsibility.]

                          END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box.  I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
                  Comparison of Multiprotocol Routers
                           Henry Nussbacher
                             October 1990
                              Version 1.6


                       +--------------+--------------+---------------+
 Multiprotocol         | cisco AGS+   | Wellfleet LN | Proteon p4200 |
 Router                | Rel. 8.1(14) | Rel. 5.35    |               |
                       +--------------+--------------+---------------+
 1. General            |              |              |               |
    - # of slots       | 9            | 4            | 7             |
    - Processor        | 68020        | 68020        | 68020         |
    - Memory           | 4Mbyte       | 4Mbyte       | 2Mbyte        |
    - Updates via      | ROM, TFTP    | diskette,TFTP| diskette,TFTP |
    - Speed of bus     | 530Mb/sec (a)| 320Mb/sec    |               |
    - Boot from        |              |              |               |
      - ROM            | Yes          | No           | No            |
      - Net-boot       |              |              |               |
        - IP           | Yes          | No           | Yes           |
        - Decnet (MOP) | No           | No           | No            |
      - Diskette       | No           | Yes          | No            |
      - Another router | Yes          | No           | No            |
    - Volatile changes | Yes  (b)     | No           | Yes   (h)     |
    - CPU statistics   | Yes  (c)     | No           | Yes           |
    - Memory stats     | Yes          | No           | Yes           |
    - Ease of install  | Very easy    | menu driven  |               |
    - Documentation    | Difficult    | Skimpy       | Clear, orderly|
    - Autorestart (d)  | Yes          | Yes          | Yes           |
    - Restart for      |              |              |               |
      config changes   | No           | Yes          | Yes           |
    - Watchdog timer   | Yes          |              | Yes           |
    - Reboot time  (e) | 29 sec  (f)  |  60 sec      | 32 sec (i)    |
    - Power-up time (g)| 29 sec       | 120 sec      | 32 sec (i)    |

 Notes:
 a. Speed of old AGS bus is 160Mb.
 b. Volatile changes represents the ability of the router to accept a
    configuration change that is dynamic that only affects the current
    running system and once the system is rebooted, the change
    disappears.
 c. CPU statistics refers to the ability of the router to provide
    a monitoring facility to see what the CPU is doing and how often
    it is doing it.
 d. Autorestart in the event of a power failure.
 e. Reboot time refers to the amount of elapsed time needed to
    perform a logical restart (reboot) from the fastest available
    media.
 f. cisco timings are for older AGS system.
 g. Power-up time refers to the amount of elapsed time needed from
    the time of a power failure and recovery until the router is up and
    operational.
 h. Only available for DECnet and OSPF, and only for a subset of
    available parameters.
 i. Booting via Proteon's Intergrated Boot Device, with running
    diagnostics.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       | 7x10Mb        |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 8x10Mb       | No            |
    - 4Mb Token Ring   | 3x4Mb    (i) | 4x4Mb        | 7x4Mb         |
    - 16Mb Token Ring  | Rel 8.2  (j) | Rel 5.40 (c) | No            |
    - RS232            | 24x64kb      | 16x64kb      | 14x64kb       |
    - RS449            | 12x64kb      | 16x64kb      | 14x64kb       |
    - V.35             | 12x64kb      | 16x64kb      | 14x64kb       |
    - T1               | 12x1.544Mb   | 8x1.544Mb    | 14x1.544Mb    |
    - CEPT DS1 (2Mb)   | 12x2Mb       | 8x2Mb        | 12x2Mb        |
    - FDDI             | 2x100Mb      | Rel 5.50 (d) | 2x100Mb       |
      - DAS (Dual)  (e)| Yes          | Yes          | Yes           |
      - SAS (Single)   | Yes          | No           | Yes           |
    - Ultranet         | Rel 8.2   (k)|              |               |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          | 255           |
    - Card types  (g)  | 6E, 1E2S,    | 2E, 1E1S,    | 1E, 2S, 4S,   |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  | 1TR, .5F      |
                       | 1TR, 1F   (h)| 1TR2S, 4S,   |               |
                       |              | 1TR          |               |

 Notes:
 a. Each interface subsection represents the maximum number of LANs
    or WANS that can be configured for that particular subsection.
    It is possible to "mix and match" various subsections by reducing
    the upper limit.
 b. Thin Ethernet refers to a standard BNC connector available directly
    on the router.
 c. 4x16Mb.
 d. 1x100Mb.
 e. Dual is also known as Type A and Single is also known as Type B.
 f. Depends on memory limitations.
 g. Card types: E: Ethernet, S: Serial/Synchronous line
                TR: Token-Ring, F: FDDI
 h. The 6E and 1F cards are for the faster cBus only.
 i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
 j. To be supported in later release of Version 8.2.
 k. Ultranet support will be in a later release of 8.2 but will
    only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.

 3. Interface part II  |              |              |               |
    - Frame Relay (a)  | Rel 8.2      |              |               |
    - Ethernet         |              |              |               |
      encapsulation    |              |              |               |
      - Standard v2.0  | Yes          |              | Yes           |
      - IEEE 802.3     | Yes          |              | Yes           |
      - SNAP 802.2     |              |              |               |
        (RFC1042)      | Yes          | Yes          | No            |
    - Serial           |              |              |               |
      encapsulation    |              |              |               |
      - HDLC           | Yes          |              | Yes           |
      - LAPB           | Yes          |              | No            |
      - PPP (RFC1134)  | Yes          |              |               |
      - DDCMP          | No           | No           | No            |
      - X.25           | Yes          |              | Yes           |
        - SVC          | Yes          | Yes          | Yes           |
        - PVC          | Yes          | Yes          | Yes           |
    - Encryption   (b) | Pulse-time   |              |               |
    - Filtering by     |              |              |               |
      source/dest      | Yes          | Yes          | Yes           |

Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
   encrypting devices on various interfaces or circuits.
c. For CLNP only.

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          | Yes           |
    - ARP  (RFC826)    | Yes          | Yes          | Yes           |
    - RARP (RFC903)    | Yes          | No           | No            |
    - BOOTP (RFC951)   | Yes          | No           | No            |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          | Yes           |
    - ICMP             | Yes          | Yes          | Yes           |
    - Name-server      | Yes          | No           | No            |
    - Accounting       | Yes          | No           | No            |
    - MTU              | Yes          | No           | No            |
    - Security - IPSO  | Yes          | No           |               |
    - Static routing   | Yes          | Yes          | Yes           |
    - Source routing   | Yes          | No           | Yes           |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          | Yes           |
      - TCP            | Yes          |              |               |
      - UDP            | Yes          |              |               |
      - ICMP           | Yes          |              |               |
      - by protocol (b)| Yes   (a)    | Yes          |               |
    - Routing protocols|              |              |               |
      - RIP (RFC1058)  | Yes          | Yes          | Yes           |
      - EGP (RFC904)   | Yes          | Yes          | Yes           |
      - BGP (RFC1105)  | Yes          | No           |               |
      - Proprietary    | IGRP         | eRIP         | No            |
      - Filtering      | Yes          | No           | Yes           |
      - Default routes | Yes          | Yes          | Yes           |
      - OSPF           | Rel 9.0      | Rel 5.6      | Yes           |

 Notes:
 a. Can be done but is difficult and requires advanced knowledge of the
    specific protocols.
 b. Filtering by protocol can also be viewed as filtering by port
    number.

 5. DECNET             |              |              |               |
    - Phase IV Router  | Yes          | Yes          | Yes           |
    - Area Router      | Yes          | No           | Yes           |
    - Phase IV+   (a)  | Rel 8.2      | No           |               |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      |              |               |
    - Phase V          | Yes     (b)  | No           | Yes     (b)   |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           | No            |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          | Yes           |
      - area-max-hops  | Yes          | Yes          | Yes           |
      - max-address    | Yes          | Yes          | Yes           |
      - max-area       | Yes          | Yes          | Yes           |
      - max-cost       | Yes          | Yes          | Yes           |
      - max-hops       | Yes          | Yes          | Yes           |
      - max-visits     | Yes          | Yes          | Yes           |
      - router-priority| Yes          | Yes          | Yes    (e)    |
      - hello-timer    | Yes          | Yes          | Yes           |
      - routing-timer  | Yes          | Yes          | Yes           |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           | Yes           |
      - by protocol    | No           | No           | No            |
      - by object      | No           | No           | No            |
      - routing        | Yes    (d)   | No           | Yes    (d)    |
    - MOP              | Bridged      | Bridged      | Yes    (f)    |
    - Static routing   | No           | No           | No            |
    - Max routing table| 1023         | 1023         | 1023          |
    - Max # of broad.  |              |              |               |
      router adjencency| 32           |              |               |

 Notes:
 a. Phase IV+ refers to path-split capability.  This means "normal" and
    not "interim".  Normal allows out-of-sequence packets to arrive.
    Interim does not allow out-of-sequence packets to arrive.
 b. cisco claims that it's ISO CLNS support is compatible with Decnet
    Phase V.
 c. Address Translation Gateway is the ability to connect two separate
    Decnet networks with overlapping addresses.
 d. It is not possible to filter out of area addresses.  It is only
    possible to filter an entire area or addresses within one's area.
 e. On a per circuit basis, as required by DECnet specs.
 f. MOP System ID.

 6. Bridging           |              |              |               |
    - Local bridging   | Yes          | Yes          | No            |
      - LAVC      (a)  | Yes          | Yes          | No            |
    - Remote bridging  | Yes   (b)    | Yes          | No            |
    - Transparent      |              |              |               |
      - Learning       | Yes          | Yes          | No            |
      - Spanning tree  |              |              |               |
        (IEEE 802.1)   | Yes          | Yes          | No            |
    - Priority    (c)  | Rel 8.2      | No           | No            |
    - Filtering        |              |              |               |
      - Multicast      | Yes          | Yes          | No            |
      - Protocol       | Yes          | Yes          | No            |
      - Source/dest    | Yes          | Yes   (g)    | No            |
      - Masking   (d)  | No           | No           | No            |
    - Load sharing     | Yes   (e)    | Yes          |               |
    - Token Ring       |              |              |               |
      - Source route   | Yes          |              | Yes           |
      - Multi-ring (f) | Yes          |              | No            |

 Notes
 a. LAVC refers to the ability to act as a local bridge between two Vax
    clusters using the DEC LAVC protocol.
 b. cisco does not support bridging over X.25 or LAPB.
 c. Priority refers to the ability to assign a priority to a specific
    protocol so that that protocol is sent faster than any other
    protocol over a specific circuit/interface.
 d. Masking refers to the ability to specify some pattern string to be
    matched within the packet, so that the user can specify almost any
    filter.
 e. cisco load sharing (balancing) is on a per-node basis and not on
    a per packet basis.  That means that over 2 parallel serial lines
    the cisco will automatically allocate 50% of the learned Ethernet
    addresses to one line and the other 50% to the other line.
 f. Multi-ring refers to bridging between multiple Token Ring networks
    (all hosts must understand RIF).
 g. Wellfleet can only filter on destination address and not on source
    address.

 7. Other protocols    |              |              |               |
    (ability to route) |              |              |               |
    - XNS              | Yes  (a)     | Yes          | Yes           |
      - UB derivitive  | Yes          |              | Yes           |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          | Yes           |
      - Phase 2        | Rel 8.2      | Rel 5.40     | No            |
      - Tokentalk      | Rel 8.2      | Yes          | No            |
      - Ethertalk      | Yes          | Yes          | Yes           |
      - Localtalk      | No           |              | No            |
      - RTMP           | Yes          | Rel 5.40     | Yes           |
      - AARP           | Yes          | Rel 5.40     | Yes           |
      - NBP            | Yes          | Rel 5.40     | Yes           |
      - EP             | Yes          | Rel 5.40     | Yes           |
      - ATP            | Yes          |              | Yes           |
      - ZIP            | Yes          | Rel 5.40     | Yes           |
      - DDP            | Yes          | Yes          | Yes           |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           | Yes           |
      - ISO 9542 ES-IS | Yes          | No           | Yes           |
    - Apollo Domain    | Yes          | No           | Yes           |
    - Novell IPX       | Yes  (a)     | Yes          | Yes           |
    - Banyan Vines     | Rel 8.2      |              |               |
    - X.25             | Yes          | Yes          | Yes           |
      - bridging       | Rel 9.0      | Yes          | No            |
      - routing        | Yes          | Yes          | Yes           |
      - switching      | Yes          | Yes ???      | No            |
    - Security         | Yes  (b)     |              |               |

 Notes:
 a. With cisco equipment, if there are both Ethernet and Token Ring
    interfaces, then DECnet cannot be run simultaneously with either
    Novell IPX or XNS.  This restriction will be removed in Release 8.2.
 b. cisco provides filtering/permitting/denying certain packets
    only for IPX, XNS and Appletalk in the section listed above.

 8. Management         |              |              |               |
    - Central managed  | Yes          | Yes          | Yes           |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3        | 80286 AT      |
      - External       |              |              |               |
        software (b)   | No      (c)  | No           | No            |
      - X netmap       | Yes          | Yes          |               |
        - Telnet to    |              |              |               |
          device  (d)  | Yes          | No           |               |
      - X interactive  | Yes          |              |               |
        performance    |              | Yes          |               |
      - History stats  | Yes          | No           |               |
      - Report writer  | Yes     (c)  | No           |               |
      - Alerts    (e)  | No           | No           |               |
      - User defined   |              |              |               |
        extensions (m) | Yes          | No           |               |
    - Usage stats      | Yes          | Yes  (f)     |               |
    - Direct MIB access| No           | Yes          |               |
    - PING             | Yes          | Yes  (g)     | No            |
    - Traceroute       | Yes          | No           |               |
    - Telnet           | Yes     (h)  | Yes  (i)     | Yes (n)       |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      | No            |
    - NICE        (j)  | No           | No           | No            |
    - Decnet connect   | No           | No           | No            |
    - Passwords (k)    | Yes          | Yes          | Yes           |
    - Netview support  |              |              |               |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          | Yes           |

 Notes:
 b. External software refers to the need to have some external
    software package available in order to run SNMP monitoring.
 c. cisco requires the Sybase database system in order to run their
    NMS software.  This package is bundled with their NMS.
 d. Ability to click on an icon on the X-11 network map and open
    a telnet connection to the device in question.
 e. Alerts refers to the ability to define a preset limit for a
    specific MIB variable at which point the SNMP monitoring software
    will present a window on top of the network map informing the
    network operator of the problem.
 f. Wellfleet interactive usage statistics are only for (ISO model)
    level 2.  Upper level statistics (such as RIP, UDP, TCP, Decnet
    HELLO, ARP) are not available.
 g. Wellfleet PING command stops after first failure and waits for
    user response.  This makes it very hard to check the total
    percentage of line failures over a short period of time.
 h. cisco is limited to 5 incoming Telnet sessions but has no
    limitation on outgoing Telnet sessions.
 i. Wellfleet Telnet is limited to one incoming and one outgoing
    session.
 j. NICE refers to the ability of the router to accept "SET EXECUTOR"
    as well as initiate a "SET EXECUTOR" to a remote host.
 k. Passwords refers to the ability to limit certain configuration and
    customization options only to those users who supply a password.
 l. cisco command is not an EXEC command but actually requires a
    configuration change to disable a line.
 m. The ability for the NMS software to add other vendor MIBs to their
    database, in order to manage these particular hardware units.
 n. Proteon is limited to 2 incoming and no outgoing sessions.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          | Yes           |
    - LAN              | Yes          | Yes          | Yes           |
    - Link             | Yes          | Yes          | Yes           |
    - Decnet           | Yes          | Yes          | Yes           |
    - Tcp/Ip           | Yes          | Yes          | Yes           |
    - Event log        | Yes          | Yes          | Yes           |
    - Environmentals   | Yes          | No           | No            |

 Notes:
 a. Environmentals refers to the monitoring of variables such as
    fan, power supply, memory, temperature, etc.

 10. Performance  (a)  |              |              |               |
    - Router forward   | 2917    (b)  | 3757   (c)   | 902           |
    - Router filter (d)| 2279    (b)  | 3757         | 902           |
    - Bridge forward   |              |              |               |
    - Bridge filter    |              |              |               |
    - LAT compression  | Yes          | No           |               |

 Notes:
 a. Performance based on 256 byte packets, between separate
    interface cards, with no packet loss.  Numbers listed are in
    packets per second.  Numbers based on Bradner report, Harvard
    University, Sept 1989.  A revised benchmark is expected sometime in
    Sept 1990.
 b. cisco performance numbers based on AGS and CSC2 hardware.
 c. Wellfleet numbers may be higher but equipment was not able to
    generate packets faster than the LN.
 d. Filter is based on 10 packet filters enabled.

 11. Survivability     |              |              |               |
    - alternate power  |              |              |               |
      supply           | No           | Yes   (d)    | No            |
    - standby line  (a)| No           | No           | No            |
    - fault tolerant(b)| No           | No           | No            |
    - field tolerant(c)| No           | No           | No            |
    - broadcast storms | Yes          | No           | Yes           |

 Notes:
 a. Standby line refers to the ability to define a line that is to be a
    hot standby, in the event that the primary line goes down.  The
    software switches all traffic automatically to the backup line.
 b. Fault tolerant refers to having redundent systems that are normally
    in standby mode, and that are only called into active mode in the
    event that the primary system fails.  Various systems are the power
    supply, the fan, the bus, the controller cards, etc.
 c. Field tolerant refers to the ability to withstand harsh elements
    and conditions out in the "field."
 d. Alternate power supply only available in large Concentrator model.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Oct 90 15:03:34 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU>
To:        cisco@spot.colorado.edu, wellfleet@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu
Subject:   Router scorecard V1.6

                              CAVEATS
                              -------

    The following scorecard tries to compare various  multi-protocol
routers.   The  current  scorecard  mainly  contains information for
cisco and  Wellfleet but  any other vendor is welcome  to  send me a
complete set of  manuals for their  equipment so that  I can analyze
and update the scorecard.

    The fact of  the matter is  that certain features  and "gotchas"
only appear when testing the actual equipment.  I hope that the user
population of multi-protocol routers  will assist me in  making this
scorecard as comprehensive as possible so that people who follow  do
not have to go through what I have gone through.

    It was  difficult to  decide whether  to include  future release
notes  in  this  scorecard.   I  trust  the  user  population in the
Internet to take each promise for a "future feature" with a grain of
salt  and  to  keep  watch  on  the  vendors that indeed they follow
through with their  promises.  All too  often vendors state  certain
features will be available in a certain release and sometimes  their
deadlines slip.   It is  advised that  people should  not base their
decisions on the future release notes. [That was a long caveat].

    If you  have comments,  suggestions, additions,  or subtractions
or corrections, please send them to:

HANK@VM.TAU.AC.IL   or   HANK@TAUNIVM.BITNET    (but not to both!)

    The  scorecard will  be updated on a monthly basis.  This report
may be freely reproduced as long as nothing is altered or removed.

    If you read this report  and are not connected to  the Internet,
you can send your comments to:

Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

    [The above employer has nothing to do with this scorecard so  if
something bothers you about it, I take full responsibility.]

                          END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box.  I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
                  Comparison of Multiprotocol Routers
                           Henry Nussbacher
                             October 1990
                              Version 1.6


                       +--------------+--------------+---------------+
 Multiprotocol         | cisco AGS+   | Wellfleet LN | Proteon p4200 |
 Router                | Rel. 8.1(14) | Rel. 5.35    |               |
                       +--------------+--------------+---------------+
 1. General            |              |              |               |
    - # of slots       | 9            | 4            | 7             |
    - Processor        | 68020        | 68020        | 68020         |
    - Memory           | 4Mbyte       | 4Mbyte       | 2Mbyte        |
    - Updates via      | ROM, TFTP    | diskette,TFTP| diskette,TFTP |
    - Speed of bus     | 530Mb/sec (a)| 320Mb/sec    |               |
    - Boot from        |              |              |               |
      - ROM            | Yes          | No           | No            |
      - Net-boot       |              |              |               |
        - IP           | Yes          | No           | Yes           |
        - Decnet (MOP) | No           | No           | No            |
      - Diskette       | No           | Yes          | No            |
      - Another router | Yes          | No           | No            |
    - Volatile changes | Yes  (b)     | No           | Yes   (h)     |
    - CPU statistics   | Yes  (c)     | No           | Yes           |
    - Memory stats     | Yes          | No           | Yes           |
    - Ease of install  | Very easy    | menu driven  |               |
    - Documentation    | Difficult    | Skimpy       | Clear, orderly|
    - Autorestart (d)  | Yes          | Yes          | Yes           |
    - Restart for      |              |              |               |
      config changes   | No           | Yes          | Yes           |
    - Watchdog timer   | Yes          |              | Yes           |
    - Reboot time  (e) | 29 sec  (f)  |  60 sec      | 32 sec (i)    |
    - Power-up time (g)| 29 sec       | 120 sec      | 32 sec (i)    |

 Notes:
 a. Speed of old AGS bus is 160Mb.
 b. Volatile changes represents the ability of the router to accept a
    configuration change that is dynamic that only affects the current
    running system and once the system is rebooted, the change
    disappears.
 c. CPU statistics refers to the ability of the router to provide
    a monitoring facility to see what the CPU is doing and how often
    it is doing it.
 d. Autorestart in the event of a power failure.
 e. Reboot time refers to the amount of elapsed time needed to
    perform a logical restart (reboot) from the fastest available
    media.
 f. cisco timings are for older AGS system.
 g. Power-up time refers to the amount of elapsed time needed from
    the time of a power failure and recovery until the router is up and
    operational.
 h. Only available for DECnet and OSPF, and only for a subset of
    available parameters.
 i. Booting via Proteon's Intergrated Boot Device, with running
    diagnostics.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       | 7x10Mb        |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 8x10Mb       | No            |
    - 4Mb Token Ring   | 3x4Mb    (i) | 4x4Mb        | 7x4Mb         |
    - 16Mb Token Ring  | Rel 8.2  (j) | Rel 5.40 (c) | No            |
    - RS232            | 24x64kb      | 16x64kb      | 14x64kb       |
    - RS449            | 12x64kb      | 16x64kb      | 14x64kb       |
    - V.35             | 12x64kb      | 16x64kb      | 14x64kb       |
    - T1               | 12x1.544Mb   | 8x1.544Mb    | 14x1.544Mb    |
    - CEPT DS1 (2Mb)   | 12x2Mb       | 8x2Mb        | 12x2Mb        |
    - FDDI             | 2x100Mb      | Rel 5.50 (d) | 2x100Mb       |
      - DAS (Dual)  (e)| Yes          | Yes          | Yes           |
      - SAS (Single)   | Yes          | No           | Yes           |
    - Ultranet         | Rel 8.2   (k)|              |               |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          | 255           |
    - Card types  (g)  | 6E, 1E2S,    | 2E, 1E1S,    | 1E, 2S, 4S,   |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  | 1TR, .5F      |
                       | 1TR, 1F   (h)| 1TR2S, 4S,   |               |
                       |              | 1TR          |               |

 Notes:
 a. Each interface subsection represents the maximum number of LANs
    or WANS that can be configured for that particular subsection.
    It is possible to "mix and match" various subsections by reducing
    the upper limit.
 b. Thin Ethernet refers to a standard BNC connector available directly
    on the router.
 c. 4x16Mb.
 d. 1x100Mb.
 e. Dual is also known as Type A and Single is also known as Type B.
 f. Depends on memory limitations.
 g. Card types: E: Ethernet, S: Serial/Synchronous line
                TR: Token-Ring, F: FDDI
 h. The 6E and 1F cards are for the faster cBus only.
 i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
 j. To be supported in later release of Version 8.2.
 k. Ultranet support will be in a later release of 8.2 but will
    only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.

 3. Interface part II  |              |              |               |
    - Frame Relay (a)  | Rel 8.2      |              |               |
    - Ethernet         |              |              |               |
      encapsulation    |              |              |               |
      - Standard v2.0  | Yes          |              | Yes           |
      - IEEE 802.3     | Yes          |              | Yes           |
      - SNAP 802.2     |              |              |               |
        (RFC1042)      | Yes          | Yes          | No            |
    - Serial           |              |              |               |
      encapsulation    |              |              |               |
      - HDLC           | Yes          |              | Yes           |
      - LAPB           | Yes          |              | No            |
      - PPP (RFC1134)  | Yes          |              |               |
      - DDCMP          | No           | No           | No            |
      - X.25           | Yes          |              | Yes           |
        - SVC          | Yes          | Yes          | Yes           |
        - PVC          | Yes          | Yes          | Yes           |
    - Encryption   (b) | Pulse-time   |              |               |
    - Filtering by     |              |              |               |
      source/dest      | Yes          | Yes          | Yes           |

Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
   encrypting devices on various interfaces or circuits.
c. For CLNP only.

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          | Yes           |
    - ARP  (RFC826)    | Yes          | Yes          | Yes           |
    - RARP (RFC903)    | Yes          | No           | No            |
    - BOOTP (RFC951)   | Yes          | No           | No            |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          | Yes           |
    - ICMP             | Yes          | Yes          | Yes           |
    - Name-server      | Yes          | No           | No            |
    - Accounting       | Yes          | No           | No            |
    - MTU              | Yes          | No           | No            |
    - Security - IPSO  | Yes          | No           |               |
    - Static routing   | Yes          | Yes          | Yes           |
    - Source routing   | Yes          | No           | Yes           |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          | Yes           |
      - TCP            | Yes          |              |               |
      - UDP            | Yes          |              |               |
      - ICMP           | Yes          |              |               |
      - by protocol (b)| Yes   (a)    | Yes          |               |
    - Routing protocols|              |              |               |
      - RIP (RFC1058)  | Yes          | Yes          | Yes           |
      - EGP (RFC904)   | Yes          | Yes          | Yes           |
      - BGP (RFC1105)  | Yes          | No           |               |
      - Proprietary    | IGRP         | eRIP         | No            |
      - Filtering      | Yes          | No           | Yes           |
      - Default routes | Yes          | Yes          | Yes           |
      - OSPF           | Rel 9.0      | Rel 5.6      | Yes           |

 Notes:
 a. Can be done but is difficult and requires advanced knowledge of the
    specific protocols.
 b. Filtering by protocol can also be viewed as filtering by port
    number.

 5. DECNET             |              |              |               |
    - Phase IV Router  | Yes          | Yes          | Yes           |
    - Area Router      | Yes          | No           | Yes           |
    - Phase IV+   (a)  | Rel 8.2      | No           |               |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      |              |               |
    - Phase V          | Yes     (b)  | No           | Yes     (b)   |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           | No            |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          | Yes           |
      - area-max-hops  | Yes          | Yes          | Yes           |
      - max-address    | Yes          | Yes          | Yes           |
      - max-area       | Yes          | Yes          | Yes           |
      - max-cost       | Yes          | Yes          | Yes           |
      - max-hops       | Yes          | Yes          | Yes           |
      - max-visits     | Yes          | Yes          | Yes           |
      - router-priority| Yes          | Yes          | Yes    (e)    |
      - hello-timer    | Yes          | Yes          | Yes           |
      - routing-timer  | Yes          | Yes          | Yes           |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           | Yes           |
      - by protocol    | No           | No           | No            |
      - by object      | No           | No           | No            |
      - routing        | Yes    (d)   | No           | Yes    (d)    |
    - MOP              | Bridged      | Bridged      | Yes    (f)    |
    - Static routing   | No           | No           | No            |
    - Max routing table| 1023         | 1023         | 1023          |
    - Max # of broad.  |              |              |               |
      router adjencency| 32           |              |               |

 Notes:
 a. Phase IV+ refers to path-split capability.  This means "normal" and
    not "interim".  Normal allows out-of-sequence packets to arrive.
    Interim does not allow out-of-sequence packets to arrive.
 b. cisco claims that it's ISO CLNS support is compatible with Decnet
    Phase V.
 c. Address Translation Gateway is the ability to connect two separate
    Decnet networks with overlapping addresses.
 d. It is not possible to filter out of area addresses.  It is only
    possible to filter an entire area or addresses within one's area.
 e. On a per circuit basis, as required by DECnet specs.
 f. MOP System ID.

 6. Bridging           |              |              |               |
    - Local bridging   | Yes          | Yes          | No            |
      - LAVC      (a)  | Yes          | Yes          | No            |
    - Remote bridging  | Yes   (b)    | Yes          | No            |
    - Transparent      |              |              |               |
      - Learning       | Yes          | Yes          | No            |
      - Spanning tree  |              |              |               |
        (IEEE 802.1)   | Yes          | Yes          | No            |
    - Priority    (c)  | Rel 8.2      | No           | No            |
    - Filtering        |              |              |               |
      - Multicast      | Yes          | Yes          | No            |
      - Protocol       | Yes          | Yes          | No            |
      - Source/dest    | Yes          | Yes   (g)    | No            |
      - Masking   (d)  | No           | No           | No            |
    - Load sharing     | Yes   (e)    | Yes          |               |
    - Token Ring       |              |              |               |
      - Source route   | Yes          |              | Yes           |
      - Multi-ring (f) | Yes          |              | No            |

 Notes
 a. LAVC refers to the ability to act as a local bridge between two Vax
    clusters using the DEC LAVC protocol.
 b. cisco does not support bridging over X.25 or LAPB.
 c. Priority refers to the ability to assign a priority to a specific
    protocol so that that protocol is sent faster than any other
    protocol over a specific circuit/interface.
 d. Masking refers to the ability to specify some pattern string to be
    matched within the packet, so that the user can specify almost any
    filter.
 e. cisco load sharing (balancing) is on a per-node basis and not on
    a per packet basis.  That means that over 2 parallel serial lines
    the cisco will automatically allocate 50% of the learned Ethernet
    addresses to one line and the other 50% to the other line.
 f. Multi-ring refers to bridging between multiple Token Ring networks
    (all hosts must understand RIF).
 g. Wellfleet can only filter on destination address and not on source
    address.

 7. Other protocols    |              |              |               |
    (ability to route) |              |              |               |
    - XNS              | Yes  (a)     | Yes          | Yes           |
      - UB derivitive  | Yes          |              | Yes           |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          | Yes           |
      - Phase 2        | Rel 8.2      | Rel 5.40     | No            |
      - Tokentalk      | Rel 8.2      | Yes          | No            |
      - Ethertalk      | Yes          | Yes          | Yes           |
      - Localtalk      | No           |              | No            |
      - RTMP           | Yes          | Rel 5.40     | Yes           |
      - AARP           | Yes          | Rel 5.40     | Yes           |
      - NBP            | Yes          | Rel 5.40     | Yes           |
      - EP             | Yes          | Rel 5.40     | Yes           |
      - ATP            | Yes          |              | Yes           |
      - ZIP            | Yes          | Rel 5.40     | Yes           |
      - DDP            | Yes          | Yes          | Yes           |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           | Yes           |
      - ISO 9542 ES-IS | Yes          | No           | Yes           |
    - Apollo Domain    | Yes          | No           | Yes           |
    - Novell IPX       | Yes  (a)     | Yes          | Yes           |
    - Banyan Vines     | Rel 8.2      |              |               |
    - X.25             | Yes          | Yes          | Yes           |
      - bridging       | Rel 9.0      | Yes          | No            |
      - routing        | Yes          | Yes          | Yes           |
      - switching      | Yes          | Yes ???      | No            |
    - Security         | Yes  (b)     |              |               |

 Notes:
 a. With cisco equipment, if there are both Ethernet and Token Ring
    interfaces, then DECnet cannot be run simultaneously with either
    Novell IPX or XNS.  This restriction will be removed in Release 8.2.
 b. cisco provides filtering/permitting/denying certain packets
    only for IPX, XNS and Appletalk in the section listed above.

 8. Management         |              |              |               |
    - Central managed  | Yes          | Yes          | Yes           |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3        | 80286 AT      |
      - External       |              |              |               |
        software (b)   | No      (c)  | No           | No            |
      - X netmap       | Yes          | Yes          |               |
        - Telnet to    |              |              |               |
          device  (d)  | Yes          | No           |               |
      - X interactive  | Yes          |              |               |
        performance    |              | Yes          |               |
      - History stats  | Yes          | No           |               |
      - Report writer  | Yes     (c)  | No           |               |
      - Alerts    (e)  | No           | No           |               |
      - User defined   |              |              |               |
        extensions (m) | Yes          | No           |               |
    - Usage stats      | Yes          | Yes  (f)     |               |
    - Direct MIB access| No           | Yes          |               |
    - PING             | Yes          | Yes  (g)     | No            |
    - Traceroute       | Yes          | No           |               |
    - Telnet           | Yes     (h)  | Yes  (i)     | Yes (n)       |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      | No            |
    - NICE        (j)  | No           | No           | No            |
    - Decnet connect   | No           | No           | No            |
    - Passwords (k)    | Yes          | Yes          | Yes           |
    - Netview support  |              |              |               |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          | Yes           |

 Notes:
 b. External software refers to the need to have some external
    software package available in order to run SNMP monitoring.
 c. cisco requires the Sybase database system in order to run their
    NMS software.  This package is bundled with their NMS.
 d. Ability to click on an icon on the X-11 network map and open
    a telnet connection to the device in question.
 e. Alerts refers to the ability to define a preset limit for a
    specific MIB variable at which point the SNMP monitoring software
    will present a window on top of the network map informing the
    network operator of the problem.
 f. Wellfleet interactive usage statistics are only for (ISO model)
    level 2.  Upper level statistics (such as RIP, UDP, TCP, Decnet
    HELLO, ARP) are not available.
 g. Wellfleet PING command stops after first failure and waits for
    user response.  This makes it very hard to check the total
    percentage of line failures over a short period of time.
 h. cisco is limited to 5 incoming Telnet sessions but has no
    limitation on outgoing Telnet sessions.
 i. Wellfleet Telnet is limited to one incoming and one outgoing
    session.
 j. NICE refers to the ability of the router to accept "SET EXECUTOR"
    as well as initiate a "SET EXECUTOR" to a remote host.
 k. Passwords refers to the ability to limit certain configuration and
    customization options only to those users who supply a password.
 l. cisco command is not an EXEC command but actually requires a
    configuration change to disable a line.
 m. The ability for the NMS software to add other vendor MIBs to their
    database, in order to manage these particular hardware units.
 n. Proteon is limited to 2 incoming and no outgoing sessions.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          | Yes           |
    - LAN              | Yes          | Yes          | Yes           |
    - Link             | Yes          | Yes          | Yes           |
    - Decnet           | Yes          | Yes          | Yes           |
    - Tcp/Ip           | Yes          | Yes          | Yes           |
    - Event log        | Yes          | Yes          | Yes           |
    - Environmentals   | Yes          | No           | No            |

 Notes:
 a. Environmentals refers to the monitoring of variables such as
    fan, power supply, memory, temperature, etc.

 10. Performance  (a)  |              |              |               |
    - Router forward   | 2917    (b)  | 3757   (c)   | 902           |
    - Router filter (d)| 2279    (b)  | 3757         | 902           |
    - Bridge forward   |              |              |               |
    - Bridge filter    |              |              |               |
    - LAT compression  | Yes          | No           |               |

 Notes:
 a. Performance based on 256 byte packets, between separate
    interface cards, with no packet loss.  Numbers listed are in
    packets per second.  Numbers based on Bradner report, Harvard
    University, Sept 1989.  A revised benchmark is expected sometime in
    Sept 1990.
 b. cisco performance numbers based on AGS and CSC2 hardware.
 c. Wellfleet numbers may be higher but equipment was not able to
    generate packets faster than the LN.
 d. Filter is based on 10 packet filters enabled.

 11. Survivability     |              |              |               |
    - alternate power  |              |              |               |
      supply           | No           | Yes   (d)    | No            |
    - standby line  (a)| No           | No           | No            |
    - fault tolerant(b)| No           | No           | No            |
    - field tolerant(c)| No           | No           | No            |
    - broadcast storms | Yes          | No           | Yes           |

 Notes:
 a. Standby line refers to the ability to define a line that is to be a
    hot standby, in the event that the primary line goes down.  The
    software switches all traffic automatically to the backup line.
 b. Fault tolerant refers to having redundent systems that are normally
    in standby mode, and that are only called into active mode in the
    event that the primary system fails.  Various systems are the power
    supply, the fan, the bus, the controller cards, etc.
 c. Field tolerant refers to the ability to withstand harsh elements
    and conditions out in the "field."
 d. Alternate power supply only available in large Concentrator model.
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 18:56:14 GMT
From:      bu.edu!buit13!kwe@uunet.uu.net  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Maintainability of TELNET ...
In article <9010021049.AA06180@WLV.IMSD.CONTEL.COM>
 mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
>...
>  1.  Do routers generally have the capability to re-route traffic over
>      an alternate circuit?
  ...
>  4.  Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
>      alleviate problems?
>
	One problem with routing fallback has to do with the time
constants of the routing protocols (and link level fault protocols, if
any) and the time constant of the failure.  Sounds to me like crypto
sync loss is a fast time constant sort of error.

	This begs the question of whether the routing protocol should
spend the time required to re-route or whether it should hold off and
wait for the link to come back up.  With the advent of open link state
protocols which converge "instantly", perhaps this point is becoming
moot, but with distance vector protocols it is very hard to deal with
link level state "flapping" side effects and still keep routing
traffic down.

	Same thinking applies to TCP or Telnet timers.  Should they
wait a short time or a long time?  How should they treat redirects and
black holes?  I think that should be up to the application, since mail
usually has a different idea than telnet would.  Put me in the "hate
TCP/IP keepalives" camp.

	--Kent
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 20:58:54 GMT
From:      crash!ncr-sd!ncrcae!wingo@nosc.mil  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   network file backup

Does anyone know of a network based (TCP/IP) file system back-up/restore 
product that is currently available for UNIX 5.3 or 5.4. How about one that
would also be available on OS/2 based systems.....

We are very interested in this type of product....

Thanks in advance for your help.....

David Wingo, NCR Corp System 3000
voice 803-791-6476
email: wingo@Columbia.NCR.COM
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 90 21:46:58 GMT
From:      julius.cs.uiuc.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!wls@apple.com  (Bill Stapleton)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM 9000 TCP/IP, lpr?

Another campus entity is looking into purchasing an IBM 9000 system, which
would run VM, and comes with some sort of TCP/IP package.  They want to be
sure it works with our (BSD) network, especially for printing.  Does anybody
know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol?
Any information is most appreciated.

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 00:58:36 GMT
From:      snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!srcsip!pserv!stevem@bloom-beacon.mit.edu  (Steve Mestad)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Rarpd
I am looking for source for the rarp daemon.  I would like it for
HP-UX 7.0 on the HP 9000 series 300 systems but at this point I would
be willing to take any source and hope for the best.

Please let me know where I can find this beastie.  Thanks.  SM

stevem@cfsmo.honeywell.com
stevem%pserv@src.honeywell.com (if the above is ill from your location)
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Oct 90 08:34:49 MDT
From:      Greg Satz <satz@cisco.com>
To:        brooks@apple.com (Kevin Brooks)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: HP TCP/IP router/bridge?
The cisco router will do this and has for the last three year. Drop a note
to customer-service@cisco.com for more information.

Greg
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Oct 90 11:42:22 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mailrus!sharkey!cfctech!alexb@uunet.uu.net  (Alex Beylin)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
If you want Named Pipes, you need LAN Manager, which means Netbios,
which means RFC 1001/1002 if you want it over TCP/IP.  I don't know
of any RFC 1001/1002 Netbioses which implement "p-nodes" or
"m-nodes", so you can't use a conventional router.  TWG has a hack
which uses static client configuration to avoid this problem, but a
cleaner alternative (IMHO) is to use the cisco SLIP concentrator,
which keeps the clients on the same net/subnet as its attached
ethernet (fine as long as your servers are on that ethernet).

If you use the latter approach, you can use our PC/TCP as well as
TWG's WIN/PC.  I can never remember if Beame & Whiteside has an RFC
Netbios, but none of the others (Excelan, U-B, CMC, Interlan, Bridge)
support SLIP.

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

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Oct 90 13:12:12 PST
From:      "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu>
To:        Alex Beylin <mailrus!sharkey!cfctech!alexb@UUNET.UU.NET>, tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
>A project have come up around here that require multiple
>PCs to get dial-in access to the TCP/IP network.  One of the
>major requirements is support for Named Pipes down to the PC.
>Current plan is to use SLIP and a router with dial-in ports.
>
>Would someone care to recommend a PC package that would do good
>SLIP emulation and a router that would be suitable for this job?
>

Alex:
We intend on implementing a similar system here, although we don't
have the named pipes requirement.  We have a cisco terminal server
that can be configured with several dial-in ports.

The software angle is a bit more complex.  As I understand it, the
remote PC user will need to use a communications package like kermit
or xmodem to connect to the terminal server.  A commercial (such as
FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package
can then be run over SLIP.  FTP's package can be ordered with SLIP,
and there is a SLIP driver in Clarkson's pd packet driver distribution.

I should point out that cisco's box can provide the telnet connection
itself, so that a remote PC user can dial in and start a telnet session
from the server without having the TCP-IP software installed on the PC.
However, if need 3270 emulation (as we do), the current release of the
cisco's software won't do the job.

I hope my more knowledgeable colleagues will correct me if I have made
any egregious errors...

Don Proctor                            <spgdrp@uccvma.ucop.edu>
Information Systems & Computing        <spgdrp@uccvma.bitnet>
University of California               415/987-0356
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 05:27:08 GMT
From:      munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net  (Michael Paddon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
From article <266@aldetec.oz.au>, by mawson@aldetec.oz.au (Graeme Mawson):
> 
> We are presently experimenting with the TCP/IP protcol suite over an Ethernet
> LAN.  A useful guide to TCP/IP by Comer seems to suggest that TCP segment
> size is user-definable.  Is this true?  Does anyone know how to define it?

It surely is. On BSD based systems, the macro TCP_MSS is defined in
/usr/include/netinet/tcp.h. This may be changed with impunity since the
negotiation undergone at connection setup time chooses the smaller of
the segment sizes supported by each implementation.

There is not much point setting TCP_MSS to be greater than
	(maximum IP packet size - IP header size - TCP header size)
[536 octets] since IP fragmentation will take place. Receipt of a
fragmented packet is an all or nothing proposition; a good thing to
avoid for throughput reasons.

In general, the BSD TCP parameters in tcp.h and tcp_timers.h are
close to optimal for ethernet (default RTT is a little pessimistic,
but that is so the latter stages of backoff work properly). I found
I had to do a fair bit of tuning to get everything right for a
SLIP environment with flakey link hardware.

					Michael

-------------------------------------------------------------------
|                     |     Internet: paddon@meo78b.enet.dec.com  |
|                     |     ACSnet:   mwp@ubeaut.oz.au            |
|  Michael Paddon     |     ACSnet:   mwp@munnari.oz.au           |
|                     |     EasyNet:  meo78b::paddon              |
|                     |     Voice:    +61 3 895 9392              |
-------------------------------------------------------------------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Oct 90 13:36:01 PST
From:      "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu>
To:        tcp-ip-relay@NIC.DDN.MIL, tcp-ip@nic.ddn.mil
Subject:   Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
>I am running a Sun Sparcstation and can communicate with the VAX using
>telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
>solution to my problem would be a telnet-like program which accepts a
>script containing expect/send pairs much like UUCP and some PC
>communications programs. Does such a program exist?
>
>I would also appreciate any suggestions of alternate solutions.
>
We run TGV's MultiNet on our VMS machine.  It does a remarkable job of
bringing Unix/Ultrix connectivity to the VMS world.

Don Proctor                            <spgdrp@uccvma.ucop.edu>
Information Systems & Computing        <spgdrp@uccvma.bitnet>
University of California               415/987-0356
Office of the President

The opinions expressed do not necessarily reflect the opions of my
employer. The University of California does not endorse any commercial
products mentioned.
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed 3 Oct 90 14:26:43-PDT
From:      VANCE@TGV.COM (Icarus)
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
>I am running a Sun Sparcstation and can communicate with the VAX using
>telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
>solution to my problem would be a telnet-like program which accepts a
>script containing expect/send pairs much like UUCP and some PC
>communications programs. Does such a program exist?

One solution would be to put a TCP/IP package that supports rsh on your VAX. 
There are several that do (MultiNet, WIN/TCP, Fusion, possibly others...)

Scripted TELNET is another issue.  I don't know of any of the IP for VMS (or
for other platforms for that matter) that support this.

-----Stuart
-------
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Oct 90 18:48 MST
From:      WIMMER@Arizona.edu
To:        TCP-IP@NIC.DDN.MIL
Subject:   UN-Subscribe
Apologies to the Network for posting this here.

Please drop me from this list.

Terry Wimmer

Wimmer@rvax.ccit.arizona.edu            (old account address)
         or 
Wimmer@Arizona.edu                      (current address)


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 16:24:46 GMT
From:      usc!snorkelwacker!ai-lab!ai.mit.edu!dms@ucsd.edu  (David M. Siegel)
To:        tcp-ip@nic.ddn.mil
Subject:   Heathkit Weather Computer (IDW5001)
We have just ordered a Heathkit IDW5001 weather computer.  Our plans are
to make the readings from the computer available over our network.  It
would be nice to use a "standard" weather TCP/UDP protocol for this
purpose.  Ideally, all Internet sites with weather data could support
this protocol.  The protocol should be extensible, since it is hard to
anticipate all types of weather data that people might have.

I'm wondering, does such a protocol exist?

Also, does anyone else have IDW5001 weather computers.  We'd be
interested in obtaining your software to interface to the computer, and
for client programs.  Our plans are to run it on a Unix box, connected
via the RS232 port. 

-Dave
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 19:23:49 GMT
From:      eru!hagbard!sunic!dkuug!resam!andrew@bloom-beacon.mit.edu  (Leif Andrew Rump)
To:        tcp-ip@nic.ddn.mil
Subject:   Does anybody know LM-X or Lackman?
Do any one of you know where we can get LM-X (Lan Manager) software
for the 386-UNIX System V rel 4 running on top of TCP/IP.

We would also like to know the address of a company called Lackman
who supplies TCP/IP software for UNIX systems.

Thank you in advance

Leif Andrew


Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark
UUCP: andrew@ambra.dk, phone: +45 39 27 11 77                /
Currently at Scandinavian Airline Systems                =======/
UUCP: andrew@resam.dk, phone: +45 32 32 22 79                \
SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark

> > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 20:07:49 GMT
From:      att!cbnewsk!lih@ucbvax.Berkeley.EDU  (andrew.a.lih)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: quick check for available host
In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes:
> What is a quick way for a shell script to find out if a networked
> host is currently available?

If you just want to know if the host is alive, then the 'ping'
program will suffice.  It basically sends packets over to the
host you specify and returns the round trip time for the
packet.  Most of the time it is used to detect delays and
transmission times, but in this case you can use it to see
if the machine is up.

/lih

AT&T Bell Labs
Middletown, NJ
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 20:15:35 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!kriger@ucsd.edu  (Sidney Kriger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes:
>For routers see cisco or there are terminal servers that support SLIP.
>I worked for an outfit that sold cisco and the company I work for now
>sells the Encore Annex II.  
>
>encore (terminal server with slip) 
>617-460-0500
>
>      *  John E. Allen - Intergraph Corporation -  (205) 730-8627  *
>      *                   System Sales Support                     *
>      *           ingr!b23b!allen!jallen@uunet.uu.net              *  

Xylogics now manufactures the Annex II terminal server and has for about
2 years, not Encore.    800-225-3317

Sidney Kriger
Xylogics, Inc.             voice:  617-272-8140 
53 Third Ave.              fax:    617-273-5392
Burlington, MA  01803      email:  kriger@Xylogics.COM
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 20:27:45 GMT
From:      bcstec!bcstec.uucp@uunet.uu.net  (Charles Derykus)
To:        tcp-ip@nic.ddn.mil
Subject:   Nameservice questions
I have several questions regarding nameserver:

  (1) Can nameservice resolve reverse translation queries "up the tree"
      towards the root domain if the domains of the requested node and
      the requesting node are at the same level, e.g.

      Nameserver Node		Domain
      ---------------		------
	cabbage			vegetable
	parsley			herb.vegetable
	carrot			underground.vegetable

       can "carrot" ask "cabbage" to reverse translate an I.P. in 
       "herb.vegetable"  and if so, how?
		
       We have gotten it to work only by specifying in the named.boot
       on carrot a line like the one below where 192.33.72.10 is the
       I.P. of parsley
     
       secondary	72.33.192.in-addr-arpa	192.33.72.10  herb.bak

       In other words,  carrot seems to have to know that parsley is
       authoratative for the herb.vegetable domain and doesn't seem to be 
       able to pull it down from a server such as cabbage in a higher
       domain.
   (2) A named.rev with multiple $ORIGIN lines worked fine on out primary
       nameserver for a while but then the secondary nameserver starting
       breaking. The only way we get it working now is by specifying separate
       reverse translation files for each $ORIGIN line, e.g.

       in the primary's named.boot:    

       primary	207.128.in-addr.arpa		herb.207.128.in-addr.arpa
       primary	79.33.192.in-addr.arpa		herb.79.33.192.in-addr.arpa


       in the secondary's named.boot:   (primary's I.P. is 128.207.254.44)

       secondary  207.128.in-addr.arpa		128.207.254.44
       secondary  79.33.192.in-addr.arpa	128.207.254.44

       Does nameservice break if these separate reverse files exceed some
       limit- either in number of files or memory capacity- as the 
       "named.rev" file apparently does? 

Thanks for listening. Any help greatly appreciated.        



Charles DeRykus				Internet:   ced@bcstec.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced
Renton, WA.  M/S 6R-37			(206) 938-4520 (home)
(206) 234-9223
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 21:12:12 GMT
From:      SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP, IP Routers and Named Pipes

>A project have come up around here that require multiple
>PCs to get dial-in access to the TCP/IP network.  One of the
>major requirements is support for Named Pipes down to the PC.
>Current plan is to use SLIP and a router with dial-in ports.
>
>Would someone care to recommend a PC package that would do good
>SLIP emulation and a router that would be suitable for this job?
>

Alex:
We intend on implementing a similar system here, although we don't
have the named pipes requirement.  We have a cisco terminal server
that can be configured with several dial-in ports.

The software angle is a bit more complex.  As I understand it, the
remote PC user will need to use a communications package like kermit
or xmodem to connect to the terminal server.  A commercial (such as
FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package
can then be run over SLIP.  FTP's package can be ordered with SLIP,
and there is a SLIP driver in Clarkson's pd packet driver distribution.

I should point out that cisco's box can provide the telnet connection
itself, so that a remote PC user can dial in and start a telnet session
from the server without having the TCP-IP software installed on the PC.
However, if need 3270 emulation (as we do), the current release of the
cisco's software won't do the job.

I hope my more knowledgeable colleagues will correct me if I have made
any egregious errors...

Don Proctor                            <spgdrp@uccvma.ucop.edu>
Information Systems & Computing        <spgdrp@uccvma.bitnet>
University of California               415/987-0356

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 21:36:01 GMT
From:      SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a program like telnet, but driven by a script?

>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
>I am running a Sun Sparcstation and can communicate with the VAX using
>telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
>solution to my problem would be a telnet-like program which accepts a
>script containing expect/send pairs much like UUCP and some PC
>communications programs. Does such a program exist?
>
>I would also appreciate any suggestions of alternate solutions.
>
We run TGV's MultiNet on our VMS machine.  It does a remarkable job of
bringing Unix/Ultrix connectivity to the VMS world.

Don Proctor                            <spgdrp@uccvma.ucop.edu>
Information Systems & Computing        <spgdrp@uccvma.bitnet>
University of California               415/987-0356
Office of the President

The opinions expressed do not necessarily reflect the opions of my
employer. The University of California does not endorse any commercial
products mentioned.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 90 21:48:47 GMT
From:      issm!wraith.wtp.contel.com!powell@uunet.uu.net  (Mike Powell "CFS Net Ops")
To:        tcp-ip@nic.ddn.mil
Subject:   Network Monitors/Managment ... again (repost)
Since the first one appears to have gone to /dev/null due to a missing
Date:, we will try again....

We are in the process of evaluating Network Monitor/Management packages.
I missed most of the previous discussion.

We have looked at/read glossies from Cisco, Cabletron, Excelan (Novell),
Silicon Graphics, ACC, and Micro Technologies (inhouse demo, high 
pressure salesman). I've only read a short article about the HP stuff.
MT is the only one we have taken an in-depth look at, but we are
working on others.

Three Questions:
1) anybody out there dealt with or have installed and operating any of
   these packages? how was the sales and technical staff? MT seems like
   they will eventually have a good product, but the level of the
   visible technical personnel is less than what I would expect of a
   major player in this game.
2) are the respective companies product groups reading this stuff?
   I would like to hear from you (I've already heard from two).

3) has anyone considered piecing one entity from one vendor with another?
Direct replys appreciated, I will post a summary.
Thanks,
Mike
--
Mike Powell PPASEL
"arp, arp, arp" The mating call of the lonely packet.
Disclaimer: I speak for myself. No relation to the DUAT folks.
internet: powell@wraith.wtp.contel.com  Usenet: {contel-fss}!powell
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      ljm@mercury.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re:  SLIP, IP Routers and Named Pipes

>A project have come up around here that require multiple
>PCs to get dial-in access to the TCP/IP network.  One of the 
>major requirements is support for Named Pipes down to the PC.
>Current plan is to use SLIP and a router with dial-in ports.
>
>Would someone care to recommend a PC package that would do good
>SLIP emulation and a router that would be suitable for this job?
>

Given your Named Pipes requirement, you actually have a much more
fun problem to solve.  You need a TCP/IP with support for not only
SLIP but also NetBIOS over TCP/IP which works through IP routers.  I
think we are currently the only TCP/IP product with both, but I think
FTP Software will be able to provide a NetBIOS which works through
routers in the near to medium future.

By the way, I do have to ask.  Why Named Pipes?

enjoy,
leo j mclaughlin iii
ljm@twg.com

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Oct 90 09:40:01 pdt
From:      Walter Underwood <wunder@hpsdel.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: HP TCP/IP router/bridge?
   Does anyone know of a bridge or router that will allow HP hosts running
   TCP/IP which speak IEEE style packets (802.2 encapsulated) to
   communicate with ethernet style IP implementations?

I've answered Kevin separately, but here is the info for everyone
else:

  1. The old-style HP 802.2/802.3 encapsulation pre-dates SNAP.  It
     uses the SAP originally reserved for IP (06) and uses a separate
     protocol for address resolution (Probe).  All this design was
     done back in 1981-82, when no one but the 802 committee and HP
     were interested in 802.

  2. HP does not encourage new implementations of HP 802 and Probe,
     because there are standard, and thus better, alternatives.

  3. All HP products now support Ethernet and ARP, so no one has to
     worry about the HP 802 encapsulation anymore.  Just upgrade to
     the latest networking bits.

wunder
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Oct 90 10:26:00 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        issm!wraith.wtp.contel.com!powell@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Network Monitors/Managment ... again (repost)

My experience is with Sun Microsystems, Inc. Sun Network Management
product (SNM) and HP's network management system.

I have spent a lot of time using SNM and find it useful.  It is
especially good at allowing for the incorporation of user defined
applications.  However, it's many features and seemingly infinite
configuration capabilities are not for the novice.

HP has a good product which should be the network management
answer for 85 percent of the networks out there.  The user interface
is easy.  It can learn about the networks it is attached to and provides a
number of useful problem solving features.

Phil
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 14:02:43 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Keith Jackson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP info wanted
NASA Lewis has the KNET product running on our VM system and from what I 
gather it has not been entirely happy.  TCP/IP was just installed on the
MVS system and the same product was also installed on VM replacing KNET.

Sorry about being so vaque, but I not in charge of those systems.  If you 
would like more info, give my a call and I can get you in touch with the
appropriate system people.

--
-----------------------------------------------------------------------------
Keith Jackson                  |     phone: 216-433-5105 or
Sverdrup Technology, Inc       |            216-891-2946
NASA Lewis Research Center     |     email: vvkmj@spica.lerc.nasa.gov
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Oct 90 18:32:40 EDT
From:      fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
To:        TCP-IP@NIC.DDN.MIL
Subject:   Reply to network file backup
We back up our two Sun 3/60 workstations to a CDC Cyber 840 by using the
standard "dump" command with the output directed to a NFS-mounted file on
the Cyber.  We do incremental dumps every night and full dumps once per week.
It's all automatic - controlled by a crontab entry.

This is a very efficient way of doing it - we can back up 100 megabytes
in about 25 minutes, all unattended.

You also have to back up the root partition to tape once in a while in case
you have to do a full restore.

Try it, you'll like it!

   - Bob Fillmore
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 15:38:42 GMT
From:      uokmax!munnari.oz.au!bruce!merlin!morgana!ianh@apple.com  (Ian Hoyle)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for DEPCA boards
nelson@sun.soe.clarkson.edu (Russ Nelson) writes:

>In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:

>      Can anyone point me to drivers, software, vendors to let me run
>   TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
>   cards.  Packet drivers compatible with NCSA, KA9Q, or even a commercial
>   package would be appreciated.

>Not yet, but the picture is coming into focus.  We've gone from
>"Digital refuses to release programming information" (that was just a
>rumor) to "How may I help get you the information you need to write a
>packet driver?"

Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards *but*
like PCSA, they only seem to provide full functionality on the supported PC
platforms ie IBM, Compaq etc. Clones of various types (with their myriad
BIOS's) just don't work at all sometimes. This seems to occur with 
monotonous regularity.

When it does work it's just fine :-)

			ian
--
                Ian Hoyle
     /\/\       Image Processing & Data Analysis Group
    / / /\      BHP Melbourne Research Laboratories
   / / /  \     245 Wellington Rd, Mulgrave, 3170
  / / / /\ \    AUSTRALIA
  \ \/ / / /
   \  / / /     Phone   :  +61-3-560-7066
    \/\/\/      FAX     :  +61-3-561-6709
                E-mail  :  ianh@bhpmrl.oz.au
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 16:01:28 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!ernie.viewlogic.com!curly!alan@ucsd.edu  (Alan Medsker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: network file backup
I think Legato, or some company with a similar name, has such a
product.  I don't see the ad in Sun Tech Journal that I think might
have been the last issue.

Alan
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan Medsker                                 Viewlogic Systems, Inc.
Voice: (508) 480-0881                        293 Boston Post Road West
Fax: (508) 480-0882                          Marlboro, MA  01752
Internet: amedsker@Viewlogic.COM
cc:Mail: Alan Medsker at Viewlogic
CI$: 76376,662
BIX: amedsker
2 Meters: WB0SQR
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
My opinions, of course.  And don't hold me to them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 16:14:35 GMT
From:      bywater!arnor!news@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   RE: IBM 9000 TCP/IP, lpr?
> Another campus entity is looking into purchasing an IBM 9000 system, which
> would run VM, and comes with some sort of TCP/IP package.  They want to be
> sure it works with our (BSD) network, especially for printing.  Does anybody
> know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol?
> Any information is most appreciated.
>
> --
> Bill Stapleton

IBM's TCP/IP Version 2 for VM product, due out at the end of the year,
includes an LPR client and LPD server. They have been written to
interoperate with 4.3 LPR/LPD and work fine.

If you're running our Version 1 product, I believe there is at least one
LPR/LPD implementation available, from Columbia University. I believe it
is free, but you'd have to contact them directly.

Bill Rubin
IBM TJ Watson Research
rubin@ibm.com
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Oct 90 14:35:48 +0100
From:      Denis.Russell@newcastle.ac.uk
To:        tcp-ip@nic.ddn.mil
Subject:   IP over X.25
I have an interest in routing IP datagrams over an X.25 network,
and  would  like  some information on the characteristics actual
products  (routers)  that  do  this.   The  kind  of  completely
hypothetical  (!)  setup that interests me is a set of say 50 to
100 mainly Ethernet LANs connected by a wide-area  X.25  network
with X.25 speeds in the 9.6kbps-64kbps-2Mbps range.
 
     In  the  worst  case  one might imagine a permanent 2 * N^2
network of X.25 calls, and clearly some intermediate plan  using
an hierarchy of routers would be preferable.
 
     However,  I  am  primarily  interested  in  an intermediate
scenario where the X.25 calls are established and  cleared  down
as required.  Clearly the practicality of this this would depend
on  the  traffic  pattern - but that is not the primary focus of
this query.  The primary focus is to find  out  whether  routers
that  support  X.25  as  an  IP  bearer  have  the right sort of
characteristic for such an application.  For example, one  would
require  support for a substantial number of such calls (10, 20,
30?), and the  automatic  clearing  down  of  calls  after  some
inactivity  timeout.   What  speed X.25 is supported (preferably
well beyond 64kbps)?  Does a  router  exploit  already  existing
inbound  X.25  calls  to send outbound datagrams or does traffic
always result in two calls, one used in  each  direction?   What
other questions are important?
 
     As  some  examples of the clarifications we would value are
that we understand that Sunlink supports only 4  X.25  calls  by
default,  but  can  be configured for any larger number.  On the
other hand, the calls are never cleared due to  inactivity.   We
don't  know  whether any routers exploit X.25 in a duplex manner
or whether two calls are always/sometimes/never set up.
 
     I'll  summarise  to  the  list  if there is interest in the
results.
 
Denis Russell           JANET:     Denis.Russell@uk.ac.newcastle
Computing Laboratory    Internet:  Denis.Russell@newcastle.ac.uk
The University
Claremont Road          Tel:   (+44) 91 222 8243
Newcastle upon Tyne     Fax:   (+44) 91 222 8232
       NE1 7RU          Telex: 53 65 4  UNINEW G
ENGLAND
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 16:18:09 GMT
From:      munnari.oz.au!murdu!viccol!gjocc@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Assigning IP addresses

   What is the best method for dynamically assigning IP addresses to PC's
 that are directly on our main ethernet?

 I have heard of the BOOTP and RARP protocols, so I guess what I need is BOOTP
 or RARP server software.

 Our main machines are VAX running VMS with  6.4 CMU TCP/IP and a Sequent
 S27 with DYNIX (BSD 4.2 UNIX). The PCs will probably be running
 NCSA telnet (which does RARP I believe).
 Any pointers to cheap software that can
 assign IP addresses to the PCs on our ethernet would be welcome.


Greg O'Sullivan (gjocc@csv.viccol.edu.au) 
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 17:10:05 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Does anybody know LM-X or Lackman?
In article <1990Oct3.192349.781@resam.dk>
   andrew@resam.dk (Leif Andrew Rump) writes:
>We would also like to know the address of a company called Lackman
>who supplies TCP/IP software for UNIX systems.

Results of WHOIS LACHMAN.COM:
----------------------------
Lachman Associates, Inc. (LACHMAN-DOM)
   1901 North Naper Boulevard
   Naperville, IL 60540-1031

   Domain Name: LACHMAN.COM

   Administrative Contact:
      Goldman, Ezra  (EG56)  ez%laidbak@SUN.COM
      (312) 505-9100 ext 233
   Technical Contact, Zone Contact:
      Alexander, Steve  (SA65)  stevea@i88.isc.com
      (708) 505-9100 ext 256

   Record last updated on 01-Sep-88.

   Domain servers in listed order:

   LAIZY.LACHMAN.COM		192.35.52.1
   LAIDBAK.LACHMAN.COM		192.35.52.2
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 18:14:00 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls49!linegar@ucbvax.Berkeley.EDU  (Derick Linegar)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet Address Uniqueness...

In trying to debug a problem we are having here with our file server with
2 ethernet boards connected to 2 *different* subnets on the same network,
our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet
address, obtained from the primary ethernet board. Of course, warning bells
are going of here. Now I've been searching the RFC and IEEE docs and I cannot
find any documentation that sort of says that Ethernet Addresses are assigned
to Ethernet boards, not hosts.

Anyone have an idea where it might be. I cannot go back to the vendor and
say 

  " .... well everyone *knows* that ethernet addresses *must* be unique..."


				-derick-
--
#include <disclaimer.h>
Derick Linegar,     Internet Systems 4P27,              Bell-Northern Research 
BITNET: LINEGAR@BNR.ca                                  P.O. Box 3511 Station C
UUCP:   ...uunet!bnrgate!bwdls49!linegar		Ottawa ONT. K1Y 4H7
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 19:01:08 GMT
From:      synoptics!sblair@decwrl.dec.com  (Steven Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: network file backup
We here use a very nive networked backup system called
"budtool(BackUp Daemon Tool) from Delta Microsystems in
Livermore Calif. Their phone is (415) 449-6881.

We do nightly -0- backups of 10 Gbytes of machines. Without
a hitch.

Has an incredibly felxible timing mechanism, history mechanisms,
scheduling tools, labeling tools, tape testing tools, and is
affordable.

We've got no releationship with them, than a very satisfied
customer<->vendor relationship. They have always answered calls
promptly, provided bug fixes promptly, and are generally very
nice folks.

The Legato Networker was evaluated here. We already had too
much invested in Delta Micro's solution to justify using it.
--
Steven C. Blair		Network Operations Center
SynOptics Communications Inc. Mountain View, California
INTERNET: sblair@synoptics.com  sblair@excalibur.synoptics.com
PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com
---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<----
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 19:59:18 GMT
From:      eplrx7!mcneill@louie.udel.edu  (Keith McNeill)
To:        tcp-ip@nic.ddn.mil
Subject:   Where is latest/greatest version of proxyarpd?
Subject says it....I tried comp.sources.wanted but I got no replies.

Thanks,

Keith
-- 
    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-9353/7395           |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357
--
The UUCP Mailer
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Oct 90 09:40:12 -0700
From:      jqj@hogg.cc.uoregon.edu
To:        fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reply to Ethernet Address Uniqueness...
Having the same MAC-level address for all interfaces (phrased differently,
associating the MAC-level address with the NODE rather than with the INTERFACE)
is part of the spec for both DECNET IV and XNS.  It falls out of a design that
has an algorithmic link between the MAC address and the protocol address.

Many people believe that having a protocol address that belongs to the node
rather than to the interface is a Good Idea, and that doing it the other way
was a bad decision in the IP suite.  I don't have a strong opinion, but I
do know that the XNS/DECNET way of doing things makes routing to multihomed
hosts easier.  In the IP world there is no unambiguous way to decide whether
2 IP addresses refer to the same host; sure I can look in the DNS, but there
is no guarantee that either or both addresses will be in the in-addr.arpa
tree.

Other people like the idea of algorithmic mapping from protocol to MAC
address.  It means that you don't need something like ARP, but it also
limits your flexibility substantially, especially on physical networks
like arcnet or 3mb Ethernet where the range of MAC addresses is very 
limited or hardwired in the interface.  And it of course fails to generalize
to cases where one needs to support multiple protocol stacks that each want
to change the MAC address based on the protocol address!
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 90 23:36:19 GMT
From:      pilchuck!amc-gw!morpho!erik@uunet.uu.net  (Erik Vollemaere)
To:        tcp-ip@nic.ddn.mil
Subject:   R/S 6000 raw I/O on Ethernet
We're attempting to establish communications between an IBM
R/S 6000 and a remote host with a CMC-20 board through Ethernet.
The communication must be done through non-encapsulated Ethernet
packets.  The idea is to send it a packet of type AM and to
wait untill we receive a -broadcast- packet from it of type
PU.  Then we send it a packet of type BS with the bootstrap
program.  The first portion of this works fine.  We open the
device (in this case /dev/ent0) and write() the packet.  The
remote host responds with alternating BR - and PU type packets
(verified through an Ethernet analyzer).  The problem is that
we do not "recognize" the packets from the remote host.  Reads
fail with an EIO error ("An I/O error occurred while reading
from the file system").  Even if we get the read to succeed
(suggestions?), we prefer not to have to analyze every packet
looking for our target.

The question is: what call(s) do we use and how do we set it up
to return an Ethernet broadcast packet of type PU and ignore
everything else?  We can accomplish this on different platforms
using raw socket I/O but those same calls fail on the R/S 6000.
The error messages are "Can't assign requested address" or
"Destination address required" (protocol interference).  IBM
recommended using the device driver directly (/dev/ent0) and
that works fine for the write portion of the problem, but we're
now stuck on the read portion.  We've been waiting for a solution
from IBM but so far their suggestions have not given us the
desired result.

___________________________________________________________________________

  Standard disclaimer... the above opinions are mine, all mine.

  Erik J.P. Vollemaere  (B) / (VL)
____________________________________________________________________________

amc-gw!morpho!erik
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 01:20:32 GMT
From:      agate!linus!philabs!ttidca!quad1!srhqla!avatar!kory@ucbvax.Berkeley.EDU  (Kory Hamzeh)
To:        tcp-ip@nic.ddn.mil
Subject:   Need a RARP Demon
Does anyone know where I can get my hands on source code for a Reverse
ARP demon to work on a Sun Sparcstation? I know Sun already has one, but
we have a special application where we need to slightly modify the Sun
version.

Thanks,
--kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 01:23:19 GMT
From:      bacchus.pa.dec.com!mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 9 interesting & challenging problems for Netman
In article <9009210641.AA20321@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>1. given the trace of packets between two end points on a LAN,
>and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol,
>detect protocol (elements of procedure) errors. (easier, do the same
>given ASN or XDR for packet formats:-)
>
>2. Given same data, automatically ascribe performance problems 
>to incorrect packet size, timeout, window etc...
>
This is similar to research reported on by Bruce L. Hitson in
"Knowledge-Based Monitoring and Control: An Approach to Understanding
the Behavior of TCP/IP Network Protocols", Proc. SIGCOMM '88.

This was a rule-based system, not a "specification-based" system,
but perhaps that is not such a big difference.

>4. Find a good way to visualise the "closeness" of hosts based on the
>frequency with which they communicate (this is non-trivial)
>
>5. Automatically draw a "tube" map (friendly/Metro) of the net given 
>the topography...

Jon sent his message before he attended SIGCOMM '90 last week, where
I gave a paper that touched on this topic.  This is "work in progress"
so it will be a while before I can publish a detailed paper.

>7. Interpret auto-correllation between packets from/to and/or
>same src/dst in a sensible fashion...

I suppose this depends on one's definition of "sensible", but I've
seen a few papers on this.  For example, Mark J. Lorence and M.
Satyanarayanan, "IPwatch: A Tool For Monitoring Network Locality",
Operating Systems Review 24:1 (January 1990).

These all seem to be fertile areas for research, as Jon has pointed out.

-Jeff
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 01:26:02 GMT
From:      asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Does anybody know LM-X or Lackman?
In article <1990Oct3.192349.781@resam.dk> andrew@resam.dk (Leif Andrew Rump) writes:
>Do any one of you know where we can get LM-X (Lan Manager) software
>for the 386-UNIX System V rel 4 running on top of TCP/IP.
>
>We would also like to know the address of a company called Lackman
>who supplies TCP/IP software for UNIX systems.

Lachman Associates -- the last address I have for them is 1901 N.
Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133.-- 
"Drive carefully."
"What is it with women and 'drive carefully'?  'No, I'm going to steer 
with my feet and read the comic paper.'"
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 01:29:20 GMT
From:      bacchus.pa.dec.com!mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA writes:
>To avoid fragmentation, can TCP MSS be equal to path MTU, or must
>it be less by some number of octets to allow for TCP and IP headers?
>If so, what is a good value?

The Path MTU Discovery document (now an Internet Draft, soon to be
an RFC if all goes well) says:

	  Note: The TCP MSS is defined to be the relevant IP datagram
	  size minus 40 [see RFC879].  The default of 576 octets for
	  the maximum IP datagram size yields a default of 536 octets
	  for the TCP MSS.

In other words, the TCP MSS should be at least 40 octets less than the
path MTU.

-Jeff
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Oct 90 08:51:58 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
Hi.

For further discussion of the TCP MSS see RFC 879.

--jon.

	Date: 5 Oct 90 01:29:20 GMT
	From: bacchus.pa.dec.com!mogul@decwrl.dec.com  (Jeffrey Mogul)
	Subject: Re: TCP segment size -- user defined?
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

	In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA
	writes:

	>To avoid fragmentation, can TCP MSS be equal to path MTU, or must
	>it be less by some number of octets to allow for TCP and IP headers?
	>If so, what is a good value?

	The Path MTU Discovery document (now an Internet Draft, soon to be
	an RFC if all goes well) says:

		  Note: The TCP MSS is defined to be the relevant IP datagram
		  size minus 40 [see RFC879].  The default of 576 octets for
		  the maximum IP datagram size yields a default of 536 octets
		  for the TCP MSS.

	In other words, the TCP MSS should be at least 40 octets less than the
	path MTU.

	-Jeff

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 04:23:20 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!trlluna!ilium!andrews@ucsd.edu  (Murray Andrews)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP product guide (was Re: SNMP comparison)
In article <900925212840.581117@DOCKMASTER.NCSC.MIL>,
Sabo@DOCKMASTER.NCSC.MIL writes:
> 
> The second version of the SNMP product guide has just been published by
> McGraw Hill's Datapro Research.  This guide covers all of the SNMP NMSs
> which were on the market as of a few weeks ago.  Contact Jill
> Huntington-Lee at 1 (800) 328-2776 extension 2444.  Rumor has it that
> copies of this report will be distributed free of charge at the Datapro
> booth during INTEROP 90.
> 
> L.  Michael Sabo

Does anyone have a fax number, email or snail mail address for this contact
or an Australian distributor?

An email response would be appreciated since I will be away for a couple of
weeks and a response may get expired in my absence. But then again it
might not.

Thanks,
	Murray Andrews
	Telecom Australia Research Laboratories.
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 04:36:43 GMT
From:      world!ddern@uunet.uu.net  (Daniel P Dern)
To:        tcp-ip@nic.ddn.mil
Subject:   RFC 1174 in the news (also, Internet Toaster)
The current (October 1990) issue of Data Communications has
a news article on RFC 1174 (not mentioned by [name]), "Federal
Networking Council to Widen Access to the Internet; Agrees to
Drop Requirement that New Members Obtain a Government Sponsor."
by yours truly.

I haven't read through the final printed version carefully, but
suspect there are some inaccuracies due to editing and condensing
and late night phone discussions with the editors .... I'm considering 
posting an alternate version.  For members of the Internet community
up to date on what's happening, one or two paragraphs would say all;
for others, it seemed to take more thousands of words than I was given...

Also, on the last page, a preview of John Romkey's Internet
Toaster, and other networked appliances/devices (some of which
were discussed here in the past month or two...).

Daniel Dern

(Don't ask me for copies; call McGraw-Hill. Tnx)

 






-- 
Daniel Dern, Ministry of Public Relations (MiniPurl)  (617) 926-8743
  High-tech journalism, PR and humor; substitute dance/Unix instructor
  Internet: ddern@world.std.com  UncaSam: PO Box 114 Belmont MA 02178
          "No! We Don't Sell Frozen Yogurt Here!"
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 06:03:27 GMT
From:      mcsun!tuvie!edvvie!eliza!schweigl@uunet.uu.net  (Johnny Schweigl)
To:        tcp-ip@nic.ddn.mil
Subject:   FTP client source available as PD ?
I am looking for the source of an FTP client program. If something like
this is available in the public domain could anyone please mail it to me?
BTW: I've got no FTP access, so please use email

Thanks in advance, Johnny
-- 
This does not reflect the   | Johann  Schweigl | DOS?
opinions of my employer.    | johnny@edvvie.at | Kind of complicated
I am busy enough by talking |                  | bootstrap loader ...
about my own ...            |   EDVG  Vienna   | 
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Oct 90 11:25:44 EDT
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        TCP-IP@nic.ddn.mil
Subject:   Traceroute for 3B2/600's under sys V R3.2.2
Hello,

I am looking for a copy of traceroute that runs on the AT&T 3B2/600,
under System V Release 3.2.2.

I am particularly curious as to whether Sys V requires the raw IP kernel
hack that BSD systems do.

Please mail your responses directly to me so as not to clog the list.

Thanks in advance!

Bob Stratton 		| dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet]
NAVMEDATASERVCEN	| dsc3rjs@vmnmdsc		      [BITNET only]
(Innova Comms. / AT&T)	| 295-3371 [AV]    +1 301 295 3371    [PSTNet]
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Oct 90 11:59:38 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
Cc:        TCP-IP@nic.ddn.mil
Subject:   Reply to Ethernet Address Uniqueness...
>In the DEC VAX environment the unique Ethernet address on each board is
>overridden by DECNET when it starts to use that board.  The address is set
>to four bytes of a constant value plus two bytes which contain the DECNET
>area and node numbers.  Lots of opportunity for duplication!
>Does anyone know why DEC chose this scheme?
>
>  - Bob Fillmore     FILLMORE@EMRCAN.BITNET

I believe it was to keep down the size of routing tables.  Since the Ethernet
address can be calculated from the DECnet address, you don't have to keep a
48-bit MAC address in your mapping from Network layer to Data Link layer.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Oct 90 12:05:47 EDT
From:      fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
To:        TCP-IP@NIC.DDN.MIL
Subject:   Reply to Ethernet Address Uniqueness...
In the DEC VAX environment the unique Ethernet address on each board is
overridden by DECNET when it starts to use that board.  The address is set
to four bytes of a constant value plus two bytes which contain the DECNET
area and node numbers.  Lots of opportunity for duplication!
Does anyone know why DEC chose this scheme?

  - Bob Fillmore     FILLMORE@EMRCAN.BITNET
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 09:55:24 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!nikhefh!a20@bloom-beacon.mit.edu  (Marten Terpstra)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP over X.25
In article <emu-ul20.1990.1004.143548.cl04@uk.ac.ncl.mts> Denis.Russell@newcastle.ac.uk writes:

[stuf deleted]

>this query.  The primary focus is to find  out  whether  routers
>that  support  X.25  as  an  IP  bearer  have  the right sort of
>characteristic for such an application.  For example, one  would
>require  support for a substantial number of such calls (10, 20,
>30?), and the  automatic  clearing  down  of  calls  after  some
>inactivity  timeout.   What  speed X.25 is supported (preferably
>well beyond 64kbps)?  Does a  router  exploit  already  existing
>inbound  X.25  calls  to send outbound datagrams or does traffic
>always result in two calls, one used in  each  direction?   What
>other questions are important?

CISCO IP routers can provide you with everything you want.
The max speed for normal serial interfaces in these boxes is T1
(or 1.544 Mbit/s). You can of course get higher speed interfaces.

The set-up and clearing of calls can simply be done by specifying an
idle timer. Only one call is needed for two way traffic. It will set
up a call if it has traffic to route. CISCO even provides x25 switching
if you want this. Ask CISCO for some info or drop a line at
customer-support@cisco.com.

Marten
--
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Phone    : +31 20 592 5102                           Amsterdam, The Netherlands
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 11:03:16 GMT
From:      matthew@ooc.uva.nl (Matthew Lewis)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: MAC MS-MAIL to SMTP gateway?

kdb@macaw.intercon.com (Kurt Baumann) writes:

>In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer)
>writes:
>> I thought the GatorMail products were software to run on the GatorBox.  Am I
>> mistaken?  Hard to believe that products designed for a GatorBox would run
>> on Kinetics-oops-Novell-oops-Shiva FastPath.
 
>I might be mistaken, but they do sell it as a seperate product.  The last
>I knew it ran with any AppleTalk-IP gateway product.  Course this might have
>changed as well.  Anyone listening from Cayman, Brad?
 
>Kurt
i
When Cayman took over marketing the Mail*Link software from StarNine, they
changed the name to GatorMail.  This has no relationship to the GatorBox,
except that the first 5 letters are the same :-).  It will run on a QuickMail
center with access to your Unix box via TCP/IP.  That means via

	Ethernet
	FastPath
	Multigate
	GatorBox

	(Have I left any out? Probably!)

We run GatorMail-Q via a Multigate, with no problems.

Matthew Lewis

-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 16:24:00 EST
From:      system@lns61.tn.cornell.edu
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   re: Reply to Ethernet Address Uniqueness...
Bob,

>In the DEC VAX environment the unique Ethernet address on each board is
>overridden by DECNET when it starts to use that board.  The address is set
>to four bytes of a constant value plus two bytes which contain the DECNET
>area and node numbers.  Lots of opportunity for duplication!
>Does anyone know why DEC chose this scheme?

The "four constant bytes" are reserved to DEC (for DECnet)
just as the high-order butes of the physical hardware Ethernet addresses
in those Ethernet boards' address ROMs are also reserved to DEC.

In a given DECnet wide-area network, all DECnet node addresses are 
required to be unique. As a result, there is no opportunity for 
duplication on a local Ethernet either. (I am ignoring the
complications introduced by setting limits on the address ranges
passed by routers.)

One reason that DEC chose this scheme is that it allows "end-node"
DECnet systems, which have no routing information whatsoever,
to be able to send messages to other end-node systems on the same
Ethernet even when there are no DECnet routers present.
They just calculate what the Ethernet address must be and
blindly transmit the message into the ether.

Of course, the fact that DECnet addresses are limited to 16 bits
means that larger networks are limited to a maximum of about 64K
systems. My guess is that there are fewer than a dozen networks 
for which this causes problems. This address limitation in Phase IV 
DECnet is one of the reasons that DEC is moving to OSI for
DECnet Phase V.

I hope this helps.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: +1-607-255-0688 
Laboratory of Nuclear Studies        FAX: +1-607-255-8062
Wilson Synchrotron Lab            BITNET: SYSTEM@CRNLNS
Judd Falls & Dryden Road        Internet: SYSTEM@LNS61.TN.CORNELL.EDU
Ithaca, NY, USA 14853-8001   HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 11:53:23 GMT
From:      att!mcdchg!ddsw1!proxima!olsa99!iosys!icl011!root@ucbvax.Berkeley.EDU  (Super user)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for POP mail for MAC
> We are looking for various POP/SMTP implementations for the Macintosh.  
> Our requirements include support for MacTCP and source code 
> availability.  

hi Steven Wallace of Indiana Uv did you ever find the POP/Coke for your 
Mac/Rain/Coats, will not to panic if've just the thing for you.

1. find a pen.
2. find a paper ( used may suit )
3. use 'effort' to scribe pen on paper!

5(a) not what you may have wonted but it's a good, ain't it!
/*******************************************************************************
 *                    Sean J & Associates.                                     *
 *  COPYRIGHT (c) 1984-1989 Sean J & Ass, Knockyrourke Co Cork, Ireland.       *
 *  All rights reserved.  No part of this work covered by the                  *
 *  copyright hereon may be reproduced or used in any form or by any means     *
 *  -- graphic, electronic, or mechanical, including photocopying,             *
 *     recording, taping, or information storage and retrieval systems --      *
 *  without permission of Sean J & Associates.                                 *
 ******************************************************************************/

Very Best Regards, SEan S.
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 14:55:59 GMT
From:      bu.edu!polygen!bill@uunet.uu.net  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
Phil Karn's KA9Q package would do just fine.  KA9Q is a program that allows
connection to the PC via ftp, telnet, smtp, et. al. at the same time.  It
has a builtin multitasking mechanism.  It also supports slip, and routing. I
have used it for a slip to ethernet router before.  You can find it on
thumper.bellcore.com under the /pub/ka9q directory. 
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 14:57:23 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!olivea!oliveb!felix!dhw68k!zardoz.cpd.com!durin!frankh@ucsd.edu  (Frank Halsema)
To:        tcp-ip@nic.ddn.mil
Subject:   PCPOP hangs
I just picked up PC POP from nasa.trident.gov. I set up the popd on my
sun 3/280 running SunOS 4.1. I have had NCSA telnet with packet
drivers for a while and they work fine. The set up is a com 3c503 card
with the memory jumper on CC000 packet driver version 4.2 the command
for the driver is 

c:\ncsa\3c503 0x7e 3 0x300 1

I enter

set configtel=c:\ncsa\config.tel

when i run pcpop in the directory pcpop I comes up with the initial
configuration screen. If I type with minimal delays I can get the
information in but after entering yes to confirm the configuration it
hangs. Also if I delay in entering the configuration data I get a hang
immediately. I have taken everything out of my config.sys except for
the ANSI.SYS, FILES, and BUFFERS lines. There is also a break=on.
below is my config.tel. Any help would be greatly appreciated.
 
#
#  Example host file for Telnet 2.2
#
#  "funny, this configuration file is readable ..."
#
#  This file is free form
#  Separators are any char <33 and :;=
#
#  The form is keyword=value for each parameter.
#  The first set of parameters refer to the whole program's defaults.
#  These parameter values can be in any order.
#  Following this are the individual machine specs.
#  If the first machine is name "default", then it contains default
#  values for the rest of the machines.
#
myip=192.42.141.101
name=pippin
netmask=255.255.255.0		# subnetting mask
hardware=packet
				#    values are: 3c501,ni5210,pcnic,wd8003
				#    for ps/2: nicps2,3c523
tek=yes				# enable tektronix graphics
video=ega	  		# type of video screen
				#    Legal values for video are:
				#    cga,ega,no9,hercules
bios=no				# don't use slow BIOS screen access
				#    bios=yes to reduce flicker on cga
				#    bios=yes for TopView or Windows
interrupt=3			# hardware IRQ interrupt for 3C501 board
address=0
ioaddr=7E  			# base address for I/O registers
ftp=yes				# do you want ftp enabled?
rcp=yes				# do you want rcp enabled?
capfile=mycap			# default name for capture file
domain="sparta.com"	# default domain for name lookups
hpfile=hp.out			# file to write HPGL to,
				#    COM1 can be used for attached plotter
psfile=ps.out			# file to write postscript to
tekfile=tek.out		 	# file to write Tek codes to
arptime=4			# arp timeout in seconds
				#    affects machines on your local network
#passfile="c:\ncsa\ftppass"	# name of file to find FTP passwords in

#
#  Following are individual machine specifications
#  Gateways are used in order that they appear in the file
#  Nameservers rotate, #1, #2, #3, #1, #2 when a request fails
#
#  The machine named "default" contains the fields which are automatically
#  filled in for other hosts.  name=default machine should appear first.
#
name = default			# Session name, "default" is a reserved name
				#   Not a real machine, default parameters only
#
#
#gateway=1			# This machine is a gateway for me
#
scrollback=100			# number of lines of scrollback per session
erase=delete			# use delete code or backspace code for <- key?
				#   legal values are "delete" and "backspace"
vtwrap=yes			# should VT100 be in wrap mode or not?
nfcolor=green			# normal, foreground
nbcolor=black			# normal, background
rfcolor=black			# reverse, foreground
rbcolor=white			# reverse, background
ufcolor=blue			# underline, foreground
ubcolor=black			# underline, background
#crmap=4.3BSDCRNUL		# map of the CR key for compatibility
#duplex=half			# modifier for non-echo mode, forces send
clearsave=yes			# save lines on clear screen yes/no
#  The following entries affect the tuning of TCP connections to this host.
#  They should be set by the network administrator who is familiar with
#    the requirements of your specific network.
contime=20			# timeout in seconds to try connection
retrans=7			# starting retransmit time out in ticks
				#   1/18ths of sec
mtu=512				# maximum transmit unit in bytes
				#   outgoing packet size, MAX=1024
maxseg=512			# largest segment we can receive
				#   whatever the hardware can take, MAX=1536
rwin=512			#   TCP window size, MAX=4096
#
#  Below this line, most of the communication parameters are obtained
#   from the "default" host entry.
#  Machine names, IP addresses, and special communication parameters are
#   present when needed.
#

name=durin ; hostip=192.42.141.7 ; nameserver=1
#name=mynameserver ; hostip=127.0.0.2 ; nameserver=1
-- 
Frank Halsema                           UUCP: durin!frankh             
SPARTA, Inc.                   		Internet: frankh%durin@uunet.uu.net
23041 de la Carlota, Suite 400
Laguna Hills Ca, 92653     (714) 768-8161 EXT 339  (714)583-9114 FAX
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 15:22:31 GMT
From:      world!esegue!johnl@uunet.uu.net  (John R. Levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Does anybody know LM-X or Lackman?
In article <12817@asylum.SF.CA.US> sharon@asylum.UUCP (Sharon Fisher) writes:
>Lachman Associates -- the last address I have for them is 1901 N.
>Naper Blvd., Naperville, IL 60540-1031; (312) 505-9100; fax (312) 505-9133.

Lachman is now a subsidiary of Interactive Systems, but they're still at the
same address.  On the net they're known as laidbak.uucp or i88.isc.com.  The
telephone area code has changed from 312 to 708, the postal zip to 60563-8895.

-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|spdcc|world}!esegue!johnl
Atlantic City gamblers lose $8200 per minute. -NY Times
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 16:23:16 GMT
From:      sdd.hp.com!usc!isi.edu!gremlin!nrtc.northrop.com!domae@ucsd.edu  (Terry Domae)
To:        tcp-ip@nic.ddn.mil
Subject:   CSLIP/PPP Status?
Does anyone know the current status of CSLIP and PPP?

I have not seen any real news in almost a year. 

Terry Domae
Northrop Research and Technology Center

Terry Domae 
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 16:41:59 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes

 A few new-to-named-pipes questions...

Am I correct in assuming that it is the 'non-passing' for certain
IP/UDP broadcast packets that prevents 'stock' named-pipes from
working across IP routers?

If that is the only reason, then could one expect named-pipes to work
across a router that could be configured to pass these broadcasts in a
controlled manner? (no loops and all that...)

inquireing minds and all...

rick

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | 'Tis nobler to suffer...
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 17:03:13 GMT
From:      ogicse!plains!kapoor%plains.NoDak.edu@decwrl.dec.com  (Sanju Kapoor)
To:        tcp-ip@nic.ddn.mil
Subject:   Broadcasting on Sockets

I am sending this for a friend of mine who does not have access to this
net group. I would send all replies to him. Here is his question :

/******************************************************************************
I am having problems with broadcasting on socket. I keep getting the
message "Can't assign requested address" when I call the function sendto.
What am I doing WRONG. I am sending the code where I am having the problem.

When I do "ifconfig le0" on the interface I do see the broadcast address of 
my network interface(lance ethernet). ALL machines are SUN SPARCstation SLC 
running SunOS 4.1. 

I am trying to write a function that will find a resource on the network.
On each of the host machine on the network there is a server which keeps
track of the resources available on the local host. When a client needs a 
resource "X" it sends a broadcast message to locate the resource and waits 
for the response from the server which owns the resource. Assume that the 
resources uniquely exist on the network. 

I may be doing something wrong here but can't seem to fix it. If anyone 
can give suggestions I would appreciate it . Also, I would like to know 
how does the server on the host listen for broadcast message. Thanks in advance.
*******************************************************************************/
int
find_resource(resource,location)
char	*resource,             /* resource to be located   */
	*location;             /* location of the resource */
			       /* to be set by this function */
{
	int	brd_socket,
		brd_on,
		cnt,
		len;
	char	buf[BUFSIZ];
	struct	sockaddr_in	clnt_addr,
				serv_addr;
	struct	sockaddr 	dest_addr;
	struct	ifconf	 	ifc;
	struct	ifreq	 	*ifr;

	if ((brd_socket = socket(AF_INET,SOCK_DGRAM,0)) < 0) 
		return (-1);
	brd_on = 1; 
	if (setsockopt(brd_socket,SOL_SOCKET,SO_BROADCAST,
				&brd_on,sizeof(brd_on)) == -1) 
		return(-1);
	clnt_addr.sin_family = AF_INET;
	clnt_addr.sin_addr.s_addr = htonl(INADDR_ANY);
	clnt_addr.sin_port = 0;
	len = sizeof(clnt_addr);
	if (bind(brd_socket,(struct sockaddr *) &clnt_addr,len) < 0) 
		return(-1);
	ifc.ifc_len = sizeof(buf);
	ifc.ifc_buf = buf;
	if (ioctl(brd_socket,SIOCGIFCONF,(char *) &ifc) < 0) 
		return(-1);
	ifr = ifc.ifc_req;
	for (cnt = ifc.ifc_len/sizeof(struct ifreq); --cnt >0 ; ifr++) {
		if (ifr->ifr_addr.sa_family != AF_INET)
			continue;
		if (ioctl(brd_socket,SIOCGIFFLAGS,(char *) ifr) < 0) 
			return(-1);
		if (((ifr->ifr_flags & IFF_UP) == 0)  ||
		    (ifr->ifr_flags & IFF_LOOPBACK)   ||
		    ((ifr->ifr_flags & IFF_BROADCAST) == 0)) 
				continue;
		if (ifr->ifr_flags & IFF_BROADCAST) 
			if (ioctl(brd_socket,SIOCGIFBRDADDR,(char *) ifr) < 0) 
				return(-1);
		bcopy(ifr->ifr_broadaddr,(char *)&dest_addr,
					sizeof(ifr->ifr_broadaddr));
		len = strlen(resource);
		if (sendto(brd_socket,resource,len,0,(struct sockaddr *) 
					&dest_addr,sizeof(dest_addr))== -1) 
			return(-1);
	} 
	if (recvfrom(brd_socket,location,sizeof(location),0,
				(struct sockaddr*)&serv_addr,&len) == -1)  
		return(-1);
return(0);
} 
----------------------------------------------------------------------------
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 17:26:28 GMT
From:      zaphod.mps.ohio-state.edu!samsung!olivea!oliveb!felix!dhw68k!fedeva!bill@tut.cis.ohio-state.edu  (Bill Daniels)
To:        tcp-ip@nic.ddn.mil
Subject:   is syslog(3) to remote possible?
I posted a similar request about a week or two ago.  Just as luck would
have it my news machine went away for a couple of days right afterwards.

I have need to log operator messages via syslog(3) on a remote machine. I
am sure that this is possible because of the way the docs and headers read.
It seems however that Ultrix has coded up syslog() so that all messages go
to the local machine.

If there is a way around this I would be ever grateful to the one who shares
the insight.  If there is not a workaround, could someone mail me the source
to syslog(3) and syslog(8) if it is publicly available?

Thanks for your help

bill daniels
-- 
bill daniels
federal express, memphis, tn
{zardoz!dhw68k,mit-eddie!premise}!fedeva!bill
bill@fedeva.UUCP
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 17:54:14 GMT
From:      tjh+@andrew.cmu.edu  (Tom Holodnik)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for the NeXT machine?

	Is there a (preferably free) SLIP implementation for the NeXT machine?

Thanks in advance. 

____________________________
Tom Holodnik               
Networking & Communications
Carnegie-Mellon University 
UCC-137 4910 Forbes Avenue
Pittsburgh PA 15213
(412)-268-2028
____________________________
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:09:22 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reply to Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes:
> In the DEC VAX environment the unique Ethernet address on each board is
> overridden by DECNET when it starts to use that board.  The address is set
> to four bytes of a constant value plus two bytes which contain the DECNET
> area and node numbers.  Lots of opportunity for duplication!
> Does anyone know why DEC chose this scheme?
 
Basic answer- They messed up! DECnet Phase V will abandon this ill concieved
idea. It was a clever idea to allow a direct and unambiguous translation from
DECnet address to Ehternet address which eliminates the need for ARP or some
similar method of Ethernet address resolution. They have since learned the
folly of this and do the reverse in Phase V. They code the 6 bytes of the
Ethernet address into the system's NSAP (OSI address).

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:10:33 GMT
From:      sunquest!alpha.sunquest.com!gavron@arizona.edu  (Ehud Gavron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reply to Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET writes...
#In the DEC VAX environment the unique Ethernet address on each board is
#overridden by DECNET when it starts to use that board.  The address is set
#to four bytes of a constant value plus two bytes which contain the DECNET
#area and node numbers.  Lots of opportunity for duplication!
#Does anyone know why DEC chose this scheme?

	On one ethernet, the duplication only occurs if two
	nodes have the same DECnet address -- which is not
	only a no-no but since both would have terrible
	problems, this condition would not persist long.

	There is therfore not "lots of opportunity for
	duplication."  It also is completely immaterial
	why DEC chose this scheme.  Suffice to say that
	the next major DECnet release (now targeted for
	'92) will be completely different.

# 
#  - Bob Fillmore     FILLMORE@EMRCAN.BITNET
                                      ^^^^^^

	Ehud

/----------------------------------------------------------------------------\
| Ehud Gavron, Systems analyst  | gavron@vesta.sunquest.com      (Internet)  |
| Sunquest Information Systems  | uunet!sunquest!gavron          (UUCP)      |
| 930 N. Finance Center Drive   | gavron@lampf                   (BITNET)    |
| Tucson, Arizona, 85710        | (602)722-7546/885-7700 x.2546  (AT&Tnet)   |
|----------------------------------------------------------------------------|
|           your cute quote here                                             |
\----------------------------------------------------------------------------/
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:16:35 GMT
From:      bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!ctw@bloom-beacon.mit.edu  (Charles T. Wolverton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for DEPCA boards
In Article: 13237, ianh@bhpmrl.oz.au (Ian Hoyle) says:

> Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards ...

			ian

My Wollongong documentation has installation instructions for

1. "an existing DEC LAN in working condition" 
2. "an existing 3com 3+Open LAN in working condition"

Is this equivalent to:

1.' "a network card with the appropriate DEC DLL-compliant driver"
2.' "a network card with the appropriate MS NDIS-compliant driver and
    protocol manager software" ???

If no, I don't understand the response quoted above. If yes, wouldn't
the restated versions (possibly corrected, since I don't really
understand yet how NDIS works and know nothing about DLL) be more
generally useful??

Edification, please.

-chas   ctw@aero.org
-- 
***  Charles T. Wolverton    *****  Aerospace Corporation  ***
***  ctw@aerospace.aero.org  *****  P.O. Box 92957  M1-023 ***
***  (213) 336-5204          *****  Los Angeles, CA 90009  ***
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:23:23 GMT
From:      olivea!orc!bu.edu!mirror!roskuski@apple.com  (Barry J. Roskuski)
To:        tcp-ip@nic.ddn.mil
Subject:   Long distance TCP/IP

    Please excuse the dumb question, but I am utterly ignorant about
    this stuff.

    What is necessary to set up a TCP/IP network between two UNIX 
    systems at 2 different sites? I've guessed that we can use SLIP
    over a modem, but performance probably wouldn't be what we'd like.
    I've heard mention of T1 lines, but am not sure how I would connect
    to them (or even what they are for that matter). Can you hang a T1
    line off of an ethernet with the appropriate bridge? Is this what
    I need, or am I way off base? And how does X.25 fit into this. Any 
    help or pointers in the right direction would be appreciated.

---
Barry J. Roskuski                   Mirror Systems
                                    2067 Massachusetts Ave.
                                    Cambridge, MA 01240
roskuski@mirror.TMC.COM
{mit-eddie, pyramid, harvard!wjh12, xait}!mirror!roskuski
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:33:49 GMT
From:      arizona.edu!leonard@arizona.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
In article <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>, fillmore@emrcan.BITNET 
writes:
> In the DEC VAX environment the unique Ethernet address on each board is
> overridden by DECNET when it starts to use that board.  The address is set
> to four bytes of a constant value plus two bytes which contain the DECNET
> area and node numbers.  Lots of opportunity for duplication!
> Does anyone know why DEC chose this scheme?

Sure, it saves DECnet having to have an address resolution protocol a la
ARP ... if a DECnet node wants to find the MAC address for a given DECnet
address, it already knows what the address *should* be.

There's a couple of problems with this approach:

1. If you are running different network protocols on the same Ethernet
board, then obviously they can't *all* do this!  I believe that Novell's
IPX similarly hacks the Ethernet address, which (if true) means that DECnet 
and IPX can't share the same board.

2. A DECnet node can't have multiple Ethernet interfaces running DECnet on
the same bridge-extended Ethernet.  (Because the bridges will see the
same Ethernet addr on both sides!)  This may seem like a perverse topology
to IP oriented folks, but given DEC's historical MAC layer uber alles 
approach, in some situations this can be exactly what you would want.

In DECnet Phase V (due out twelve months from any given point in
time ;-) ), DECnet is supposed to stop resetting the hardware
addresses on its Ethernet adapters, and will presumably adopt some
ARP protocol.
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 19:52:37 GMT
From:      sun-barr!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes:
>our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet
>address, obtained from the primary ethernet board. Of course, warning bells
>are going of here. Now I've been searching the RFC and IEEE docs and I cannot
>find any documentation that sort of says that Ethernet Addresses are assigned
>to Ethernet boards, not hosts.

This seems to come up fairly often...  The original intent of Ethernet was
quite specifically to assign addresses to hosts, not boards, which is one
reason why Ethernet addresses are required to be programmable instead of
being locked into the boards.  The XNS protocols use Ethernet addresses
as host numbers and *must* have exactly one address per host.

With TCP/IP, the Ethernet addresses are largely invisible to the upper
levels and it doesn't really matter much either way, unless for some
reason you've got two boards on the same network (in which case you will
have other problems...).
-- 
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 20:33:50 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!alexb@decwrl.dec.com  (Alex Beylin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP with Named Pipes

First, thanks to everyone for many helpfull responces regarding 
SLIP and Named Pipes.

From the responces I see that more details are in order.  What ww would like 
to do is allow users with portable computers and modems to user DCA's
CommServer in order to access 3090 resources.  As James Van Bokkelen
pointed out, we have to use Lan Manager.  CommServer can use a number     
of APIs, but Named Pipes seems the cleanest.  In order to carry it all
the way to the PC we will need NetBios and SLIP software on the PC.

The solution seems to be cisco SLIP concentrator and PC/TCP (Thank you,
James).  We will be running tests late October.  I will post results 
to this group.

Again, thanks to everyone for all the help.   

-- Alex


 Alex Beylin, Unix Specialist   | +1 313 948-3386
 alexb@cfctech.cfc.com          | Chrysler Financial Corp.
 sharkey!cfctech!alexb          | MIS, Distributed Systems
 ATT Mail ID: attmail!abeylin   | Southfield, MI 48034
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 90 21:24:00 GMT
From:      system@LNS61.TN.CORNELL.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Reply to Ethernet Address Uniqueness...

Bob,

>In the DEC VAX environment the unique Ethernet address on each board is
>overridden by DECNET when it starts to use that board.  The address is set
>to four bytes of a constant value plus two bytes which contain the DECNET
>area and node numbers.  Lots of opportunity for duplication!
>Does anyone know why DEC chose this scheme?

The "four constant bytes" are reserved to DEC (for DECnet)
just as the high-order butes of the physical hardware Ethernet addresses
in those Ethernet boards' address ROMs are also reserved to DEC.

In a given DECnet wide-area network, all DECnet node addresses are 
required to be unique. As a result, there is no opportunity for 
duplication on a local Ethernet either. (I am ignoring the
complications introduced by setting limits on the address ranges
passed by routers.)

One reason that DEC chose this scheme is that it allows "end-node"
DECnet systems, which have no routing information whatsoever,
to be able to send messages to other end-node systems on the same
Ethernet even when there are no DECnet routers present.
They just calculate what the Ethernet address must be and
blindly transmit the message into the ether.

Of course, the fact that DECnet addresses are limited to 16 bits
means that larger networks are limited to a maximum of about 64K
systems. My guess is that there are fewer than a dozen networks 
for which this causes problems. This address limitation in Phase IV 
DECnet is one of the reasons that DEC is moving to OSI for
DECnet Phase V.

I hope this helps.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: +1-607-255-0688 
Laboratory of Nuclear Studies        FAX: +1-607-255-8062
Wilson Synchrotron Lab            BITNET: SYSTEM@CRNLNS
Judd Falls & Dryden Road        Internet: SYSTEM@LNS61.TN.CORNELL.EDU
Ithaca, NY, USA 14853-8001   HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 09:38:17 PDT (Sat)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        oberman@rogue.llnl.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Reply to Ethernet Address Uniqueness...
   Date: 5 Oct 90 19:09:22 GMT
   From: decwrl!lll-winken.llnl.gov!rogue.llnl.gov!oberman
   References: <5A0A050B012801FE-MTAEMR1*fillmore@emrcan>
   Sender: tcp-ip-relay@nic.ddn.mil

   They code the 6 bytes of the
   Ethernet address into the system's NSAP (OSI address).

What a great idea. So if you change your ethernet card, your machine's
address changes too?
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 03:32:37 GMT
From:      shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com  (Tim Peiffer (The Net Guy))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
In article <9987@xenna.Xylogics.COM> kriger@Xylogics.COM (Sidney Kriger) writes:
>In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes:
>>I worked for an outfit that sold cisco and the company I work for now
>>sells the Encore Annex II.  
>Xylogics now manufactures the Annex II terminal server and has for about
>2 years, not Encore.    800-225-3317

	I have both the Encore and Xylogics varients of the Annex II
	terminal server running some ports under slip.  I am very happy
	with the ease in configuration,  but I would like to see something
	that supports the Van Jacobsen hdr compression algorithms( RFC 1144).	
	Does anyone know of a product that supports this scheme?  SLIP is
	sssoooo easy to configure slip on an Annex. It seems like a shame
	to waste it, but ftp and telnet are so gawdawfully slow even over
	a 38.4k link that I still resist putting it in place.

	For those that care, Xylogics is the Manufacturer of the Annex
	now, but Encore still oem's the product, and they have their
	own software line to support the normal Encore line of multimaxen.


Tim
-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 03:56:25 GMT
From:      agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com  (Tim Peiffer (The Net Guy))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Nameservice questions
In article <465@bcstec.UUCP> ced@bcstec.uucp (Charles Derykus) writes:
>  (1) Can nameservice resolve reverse translation queries "up the tree"
>      towards the root domain if the domains of the requested node and
>      the requesting node are at the same level, e.g.
[...}
>       can "carrot" ask "cabbage" to reverse translate an I.P. in 
>       "herb.vegetable"  and if so, how?

	Yes, you can forward unresolved entries (those not in your
	domain or in your secondary zones) by using the forwarding
	construct in named.boot.
	; forward name-service request when we can't (won't) handle them
	forwarders	first_forwarder_ipaddr  second_forwarder_ipaddr

>   (2) A named.rev with multiple $ORIGIN lines worked fine on out primary
>       nameserver for a while but then the secondary nameserver starting
>       breaking. The only way we get it working now is by specifying separate
>       reverse translation files for each $ORIGIN line, e.g.
	
	I do not really understand.  I would answer your question with no.
	The in-addr.arpa domain is rather unusual and should be treated 
	differently than most others.  The declaration in named.boot 
	specifies service for a particular domain.  I think that your 
	declaration would break unless it were of the following form:

	named.boot
	----------
	primary 207.128.in-addr.arpa.		herb.file_name
	
	herb.file_name
	----------
	$ORIGIN 254.207.128.in-addr.arpa.
	44	IN	PTR	parsley.herb.blah.blah.
	$ORIGIN 253.207.128.in-addr.arpa.
	1	IN	PTR	oregano.herb.blah.blah.	

Tim
-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 04:00:29 GMT
From:      agate!shelby!msi.umn.edu!cs.umn.edu!peiffer@apple.com  (Tim Peiffer (The Net Guy))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: quick check for available host
In article <1990Oct3.200749.16049@cbnewsk.att.com> lih@cbnewsk.att.com (andrew.a.lih) writes:
>In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes:
>> What is a quick way for a shell script to find out if a networked
>> host is currently available?

	If you want more than what 'ping' offers, but not the mess
	that rwho provides, check out rup(), and rusers().

Tim
-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 04:32:56 GMT
From:      mimos!rangkom!napi@uunet.uu.net  (Mazli Hashim)
To:        tcp-ip@nic.ddn.mil
Subject:   Problem with remote printing

Hi netters

When I send a job for remote printing from a Convex via an Apollo
workstation which is attached to an Apple Laser Writer II, the 'lpd'
on the Convex gives this error message in 'lpd-errs':-

	/usr/lib/lpd: lw: lost connection or error in recvjob

and the 'lpd' on the Apollo gives this error message in its 'lpd-errs':-

	Oct  6 12:05:28 t1a lpd[1537]: cannot find device 1222352, 1

What could be the problem(s)?  Any pointers are appreciated.

Napi
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 15:13:29 GMT
From:      att!cbnews!junk1@ucbvax.Berkeley.EDU  (eric.a.olson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Does anybody know LM-X or Lackman?


	I have heard that if you run a program on a virtual
	console (vt??), the console will not be subject to
	screen-scrambling with console error messages.  This
	appears to be true, as my machine running X never gets
	bothered by the messages.   

	How do I force the console into this mode?
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 19:07:34 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there a program like telnet, but driven by a script?
In article <26797@fmsrl7.UUCP> hugh@slee01.srl.ford.com (Hugh Fader) writes:

   I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS.
   I am running a Sun Sparcstation and can communicate with the VAX using
   telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One
   solution to my problem would be a telnet-like program which accepts a
   script containing expect/send pairs much like UUCP and some PC
   communications programs. Does such a program exist?

See "expect" from Don Libes, ftp'able from durer.cme.nist.gov.  An extract
from the man page:

     expect is a program that "talks" to other  interactive  pro-
     grams  according  to a script.  Following the script, expect
     knows what can be expected  from  a  program  and  what  the
     correct  response  should  be.  An interpreted language pro-
     vides branching and high-level control structures to  direct
     the  dialogue.   In  addition, the user can take control and
     interact directly when desired, afterward returning  control
     to the script.

Since this is a program which isn't necessarily related to tcp/ip, please
follow up to comp.unix.misc.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 90 21:21:13 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!pluto!rstevens@ucsd.edu  (Rich Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: >>> Internetworking with TCP/IP book FOR SALE <<<
Be aware that the 2nd edition of this book was just published by
Prentice Hall.  I've only glanced at it, so I can't give a list
of what's changed, but it is about 150 pages longer.

This 2nd edition retains the subtitle "Principles, Protocols,
and Architectures" and is listed as Volume I.  The back cover
lists Volume II with the subtitle "Implementation and Internals"
and its by Comer and David L. Stevens.  I believe that Volume II
will be out in 1991 and will contain the source code to the Xinu
implementation of TCP/IP.

	Richard Stevens
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 90 00:04:48 GMT
From:      zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu  (Cliff Yamamoto)
To:        tcp-ip@nic.ddn.mil
Subject:   Our Sun isn't "RIPing"
Greetings network gurus!

We have a Sun Sparc+ running as a file server and router for our building's
LAN.  We also have a Banyan server running as passive router on the same
physical ethernet.  On this same ethernet, we have various PCs.  Some are
running PC-NFS while others are running PC/TCP on top of Vines.  A picture
is probably in order:


     PC  . . .   PC  . . .   PC  . . . etc      Banyan
     |           |           |               +--Server--+
     |           |           |               |          |        x.x.63.1
     +-----------+-----------+---------------+----------+-----------+
  x.x.63.10   x.x.91.20   x.x.91.21      x.x.63.107  x.x.91.1       |
                                                                   Sun
                                                                  Sparc+
where: x.x.63.x is Tcp/Ip & NFS                                     |
       x.x.91.x is Banyan/Vines        x.x.1.137  x.x.1.xxx         |
       x.x.1.xx is Labwide backbone     ----------------------------+
                                           |          |         x.x.1.165
                                          Sun       other
                                           A     hosts & subnets

The situation:

- We have /etc/gateways on the Sun Sparc+ configured as required.
- All the PCs on the 63.x and 91.x subnets can ping each other fine.
- All the PCs on the 63.x can ping the x.x.1.xxx hosts and vice-versa.
- The Sun Sparc+ can ping all hosts on all subnets.

The problem:

- NONE of the 91.x hosts can ping the x.x.1.xxx hosts and vice-versa.

The probable cause?

- The Sun Sparc+ is not sending out RIP info to the hosts on x.x.1.xxx
  about the 91.x subnet.

The test:

- We added an explicit /etc/gateway routing entry at Sun A.  It basically
  tells Sun A that all x.x.91.0 traffic should route to x.x.1.165 with a
  metric of 1 and passive.  THIS WORKED!!  Sun A was able to ping all PCs
  on the 91.x subnet and vice-versa.

The question:

So does anyone know what causes this?  We don't have access to a sniffer so
it makes it difficult to see if the Sparc+ is sending out info.  Is there
something we missed?  Any help would be appreciated.

Thanks in advance!
Cliff Yamamoto
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sun 7 Oct 90 22:44:48-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        shelby!msi.umn.edu!cs.umn.edu!peiffer@decwrl.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
	Does anyone know of a product that supports [cslip]?  SLIP is
	sssoooo easy to configure slip on an Annex. It seems like a shame
	to waste it, but ftp and telnet are so gawdawfully slow even over
	a 38.4k link that I still resist putting it in place.

Really?  FTP is slow?  Our experience at cisco (with our own terminal
servers, of course) was that FTP was quite zippy - the sliding window
of TCP bought you much more than you lost from the big headers.  Compared
to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast.

Telnet, however, was quite painful, and I don't even want to think about
running telnet and FTP at the same time.

BillW
-------
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 90 22:50:12 GMT
From:      bionet!turbo.bio.net!lear@apple.com  (Eliot)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Need a RARP Demon
Kory Hamzeh asks for information on a PD rarpd.

I don't know about rarpd, but would bootp serve your purposes?
-- 
Eliot Lear
[lear@turbo.bio.net]
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 90 07:04:48 GMT
From:      wuarchive!zaphod.mps.ohio-state.edu!usc!neuro.usc.edu!dra@decwrl.dec.com  (Diane Annala)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <NELSON.90Sep28233146@image.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
#
#Prudent or not, you agreed to do so, yet you have not.  That makes you
#liars.  I suggest to dear gentle readers that they keep that in mind.
#
#   Xircom will be
#   discontinuing the shipment of the Packet Driver based
#   on the Clarkson Packet driver and will be replacing it
#   with a fully compliant Packet Driver developed
#   independently.
#
#You can bet your bippy I'm going to go over your "independently developed"
#packet driver with a fine-toothed comb.

Of course, Xircom could include a provision in their copyright notice
forbidding nelson@image.clarkson.edu from disassembling, decompiling,
or otherwise going over the new packet driver with a fine toothed comb.
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 90 20:39:29 GMT
From:      news!german@iuvax.cs.indiana.edu  (Chad W. German)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA TELNET / BANYAN
Does anyone have Telnet running concurrently along
with Banyan Vines network.... What set-up are you
using.  With Telnet installed on each workstation
every thing works fine as long as your not logged into
the file server.  Once logged in or having Telnet reside
on a network drive, the PC and network loses communications.
I'm fimiliar with the way Novell can function with Telnet
by the use of packet drivers..... What is the secret for
Vines.....?? Thanks in advance for any info../
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 90 23:35:11 GMT
From:      gohp3!dc@uunet.uu.net  (Darren Croke)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes:
>
> text deleted
>
>There is not much point setting TCP_MSS to be greater than
>	(maximum IP packet size - IP header size - TCP header size)
>[536 octets] since IP fragmentation will take place. Receipt of a
>fragmented packet is an all or nothing proposition; a good thing to
>avoid for throughput reasons.
>

The 536 octects in brackets is the minimum but by no means always 
equal to (maximum IP packet size - IP header size - TCP header size).

Look at the packets on an Ethernet sometime. I am running a 4.3 BSD
TCP/IP implementation here that quite happily negotiates a MSS of 
1000 bytes and then proceeds to send unfragmented 1000 byte packets.

I think you will find that it is common for IP implementations to
send and accept datagrams without fragmentation up to 
(connected network MTU - IP header size - TCP header size).

Darren Croke.
dc@graphon.com
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 02:03:02 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   rfc1183:  new RR types

I just retrieved an RFC defining some new RR types for the DNS.
A few things bother me.

First, it isn't clear to me that X25 address and ISDN address should
be separate types.  There are a number of other media where a similar
record is needed, such as the Datakit VCS(R) and dial-up SLIP or PPP.
I think I'd prefer a media address RR, with a subtype field first.  I
understand why in some cases one might opt for different records (and
the matter is discussed in the RFC for an Andrew File System RR),
but I'd vote differently than did the authors.  My reasoning is simple:
there are, I think, many different media for which the concept is
applicable.  If the vendor supports media address, I can create my
own subtypes; it's much harder to add new RR types without the vendor's
name server source.

Second, it isn't clear to me who should be using the Route Through RR.
Under what circumstances should a router do this (expensive) query?
When there's no route to the host?  To the network?  What if the
router doesn't have a direct link to the preferred forwarding host?
Route towards is, and hope that the next hop knows enough to use
the new record?  I'm not saying RT is a bad idea, or hasn't been thought
through; I am saying that I'd like to see some discussion on how
it's intended to be used in a real Internet.

		--Steve Bellovin
		smb@ulysses.att.com

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 October 1990 15:15:13 CDT
From:      <DANIEL@UIUCVMD>
To:        <tcp-ip@nic.ddn.mil>
Subject:   .netrc equivalent
I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS.
This application normally refers to the .netrc file to get password
information.  Are there any convensions on CMS for the equivalent?

Also, the program does not like to send the password across the net in
clear text so it calls the standard UNIX crypt command to do the DES
encryption of the password.  Is the DES encription available on VM/CMS
systems if I don't own the standard IBM box to do this?  What is the
standard calling procedure for programs using an IBM DES configuration?

-- Daniel Pommert
 pommert@uiuc.edu
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Oct 90 14:15:17 EDT
From:      fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
To:        TCP-IP@NIC.DDN.MIL
Subject:   Reply to Re: Ethernet Address Uniqueness...
In my recent message about DECNET Ethernet address non-uniqueness I should have
mentioned that my site works in a mixed DECNET - TCP/IP environment (plus
Appletalk, etc.).  Problems arise in VAXes which run both DECNET and TCP/IP
on the same Ethernet interface - the Ethernet address used in ARP responses
depends on whether DECNET was started before or after TCP/IP, because DECNET
changes the Ethernet address in the interface hardware (in RAM memory).
If the TCP/IP software uses the modified DECNET Ethernet address then there
might be address duplication because IP addresses are connection oriented,
not node oriented.
________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Oct 90 18:46:29 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news@tut.cis.ohio-state.edu  (Cliff Yamamoto)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Our Sun isn't "RIPing"
VINES servers act as very simple IP routers, and as far as I know do not
support any dynamic routing protocols (no RIP).  If the Sun doesn't hear
about about the VINES subnet via RIP, it has to be told via a static route.

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

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Oct 90 18:46:31 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Reply to Re: Ethernet Address Uniqueness...
This is a standard gotcha of using protocols that change the address.
There is no solution other than to make sure that DECNet is always
started before anything else that cares about the Ethernet address.

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

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 13:35:29 GMT
From:      usenet.ins.cwru.edu!po.CWRU.Edu!cjs@tut.cis.ohio-state.edu  (Christopher J. Seline)
To:        tcp-ip@nic.ddn.mil
Subject:   How do I make 'calls' to Standford TCPIP for the PC

Hi,
We've got Stanford's PC TCPIP software on our PCs.  Is there some type 
of standard for placing 
calls to it?

thanks in advance,

cjs@cwru.cwru.edu
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 13:44:06 GMT
From:      sun-barr!newstop!texsun!letni!mic!supernet!gtoye@decwrl.dec.com  (Gene Toye)
To:        tcp-ip@nic.ddn.mil
Subject:   Info on TN3270 Protocol

Does anyone know where I can get a specification for the protocol
used by TN3270 for communicating with the IBM host/controller?
I specifically mean the protocol for data to/from the TN3270 application,
not SNA or 3270 Data Stream.

Thanks for your assistance.
-- 
Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248
Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org
Usenet:   uunet!{iex,ntvax}!supernet!gtoye
DISCLAIMER: My employer never knows what I am going to say next.
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 14:54:01 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   in-addr.arpa used?

Our name server, on a VM system, receives reverse mapping queries.
One reason found is mailing on Unix systems, that also produces other
strange requests (sendmail.mx on SunOS, see below).
I am wondering how many such requests will come from the Internet when
we will be connected.
So, my question is: how useful is it to ask our administrators
to implement their in-addr.arpa domains?
Is it usually done?

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET

Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09
 Oct 90 15:49:11 +0100
Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX)
 with  TCP; Tue, 09 Oct 90 15:49:09 +01
Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0)
        id AA08359; Tue, 9 Oct 90 15:49:38 +0100
Received: by rib1 (4.0/SMI-4.0)
        id AA06469; Tue, 9 Oct 90 15:49:26 +0100
Date: Tue, 9 Oct 90 15:49:26 +0100
From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI)
Message-Id: <9010091449.AA06469@rib1>
To: pirard@vm1.ulg.ac.be

datagram from 139.165.16.1 port 2013, fd 8, len 43
req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12
req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0)
forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec

datagram from 139.165.2.1 port 53, fd 8, len 43
send_msg -> 139.165.16.1 (UDP 11 2013) id=2

datagram from 139.165.16.1 port 2014, fd 8, len 42
req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1
req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2014) id=3 Local

datagram from 139.165.16.1 port 2015, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 4 type=1
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2015) id=4 Local

datagram from 139.165.16.1 port 2016, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 5 type=15
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2016) id=5 Local

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Oct 90 15:54:01 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil, IBM TCP/IP List <IBMTCP-L@PUCC>
Subject:   in-addr.arpa used?
Our name server, on a VM system, receives reverse mapping queries.
One reason found is mailing on Unix systems, that also produces other
strange requests (sendmail.mx on SunOS, see below).
I am wondering how many such requests will come from the Internet when
we will be connected.
So, my question is: how useful is it to ask our administrators
to implement their in-addr.arpa domains?
Is it usually done?

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET

Received: from BLIULG11 by BLIULG11 (Mailer R2.07) with BSMTP id 5355; Tue, 09
 Oct 90 15:49:11 +0100
Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP R1.2.2MX)
 with  TCP; Tue, 09 Oct 90 15:49:09 +01
Received: from rib1 ([139.165.8.17]) by montefiore.ulg.ac.be (4.0/SMI-4.0)
        id AA08359; Tue, 9 Oct 90 15:49:38 +0100
Received: by rib1 (4.0/SMI-4.0)
        id AA06469; Tue, 9 Oct 90 15:49:26 +0100
Date: Tue, 9 Oct 90 15:49:26 +0100
From: pirard@montefiore.ulg.ac.be (PIRARD ANDRE tel 4932 SEGI)
Message-Id: <9010091449.AA06469@rib1>
To: pirard@vm1.ulg.ac.be

datagram from 139.165.16.1 port 2013, fd 8, len 43
req: nlookup(17.8.165.139.in-addr.arpa) id 2 type=12
req: missed '17.8.165.139.in-addr.arpa' as '' (cname=0)
forw: forw -> 139.165.2.1 8 (53) nsid=80 id=2 3225ms retry 6 sec

datagram from 139.165.2.1 port 53, fd 8, len 43
send_msg -> 139.165.16.1 (UDP 11 2013) id=2

datagram from 139.165.16.1 port 2014, fd 8, len 42
req: nlookup(vm1.montefiore.ulg.ac.be) id 3 type=1
req: found 'vm1.montefiore.ulg.ac.be' as 'vm1.montefiore.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2014) id=3 Local

datagram from 139.165.16.1 port 2015, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 4 type=1
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2015) id=4 Local

datagram from 139.165.16.1 port 2016, fd 8, len 31
req: nlookup(vm1.ulg.ac.be) id 5 type=15
req: found 'vm1.ulg.ac.be' as 'vm1.ulg.ac.be' (cname=0)
req: answer -> 139.165.16.1 11 (2016) id=5 Local
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 18:44:31 GMT
From:      maytag!focsys!larry@iuvax.cs.indiana.edu  (Larry Williamson)
To:        tcp-ip@nic.ddn.mil
Subject:   telnet & rlogin set /dev/ttyp* mod differently

people that rlogin to machines here have their /dev/ttp* entries mod's
set differently. In particular, if one telnets, then /dev/ttyp* is set
with mod 111, whereas if one logs in with rlogin, then it is set 666.

Why is this? How can I define what the setting should be? I don't want
to put chmod commands in /etc/profile or the user's profiles. 

the systems involved here are Interactive's 386/ix 2.2. Rlogins and
telnets are from many different types of machines and terminal
servers.

-Larry
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 20:15:13 GMT
From:      DANIEL@UIUCVMD
To:        comp.protocols.tcp-ip
Subject:   .netrc equivalent

I'm porting an UNIX/VMS TCP/IP based application written in C to VM/CMS.
This application normally refers to the .netrc file to get password
information.  Are there any convensions on CMS for the equivalent?

Also, the program does not like to send the password across the net in
clear text so it calls the standard UNIX crypt command to do the DES
encryption of the password.  Is the DES encription available on VM/CMS
systems if I don't own the standard IBM box to do this?  What is the
standard calling procedure for programs using an IBM DES configuration?

-- Daniel Pommert
 pommert@uiuc.edu

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 20:28:02 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is a UNIX Domain Socket?
On 27 Sep 90 18:06:32 GMT, harvey@dg-rtp.dg.com (Michael Harvey) said:

harvey> In article <82@unigold.UUCP>, lance@unigold.UUCP (Lance
harvey> Ellinghouse) writes:

lance> Ok, I know this is a dumb question..  What exactly is a Unix
lance> Domain Socket?  What makes it different from a INET Socket?

harvey> A socket is simply a communication endpoint.  Sockets support
harvey> two communications domains: the UNIX domain for
harvey> process-to-process communication on the same host, and the
harvey> Internet domain for process-to-process communication between
harvey> hosts that communicate with one another using the DARPA standard
harvey> communication protocols, such as IP, TCP, and UDP.

harvey> In the UNIX domain, socket names are UNIX pathnames;
harvey> for example, a socket may be named /tmp/foo.
harvey> Naming sockets in the Internet domain involve concatenating
harvey> the Internet address with a port number.

harvey> I think that covers the basics.  Comments?

I think I can do better :-). Under Unix all out-of-address space
communication (except for ptrace(2) and signals) is via file
descriptors; file descriptors have a common interface, based on
read/write readv/writev, and ioctl(), etc..., and a type.

One of the types of a file descriptor is socket; when a file descriptor
is a socket, it is attached using a full duplex channel to another
socket file descriptor somewhere.

Socket file descriptors have a number of properties that normal file
descriptors do not have; among these are the type of communication
(stream, message, etc...), an identifier, two modes of connecting a
socket to another for transmitting data, and whether there is the
possibility to transmit file descriptors over the channel.

Socket file descriptors are supported by a a set of protocol
implementations called a 'domain'; only sockets in the same domain may
be connected.

The UNIX domain is a domain where there is only one socket type, only
one protocol, the pipe protocol, where the only socket type allowed is
stream, where socket identifiers are pathnames in the UNIX filesystem,
and where filedescriptors may be passed thru the communication channel
between two sockets.

By contrast the INET domain supports three socket types (stream,
datagram and raw), a number of protocols, socket identifiers are
internet 32 bit numbers, and filedescriptors may not be passed thru the
channel between two sockets.

Many other domains exist.

In the original 4.2BSD design it was to be possible to have user
processes implement domains, by putting the protocol code in the user
process, and having all communications between two sockets in that user
domain be interepted by the user process implementing that domain.

This is still possible by using the UNIX domain, even if in a contrived
way (in particular it is not possible to support other than stream
sockets), by having users for that domain connect in the UNIX domain to
the user implemented domain server, that would return a socket in that
domain (actually a socket to itself, usually, in the UNIX domain).
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 21:29:05 GMT
From:      elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com  (Michael O'Brien)
To:        tcp-ip@nic.ddn.mil
Subject:   Use of TCP/IP with satellite delays
Someone recently asked a question about use of TCP/IP over a satellite
link, and since I've never worked in that realm, the ground got mushy
under my feet.  I'd like a reality check.

I seem to recall that TCP/IP is perfectly usable over a satellite link
that has reasonably high bandwidth, but 300msec propagation delays.
Adaptive retransmission and multi-packet frames get around this problem,
no?  Of course, char-at-a-time telnet will lose no matter what, but
mail and file transfers should move acceptably, right?

More specifically I'm talking about something like a KA9Q implementation
running via satellite radio link from a research vessel at sea.
--
Mike O'Brien
obrien@aerospace.aero.org
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 21:53:06 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: in-addr.arpa used?
In article <9010091715.AA05649@ucbvax.Berkeley.EDU> PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) writes:
   ...how useful is it to ask our administrators to implement their
   in-addr.arpa domains?  Is it usually done?

See RFC1123 ("Requirements for Internet Hosts -- Application and
Support"), section 6.1.1:

         Every host MUST implement a resolver for the Domain Name
         System (DNS), and it MUST implement a mechanism using this
         DNS resolver to convert host names to IP addresses and
         vice-versa [DNS:1, DNS:2].

Yes, it's very useful.  It's usually done.  Addresses for which
reverse mapping is not maintained are not in conformance to the
applicable standards, and should receive a firm finger-wagging.  If
your local administrators hesitate, bash them over the head with a
printed copy of RFC1123, all 98 pages.

Hmmm, I just noticed upon closer reading that this requirement only
applies to the resolver that must be available on each host.  It
doesn't say that an authoritative reverse mapping must be available
(from some name server somewhere) for every address.  So bash them
gently, if you must :-)
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 22:18:43 GMT
From:      ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls56!fortinp@beaver.cs.washington.edu  (Pierre Fortin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
In article <12628063537.11.BILLW@mathom.cisco.com>, BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
> 
> 	Does anyone know of a product that supports [cslip]?  SLIP is
> 	sssoooo easy to configure slip on an Annex. It seems like a shame
> 	to waste it, but ftp and telnet are so gawdawfully slow even over
> 	a 38.4k link that I still resist putting it in place.
> 
> Really?  FTP is slow?  Our experience at cisco (with our own terminal
> servers, of course) was that FTP was quite zippy - the sliding window
> of TCP bought you much more than you lost from the big headers.  Compared
> to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast.

Care to share the test configuration with us?  I use SLIP over a Microcom
AX/9624c MNP Class 6 modem and a cisco terminal server.  I see the modem
lights grinding away, waiting..., grinding away, waiting..., etc.
It's almost as though the VJ algorithms were throttling...  I found I could
get more files through by starting 2-3 FTPs so that one is still running when
the other 1-2 are stalled.  Sort of round-robin FTP transfers; doesn't work
if I've only got one file to transfer though... :^(

> 
> Telnet, however, was quite painful, and I don't even want to think about
> running telnet and FTP at the same time.

When you're FTPing and your only link is tied up, you're quite happy to be
able to get *any* response to keep working.  If only I had what ammounts to
"local echo" or tn3270-type buffering on telnet over SLIP... sigh.
> 
> BillW
> -------


Pierre Fortin       Bell-Northern Research     I know, my postings are
Internet Systems    P.O.Box 3511, Stn C        terse and humourless. So?
(613)763-2598       Ottawa, Ontario            RIP: aptly named protocol
fortinp@bnr.ca      Canada    K1Y 4H7          AppleTalk: Adam&Eve's design
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 22:58:36 GMT
From:      apple.com!erekose@apple.com  (Erik Scheelke)
To:        tcp-ip@nic.ddn.mil
Subject:   File Broadcast
We have a local area network of UNIX based PCs running TCP-IP, and I
was asked if there was any software that will broadcast a file to all
machines on the network.  I didn't know of any and was wondering if
anyone out there in netland knew of any.  If not, I guess I will have
to write something myself.  I would appreciate any infomation about
programs or algorithms that do file broadcasting.  It must use a broadcast,
not a copy to one machine then copy to another method (i.e. UDP), and
if a machine is up it must reliably send the file.

Thanks in advance for any help!

Erik Scheelke
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Oct 90 10:51:51 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  Use of TCP/IP with satellite delays
It works fine.  TELNET on the other hand is something of a pain.  I have
done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village
CA (LA area) with two satellite hops and a 9600 baud link between Westlake
and Marina Del Rey.  Found you forget what you typed and can almost go out-
side for a smoke waiting for the echo.

Merton
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 90 23:16:54 GMT
From:      spdcc!dyer@husc6.harvard.edu  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
I think your problems are more to do with the nature of your modems
than any inherent problems with medium speed SLIP links.  I lived for
two years quite happily with a LADS circuit supporting a full time
point-to-point SLIP connection running at 19.2kb.  No fancy modems,
just a pair of local data sets.  19.2kb SLIP is subjectively quite
reasonable, and I found that even on a heavily loaded line supporting
NNTP, a couple of telnet/rlogin sessions, regular SMTP traffic and the
occasional FTP, the delay wasn't all THAT bad.

All bets are off when you start talking about pseudo-full-duplex modems
like Telebit Trailblazers or MNP6, or noisy lines or lossy serial interfaces.
But let's identify *these* as potential areas of problems, and not tar
the underlying technology unjustly.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 03:16:26 GMT
From:      brunix!euclid.math.temple.edu!freedman@uunet.uu.net  (Avi Freedman)
To:        tcp-ip@nic.ddn.mil
Subject:   Can I use the Berkeley lp protocol for remote DOS prints from COM1?
I've got NCSA telnet configured and printing remotely off of a Sun, but
is there any commercial/pd program out there which lets me trap what goes
to com1/com2/prn from an application?  (I've got an application which 
can't print to a file).  Any pointers would be greatly appreciated.

	- Avi
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Wed 10 Oct 90 12:24:44-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        fortinp@bnr.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP, IP Routers and Named Pipes
    > 
    > Really?  FTP is slow?  Our experience at cisco (with our own terminal
    > servers, of course) was that FTP was quite zippy - the sliding window
    > of TCP bought you much more than you lost from the big headers.  Compared
    > to DEC-20 to PC kermit, FTP's FTP over slip was nearly twice as fast.

    Care to share the test configuration with us?  I use SLIP over a
    Microcom AX/9624c MNP Class 6 modem and a cisco terminal server.  I
    see the modem lights grinding away, waiting..., grinding away,
    waiting..., etc.  It's almost as though the VJ algorithms were
    throttling...  I found I could get more files through by starting 2-3
    FTPs so that one is still running when the other 1-2 are stalled.
    Sort of round-robin FTP transfers; doesn't work if I've only got one
    file to transfer though... :^(


The configuration was a 286 based PC clone running either (old, non-sliding
window, 92 byte packet) MSDOS kermit or FTP software's package v 1.16,
connected vai a 19.2kbps direct line to aa cisco terminal server (v6.1
software?  This was slightly before SLIP was released on the cisco TS)
We were talking to either HPUX or TOPS20 (no VJ algorthims in sight!)

FTP software was configured with a window size of 1024, and an MSS of 512,
if I remember correctly.  It's sort of important (with no slow start) that
the number of MSS packets in a window be both larger than 1 and smaller than
the effective queue-size on the terminal server (then 3, now settable). (Your
description of the problem sounds exactly like the MSS is > window/2, so that
you end up operating lock-step instead of sliding windows, by the time SWS
algorithms come into play.)

FTP file transfer speeds were about 13kbps, while kermit was about half that.

I haven't done those tests in a couple of years, though - I would hope that
everything still works at least as well as it did then!

Bill Westfield
cisco Systems.
-------
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 06:04:40 GMT
From:      cbmvax!grr@uunet.uu.net  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: is syslog(3) to remote possible?
In article <111@fedeva.UUCP> bill@fedeva.UUCP (Bill Daniels) writes:
> I posted a similar request about a week or two ago.  Just as luck would
> have it my news machine went away for a couple of days right afterwards.
> 
> I have need to log operator messages via syslog(3) on a remote machine. I
> am sure that this is possible because of the way the docs and headers read.
> It seems however that Ultrix has coded up syslog() so that all messages go
> to the local machine.

The Ultrix syslog seems to be able to capture and display remote syslog
messages, but doesn't seem to be able to direct it's own messages to
another system.

Other people have claimed that the BSD 4.3 syslog stuff is easy to get
working with Ultrix, but I haven't tried it (yet).

Note that having Ultrix syslog capture messages originating from a Sun system
results in a ugly syslog file, apparently there is some format divergence.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Oct 90 10:29:26 EDT
From:      Chris Weider <clw@merit.edu>
To:        system@lns61.tn.cornell.edu, tcp-ip@nic.ddn.mil
Subject:   re: Reply to Ethernet Address Uniqueness...
In a recent message (10/5), Selden E. Ball, Jr. states that:
>Of course, the fact that DECnet addresses are limited to 16 bits
>means that larger networks are limited to a maximum of about 64K
>systems. My guess is that there are fewer than a dozen networks
>for which this causes problems.
I think this estimate is conservative. :)

On CICNet, we've had to jerry-rig our routers to get a true heirarchical
DECNet architechture; I suspect that a lot of other regionals have had to also.
I'm eagerly awaiting DECnet Phase 5.
Chris Weider
-----------------------------------------------------------------------------

Chris Weider                        | -Geteilte Freude ist  
MERIT's CICNet Technical Rep.       |   doppelte Freude 
email: clw@merit.edu                |     -Goethe 
Phone: (313) 936-2090  or           | -Party on, dudes! 
       1-800-66-MERIT               |   -Abraham Lincoln, "Bill and Ted"
 
 
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 13:54:58 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
In article <4401@spdcc.SPDCC.COM> dyer@spdcc.COM (Steve Dyer) writes:
   All bets are off when you start talking about pseudo-full-duplex
   modems like Telebit Trailblazers or MNP6, or noisy lines or lossy
   serial interfaces.  But let's identify *these* as potential areas
   of problems, and not tar the underlying technology unjustly.

We see very reasonable performance with compressed-header SLIP or PPP
between Sun-4/60s over a pair or Trailblazer Plusses:  1.3-1.5Kb/sec
FTP throughput with PPP, nearing the modem's advertised pipe diameter.
Interactive response OK too, though not what you'd call "pleasant" if
you're used to fatter hoses.  I haven't tried high values of MNP or
HST.

Don't bother with Classic SLIP, particularly not with TBs.
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 16:36:46 GMT
From:      clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!cunews!mentor.gandalf.ca!ddrg@uunet.uu.net  (Duncan Glendinning)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Use of TCP/IP with satellite delays
In article <88084@aerospace.AERO.ORG> obrien@aero.aero.org (Michael O'Brien) writes:
>Someone recently asked a question about use of TCP/IP over a satellite
>link, and since I've never worked in that realm, the ground got mushy
>under my feet.  I'd like a reality check.
>
>I seem to recall that TCP/IP is perfectly usable over a satellite link
>that has reasonably high bandwidth, but 300msec propagation delays.
>Adaptive retransmission and multi-packet frames get around this problem,
>no?  Of course, char-at-a-time telnet will lose no matter what, but
>mail and file transfers should move acceptably, right?
>
>More specifically I'm talking about something like a KA9Q implementation
>running via satellite radio link from a research vessel at sea.
>--
>Mike O'Brien
>obrien@aerospace.aero.org

We've successfully run SLIP over a satelite link between our offices
here in Ottawa, and both Wheeling IL, and Warrington UK.  Though a bit
slow for interactive use (9600 baud) it was possible.  The primary
use was for large (>1M byte) file transfers, where we saw better
throughput than kermit.  Here are some results:

   Wheeling IL to Ottawa Ont:
      file size: 2744320 bytes ftp: 76 min kermit: 995 min

Please note that the 9600 baud channel is just one of a number that
are stat muxed.
-- 
Duncan Glendinning         CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 17:11:02 GMT
From:      psuvm!drj100@psuvax1.cs.psu.edu  (Daniel R. Jeuch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bad SLIP performance (was Re: SLIP, IP Routers and Named Pipes)
In article <BOB.90Oct10095447@volitans.MorningStar.Com>, bob@MorningStar.Com
(Bob Sutterfield) says:
>
>We see very reasonable performance with compressed-header SLIP or PPP
>between Sun-4/60s over a pair or Trailblazer Plusses:  1.3-1.5Kb/sec
>FTP throughput with PPP, nearing the modem's advertised pipe diameter.
>Interactive response OK too, though not what you'd call "pleasant" if
>you're used to fatter hoses.  I haven't tried high values of MNP or
>HST.
>
>Don't bother with Classic SLIP, particularly not with TBs.

Unfortunately, here at Penn State, all we have is MNP5 9600 V.32 dial-in
lines... I get throughput with classic SLIP (PSU also doesn't use
compression) of somewhere between .8-.9kb/sec.  Not great, but it's
free for Penn State students... (Kind of important for my budget!)
TN3270 does suffer, though!
-----
Daniel R. Jeuch                   Microsoft Corp. Student Rep.
10 Vario Blvd., Box 185           DRJ100@PSUVM, drj100@psuvm.psu.edu
State College, PA  16803          (814) 867-4622, (800) 232-5129
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 18:00:22 GMT
From:      timbuk!redwood22!nrd@uunet.uu.net  (Neal Dalton)
To:        tcp-ip@nic.ddn.mil
Subject:   I there a Compressed SLIP for Sun OS 4.1
I've seen slip for Sun OS 4.1 and am tring to find out how to implement cslip on Sun OS 4.1

In cslip for Sun OS 4.0 they provided a tty driver modified for compression.  Will this 
work for OS 4.1 or did 4.1 fix the problems with 4.0.

-- 
Neal  /\    /   _     /   \|||/                   Neal Dalton
     /  \  / _  _\   /   /     \                  Cray Research, inc
    /    \/_</_(_/\_/   (  o o  ) _________       655-F Lone Oak Dr.
                         \  ^  / /         \      Eagan, MN 55121
                          \ 0 / <   OH NO,  )
Internet: nrd@cray.com     \_/   \ not him!/      Fax:   (612) 683-5599
    uucp: uunet!cray!nrd          \_______/       Phone: (612) 683-5607
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 18:12:47 GMT
From:      GHOLAN@vm.ucs.UAlberta.CA (Geoffrey Holan)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   runing ka9q on appletalk

Has anyone got the localtlk packet driver working,
this is for use with a ka9q router. I am unable to
load-up the correct appletalk drivers for localtlk
to talk to. I am using the lsl.com, atalk.com and
ltalkp.com, but none of them seem to be the proper
driver(s) that localtlk needs to use to talk to the
ibm pc appletalk board. I am using the 7 version
of Clarkson's packet drivers..
   any hints would be appr.  thanks

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 23:18:00 EDT
From:      "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   SNMP  Agent by Proxy

From:
David Sweigert
supporting U.S. Special Operations Command

We are trying to find the public domain software for a SNMP
package that can run off a PC.  We would like to modify the 
source code to acquire data from a Veristron TCU.  Anyone
know where we can get an SNMP Agent for a PC. ???

po box 4423
annapolis, md 21403

301-637-5098


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 90 20:03:07 GMT
From:      pacbell.com!pacbell!dplace!hicom!toshiya@decwrl.dec.com  (Toshiya Itoh)
To:        tcp-ip@nic.ddn.mil
Subject:   Connectathon??


Does anybody know the word "Connectathon?" (may not be right spell)

I heard it's the name of a kind of competition of TCP/IP implementations.

If it was true, how can I get the information about the result of this
competition?


Thank you very much in advance,

Toshiya Itoh.

==========================================================
Software Engineer
Hitachi Computer Products Inc.
3101 Tasman Dr.
Santa Clara, Ca. 95054

E-mail t_itoh@hitachi.com
==========================================================
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 00:22:25 GMT
From:      munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@uunet.uu.net  (Andrew McRae)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for in_cksum for 68k.
Does anyone have a 68000 specific in_cksum routine for
doing IP checksums?

I have been using the machine independent version,
but I have looked at the VAX and CCI routines that came
with the 4.3 BSD network source, and it seems it would be
a big win to have a 68k version. I am actually running a
68000 rather than a 68020, but a 68020 version would be
useful as a starting point.

Thanks!

Andrew McRae			inet:	andrew@megadata.mega.oz.au
Megadata Pty Ltd,		uucp:	..!uunet!megadata.mega.oz.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 03:14:33 GMT
From:      pyrdc!pyrnj!bartal!monymsys!sonyd1.Broadcast.Sony.COM!blilly.UUCP!balilly.UUCP!bruce@uunet.uu.net  (Bruce Lilly)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
In article <linegar.655064040@bwdls49> linegar@bwdls49.bnr.ca (Derick Linegar) writes:
>
>[ ... ]
> Now I've been searching the RFC and IEEE docs and I cannot
>find any documentation that sort of says that Ethernet Addresses are assigned
>to Ethernet boards, not hosts.
>
>Anyone have an idea where it might be. I cannot go back to the vendor and
>say 
>
>  " .... well everyone *knows* that ethernet addresses *must* be unique..."

``For information on global (U) address administration contact the
Secretary, IEEE Standards Board, 345 East 47 Street, New York, NY 10017.''

(Footnote on page 26 of ANSI/IEEE Standard 802.3-1985  ISO/DIS 8802/3)

My recollection is that each manufacturer is assigned a group of addresses
and is expected to make the hardware address unique for each interface.
As has been pointed out (for the specific case of DECnet) it is also
possible to override the hardware address via software, and that may be a
part of your problem.

The IEEE Secretary ought to be able to clarify this situation, and may be
able to tell you what range of addresses are assigned to your particular
vendor.

Late flash: after checking several references, I found:

``14.4.2 Ethernet addresses

Host computers on Ethernet are identified by two addresses, the Ethernet
address (a 48-bit hardware address) and an IP or software address.
Ethernet addresses are guaranteed unique because vendors building Ethernet
interfaces have a set of addresses assigned to them. The IEEE Standards
Board in New York City assigns the first 24 bits to a manufacturer, which
then allocates the last 24 bits sequentially.  The address is either built
into the interface board or stored in ROM on the board.''

(From _UNIX(R)_System_Administration_Handbook_ by Nemeth, Snyder, and
Seebass, published by Prentice-Hall, p. 243) An excellent book, by the
way, although it is heavily biased toward BSD.

Note however that the IEEE standard permits either 16-bit or 48-bit
addresses, so don't take that too literally.

Hope this helps.
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 03:18:00 GMT
From:      dsweigert@PAXRV-NES.NAVY.MIL ("SWEIGERT, DAVID")
To:        comp.protocols.tcp-ip
Subject:   SNMP  Agent by Proxy


From:
David Sweigert
supporting U.S. Special Operations Command

We are trying to find the public domain software for a SNMP
package that can run off a PC.  We would like to modify the 
source code to acquire data from a Veristron TCU.  Anyone
know where we can get an SNMP Agent for a PC. ???

po box 4423
annapolis, md 21403

301-637-5098

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 09:14:00 CDT
From:      "Nunez, Paul" <nunez@tawc1.eglin.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Need SMB Info
I need information on SMB.  I've seen it referred to as both Server Message
Block protocol and Server Management Block protocol - which is correct?  Where 
can I get more information on what it is and how it works?  

Also, would those of you running in an SMB client/server environment please
pass on information concerning your server product (Company names, phone 
numbers, problems, etc.).  I am especially interested in a comparison of 
Wollongong's SMB server product vs. Syntax's.  Someone told me Syntax's 
product (name unknown) is licensed by Wollongong (is OEM'd the correct term?).
Is this true?

We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. 

Please reply to me directly; I'll summarize and post if enough interest.

Thanks,
=======================================================================
PAUL E. NUNEZ  (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil)
USAFTAWC/SCAM   EGLIN AFB, FL 32542          (904-882-4100)

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Oct 90 11:41:41 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        munnari.oz.au!metro!natmlab.dap.csiro.au!megadata!andrew@UUNET.UU.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Looking for in_cksum for 68k.
 > 
 > Does anyone have a 68000 specific in_cksum routine for
 > doing IP checksums?
 > 
 > I have been using the machine independent version,
 > but I have looked at the VAX and CCI routines that came
 > with the 4.3 BSD network source, and it seems it would be
 > a big win to have a 68k version. I am actually running a
 > 68000 rather than a 68020, but a 68020 version would be
 > useful as a starting point.

Look at RFC 1071....

1071  Braden, R.T.; Borman, D.A.; Partridge, C.  Computing the Internet
      checksum.  1988 September; 24 p. (Format: TXT=54941 bytes)  (Updated by
      RFC 1141)

Frank Kastenholz
Racal Interlan
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Oct 90 11:59:26 EDT
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        TCP-IP@NIC.DDN.MIL
Subject:   traceroute on 3B2/600 under TWG's TCP/IP

Hello all,

	I am in the process of porting traceroute to an AT&T 3B2/600 with the
AT&T Enhanced WIN/3B TCP/IP software from Wollongong.

	Will the IPPROTO_RAW work as delivered? I noticed that the
docs for traceroute indicate a mod to the BSD kernel's raw IP output
routine is required, but I have no clue as to whether the same is true
for System V/3.2.2.

	On execution, I get SO_SNDBUF: Bad protocol option, which
would lead me to believe that there is some lower-lever work needed.
Of course, if I #undef SO_SNDBUF, the code runs, but all I see are
lines with "*    *    *".

	Failing that, does anyone know where I might find a version of
traceroute already written for System V machines?

Thanks in advance!

Bob Stratton 		| dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet]
NAVMEDATASERVCEN	| dsc3rjs@vmnmdsc		      [BITNET]
(Innova Comms. / AT&T)	| 295-3371 [AV]    +1 301 295 3371    [PSTNet]
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 10:21:18 GMT
From:      mcsun!i2unix!alessia!athena@uunet.uu.net  (Matteo Frigo)
To:        tcp-ip@nic.ddn.mil
Subject:   Strange bahaviour of an LSX3020 with tcp protocol

	I have an Olivetti LSX3020 with Ethernet card, 8Mb
ram and 280MB hard disk. I am on Internet. I have this problem:
I can connect to Europe from here (Padova, Italy) and
and to East Coast (NY and Boston), but I cannot have
any tcp service from Berkeley, ucsd and so on.
Next to the LSX I have a Sun 3 which works and has no
problem in telnetting and ftp-ing to the entire world.

	I suspect it is a problem of timeouts, but I have
absolutely no idea of where to put my hands on.

	I noted the machine worked before the new link between
CNUCE and SURA, and in some moments it works again for a few
minutes.

	Any help would be appreciated. I am quite disperate
because the LSX acts as nameserver and mail exchanger for 
the domain dei.unipd.it, as other machines cannot be used
for that for technical and administrative reasons, and my
system has stopped working with no apparent reason.

Matteo Frigo
athena@alessia.dei.unipd.it

( try to reply with athena%alessia.dei.unipd.it@mcsun.eu.net because
of these problems)
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 13:35:25 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdlh131!mleech@ucbvax.Berkeley.EDU  (Marcus Leech)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Use of TCP/IP with satellite delays
In article <88084@aerospace.AERO.ORG>, obrien@aero.aero.org (Michael O'Brien) writes:
> More specifically I'm talking about something like a KA9Q implementation
> running via satellite radio link from a research vessel at sea.
KA9Q works very well in this type of environment--Phils round-trip-timer
  algorithm is generally acknowledged to be the best in the business.  It's
  quite accurate, and converges quickly.  I've used KA9Q over a
  satellite link between Ottawa, and Calgary.  Provided you have a low
  BER, you can simply crank up your TCP WINDOW and MSS and expect to get
  quite good performance for FTP, etc.
-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CANADA      |necessarily BNRs
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 14:14:00 GMT
From:      nunez@TAWC1.EGLIN.AF.MIL ("Nunez, Paul")
To:        comp.protocols.tcp-ip
Subject:   Need SMB Info

I need information on SMB.  I've seen it referred to as both Server Message
Block protocol and Server Management Block protocol - which is correct?  Where 
can I get more information on what it is and how it works?  

Also, would those of you running in an SMB client/server environment please
pass on information concerning your server product (Company names, phone 
numbers, problems, etc.).  I am especially interested in a comparison of 
Wollongong's SMB server product vs. Syntax's.  Someone told me Syntax's 
product (name unknown) is licensed by Wollongong (is OEM'd the correct term?).
Is this true?

We have 6 uVAX 3600's running VMS 5.3-1 and Wollongong's WIN/TCP for VMS V5.1. 

Please reply to me directly; I'll summarize and post if enough interest.

Thanks,
=======================================================================
PAUL E. NUNEZ  (nunez@tawc1.eglin.af.mil) or (nunez@uv4.eglin.af.mil)
USAFTAWC/SCAM   EGLIN AFB, FL 32542          (904-882-4100)

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 17:15:34 GMT
From:      usc!cs.utexas.edu!execu!sequoia!cb@ucsd.edu  (Christopher D. Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP (socket library) for MS Windows 3
Execucom is building an MS Windows 3.0 software product 
which supports TCP/IP using the socket library model.  
Frankly, we were hoping that Sun would have already 
delivered the supporting network software ...  In any case, 
we need to get on with this aspect of the project and are 
looking for commercial software supporting TCP/IP via 
sockets under Windows 3 (including 386 enhanced mode).

I am doubtful about using the public domain software so 
frequently discussed here.  This route would seem to require 
a good deal more technical expertise than a commercial 
package.  A commercial package would also seem to reduce 
legal difficulties when reselling the software.  Is this too 
conservative?

"Network Windows (TM) Software Development Kit" from 
Distinct Corporation in Saratoga, CA claims to meet my 
requirements.  I would appreciate hearing from anyone who 
has experience with this product and/or company.  Pointers 
to alternate products would be gratefully accepted.

If there appears to be any interest, I post any alternate 
vendors and product reviews.

Thanks in advance.

Chris
-- 
Christopher D. Brown

Digital: {uunet|cs.utexas.edu}!execu!cb
Analog: (512) 327-7070
Physical: Execucom, 108 Wild Basin Road, Two Wild Basin, Austin, TX 78764
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Oct 90 16:38:43 +0100
From:      "Alain FONTAINE (Postmaster - NAD)" <af%sei.ucl.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Heathkit Weather Computer (IDW5001)
On Wed, 3 Oct 90 16:24:46 GMT David M. Siegel said:
>would be nice to use a "standard" weather TCP/UDP protocol for this
>purpose.  Ideally, all Internet sites with weather data could support
>this protocol.  The protocol should be extensible, since it is hard to
>anticipate all types of weather data that people might have.
>
>I'm wondering, does such a protocol exist?
>
This question has been discussed some months ago. The conclusion was that no
new protocol is needed: this is an ideal application for SNMP. Just define
a weather-report MIB....

P.S. I tried a private reply, but it was bounced at uunet.....

Alain FONTAINE                       +--------------------------------+
Universite Catholique de Louvain     | If your mail software barks at |
Service d'Etudes Informatiques       | my address, you may try :      |
Batiment Pythagore                   |                                |
Place des Sciences, 4                |     FNTA80@BUCLLN11.BITNET     |
B-1348 Louvain-la-Neuve, BELGIUM     +--------------------------------+
phone +32 (10) 47-2625
z * * * 47745578
'Alain FONTAINE (Pos David M. Siegel     10/11/90*Heathkit Weather Computer (IDW
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 90 23:55:50 GMT
From:      jay@axiom.maths.uq.oz.au (Joseph Young)
To:        comp.protocols.appletalk,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Mac Access to TCP/IP



I'm faced with the following configuration:

          +-----+                                                +-----+
          ! Mac !                                                ! IBM !
          +--+--+                                                ! PCs !
             !                +--------+                         +--+--+
   Novell Trunk - LocalTalk   ! Novell !  Novell Trunk - Ethernet   !
-------------+----------------+ File   +----------+-----------------+--->
                              ! Server !          !
                              +--------+          !
                             (NetWare 2.15)    +--+---+
                                               !Bridge!(Brand: Wellfleet) 
                                               !Router!
                                               +--+---+
                     Ethernet to remote hosts     !  (TCP/IP)
           ---------------------------------------+-----------------------

Question: How can I get the Macintoshes on the Novell LocalTalk trunk talking
          to the remote hosts on the Ethernet running TCP/IP. The type of
          services I'm interested in are Telnet, FTP and mail.

Any help would be greatly appreciated .. I'm fairly new at this type of thing.

Joe Young

jay@axiom.maths.uq.oz.au

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 October 1990 0933-PDT (Friday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re: Ethernet Address Uniqueness...
The 10base5 NI cards in our AT&T 3b2's were all delivered with
the same ethernet address.  This was a big surprise, because we
too had come to expect manufacturer's would assign unique addresses.
The similar ethernet addresses didn't cause any problems because
the IP layer in each machine filtered out only those packets destined
for the local machine.  Everyone ARP'ed to the same ethernet address.  
Sort of like multicasting (unicasting?).  We didn't realize what was
happening until packet tracing to find an unrelated problem.  We've
since found an undocumented command which allows setting the ethernet
address and the machines now all have unique ethernet addresses.

Ron Stanonik
stanonik@nprdc.navy.mil
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Oct 90 07:40:58 EDT
From:      R17G000 <R17G@UNB.CA>
To:        <TCP-IP@NIC.DDN.MIL>
Subject:   Can I use the Berkeley lp protocol for remote DOS prints fromCOM1?
> I've got NCSA telnet configured and printing remotely off of a Sun, but
> is there any commercial/pd program out there which lets me trap what goes
> to com1/com2/prn from an application?  (I've got an application which
> can't print to a file).  Any pointers would be greatly appreciated.
>
> 	- Avi

Could you please post your findings to the list if applicable or forward
them to me at R17G@UNB.CA ?

Thanks in advance.
---------------------------------------------------------------+
Abdulaziz Al-Zoman             |          R17G@UNB             +
Faculty of Computer Science    |            -or-               |
University of New Brunswick    |          r17g@unb.ca          +
F'ton, N.B                     |            -or-               |
CANADA   E3B 5A3               |          r17g@unb.bitnet      +
---------------------------------------------------------------+
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 07:42:56 GMT
From:      mintaka!olivea!samsung!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@bloom-beacon.mit.edu  (Arnold Nipper)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: access to polydos.uni-konstanz.de
In article <1627.655631099@munnari> kre@MUNNARI.OZ.AU (Robert Elz) writes:
>For TCP-IP reades, this was (part of a message) sent to INFO-NETS ...
>
>    Date:        Wed, 10 Oct 90 22:44:14 PDT
>    From:        netinfo@violet.berkeley.edu (Postmaster & BITINFO)
>    Message-ID:  <9010110544.AA12667@violet.berkeley.edu>
>
>    I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop)
>    packets appear to go into a black hole.
>
>I didn't believe that number when I first saw it ... thought
>it must be a typo, or something, so I just had to try it
>for myself...
>
>But sure enough, its correct, there is something out there,
>pretending to be net 188.1, and connected to the Internet.

Yes, the netname is WIN-IP (WIssenschaftsNetz) and this net
is an IP/X.25 net connecting most of the German universities
and other research institutions.

>
>Unless some very strange thigs have happened, net 188.1 is
>not yet allocated to anyone (and perhaps by the time it is
>no-one will really care anyway, as its so close to the end
>of the available class B numbers).  Certainly there are no
>allocated 188.* nets listed in the NIC's network-contacts.txt
>file.

Nets 188.1 - 191.254 are preallocated to what is called
PDN cluster. This net clustering is the basis for the
PDN cluster addressing scheme which uses it to do efficient
routing. Contact C.-H. Rokitansky ( roki@dhafeu52.bitnet ) to
get more information about this. He is the former chairman
of the IETF working group on PDN.

>
>Is there some proper person to get in contact with these
>people and politely, or very impolitely, suggest that if
>they want to be connected to the internet, they should be
>using properly allocated numbers?
>

For more information about this, please contact:

	Martin Wilhelm
 	Verein zur Foerderung eines Deutschen Forschungsnetzes (DFN) e.V.
 	Zentrale Projektleitung
 	Pariser Strasse 40
 	W-1000 Berlin 15
 	Federal Republic of Germany
 	+49 30 884299 30
 	wilhelm@zpl.dfn.dbp.de

If you have problems to reach uni-konstanz.de please contact me or:

	Jochen Bruening
	University of Konstanz
 	Universitaetsstrasse 10
 	Postfach 5560, D-7750 Konstanz
 	+49 7531 88 2410
 	rzbng@dknkurz1.bitnet

>Its no wonder that routing isn't working...

Net 188.1 is only the backbone for IP/WIN. Therefor there should be
no problems to reach any site in Germany connected to the internet.
Of course if you want to connect to some backbone machine with a
188.1 address you will fail.

Arnold
********************************************************************************
Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe *  +49 721 608 4331
********************************************************************************
-----------[000143][next][prev][last][first]----------------------------------------------------
From:      lefty@TWG.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Connectathon??
>Does anybody know the word "Connectathon?" (may not be right spell)
>
>I heard it's the name of a kind of competition of TCP/IP implementations.

Connectathon is actually an interoperability testing event for ONC/NFS
implementations.  Many vendors who have NFS products set them up on a
shared network and attempt to run a standard set of test suites in an
attempt to get everybody's implementations to work against everybody
else's.

Connectathon 1991 is scheduled to be held this coming March, in San Jose.

--
David N. Schlesinger                 |    Internet:  lefty@twg.com
The Wollongong Group                 |    AppleLink: D6122
1129 San Antonio Road                |    AOL:       lefty3
Palo Alto, CA  94303                 |
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 09:09:26 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Use of TCP/IP with satellite delays



 >>Someone recently asked a question about use of TCP/IP over a satellite
 >>link, and since I've never worked in that realm, the ground got mushy
 >>under my feet.  I'd like a reality check.
 

You should see paper by Seo et al in sigcomm 88 for measurement of TCP
& IP over SATNET - the relevant bits include:

slow start and mean+variance RTT estimator TCP over the atalantic 
packet satellite
network - 

even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade
...it just isnt a problem any more :-)

jon

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 10:12:49 GMT
From:      apple.com!erekose@apple.com  (Erik Scheelke)
To:        tcp-ip@nic.ddn.mil
Subject:   Reliable Datagram Protocols
Does anyone know of a reliable connectionless datagram protocol that
runs on top of UDP?  Is so, is there a library out there I can get?

Thanks in advance,
Erik Scheelke
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Oct 90 17:44:59 +1000
From:      Robert Elz <kre@munnari.oz.au>
To:        netinfo@violet.berkeley.edu (Postmaster & BITINFO)
Cc:        info-nets@Think.COM, TCP-IP@Nic.DDN.MIL
Subject:   Re: access to polydos.uni-konstanz.de
For TCP-IP reades, this was (part of a message) sent to INFO-NETS ...

    Date:        Wed, 10 Oct 90 22:44:14 PDT
    From:        netinfo@violet.berkeley.edu (Postmaster & BITINFO)
    Message-ID:  <9010110544.AA12667@violet.berkeley.edu>

    I get to Germany in 17 hops, then beyond 188.1.132.24 (21st hop)
    packets appear to go into a black hole.

I didn't believe that number when I first saw it ... thought
it must be a typo, or something, so I just had to try it
for myself...

But sure enough, its correct, there is something out there,
pretending to be net 188.1, and connected to the Internet.

Unless some very strange thigs have happened, net 188.1 is
not yet allocated to anyone (and perhaps by the time it is
no-one will really care anyway, as its so close to the end
of the available class B numbers).  Certainly there are no
allocated 188.* nets listed in the NIC's network-contacts.txt
file.

Is there some proper person to get in contact with these
people and politely, or very impolitely, suggest that if
they want to be connected to the internet, they should be
using properly allocated numbers?

Its no wonder that routing isn't working...

kre
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Oct 90 10:09:26 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        ddrg@mentor.gandalf.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Use of TCP/IP with satellite delays


 >>Someone recently asked a question about use of TCP/IP over a satellite
 >>link, and since I've never worked in that realm, the ground got mushy
 >>under my feet.  I'd like a reality check.
 

You should see paper by Seo et al in sigcomm 88 for measurement of TCP
& IP over SATNET - the relevant bits include:

slow start and mean+variance RTT estimator TCP over the atalantic 
packet satellite
network - 

even a mere RSRE algoritm RTT TCP ran in service over SATNET for a decade
...it just isnt a problem any more :-)

jon
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Oct 90 13:56:28 MEZ
From:      Ewald Jenisch <Z00EJR01%AWIUNI11@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   ISO Country codes
Does anybody out there in the netland know where I can find a listing
of all ISO Country Codes. As far as I remember there was such a list
hanging around for anonymous FTP but I don't remember which server.

Thanks in advance for any help,
Ewald JENISCH
University Computer Center
University of Vienna, Austria
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E-mail: Z00EJR01@AWIUNI11.BITNET                Snail-mail:
        Z00EJR01@helios.edvz.univie.ac.at       Universitaetsstrasse 7
Tel.:   (+43 222) 43-61-11/251                  A-1010 Vienna, Austria
Fax:    (+43 222) 43-61-11/170                  Europe
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 16:43:53 GMT
From:      Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch)
To:        comp.protocols.tcp-ip
Subject:   ISO Country codes

Does anybody out there in the netland know where I can find a listing
of all ISO Country Codes. As far as I remember there was such a list
hanging around for anonymous FTP but I don't remember which server.

Thanks in advance for any help,
Ewald JENISCH
University Computer Center
University of Vienna, Austria
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E-mail: Z00EJR01@AWIUNI11.BITNET                Snail-mail:
        Z00EJR01@helios.edvz.univie.ac.at       Universitaetsstrasse 7
Tel.:   (+43 222) 43-61-11/251                  A-1010 Vienna, Austria
Fax:    (+43 222) 43-61-11/170                  Europe

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 17:04:24 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!ni.umd.edu!sayshell.umd.edu!louie@ucsd.edu  (Louis A. Mamakos)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for in_cksum for 68k.
In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>Does anyone have a 68000 specific in_cksum routine for
>doing IP checksums?

The is the checksum routing that I use in the Amiga port of the KA9Q TCP/IP 
package.  It seems to work.

louie


;
;  Compute the 1's complement sum of data buffer.  Called from C as
;
;	unsigned short
;	lcsum(buf, cnt)
;		unsigned short *buf;
;		unsigned short cnt;
;
;
_lcsum:
	MOVE.L	4(A7),A0	; get pointer to data block
	MOVE.L	8(A7),D1	; get number of 16bit words to sum
	MOVE	D2,A1		; save D2 in a volitile register
	MOVE	D1,D2		; save a copy of the count
	LSR.L	#1,D1		; convert from words to longs
	MOVEQ.L	#0,D0		; D0 used to accumulate the sum, clear CC
	BRA.S	endl		; jump to end of loop to start things off
;
; Take advantage of 68010 loop mode cache and add 2 words at a time until
; a carry propagates out.  68020 users win 'cause of instruction cache.
;
loop:	ADD.L	(A0)+,D0	; add two words in
endl:	DBCS	D1,loop
	BCC.S	done		; jump if done
	ADDQ.L	#1,D0		; add in carry
	BRA.S	endl		; resume loop
done:
	BTST	#0,D2		; was word count odd?
	BEQ.S	done2

	MOVEQ.L	#0,D2
	MOVE.W	(A0),D2		; get the last word
	ADD.L	D2,D0		; add it in
	BCC.S	done2		; did that cause a carry?
	ADDQ.L	#1,D0		; yes
done2:
	MOVE.L	A1,D2		; restore register

	MOVE.L	D0,D1		; get copy of sum	     D0=ABCD D1=ABCD
	SWAP.W	D1		; into low order part of D1  D0=ABCD D1=CDAB
	AND.L	#$FFFF,D1	; zap (is this necessary?)   D0=ABCD D1=00AB
	ADD.W	D0,D1		; two halfs of sum together
	MOVEQ.L	#0,D0
	ADDX.W	D0,D1		; get last carry
	MOVE.W	D1,D0
	RTS
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 19:42:09 GMT
From:      media-lab!media-lab.media.mit.edu!dnb@eddie.mit.edu  (David N. Blank)
To:        tcp-ip@nic.ddn.mil
Subject:   netdiag?
Howdy-
  In my travels along the anonymous ftp byways I encountered a file
called netdiag.tar.Z that had what appeared to be a really handy
network debug/display tool with some problems:
  1) It was a set of Sun 3 binaries with no source code that ran only
     under Suntools.
  2) The README file was truncated at 512 bytes, (in mid-sentence,
     even).
  3) There were not docs external to the program.
Does anyone have any information on this program and where I could get
a more complete version of it?  Thanks muchly in advance.
        Peace,
          dNb
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 90 23:00:10 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!atmos.washington.edu!harry@ucsd.edu  (Harry Edmon)
To:        tcp-ip@nic.ddn.mil
Subject:   Where can I find source to PPP or SLIP?
Where can I get source to PPP or SLIP for SunOS 4.1?  Please mail
responses directly to me.  Thanks.
--
Harry Edmon		INTERNET: harry@atmos.washington.edu
(206) 543-0547		UUCP:	  uw-beaver!atmos.washington.edu!harry
Dept of Atmospheric Sciences, AK-40
University of Washington
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 00:21:43 GMT
From:      excelan!donp@ames.arc.nasa.gov  (don provan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes:
>I believe that Novell's IPX similarly hacks the Ethernet address....

This has nothing to do with TCP-IP, but i don't want this rumor to
spread.  IPX does not modify the ethernet address.
							don provan
							donp@novell.com
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 03:44:02 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!caen!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   connect: Network is unreachable, (or) I want my FTP
From: emv@math.lsa.umich.edu (Edward Vielmetti)

My site gets a feed of the sub.* and dnet.* newsgroups, which are in
German.  There is a fair amount of interesting stuff discussed in
these groups, and it's a good way to put that high school German to
practice.  More to the point, there is a fair amount of software
developed in Germany which is made available for anonymous FTP, that
is to say stuff available there and nowhere else.

So, when I see in sub.tex that there's an interesting set of TeX
macros to be had from "forwiss.uni-passau.de", my first inclination is
to go and take a look and get them.  And the last thing that I want to
see is "Network is unreachable" with the traceroute stopping at my
local NSS.  It is extremely frustrating, that I can learn about
European internet resources via Usenet, but when I go to connect to
the the NSF backbone blocks my access.

Do any of the USA "commercial" internet service providers provide
access to the European networks which aren't permitted to use the NSF
backbone?  I.e., if my regional network were to get say an Alternet or
PSI connection they could receive the Euro-routes that way and there
would be access.  Or perhaps my regional already has a transatlantic
link, and they could bypass the backbone that way?  One way or another
there has to be a legit way to be "part of" the Euro-internet and not
get blockaded by the NSF.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives

ps. forwiss.uni-passau.de [132.231.1.10], in /archive/tex/macros/nice20.zoo.
"Jetzt hoffe ich, dass das Makropaket einen groesseren Kreis von Anwendern findet."
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 03:58:38 GMT
From:      jarthur!bridge2!api!gpz@uunet.uu.net  (G. Paul Ziemba)
To:        tcp-ip@nic.ddn.mil
Subject:   TFTP: should ERROR be ACK-ed?
Please forgive me if this question has been beaten to death
in previous discussions; I am new to this group.

I have seen some TFTP clients exhibit the following behavior, and I
would like to know if it is correct:

    1. client sends a RRQ (read request) to a server.

    2. server decides it cannot perform the request,
       so server sends an ERROR to the client.

    3. client sends an ACK to the server.

Should the client have sent an ACK?

 ~!paul
--
Paul Ziemba  api!gpz  gpz@ESD.3com.com  408.764.5390   OS/2: just say no.

"How much char could a char star star if char star could star char?"
(quote stolen from mspercy@clemson.clemson.edu)
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 04:05:15 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: connect: Network is unreachable, (or) I want my FTP
In article <EMV.90Oct12224402@josephus.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:

   macros to be had from "forwiss.uni-passau.de", my first inclination is
   to go and take a look and get them.  And the last thing that I want to
   see is "Network is unreachable" with the traceroute stopping at my

My local friendly network service trouble desk informs me that the NSFnet
has a request to add this to their routing tables, so I guess you should
tone down some of the rhetoric of the previous message.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Oct 90 16:26 EDT
From:      BIWINE%vassar.bitnet@pucc.PRINCETON.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Protocol analyzer
Is anyone aware of pd software that would turn a workstation (U*ix, VMS,
MS-DOS, or Mac) into an Ethernet protocol analyzer?

Thanks for your help.

Bill Wine
biwine@vassar.bitnet
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Oct 90 19:08:22 -0400
From:      Hans-Werner Braun <hwb@merit.edu>
To:        emv@math.lsa.umich.edu
Cc:        hwb@merit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  connect: Network is unreachable, (or) I want my FTP
Ed Vielmetti:

Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with
the hope for increased knowledge on your part about how things interact, I
find it regrettable that you have to air your frustrations in public, in
particular given the tone you used. Look, you describe access to a 
University, for which in general NSF takes a quite liberal view. If there
is a University in at least a country that the US is friends with, NSF,
to the best of my knowledge, never objected to have them be known to the
NSFNET. With some international sites we need to get concurrance from a
national coordination body, in the case you mentioned, University of Passau in
Germany, we need concurrance from, e.g., DFN as a german national coordination
body. Once we receive a confirmation we need to request permission from
the NSF for each and every international network to be configured. The NSF
confirmation is to protect both NSF as well as Merit. Sometimes, including
in this case, where a network is requested to be configured via multiple NSS
entry points, we also need to confirm the announcements with all the sites a
network should be configured for, to allow for the proper coordination as
well as the proper metric configuration for primary, secondary, etc. paths.
All of this is standard procedure and should not take more than a few days.

If a network is unknown, it has typically either not been requested for
addition to the policy data base or it is not been dynamically announced
at the time you tried by the client network to the NSS where it would be
announced to or there is a time window between a request and the configuration
(which should typically not last for more than a few days and only happen once 
until it is configured).

I will attach some relevant messages which show you that you got caught in the
window between request and configuration.

An intelligent approach towards dealing with these kind of issues would be to
communicate with your local provider of campus networking. Generally this
should work fine with most campuses, which then deal with the appropriate
regional network and/or the NSFNET NOC. In your case, as you know, they are
all the same (UMnet + Merit + NSFNET) and you should have been able to get the
information easily. You are otherwise wasting alot of time, effort and
bandwidth.

	Hans-Werner Braun

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

To: nsfnet-admin@merit.edu
Subject: Network Announcement Change Request
Cc: hostmaster@mcsun.EU.net, hostmaster@germany.eu.net, kaehler@zpl.dfn.dbp.de,
        wilhelm@zpl.dfn.dbp.de, staff@sunic.sunet.se, ops@uunet.uu.net,
        Ruediger Volk <unido!rv@relay.EU.net>
From: hostmaster@mcsun.EU.net
X-Organisation: EUnet/Alternet
X-Phone: +31 20 5924112
Date: Wed, 10 Oct 90 19:50:39 +0100
Sender: dfk@mcsun.EU.net


Hi,

Please add the following networks to the NSFnet routing database.
All networks are in Germany (no problems with east and west anymore :-).
All of them have ICS sponsored by NSF according to their admins.

Routing is coordinated within RIPE and US connectivity is via
EUnet/Alternet with backup via NORDUnet.

Thank you for your cooperation

Daniel Karrenberg
EUnet/Alternet Routing Contact



        ***** Network Announcement Change Request *****


                          Inbound Announcements        Add/Del 
                               to NSFNET              or Change
                          --------------------------- ---------
Network Number/Name       1stAS# 2ndAS# 3rdAS# 4thAS#   A/D/C    Country
-------------------       ------ ------ ------ ------ ---------  -------

130.149 TUB                 701    224    97              A       Germany
132.180 UNIBT-LAN           701    224    97              A       Germany
132.231 UNI-PASSAU          701    224    97              A       Germany
134.100 UNIHH               701    224    97              A       Germany
134.107 MPPMU-LAN           701    224    97              A       Germany
141.1 DFN-WIN1 (ECRCNET)    701    224    97              A       Germany
141.2 DFN-WIN2 (UNI-FFM)    701    224    97              A       Germany
192.54.41 EMBNET            701    224    97              A       Germany

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

Date: 12 Oct 90 15:47 GMT+0100
From: Martin Wilhelm <wilhelm%zpl.dfn.dbp.de@RELAY.CS.NET>
To: ip-register@MERIT.EDU
Cc: hostmaster%germany.eu.dbp.de@RELAY.CS.NET
Subject: Request for Handling

Sheri,
can you please process the following request of Ruediger Volk ?
All he institutes mentioned below belong to the academia and are members
of the DFN association.

Best regards and thanks a lot

-martin

------------------------------ cut here ---------------------------------


>From rv Mon Oct  8 07:57:35 1990
To: kaehler@zpl.dfn.dbp.de, wilhelm@zpl.dfn.dbp.de
Subject: Zulassung zum NSFnet
Cc: hostmaster@Germany.EU.net, hostmaster@noc.EU.net

Dear Colleagues,

please, forward this request to admit the following IP networks to use
the NSFnet backbone to MERIT. 
To enable us and other people involved to follow the procedure and 
help if anything should hang I suggest to use 
Cc: hostmaster@noc.EU.net, hostmaster@Informatik.Uni-Dortmund.DE
on all transactions.


net name	net number	organization

DMSWWU-ETHER	128.176		Univ. Muenster

UEGNET		132.252		Univ. Essen

UNI-OLDENBURG	134.106		Univ. Oldenburg

WICOB		192.55.244	Wissenschaftskolleg Berlin


For the first three networks listed the appropriate NOCs will be sending
requests for including routing information into the NSFnet routing policy
data base in parallel.

The appropriate NOCs also will request routing support at MERIT for the
following networks, which - to my knowledge - already have NSF's approval;
for smoothing the procedure I ask you to confirm these networks to MERIT
as well.


Net name		net number	Organization

TUB			130.149		TU Berlin

UNIBT-LAN		132.180		Univ. Bayreuth

UNI-PASSAU		132.231		Uni Passau

UNIHH			134.100		Univ. Hamburg

MPPMU-LAN		134.107		MPI f. Physik, Munich

EMBNET			192.54.41	EMBL Heidelberg

DFN-WIN1 (ECRCNET)	141.1		ECRC Munich

DFN-WIN2 (UNIFFM-NET)	141.2		Univ. Frankfurt


Thanks for your cooperation,
  Ruediger Volk

---------- End of Copy ----------

------------------------------------------------------------------------------
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 12:46:02 GMT
From:      usc!srhqla!quad1!ttidca!mb@ucsd.edu  (Michael Bloom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for in_cksum for 68k.
In article <347@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>Does anyone have a 68000 specific in_cksum routine for
>doing IP checksums?
>
>I have been using the machine independent version,
>but I have looked at the VAX and CCI routines that came
>with the 4.3 BSD network source, and it seems it would be
>a big win to have a 68k version. I am actually running a
>68000 rather than a 68020, but a 68020 version would be
>useful as a starting point.

A number of years back, I posted a request similar to yours and got
not a single response.  So I went ahead and hand optimized the
assembly output from compiling the machine independent version,
taking a few hints from RFC 1071.

I measured about 35 % improvement over the straight C file compiled by
PCC.  It might be the case that compiling the straight C source with
GNU C is nearly as good as (or perhaps better than) a hand optimized
version. I don't know.  We didn't have gcc when I did this.

There's still almost certainly room for some more optimization. I'd like
to see your improvements.

I've been using this for a couple of years on our machines.  If you
use it, please do not remove the notice at the start of the file.

By the way, although the routine won't be re-entered if you are using
the bsd networking code, if you are using some other networking code, 
you might want to move s_util to the stack.

#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
#	in_cksum.s
# This archive created: Sat Oct 13 05:34:53 1990
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "extracting 'in_cksum.s'" '(6279 characters)'
if test -f 'in_cksum.s'
then
	echo shar: "will not over-write existing file 'in_cksum.s'"
else
sed 's/^	X//' << \SHAR_EOF > 'in_cksum.s'
	X#
	X# Please do not remove this comment.
	X#
	X# This file was created by Michael Bloom (mb@ttidca.tti.com) by hand
	X# optimizing the assembly output from compiling the source file "in_cksum.c"
	X# which is covered by the following notice allowing redistribution:
	X#
	X# /*
	X#  * Copyright (c) 1988 Regents of the University of California.
	X#  * All rights reserved.
	X#  *
	X#  * Redistribution and use in source and binary forms are permitted
	X#  * provided that this notice is preserved and that due credit is given
	X#  * to the University of California at Berkeley. The name of the University
	X#  * may not be used to endorse or promote products derived from this
	X#  * software without specific prior written permission. This software
	X#  * is provided ``as is'' without express or implied warranty.
	X#  *
	X#  *      @(#)in_cksum.c  7.1 (Berkeley) 3/29/88
	X#  */
	X# 
	X	file	"in_cksum.c"
	X	data	1
	X	lcomm	s_util,2
	X	text
	X	global	nin_cksum,in_cksum
	X#
	X# in_cksum(m,len)
	X#	m -> %a0
	X#	len -> %d2
	X#
	X# locals:
	X#	scratch: %a1,%d0,%d1
	X#	sum: %d3
	X#	mlen: %d4
	X#		 
	Xin_cksum:
	Xnin_cksum:
	X	link.l	%fp,&F%1
	X	movm.l	&M%1,(4,%sp)
	X	mov.l	(8,%fp),%a0	# m
	X	mov.l	(12,%fp),%d2	# len
	X
	X	clr.l	((S%1-4).w,%fp)	#   59 int byte_swapped = 0;
	X
	X	mov.l	&0,%d3		#   60 register sum = 0;3
	X	mov.l	&0,%d4		# register mlen = 0;
	XL%cksm50:				#   63 for (;m && len; m = m->m_next) {
	X	mov.l	%a0,%d0
	X	beq	L%cksm49
	X	tst.l	%d2
	X	beq	L%cksm49
	X	tst.w	(%a0,8.w)	# if (m->m_len == 0) 
	X	beq	L%cksm48			# continue;
	XL%cksm51:	
	X	mov.l	%a0,%d0		# w = (( u_short *)((int)(m) + (m)->m_off)); 
	X	add.l	(%a0,4.w),%d0	#
	X	mov.l	%d0,%a1		#
	X	mov.l	&-1,%d0		#
	X	cmp.l	%d4,%d0		# if (mlen == -1) {
	X	bne.b	L%cksm52	
	X# The first byte of this mbuf is the continuation of a word spanning
	X# between this mbuf and the last mbuf.  s_util.c[0] was already saved
	X# when scanning previous mbuf.
	X
	X	mov.b	(%a1),s_util+1	#	 s_util.c[1] = *(char *)w;
	X	mov.l	&0,%d0		#
	X	mov.w	s_util,%d0	#
	X	add.l	%d0,%d3		#	 sum += s_util.s;
	X	lea.l	(%a1,1.w),%a1	#	 w = (u_short *)((char *)w + 1);
	X	mov.w	(%a0,8.w),%d0	#	 mlen = m->m_len - 1;
	X	ext.l	%d0		#
	X	sub.l	&1,%d0		#
	X	mov.l	%d0,%d4		#	""
	X	sub.l	&1,%d2		#	 len--;
	X	bra.b	L%cksm53		# } else {
	XL%cksm52:				#	 not a cont. of word spanning 2 mbufs
	X	mov.w	(%a0,8.w),%d0	#
	X	ext.l	%d0		#
	X	mov.l	%d0,%d4		#	 mlen = m->m_len;
	XL%cksm53:				# }
	X	cmp.l	%d2,%d4		# if (len < mlen)
	X	bge.b	L%cksm54		#
	X	mov.l	%d2,%d4		#	 mlen = len;
	XL%cksm54:				#
	X	sub.l	%d4,%d2		# len -= mlen;
	X#				#
	X# Force to even boundary	#
	X#				#
	X	mov.l	%a1,%d0		# if ((1 & (int) w) && (mlen > 0)) {
	X	and.l	&1,%d0		#
	X	beq.b	L%cksm55		#
	X	tst.l	%d4		# 
	X	ble.b	L%cksm55		#
	X	mov.l	%d3,%d0		# REDUCE
	X	swap	%d0		#
	X	add.w	%d0,%d3		#
	X	mov.l	&0,%d0		#
	X	addx.w	%d0,%d3		#
	X	and.l	&0xffff,%d3 	# ""
	X
	X	lsl.l	&8,%d3		#	 sum <<= 8;
	X	mov.b	(%a1),s_util	#	 s_util.c[0] = *(u_char *)w; 
	X	lea.l	(%a1,1.w),%a1	#	 w = (u_short *)((char *)w + 1); 
	X	sub.l	&1,%d4		#	 mlen--;
	X	mov.l	&1,((S%1-4).w,%fp)#	 byte_swapped = 1;
	X				#  }
	XL%cksm55:				# if ((2 & (int) w) && (mlen > 0)) {
	X	mov.l	%a1,%d0		#	 if >= 2 bytes left and now
	X	and.l	&2,%d0		#	 short aligned, add first
	X	beq.b	L%cksm56		#	 short so rest is long
	X	mov.l	&2,%d0		#	 aligned.
	X	cmp.l	%d4,%d0		#
	X	blt.b	L%cksm56		#
	X	mov.l	&0,%d0		#	 sum += *w++;
	X	mov.w	(%a1)+,%d0	#
	X	add.l	%d0,%d3		#
	X	sub.l	&2,%d4		#	 mlen-=2;
	X				#  }
	XL%cksm56:	
	X	mov.l	%d4,%d1		#
	X	mov.l    %d1,%d0 	#
	X	lsr.l    &6,%d1 	# number of times in loop = mlen/64
	X	and.l    &0x3c,%d0 	#
	X	neg.l    %d0 		#
	X	add.l	%d0,%d4 	#
	X	and.b    &0xf,%cc 	#
	X	jmp     66(%pc,%d0.b) 	# jump into middle of table for first iter
	Xnextloop: 
	X	mov.l    (%a1)+,%d0 	
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	X	mov.l    (%a1)+,%d0 
	X	addx.l   %d0,%d3 
	Xendloop: 
	X	mov.l	&0,%d0		# (move does not affect X bit)
	X	addx.l	%d0,%d3		# add in carry from addx last operation
	X	dbra    %d1,nextloop 	# (dbra does not affect X bit)
	X	and.l	&0x3,%d4	# above loop got all but possibly last 4 bytes
	X				# if (mlen == 0 && byte_swapped == 0)
	X				#	   continue
	X	bne.b	L%cksm57
	X	tst.l	((S%1-4).w,%fp)
	X	beq.b	L%cksm48	
	X# REDUCE
	XL%cksm57:
	X	mov.l	%d3,%d1
	X	swap	%d1
	X	add.w	%d1,%d3
	X	mov.l	&0,%d0
	X	addx.w	%d0,%d3
	X	and.l	&0xffff,%d3
	XL%cksm_11:
	XL%cksm58:				# while ((mlen -= 2) >= 0) {
	X	sub.l	&2,%d4
	X	blt.b	L%cksm59
	X	mov.l	&0,%d0			# sum += *w++;
	X	mov.w	(%a1)+,%d0
	X	add.l	%d0,%d3
	X	bra.b	L%cksm58		# }
	XL%cksm59:
	X	tst.l	((S%1-4).w,%fp)	# if (byte_swapped) {
	X	beq.b	L%cksm60
	X	# REDUCE
	X	mov.l	%d3,%d1
	X	swap	%d1
	X	add.w	%d1,%d3
	X	mov.l	&0,%d0
	X	addx.w	%d0,%d3
	X	and.l	&0xffff,%d3
	XL%cksm_13:
	X	lsl.l	&8,%d3		# sum <<= 8;
	X	clr.l	((S%1-4).w,%fp)		# byte_swapped = 0;
	X	mov.l	&-1,%d0		# if (mlen == -1) {
	X	cmp.l	%d4,%d0
	X	bne.b	L%cksm61
	X	mov.b	(%a1),s_util+1		# s_util.c[1] = *(char *)w;
	X	mov.l	&0,%d0			# sum += s_util.s;
	X	mov.w	s_util,%d0
	X	add.l	%d0,%d3
	X	mov.l	&0,%d4			# mlen = 0;
	X				# } else
	X	bra.b	L%cksm62
	XL%cksm61:
	X	mov.l	&-1,%d4		#	 mlen = -1;
	XL%cksm62:
	X	bra.b	L%cksm63		# } else if (mlen == -1)
	XL%cksm60:
	X	mov.l	&-1,%d0
	X	cmp.l	%d4,%d0
	X	bne.b	L%cksm64
	X	mov.b	(%a1),s_util	#	 s_util.c[0] = *(char *)w;
	X				# }
	XL%cksm64:
	XL%cksm63:
	XL%cksm48:
	X	mov.l	(%a0),%a0
	X	bra	L%cksm50
	XL%cksm49:
	X	tst.l	%d2		# if (len)
	X	beq.b	L%cksm65
	X	data	2		# printf("cksum: out of data\n");
	XL%cksm67:
	X	byte	'c,'k,'s,'u,'m,':,0x20,'o
	X	byte	'u,'t,0x20,'o,'f,0x20,'d,'a
	X	byte	't,'a,'\n,0x00
	X	text
	X	mov.l	&L%cksm67,(%sp)
	X	jsr	printf
	XL%cksm65:		# if (mlen == -1) {
	X	mov.l	&-1,%d0
	X	cmp.l	%d4,%d0
	X	bne.b	L%cksm68
	X	clr.b	s_util+1		# s_util.c[1] = 0;
	X	mov.l	&0,%d0		# sum += s_util.s;
	X	mov.w	s_util,%d0
	X	add.l	%d0,%d3
	X	mov.l	&0,%d0
	X	addx.l	%d0,%d3		# handle carry
	X	#  183 }
	X	# REDUCE
	XL%cksm68:
	X	mov.l	%d3,%d1		
	X	swap	%d1
	X	add.w	%d1,%d3
	X	mov.l	&0,%d0
	X	addx.w	%d3,%d0
	X	and.l	&0xffff,%d0
	X	not.w	%d0		# return (~sum & 0xffff);
	X				#  186 }
	X	movm.l	(4,%sp),&M%1
	X	unlk	%fp
	X	rts
	X	set	S%1,0
	X	set	T%1,0
	X	set	F%1,-28
	X	set	M%1,0x001c 
	X	data	1
SHAR_EOF
if test 6279 -ne "`wc -c < 'in_cksum.s'`"
then
	echo shar: "error transmitting 'in_cksum.s'" '(should have been 6279 characters)'
fi
fi
exit 0
#	End of shell archive
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 14:22:55 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!i32fs2!nipper@ucsd.edu  (Arnold Nipper)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: connect: Network is unreachable, (or) I want my FTP
In article <EMV.90Oct12224402@josephus.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>From: emv@math.lsa.umich.edu (Edward Vielmetti)
>
>My site gets a feed of the sub.* and dnet.* newsgroups, which are in
>German.  There is a fair amount of interesting stuff discussed in
>these groups, and it's a good way to put that high school German to
>practice.  More to the point, there is a fair amount of software
>developed in Germany which is made available for anonymous FTP, that
>is to say stuff available there and nowhere else.
>
>So, when I see in sub.tex that there's an interesting set of TeX
>macros to be had from "forwiss.uni-passau.de", my first inclination is
>to go and take a look and get them.  And the last thing that I want to
>see is "Network is unreachable" with the traceroute stopping at my
>local NSS.  It is extremely frustrating, that I can learn about
>European internet resources via Usenet, but when I go to connect to
>the the NSF backbone blocks my access.

That's not the right point of view. Obviously U Passau does not want
to have access to the Internet. There are at least four access points
to the Internet in Germany ( via EASInet, DFN, Unido, XLINK ).

>
>Do any of the USA "commercial" internet service providers provide
>access to the European networks which aren't permitted to use the NSF
>backbone?  I.e., if my regional network were to get say an Alternet or
>PSI connection they could receive the Euro-routes that way and there
>would be access.  Or perhaps my regional already has a transatlantic

XLINK provides access to PSI net for everyone in Germany who wants. But 
of course you have to pay for services. :-)

>link, and they could bypass the backbone that way?  One way or another
>there has to be a legit way to be "part of" the Euro-internet and not
>get blockaded by the NSF.
>
>--Ed
>

Arnold
********************************************************************************
Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de
XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe *  +49 721 608 4331
********************************************************************************
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 21:18:16 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reply to Re: Ethernet Address Uniqueness...
In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes:
> This is a standard gotcha of using protocols that change the address.
> There is no solution other than to make sure that DECNet is always
> started before anything else that cares about the Ethernet address.


I do not see the problem.  When our DECNET stuff changes the MAC address as
it starts, it tells the ethernet driver to call arpwhohas() again, just
as if the driver were starting from scratch.  The result is that the rest
of the IP network sees nothing stranger than if you had quickly taken your
system down, switched ethernet cards, and rebooted.  The general mechanism
can be encapsulated in an ioctl() so that all media can be wishywashy
about MAC addresses.  Changing ethernet MAC addresses using this ioctl()
works just fine on our systems.  I can't imagine anyone doing less
(for DECNET if not the ioctl()), so I'm sure Sun, DEC, and the other UNIX
DECNET vendors do the same or better.

It is true that bad things happen if you try to start DECNET on two
different boxes with the same node and area numbers, or otherwise try to
share a single MAC address with more than one machine.  However, this is
not much worse than assigning a single IP address to more than host.


Vernon Schryver,   vjs@sgi.com
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 21:35:12 GMT
From:      swrinde!cs.utexas.edu!sun-barr!newstop!exodus!cs%Eng.Sun.COM@ucsd.edu  (Carl Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Connectathon??
> Does anybody know the word "Connectathon?" (may not be right spell)
> 
> I heard it's the name of a kind of competition of TCP/IP implementations.
> 
> If it was true, how can I get the information about the result of this
> competition?

	Connectathon (TM) is the name of an event whose original purpose was
to bring together NFS implementations and ensure that they interoperated.  In
later years, X Window System testing has also been added.  I've been there as
a vendor and as part of the group putting it on.  It was never intended to be
a competition.  Nor is it intended to be a trade show (although there is a
press event at its conclusion).  It is purely an engineering event.  Any NFS
or X Window System implementation is eligible (and should make a concerted
effort) to attend.  An announcement is normally published in comp.protocols.nfs
and comp.windows.x when the dates and location have been decided.
	Testing results are never published.  Sun (the event's major sponsor)
doesn't even allow access to the results by any of our employees who aren't
directly involved in running the event.

			Carl
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 90 22:07:52 GMT
From:      mcsun!hp4nl!star.cs.vu.nl!rvdp@uunet.uu.net  (=Ronald van der Pol)
To:        tcp-ip@nic.ddn.mil
Subject:   3com ethernetcard + SCO TCP/IP

I have some problems with a 3COM 503 Ethernet card. It only
seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I
use the default IRQ vector of 2. When I try to set the IRQ 
to 5 it doesn't work (e.g. when I install the Unix e3B driver). 
Should I use some additional (MS-DOS??) setup software? 
(there is no interrupt conflict!)

--
		Ronald van der Pol  <rvdp@cs.vu.nl>
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 90 02:55:17 GMT
From:      sdd.hp.com!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Re: Ethernet Address Uniqueness...
In article <9010121633.AA00795@atlantic.nprdc.navy.mil> stanonik@nprdc.navy.mil writes:
>The 10base5 NI cards in our AT&T 3b2's were all delivered with
>the same ethernet address...

AT&T has probably been bitten by a problem that has affected a number of
established companies when they tried to build Ethernet gear:  traditional
production facilities have a very strong mindset towards building utterly
identical boxes, and the only thing they are set up to do with PROMs is to
duplicate them.  If you simply hand them the new design and tell them to
build it, the odds are very good that you will get identical Ethernet
addresses, even if it says in the fine print that they should be different.
And testing the new boards one at a time won't catch it!
-- 
"...the i860 is a wonderful source     | Henry Spencer at U of Toronto Zoology
of thesis topics."    --Preston Briggs |  henry@zoo.toronto.edu   utzoo!henry
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 90 03:34:53 GMT
From:      mintaka!spdcc!dyer@BLOOM-BEACON.MIT.EDU  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  connect: Network is unreachable, (or) I want my FTP
In article <9010132308.AA16298@kiddo.merit.edu> hwb@MERIT.EDU (Hans-Werner Braun) writes:
>Given all your frequent interactions with the Merit/UMnet/NSFNET NOC with
>the hope for increased knowledge on your part about how things interact, I
>find it regrettable that you have to air your frustrations in public, in
>particular given the tone you used...You are otherwise wasting alot of time,
>effort and bandwidth.

Sitting here, it is not at all clear which was the more obnoxious message, nor
which the greater waste of bandwidth.  I'd rather read a bit of enthusiastic
questioning given the spirit of this list than the same amount of pompous
bureaucratese offered in response.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 90 23:11:39 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip
Subject:   New product announcement: NFSper





FOR IMMEDIATE PUBLICATION			OCT 14, 1990


ESP Software
11 Grant St.
Potsdam, NY 13676


ESP Software would like to announce their newest product, NFSper.
NFSper is a NFS server with an order of magnitude better performance
than any existing NFS server.  NFSper uses a proprietary technique to
cache NFS requests on the client before they are transmitted to the
server.  Lab tests have shown that the NFS packet are available on the
client an average of 100 microseconds before the client sends the
request.  Under test conditions, we have observed packets a full 250
uSec before the request transmission!

NFSper avoids paradoxical effects by caching the packet rather than
actually upcalling it.  If the request packet falls on the floor, or
the client fails to carry out its intent to send the request, then the
client will never request the packet from the cache.  Of course, in
the case of high network loads or indecisive software, NFSper will
rapidly fill your cache, removing any performance advantage.

NFSper comes with programmers guidlines for stern, decisive coding.
The sooner a decision is made to request a packet, the sooner NFSper
can start sending the reply.  We have found that most software makes
this decision soon enough, but new software should of course take
advantage of this new technology.

We are currently working on TelePathWay, "All the Network without all
the wiring."  TelePathWay does away with the need to run coax or
twisted pair.  TelePathWay plugs into the AUI port found on most
Ethernet equipment.  You must supply your own telepath.  Deliveries
are expected by 4Q91.


				Direct all inquiries To:

				Russell N. Nelson, President
				ESP Software
				11 Grant St.
				Potsdam, NY 13696

				(315)265-5655



--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
It's better to get mugged than to live a life of fear -- Freeman Dyson

-----------[000167][next][prev][last][first]----------------------------------------------------
From:      ljm@mercury.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re:  Can I use the Berkeley lp protocol for remote DOS prints from, COM1?

>I've got NCSA telnet configured and printing remotely off of a Sun, but
>is there any commercial/pd program out there which lets me trap what goes
>to com1/com2/prn from an application?  (I've got an application which 
>can't print to a file).  Any pointers would be greatly appreciated.

Wollongong will provide LPR print redirector software in December, FTP
Software should also be shipping something 'real soon now'.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

P.S. Please post any follow up comments which require a distribution
list audience to pcip@udel.edu.

-----------[000168][next][prev][last][first]----------------------------------------------------
From:      ljm@mercury.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   All nets broadcasts (was: SLIP, IP Routers and Named Pipes)

>
>Am I correct in assuming that it is the 'non-passing' for certain
>IP/UDP broadcast packets that prevents 'stock' named-pipes from
>working across IP routers?
>

Yes.

>
>If that is the only reason, then could one expect named-pipes to work
>across a router that could be configured to pass these broadcasts in a
>controlled manner? (no loops and all that...)
>

The basic problem is that Lan Manager is trying to overcome its lack
of a directory services with a mechanism, all-nets-broadcast, which
just doesn't belong in an network with over a million users.

If you really need to support LM's naming mechanisms, a more reasonable
approach is to catch those broadcast NetBIOS name requests and translate
them into DNS requests.

enjoy,
leo j mclaughlin iii
ljm@twg.com

P.S. Please pass any comments about the number of nodes/users to
/dev/null or just read the archives of the last 'size of the Internet'
debates.


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Oct 90 09:17 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>
Cc:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   RE: SNMP  Agent by Proxy
I checked RFC 1147, and found that the CMU SNMP Distribution includes
code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent
portions of which "run on CMU's IBM PC/AT based router."  It would be
better than starting from scratch...

As given in RFC 1147, the CMU SNMP distribution is available via
anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files
pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar.

You might look for a higher release number.  I'm sure that the CMU SNMP
has been updated more recently than has its catalog entry.

- Bob Stine
  Applied Cybernetics, Inc.
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Oct 90 11:23:32 PDT
From:      postel@venera.isi.edu
To:        apple.com!erekose@apple.com, tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols
Hi.

"Reliable Datagram" is an oxymoron.

--jon.

	From tcp-ip-RELAY@NIC.DDN.MIL Fri Oct 12 17:39:16 1990
	Date: 12 Oct 90 10:12:49 GMT
	From: apple.com!erekose@apple.com  (Erik Scheelke)
	Subject: Reliable Datagram Protocols
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

	Does anyone know of a reliable connectionless datagram protocol that
	runs on top of UDP?  Is so, is there a library out there I can get?

	Thanks in advance,
	Erik Scheelke

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Oct 90 09:27 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        BIWINE <BIWINE%vassar.bitnet@pucc.princeton.edu>
Cc:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   RE: Protocol analyzer
Bill,

A quick scan of RFC 1147 did not turn up a product that would exactly
satisfy your request.  There is, however, a publically available
package that monitors ethernet traffic and displays header fields.
It's called "Netwatch".

According to RFC 1147, Netwatch is available as a utility program in the
pcip distribution from host husc6.harvard.edu, in directory pub/pcip.
Its also available as a standalone package from windom.ucar.edu,
in file pc/network/netwatch.arc. (A binary "dearc" program is also
available from windom.ucar.edu.)

Regards,

Bob Stine
Applied Cybernetics, Inc.
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Oct 90 14:38:19 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil
Subject:   Re:  Use of TCP/IP with satellite delays
> From tcp-ip-RELAY@NIC.DDN.MIL Thu Oct 11 01:16:19 1990
> Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
> Date: Wed, 10 Oct 90 10:51:51 -0700
> From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
> Message-Id: <9010101751.AA08638@WLV.IMSD.CONTEL.COM>
> To: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, tcp-ip@nic.ddn.mil
> Subject: Re:  Use of TCP/IP with satellite delays
> 
> It works fine.  TELNET on the other hand is something of a pain.  I have
> done a TELNET connection between Stuttgart-Vaihingen, FRG and Westlake Village
> CA (LA area) with two satellite hops and a 9600 baud link between Westlake
> and Marina Del Rey.  Found you forget what you typed and can almost go out-
> side for a smoke waiting for the echo.
> 
> Merton

But if you have Linemode Telnet, then the tty echo and line buffering happens
locally, making a long-delay link like this very usable for interactive
traffic, as long as you run line-oriented applications.  If you run "vi" or
some other screen oriented application that wants to do its own terminal
echoing, you switch into remote echo and lose just like before...

			-David Borman, dab@cray.com
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Oct 90 20:36:04 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        prism!ccastjr@gatech.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  The network
John:

>      Somewhere on campus here, we had a Post script formatted
> map of the network (showing who is on .mil, and who is on .com
> etc etc)...does anyone know where I can find this?

Not particularly germane to your question, but this sounds like an interesting
map.  How is the "class" of the user related to the network to which it is
connected?

Upon which network would I find *.gov, *.mil, *.com, *.edu, *.de, *.au, *.nz,
etc.?  How was this determined?  As a discrete example, on which network
would you find "contel.com"?  (A hint--name all network(s) to which contel.com
is a member--*.gov, *.mil, *.com, etc. doesn't suggest anything accept the
"class" of activity in which the organization is involved.)

Merton

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 14:17:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   RE: SNMP  Agent by Proxy

I checked RFC 1147, and found that the CMU SNMP Distribution includes
code for an SNMP agent for a Kenetics Fastpath2/3/4, the machine independent
portions of which "run on CMU's IBM PC/AT based router."  It would be
better than starting from scratch...

As given in RFC 1147, the CMU SNMP distribution is available via
anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21), as files
pub/cmu-snmp.9.tar, and pubkip-snmp.9.tar.

You might look for a higher release number.  I'm sure that the CMU SNMP
has been updated more recently than has its catalog entry.

- Bob Stine
  Applied Cybernetics, Inc.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 14:27:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   RE: Protocol analyzer

Bill,

A quick scan of RFC 1147 did not turn up a product that would exactly
satisfy your request.  There is, however, a publically available
package that monitors ethernet traffic and displays header fields.
It's called "Netwatch".

According to RFC 1147, Netwatch is available as a utility program in the
pcip distribution from host husc6.harvard.edu, in directory pub/pcip.
Its also available as a standalone package from windom.ucar.edu,
in file pc/network/netwatch.arc. (A binary "dearc" program is also
available from windom.ucar.edu.)

Regards,

Bob Stine
Applied Cybernetics, Inc.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 15:42:54 GMT
From:      sdd.hp.com!samsung!sol.ctr.columbia.edu!cica!greg@ucsd.edu  (Gregory TRAVIS)
To:        tcp-ip@nic.ddn.mil
Subject:   Need Ethernet driver for CT Megaframe

Posting for a friend, reply to below address.

Looking for Ethernet driver for a Convergent Technologies MegaFrame
AKA S1280.  Running CTIX version 5.1.

Willing to pay, vendor won't sell it to us.  No "get a new vendor" comments
please.

Thanks,
Mike Mason, ph 202-382-1274
obpa1!mem.UUCP

-- 
Gregory R. Travis                Indiana University, Bloomington IN 47405
greg@cica.cica.indiana.edu       Center for Innovative Computer Applications
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 17:42:46 GMT
From:      agate!bionet!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!evax!utacfd!letni!mic!ernest!alan@ucbvax.Berkeley.EDU  (Alan Edmonds)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can I use the Berkeley lp protocol for remote DOS prints fromCOM1?
In article <ID3364.D901012.T084058.R17G@UNB.CA> R17G@UNB.CA (R17G000) writes:
>> I've got NCSA telnet configured and printing remotely off of a Sun, but
>> is there any commercial/pd program out there which lets me trap what goes
>> to com1/com2/prn from an application?  (I've got an application which
>> can't print to a file).  Any pointers would be greatly appreciated.
>>
>> 	- Avi
>
>Could you please post your findings to the list if applicable or forward
>them to me at R17G@UNB.CA ?

Me too.
-- 
Alan Edmonds                                     Texas Instruments, Inc.
My opinions are only my own.                     M/S 8513
Work phone: (214)575-6427                        6620 Chase Oaks Blvd.
Email: alan@ernest.UUCP or alan@ernest.ti.com    Plano, Texas  75023
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 18:54:09 GMT
From:      dino!sharkey!fmsrl7!teemc!fmeed1!wehr@uunet.uu.net  (Bruce Wehr)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: HP TCP/IP router/bridge?
In article <45306@apple.Apple.COM>, brooks@Apple.COM (Kevin Brooks) writes:
> 
> Does anyone know of a bridge or router that will allow HP hosts running
> TCP/IP which speak IEEE style packets (802.2 encapsulated) to
> communicate with ethernet style IP implementations?  Do most of the
> router/bridge vendors support both IEEE and ethernet style IP packets?

I don't have much experience here, but I'm installing a small ethernet
network (about a dozen hosts) here at work - and I'm learning while
doing. My design includes a bridge in each lab, primarily to aid in
fault isolation. The bridge I've chosen is the Retix 2255.

The manual says it will pass both style packets transparently, which (I
think) answers your second question.  It also states that the software
on each respective host must deal with packet differences themselves,
which (I think) answers your first question (that is, if I understand
your first question correctly - you're looking for a bridge that will
convert one style packet to another - right?  This bridge explicitly
*won't* [and I don't know of one that will].  But, it will pass both
types, no problem).

I hope this helps.

-- 
	       Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
 (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu)
		   Ford Motor Company - Electronics Division
  17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 19:15:41 GMT
From:      bacchus.pa.dec.com!deccrl!shlump.nac.dec.com!tkou02.enet.dec.com!jituha!jitgmn.enet.dec.com!shimizu@decwrl.dec.com  (Hidetoshi Shimizu)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3com ethernetcard + SCO TCP/IP
In article <7947@star.cs.vu.nl> rvdp@cs.vu.nl (=Ronald van der Pol) writes:

> Xref: jituha comp.unix.sysv386:1390 comp.dcom.lans:12626 comp.protocols.tcp-ip:13626
> Path: jituha!tkou02.enet.dec.com!shlump.nac.dec.com!bacchus.pa.dec.com!decwrl!uunet!mcsun!hp4nl!star.cs.vu.nl!rvdp
> From: rvdp@cs.vu.nl (=Ronald van der Pol)
> Newsgroups: comp.unix.sysv386,comp.dcom.lans,comp.protocols.tcp-ip
> Date: 13 Oct 90 22:07:52 GMT
> Sender: news@cs.vu.nl
> Lines: 10
>
>
> I have some problems with a 3COM 503 Ethernet card. It only
> seems to work with SCO UNIX 3.2.0 TCP/IP (Lachmann) when I
> use the default IRQ vector of 2. When I try to set the IRQ 
> to 5 it doesn't work (e.g. when I install the Unix e3B driver). 
> Should I use some additional (MS-DOS??) setup software? 
> (there is no interrupt conflict!)
>
> --
>		 Ronald van der Pol  <rvdp@cs.vu.nl>

You should use a EtherLink-II Diagnostic Software under the MS-DOS and setup 
Interrupt vector .
--
Hidetoshi Shimizu       Digital Equipment Corporation Japan 
Financial-2 EIC         Urbannet Ikebukuro bldg 3-16-3 Higashi Ikebukuro
                        Toshima-ku Tokyo 170
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 20:26:00 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!mtecv2!vmtecmex.cem.itesm.mx!gcavazos@ucsd.edu  (Gustavo Cavazos)
To:        tcp-ip@nic.ddn.mil
Subject:   What is SNMP
What is SNMP? 
Here we have a Fastpath IV, when I check the network, besides registering 
as a Gateway it 
registers itself as a SNMP.
So what is SNMP?


-Gus Cavazos
-gcavazos at vmtecmex.bitnet
-gcavazos at vmtecmex.cem.itesm.mx
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 20:33:48 GMT
From:      asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SNMP network manager software for article
I'm doing a story on SNMP network manager software (as opposed to
agent) for a story for Business Communication Review.  If you produce
or know of such software, available to users (i.e., not OEM-only),
please let me know...or if there's some kind of global list, that'd be
great.  Thanks!

The story will be an overview of the various packages available, with
a chart comparing their features.
-- 
"Drive carefully."
"What is it with women and 'drive carefully'?  'No, I'm going to steer 
with my feet and read the comic paper.'"
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 90 20:39:20 GMT
From:      prism!ccastjr@gatech.edu  (COOOooOoooooOOOOoOOoOOooKIE!!!!!)
To:        tcp-ip@nic.ddn.mil
Subject:   The network


I have some questions.  This might be better suited to another
group (is there one dedicated to arpa/internet access besides
this one?), but here goes.

     What is the cost of having access to the net (via your
own machine)?

     Somewhere on campus here, we had a Post script formatted
map of the network (showing who is on .mil, and who is on .com
etc etc)...does anyone know where I can find this?

thanks

John


-- 
   Emporers Thought for the Day:                |       John E. Rudd jr.
Only the insane have the strength to prosper;   |  ccastjr@prism.gatech.edu
   Only those who prosper judge what is sane.   |  (ex- kzin@ucscb.ucsc.edu)
#include<std.disclaim>  Send all comments, flames, and complaints to /dev/null.
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 1990 05:20:06 PDT
From:      Elayne_McFaul.Wbst128@xerox.com
To:        TCP-IP-Internet-NS.all_areas@Xerox.com, TCP-IP-NS.all_areas@Xerox.com, tcp-ip@nic.ddn.MIL
Cc:        McFaul.WBST128@Xerox.com
Subject:   Protocol specification for Unix rcp
Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility?

Elayne McFaul
Xerox Corporation
mcfaul.wbst128@xerox.com
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 00:49:07 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is SNMP
In article <2396@mtecv2.mty.itesm.mx> gcavazos@vmtecmex.cem.itesm.mx (Gustavo Cavazos) writes:
>What is SNMP? 
>Here we have a Fastpath IV, when I check the network, besides registering 
>as a Gateway it 
>registers itself as a SNMP.
>So what is SNMP?

Simple Network Management Protocol - for more info, get Marshall Rose's
book, "The Simple Book", Prentice Hall. ISBN # 0138126119.

-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 12:44:24 -0700
From:      bbrooks@salt.acc.com (Bill Brooks)
To:        tcp-ip@nic.ddn.mil
snmp@psi.com
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 12:46:49 -0700
From:      bbrooks@salt.acc.com (Bill Brooks)
To:        tcp-ip@nic.ddn.mil
plase add me to the mail list at bbrooks@salt.acc.com
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 09:04:13 -0400
From:      jcurran@SH.CS.NET
To:        Sharon Fisher <asylum!sharon@decwrl.dec.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SNMP network manager software for article
Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network
management tools.  It's not necessarily complete, but it's a good start..

/John
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 07:53 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        Sharon Fisher <asylum!sharon@decwrl.dec.com>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: Looking for SNMP network manager software for article
Datapro has compiled a list of SNMP management systems.  For information
on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill
Huntington-Lee.  Also, RFC 1147, available via anonymous FTP or email
from nic.ddn.mil, lists several SNMP packages.

- Bob Stine
  Applied Cybernetics, Inc.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 03:15:18 GMT
From:      faatcrl!warb@rutgers.edu  (Dan Warburton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: The network
ccastjr@prism.gatech.EDU (COOOooOoooooOOOOoOOoOOooKIE!!!!!) writes:




>     What is the cost of having access to the net (via your
>own machine)?

The Answer is: ........... it Depends!!!

It depends mostly on how close the nearest access point is to your computer
and what kind of computer you have and what you purpose for connection is and
and how much bandwitdh to the net you would like. Maybe a couple of examples
might clarify.

Ex. 1  Your network connection is a local machine across the room. Just 
       string some ethernet cable across the room. Get the SysAdm to 
       assign you a spare internet number and zoom! You are on the net.

Ex. 2 You don't have a campus connection and want a 56k baud connection.
      Start with about 25k in equipment costs, add line connect charges,
      annual rental of line (say 40 miles), add private network gateway cost
      you should end up with 30k startup plus 20k recurring. This IS just
      an example, your milage my vary.
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 11:20:14 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '91 Call for Papers

		    Call For Papers

		 ACM SIGCOMM '91 CONFERENCE
 Communications Applications, Architectures and Protocols

	    ETH Zurich, Zurich, Switzerland
   September 4-6, 1991 (Tutorials September 3, 1991)


The conference provides an international forum for the presentation
and discussion of communication network applications and
technologies, as well as recent advances and proposals on communication
architectures, protocols, algorithms, and performance
models. It is the first time that SIGCOMM will hold its conference
outside of the United States.

Authors are invited to submit full papers concerned with both
theory and practice. The areas of interest for the conference
include, but are not limited to the following: Analysis and
design of computer network architectures and algorithms, innovative
results in local area networks, computer-supported cooperative work,
network interconnection and mixed-media networks,
high-speed networks, resource sharing in distributed systems,
network management, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should
have an abstract of 100-150 words. All submitted papers will be
reviewed and will be judged with respect to their quality and
relevance. Authors of accepted papers will be expected to sign an
ACM copyright release form. The Proceedings will be distributed
at the conference and published as a special issue of ACM SIGCOMM
Computer Communication Review. Notable papers will be considered
for publication in ACM Transactions on Computer Systems.

Submit 5 copies of each paper to the program chairman (or in the
US, the US program committee contact):

Prof. Bernhard Plattner
Technische Informatik und Kommunikationsnetze  Telephone: +41 1 254 7000
ETH-Zentrum (IFW)                Fax: +41 1 262 3973
8092 Zurich, Switzerland
EMAIL: <plattner@komsys.tik.ethz.ch> or
<C=ch; ADMD=arcom; PRMD=switch; O=ethz; ou1=tik; ou2=komsys; s=plattner>


The US program committee contact is:

Greg Wetzel
AT&T Bell Laboratories           Telephone: +1 (708) 979-4782
M/S IH 1B-213               Fax: +1 (708) 979-2350
2000 N. Naperville Road          E-Mail: g_f_wetzel@att.com
Naperville, IL 60566

For more  information  about  the  conference,  e-mail  to
sicomm91@nri.reston.va.us

Special session: Applications of High Speed Networks

One or more sessions of the conference will be devoted to the
subject of applications of high speed networks. Papers in these
sessions will focus on concepts, implementation and experience of
applications that need the performance that future high speed
networks will offer. Topics include, but are not limited to new
approaches to computer-supported cooperative work, graphic visualization,
and access to supercomputers. Papers submitted for
these topics should address applications and their communications
requirements.

Student Paper Award

Papers submitted by students will enter a student-paper award
contest. Among the accepted papers, a maximum of four outstanding
papers will be awarded (1) full conference registration and (2) a
travel grant of $500 US dollars. To be eligible the student must
be the sole author or a primary contributor to the paper.

IMPORTANT DATES


Deadline for paper submission:  March 2, 1991.
Notification of acceptance:   April 30, 1991.
Camera ready papers due:     May 31, 1991.
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 05:49:02 GMT
From:      encore!zelig!jdarcy@husc6.harvard.edu  (Floating Exception)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
apple.com!erekose@apple.com  (Erik Scheelke):
>	Does anyone know of a reliable connectionless datagram protocol that
>	runs on top of UDP?  Is so, is there a library out there I can get?

postel@VENERA.ISI.EDU writes:
>Hi.
>
>"Reliable Datagram" is an oxymoron.

Very funny.  Really.  I would guess, however, that Erik is referring to a
connectionless protocol that preserves message boundaries and guarantees
delivery but not necessarily sequencing or non-duplication.  I'm sure such
beasts exist somewhere.

--

Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com
      Nothing was ever achieved by accepting reality
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 12:45:14 -0400
From:      ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!)
To:        WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  The network
well, there was a horizontal line and off from that broke the basic
networks (.com .mil .gov etc) in vertical directions (some up, some
down).  Each "T" in the network was a further sub net (so, when
the .edu broke off the base line, there were further breakoffs
to .gatech and .mit and .berkeley etc)

I think they put commercial orgs on .com even if they had an additional
 .mil address..  it wasn't meant to be a geographic map (from what I saw)
but a network topology map.

hope that explains it..if I find a copy, I'll send it to you.

John

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 11:35:26 EDT
From:      kate@tecnet1.jcte.jcs.mil
To:        tcp-ip@nic.ddn.mil
Subject:   route needed
I am trying to send a message to the UK. The address is:
user@company.co.uk
I know it is a valid address over there but my DOD machine doesn't know how
to get it there. I was wondering if there is a static route I could type
that will get it over there?
Thanks
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 20:46:14 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        dab@berserkly.cray.com, elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com, mcc@WLV.IMSD.CONTEL.COM, tcp-ip@nic.ddn.mil
Subject:   Re:  Use of TCP/IP with satellite delays
David:

As the author you well know that a valid TELNET line mode didn't exist until
you did the necessary work.  4.3 BSD always devolves to an equivalent of an
rlogin connection with single character frames.  There are toooo many products
for other platforms that  don't really support all TELNET options and in fact
don't work when faced with a system that doesn't devolve to the 4.3 BSD default.

Now that you've completed a legitimate line mode are you going to implement a
valid NVDET option?

Merton
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Oct 90 21:19:08 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        WLV.IMSD.CONTEL.COM!mcc@gatech.edu, ccastjr@prism.gatech.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  The network
John:

I like your statements--they follow the party line.  Let me insert a little
reality before you send any maps--actually send the maps, I would like to
take a look at this make believe world.

The point of my interest was that the networks never devolved in the conceptual
outlines that were anticipated years earlier.  There is no *.org, *.gov, *.edu,
or *.com networks.  There is an *.mil network but it incorporates all of the
preceding "classes" of users.  There are regional networks that incorporate
these "classes" of users.  There are no networks, to my knowledge, that are
composed of a single "class" of user.

For example, *.contel.com is a member of several networks.  The membership
is partly historical, it is partly a matter of emphasis, and it is partly
a matter of entry and sponsorship in the ARPA and MILNET domains.  Actually,
one might want to consider the role of acquisition in network membership.
The domain *.imsd.contel.com is a MILNET member, all other *.contel.com domains
are members of SURAnet.

Another example is the *.radc.af.mil domain.  The tops20.radc.af.mil system
is part of NYSERnet.  The lonex.radc.af.mil and subsidiary systems are strictly
a part of MILNET.  One can access the *.radc.af.mil domain either through
NYSERnet or MILNET.

Merton

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 12:20:06 GMT
From:      Elayne_McFaul.Wbst128@xerox.com
To:        comp.protocols.tcp-ip
Subject:   Protocol specification for Unix rcp

Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility?

Elayne McFaul
Xerox Corporation
mcfaul.wbst128@xerox.com

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 12:53:00 GMT
From:      0004219666@mcimail.com (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP network manager software for article

Datapro has compiled a list of SNMP management systems.  For information
on getting their list, dial 1-800-DATAPRO, and ask to speak with Jill
Huntington-Lee.  Also, RFC 1147, available via anonymous FTP or email
from nic.ddn.mil, lists several SNMP packages.

- Bob Stine
  Applied Cybernetics, Inc.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 13:04:13 GMT
From:      jcurran@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP network manager software for article

Refer to RFC 1147 (Network Management Tool Catalog) as it lists several SNMP network
management tools.  It's not necessarily complete, but it's a good start..

/John

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 15:20:14 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '91 Call for Papers


		    Call For Papers

		 ACM SIGCOMM '91 CONFERENCE
 Communications Applications, Architectures and Protocols

	    ETH Zurich, Zurich, Switzerland
   September 4-6, 1991 (Tutorials September 3, 1991)


The conference provides an international forum for the presentation
and discussion of communication network applications and
technologies, as well as recent advances and proposals on communication
architectures, protocols, algorithms, and performance
models. It is the first time that SIGCOMM will hold its conference
outside of the United States.

Authors are invited to submit full papers concerned with both
theory and practice. The areas of interest for the conference
include, but are not limited to the following: Analysis and
design of computer network architectures and algorithms, innovative
results in local area networks, computer-supported cooperative work,
network interconnection and mixed-media networks,
high-speed networks, resource sharing in distributed systems,
network management, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced pages long and should
have an abstract of 100-150 words. All submitted papers will be
reviewed and will be judged with respect to their quality and
relevance. Authors of accepted papers will be expected to sign an
ACM copyright release form. The Proceedings will be distributed
at the conference and published as a special issue of ACM SIGCOMM
Computer Communication Review. Notable papers will be considered
for publication in ACM Transactions on Computer Systems.

Submit 5 copies of each paper to the program chairman (or in the
US, the US program committee contact):

Prof. Bernhard Plattner
Technische Informatik und Kommunikationsnetze  Telephone: +41 1 254 7000
ETH-Zentrum (IFW)                Fax: +41 1 262 3973
8092 Zurich, Switzerland
EMAIL: <plattner@komsys.tik.ethz.ch> or
<C=ch; ADMD=arcom; PRMD=switch; O=ethz; ou1=tik; ou2=komsys; s=plattner>


The US program committee contact is:

Greg Wetzel
AT&T Bell Laboratories           Telephone: +1 (708) 979-4782
M/S IH 1B-213               Fax: +1 (708) 979-2350
2000 N. Naperville Road          E-Mail: g_f_wetzel@att.com
Naperville, IL 60566

For more  information  about  the  conference,  e-mail  to
sicomm91@nri.reston.va.us

Special session: Applications of High Speed Networks

One or more sessions of the conference will be devoted to the
subject of applications of high speed networks. Papers in these
sessions will focus on concepts, implementation and experience of
applications that need the performance that future high speed
networks will offer. Topics include, but are not limited to new
approaches to computer-supported cooperative work, graphic visualization,
and access to supercomputers. Papers submitted for
these topics should address applications and their communications
requirements.

Student Paper Award

Papers submitted by students will enter a student-paper award
contest. Among the accepted papers, a maximum of four outstanding
papers will be awarded (1) full conference registration and (2) a
travel grant of $500 US dollars. To be eligible the student must
be the sole author or a primary contributor to the paper.

IMPORTANT DATES


Deadline for paper submission:  March 2, 1991.
Notification of acceptance:   April 30, 1991.
Camera ready papers due:     May 31, 1991.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 15:45:25 GMT
From:      asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for users who run SNMP in their bridges & routers
I've also gotten an assignment from Datamation to write about the use
of SNMP in bridges and routers.  I am looking for users in this area.
If you're a user, or if you're a vendor who can provide users I can
talk to, please let me know.  Thanks!
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 16:31:37 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reply to Re: Ethernet Address Uniqueness...
In article <9010092346.AA29384@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes:
> This is a standard gotcha of using protocols that change the address.
> There is no solution other than to make sure that DECNet is always
> started before anything else that cares about the Ethernet address.
 
This is getting a bit far afield from tcp-ip, but the above is not quite true.
By setting the SYSGEN value for SCSSYSTEMID to the value ((DECnet area*1024) +
node), the order in which products are started in no longer significant as the
MAC address of the Ethernet cards is rewritten before any layered software is
run. 48.168 would yield an SCSSYSTEMID of 49320, (48*1024)+168.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 16:34:28 GMT
From:      mcsun!i2unix!alessia!athena@uunet.uu.net  (Matteo Frigo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Strange bahaviour of an LSX3020 with tcp protocol

	[ I reply to myself :-) ]

	I have been able to solve the problem, and as it is a bug
of of X/OS 2.2 I post the solution .

	The problem was in the incorrect TTL (time to live of tcp packets)
which was set to 15, while the sun had 30. The constant TCP_TTL
is defined in netinet/tcp_timer.h. My kernel was compiled with
this low value, which inhibits tcp connections which far hosts.

	As I have not access to Olivetti kernel's sources,  I
made a patch directly on /usr/mixos/kernel/tcpip/libtcp_ip.a,
using as guide the tcp sources from BSD4.3 . The constant is used
in two object modules.

	I believe this is a problem of all LSX machines with X/OS 2.2
and I can give details on patching the kernel to anyone who
is interested in. I would also thank all the people who gave
me suggestions after my news.

Matteo Frigo
athena@alessia.dei.unipd.it (it works now !)
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 20:54:54 GMT
From:      wuarchive!emory!hubcap!mmccann@eddie.mit.edu  (Mike McCann)
To:        tcp-ip@nic.ddn.mil
Subject:   Need phone numbers...
I am interested in subnetting several building off our Ethernet backbone
(passing TCP-IP, DECnet and AppleTalk packets) to cut down on the amount
of backbone traffic and inefficient IP number usage.  Anyone have phone
numbers for networking companies (such as Proteon or Sysco)?  I also
want these routers to be managed by SNMP.  Any suggestions?

Thanks in advance for your help,

-- 
Mike McCann       (803) 656-2721   Internet = mmccann@hubcap.clemson.edu 
Engineering Computer Operations      Bitnet = mmccann@clemson.bitnet
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 21:30:00 GMT
From:      snorkelwacker!mintaka!spdcc!ima!mirror!frog!tdh@apple.com  (T. Dave Hudson)
To:        tcp-ip@nic.ddn.mil
Subject:   single tcpcb loopback bug
This seems to be a previously unpublished bug.
(Do 4.3BSD TCP/IP bugs belong in comp.bugs.4bsd.ucb-fixes instead?)

We are using the following base revisions of 4.3BSD TCP/IP source
modules:
	@(#)tcp_input.c	7.15.1.3 (Berkeley) 2/15/89
	@(#)tcp_output.c	7.13.1.4 (Berkeley) 2/15/89

When a user program (which I did not write) does
	1) socket(PF_INET, SOCK_STREAM, 0)
	2) bind() {PF_INET, port=3000, INADDR_ANY}
	3) connect() {PF_INET, port=3000, local host's IP address}
the kernel goes into an infinite "loop" (dump indicates many ACKs but
little data in tcpstats) presumably scheduling SYN/ACK (and possibly
something else; dump only showed last message) messages to and from
presumably the same tcpcb.  The tcpcb is in SYN SENT state, with
tcp_output() called from the dropafterack section of tcp_input(), and
with tcp_output() having successfully sent a message, contents unknown
except that the last freed mbuf, appropriately, is SYN/ACK with both
ports equal to 3000 and using the local node's Ethernet interface's IP
address.  The SYN/ACK message contains an ISN that disagrees (having
been incremented) with the tcpcb's idea of it, but an acknowledgement
number that (matching the SYN/ACK's ISN, properly incremented from
the tcpcb's ISN) is OK.

I suspect that a workable fix is to use the tcpcb's ISN when sending
any SYN, although I haven't tried this yet.  However, the failure to
do this ought to have generated a RST, IMHO, so I guess there are
actually two bugs here.

Has anyone already worked out a fix for this?  (I will summarize
responses received by email.  My guess is that it will be another
month or two before I can spend time working out a fix myself.)

				David Hudson
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 90 21:39:43 GMT
From:      sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU  (Chris Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols
> postel@VENERA.ISI.EDU sez:
>
> "Reliable Datagram" is an oxymoron.
>
> --jon.

Perhaps reliable datagram using UDP is an oxymoron, depending on the
transport layer.

However XTP datagrams *are* reliable.  Mail to xtp-request@pei.com
for information or a XTP spec.

					Chris Johnson
					cjohnson@pei.com
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 01:41:59 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: File Broadcast
In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes:
+---------------
| We have a local area network of UNIX based PCs running TCP-IP, and I
| was asked if there was any software that will broadcast a file to all
| machines on the network.  I didn't know of any and was wondering if
| anyone out there in netland knew of any.  If not, I guess I will have
| to write something myself.  I would appreciate any infomation about
| programs or algorithms that do file broadcasting.  It must use a broadcast,
| not a copy to one machine then copy to another method (i.e. UDP), and
| if a machine is up it must reliably send the file.
+---------------

Using the multicast features of the XTP protocol, you could do what you
want with something like the following:

        for i in $MACHINELIST
        do
		# start each receiver listening
                rsh $i 'txtp -r -s -M | tar xf - &'
        done
	# now multicast the file
        txtp -t -s -M <src_file

"Txtp" is an XTP-ized version of "ttcp", the common TCP test program.

Of course, you need XTP support on each machine...   ;-}


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 10:33:48 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        news!german@iuvax.cs.indiana.edu  (Chad W. German)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA TELNET / BANYAN
VINES doesn't use packet drivers.  Instead, they have a hardware device
sharing interface built into VINES.  We offer a version of PC/TCP which
talks to it, and gives the functionality you want.  I don't know if any
of the freeware developers have ever considered doing drivers for this.

I have heard rumors of VINES which can use NDIS, and if you could get
it, this could be combined with the NDIS-Packet Driver adapter to use
freeware.  If this is in fact a feature of their 4.0 release, I have
been told it will be available sometime this winter.

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

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 08:23 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        Merton Campbell Crockett <mcc@wlv.imsd.contel.com>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re:  The network
>The point of my interest was that the networks never devolved in the conceptual
>outlines that were anticipated years earlier.  There is no *.org, *.gov, *.edu,
>or *.com networks...  There is an *.mil network but it incorporates all of the
>preceding "classes" of users.  There are regional networks that incorporate
>these "classes" of users.  There are no networks, to my knowledge, that are
>composed of a single "class" of user.

My understanding on this issue (such as it is :-)  ) is that the name space
is independent from the actual network topology.  E.g., having an "edu"
domain does _NOT_ mean that one should expect to find an education net.

If this thread goes much further, it would probably be more appropriate for
name-droppers.

Bob Stine
Applied Cybernetics, Inc.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Wed 17 Oct 90 13:24:19-PDT
From:      VANCE@TGV.COM (Icarus)
To:        marge%masbull.my.bull.fr@TGV.COM
Cc:        tcp-ip@nic.ddn.mil
>Does anyone know of a product that supports DOS diskless station on
>TCP/IP with UNIX server using TFTP and BOOTP.

I know of two.  Try:

	Beame & Whiteside	(416) 648-6556
	FTP Software		(617) 246-0900

Regards,
-----Stuart
-------
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 12:14:58 CDT
From:      mailing list <tcpip@server.af.mil>
To:        mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  The network
> The point of my interest was that the networks never devolved in the conceptual
> outlines that were anticipated years earlier.  There is no *.org, *.gov, *.edu,
> or *.com networks.  There is an *.mil network but it incorporates all of the
> preceding "classes" of users.  There are regional networks that incorporate
> these "classes" of users.  There are no networks, to my knowledge, that are
> composed of a single "class" of user.
>
Yes, even the milnet has its non-military users.
 
I guess what I wanted to say, is that the map that John is referring to is
a map of the Domains of the internet.  I remember seeing it once, and it
is strictly a break-out of all the domains registered with the SRI-NIC...

I don't know that that means you can get it from the NIC, however.  I am
sure that I did not get it from the NIC myself.  I also remember that I got
this "map" early this year, and it hadn't been revised since 88.  If 
anyone does run across a really current one, I'd be interested in seeing
how well it reflects our af.mil reality (:->

/matt

jonson@server.af.mil
I speak not for my organization.

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 09:17:23 GMT
From:      mcsun!hp4nl!dnlunx!dnlts!icp@uunet.uu.net  (R. Sonneveld, ICP, NAD, ICP@HLSDNL5.BITnet, +31 70 435362)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ISO Country codes
In article <9010121643.AA28145@ucbvax.Berkeley.EDU>, 
   Z00EJR01%AWIUNI11@PUCC.PRINCETON.EDU (Ewald Jenisch) writes:

> Does anybody out there in the netland know where I can find a listing
> of all ISO Country Codes. As far as I remember there was such a list
> hanging around for anonymous FTP but I don't remember which server.

Try your nearest NETSERV, for the file: COUNTRY ISOCODES. 

Rolf Sonneveld
PTT Research
The Netherlands
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 09:23:07 +0100
From:      Denis.Russell@newcastle.ac.uk
To:        kate@tecnet1.jcte.jcs.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: route needed
Re:
 
> I am trying to send a message to the UK. The address is:
> user@company.co.uk
> I know it is a valid address over there but my DOD machine doesn't know how
> to get it there. I was wondering if there is a static route I could type
> that will get it over there?
> Thanks
 
Try routing it via nsfnet-relay.ac.uk, i.e. try either
 
      user%company.co.uk@nsfnet-relay.ac.uk
 
 or
 
      user%uk.co.company@nsfnet-relay.ac.uk
 
(The  second  form  might  just  be  required  because  our mail
addresses are the other way round).
 
If  you  look at the trace of this message to you, you should be
able to see this gateway in the route.
 
                 Denis
 
Denis Russell           JANET:     Denis.Russell@uk.ac.newcastle
Computing Laboratory    Internet:  Denis.Russell@newcastle.ac.uk
The University
Claremont Road          Tel:   (+44) 91 222 8243
Newcastle upon Tyne     Fax:   (+44) 91 222 8232
       NE1 7RU          Telex: 53 65 4  UNINEW G
ENGLAND
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 16:06:00 EDT
From:      CHRISTOPHER TANNER <TANNERC@CRL.AECL.CA>
To:        tcp-ip@NIC.DDN.MIL
Subject:   WIN$LPD on VMS
Greetings
Using Wollongong's version of LPD on VMS, is it possible to specify parameters
for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an
lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system.

Thanks for your help

Chris Tanner
AECL Research
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 13:23:00 GMT
From:      0004219666@mcimail.com (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re:  The network

>The point of my interest was that the networks never devolved in the conceptual
>outlines that were anticipated years earlier.  There is no *.org, *.gov, *.edu,
>or *.com networks...  There is an *.mil network but it incorporates all of the
>preceding "classes" of users.  There are regional networks that incorporate
>these "classes" of users.  There are no networks, to my knowledge, that are
>composed of a single "class" of user.

My understanding on this issue (such as it is :-)  ) is that the name space
is independent from the actual network topology.  E.g., having an "edu"
domain does _NOT_ mean that one should expect to find an education net.

If this thread goes much further, it would probably be more appropriate for
name-droppers.

Bob Stine
Applied Cybernetics, Inc.

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 23:46:45 -0400
From:      cfm@sparta.com (Carl Muckenhirn)
To:        ccastjr@prism.gatech.edu (COOOooOoooooOOOOoOOoOOooKIE!!!!!)
Cc:        WLV.IMSD.CONTEL.COM!mcc@gatech.gatech.edu, tcp-ip@nic.ddn.mil
Subject:   Network Maps (was: The network)
the map you are refering to used to be available from the DDN NIC
(NIC.DDN.MIL).  It has nothing to do with network geography or
topology, but is a listing of the domains that are registered with the
NIC.  It was (is, it is probably still out there somewhere) basically
a tree with the "INTERNET" as the root node, .com, .mil, .gov, .org,
.us, .uk, ... as the first level descendents, .af.mil, .sparta.com,
.mitre.org, ... etc.  For the most part the tree is very shallow, but
some branches are fairly deep (mit.edu comes to mind).

This whole map is just a layout of administrative domains.  There are
a number (most?) of domains that consist of several "networks" (a
group of computers organized under a single network number).  There is
no reason that a domain (sparta.com for example) cannot be
geographically diverse (for example with a "network" in Washington,
D.C. and another in Baltimore, MD) but sharing the administrative and
naming structure provided by the DNS (all hosts on these networks have
hostnames of the form <something>.sparta.com (<something> maybe <foo> or
<foo>.<bar> or <foo>.<bar>.<foobar>..... [you get the picture]).

If you want a picture of the "network topology" you need to start
looking at the network addresses, find the gateways on those networks,
hook the gateway's different network addresses together, then go to
the next layer of networks and so on.  This should be doable (I've
been working on related pieces of this problem for the last 2 years
on and off) with the information in the NIC (and NSFNET NISC).  The
hard part comes when you try to display it, what is the point of
reference (if I start at the nsfnet the picture is much different
than if I start at a stub network), what symbology is appropriate (are
the connected networks lines, clouds, layers of an onion) and so on.
And once you've figured that out, someone will say, "But WHERE are
these things?" and you now have to get all the addresses for the
gateways, and now the pretty layered picture is a bowl of spaghetti.
(Are there any idle topologists out there?)

All this is to say, I doubt that there are any "network maps" out
there that show the entire internet.  There are some very good
geographic maps of some of the regional and educational nets (THENet
sticks in my mind) out there, but I think that all were manually done
(a Mac, some clip-art, a lot of time).  I can't remember right off where
they can be found, if anyone is interested drop me a line and I'll see
if I can dig it out.  

A few people here at Sparta have done a lot of thinking about how to
do automated generation of topographic and geographic network maps,
and we have some of the basics down but we are between contracts and
don't know if this work will continue (being a defense contractor is
the pits sometimes).  If anyone has any other insights on this topic
I'd be happy to hear from you.

carl.
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 17:06:48 GMT
From:      VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!cwns1!chet@tut.cis.ohio-state.edu  (Chet Ramey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Protocol specification for Unix rcp
>Where can I find a protocol specification for rcp, the 4.3BSD remote copy utility?

/usr/src/bin/rcp.c

:-)

Chet
-- 
Chet Ramey			``As I recall, Doug was keen on boxing.  But
Network Services Group		  when he learned to walk, he took up puttin'
Case Western Reserve University	  the boot in the groin.''
chet@ins.CWRU.Edu
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 17:16:10 GMT
From:      prism!ccastjr@gatech.edu  (COOOooOoooooOOOOoOOoOOooKIE!!!!!)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  The network

Sorry if my statements were misleading.  I know that the *.mil and *.edu\
don't denote a PHYSICAL network.. but a "logical" network..
The map is drawn along this "logical" network.

I understood this, but I guess that didn't come across.. sorry.

John

-- 
   Emporers Thought for the Day:                |       John E. Rudd jr.
Only the insane have the strength to prosper;   |  ccastjr@prism.gatech.edu
   Only those who prosper judge what is sane.   |  (ex- kzin@ucscb.ucsc.edu)
#include<std.disclaim>  Send all comments, flames, and complaints to /dev/null.
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 1990 0:48:32 PDT
From:      SRI Network Information Systems Center <nisc@nisc.sri.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Domain Survey Results
Network Information Systems Center                              October 1, 1990
SRI International                                                 Domain Survey

                            INTERNET DOMAIN SURVEY

The  Domain  Survey  statistics  are  compiled  by  ZONE,  the  Zealot  Of Name
Edification.  ZONE runs on a DEC-2065  mainframe  connected  to  the  Internet.
ZONE begins with a list of top-level domains and their associated name-servers.
For each domain, ZONE attempts to make a TCP connection to one  of  the  listed
name-servers.  Once connected, ZONE requests a dump (called a zone transfer) of
the domain being served.  ZONE collects information on host  names,  nicknames,
addresses,  mail  exchanger records (MX records) and name-server records.  If a
name-server record refers to a subdomain, then that subdomain is added  to  the
list  of  domains  that  ZONE searches.  In this way, ZONE descends through the
entire domain tree trying to find all existing domains.   ZONE  cycles  through
its  list  of  domains left to search until it has gone through the entire list
without receiving any new information.

When ZONE finishes, it dumps  out  a  table  of  all  the  information  it  has
collected  in  a  format similar to HOSTS.TXT.  ZONE also creates a file with a
list of all the domains it has found.  Sometimes a  domain  can't  be  searched
because the servers can't be reached, or because of administrative restrictions
that disallow zone transfers.

ZONE reports the total number of hosts and domains it has  found.    The  total
elapsed  and  cpu  time to run ZONE are also indicated in the statistics, along
with the size of the generated host table.  ZONE also keeps track of  how  many
different  IP addresses each individual host has assigned to it.  This table is
listed under "Number of Addresses per Host".  Hosts  with  zero  addresses  are
really just mail forwarding entries, usually to a host that is not connected to
the Internet.  Many of these entries are wildcards for entire domains that  are
not on the Internet.

A  search  of  a few popular keywords (names of machines and operating systems)
was done on the resulting host table.  The results are listed  in  the  section
"String Searches on Host Table".  No attempt was made to make sure one of these
strings wasn't just a substring of a larger (possibly unrelated) string.

The first component of each domain name was stripped off and a  list  of  'host
names' was generated.  The top 72 most popular host names are listed along with
the number of occurrences of each.


                             DOMAIN SURVEY RESULTS

                                  Statistics

                    Hosts:                        313,000    [minimum]
                    Domains:                      9300       [approximately]
                    Total elapsed time:           5 days
                    Total cpu time:               4.5 hours
                    Host table generated:         25 megabytes


                  Number of Addresses per Host

                    Addresses           Hosts
                    0                   22964     [MX-only entries]
                    1                  306516
                    2                    4929
                    3                     626
                    4                     328
                    5                     148
                    6                     135
                    7                      63
                    8                      43
                    9                      20
                    10                     13


                  String Searches on Host Table

                    pc                  46600
                    unix                38700
                    sun                 37700
                    mac                 28400
                    hp.com              24500
                    ibm                 20700
                    vax                 14300
                    vms                  5900
                    tops-20                30


                        Top 72 Most Popular Host Names

171 mars     108 gauss    93 earth     83 hermes    74 europa    68 polaris
169 venus    107 opus     93 athena    82 moe       74 bach      68 odin
168 pluto    107 newton   90 larry     81 sneezy    73 uranus    67 sparky
147 jupiter  104 grumpy   89 titan     81 mozart    71 math      67 maxwell
138 zeus     103 sirius   89 sleepy    81 gandalf   71 falcon    66 pc2
138 mercury  103 gw       89 fred      80 vega      71 alpha     66 bashful
134 iris     100 merlin   87 doc       80 mickey    70 spock     66 altair
133 cs         97 eagle   85 dopey     80 astro     70 pollux    65 ra
130 orion      97 calvin  84 rigel     79 happy     70 pegasus   65 curly
125 saturn     96 thor    84 phoenix   79 cisco     70 hydra     65 castor
123 neptune    96 sol     84 io        78 helios    70 frodo     64 max
117 hobbes     96 apollo  83 snoopy    75 hal       69 euler     64 gemini
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 19:40:59 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  The network
In article <9010171715.AA01958@server.af.mil>, tcpip@server.af.mil (mailing list) writes:
> 
> I don't know that that means you can get it from the NIC, however.  I am
> sure that I did not get it from the NIC myself.  I also remember that I got
> this "map" early this year, and it hadn't been revised since 88.  If 
> anyone does run across a really current one, I'd be interested in seeing
> how well it reflects our af.mil reality (:->

The file (in PostScript) is available from nic.ddn.mil. It is
netinfo:domain-chart.ps. It has not been updated since it was created in Sept.
1988. It is quite large and prints about 20 pages as I recall.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 19:45:21 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   Can One API Support Both TCP/IP and LU 6.2?
Do TCP/IP and and IBM's LU 6.2 share enough in common as
peer-to-peer protocols that it would be possible to build a single
API on top of both?  I have heard some discussion that IBM's
Common Programming Interface - Communications (CPI-C) might evolve
into such an approach.  Obviously one impediment to a common API
is that the two protocols use different naming systems, but
assuming you could bridge that difference are the protocols - as
protocols only - semantically and syntactically similar enough
that one could build a generic model that bridges the two?

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Oct 90 18:30:08 +0100
From:      marge@masbull.my.bull.fr (Alain Margeride)
To:        tcp-ip@nic.ddn.mil
Does anyone know of a product that supports DOS diskless station on
TCP/IP with UNIX server using TFTP and BOOTP.

Alain MARGERIDE
BULL
email:    margeride@my.bull.fr
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 22:24:50 GMT
From:      bionet!synoptics!sblair@apple.com  (Steven Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:
I've tried to respond to the poster, but was unsuccessful.

Here's another:

Espirit  Systems Inc. (408)954-9900

I used to have a friend there, but he quit. Never used their
product(s), but know that they're diskless PC's....

--
Steven C. Blair		Network Operations Center
SynOptics Communications Inc. Mountain View, California
INTERNET: sblair@synoptics.com  sblair@excalibur.synoptics.com
PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com
---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<----
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 90 23:15:07 GMT
From:      palter@cs.Buffalo.EDU (Bill Palter)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: WIN$LPD on VMS


In article <1AAD8E9AD8BF401F39@CRL.AECL.CA>, TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) writes:
> Greetings
> Using Wollongong's version of LPD on VMS, is it possible to specify parameters
> for the VMS PRINT commands such as /FLAG and /FORM=xxx? I would like an
> lpr -Pxx (on UNIX) to become PRINT /Q=xx/FLAG/FORM=yy on the VMS system.


	Yes it is, for some reason the text of the /FORM qualifier  was omitted
from the documentation. In your printcap entry for the printer just specify
/FORM=formname. /FLAG is more difficult, since it is basicly useless due to the fact that the filename that would be displayed on it is the name of the spool file and not that of the file  that was printed. But if you want it you 
could take the sample USRJBC procedure from the manual and change the
text of the USRJBC_OPEN routine to be:

	jbc_info.flags |= LPDSMB_M_FILE_FLAG;

This with change the attributes of the print job to /FLAG when it is created 
in the VMS print queue.


Bill Palter 
The Wollongong Group
palter@twg.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 00:25:01 GMT
From:      ubc-cs!van-bc!mdivax1!zintel@beaver.cs.washington.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Redirecting console IO
I am developing software on a SPARC for a Motorola delta 3400 System V box.
Both boxes are on an ethernet. I am using rsh and rlogin to copy files and
run tests. I would like to be able to access the console (hardware port 0) of
the delta box in a window under sun-os.

Any hints would be greatly appreciated.
-- 
Mike Zintel                                       It is wiser to be kind
                                                    than to be wise.
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 00:35:10 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA TELNET / BANYAN
In article <9010171533.AA22340@ftp.com> jbvb@ftp.com writes:
>I have heard rumors of VINES which can use NDIS, and if you could get
>it, this could be combined with the NDIS-Packet Driver adapter to use
>freeware.  If this is in fact a feature of their 4.0 release, I have
>been told it will be available sometime this winter.
>

The multi-protocol NDIS interface for Vines 4.0 is available from Banyan
N/C - it's patch # 1W. James' NDIS-Packet driver adapter works with Vines
4.0 P1W and cutcp or ka9q.

-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 10:14:09 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil, ietf@isi.edu
Subject:   SIGCOMM '90 materials

Hi folks:
    
    I'm getting queries about the SIGCOMM '90 proceedings and hope this note
will help reduce the flow.

    If you are a member of ACM SIGCOMM, you should receive the proceedings in
the mail any day now.  If you are not a member of ACM SIGCOMM you can order
a copy of the proceedings from the ACM Order Dept at 1-800-342-6626.  The
item number is 533900.

    Also, yes there are some extra copies of the notes for the tutorial on
high speed networking given by Van Jacobson and Harry Rudin.  CNRI is
processing orders -- send a note to Lisa Duncan (lduncan@nri.reston.va.us)
for pricing and shipping info.

Craig

PS: Unfortunately, we're out of T-shirts... :-)
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 8:36:28 CDT
From:      wmarko@ub.d.umn.edu (William J. Marko)
To:        tcp-ip@nic.ddn.mil (tcp-ip group)
Subject:   please use the d key
please excuse...just a test
-- 
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 09:30:43 EDT
From:      glenn@sirius.econ.uga.edu (Glenn F. Leavell)
To:        TCP-IP%NIC.DDN.MIL@uga.cc.uga.edu
Subject:   Re:  Domain Survey Results
Thanks!  That's interesting.  I see that 'rigel' is the 33rd most popular
host name.  You can't beat the originality.

--Glenn
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 12:39:22 -0400
From:      Steven_Carmody@brown.edu
To:        TCP-IP@NIC.DDN.MIL
Subject:   SNMP monitors
WeUre in the process of looking at SNMP based monitors, and expect to use
one to monitor gateways and services in the campus network. ThereUs a
discussion starting in this digest which seems headed toward developing a
RscorecardS comparing many of the currently available products. I think
everyone will benefit if the community creates a such a yardstick. However,
in an interest in getting our site moving, and at the great risk of
oversimplification, IUd like to get a sense of whatUs out there. So far, I
can see three groups of products: 1) the PC-based monitors (wollongong, the
recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a
large number of commercially available, UNIX based monitors (often from
router vendors). IUve separated 2 and 3 because the NyserNet package is
available to universities for approximately 1/10 the cost of the packages
in category 3.


The question is -- are there any generalizations which can be made about
each of the categories? can the PC-based packages handle a large campus
sized network? are there major problems with the NyserNet monitor that the
packages in category 3 have corrected? Any info and experiences would be
appreciated.
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 October 1990 1322-PDT (Thursday)
From:      stanonik@nprdc.navy.mil (Ron Stanonik)
To:        tcp-ip@nic.ddn.mil
Subject:   4.3bsd/watching icmp traffic
We've modified a copy of 4.3bsd ping to just watch icmps
received; ie, not ping, just watch.  We've got it running
on our gateway, a vax running 4.3bsd.  We'd also like to
see icmps being forwarded through the vax.  Any suggestions?
Maybe using some socket type other than SOCK_RAW?  Or maybe
4.3bsd just doesn't give applications a chance to get their
hands on packets being forwarded?

Thanks,

Ron Stanonik
stanonik@nprdc.navy.mil

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 09:55:50 GMT
From:      psuvm!barilvm!p88036@psuvax1.cs.psu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   station name
Hi, here is my question:

Is there a way to get the name of the station I actually logged in from,
( this can be an X terminal or another workstation) so that I could direct
Xwindows output to this screen in some automatic way ?

Any information will be appriciated.
                      Ephraim.
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 10:46:19 GMT
From:      mcsun!ub4b!dg13!pnoe@uunet.uu.net  (Pierre Noel)
To:        tcp-ip@nic.ddn.mil
Subject:   Enormous difference of speed between PC/TCP and PCNFS

Hi NetLand, 

I made a program using socket protocols under TCP/IP Ethernet, to communicate
with a Unix Server (in that case, SCO-ODT Unix on a Olivetti's XP9 with a 
3COM's 3C503 Ethernet Card), I also made the Server part of the protocol then
I can control both sides of the problem.

My problem seems to be in the client side of the program : due to our site 
configuration, I gave two versions of the product, one for PC/TCP (Release 2.04)
and the other for PC-NFS (Release 3.01). The main purpose of the application is
to download lot of files (2/3 Mbytes each time) from the Server to the Client
requesting them; the download is segmented, at the socket level, in records of
1024 bytes each, using the send() and recv() function calls. The sources of 
the PC/TCP and PC-NFS application are excactly the same, only the libraries 
linked to are different. I made test on the same machine (Olivetti M300 with
a 3COM 3C501 Ethernet Card), the result is absolutely uncomprehensible : 
the relation between the time spent by the PC/TCP and the PC-NFS application is
about 1 to 10 !!!

I've checked where was the problem and what I've seen is that the difference of performance is located in the time spent between reception of records.
I've also encountered the same kind of problem with PC-NFS when trying to rcp
multiple small file one after another : the 2 firsts were transmitted ok but theother ones had also big delay.

My question is : do someone has knowledge of similar problem and do you know if
it is possible to tune the product to have acceptable performance ?

I know that the solution is maybe changing all our PC-NFS to PC/TCP but as our
park is about 700 PCs and our needs for the application are really urgent, it
must not be the right solution now.

I would be very happy to receive clues.

Thank you for your attention and apologies for spelling mistakes


						Pierre Noel
						pnoe@dg13.cec.be
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 19:27:18 PDT
From:      David Doll <davidd@hitl.vrnet.washington.edu>
To:        craig@nnsc.nsf.net
Cc:        tcp-ip@nic.ddn.mil, ietf@isi.edu
Subject:   SIGCOMM '90 materials
So can you let us know when there are more t-shirts? :)

David Doll
Programmer/Analyst
Human Interface Technology Lab
FU - 20
Seattle, WA 98195 
(206) 543-5075
davidd@hitl.vrnet.washington.edu
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 12:53:29 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   load sharing telnet/rlogin/route to mainframe


we have a mainframe with a lot of timesharers who rlogin/telnet
from workstations - the mainframe ethernet i/f is a bit slow
so we've put several on the machine...

can we set up clients so that they pick which i/f to route to
uniform random, or even deterministically - we dont want
users to know and we dont want to hack rlogin (we've done
this before the other way round to loadsare users round a lot
of workstations)...

could we magic it up by setting a route metric differently
for each of the masionframes i/f IP addressses in different
clients perhaps? (routing seems the natural place to add
loadsharing) but remembering they are all on same net & even
subnet...(i.e. add a host route for each i/f/?)?

what have other people done (and no humerous remarks about
buy a different mainframe or get different i/fs we didnt
really have a choice:-)  ?

thanks

jon 

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 13:40:55 GMT
From:      shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com  (Paul Ciarfella)
To:        tcp-ip@nic.ddn.mil
Subject:   Does ICMP optional data include IP header + options?

  Does the Internet header + 64 bits of data copied into the data field
  of an ICMP error message include the options from the original IP
  packet (if present), ie.,

	data = IP header + options + 64 bits of data 
		or
	data = IP header + 64 bits of data

  Thanks,

  Paul C

  ---------------------------------------------------------------------------
    Paul Ciarfella        Digital Equipment Corporation      Littleton, MA
  ---------------------------------------------------------------------------
  Disclaimer : My opinions are my own.   |  When in doubt, mumble.
  Address    : ciarfella@shug.enet.dec.com  
  ---------------------------------------------------------------------------
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 14:44:20 GMT
From:      princeton.edu!tengi@princeton.edu  (Christopher Tengi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: in-addr.arpa used?
If you are going to get them to implement in-addr.arpa on your local nameserver, don't forget to have them get authority delegeted to them from the NIC.  ie Princeton has authority for Princeton.EDU and 112.128.in-addr.arpa.

					/Chris
-- 

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Oct 90 13:53:29 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   load sharing telnet/rlogin/route to mainframe

we have a mainframe with a lot of timesharers who rlogin/telnet
from workstations - the mainframe ethernet i/f is a bit slow
so we've put several on the machine...

can we set up clients so that they pick which i/f to route to
uniform random, or even deterministically - we dont want
users to know and we dont want to hack rlogin (we've done
this before the other way round to loadsare users round a lot
of workstations)...

could we magic it up by setting a route metric differently
for each of the masionframes i/f IP addressses in different
clients perhaps? (routing seems the natural place to add
loadsharing) but remembering they are all on same net & even
subnet...(i.e. add a host route for each i/f/?)?

what have other people done (and no humerous remarks about
buy a different mainframe or get different i/fs we didnt
really have a choice:-)  ?

thanks

jon 
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 16:21:50 GMT
From:      hpda!hpcuhb!hpindda!subbu@ucbvax.Berkeley.EDU  (MCV Subramaniam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: single tcpcb loopback bug
>This seems to be a previously unpublished bug.

	Yes, it is unpublished, but not unreported. We, at HP have found this
	bug in 4.3 BSD, and have submitted a fix to Mike Karels. 

	You may not believe it, but 4.3 BSD cannot handle crossing SYNs!
	(i.e. if two 4.3 machines send SYN to each other and they cross each 
	other, the machines will go in an infinite loop sending SYN|ACKs
	to each other). Connecting to the same port number causes a similar
	situation to happen. 

	You send a SYN and go into SYN_SENT state, and you receive the SYN
	while in SYN_SENT state!

	The fix involves handling a SYN correctly while in the SYN_SENT state.

>I suspect that a workable fix is to use the tcpcb's ISN when sending
>any SYN, although I haven't tried this yet.  However, the failure to
>do this ought to have generated a RST, IMHO, so I guess there are
>actually two bugs here.

The ISN is already used while sending a SYN.

-Subbu
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 16:42:00 GMT
From:      csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   question about SMTP MX records
I am trying to send a message to someone@applelink.apple.com.  This
host has no TYPE A record, only an MX record.  My mailer currently
cannot resolve MX records.  As a workaround, I thought I would just
send to someone%applelink.apple.com@apple.com.  It is my (limited) 
understanding that addresses are parsed from right to left, so this
message would be sent to apple.com, who would then be able to forward
it to applelink.apple.com.

Some questions:
1) is the syntax of the address I am trying to use valid?
2) am I violating any network rules by routing my message through
another host?
3) should this message be getting delivered?  
I have sent several test messages that have disappeared into a black hole...

Thanks in advance for any help you can provide!

Robin Goldstone, Systems Software Specialist
California State University, Chico Computing Services
robin@csuchico.edu
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 18:52:49 GMT
From:      cunixf.cc.columbia.edu!cs.columbia.edu!ji@rutgers.edu  (John Ioannidis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: File Broadcast
>In article <45509@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes:
>
> We have a local area network of UNIX based PCs running TCP-IP, and I
> was asked if there was any software that will broadcast a file to all
> machines on the network.  I didn't know of any and was wondering if
> anyone out there in netland knew of any.  If not, I guess I will have
> to write something myself.  I would appreciate any infomation about
> programs or algorithms that do file broadcasting.  It must use a broadcast,
> not a copy to one machine then copy to another method (i.e. UDP), and
> if a machine is up it must reliably send the file.
>
>

We have written a protocol we call "A Coherent File Transfer Protocol" 
(RFC number pending). The idea is that the server broadcasts packets
from a file, and all the clients grab them as they fly by. If they miss
any, they send block requests to the server. We are in the process
of polishing the reference port, which will be available from 
cs.columbia.edu [128.59.16.20] for anonymous ftp. 

Watch this space!

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 18:56:38 GMT
From:      pyramid!lstowell@hplabs.hpl.hp.com  (Lon Stowell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can One API Support Both TCP/IP and LU 6.2?
Yes, you can build a common API.  CPI-C on the AS/400 is such a
product, you can run TCP/IP, OSI, SNA from the same API.  The
difficulty in naming conventions is hidden in the fine print of
such API's....as are the other differences in these protocol
stacks.  All of them provide essentially similar services, but
the LAYER within which a specific service is performed as well
as the implementation method varies widely.

The IBM technique is to note that all of the naming, route
discovery, etc. methods are "implementation specific" and that
they are utility functions performed by the Physical Unit.

Not only do the naming conventions of LU 6.2 differ from TCP/IP,
the techniques for route discovery and routing differ as well.
About the only thing the two have in common is the ability to
provide a high level common API.   

Such a "generic" API implementation will never be as efficient
as a protocol specific one, but it sure makes things a LOT
easier on programmers, user's etc.  RAM is cheap, and MIPS are
always available.  Programmer's blood pressure and sanity are
a little more precious.....


            /|
	\'o.O'
	=(___)=
	   U

     THPTH! ACKHH!
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 21:59:03 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   router tests volume 3
Well here it is, the results of the 3rd round of router testing.

This round consists of local Ethernet to Ethernet routers, all of them I
could get.

This document is copyright 1990 by Scott Bradner.

You can repoduce this posting in any way you want as long as the copy
is complete with no modifications.

A set of files for the slides that I used in the InterOp report are on
husc6.harvard.edu in pub/rtests (the old stuff is in "old"), lots of
nice graphs etc.

    Scott Bradner, Harvard University, 33 Kirkland St., Cambridge MA 02138
    (617)495-3864, sob@harvard.edu

First some history:

	I got a call from Wellfleet back in August wondering if I was going
to go through another round of tests.  I said that I did not have the
required equipment, since many of the vendors now had equipment that was
faster than the test setup we had used last year.  "We will give you some
equipment to do your tests." he said.  "Well..." said I, "how about a loan?",
"Sure" he said.  So after some discussion they agreed to loan me some of
the equipment that they were using for in house testing.  They also agreeed
to provide access to Terry Bradley who had done all the programming on the
test bed. (I, naturally, wanted some changes in the test software.)
Terry spent quite a while making the changes I requested and getting out a
number of small bugs, and I sent out a call for equipment to be tested.  I
got back quite a few devices and herein report the results of the tests.

	All but one of the vendors sent a person along with the
router to do setup. (So I would not have to read all those manuals and set
the things up wrong in the end.)  The tests for each of the devices were
done over one or two days at a lab at Harvard.

The test setup:

	A modified Wellfleet router was used a a test source.  This device
	had two separate channels of test traffic.  Each channel consisted
	of one packet source port and one "keep alive" port.  The "keep alive"
	port sent out groups of frames designed to convince the router that a
	node existed on this "net" that spoke some specific protocols.  The
	supported protocols were:

	IP		( keep alive was a ARP response)
	DECNET		(hello packet)
	AppleTalk II	(AARP packet)
	IPX		(IPX-RIP? response)
	bridge mode	( a packet with a specific source MAC address)

	The device-to-be-tested was attached so that an "input" port
	was attached to one of the test frame sources and an "output" port
	was attached to the corresponding "keep alive" port.  If the device had
	four or more ports, both sets of test channels were used.

	The modified Wellfleet router generated a stream of test frames
	consisting of a specific number of frames, in a selected protocol, of a
	selected size and with a selected interframe gap (ifg).  One of the test
	channels (channel 3) was used for all of the tests and the 2nd
	channel was used only for the dual stream test.

	test source frame rate:
	size	theoretical	channel "3"	channel "4"
	64	14880		14489		14549
	128	 8445		 8324		 8340
	256	 4528		 4494		 4498
	512	 2349		 2340		 2341
	1024	 1197		 1195		 1195
	1518	  812		  812		  812

	(The Wellfleet test code can do quite a bit more than I made use of,
	it can generate mixed protocol packet streams for example, additional
	work needs to be done to create a set of test specifications that better
	emulate a "real" data network.)

The counter:
	A HP 4972A Lan Protocol Analyzer was used to find the frame rates
	and to count the output frames.  The HP ran the "stats" program
	to monitor the network.

The router configuration:
	The router was configured at the start of the test suite and the
	configuration was not changed throughout the first set of tests.
	The configuration was then altered to add a single "filter"
	condition, tests were run on that, then the configuration was
	changed to add 9 more filter conditions and tests were run on that.
	The bridge tests were configured for and run separately.
	
The tests:

    Note:
	The design of these tests comes from the work of the IETF
	Benchmarking Methodology Working Group.

  single channel:
    "delay"
	Aim - find delay through router.
	A Tektronix 2337 scope was attached to both the input and
	output router ports.
	A stream of frames with a large ifg was sent through the router.
	The scope was used to measure the time delay between the end
	of the input frame and the start of the output frame.
    "raw rate"
	Aim - find out impact of max rate input data rate.
	The HP was connected to the "output" port of the router.
	A stream of frames of a specific protocol and a specific size
	with the minimum ifg, was sent to the input port on
	the router.  The number of frames was selected to produce about
	30 sec of data stream. 
	The "stats" program was reset after the start of the data stream
	and the "10 sec avg" value was watched to get the "raw rate".
    "max rate"
	Aim - find highest rate at which router passes 100% of input frames.
	The HP was connected to the "output" port of the router.
	A stream of frames of a specific protocol and a specific size
	with a selected inter frame gap, was sent to the input port on
	the router.  The number of frames was selected to produce about
	20 sec of data stream. 
	The "stats" program was reset before the data stream was started.
	The "total frames" value was used to see if all of the offered
	frames were forwarded.  If not, the ifg was increased, if yes
	the ifg was reduced.  This process was followed until the point
	at which a reduction of "1" in the ifg would not pass all the
	frames.
	The HP was then attached to the frame source and the test rerun
	with the determined ifg to get the frame rate.

   "dual stream"
	Aim - find effect of more than one data stream through router.
	"raw rate" test run but with both frame sources sending frames
	with the minimum ifg.
	The HP was first connected to one "output", a test was run to
	find the rate, then the HP was moved to the other output and the
	test rerun.
	NOTE: this test is flawed, the "right" way to do this is the same
	as for the "max rate" test, putting the same frame rate into both
	inputs and counting the outputs.  But this was just to much work,
	strong need for automation.
		
Some nomenclature:
	"one filter"
		permit traffic from ip address 192.32.100.1 to 192.32.200.1
	"10 filter"
		permit traffic from ip address 192.32.100.11 to 192.32.200.11
		permit traffic from ip address 192.32.100.12 to 192.32.200.12
		permit traffic from ip address 192.32.100.13 to 192.32.200.13
		permit traffic from ip address 192.32.100.14 to 192.32.200.14
		permit traffic from ip address 192.32.100.15 to 192.32.200.15
		permit traffic from ip address 192.32.100.16 to 192.32.200.16
		permit traffic from ip address 192.32.100.17 to 192.32.200.17
		permit traffic from ip address 192.32.100.18 to 192.32.200.18
		permit traffic from ip address 192.32.100.19 to 192.32.200.19
		permit traffic from ip address 192.32.100.1 to 192.32.200.1
	"between interface cards" for the single channel tests means
		a data stream that goes in a port on one Ethernet interface
		card and out a port on a 2nd Ethernet interface card.
	"within interface card" for the single stream tests means
		a data stream that goes in a port on an Ethernet
		interface card and out on another port on the same card.
	"between interface cards" for the dual stream tests means two data
		streams, both of which come in ports on one Ethernet
		interface card and both of which exit from ports on a 2nd 
		Ethernet interface card.
	"within interface card" for the dual stream tests means one data
		stream that comes in a port on one Ethernet interface card
		and exits via another port on the same card, and a 2nd
		stream that enters on one port on a separate Ethernet
		interface card and exits via a 2nd port on this separate
		card.

The results:
	(I have checked these numbers but there may be transcription or
typing errors.)

3com NETBuilder - TCP/IP - within interface card

size    theo    test  ip_max  ip_fld
64     14880   14489    6404    6401
128     8445    8324    6648    6553
256     4528    4494    4004    3953
512     2349    2340    2202    2183
1024    1197    1195    1010    1153
1518     812     812     799     792

3com NETBuilder - Bridge Mode - within interface card

size    theo    test  br_max  br_fld
64     14880   14489    9830    9750
128     8445    8324    6735    6564
256     4528    4494    3994    3953
512     2349    2340    2202    2183
1024    1197    1195    1159    1153
1518     812     812     805     792

BBN T20 - TCP/IP - within interface card

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489    4315    4664    2620    2778    2620    2775
128     8445    8324    4339    4654    2433    2777    2433    2777
256     4528    4494    4493    4493    2231    2772    2231    2774
512     2349    2340    2340    2340    2340    2340    2340    2340
1024    1197    1195    1194    1194    1194    1194    1194    1194
1518     812     812     811     811     811     811     811     811

cisco AGS+ - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489   14488   14488   14488   14488   14488   14488
128     8445    8324    8324    8324    8324    8324    8324    8324
256     4528    4494    4493    4493    4494    4494    4494    4494
512     2349    2340    2340    2340    2340    2340    2340    2340
1024    1197    1195    1194    1194    1195    1195    1195    1195
1518     812     812     811     811     812     812     812     812

cisco AGS+ - AppleTalk II - between interface cards

size    theo    test at2_max at2_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340

cisco AGS+ - DECNET - between interface cards

size    theo    test  dn_max  dn_fld
64     14880   14489   13097   13270
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - IPX - between interface cards

size    theo    test ipx_max ipx_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - Bridge Mode - between interface cards

size    theo    test  br_max  br_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - Dual IP Streams - between interface cards

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    9682    9700
128     8445    8324    8340    8324    8340
256     4528    4494    4498    4493    4498
512     2349    2340    2341    2340    2341
1024    1197    1195    1195    1194    1195
1518     812     812     812     812     812

cisco AGS+ - TCP/IP - within interface card

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489   14488   14488   14488   14488   14488   14488
128     8445    8324    8324    8324    8324    8324    8324    8324
256     4528    4494    4494    4494    4494    4494    4494    4494
512     2349    2340    2340    2340    2340    2340    2340    2340
1024    1197    1195    1195    1195    1194    1194    1194    1194
1518     812     812     812     812     811     811     811     811

cisco AGS+ - AppleTalk II - within interface card

size    theo    test at2_max at2_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340

cisco AGS+ - DECNET - within interface card

size    theo    test  dn_max  dn_fld
64     14880   14489   13097   13256
128     8445    8324    8323    8323
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - IPX - within interface card

size    theo    test ipx_max ipx_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - Bridge Mode - within interface card

size    theo    test  br_max  br_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

cisco AGS+ - Dual IP Streams - within interface card

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    9689    9698
128     8445    8324    8340    8323    8340
256     4528    4494    4498    4494    4498
512     2349    2340    2341    2340    2341
1024    1197    1195    1195    1194    1195
1518     812     812     812     812     812

Network Systems Corporation EN640-8 - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489    6327    6233    4636    4413    1718    1670
128     8445    8324    5105    5189    4111    3875    1629    1576
256     4528    4494    3755    3752    3745    3756    1599    1536
512     2349    2340    2124    2123    2122    2123    1565    1493
1024    1197    1195    1137    1136    1138    1138    1141    1135
1518     812     812     786     784     787     786     788     784

Network Systems Corporation EN640-8 - AppleTalk II - between interface cards

size    theo    test at2_max at2_fld
64     14880   14489     827       0
128     8445    8324     808       0
256     4528    4494     770       0
512     2349    2340     702     269

Network Systems Corporation EN640-8 - DECNET - between interface cards

size    theo    test  dn_max  dn_fld
64     14880   14489     919       0
128     8445    8324     886       0
256     4528    4494     825       0
512     2349    2340     727     280
1024    1197    1195     588     452
1518     812     812     443     381

Network Systems Corporation EN640-8 - Dual IP Streams - between interface cards

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    3224    3396
128     8445    8324    8340    2832    2975
256     4528    4494    4498    2638    2651
512     2349    2340    2341    2335    2123
1024    1197    1195    1195    1138    1195
1518     812     812     812     786     812

Network Systems Corporation EN640-8 - TCP/IP - within interface card

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489    5986    6604    4775    4630    1732    1702
128     8445    8324    5259    5732    4605    4164    1662    1629
256     4528    4494    3727    3757    3729    3641    1541    1523
512     2349    2340    2128    2123    2122    2123    1508    1450
1024    1197    1195    1140    1138    1139    1135    1139    1135
1518     812     812     788     784     788     783     780     782

Network Systems Corporation EN640-8 - AppleTalk II - within interface card

size    theo    test at2_max at2_fld
64     14880   14489     828       0
128     8445    8324     805       0
256     4528    4494     767       0
512     2349    2340     701     266

Network Systems Corporation EN640-8 - DECNET - within interface card

size    theo    test  dn_max  dn_fld
64     14880   14489     919       0
128     8445    8324     885       0
256     4528    4494     826       0
512     2349    2340     719     278
1024    1197    1195     580     453
1518     812     812     439     381

Novell NetWare 386 - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld
64     14880   14489    3275    3270
128     8445    8324    3207    3202
256     4528    4494    2892    2856
512     2349    2340    1822    1764
1024    1197    1195    1050    1030
1518     812     812     744     731

Novell NetWare 386 - IPX - between interface cards

size    theo    test ipx_max ipx_fld
64     14880   14489    3295    3240
128     8445    8324    3274    3172
256     4528    4494    2953    2852
512     2349    2340    1861    1768
1024    1197    1195    1078    1031
1518     812     812     787     731

Proteon P4200 - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489    3616    3576    2675    2054    2675    2050
128     8445    8324    3081    3058    2247    1674    2258    1668
256     4528    4494    1667    1529    1493    1253    1493    1248
512     2349    2340     948     896     875     815     876     814
1024    1197    1195     508     473     465     447     465     447
1518     812     812     348     325     324     313     325     313

Proteon P4200 - DECNET - between interface cards

size    theo    test  dn_max  dn_fld
64     14880   14489    1747    1469
128     8445    8324    1595    1453
256     4528    4494    1505    1401
512     2349    2340     968     804
1024    1197    1195     539     452
1518     812     812     405     310

Proteon P4200 - IPX - between interface cards

size    theo    test ipx_max ipx_fld
64     14880   14489    1881    1593
128     8445    8324    1718    1560
256     4528    4494    1608    1503
512     2349    2340     970     812
1024    1197    1195     519     450
1518     812     812     411     310

Proteon P4200 - Dual IP Streams - between interface cards

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    1085    1181
128     8445    8324    8340       U       U
256     4528    4494    4498     825     833
512     2349    2340    2341     665    1107
1024    1197    1195    1195    1109     665
1518     812     812     812     270     433

Proteon rig - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489   12802   12142    4622    4513    4605    4530
128     8445    8324    7896    7998    4233    4212    4222    4204
256     4528    4494    4351    4350    2964    2944    2964    2943
512     2349    2340    2287    2294    1850    1835    1850    1837
1024    1197    1195    1186    1181    1060    1047    1060    1048
1518     812     812     812     805     749     741     749     742

Proteon rig - Dual IP Streams - between interface cards

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    8516    7749
128     8445    8324    8340    8027    6989
256     4528    4494    4498    4494    3936
512     2349    2340    2341    2333    4098
1024    1197    1195    1195    1193    1192
1518     812     812     812     810     809

Timeplex TIME/LAN 100 - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld
64     14880   14489    5480    4822
128     8445    8324    4865    4162
256     4528    4494    3287    3253
512     2349    2340    1969    1949
1024    1197    1195     977     973
1518     812     812     691     687

Wellfleet Link Node - TCP/IP - between interface cards

size    theo    test  ip_max  ip_fld  1f_max  1f_fld 10f_max 10f_fld
64     14880   14489   14473   14473   11107   10778    9708    9998
128     8445    8324    8322    8322    8322    8322    8324    8324
256     4528    4494    4493    4493    4494    4494    4494    4494
512     2349    2340    2340    2340    2340    2340    2340    2340
1024    1197    1195    1196    1196    1193    1193    1195    1195
1518     812     812     811     811     811     811     812     812

Wellfleet Link Node - AppleTalk II - between interface cards

size    theo    test at2_max at2_fld
64     14880   14489   12676   13629
128     8445    8324    8324    8324
256     4528    4494    4493    4493
512     2349    2340    2341    2341

Wellfleet Link Node - DECNET - between interface cards

size    theo    test  dn_max  dn_fld
64     14880   14489   10151   10404
128     8445    8324    8322    8322
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1194    1194
1518     812     812     812     812

Wellfleet Link Node - IPX - between interface cards

size    theo    test ipx_max ipx_fld
64     14880   14489   10420   10642
128     8445    8324    8324    8324
256     4528    4494    4493    4493
512     2349    2340    2340    2340
1024    1197    1195    1194    1194
1518     812     812     812     812

Wellfleet Link Node - Bridge Mode - between interface cards

size    theo    test  br_max  br_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

Wellfleet Link Node - Dual IP Streams - between interface cards

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549    7790    7780
128     8445    8324    8340    7186    7196
256     4528    4494    4498    4491    4493
512     2349    2340    2341    2340    2339
1024    1197    1195    1195    1194    1194
1518     812     812     812     811     811

Wellfleet Link Node - TCP/IP - within interface card

size    theo    test  ip_max  ip_fld  1f_max  1f_fld  1f_max  1f_fld
64     14880   14489   11086   12646    8983    9636    8930    9655
128     8445    8324    8322    8322    8324    8324    8324    8324
256     4528    4494    4493    4493    4494    4494    4494    4494
512     2349    2340    2340    2340    2340    2340    2340    2340
1024    1197    1195    1196    1196    1193    1193    1193    1193
1518     812     812     811     811     811     811     811     811

Wellfleet Link Node - AppleTalk II - within interface card

size    theo    test at2_max at2_fld
64     14880   14489   10707   11390
128     8445    8324    8322    8322
256     4528    4494    4493    4493
512     2349    2340    2339    2339

Wellfleet Link Node - DECNET - within interface card

size    theo    test  dn_max  dn_fld
64     14880   14489    8634    8982
128     8445    8324    8322    8322
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1193    1193
1518     812     812     811     811

Wellfleet Link Node - IPX - within interface card

size    theo    test ipx_max ipx_fld
64     14880   14489    8780    9109
128     8445    8324    8322    8322
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1194    1194
1518     812     812     811     811

Wellfleet Link Node - Bridge Mode - within interface card

size    theo    test  br_max  br_fld
64     14880   14489   14488   14488
128     8445    8324    8324    8324
256     4528    4494    4494    4494
512     2349    2340    2340    2340
1024    1197    1195    1195    1195
1518     812     812     812     812

Wellfleet Link Node - Dual IP Streams - within interface card

size    theo   test1   test2  d1_fld  d2_fld
64     14880   14489   14549   12652   13024
128     8445    8324    8340    8324    8337
256     4528    4494    4498    4491    4497
512     2349    2340    2341    2334    2341
1024    1197    1195    1195    1195    1195
1518     812     812     812     811     811
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 90 23:18:54 GMT
From:      brunner@bullhead.uucp
To:        comp.sys.ibm.pc.rt,comp.protocols.tcp-ip
Subject:   Re: X25 for RT running BSD 4.3

In article <788@nikhefk.UUCP> werner@nikhefk.UUCP (Werner Vogels) writes:
>
>Does anybody know anything about a X25 board and software for a RT running
>BSD4.3 .
>
>Werner H.P. Vogels
>Software Expertise Centrum                      
>Haagse Hogeschool, Intersector Informatica     tel: +31 70 618419
>Louis Couperusplein 2-19, 2514 HP Den Haag     E-mail: werner@nikhefk.nikhef.nl
>The Netherlands                                     or werner@hhinsi.uucp

I don't know of one, if there is one I would like to know also. I'm cross
posting this to the tcp-ip list as someone on the tcp-ip list may know of
an X.25 board for the IBM RT running 4.3bsd.

#include <std/disclaimer.h>
Eric Brunner, Consultant, IBM AWD Palo Alto	(415) 855-4486
inet: brunner@monet.berkeley.edu		uucp: uunet!ibmsupt!brunner
trying to understand multiprocessing is like having bees live inside your head.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 07:55:37 -0400
From:      Scott Brim <swb@chumley.TN.Cornell.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
And don't forget about VMTP.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 03:19:58 GMT
From:      olivea!samsung!munnari.oz.au!mtiame!ubeaut!mwp@apple.com  (Michael Paddon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
From article <538@gohp3.graphon.com>, by dc@gohp3.graphon.com (Darren Croke):
> In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes:
>>
>>There is not much point setting TCP_MSS to be greater than
>>	(maximum IP packet size - IP header size - TCP header size)
>>[536 octets] since IP fragmentation will take place. Receipt of a
>>fragmented packet is an all or nothing proposition; a good thing to
>>avoid for throughput reasons.
>>
> I think you will find that it is common for IP implementations to
> send and accept datagrams without fragmentation up to 
> (connected network MTU - IP header size - TCP header size).

You are, of course, correct. The link-layer MTU is the important variable
here, determining the maximum size of datagrams (up to 64K octets).

I pulled the value 536 from some work I was doing with a SLIP implementation,
forgetting at the time that it was a special case.

					Michael

-------------------------------------------------------------------
|                     |     Internet: paddon@meo78b.enet.dec.com  |
|                     |     ACSnet:   mwp@ubeaut.oz.au            |
|  Michael Paddon     |     ACSnet:   mwp@munnari.oz.au           |
|                     |     EasyNet:  meo78b::paddon              |
|                     |     Voice:    +61 3 895 9392              |
-------------------------------------------------------------------
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 08:41 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        Chris Johnson <sgi!cjohnson%somni.wpd.sgi.com@ucbvax.berkeley.edu>, tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re:  Reliable Datagram ??? Protocols
Your message suggests that you are differing over facts, when it's clear
that the difference is in terminology.

I'd  bet that Jon is one of the original coiners of the term 'datagram'.
(If not, I'm sure he rubbed shoulders with the fellow that coined the term.)

The XTP use of the term could be considered inappropriate.  Perhaps it
should have been called something else.  (Reliable transaction packet?
Unit message?)

- Bob Stine

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 14:40:40 -0400
From:      tmallory@BBN.COM
To:        tcp-ip@nic.ddn.mil
Cc:        tmallory@BBN.COM
Subject:   Re: Reliable Datagram Protocol

I've didn't save the original message because I felt sure someone would
chip in the following:

from rfc-index.txt.1174:
1151  Partridge, C.; Hinden, R.M.  Version 2 of the Reliable Data Protocol
      (RDP).  1990 April; 4 p. (Format: TXT=8293 bytes)  (Updates RFC 908)

This is really an addendum to RFC 908, which must also be retrieved.

[the first name for this protocol WAS Reliable Datagram Protocol]

Not that you will find this widely implemented, but it surely ought to be
mentioned given the original request.

Tracy
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 09:23:17 +0100
From:      Denis.Russell@newcastle.ac.uk
To:        tcp-ip@nic.ddn.mil
Subject:   IP over X.25 - summary
On 4th Oct I sent out a query about routing extensive IP over an
X.25  network.   This  is  a brief summary of the responses, and
other information gathered at the same time.  Many thanks to all
those who responded.
 
I  got  several  messages  in  reply.   It  seems  that the main
commercial routers have the right characteristics for the  task.
They  can  support  high speed, have settable inactivity timers,
multiple X.25 calls, use X.25 calls for  two-way  traffic.   All
the  things  we'd hoped for, even expected, but weren't actually
certain about.
 
It  was  confirmed  that  the Sun software established permanent
X.25 calls and never  cleared  them  down,  but  several  people
referred  us to the Nottingham software that did not suffer from
these problems.
 
Several people warned us that large packet and window sizes were
an absolute must for throughput.
 
Sadly,  and  despite a couple of specific queries, there were no
responses directly from people relating experience of setting up
an extensive IP network on top of an X.25  network  rather  than
just  operating  a  few  links.  However, the second-hand wisdom
(which I do not doubt) was that it was not an ideal way  to  run
an  IP  network, but that, subject to tuning, etc, it would work
OK.
 
             Denis.
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 11:06:16 GMT
From:      clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!ria!ria.ccs.uwo.ca!peter@uunet.uu.net  (Peter Marshall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
In article <2126@excelan.COM>, donp@na.excelan.com (don provan) writes:
|> In article <1990Oct5.123350.145@arizona.edu> leonard@arizona.edu writes:
|> >I believe that Novell's IPX similarly hacks the Ethernet address....
|> 
|> This has nothing to do with TCP-IP, but i don't want this rumor to
|> spread.  IPX does not modify the ethernet address.

While DECnet IV wants to change the ethernet number to match the DECnet node
and host number, IPX only requires the same ethernet number to be used on all
interfaces to a machine.  It doesn't care what they are set to.  This allows
DECnet and IPX to  coexist on the same router as long as you get the DECnet
running first and then start the IPX.


--
Peter Marshall, Manager (Academic Networking)
CCS, NSC, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2111x6032
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@ria.uucp
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 18:03:51 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Erik Scheelke <apple.com!erekose@apple.com>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: Reliable Datagram Protocols
 
All semantics aside there was a working group that had outlined
a draft RFC xxxx for doing " OSI Connectionless XPORT Services on
top of UDP ".....heresy I know (smile).

It was in memo format and comments email addr was listed as
'chi@osf.org'. That is as close as you may come to a non
proprietary implementation of what you are looking for.

I don't even know if the group still exists, but the draft had
some interesting possibilities for certain applications and
services over an IP backbone.

 Good Luck
 George Williams
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 12:06:34 GMT
From:      bbn.com!craig@apple.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about SMTP MX records
In article <1990Oct18.164200.5699@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes:
>...  As a workaround, I thought I would just
>send to someone%applelink.apple.com@apple.com.  It is my (limited) 
>understanding that addresses are parsed from right to left, so this
>message would be sent to apple.com, who would then be able to forward
>it to applelink.apple.com.

>1) is the syntax of the address I am trying to use valid?

    Yes the syntax is correct.

>2) am I violating any network rules by routing my message through
>another host?

    No, though doing this sort of thing frequently (like sending all
your mail via another system because your system doesn't support MX)
is considered rude.

>3) should this message be getting delivered?  

    Yes.  Apple.com is the MX for applelink.apple.com, so it should
    accept mail for applelink.apple.com.  Note that if Apple.com was
    not the MX for applelink.apple.com, then all bets are off.  You
    should not assume that via j random host using the %-hack is
    safe or reasonable.

    You mention your mail is going into a black hole, that's definitely
    a problem.  Mail should not vanish without a trace...

Craig
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 16:05:43 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP monitors
In article <9010181639.AA14322@po.cis.brown.edu>
 Steven_Carmody@BROWN.EDU writes:

>... I'd like to get a sense of what's out there. So far, I
>can see three groups of products: 1) the PC-based monitors (wollongong, the
>recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a
>large number of commercially available, UNIX based monitors (often from
>router vendors)...
>
>The question is -- are there any generalizations which can be made about
>each of the categories?

	I can generalize.  :-)

1)	I don't like PC based packages because I need workstation
power and multitasking.  You will need multitasking and virtual memory
to do good fault management and data gathering.  Of course, you could
use a pile of PCs.  And I do understand the need for a low end PC
package for smallish PC networks.  So I would say they are OK for
small nets with unsophisticated tool requirements, but not suitable
for largish nets.

	The Proteon Overview PC tool is pretty good, even in its
earliest release, with which I am most familiar.

2)	The NYSERnet stuff is still pretty good in comparison to other
software, and that is disappointing.  It indicates that the
development of tools has stalled or gotten sidetracked.  Some points
of interest:

3)	Fancy graphics.  Migrating from an early X window environment
to Motif doesn't buy the network manager a lot.  This has distracted
developers excessively.  But Motif is very pretty; witness the
Cabletron displays.  Nice pastels, shadows, pictures, etc.  Value?  To
be determined.  The people running the InterOp show network used ping
and traceroute a lot, but then they may be old fashioned.  :-)

	Databases.  A database is an important feature of an advanced
network management fault monitor and data gatherer.  Early
implementations fall short in the ease of use category.  We need some
database interfaces that match the window environment more closely.

	Configuration.  It is very difficult to adopt or change a tool
in a large network if the tool does not help the network manager
configure the tool.  This is one area where the NYSERnet tool is just
awful, requiring the same data to be entered multiple times
consistently in the snmpxmon.cf file.  Dynamic configuration of
commercial products is on the drawing board in the tools I have
examined closely, but is not available in a production release.

	Data gathering and interpretation.  This area has been
entirely neglected in the tools I have seen.  Data gathering and
analysis should be database driven.  Report generators should be
supplied and should be customizable.  The database must be accessible
outside the network management tool.  The database must be custom
extensible to deal with such local issues as inventory and cost
accounting.  There should be utilities for automagic aging and
compression of performance data timelines, reducing the demand for
disk space growth and easing back-up and archiving.  No one is
addressing these issues, in the tools I have examined.  NYSERnet is
still as good as any of the other tools, which is disappointing.

	One reason I think that progress is disappointing is that the
network management market is limited.  Developers are getting enamored
of the "Distributed Computing Environment Management".  I have heard
more than one developer talk about stuffing every conceivable variable
and extension into the MIB for managing PCs, workstations, and servers
and this is a distraction away from the purely Network Management
needs of largish networks.  However, I understand that tools for DCE
management are useful.  Sun's tool is interesting.  If it saves
sysadmin time, it's a good thing.  DCE management tools have a wider
market than purely NM tools.  But DCE management is more embryonic
than NM, so I would rather see some vendors concentrate on solving NM
problems before turning to DCEM.  They could learn from us.

	One bright note: Cabletron's Network Virtual Machine and
object oriented development environment are powerful architectural
elements of next generation tools.  The NVM can scale well, and holds
out some hope of unified Internet management (if such could happen
politically and organizationally and could be standardized for
interoperability).  The OOP model in the Cabletron Spectrum tool is an
apparently powerful technique for allowing user customization and for
MIB and device tracking.  I think object oriented techniques will
prove very useful in managing development of sophisticated NM tools,
but that is just my embryonic gut feel; it has yet to be demonstrated.

	--Kent
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 17:52:33 GMT
From:      agate!shelby!msi.umn.edu!cs.umn.edu!ux.acs!aaron@ucbvax.Berkeley.EDU  (Aaron Y.T. Cheung)
To:        tcp-ip@nic.ddn.mil
Subject:   Which is the correct/standard way to set up a mail forwarder w/ MX ?
Question being:

I want to set up host abc.edu as MX forwarder for domain xyz.org,
whereas host def.edu (which takes to abc.edu via smtp) takes care
of all xyz.org mails,

could someone point me to the standard way to have it set up, with
sendmail.cf (or elsewhere)? Eg., how does major MX gateways running
SMTP do that, TECHNICALLY?

In short and again, host abc.edu will receive all mails for xyz.org
and forward it to def.edu for final delivery.

NOTE: root@xyz.org should NOT be forwarded to root@abc.edu (ie,
      xyz.org is not to be set up as an alias of abc.edu.)


You can assumption:
1. the MX record for xyz.org is already in the DNS system & readily resolvable.
2. abc.edu and def.edu can talk to each other via smtp

Thanks in advance, /aaron.
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 18:40:40 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Datagram Protocol


I've didn't save the original message because I felt sure someone would
chip in the following:

from rfc-index.txt.1174:
1151  Partridge, C.; Hinden, R.M.  Version 2 of the Reliable Data Protocol
      (RDP).  1990 April; 4 p. (Format: TXT=8293 bytes)  (Updates RFC 908)

This is really an addendum to RFC 908, which must also be retrieved.

[the first name for this protocol WAS Reliable Datagram Protocol]

Not that you will find this widely implemented, but it surely ought to be
mentioned given the original request.

Tracy

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 20:36:12 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about SMTP MX records
In article <1990Oct18.164200.5699@ecst.csuchico.edu>, robin@csuchico.edu (Robin Goldstone) writes:
> I am trying to send a message to someone@applelink.apple.com.  This
> host has no TYPE A record, only an MX record.  My mailer currently
> cannot resolve MX records.  As a workaround, I thought I would just
> send to someone%applelink.apple.com@apple.com.  It is my (limited) 
> understanding that addresses are parsed from right to left, so this
> message would be sent to apple.com, who would then be able to forward
> it to applelink.apple.com.
> 
> Some questions:
> 1) is the syntax of the address I am trying to use valid?
> 2) am I violating any network rules by routing my message through
> another host?
> 3) should this message be getting delivered?  
> I have sent several test messages that have disappeared into a black hole...

The use of the '%' hack is not a part of any standard. But it usually works. So
the syntax of the address is probably OK. APPLE.COM is the mail exchanger for
APPLE and APPLELINK, so it SHOULD work, but only by convention. It does not
violate any "rules", such as they aren't. But this type of routing is quite
undesireable--but very common.

Mail to APPLELINK is staged on APPLE.COM for delivery, so maybe the route
between APPLELINK and APPLE is down.

You should really try to get a mailer that handles MX records some day.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 22:03:51 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Datagram Protocols


 
All semantics aside there was a working group that had outlined
a draft RFC xxxx for doing " OSI Connectionless XPORT Services on
top of UDP ".....heresy I know (smile).

It was in memo format and comments email addr was listed as
'chi@osf.org'. That is as close as you may come to a non
proprietary implementation of what you are looking for.

I don't even know if the group still exists, but the draft had
some interesting possibilities for certain applications and
services over an IP backbone.

 Good Luck
 George Williams

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 90 22:31:46 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu  (Jan Engvald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Address Uniqueness...
>While DECnet IV wants to change the ethernet number to match the DECnet node
>and host number, IPX only requires the same ethernet number to be used on all
>interfaces to a machine.  It doesn't care what they are set to.  This allows
>DECnet and IPX to  coexist on the same router as long as you get the DECnet
>running first and then start the IPX.

No, NO. *NOVELL* IPX routers/servers don't change the Ethernet address
of any interface card (*).

We have several servers with two Ethernet cards. One card uses type
8137 protocoll and the other Novells ISO-like protocoll. Both are
connected to the *SAME* Ethernet segment, and if they used the same
Ethernet address it would mean disaster.

Looking with an Ethernet monitor you can see that at the link layer
each card uses its own address that it was born with. However, at the
network layer Novell IPX uses 32 bits of network id + 48 bits node id,
and the node id is the Ethernet address of the first (LAN A) card.

(*) The Cisco router, for some reason I don't understand, say they
    do change the adress of its interfaces when Novell IPX routing
    is turned on.
                                             
Jan Engvald, Lund University Computing Center
________________________________________________________________________
   Address: Box 783                E-mail: xjeldc@ldc.lu.se
            S-220 07 LUND     Earn/Bitnet: xjeldc@seldc52
            SWEDEN           (Span/Hepnet: Sweden::Gemini::xjeldc)
    Office: Soelvegatan 18         VAXPSI: psi%2403732202020::xjeldc
 Telephone: +46 46 107458          (X.400: C=se; A=TeDe; P=Sunet; O=lu;
   Telefax: +46 46 138225                  OU=ldc; S=Engvald; G=Jan)
     Telex: 33533 LUNIVER S
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Oct 90 14:31:12 -0400
From:      ah335@cleveland.Freenet.Edu (Richard Banks)
To:        tcp-ip@nic.ddn.mil
Subject:   Test; Please ignore.


This is a test, I don't think i'm receiveing the lsit !
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Oct 90 20:15 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Why Sun adopted UDP-based RPC to implement NFS, but not TCP-based RPC?

Hi, netlander! The title says it all. What is your opinions of why Sun adopted
UDP-based RPC to implement NFS, not TCP-based RPC? Since in NFS, the client
and server normally would like to maintain the relationship for quite a long
time, using TCP-based RPC is supposed to be more economical/efficient (am I
rite?). Moreover, by using TCP-based RPC, there is no need to implement a
end-to-end mechanism for relaibility, since TPC has the necessary realibility
built in. Any ideas/opinions.

Thanks

- beng hang (email: taybengh@nusdiscs)
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Oct 90 16:25:30 EDT
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        wuarchive!emory!hubcap!mmccann@EDDIE.MIT.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Need phone numbers...
   Date: 16 Oct 90 20:54:54 GMT
   From: wuarchive!emory!hubcap!mmccann@eddie.mit.edu  (Mike McCann)

   ... networking companies (such as Proteon or Sysco)?

Proteon and Sysco are both Boston area companies and while Proteon
does do networking, Sysco is a food service company.  (You probably
meant cisco, it's pronounced the same :-).
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 90 17:42:59 GMT
From:      mcsun!unido!wrkof!dksoft!dirk@uunet.uu.net  (Dirk Koeppen)
To:        tcp-ip@nic.ddn.mil
Subject:   How to configure the network files in the right way ?

When I look at other TCP/IP boxes I mostly find strange configured
networks. Some loopback networks do not use the 127.0.0.1 address and
so on. 

Therefore I would like to put the following statements into discussion.
I am very interested if the way I configured my network is the right way to do.

The machine I configure is called dksoft (192.1.1.99) the network is
called incom (my full address is dksoft@incom.de).

First the /etc/hosts file:
127.0.0.1	loopback loop
192.1.1.99	dksoft dksoft.incom.de localhost local
192.1.1.100	nix nix.incom.de

Note that I put the localhost entry behind the name of the local host. Most
hosts have the localhost entry behind the kernel loopback entry. Also an
entry loopback names the kernel loopback address. Some systems I have seen
(especially SCO-UNIX) return a NULL-pointer on the gethostbyname() call
if the domain address is not set in the same line where the hostname appears.
Therefore I also addred the *.incom.de entry.

The /etc/networks file then looks like:
loopback	127		loopback-net software-loopback-net
incom		192.1.1		local-net

Another important point is how to load the network devices. The Ethernet
device I use is wd0, the kernel-loopback is lo0. I found that most
standard installations load the lo0 device with localhost. This would
set the Internet-address to the lo0 device.

I therefore changed my /etc/netd.cf file to the following:
ifconfig "wd0" dksoft up
ifconfig "lo0" loopback up

If I now use netstat -i everything seem all right:

Name  Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
wd0   1500  incom       dksoft.incom 2790    0     9522    2     0     
lo0   2048  loopback    loopback     14418   0     14418   0     0     

or netstat -in:

Name  Mtu   Network     Address      Ipkts   Ierrs Opkts   Oerrs Collis
wd0   1500  192.1.1     192.1.1.99   2790    0     9522    2     0     
lo0   2048  127         127.0.0.1    14422   0     14422   0     0     


Waiting for comments...
Dirk
-- 
..............							  .............
...........							     ..........
........  Dirk Koeppen - Holzwiesenweg 22 - D-6050 Offenbach - Germany  .......
.....  Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - uucp: dirk@incom.de  .....
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 90 21:25:48 GMT
From:      unmvax!pprg.unm.edu!topgun!mustang!nntp-server.caltech.edu!ggumby!tim@ucbvax.Berkeley.EDU  (Timothy L. Kay)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about SMTP MX records
oberman@rogue.llnl.gov writes:

>You should really try to get a mailer that handles MX records some day.

Fine, but how do we get Silicon Graphics to provide a mailer that supports
MX records?  Is there a way of putting pressure on them, such as being able
to claim that their machines violate internet standards or somesuch?

Tim
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Oct 90 06:22:58 EDT
From:      Vint Cerf <vcerf@NRI.Reston.VA.US>
To:        Craig Partridge <craig@nnsc.nsf.net>, tcp-ip@nic.ddn.mil, ietf@isi.edu
Cc:        lduncan@NRI.Reston.VA.US
Subject:   Re: SIGCOMM '90 materials
Regarding Tutorial Notes from SIGCOMM 90, please be aware that
we have ONLY the tutorial notes from Rudin/Van Jacobson (tutorial
number 1). We don't have any from the other tutorial. The cost
for the R/VJ tutorial notes is $30 which includes shipping and
handling for North American destinations. Air shipment to places
farther away will vary.

Vint Cerf
CNRI
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 90 05:19:18 GMT
From:      bbs!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   3c523 packet drivers -- what's the trick?
HELP!

We're trying to get a few PS/2s running with the packet drivers, and are
having no luck at all.  All we get is a "Timed out initializing board"
message...... and no function!

If anyone out there has this working, PLEASE let me know immediately.  Email
appreciated with hints, tricks, traps, and new code if we need something
other than what we have.  The drivers we have are dated mid-august of this
year.  We really need this working Monday AM!

Thanks MUCH in advance!

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 90 08:11:55 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!jgd@tut.cis.ohio-state.edu  (John G. DeArmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3c523 packet drivers -- what's the trick?
karl@naitc.naitc.com (Karl Denninger) writes:

>HELP!

>We're trying to get a few PS/2s running with the packet drivers, and are
>having no luck at all.  All we get is a "Timed out initializing board"
>message...... and no function!

I had the same problem last year.  I stumbled onto a work-around that
you probably won't like. :-)  I found that if an old beta version of
the driver was loaded, the machine warm booted and then the new version
loaded, everything worked OK.  Great, eh?

One must assume that some memory location is getting twiddled by one
or the other but I never had time to run this one down.  If you find
out what it takes to make the new ones work, I'd appreciate hearing.
Since terminal emulation is about all a PS/2 is good for, I expect
to run into a couple more someday.

John

-- 
John De Armond, WD4OQC  | "The truly ignorant in our society are those people 
Radiation Systems, Inc. | who would throw away the parts of the Constitution 
Atlanta, Ga             | they find inconvenient."  -me   Defend the 2nd
{emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st.
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 90 14:15:47 GMT
From:      bbn.com!craig@apple.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram Protocol
In article <9010201341.AA18699@ucbvax.Berkeley.EDU> tmallory@BBN.COM writes:
>from rfc-index.txt.1174:
>1151  Partridge, C.; Hinden, R.M.  Version 2 of the Reliable Data Protocol
>      (RDP).  1990 April; 4 p. (Format: TXT=8293 bytes)  (Updates RFC 908)
>
>[the first name for this protocol WAS Reliable Datagram Protocol]

A quick comment on RDP -- there's considerable misunderstanding about
what RDP is and is not.

When people ask for a reliable datagram protocol (and before Jon Postel
jumps on me, yes Jon, I know it is an oxymoron) what they typically
mean is a transaction protocol -- a protocol that allows them to exchange
data units reliably with multiple remote systems.  A sort of reliable
version of UDP.

RDP should be viewed as a record-oriented TCP.  I.e. RDP uses connections,
and transmits a reliable stream of delimited data.  It is not a transaction
protocol.

Craig
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 09:18:35 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        encore!zelig!jdarcy@husc6.harvard.edu  (Floating Exception)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
    apple.com!erekose@apple.com  (Erik Scheelke):
    >     Does anyone know of a reliable connectionless datagram protocol that
    >     runs on top of UDP?  Is so, is there a library out there I can get?
    
    postel@VENERA.ISI.EDU writes:
    >Hi.
    >
    >"Reliable Datagram" is an oxymoron.
    
    Very funny.  Really.  I would guess, however, that Erik is referring to a
    connectionless protocol that preserves message boundaries and guarantees
    delivery but not necessarily sequencing or non-duplication.  I'm sure such
    beasts exist somewhere.

What Jon said was the very, very condensed summary of an issue that he has
no doubt seen hashed over far too many times.  Even though I've been over
it twice as many times on the phone to customers as I've seen it discussed
here, I'll try my hand at laying it out in long form.

"Datagrams" are defined as single messages.  Sometimes you send one and you
don't expect an answer.  Sometimes you kind of hope for a reply, but the
transaction you are attempting isn't worth the overhead of setting up a
connection; if you don't get an answer, the request may have been lost, the
server may be down, or the reply may have been lost.  You don't care, there
are many servers, and your timeout handler has just sent a duplicate query
to another of them...

"Connectionless" means that there is no state at either the source or the
destination of the message.  Thus, a connectionless protocol cannot
guarantee delivery.  If the sender keeps enough state and includes enough
information in each message to guarantee delivery (e.g. some sort of
unique ID, and a timeout if the guaranteed response doesn't arrive), you
only need to add a little state to the receiver to allow sequencing and
non-duplication.  If the application must keep track because the
transport doesn't, it still looks like a connection to me...

So, every time this came up in the past, the next stage was to ask the
person looking for a "reliable connectionless protocol" or somesuch what
was really needed.  The most frequent goal has been some sort of transport
for a little machine, or a new one for which there is no networking
software yet.  The searcher doesn't want to implement all of TCP, and sees
"datagrams" as being easier, particularly on a single Ethernet.  Another
common goal has been to get very high throughput by avoiding the "excessive
overhead" of TCP, but Van Jacobsen's research has more or less laid that
one to rest.  A third one has been "preservation of message boundaries".

There are a number of 'reliable' alternatives to TCP, including NETBLT
(optimized for block transfers over lossy links), ISO TP, RDP and others.
Those I'm familiar with offer built-in functionality for preserving message
boundaries, along with varying approaches to connection establishment and
acknowlegement.  However, it does not appear that they provide enough extra
functionality, or require enough less effort to develop that they (except
for ISO TP) will ever become very widespread.

Frequently, having been made aware of the alternatives, the searcher reads
the specs and decides that he won't save anything.  Sometimes the next stage
is a complaint about excessive complexity containing the assertion "I never
see *any* packet loss between my Frobozz boxes on my FooNeT".  Whereupon
a large number of people jump down the complainer's throat, mostly network
maintainers suffering the slings and arrows of trying to make protocols
designed for 'little' nets run on 'big, bad' nets...

In summary, if you need reliability in an "internet" protocol, those "in
tune with the Tao of the Internet" assert that you need a connection, flow
control and an end-to-end data integrity check.  If all of your
transactions are guaranteed to fit in one packet, you can replace the
connection state with server idempotency.  If not, message boundaries are
best not tied to packet boundaries, lest you fall afoul of differing
MTUs and fragmentation (see RFC 1001/1002 Netbios over TCP for an example
of a header/length-based scheme).  If you leave the integrity check out,
that's your and your customers' risk, but leaving the flow control out
could get hosts ostracized by offended backbone router operators...

"Those who do not understand TCP are doomed to re-invent it..."

(??? who said that ???)

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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 04:15:42 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3c523 packet drivers -- what's the trick?
In article <1990Oct21.051918.5813@naitc.naitc.com> karl@naitc.naitc.com (Karl Denninger) writes:

   We're trying to get a few PS/2s running with the packet drivers, and are
   having no luck at all.  All we get is a "Timed out initializing board"
   message...... and no function!

The trick is to fetch sun.soe.clarkson.edu:pub/packet-drivers/3c523.com
(in binary mode, of course).  I just got it working in the past week.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 12:17:56 PDT
From:      postel@venera.isi.edu
To:        shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  Does ICMP optional data include IP header + options?

Paul Ciarfella:

	Yes.

--jon.
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 10:37:42 EDT
From:      Bob Stewart <rlstewart@eng.xyplex.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols
> > postel@VENERA.ISI.EDU sez:
> >
> > "Reliable Datagram" is an oxymoron.
> >
> > --jon.
>
> Chris Johnson responded: 
>
> Perhaps reliable datagram using UDP is an oxymoron, depending on the
> transport layer.
> 
> However XTP datagrams *are* reliable.  Mail to xtp-request@pei.com
> for information or a XTP spec.

If they're "datagrams", then they're not reliable.  That's part of the
definition.  What you might call a "reliable datagram" could also be called
a "single-exchange virtual circuit" (yuk).  I haven't really thought about
the techniques, but I'd expect to see a protocol that looks sort of like
a connection setup with data and an implied disconnect.  "Reliable datagram"
is sort of like "reliable mail", wishing can't make it so.  It's really 
reliable only when the destination application (!) says it got it.

	Bob


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 18:40:31 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        BILLW@mathom.cisco.com, jbvb@ftp.com
Cc:        encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
I may have missed the point but doesn't a PUSH accomplish the same thing?  In
which case no modification is required.

Merton
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 12:28:35 EDT
From:      key@cs.utk.edu
To:        tcp-ip@nic.ddn.mil
Cc:        key@cs.utk.edu
Subject:   Looking for PPP for Ultrix (4.0)
Has anyone (DEC?) done PPP for Ultrix 4.0 (RISC) yet?
I've seen the BSD 4.3 and SunOS4.0.1/386i distributions.
Is there a PPP implementor's mail-list/archive?

Thanks in Advance,
Ken Key   (key@utkux1.utk.edu)
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Mon 22 Oct 90 15:35:14-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        jbvb@ftp.com
Cc:        encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
I occasionally wonder whether we should just take TCP, add a comment
that says "you WILL preserve packet boundries", change the IP protocol
type, and say "poof, here is a reliable datagram protocol".

BillW
-------
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 10:52:09 GMT
From:      mcsun!inria!ircam!mf@uunet.uu.net  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   named going into an infinite loop ...
Machine: DECsystem 5820 (RISC)
OS:      Ultrix 4.0 (Rev. 179)

Every once in a while (every 3-4 days), the name daemon starts eating CPU
time, goes to the top of the queue, and fills the syslog error message
table with messages of the form

	Oct 22 10:23:37 localhost: 93 named: accept: Too many open files

(one a second, approximately) until it is killed and/or chokes /usr/spool.
Upon restart, it works fine.  There is no apparent flood of requests prior
to that.

Does anyone have a suggestion on how to approach the problem?

Thanks,
Michael Fingerhut
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Oct 90 09:41:31 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: 3c523 packet drivers -- what's the trick?
On Sun, 21 Oct 90 08:11:55 GMT <tcp-ip-relay@NIC.DDN.MIL> said:
>karl@naitc.naitc.com (Karl Denninger) writes:
>>We're trying to get a few PS/2s running with the packet drivers, and are
>>having no luck at all.  All we get is a "Timed out initializing board"
>>message...... and no function!
>
>I had the same problem last year.  I stumbled onto a work-around that
>you probably won't like. :-)  I found that if an old beta version of
>the driver was loaded, the machine warm booted and then the new version
>loaded, everything worked OK.  Great, eh?

Indeed 3c523_5 looks to have been included in release 7 for that purpose.
But one doesn't need to warm boot. TERMIN will do the trick.

>One must assume that some memory location is getting twiddled by one
>or the other but I never had time to run this one down.  If you find
>out what it takes to make the new ones work, I'd appreciate hearing.
>Since terminal emulation is about all a PS/2 is good for, I expect
>to run into a couple more someday.

I have traced the problem some day to occur during board RAM tests.
I have suggested that the cause is that the CPU can't accessed that RAM
until the chip is initialized, what's apparently done after RAM test.
Unfortunately, I haven't got a 523 any more.
Will someone who has one give Russ a help?

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD@BLIULG11 on EARN/BITNET
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 12:04:20 GMT
From:      bbn.com!craig@eddie.mit.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about SMTP MX records
In article <tim.656457948@ggumby> tim@ggumby.cs.caltech.edu (Timothy L. Kay) writes:
>Fine, but how do we get Silicon Graphics to provide a mailer that supports
>MX records?  Is there a way of putting pressure on them, such as being able
>to claim that their machines violate internet standards or somesuch?

    Any host which does not support MX RR's in the mailer is not
Host Requirements conformant.  See page 65 of RFC 1123.
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Mon 22 Oct 90 23:37:02-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        mcc@WLV.IMSD.CONTEL.COM
Cc:        jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
    I may have missed the point but doesn't a PUSH accomplish the same thing?
    [make TCP a datagram-oriented protocol]

Well, no.  A major part that is missing is a specification for the
interface between TCP and the next layer up (in ISO, this would likely
be a whole separtate document.)  In particular, if a receiver gets
two packets with PUSH set, the interface may put both packets in a
single buffer.  To quote RFC793:

    The exact push point might not be visible to the receiving user and
    the push function does not supply a record boundary marker.

Also, on the sender side, push does not preclude use of algorithms such
as slow start, Nagle, or re-packetization on retransmit.  (Hopefully,
a system using a datagram oriented protocol does not involve situations
where these are important (well, slow start would still be useful - you
just have to do it with datagrams rather than stream data))

Finally, TCP as is will send many datagrams if you present more than a
packet-sizes worth of data.  For a datagram oriented system, you would
force it to send a fragmented IP packets instead (and the maximum
segment size would have a slightly different meaning.)

The changes to any particular TCP to achieve a reliable datagram model
would not be significant, but it would take a little work.

BillW
-------
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 17:28:20 GMT
From:      phri!marob!slhisc!jlister@nyu.edu  (John Lister)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can One API Support Both TCP/IP and LU 6.2?


Interesting thought.  The answer seems to be that you could implement
something on top of RPC that would have similar functionality to LU6.2 for
particular applications.  Although IBM has been pushing LU6.2 as a commun-
ications panacea, in actuality, most implementations use it for transaction
processing, and the orientation is definitely towards Logical Units of Work
and the questions of atomicity that Distributed Transaction Processing raise.

I have been wondering about starting a project to look at writing an RPC 
interface for CICS Distributed Transaction Processing for some time but 
haven't actually done anything about it.  Is there anyone out there who has
already got their fingers wet?

John Lister.
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 20:40:07 GMT
From:      agate!bionet!synoptics!sblair@ucbvax.Berkeley.EDU  (Steven Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   *looking for implementations of RFC-1112*


I have several users who've recently become aware of RFC1112 written
by S.Deering of Stanford(1989) on Host Extensions on IP Multicasting.

We're reviewing the paper for possible interest. Questions are:

1) Has any router/bridge company done this? If not, are any
working on it.

2) Are there any networks supporting this at this time? Or in
the future?

3) Any more interesting comments you can add to this.

IP Multicasting, for those of you who'd like to know, is:

[quoting from the RFC]

"IP multicasting is the transmission of an IP datagram to a
"host group", a set of zero, or more hosts identified by a
single IP destination address".

The RFC112 goes into many unique details that could make this
a very flexible protocol to implement, and we'd like to know
more.

For those of of us with Internet DNS sites, dealing with
potential DNS forgeries, this could indeed offer an additional
level of complexity in the future, if many adopt it...


Please email:  craigj@synoptics.com & sblair@synoptics.com
--
Steven C. Blair		Network Operations Center
SynOptics Communications Inc. Mountain View, California
INTERNET: sblair@synoptics.com  sblair@excalibur.synoptics.com
PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com
***Bring Back The USENET Backbone/ARPA Backbone, NOW***
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 21:19:36 GMT
From:      dino!atanasoff!jacobson@uunet.uu.net  (Doug Jacobson)
To:        tcp-ip@nic.ddn.mil
Subject:   subnets

I have two general questions about subnetting in TCP/IP.

At Iowa State University we have a class B address and our
campus network consists of a four large bridged Ethernet segments
with a FDDI backbone used to connect these segments.  Some of the
segments contain IP Gateways.  The campus was using transparent subnetting
until about a month aao when the campus changed to unsubnetted.  The
Broadcast addresses and the Netmasks have been changed.
(Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask
changed from 255.255.0.0 to 255.255.255.0).  The questions I are:

1)  Should we have changed the campus to not support transparent subnetting
even though we do have some true subnets within our domain.

2)  How do other organizations with class B addresses set up their networks
and do they use transparent subnetting.

You can mail your responses to me at doug@isuee1.ee.iastate.edu
if there is enough interest I will post the results to question 2.
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 21:34:18 GMT
From:      cs.utexas.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@CS.YALE.EDU  (Mark Eggers)
To:        tcp-ip@nic.ddn.mil
Subject:   RPC interface across various platforms
Are there any commercial or public domain packages that will allow the
construction of a distributed application running on such diverse platforms
as IBM MVS/XA, VAX VMS, Macintoshes, PCs, and various BSD flavors of
UNIX?

thanks for any information - /mde/
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 90 22:12:38 GMT
From:      hplred!haddad@hplabs.hpl.hp.com  (R. Peter Haddad)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Need phone numbers...
cisco can be reached at 415 326-1941. They probably have an 800 number, but I
haven't a clue what it is. I'm suprised they haven't called you. They generally
read this notes group. You can also send mail to cs@clash.cisco.com, this is
genrally read by sales/technical people at cisco.


Good Luck.

Peter Haddad
HPLabs Network Engineering
(415) 857-5618
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 10:06:28 -0700
From:      jqj@hogg.cc.uoregon.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
I think we are being a bit ingenuous in assuming that the only reason one
might want "reliable datagrams" is to implement a sequenced packet protocol,
or that the only good way to get reliable packet delivery over IP is by using
TCP.  The current discussion does not, for example, address reliable broadcast
or any of a miriad of other real transaction-oriented applications for
reliable packet exchange where the cost of setting up a VC is prohibitive.
I would even go so far as to suggest that the lack of a standard RPX protocol
in the IP suite has inhibited development of reasonable applications that
would use it!

As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a
Xerox SPP-like protocol over TCP (message boundaries and message types are 
needed to implement the semantics of Courier).  As I recall, Eric just used
a simple counted string approach, where messages could span multiple strings
and end was delimited by an EOM bit in the message header, totally ignoring IP
packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM,
I suppose).  Worked just fine if what you wanted was packet boundaries on TCP;
no changes to TCP needed.
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 10:22:37 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        William "Chops" Westfield <BILLW@mathom.cisco.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
    ....
    Finally, TCP as is will send many datagrams if you present more than a
    packet-sizes worth of data.  For a datagram oriented system, you would
    force it to send a fragmented IP packets instead (and the maximum
    segment size would have a slightly different meaning.)

Given my druthers, I'd much rather make message boundaries independent
of IP datagrams, because deliberate fragmentation is EEEVIIILLL!!!.  Also,
you'll never hear the end of "why are records limited to 65Kb" and "why
can't I use records bigger than 8Kb on my FooNix system"?

  If you're willing to re-implement everywhere
    If you're willing to settle for 16 bits of record length
      Do something really gross with the Urgent pointer and unused bits in the
      TCP header.
    Else
      Define a new TCP Record Option as: opt_type, opt_len followed by 
      (opt_len - 2)/2 "start of record offsets within this segment".
  Else
    Define a formal "Record-Oriented TCP Extension" which uses header/length
    and let the applications that want it use it.  If enough of them do so,
    someone will move support into a library, and then someone else will put
    it in the kernel.  You could even use ISO Session and get ASN.1 data
    abstraction in the ?bargain?

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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 08:52:24 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        Steven Blair <sblair@synoptics.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Flexible, Host Extensions for IP Multicasting

Steve:

    I can answer some of your questions -- Steve Deering or David Waitzman
will presumably chime in to answer the rest.

> 1) Has any router/bridge company done this? If not, are any
> working on it.

    BBN and Stanford did experiments using Butterfly gateways about two
years ago.  We also did experiments with the publicly available multicast
code for BSD from Stanford.  (I don't know where the current multicast
code is on-line, however, it will appear in 4.4BSD).

    The experiments involved trying to do multicast routing over large
areas.  The answer is, you can do it, and SPF looks like the better base
on which to build.

Craig
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 10:28:14 PDT
From:      braden@venera.isi.edu
To:        BILLW@mathom.cisco.com, jbvb@ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
If you need records, you can build a trivial framing protocol on top
of TCP.  There have been many examples of this... Mike Muuss' PKG,
records in Sun's XDR, and Dave Clark's USP come immediately to mind.

Bob Braden



-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 03:31:32 GMT
From:      usc!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!melba.bby.oz.au!gnb@ucsd.edu  (Gregory N. Bond)
To:        tcp-ip@nic.ddn.mil
Subject:   Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
Well, on a similar note....

I understand James' and Jon's arguments.  Reliable datagrams are best
implemented with TCP and a "write(len); write(data);" layer.  I am
looking for something a little different.

Consider a net with a server and many (say, 100) workstations, and a
data feed that goes to each workstation.  At the moment, I have to
open 100 TCP streams, and so each packet of data generates 200 TCP
packets, all more-or-less identical.  What would be nice would be to
broadcast the packet to the local net, and have the clients request
missed packets, thus implementing a sort of reliable broadcast.

I would be happy for some sort of overhead for the reliability (e.g.
server broadcasts empty packets with the highest serial number once
every 10 seconds), but before I re-invent wheels, has someone done
something like this?

Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 13:42:55 -0500
From:      nancy@ftp.com  (Nancy L. Connor)
To:        fun@ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   French experience needed
Does anyone know what the following phrase translates to?

..but as they say in French ca me fait une belle jambe.

Thanks for any help.

	-Nancy


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 13:02 PDT
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Reliable Datagram ??? Protocols
> Given my druthers, I'd much rather make message boundaries
> independent of IP datagrams, because deliberate fragmentation
> is EEEVIIILLL!!!.  Also, you'll never hear the end of "why are
> records limited to 65Kb" and "why can't I use records bigger
> than 8Kb on my FooNix system"?

1000% correct.

>   If you're willing to re-implement everywhere
>     If you're willing to settle for 16 bits of record length
>       Do something really gross with the Urgent pointer and unused bits in the
>       TCP header.
>     Else
>       Define a new TCP Record Option as: opt_type, opt_len followed by
>       (opt_len - 2)/2 "start of record offsets within this segment".
>   Else
>     Define a formal "Record-Oriented TCP Extension" which uses header/length
>     and let the applications that want it use it.  If enough of them do so,
>     someone will move support into a library, and then someone else will put
>     it in the kernel.  You could even use ISO Session and get ASN.1 data
>     abstraction in the ?bargain?

And what do you do if you *need* to be able to abort a "packet"
send before it all makes it through?  Say I send a 16M "packet"
and change my mind in the middle (but don't want to close the
connection...).

For this you need some "out of band" alert and flush capability
-- TCP urgent data won't do it.  (Besides that's 16M of binary
data, I'd rather avoid scanning it for escape sequences...)
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 13:13:02 -0400
From:      jcurran@SH.CS.NET
To:        Merton Campbell Crockett <mcc@wlv.imsd.contel.com>
Cc:        BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET
Subject:   Re: Reliable Datagram ??? Protocols
>> I may have missed the point but doesn't a PUSH accomplish the same thing?  In
>> which case no modification is required.
   
"A PSH bit is not a record marker and is independent of segment boundaries."
"Passing a received PSH flag to the application layer is now OPTIONAL."
(RFC1122)

Work on a TCP extension for record information rather than taking 
a step back.. 

/John

Policy Routing, 2000: "Through the networks according to their abilities,
			to the applications according to their need."
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Tue 23 Oct 90 13:44:18-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        braden@venera.isi.edu
Cc:        jbvb@ftp.com, tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
    If you need records, you can build a trivial framing protocol on top
    of TCP.  There have been many examples of this... Mike Muuss' PKG,
    records in Sun's XDR, and Dave Clark's USP come immediately to mind.

Yes, yes.  This is not difficult, and is clearly the way to do things
within the framework of the currently defined protocols.  In fact, the
cisco routers do exactly this sort of thing for running X.25 over TCP.

Aesthetically, though, it bothers me to have to do the extra work of
converting datagrams to streams and back when the underlying transmission
scheme is almost certainly datagram based.  (Hmm, is anyone running TCP
over anything other than IP?)

BillW
-------
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 15:39:47 -0500
From:      bruce@128.127.2.105
To:        nancy@ftp.com
Cc:        tcp-ip@nic.ddn.mil, fun@ftp.com
Subject:   Re: French experience needed

>Does anyone know what the following phrase translates to?

>..but as they say in French ca me fait une belle jambe.

>Thanks for any help.

>	-Nancy

I think a literal translation is something like "that I make myself a
beautiful leg".  I am not sure what the colloquialism means.

Bruce

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 14:15:49 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Merton Campbell Crockett <mcc@wlv.imsd.contel.com>
Cc:        BILLW@mathom.cisco.com, jbvb@ftp.com, encore!zelig!jdarcy@husc6.harvard.edu, tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: Reliable Datagram ??? Protocols
The "push" flag, present on tcp packets has nothing to do with
reliabilty. It just says ' forwards what's in the receiving 
application buffer ' up...now !

It has nothing to do with Datagram or Reliabilty but is associated 
with fragmentation and re-assembly.

Additionally, most APIs don't make this flag user accessible; as a 
good working knowledge of systems and protocol(s) as they pertain
to overall response time and throughput is assumed for those who
massage this flag. It can result in overall system degradation in
a distributed compute environment is set inappropriately..

A final word on UDP...if I may:

 () Architecturally, UDP is the connection-less transport for IP.

    Reliability as in pertains to delivery and retranmissions is 
    the assumed burden of  associated HLPs (higer level protocols)
    or service(s) present. I did not write the protocol but did 
    enough implementations to state this as fact.

 () It is generally the protocol of choice when the transmisssion
    media has a low error rate or an HLP (e.g. interactive ) that
    compensates for deficiencies.
    

   George Williams

( The above are my own humble views and opinions and are not a 
  critique )
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 08:23:01 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: telnet problem
In article <9010230414.AA04281@ucbvax.Berkeley.EDU> KCPENG@TWNCTU01.BITNET writes:
>Hi,
>
>the following telnet problem appears after system has booted up a period
>of time:
>
>        % telnet xxx
>        Trying...
>        Connected to xxx.
>        Escape charcter is '^['
>
>then system hangs. It seems the remote telnetd has been connected, cuz the
>escape sequence is in effect. And likely this problem appears only in Sun
>W/Ss. Any hint is highly welcome.
>
>Kai-Chih Peng
>kcpeng@twnctu01

Actually, the above message indicates that the remote TCP has responded to
the request, not that telnetd has answered. Of course, the telnetd must
tell the TCP to open a port for listening (a "passive" port in TCP
terminology), but the telnetd doesn't print the above message. Instead, it
is the local telnet that desides that once the remote TCP has
responded, the connection is fully opened. The escape character mentioned
is actually handled by the local telnet, and doesn't have anything to do
with the remote telnetd server.
-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 13:34:49 EDT
From:      Phil Dykstra <phil@BRL.MIL>
To:        William Chops Westfield <BILLW@mathom.cisco.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols
> The changes to any particular TCP to achieve a reliable datagram model
> would not be significant, but it would take a little work.

It is easy to layer a reliable message protocol on top of TCP.  We
designed one such protocol at BRL call PKG (Package Protocol) and have
used it for several distributed applications over the past five years
(e.g. in BRL-CAD).  Messages have user defined "types" and both
synchronous and asynchronous message exchanges are supported.  At one
time a version of it even ran over DECNET, but our current code is
BSD socket library oriented only.  We should have written an RFC about
it years ago.

If anyone is interested they can look at brl-cad/pkg.shar.Z via
anonymous FTP on ftp.brl.mil (a.k.a. vgr.brl.mil, 192.5.23.6).

- Phil
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 13:59:48 GMT
From:      bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!bbn.com!craig@bloom-beacon.mit.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <GNB.90Oct23133132@leo.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes:
>Well, on a similar note....
>
>Consider a net with a server and many (say, 100) workstations, and a
>data feed that goes to each workstation.  At the moment, I have to
>open 100 TCP streams, and so each packet of data generates 200 TCP
>packets, all more-or-less identical.  What would be nice would be to
>broadcast the packet to the local net, and have the clients request
>missed packets, thus implementing a sort of reliable broadcast.

There's been some muttering over beers that this might be feasible in TCP.
If you think about the idea, it isn't so crazy.  To make sure the
workstations are in sync, you'll need some sort of windowing mechanism.
To be sure everyone has data, you'll need an acknowledgment scheme.
That's pretty close to the basic service TCP offers.

So if you could open a TCP connection to an IP multicast address, and
figure out how to handle the remote ends cleanly at the sender, you'd be
pretty far along.  (And 1 sending workstation gets, at worst, 100
acks from 100 receivers -- less if receivers ack every 2nd segment).
I believe Van Jacobson and Jon Crowcroft looked at this problem in
more detail and may well have something more to add.

Craig
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 14:47:14 GMT
From:      eru!hagbard!sunic!dkuug!daimi!pe!phl@bloom-beacon.mit.edu  (Per H Larsen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP on MS-DOS PC

I'm involved in a project where we want our Unix computer to function
as a server to some MS/DOS PC's. I want to write MY OWN applications
on the PC that communicates with the Unix server.
My plan is to do this in a TCP/IP - Ethernet enviroment so I'm looking
for Software that implements TCP/IP on a MS/DOS PC and additionally has
an Application Programmers Interface from C. Further I'm looking for a
realy good Ethernet controler for the PC's.

I have heard of Wollongong WIN/TCP but there must be other products ?

Has any one had experience with Wollongong WIN/TCP ? or any other product ?

Any product is of interest.

Please Email me directly. I'll send a summary to the net if there appers
to be any interest.

  ***************************************************************************!
 ! +-----------------------------------------------------------------------+ !
 ! +  Per Hyttel Larsen      ---       Telephone : +45-86 22 25 22         + !
 ! +  Purup Electronics     /---\      Facsimile : +45-86 22 25 11         + !
 ! +  Soenderskovvej 5     | . . |     Telex     :  68242 purel dk         + !
 ! +  DK - 8520 Lystrup     \ U /      Email     :  phl@pe.dk              + !
 ! +  Denmark                \-/       Uucp      : ...!dkuug!pe!phl        + !
 ! +-----------------------------------------------------------------------+ !
  *************************************************************************** 
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 15:33:02 GMT
From:      dsl.pitt.edu!pitt!elvis.cs.pitt.edu!field@pt.cs.cmu.edu  (Gus)
To:        tcp-ip@nic.ddn.mil
Subject:   UDP/IP over ether weirdness

I've got an application that would like to send the largest UDP packet
it can.  (sun3 - sun3 running 4.0.3 over 10MB ethernet).  The only
reference to max UDP packet size is in the RPC section where it says
the max size the UDP transport mechanism can handle is 8K bytes.
(sendto () does not return EMSGSIZE until I try to send >9000
bytes per datagram).  Anyway, when I send 8K byte packets, sendto ()
doesn't complain, but the packets never arrive at the receiver.  In
fact, if I attempt to send a datagram larger than 2048 bytes, it never
arrives at the receiver.  Running etherfind on a third machine, and
watching the traffic between the UDP src and dst's I see:

-----
2048 byte packet:

 1514  udp pebbles	 wilma		       1788       4343
* 610  udp

This datagram is delivered correctly to the destination application.
   
-----
2049 byte packet:

 1066  udp pebbles	 wilma		       1790       4343
* 611  udp

Now, something is definitely wrong here.  

-----


So, what is the limit on UDP size messages (besides the 16 bit length
field limit)?  Is 2048 bytes per UDP datagram the limit?

Thanks
Brian
-----
field@cs.pitt.edu
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 17:29:07 GMT
From:      hercules!frisbee.cisco.com!allan@apple.com  (Allan Leinwand)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Need phone numbers...
Hello all,

   If there are multiple copies of this around, sorry to waste the
bandwidth.  I fought the news reader and I think it won....

   The cisco 800 number for customer service is 1-800-553-NETS or
1-800-553-6387.

Thanks,

Allan Leinwand
cisco Systems
leinwand@cisco.com
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 15:56:40 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        William Chops Westfield <BILLW@mathom.cisco.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols

the world used to divide into 
datagram & virtual circuit

it now cuts many ways -

connection oriented versus connectionless is on dimension, but
reliability is another orthogonal issue ... some people would assert
that using a 'first' datagram to establish buffer allocation for an
entry in a router's tables to decide on who gets packets dropped is 
connection oriented ... it's just not reliable...on the other hand,
asking for the right TOS may insure reliability, even though the
packet format is datagram...

so i dont agree with jon postel...however, "reliable internet" may be
an oxymoron:-)

but seriously, 'reliable virtual circuits' is an oxymoron if you've
ever tries using (I)PSS...calls get ripped out with disconnection
reasons like 'congestion' , which doesnt sound too dissimilar from
routers dropping packets (except you have to wait a while longer
before sending your next packet - or do you - well prob. not if you
are running slow start x.25, now there's an idea:-))

jon crowcroft
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 18:09:16 GMT
From:      hplred!haddad@hplabs.hpl.hp.com  (R. Peter Haddad)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: subnets
/ hplred:comp.protocols.tcp-ip / jacobson@cs.iastate.edu (Doug Jacobson) /  2:19 pm  Oct 22, 1990 /

I have two general questions about subnetting in TCP/IP.

At Iowa State University we have a class B address and our
campus network consists of a four large bridged Ethernet segments
with a FDDI backbone used to connect these segments.  Some of the
segments contain IP Gateways.  The campus was using transparent subnetting
until about a month aao when the campus changed to unsubnetted.  The
Broadcast addresses and the Netmasks have been changed.
(Broadcast changed from 129.186.X.255 to 129.186.255.255 and the netmask
changed from 255.255.0.0 to 255.255.255.0).  The questions I are:

1)  Should we have changed the campus to not support transparent subnetting
even though we do have some true subnets within our domain.

2)  How do other organizations with class B addresses set up their networks
and do they use transparent subnetting.

You can mail your responses to me at doug@isuee1.ee.iastate.edu
if there is enough interest I will post the results to question 2.
----------

Doug :

Perhaps I am missing something here. Your broadcast address seems to have 
changed to accomodate a 0 length subnet field, therefore a 16 bit host field.
Your netmask however has been changed to allow an 8 bit subnet field, and
therefore an 8 bit host field. Am I misunderstanding the situation ?  What do
you mean by "transparent" subnetting ? 

Peter Haddad
HPLabs Network Eng.
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 19:22:46 GMT
From:      mips!ultra!rajiv@apple.com  (Rajiv Dhingra)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp delayed acks


I have a question regarding acks sent out by SUNs implementation
of TCP/IP.  
 
If SUNs TCP receives a data packet of 1024 bytes followed 
by a second data packet of 410 bytes, it sends an ACK packet
acknowledging the 1434 bytes immediately.
 
However, if it receives a data packet of 1024 bytes followed
by a second data packet of 409 bytes, it delays sending
an ACK packet for 200 milli-seconds.
 
The window that it advertises in both cases is 4096 bytes.
 
Under what cases does it decide to delay sending out
an ACK packet?
 
Thanx in advance for replies.
 
Rajiv Dhingra
  Ultra Network Technologies     domain: rajiv@Ultra.COM
  101 Daggett Drive            Internet: ultra!rajiv@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!rajiv
  408-922-0100
 
 
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 21:34:28 GMT
From:      pcg@cs.aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.nfs,sci.skeptic,comp.protocols.tcp-ip
Subject:   Re: New product announcement: NFSper

On 14 Oct 90 23:11:39 GMT, nelson@sun.soe.clarkson.edu (Russ Nelson) said:

nelson> ESP Software would like to announce their newest product,
nelson> NFSper.  NFSper is a NFS server with an order of magnitude
nelson> better performance than any existing NFS server.  NFSper uses a
nelson> proprietary technique to cache NFS requests on the client before
nelson> they are transmitted to the server.  Lab tests have shown that
nelson> the NFS packet are available on the client an average of 100
nelson> microseconds before the client sends the request.  Under test
nelson> conditions, we have observed packets a full 250 uSec before the
nelson> request transmission!

Such blatant advertising! Not to mention that the technology used by ESP
may be infringing on the original rights held by Prof.  Donald Knuth for
anticipative algorithms (the so called 'Pasadena street' style), as
described in ACP vol. 1, chapter on coroutines.

It is also true that Dr.  Isaac Asimov, the distinguished inventor of
tiotimoline, the intensional solvent, may have also a valid claim to
rights on anticipative technologies.

I cannot resist mentioning a major player in this market, which is
rumoured be on the verge of adopting 'not responding -- still trying' as
corporate trademark (unfortunately for them quick research has revealed
that many of its competitors have already adopted it, at least in
spirit), and maybe make a major product name change, something along the
lines of "Archeological File System".
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 90 04:59:28 -0400
From:      ah335@cleveland.Freenet.Edu (Richard Banks)
To:        tcp-ip@nic.ddn.mil
Subject:   Help


I would like to join this list if the moderator sees this please add me,
Thanks.
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 90 22:50:32 GMT
From:      pacbell.com!tandem!ernest@ucsd.edu  (Ernest Hua)
To:        tcp-ip@nic.ddn.mil
Subject:   QUESTION on how to set up reverse mapping for subnets
Here is an example of a net with a subnet:

                  |
                  |
             199.99.44.1
             199.99.55.1
                  |
  ----------------------------------
  |               |                |
  |               |                |
199.99.55.*  199.99.66.*      199.99.77.2
                                   |
                                   |
                              199.99.77.*

199.99.44.1 (inside address is 199.99.55.1) is the name server.  What if I
want to have, say 199.99.77.88, visible by reverse name resolution (address
to name mapping)?  What is the proper way to set things up?  Assuming that
I don't really want any other 199.99.77.* hosts to be visible via reverse
mapping, except maybe 199.99.77.2 (only if that's necessary).

Please E mail replies to ernest@tandem.com.

Thanks!

Ernest Hua
Tandem Computers
408-285-5580
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Oct 90 10:22 U
From:      <KCPENG%TWNCTU01.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   telnet problem
Hi,

the following telnet problem appears after system has booted up a period
of time:

        % telnet xxx
        Trying...
        Connected to xxx.
        Escape charcter is '^['

then system hangs. It seems the remote telnetd has been connected, cuz the
escape sequence is in effect. And likely this problem appears only in Sun
W/Ss. Any hint is highly welcome.

Kai-Chih Peng
kcpeng@twnctu01
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 90 09:46:06 -0400
From:      mankin@gateway.mitre.org
To:        stanonik@nprdc.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: 4.3bsd/watching icmp traffic
Ron,

We distribute a program that gets compiled into the 4.3 kernel and
lets applications read any or all IP traffic that is being forwarded.
It is called NETMON/iptrace.  The code and a document explaining
how it works and how to install it can be anonymously ftp'd
from aelred-3.ie.org (192.48.115.36): pub/netmon.tar or pub/netmon.tar.Z.
For your requirement, you would want to compile only the instrumented
ip_input.c.  Otherwise, follow the directions as given.  By the
way, the overhead of NETMON is about 5% or less, depending on the
packet arrival rate.  And iptrace uses CPU on the same order as the
gated executable.  

A. Mankin
mankin@gateway.mitre.org
MITRE-Washington Networking Center
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 90 14:12:32 -0500
From:      stev@ftp.com
To:        Bob Stewart <stewart@xyplex.com>
Cc:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]

>    3)      Fancy graphics.  Migrating from an early X window environment
>    to Motif doesn't buy the network manager a lot.  This has distracted
>    developers excessively.  But Motif is very pretty; witness the
>    Cabletron displays.  Nice pastels, shadows, pictures, etc.  Value?  To
>    be determined.  The people running the InterOp show network used ping
>    and traceroute a lot, but then they may be old fashioned.  :-)
    
>    
>            --Kent
    
 

wait a minute here.:) you could say that i had a prat in the Interop show
network. you could also say i was there for 95% of the debugging that went
on. while we used ping alot to debug the network, we also used SNMP often.
checking ARP caches and routing was a popular pastime, as was checking
interface status. the real story is *much* different than this simple 
statement implies, though.

SNMP was not used as much as it could have been for one simple reason. no
matter what people tell you, the tools currently on the market are not easy
to use. in general, the SNMP tools that got used most were the ones that had
people who knew how to use them there to use them. personally, i used
command  line tools (like ping, tracert, and get), because that was what i
knew how to use. one of the press people who talked to me asked me which of
the SNMP monitors i liked best. i told him it was none of his business,
since he should form his own opinions, but the *real* answer was that i was
too busy to learn how to use *any* of them (with one exception, the command
line tools were easy enough to use).

if we are talking about what tools need, allow me to enlighten you for a
moment. from my experience at interop, i can tell you some interesting things.

1) SNMP is useless if the network doesnt work. large monitoring stations
with great graphics are useless if they are not connected to the network. a
small, command line of character based tool would have been more useful,
since it could have been toted around on a portable to the sections of the
network that worked.

2) SNMP graphics tools are useless if they provide too much information on
the screen. this may have been a configuration problem, but most of the
screens were *so* crowded, that a significant amount of time was used trying
to find the node you wanted to query, so you could click on it.

3) maybe i am too anxious, but i also dont like tools that make me click on
several things before i can query a router. lord forbid that the name
resolution calls are blocking, and lock the window, so i cant kill it and
try an IP address.

4) none of the tools seemed smart enough to figure out that their router
went down, and that was why everything was failing. no one pinged the router
they were using when things started to rapidly fail, to see if they had
become isolated.

5) few, if any, of the tools seemed to back off to ping to see if a machine
was there. sooo, non-snmp machines status could not be checked, even to a
rough approximation.


basically, SNMP was useful, but the functionality needed for dealing with a
network in the process of being brought up and configured was not there.

too bad so few of the people who are trying to sell products into this
market tried to help us fix our problems to see how to make their tools
better. i hope the people that did show up took notes, there are alot of
things that could have been changed to make life easier. larger, more
computionally intensive applications are not, in my opinion, the only place
to be spending more resources. portable tools are going to remain vaulable
for a long time, campers . . . . . . 

stev knowles


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 05:54:42 GMT
From:      att!emory!samsung!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!bison!jamesp@ucbvax.Berkeley.EDU  (James Pinakis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
Maybe I've missed something here, but what happens if you have multiple
entities which want to send datagrams between each other, and it may be
the case that only one datagram is sent between any given pair.
In this case, isn't the overhead of establishing a TCP connection merely
to send one "datagram" (or "data which preserves message boundaries" or
whatever the pedants like to call it) too great?  Isn't this the exact
situation when a different protocol is required and building a scheme on
top of TCP is bad?  And if I don't _want_ a connection between two sites
(i.e. I only want to send discrete messages) then why should I create one,
send the data, and then pull it down?

I agree that such a protocol is not really connectionless and that state must
be maintained at both ends, but at least from the application layer (assuming
it's implemented as a transport layer protocol) it _looks_ like I am
reliably sending datagrams.  I've spend some time over the last few months
implementing just such a protocol.  Basically it is a fairly straightforward
implementation of a sliding window protocol (protocol 6 from Tanenbaum
actually) optimised to support a particular sort of client/server model.
The main thing which it has over TCP, I believe, is that establishing the
state information is sufficiently "lightweight" so that the cost of
a client sending a small number of packets to a server is not prohibitive.

james
jamesp@bison.cs.uwa.oz.au
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 08:33:26 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <60282@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM
(Craig Partridge) writes:
+---------------
| So if you could open a TCP connection to an IP multicast address, and
| figure out how to handle the remote ends cleanly at the sender, you'd be
| pretty far along.  (And 1 sending workstation gets, at worst, 100
| acks from 100 receivers -- less if receivers ack every 2nd segment).
+---------------

XTP multicast receivers send the ACKs to the multicast address too, which
allows for something the XTP spec calls "damping" (which I prefer to call
"stifling"). If receiver "A" hears another receiver "B" emit an ACK with
"worse" news than what "A" was going to ACK, then "A" "damps" its ACK
(stifles itself, stays quiet).

A helpful related feature is "slotting", wherein a receiver delays a random
amount of time before sending an ACK, in the hopes that someone else will
send "worse" news and it can stifle itself.

Damping/slotting are optional features in XTP; with a small number of
receivers, they have some negative throughput implication due to the
increased delay on the ACKs and the (slightly) increased overhead of
running the damping algorithm. But with very large numbers of receivers
they can save a good bit of network bandwidth. What would otherwise be
a large burst of ACKs (one from every station) is replaced by a much
smaller flurry of ACKs, each one bearing "worse news" than its predecessor.
The sender retransmits based on the "worst news" (lowest ACK number) heard
during each epoch of ACK-gathering (called "buckets", in the XTP spec.)

And all this works in the absence of a reliable group-membership protocol.
However, in order to avoid "leaving a receiver behind", you have to extend
your retransmission buffers and ensure that you get "enough" epochs of
ACK-gathering (enough "buckets") so that the probability of losing "too many"
consecutive ACKs from the receiver with the worst news is "as low as you like".
But increasing the number of epochs per unit time increases the number of ACKs,
and thus the network overhead. (*sigh*) [The tradeoffs between retransmission
buffer size, ACKs per RTT, and probability of losing a receiver are discussed
in detail in "Appendix B" of the "XTP Protocol Definition, Revision 3.5".]

Anyway, as Vernon Schryver mentioned, it certainly *ought* to be be possible
to graft the XTP/multicast "bucket algorithm" onto TCP + IP/multicast...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 09:43:29 GMT
From:      mcsun!ukc!pyrltd!root44!hrc63!fddi@uunet.uu.net  (FDDI Group (Ian Wakeman - A26))
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <GNB.90Oct23133132@leo.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes:
>I would be happy for some sort of overhead for the reliability (e.g.
>server broadcasts empty packets with the highest serial number once
>every 10 seconds), but before I re-invent wheels, has someone done
>something like this?
>Greg.
although it may be heresy to say it in this group, XTP has some reliable
multicast features inside of it, although I doubt whether they've been
tested on a WAN, and claiming reliable multicast without group management
facilities is a trifle absurd - how do you know that all possible respondees
have replied? (Yes, I know that group management is then delegated to the
session management :-)

ian
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 1990 15:43 EDT
From:      Andy Hooper <HOOPER@QUCDN.QueensU.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
If you look closely at RFC 1006 (ISODE transport service on TCP), and strip
out all the stuff about TPDUs, what's left is a record boundary protocol for
TCP. It basically just puts a byte count in front of each "record" (or NPDU
in the ISODE context).
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 90 10:50:50 BST
From:      J Jackson <jj@dcs.leeds.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   WANTED: bootpd (RFC951) source
Can anybody point me to  a public copy of a bootp daemon for Unix
- by preference System V (if it makes any difference).

Cheers

Jim Jackson
School of Computer Studies	       JANET Email: jj@uk.ac.leeds.dcs
Leeds University                          INTERNET: jj@dcs.leeds.ac.uk
Leeds					     Phone:     +44 532 335451
LS2 9JT

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 12:27:02 GMT
From:      otter.hpl.hp.com!otter!gcaw@hplabs.hpl.hp.com  (Greg Watson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: French experience needed
It's a familiar way of saying

".... it might be interesting to you, but it's of absolutely no interest to me"

-Greg
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 13:04:57 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   router tests V.3 - PS
oops - a few things about the router testing posting

the correct name for the "Proteon RIG" is the "Proteon XP 20000"

the "fld" on the table is the "raw" rate (i.e. frames input at the
maximum rate that the test equipment can produce)


and here is the delay values (I seem to have missed one of the cisco
cases - sorry)

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

3com NETBuilder - delay

size	min	avg	max
64	.2	.21	.25
128	.2	.21	.25
256	.2	.21	.25
512	.2	.21	.25
1024	.2	.21	.25
1518	.2	.21	.25

BBN T20 - delay

size	min	avg	max
64	.2	5	10
128	.2	5	10
256	.2	5	10
512	.2	5	10
1024	.2	5	10
1518	.2	5	10

NSC between - delay

size	min	avg	max
64	.41	.41	.42
128	.5	.5	.6
256	.5	.5	.6
512	.5	.55	.6
1024	.5	.55	.6
1518	.5	.55	.6

NSC - within - delay

size	min	avg	max
64	.21	.21	.21
128	.22	.22	.22
256	.24	.24	.24
512	.25	.25	.25
1024	.25	.25	.25
1518	.25	.25	.25

Novell NetWare - delay

size	min	avg	max
64	.5	.55	.6
128	.55	.58	.62
256	.6	.625	.65
512	.62	.65	.7
1024	.78	.8	.82
1518	.8	.85	.9

Timeplex TIMELAN - delay

size	min	avg	max
64	.15	.15	.15
128	.15	.15	.2
256	.18	.18	.25
512	.2	.2	.3
1024	.2	.2	.3
1518	.28	.28	.28

Wellfleet - between - delay

size	min	avg	max
64	.4	.4	.41
128	.41	.41	.42
256	.42	.42	.42
512	.5	.5	.51
1024	.59	.59	.6
1518	.65	.65	.68

Wellfleet - within - delay

size	min	avg	max
64	.28	.28	.28
128	.28	.28	.28
256	.28	.28	.28
512	.28	.28	.28
1024	.28	.28	.28
1518	.28	.28	.28

cisco - within - delay

size	min	avg	max
64	.8	.8	.8
128	.8	.8	.8
256	.8	.8	.8
512	.8	.8	.8
1024	.8	.8	.8
1518	.8	.8	.8
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 13:08:00 GMT
From:      sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu  (Nathaniel Mishkin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <9010221418.AA03839@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes:
>So, every time this came up in the past, the next stage was to ask the
>person looking for a "reliable connectionless protocol" or somesuch what
>was really needed.  The most frequent goal has been some sort of transport
>for a little machine, or a new one for which there is no networking
>software yet.  The searcher doesn't want to implement all of TCP, and sees
>"datagrams" as being easier, particularly on a single Ethernet.  Another
>common goal has been to get very high throughput by avoiding the "excessive
>overhead" of TCP, but Van Jacobsen's research has more or less laid that
>one to rest.  A third one has been "preservation of message boundaries".

Good summary.  Having made the mistake (no doubt through initial
fuzzy-headedness on my part), of having built an RPC system whose protocol
I called "datagram-oriented" (and which I now call "connection-oriented,
but designed with the knowledge that RPC is the application that wants
to use it" -- at least to people who might understand what I mean), I
try to be very careful when I say "datagram" these days.

Anyway, one other goal of some people in search of something other than
TCP is the reduction in the number of network messages that need to be
exchanged for short-lived connections (which often occur when you're
doing RPC), in particular eliminating some of the connection setup and
tear-down messages.  E.g., for the purposes of RPC, it sure would have
been nice if I could do something like send data (i.e., the remote call's
input parameters) in a SYN.  (I've never seen an implementation that
allows this; I can't point to the place in the TCP spec that disallows
it, but I imagine it is disallowed.)  Maybe it's not really so bad to
have the number of control messages be more than the number of
data-carrying messages in case I make one remote call to a server, but
my assumption is that the overall system will behave better if the number
of control-only messages is reduced.

--
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 13:10:07 GMT
From:      mcgill-vision!clyde.concordia.ca!ganymede!bussiere@bloom-beacon.mit.edu  (Luc Bussieres)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: French experience needed
>>Does anyone know what the following phrase translates to?
>>..but as they say in French ca me fait une belle jambe.
>>Thanks for any help.
>>	-Nancy
>
>I think a literal translation is something like "that I make myself a
>beautiful leg".  I am not sure what the colloquialism means.
>
>Bruce
A more correct literal translation would be "That make me a beautiful
leg". The meaning is "we really don't care about it"


-- 
Luc Bussieres ---- Analyste - Dep. de Mathematiques et Informatique
Universite de Sherbrooke     
Internet : bussiere@dmi.usherb.ca
Tel: (819) 821-7981
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 14:57:05 GMT
From:      amgraf!cpsolv!psp!loethen@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   TOKEN RING VS ETHERNET
X-NEWS: psp comp.dcom.lans: 425

GREETINGS TO ALL ON THE NET.  

FIRST, PRELIMINARIES.  I AM POSTING THIS TO COMP.SYS.DEC,COMP.PROTOCOLS.TCP-IP, 
& COMP.DCOM.LANS. OUTSIDE IF THAT, CROSS-POST TO WHAT EVER YOU THINK MIGHT BE 
HELPFUL.
ALSO, PLEASE ANSWER VIA EMAIL.  MY NEWS FEED IS SPOTTY AND OCCASIONALLY 
UNRELIABLE.


I HAVE HELPED SPECIFY AND TEST A ETHERNET - TCP/IP NETWORK TO PROVIDE
BROADBAND CONNECTIVITY FOR A DEPARTMENT CONSISTING OF DEC (WORKSTATIONS, 3100
AND 3800), TANDEM AND PCS (AT AND MC BUS).  AS WE HAVE COMPLETED THE TESTING
OF THIS SYSTEM AND WERE MAKING PREPERATIONS TO PURCHASE SAID HARDWARE AND 
SOFTWARE, OUR CORPORATE SUPPORT GROUPS HAVE ASK US TO RE-EVALUATE OUR DECISIONS
AND ANALYZE WHAT IT WOULD TAKE TO MAKE THIS A TOKEN-RING NETWORK INSTEAD 
(RUNNING NOVELL ON THE RING FOR PCs).


SOME FACTS:

WE NEED FILE SHARING, REMOTE LOGIN, REMOTE BACKUP, PRINTER SHARING, TERMINAL
EMULATION (OBVIOUSLY) AND EVENTUALLY, REMOTE PROCEDURE CALLS.

THE COMPANY GOAL IS TO MIGRATE TO OSI

THERE ARE ALREADY TWO LARGE (75-100) TOKEN RINGS IN THE COMPANY, RUNNING NOVELL
AND PROVIDING CONNECTIVITY FOR PC TO THE IBM MAINFRAME.


QUESTIONS:

IS THIS A VIABLE SOLUTION (USING TOKEN RING)?  HOW MIGHT IT BE DONE?

IF T/R IS NOT A BETTER SOLUTION, WHAT ARE SOME REASONS THAT MIGHT SUPPORT THE
ETHERNET TCP/IP SOLUTION?



I HAVE DONE SOME CHECKING INTO THIS, OF COURSE, BUT I COULD USE SOME FEEDBACK
ON DIRECTIONS OR ALTERNATIVES I HAVEN'T THOUGHT OF YET.

THANKS AGAIN. 



-- 
*******************************************************************************
* Shelly Loethen		*  "Only By Attempting the Absurd,	      *
*                       	*        Can We Achieve the Impossible"	      *
*=============================================================================*
* ...uunet!amgraf!brian386!swl386!shellyl // loethen@psp.psp.com	      *
*******************************************************************************
* Disclaimer:  "My opinions are my own, thank you!"			      *
*******************************************************************************
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 15:03:04 GMT
From:      mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!verber@bloom-beacon.mit.edu  (Mark Verber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: WANTED: bootpd (RFC951) source
There is a bootp daemon (bsd 4.3) for anonymous ftp on the machine
lancaster.andrew.cmu.edu in the directory /bootp.

Cheers,
Mark
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 15:11:12 GMT
From:      mintaka!ogicse!plains!tinguely@bloom-beacon.mit.edu  (Mark Tinguely)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: named going into an infinite loop ...
In article <1990Oct22.105209.28006@ircam.ircam.fr> mf@ircam.fr (Michel Fingerhut) writes:
>Machine: DECsystem 5820 (RISC)
>OS:      Ultrix 4.0 (Rev. 179)
>Every once in a while (every 3-4 days), the name daemon starts eating CPU
>time, goes to the top of the queue, and fills the syslog error message
>table with messages of the form
>	Oct 22 10:23:37 localhost: 93 named: accept: Too many open files


 Do you have machines that queries the name server by TCP rather than
 UDP? This can be found by using `netstat'. We had the same problem with
 a IBM 3090 querying our the BIND 4.8.1 (and earlier releases) nameserver.
 I am sure the Ultrix server is based upon BIND 4.8.

 About 7 months ago I posted the fix to this problem, and (though I did
 not check), I think a simular fix went into BIND 4.8.2. There are two
 problems, but both are based on the fact that TCP queries are queued.
 It is possible with the orginal BIND code, that these queries are not
 properly released as they sit waiting on a time queue. UDP resolutions
 are just discarded if they can not be resolved right away, and do not
 cause this problem.

 If you do not want to update your nameserver to BIND (boy did I find out
 this week how many people think I am a radical for running public-domain
 software [that works correctly]), then ask at DEC to update the server.

 Last week I removed my "diff" files for the BIND error (assuming these
 were picked up in BIND 4.8.3 located at ucbarpa.berrkeley.edu in the
 4.3 directory). I just quickly scanned the areas that I modified in
 the BIND 4.8.3 files and did not see the removal of queued TCP entries,
 but since I don't follow the BIND mailing list, they may have implemented
 the solution in a different fashion than I did (or did not pick the changes
 at all). If there is a need for the TCP BIND fixes, I can restore them
 to our anonymous ftp partition.
-- 
Mark Tinguely           North Dakota State University,  Fargo, ND  58105
  UUCP:       		...!uunet!plains!tinguely
  BITNET:      		tinguely@plains.bitnet
  INTERNET:   		tinguely@plains.NoDak.edu
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 15:44:22 GMT
From:      princeton.edu!tengi@princeton.edu  (Christopher Tengi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: telnet problem
Do you eventually get the login prompt?  I have seen this type of thing happen
when telnetting to Suns from a machine whose IP address cannot be resolved into
a name using a DNS lookup.  Basically, if I am telnetting from 128.112.129.118,
the machine I am telnetting into cannot get an answer when it tries to look up
118.129.112.128.in-addr.arpa in the domain name system.  Might this be the
problem you are having?

					/Chris

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Oct 90 15:48:50 WET DST
From:      Ian Heavens <ian@spider.co.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   ttcp

What are the copyright issues with ttcp?  Are vendors permitted to
distribute it with their software?  We would like to do this.

If Mike Muus (the author) reads this, or anyone knows his email address,
please email me.

Thanks.
 
Ian Heavens	
Spider Systems Limited
Spider Park, Stanwell Street
Edinburgh, EH6 5NG, Scotland
+44 31 554 9424 (Ext 4166)

ian@spider.co.uk                 
ian%spider.co.uk@uunet.uu.net
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 18:38:14 GMT
From:      mtxinu!rtech!wrs!hwajin@ucbvax.Berkeley.EDU  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <9010231706.AA25446@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes:
>As an aside, 4.2bsd included Eric Cooper's courier compiler that implemented a
>Xerox SPP-like protocol over TCP (message boundaries and message types are 
>needed to implement the semantics of Courier).  As I recall, Eric just used
>a simple counted string approach, where messages could span multiple strings
>and end was delimited by an EOM bit in the message header, totally ignoring IP
>packet boundaries, PUSHes, etc. (you have to guarantee a PUSH after the EOM,
>I suppose).  Worked just fine if what you wanted was packet boundaries on TCP;
>no changes to TCP needed.

pretty much the same thing is done with sun rpc over tcp.  the following
is from sunrpc 4.0 release:

/*
 * xdr_rec.c, Implements TCP/IP based XDR streams with a "record marking"
 * layer above tcp (for rpc's use).
 *
 * These routines interface XDRSTREAMS to a tcp/ip connection.
 * There is a record marking layer between the xdr stream
 * and the tcp transport level.  A record is composed on one or more
 * record fragments.  A record fragment is a thirty-two bit header followed
 * by n bytes of data, where n is contained in the header.  The header
 * is represented as a htonl(u_long).  Thegh order bit encodes
 * whether or not the fragment is the last fragment of the record
 * (1 => fragment is last, 0 => more fragments to follow.
 * The other 31 bits encode the byte length of the fragment.
 */


-- 
hwajin@wrs.com
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 19:31:06 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bbn.com!papaya.bbn.com!rsalz@ucsd.edu  (Rich Salz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In <GNB.90Oct23133132@leo.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes:
|Consider a net with a server and many (say, 100) workstations, and a
|data feed that goes to each workstation.  At the moment, I have to
|open 100 TCP streams, and so each packet of data generates 200 TCP
|packets, all more-or-less identical.  What would be nice would be to
|broadcast the packet to the local net, and have the clients request
|missed packets, thus implementing a sort of reliable broadcast.

I believe this is what the ISIS distributed programming environment provides.

Write to ken@gvax.cs.cornell.edu for more info, or read the Usenet newsgroup
comp.sys.isis.

	/rich $alz
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 19:57:38 GMT
From:      smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy)
To:        comp.protocols.tcp-ip
Subject:   Intelligent bridges vs. routers

I was just asked by an officemate of mine what the disadvantages of
using an intelligent bridge over a dedicated router would be.  We
have about 20 SPARCstation 1s on a subnet, and another bunch of PCs
and things on another subnet.  Since most of the traffic on these
two subnets is local to their segment, what problems would we
encounter by removing the dedicated routers and replacing them with
intelligent bridges?  It would keep the local traffic local, but
I know we would be vulnerable to broadcast storms.  The company is,
of course, interested in cost-savings.  So what are the downfalls?

Thanks for your help.

Kevin Ruddy
smiles@ferrari.nmc.ed.ray.com

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 22:44:03 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Datagram ??? Protocols


>Aesthetically, though, it bothers me to have to do the extra work of
>converting datagrams to streams and back when the underlying transmission
>scheme is almost certainly datagram based.  (Hmm, is anyone running TCP
>over anything other than IP?)
>
>BillW

But it's orders of magnitude easier than trying to add reliability
(and performance, once you've added that reliability) to UDP or
similar. All you basically need is to add a count field to each
"packet" if you put it over TCP.

(One can get fancier, depends on the real need of the application,
originally I think all that was asked was that a write of X bytes at
this end can be turned into a read of X bytes at the other end, record
boundaries, that's trivial over TCP as it's all sequenced and reliable
already.)

-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 23:02:38 GMT
From:      wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@decwrl.dec.com  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: French experience needed
My excellent French-English translator's dictionary suggests the
phrase

	a fat lot of good it does to me!

with a small note that this is "informal usage" in both languages.

I wouldn't use either expression, however.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427
--
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 90 23:47:50 GMT
From:      hercules!frisbee.cisco.com!allan@apple.com  (Allan Leinwand)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Intelligent bridges vs. routers

I can think of a few downfalls other than broadcast storms:

   1.  an intelligent bridge will not separate your address space like a
router.  Thus, your two subnets will exist on one logical LAN.  This
may result in configuring routers to understand this situation.

   2.  a bridge will not allow you to control the network for security
reasons as well as a router if you are running multiple protocols (such
as IP and DECnet).  With a bridge all of your security control is usually
based upon the MAC level address of a host.  Keeping up with boards
swaps and changing MAC addresses can become a configuration nightmare.
With a router, the security can usually be setup to understand the
network protocol level addresses.  This usually makes security
management a bit easier.

   3.  dare I say this?  With many routers having SNMP agents, this
gives you a basis for network management.  Yet, (contradicting myself
:-)) some bridges now answer SNMP.

   4.  the cost of a low end, two port router (which has router
functionality AND bridge functionality) may surprise you....

Thanks,

Allan Leinwand
cisco Systems
leinwand@cisco.com
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 00:14:49 GMT
From:      qualcom.qualcomm.com!edmund@ucsd.edu  (The Silver Surfer)
To:        tcp-ip@nic.ddn.mil
Subject:   POP3 client for a pc
Does anybody know of a POP3 client for the pc?
It would be nice to have one that works with the Clarkson Packet Drivers, or
with FTP software's PC/TCP.

Thanx
-- 
	-------  /  /  /-----
          /    /--/   /---
        /    /  /   /-----
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 01:14:41 GMT
From:      ucselx!sol.ctr.columbia.edu!samsung!umich!umeecs!msi.umn.edu!cs.umn.edu!dmshq!com50!kksys!jhereg!imp@ucsd.edu  (Charles T. Lukaszewski)
To:        tcp-ip@nic.ddn.mil
Subject:   DECnet & IPX
In article <1990Oct19.120616@ria.ccs.uwo.ca> peter@ria.ccs.uwo.ca writes:
>While DECnet IV wants to change the ethernet number to match the DECnet node
>and host number, IPX only requires the same ethernet number to be used on all
>interfaces to a machine.  It doesn't care what they are set to.  This allows
>DECnet and IPX to  coexist on the same router as long as you get the DECnet
>running first and then start the IPX.

This is correct, but does not guarantee coexistence.  Remember that all VAX
Ethernet controllers are Version 2 devices, NOT 802.3 devices.  Netware, on
the other hand, DEFAULTS to 802.3 operation.  While you can certainly run
both protocols simultaneously on the same cable, if you want to gateway the
two environments, you have to backpatch the IPX card drivers with a utility
called 'econfig.'  Basically, econfig allows you to select whether you want
your Novell net to run using Ethernet Version 2 (type field IPX=8037) or
802.3 (length field).

This gets at a topology issue, because to avoid losing sight of your servers,
you need to econfig every station on a given subnetwork.  A quicker solution
may be to put DEC devices on their own net hanging from a Netware server,
and simply econfig just the card in the server.  The Netware server, acting
as a bridge, will deal with the differences internally.

-- 
_______________________________________________________________________________
Charles T. Lukaszewski            imp@osa.com                      612 525-0000
Managing Partner & Chairman                       Open Systems Architects, Inc.
 "Who needs a disclaimer? I liked the opinions so much, I bought the company!"
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 09:40:13 pdt
From:      Walter Underwood <wunder@hpsdel.sde.hp.com>
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
I'm surprised that no one has mentioned Cornell's ISIS system.  ISIS
is a reliable multicast system with ordering guarantees.  The hard
part about multicast designs is not the protocol, but proving that the
resulting system behaves correctly.  ISIS provides a choice of
orderings; two of the choices are causal ordering within the process
group and causal ordering across all groups.

This ordering makes designs much, much simpler.  If you are already
guaranteed that processes will see the same messages in the same
order, then any deterministic calulations will get the same result.
Notification of failures in the process group (or processes joining or
leaving) are ordered like other messages.

For more info, see the newsgroup comp.sys.isis, or send mail to Ken
Birman (ken@cs.cornell.edu).  The ISIS code is available, and runs on
LOTS of systems.

wunder

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 09:53:42 PDT
From:      braden@venera.isi.edu
To:        sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols

	Anyway, one other goal of some people in search of something other than
	TCP is the reduction in the number of network messages that need to be
	exchanged for short-lived connections (which often occur when you're
	doing RPC), in particular eliminating some of the connection setup and
	tear-down messages.  E.g., for the purposes of RPC, it sure would have
	been nice if I could do something like send data (i.e., the remote call's
	input parameters) in a SYN.  (I've never seen an implementation that
	allows this; I can't point to the place in the TCP spec that disallows
	it, but I imagine it is disallowed.) 
	
Nat,

It certainly is NOT disallowed, and all of the early research TCP's
tried to support it.  A favorite test in "bake-offs" was to send a
"Kamakazii packet", with SYN, data, and FIN all in one segment.  Not
all TCP's survived the test, but some did...  However, sending data with
the original SYN (sic) is not a big win because a full 3-way handshake
is necessary before the data can be passed to the receiving
application.  Other protocols, e.g., delta-T and VMTP, use a timer-based
mechanism to avoid 3-way handshakes; this leads to what is commonly
called a "transaction transport protocol" (see RFC-955).

Bob Braden
 

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 11:53:55 -0400
From:      aggarwal@nisc.jvnc.net (Vikas Aggarwal)
To:        stev@ftp.com, stewart@xyplex.com
Cc:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
>> SNMP was not used as much as it could have been for one simple reason. no
>> matter what people tell you, the tools currently on the market are not easy
>> to use.

Another fact is that systems supporting SNMP do not consider snmp as a
high priority task- as a result I have  routers that do not respond to
SNMP  is they are busy passing  traffic. As a  consequence, during the
better parts of  most afternoons, I would  have sites change status to
"unknown" or "down" all the time because the routers would not respond
to SNMP.

Now, if I use dear old fashioned "ping", to quote from Comer:

 ' Because the destination machine's Internet software handles ICMP,
   it is usually possible to obtain an echo even if the machine is
   overloaded'.

I do realize  that an overloaded  router should be  addressed, but  if
SNMP  could  gaurantee me a  reply if a router  was UP  and doing  its
primary funtion, I would stop  using ping to  monitor our routers  and
pay *serious* attention to snmp based  monitoring programs, as opposed
to *saying* I use   SNMP to prove  that  I  am  in sync with   the new
technologies that exist.

That is to say, is there  someone out  there who relies *only* on SNMP
to monitor the net ? Or will  'ping' be used as  a monitoring tool for
the rest of IP's life ?


-vikas
vikas@nisc.jvnc.net					(609) 258-2403
Network Engineering
			JvNCnet, Princeton, NJ
-----------------------------------------------------------------------------
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 13:45:48 -0500
From:      "Craig A. Finseth" <fin@unet.unet.umn.edu>
To:        aggarwal@nisc.jvnc.net
Cc:        stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
   I do realize  that an overloaded  router should be  addressed, but  if
   SNMP  could  gaurantee me a  reply if a router  was UP  and doing  its
   primary funtion, I would stop  using ping to  monitor our routers  and
   pay *serious* attention to snmp based  monitoring programs, as opposed
   to *saying* I use   SNMP to prove  that  I  am  in sync with   the new
   technologies that exist.

   That is to say, is there  someone out  there who relies *only* on SNMP
   to monitor the net ? Or will  'ping' be used as  a monitoring tool for
   the rest of IP's life ?

I see no reason why it is desirable to stop using ping (or, more
precisely, the ICMP Echo mechanism).  Most checking just wants to know
"are you there" and the ICMP Echo mechanism does that with much less
overhead than SNMP ever could.

For example, the network monitoring here at the U uses ICMP Echo for
most checking, reserving SNMP for those "higher level" tasks such as
checking routing tables and interface configurations.  The software
also knows not to perform the higher level checks unless the device is
known to be up.  (It also knows not to check hosts behind a down
router, but that is not related to SNMP).

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 625 0006 problems
130 Lind Hall, 207 Church St SE		+1 612 626 1002 FAX
Minneapolis MN 55455-0134, U.S.A.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 12:49:44 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Mark Eggers <cs.utexas.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@cs.yale.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: RPC interface across various platforms

Sorry if this is received more than one time...problem in original parse
of your addr. Ditto for cc: list.



This is the $64k question.....

Are there any commercial or public domain packages that will allow th
e
construction of a distributed application running on such diverse pla
tform as.....

>>> While most of the aforementioned have solutions that are designed 
>>> for distributed computing environments most of them tend to
>>> be product-based, perhaps by design. That is there is no "one"
>>> technical solution to the problem as stated; that of a generic
>>> application programming interface for distributed computing
>>> environments that every one uses to make the same calls on 
>>> any machine.( the OS may accomplish this before the API's )

>>> This is where most vendors seem to be drawing the line in the
>>> sand as to which side of the open computing fence they stand
>>> (straddle) on and probably for good reason; it will be the
>>> one that keeps software from becoming a commodity ( oops ).

>>> The good news is that everyone is making an effort to talk
>>> to everyone else. The other side of the coin is "what can be
>>> said" i.e. what application functionality can you access without
>>> buying a specific API for you machine .

>>> The companies moving in the direction of "common APIs and  open network
>>> toolkits" have the jump on the rest of the pack. This the area
>>> where the biggest gains are to be made not just dollar-wise
>>> but in the are of engineering and programming productivity. It
>>> is becoming clear that the "one" solution for a generic RPC
>>> will have support for many Application Program Interfaces. Suggested
>>> system analysis, prior to making a strategic choice.

>>> IBM MVS/XA - solutions under an SAA/CPI umbrella
>>> VAX VMS    - ditto OAA
>>> Macintoshes- MAC everything (smile)
>>> PCs        - VINES,NETWARE,NETBIOS,APPC,LU.6.2
>>> BSD flavors- Take your pick from SUN,etc's ONC to OSF(oops Mach)
>>>              et al DCEs and see below.
>>> UNIX?      - appears to be the LCD when choosing, to date.
>>>              common API/RPC  running under this will probably have
                 broadest base with respect to mix and match
                 capabilities and ease of implementation..

>>> Note: I have seen proprietary solutions that are nice...in fact so nice
>>>       elements of them will make it into standards.


 George Williams

 (Disclaimer: subjective observations. I'm sures other have specifics....)







-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 14:54:21 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        att!emory!samsung!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!bison!jamesp@ucbvax.Berkeley.EDU  (James Pinakis)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
If you can fit your entire message in one MAC-layer packet, and you only
have one, a formal connection can be replaced by server idempotency.  However,
if you have more than one message (or they are larger than one MAC-layer
packet), consider the following:

Dir	Flags		Data.

 <-	SYN		Transaction 1 request.
 ->	SYN ACK		Transaction 1 response.
 <-	ACK FIN		Transaction 2 request.
 ->	ACK FIN		Transaction 2 response.
 <-	ACK

Two transactions, five packets, perfectly legal TCP, and the server
doesn't have to be idempotent.  Four is the absolute minimum with UDP if
the server is idempotent.  I am not contending that any existing TCP API
will allow this streamlined an exchange, or that all TCPs can handle data
with the SYN (almost all can handle data with the FIN).  However, I will
argue that work in this direction offers more bang per buck than
developing both the sophisticated API and a new protocol to go under it.

One might criticize my scenario on the grounds that transaction processing
might delay things enough to cause retransmissions.  However, the same problem
afflicts any transport in this situation.  If processing time is predictable,
the API must allow setting initial timeout values.  If not, the net suffers
regardless of the API.

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

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 07:47:32 GMT
From:      munnari.oz.au!uhccux!okumura@uunet.uu.net  (Chad Okumura)
To:        tcp-ip@nic.ddn.mil
Subject:   Please Help Me ! ! !

	Can anyone out there PLEASE e-mail me the 'Hitchhiker's guide
to Internet'.  The consultant here at U.H. told me that this group
could help me find it.  Thanks in advance...

--chad
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 16:08:37 -0500
From:      stev@ftp.com
To:        aggarwal@nisc.jvnc.net (Vikas Aggarwal)
Cc:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil, stev@ftp.com, stewart@xyplex.com
Subject:   Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]

    That is to say, is there  someone out  there who relies *only* on SNMP
    to monitor the net ? Or will  'ping' be used as  a monitoring tool for
    the rest of IP's life ?
    
    
i have been arguing this for years now. in an earlier version of the PSI
code, we added it to the XMON program (what i am refering to is "ping
backoff", if we fails SNMP, we tried ping) this adds a degree of usefulness
to our software, in that it can tell you if non SNMP stuff is "UP" or not.

our current monitor tool "MON", backs off to ping, displaying a hostname in
green if SNMP thinks it is up, yellow if ping finds it up, and red if it
cant be found. this tends to be very useful in environments with "old"
equipments . . . . . . . . 


as near as i can tell, and no one has come out and said this, but it seems
to be an undercurrent in alot of people's minds, is that SNMP is enough, and
ping is somehow dirty, and shouldnt be used.  (*geesh*)


-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 11:59:50 EDT
From:      Harold Pritchett <HAROLD@uga.cc.uga.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: named going into an infinite loop ...
On Mon, 22 Oct 90 10:52:09 GMT Michel Fingerhut said:
>Machine: DECsystem 5820 (RISC)
>OS:      Ultrix 4.0 (Rev. 179)
>
>Every once in a while (every 3-4 days), the name daemon starts eating CPU
>time, goes to the top of the queue, and fills the syslog error message
>table with messages of the form
>
>	Oct 22 10:23:37 localhost: 93 named: accept: Too many open files
>
>(one a second, approximately) until it is killed and/or chokes /usr/spool.
>Upon restart, it works fine.  There is no apparent flood of requests prior
>to that.

Boy, do I have news for you.  We had that same problem here for approx a
month!!  DEC looked at it, we sent them dumps, they remotely logged onto
our machine, and finally they told us what was wrong!  The "/etc/resolv.conf"
file was mis-configured.

Make SURE that the first nameserver entry in the file points to the loopback
address.  It should look something like this:

domain     your.domain.edu
nameserver 127.0.0.1

We fixed ours, and have not had the problem since and that has been over two
weeks.  We also found that before we fixed the file, named would not dump
cache or stats in response to a kill -INT or kill -IOT command, and this
seems to have fixed that also.

For more information, you may want to contact Therese Grise in the DEC
Nashua, NH office, or Larry Pruitt in Atlanta, GA at (404) 772 2665.

Harold C Pritchett         |  BITNET:  HAROLD@UGA
BITNET TechRep             |    ARPA:  harold@uga.cc.uga.edu
The University of Georgia  |
Athens, GA 30602           |    fido:  1:370/60
(404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 14:29:53 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        stev@ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP monitors]

UP WITH ICMP!

SNMP is not enough.  What good is SNMP if the nodes on a network
do not support it.  And why should they.  They were on the net
before SNMP was a gleam in some relational database guru's eyes.

ICMP offers a lot more than SNMP cause it's there and SNMP is not.

I'm a raving supporter of TRACEROUTE and PING!  Five years from now
I'll switch to SNMP or something like it.   Hmmm, is that five or ten
years from now?  I forget.

Phil

PS:  I actually brought up some snmp stuff.  And for the nodes on
the network that support it, cisco router's, a couple of UNIX
machines running PSI stuff, and Multinet on VMS,  it's hunkydory!
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 11:43:00 GMT
From:      eru!hagbard!sunic!lth.se!tts.lth.se!xjeldc@bloom-beacon.mit.edu  (Jan Engvald)
To:        tcp-ip@nic.ddn.mil
Subject:   LANtastic on the backbone
I have earlier reported that we had problem with Lantastic networks when
they were connected to the backbone. Their ISO-like protocol caused
interference to other ISO protocols ("HP-IP" in our case, most probably
also AppleTalk Phase 2, Decnet Phase 5 and ISO-IP). This because they had
no ISO headers following the length field.

For quite a while we have now been running a new Lantastic version, the
"Xerox" version. It is an Ethernet-2 protocol, they have changed the length
field to have Ethernet type 81d6 instead. They are also using the following
multicast addresses (in our case, they may differ in your case):

  ffff00600004
  ffff00400001
  ffff01e00004

The multicast traffic is about the same as for an Ethernet based VAX-cluster.

Thanks to the Ethernet type we have had no problems what so ever with
this Xerox version of Lantastic. If you want to filter it in a bridge,
it can now also easily be done with just a type filter.

The Lantastic users report the Xerox Lantastic to be stable. And all
the previous features are retained, like very small memory consumption
and easy installation and maintenance.

If Lantastic is what you want, ensure you get the Xerox version and you
don't any longer have to fear any interference with other traffic.

                                             
Jan Engvald, Lund University Computing Center
________________________________________________________________________
   Address: Box 783                E-mail: Jan.Engvald@ldc.lu.se
            S-220 07 LUND     Earn/Bitnet: xjeldc@seldc52
            SWEDEN           (Span/Hepnet: Sweden::Gemini::xjeldc)
    Office: Soelvegatan 18         VAXPSI: psi%2403732202020::xjeldc
 Telephone: +46 46 107458          (X.400: C=se; A=TeDe; P=Sunet; O=lu;
   Telefax: +46 46 138225                  OU=ldc; S=Engvald; G=Jan)
     Telex: 33533 LUNIVER S
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 12:22:14 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@bloom-beacon.mit.edu  (Peter Mutsaers /100000)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
bzs@world.std.com (Barry Shein) writes:

>>Aesthetically, though, it bothers me to have to do the extra work of
>>converting datagrams to streams and back when the underlying transmission
>>scheme is almost certainly datagram based.  (Hmm, is anyone running TCP
>>over anything other than IP?)
>>
>>BillW

>But it's orders of magnitude easier than trying to add reliability
>(and performance, once you've added that reliability) to UDP or
>similar. All you basically need is to add a count field to each
>"packet" if you put it over TCP.

There may well be another reason not to use TCP. I for example am busy
with distributing programs over dozens of workstations. Every program
must be able to talk to any other one, 30 TCP connections is often the
maximum possible.
I could automatically close a connection if a new one must be opened, but
how do I know if no data is to be read, or underway, to the connection
I want to close?

If someone has another solution for this problem than making a reliable
UDP I'd like to hear it.
--
Peter Mutsaers                          email:    muts@fysaj.fys.ruu.nl     
Rijksuniversiteit Utrecht                         nmutsaer@ruunsa.fys.ruu.nl
Princetonplein 5                          tel:    (+31)-(0)30-533880
3584 CG Utrecht, Netherlands                                  
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 13:14:04 GMT
From:      bbn.com!craig@eddie.mit.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <12632159446.18.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>
>Aesthetically, though, it bothers me to have to do the extra work of
>converting datagrams to streams and back when the underlying transmission
>scheme is almost certainly datagram based.  (Hmm, is anyone running TCP
>over anything other than IP?)

Well, if you really wanna talk esthetics, I'm sure that somewhere in the
world, someone is running the cisco X.25 over TCP, over an IP, which at
some point in the path gets sent over an X.25 channel....

Craig
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 13:21:25 GMT
From:      santi@osf.org (Michael Santifaller)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)


	In article <GNB.90Oct23133132@leo.bby.oz.au>, gnb@bby.oz.au (Gregory N.
Bond) writes:
> Well, on a similar note....
> 
> I understand James' and Jon's arguments.  Reliable datagrams are best
> implemented with TCP and a "write(len); write(data);" layer.  I am
> looking for something a little different.
> 
> Consider a net with a server and many (say, 100) workstations, and a
> data feed that goes to each workstation.  At the moment, I have to
> open 100 TCP streams, and so each packet of data generates 200 TCP
> packets, all more-or-less identical.  What would be nice would be to
> broadcast the packet to the local net, and have the clients request
> missed packets, thus implementing a sort of reliable broadcast.
> 

	I would use broadcast RPC do this. SunRPC for example allows
	broadcasts to several servers simultaneously, you can get a reply
	from each and compare this with your list of recepients. I have
	no idea what the overhead for such a algorithm is, since the
	broadcasts are done through the portmapper on each system.
	Give it a try and make some measurements to find out its feasibility.
	RPC programming is easy to do.


	Michael Santifaller

------------------------------------------------------------------------
--------Michael Santifaller, PentaCom GmbH
(Yes, OSF uses NCS, but then -- I'm not an OSF employee)
--------------------------------------------------------------------------------

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 14:08:17 GMT
From:      bbn.com!craig@eddie.mit.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
>There may well be another reason not to use TCP. I for example am busy
>with distributing programs over dozens of workstations. Every program
>must be able to talk to any other one, 30 TCP connections is often the
>maximum possible.
>I could automatically close a connection if a new one must be opened, but
>how do I know if no data is to be read, or underway, to the connection
>I want to close?

From a protocol designer's point of view this is a terrible argument
(from an implementer's perspective, I understand the issues, but allow
me to wear my designer hat for a while).

To develop a "reliable UDP", you'll need state information (sequence
number, retransmission counts, round-trip time estimator), in principle
you'll need just about all the information currently in the TCP connection
block.

So building a "reliable UDP" is essentially as difficult as doing a TCP.
And the only reason to do it is that your operating system constrains the
number of connection blocks you can get, while the UDP interface allows
you more connection blocks, because you can put the connection blocks in
your application's memory space, rather than your kernel space (which is
putting dumb restrictions on you).

In the long run, you would almost certainly be better off fixing enhancing
the kernel to support more connection blocks, than doing a "reliable UDP."
You'll get a more flexible kernel, access to the protocol you really want,
and won't get caught in the quagmire of maintaining yet another reliable
protocol.

Craig
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 14:15:07 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <1990Oct24.094329.5037@gec-rl-hrc.co.uk> fddi@hrc63.UUCP
(FDDI Group (Ian Wakeman - A26)) writes:
+---------------
| although it may be heresy to say it in this group, XTP has some reliable
| multicast features inside of it, although I doubt whether they've been
| tested on a WAN,...
+---------------

True. All of the XTP/multicast applications I know of are on LANs. But XTP
incorporates most of the current thinking about "slow-open", RTT estimation,
and congestion control [shamelessly borrowed from TCP!], so XTP/multicast
ought to work on a WAN (except there aren't any XTP routers... yet).

+---------------
|               ...and claiming reliable multicast without group management
| facilities is a trifle absurd - how do you know that all possible respondees
| have replied?
+---------------

In XTP's "mostly reliable" mode, you set a service parameter (called "E" in
Appendix "B" of the XTP 3.5 spec) which is how many *consecutive* negative-ACKs
from any *single* station you want to be able to tolerate losing. The XTP
"bucket algorithm" then ensures that at least that many attempts have been
made to hear from everyone before releasing data from retransmisison buffers.
Larger values of "E" require larger retransmission buffers (or you can keep
the size of the retranmission buffers down by cranking up another parameter
"N", at the cost of more control packet and ACK traffic -- nothing's free).

If the probability of dropping an ACK from a given station is "p" (presumably
much less than 1), then the probability of that station falsely being "left
behind" is not worse than p^E. As long as you have a finite error rate and
enough memory for retransmission buffers (or enough spare network bandwidth),
you can make p^E "as small as you like". For example, you might choose to
set E such that p^E was less than the probability that the station will
spontaneously crash before the connection completes. In that case, "mostly"
reliable is as reliable as it gets.  ;-}

+---------------
| (Yes, I know that group management is then delegated to the session
| management :-) | ian
+---------------

Not really. There is *no* group management in the "mostly reliable" mode.
Stations can join and drop out of a connection, while getting reliability
"as good as they like" during the time that they're joined.

Maybe the following [admittedly loose anthropomorphic] analogy will help:
When you first arrive at a cocktail party, you aren't a member of, say, "that
conversation over there", and no-one pays any attention to whether you are
hearing or missing what's being said. But if you like, you can walk over and
stand within hearing range. Still, you have done nothing overt to "join" the
conversation. But now it is possible for you to send negative-ACKs ["excuse
me? what did you say?"] to cause retransmission. Provided the speaker is
willing to back up often and far enough for you [his "retransmission buffers"
are large enough] and your ACK traffic does not exceed what is considered
good taste, you can get reliability "as good as you like".

Yet all you have to do to leave the conversation is walk away and cease sending
NACKs. Again, no overt group membership protocol was utilized. In fact, the
only effect on the conversation may be, especially if you were slow or hard of
hearing, that the average data rate goes up somewhat after you leave as the RTT
or congestion estimators adapt to the new set of listeners [i.e., minus you].

(Of course, if you had a good receiver [ears], a high input processing rate,
and a bit of patience, you may never have had to send a NACK -- someone else
may have always beat you to it. I mentioned this in a previous message about
XTP's "damping" and "slotting" of ACKs.)

Anyway, the "cocktail party" analogy is intended to indicate why the "mostly
reliable" mode of multicast might have some domains of applicabililty. In
fact, this is the mode in which most of the known XTP multicast users are
operating.


-Rob

p.s. There is an XTP TAB sub-group activity on group management stuff to
support "fully reliable" XTP multicast, but it looks to me like a longer-term
standards activity...

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 21:16:00 PDT
From:      Pushpendra Mohta <pushp@CERF.NET>
To:        aggarwal@nisc.jvnc.net, stev@ftp.com
Cc:        snmp@nisc.nyser.net, stewart@xyplex.com, tcp-ip@nic.ddn.mil
Subject:   Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
>>
>>as near as i can tell, and no one has come out and said this, but it seems
>>to be an undercurrent in alot of people's minds, is that SNMP is enough, and
>>ping is somehow dirty, and shouldnt be used.  (*geesh*)
>>
>>
>>

And not to mention the fact that only traceroute and ping will work
when debugging problems with boxes you dont know the SNMP community
names of ...

--pushpendra
CERFnet
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 15:59:50 GMT
From:      HAROLD@UGA.CC.UGA.EDU (Harold Pritchett)
To:        comp.protocols.tcp-ip
Subject:   Re: named going into an infinite loop ...

On Mon, 22 Oct 90 10:52:09 GMT Michel Fingerhut said:
>Machine: DECsystem 5820 (RISC)
>OS:      Ultrix 4.0 (Rev. 179)
>
>Every once in a while (every 3-4 days), the name daemon starts eating CPU
>time, goes to the top of the queue, and fills the syslog error message
>table with messages of the form
>
>	Oct 22 10:23:37 localhost: 93 named: accept: Too many open files
>
>(one a second, approximately) until it is killed and/or chokes /usr/spool.
>Upon restart, it works fine.  There is no apparent flood of requests prior
>to that.

Boy, do I have news for you.  We had that same problem here for approx a
month!!  DEC looked at it, we sent them dumps, they remotely logged onto
our machine, and finally they told us what was wrong!  The "/etc/resolv.conf"
file was mis-configured.

Make SURE that the first nameserver entry in the file points to the loopback
address.  It should look something like this:

domain     your.domain.edu
nameserver 127.0.0.1

We fixed ours, and have not had the problem since and that has been over two
weeks.  We also found that before we fixed the file, named would not dump
cache or stats in response to a kill -INT or kill -IOT command, and this
seems to have fixed that also.

For more information, you may want to contact Therese Grise in the DEC
Nashua, NH office, or Larry Pruitt in Atlanta, GA at (404) 772 2665.

Harold C Pritchett         |  BITNET:  HAROLD@UGA
BITNET TechRep             |    ARPA:  harold@uga.cc.uga.edu
The University of Georgia  |
Athens, GA 30602           |    fido:  1:370/60
(404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 16:49:44 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC interface across various platforms


Sorry if this is received more than one time...problem in original parse
of your addr. Ditto for cc: list.



This is the $64k question.....

Are there any commercial or public domain packages that will allow th
e
construction of a distributed application running on such diverse pla
tform as.....

>>> While most of the aforementioned have solutions that are designed 
>>> for distributed computing environments most of them tend to
>>> be product-based, perhaps by design. That is there is no "one"
>>> technical solution to the problem as stated; that of a generic
>>> application programming interface for distributed computing
>>> environments that every one uses to make the same calls on 
>>> any machine.( the OS may accomplish this before the API's )
 
>>> This is where most vendors seem to be drawing the line in the
>>> sand as to which side of the open computing fence they stand
>>> (straddle) on and probably for good reason; it will be the
>>> one that keeps software from becoming a commodity ( oops ).
 
>>> The good news is that everyone is making an effort to talk
>>> to everyone else. The other side of the coin is "what can be
>>> said" i.e. what application functionality can you access without
>>> buying a specific API for you machine .
 
>>> The companies moving in the direction of "common APIs and  open network
>>> toolkits" have the jump on the rest of the pack. This the area
>>> where the biggest gains are to be made not just dollar-wise
>>> but in the are of engineering and programming productivity. It
>>> is becoming clear that the "one" solution for a generic RPC
>>> will have support for many Application Program Interfaces. Suggested
>>> system analysis, prior to making a strategic choice.
 
>>> IBM MVS/XA - solutions under an SAA/CPI umbrella
>>> VAX VMS    - ditto OAA
>>> Macintoshes- MAC everything (smile)
>>> PCs        - VINES,NETWARE,NETBIOS,APPC,LU.6.2
>>> BSD flavors- Take your pick from SUN,etc's ONC to OSF(oops Mach)
>>>              et al DCEs and see below.
>>> UNIX?      - appears to be the LCD when choosing, to date.
>>>              common API/RPC  running under this will probably have
                 broadest base with respect to mix and match
                 capabilities and ease of implementation..

>>> Note: I have seen proprietary solutions that are nice...in fact so nice
>>>       elements of them will make it into standards.


 George Williams

 (Disclaimer: subjective observations. I'm sures other have specifics....)

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 18:11:09 GMT
From:      rti!ntpdvp1!samc@mcnc.org  (Sam Christie)
To:        tcp-ip@nic.ddn.mil
Subject:   3278 Terminal emulation over TCP/IP
Some time back I posted a request for code to TN3278 which has been
ported to the Interactive SysV/386 ( 386/IX ) environment.  We have
a copy which compiles under HP/UX, but have been told we can not
spend the time to do the port.

If you have made this port, are willing to do this port for a reasonable :-)
fee, or know of a commercial port, please e-mail the particulars to me.  Since
I can't read all the news groups, this is one I normally miss.

Sam Christie                            Standard Disclaimer Applies
Northern Telecom - DMS-10
Research Triangle Park, NC
EMAIL ...!uunet!mcnc!rti!ntpdvp1!samc
919/992-3917
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Oct 90 22:30:10 EDT
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        stev@ftp.com
Cc:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Re^n: SNMP monitors
This started out to be a simple reply, but I found it inspired me and
I ran on for about three printed pages.  It was started by a couple of
messages I got early this morning, and I decided to expound a little
about what was good and bad about various systems for managing the
network, be it a single over-all NMS program or flashing from xterm to
xterm running pings and traceroutes.  This message describes many of
the ideas and feelings I have about managing my network and how this
has affected the way I do it, including the design of an NMS program I
wrote (starting over 3 years ago) and the supporting operations.  This
message was written over a period of many elapsed hours (>12 at least)
as I sat here flipping to various management tasks, coming back to the
message and flitting off again.

I think there may be useful hints in here for NMS developers in
designing their systems and for network managers in deciding what's
important to them in their tools and, perhaps, hints on how to
evaluate them.  This is one person's view, but I hope some of you find
value in it.  It seems to have turned out rather self-promotional in
parts, but since the code is available free this isn't a commercial
message :-).

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

P.S. Since it's somewhat promotional, I at least should promote
something else, too: If you want more info on the tool, see the entry
in RFC1147 which is briefer and contains contact info, or I can send
you some of the descriptive files (I think this is destined to turn
into one of them :-).  If this inspired you, maybe you should look
over the rest of 1147 as well. (See, Bob, I do promote your work :-)
----------------------------------------------------------------

In an ongoing discussion of NMS features and other stuff, Kent England
(I think) wrote, in part:
    The people running the InterOp show network used ping and
    traceroute a lot, but then they may be old fashioned.

Which inspired Stev Knowles to respond with a well thought description
of what in fact did and didn't work to manage the Interop Shownet,
including pointing out that SNMP was used a bit more than the above
statement implied, but perhaps not as much as it could have.  He
pointed out that one reason the use of the SNMP NMSs was limited was
training, but goes on to make five points where the limitations of the
more advanced tools was a problem.  This list caused me to think quite
a bit and I realized I may have a point of view that develops these
ideas more.

My main job is day-to-day management of an operational network with
about a dozen main subnets, but in my copious (ref Tom Lehrer) free
time I have developed a system for managing the network which hinges
on an NMS program I developed (about .2MB of source).  The reasons I
originally developed it, use it, and continue to expend time extending
it---rather than switching to any of the more "popular" systems---are
that it addresses all of Stev's points to some degree (either in the
programs or the way I use them), plus a few I find important but he
didn't mention.  On the other hand, there are a lot of things the
other systems do that have never made it to mine, after all I'm one
(very) part-time programmer vs frequently a full-time or even hordes
of full-time programmers.  This is in part a description of why I find
my tool with fewer total "features" to be more useful.

The interesting thing was that until I read Stev's message, I hadn't
thought to characterize it that way, I just used one of the phrases,
"They have lots of shine, but no substance" or "They give good demo,
but I don't see how I'd manage a real net with them" to describe the
alternatives and left it at that.  The main difference between the
approach of these other systems and mine seems to stem from how and
why they were developed.  Most systems I've seen (say at Interop) were
written by programmers whose job is to develop programs for sale.  The
time I get to put into mine comes solely from the time I spend doing
direct management/planning/etc.  Also my tool(s) are directed towards
a narrow audience, while the others, to be a product, need to appeal
to a wide audience, and especially the administrators who buy, not
just the technicians who use (I had trouble not using the word manager
in two different senses as both sides of that).


Most features I put in my system are conceived as I work on a specific
problem running the network.  I collect these ideas in a file.  Then
when I do have some spare time, I look over the list and decide which
is likely to have the best payback in future time saved.  Each feature
goes in because I see a specific way that it will let me do my job
easier.  Much of the earliest design of some of its operation are very
different, because I had some of Stev's points (you knew I'd get back
to these, didn't you) on my initial agenda, let me address them one at
a time (and then add my own), describing how I eliminate that
"problem" and why I did it that way:


1) "large ... stations with great graphics are useless if they are not
[on the right part of] the network": Although my program will draw
pretty pictures if you have a display, ALL the functionality is
available from a dumb serial interface (except pretty pictures, but
you could have a pre-printed hardcopy with you :-).  In fact, I use
exactly the same set of tools when managing the network over a dialup
from my H19 as I do at work on my color workstation.  These programs
contain all the code to do the fancy stuff, they just don't call it
when I'm out on a limb, so to speak.  I've never tried to build a
stripped down version that would fit in a portable, but it shouldn't
be hard (given other conditionalizations I've put in) and sounds like
an interesting new idea for my list.  Thanks, Stev.


2) "screens were [too] crowded":  This may not be a program feature as
much as what diagrams you build, on the other hand my main diagram
tool is one large window with a fairly bare bones diagram.  I try hard
to make the layouts as simple and as logical as possible.  The idea is to
not busy up the screen until you start asking for stuff.  The stuff I
put on a given display is the things I expect to want to get right
away to isolate a problem.  If there isn't a problem, I can afford
slightly more leisurely access.  The one thing I can't afford is an
"improvement" in my non-problem access that hinders me when there's an
actual failure to try and isolate.


3) many things that slow you down, including needing to "click on
several things" to do something and "name resolution calls blocking":
My goal from the outset (a side note here, I started this before SNMP
existed) was that frequent things were fast and that anything I do
regularly has to be possible with complete network failure (of course
it only reports failures :-) and that near total failure should affect
ability to operate to the absolute minimum.  That's pretty much part
of the SNMP philosophy.  This also harks back to the development
process, my decision on what is "frequent" or "regularly" is from
observing me manage my network.  Things are made easy because I find I
need to do them a lot rather than I do some things a lot because
that's what the NMS writer made easy.

All actions used to track problems are single clicks of the correct
button on the appointed thing, with perhaps a bucky bit.  The only
time you need multiple anything is if you need a host that's not on
the display, and that's ALL done on the keyboard.  As long as I'm
going to have to type to get the name in, I may as well make max use
of the keyboard.  I don't have to click somewhere to get a form, move
the mouse around to enter things in various places (hands back and
forth from mouse to keyboard).  An "action" that I want to perform is
all mouse or all keyboard, flipping back and forth slows me down.  A
few things that are used less frequently or not useful in the "Quick!
Track this down mode." do this, but it matters less here.

All the names I am likely to resolve have been done by a seperate
process that is out of the management loop and are stored on the local
disk (not over NFS!).  If the network stays up long enough for it to
get a new set of data (yes you CAN read that as zone-transfer, though
not in all cases) it does a careful atomic replacement.  I always have
consistant data, it's only outdated in the cases where direct queries
would probably fail anyway, and the interactive part never stops to to
this (unless you have real slow disks :-).  This is currently done
with crontab and shell scripts and is one of the areas where I am less
satisfied than I might be, but every other system I've looked at has
problems I find much worse.  I'll probably write a real program to do
this eventually and couple it to the master a little better than the
scripts can, but it's quite adequate for now since it's also loosely
coupled to the actual scripts that do the real DNS data.

There is still one point left in my current design where you need to
wait, but for at most a single network timeout.  Fixing this one is
REAL HIGH on my ToDo list.  I really want to have the ability to
suddenly say "Oh no, that was all the wrong stuff, forget all those
things I asked for and go do this other NOW!"


4) "tools [didn't] figure out that their router went down": The
polling loop and the diagram and interactive operation are in seperate
processes (which at present are only coupled by being nearby windows I
use cut-and-paste between, this is another area I think needs work on
my system, they should really talk, but I'm using my experience of
what I cut-and-paste to design the paradigm for how these parts will
talk).  Remember the goal of best possible operation under worse case
failure?  This is one of the specific cases I keep thinking about.  If
the nearby router goes down the polling may stop, but the piles of
errors going by alert you that something really fatal is at hand and
you immediately move to the point on the map where your workstation
shows and move out.  If the next nearest thing doesn't work, you've
already eliminated (probably) 90% or so of the possible points to
investigate and the map is working fine, you now know enough to
realize the reports af things miles away not responding are easily
ignored.  This isn't so much "the tool noticed" as the "design made
the failure softer".  This can be as important sometimes.


5) "few ... back off to ping":  My program treats protocols as a
stack.  Ping is basic to IP, SNMP runs on top of IP.  If IP
connectivity doesn't exist, don't try SNMP.  It's also possible to set
how aggressive the program should be with SNMP.  Do you want it to try
SNMP anytime it might possibly work, only when other status indicates
it should, or not at all unless specifically requested (i.e. use ping
as the normal status check).  A large part of this is due to the fact
that most of the structure and functionality of the system was in
place before SNMP came into being, in fact most of the system doesn't
use SNMP.  It's a relative latecomer.


6) [This is the one Stev didn't say but is as important to me as the
others if not more so] how well does it allow me to extend the
supported protocols?  My network runs two protocol stacks, one of them
an "invented here and barely heard of (let alone supported) outside"
stack of the same age as IP.  The two protocols have always been equal
partners in all aspects (except the other stack never had an
equivalent of SNMP developed).  In part the ability to add anything I
want on is because I wrote it, so I can.  But, I have always had a
vision of how someone with a similar situation should be able to add
their "funny" protocol with little work and make it coequal with the
other two.  In fact I have had a couple of people express interest in
it just for this reason.  Although (since I give out the source) I've
never done the final details, the design was intentionally one that
would lead itself to "you want another protocol, just write a small
interface in C, compile it and link with the object library".  You
don't need the other source (it's just nice because, right now, there
isn't any other documentation for adding protocols :-).



So all of Stev's points are important to at least one other network
manager, sufficiently so that I've put effort into solving them
locally and they've been part of what keeps me from going to a big
name NMS.  What I have now addresses these six points.  They are,
perhaps, the most important points to my being able to diagnose and
track problems on a moderate size net of mixed protocols, systems,
media, etc.  I've never really seen another NMS that addresses them as
well as I desire.  So I'll stick with my stodgy old system.  It
doesn't have the flash, but it stands up to the punishment of the net
I have to manage and comes back for more...
	(and finally, because I have the source, it runs on all six
	 different brands of workstation here and looks identical :-)
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 19:18:52 GMT
From:      att!cbnewsh!cs@ucbvax.Berkeley.EDU  (cetin.seren)
To:        tcp-ip@nic.ddn.mil
Subject:   need help w/IBM PC LAN (HEEEELP!!!)
As a mostly UNIX land dweller, I've come across a task which puts me into
the uncharted (for me, anyway!) jungles of the DOS land.

Here's my problem:  There is a nice DOS fileserver that I'd like my 386
to talk to.  The DOS fileserver is running IBM's PC LAN, version 1.2.

Here's one thing (god forbid) I might have to do:
boot my 386 with DOS, and use PC LAN to make my 386 a client to the DOS
fileserver.

I'm hoping some folks out there have a better solution for me.  Isthere any
software available for UNIX so that I can make my 386 look like it is
just another client to the fileserver so that I can keep using my 386
under UNIX while gaining access to the fileserver?  Technically, this should
be easy enough to do, since the PC LAN is TCP/IP based, but  I imagine
it would be a bitch to be able to obtain the protocol specifications.

Anyway, I'll appreciate any ideas, pointers (like where I can get some public
domain source code, if there is any), related to this matter.

My e-mail address is: (I hope I still remember my arpanet and bitnet adresses

right):

	cs%speedy.att.com@att.arpa		(BITNET)
	cs%speedy.att.com			(ARPANET)
	uunet!att!speedy!cs			(UUCP)

	If all else fails: (201) 957 3086 !!!!!!!


				Thanks a lot for reading the message, folks...
				Cetin Seren
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 19:24:29 GMT
From:      eru!hagbard!sunic!chalmers.se!afs-news!trout!dahlstr@bloom-beacon.mit.edu  (Gunnar Dahlstrom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LANtastic on the backbone
Why write in English, i ett svensk mote!!!

Bara en liten undran.

Gunnar


===============================================================================
				Gunnar Dahlstrom
			Chalmers University of Technology
			    Div. Building Technology
			   412 96 Gothenbourg, Sveden
			E-Mail: dahlstr@hus.chalmers.se
===============================================================================
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 20:55:45 GMT
From:      bellcore-2!envy!karn@rutgers.edu  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <1990Oct24.090841@apollo.HP.COM>, mishkin@apollo.HP.COM
(Nathaniel Mishkin) writes:
|> E.g., for the purposes of RPC, it sure would have
|> been nice if I could do something like send data (i.e., the remote
call's
|> input parameters) in a SYN.  (I've never seen an implementation that
|> allows this; I can't point to the place in the TCP spec that
disallows
|> it, but I imagine it is disallowed.)

I don't think anything in the TCP spec specifically disallows the
piggybacking of data with SYN bits. The only possible argument against
it is the fact that the active initiator of a TCP connection doesn't
yet know the receiver's window size yet. But even here the the worst
that should happen under the Robustness Principle is that the receiver
might not have buffer space for all (or any) of the data, requiring
the sender to retransmit it once the connection is fully open.  This
is an efficiency issue, not a protocol correctness issue, and is
identical to that associated with the "optimistic window" send policy.

But assuming no problems with buffer allocation, I see no reason why
an entire TCP connection couldn't consist of only three packets:

A->B: SYN, FIN and data
B->A: SYN, FIN, ACK (and optional data)
A->B: ACK

Of course, most application interfaces don't provide for sending such
"christmas tree" packets, but a correct implementation of TCP should
be able to handle them when received. It's hard to think of a "reliable
datagram protocol" that would take less than three packets to provide
at-most-once semantics for a single message in each direction.

Even with applications that don't require a "reliable datagram
protocol",
I think that the ability of TCP to piggyback control and data should be
much more widely used. There's no reason why a SMTP or FTP server's
opening banner couldn't be piggybacked on the server's SYN/ACK segment,
saving two packets, and no reason why FIN can't be piggybacked on the
last
segment of a data transfer, also saving two packets. Again, a correct
implementation of TCP should handle such packets just fine.

While we're on the subject of piggybacking, another thing I would
really like to see is widespread use of batched SMTP on the Internet.
I think the number of packets it takes for most SMTP implementations
to transfer a short mail message is criminal, especially when the
message has several recipients on the same system.  There's no reason
that you shouldn't be able to send a series of SMTP commands in a
single TCP segment and receive a series of responses, except that many
SMTP servers inexplicably blow up when you try this. Given that TCP is
supposed to be a reliable byte stream protocol, the designers of these
systems must have gone well out of their way to keep this from working.

Phil
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 90 23:41:36 GMT
From:      dynasys!alana!jaa@rutgers.edu  (Alan Anderson [068])
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP Drivers SCO-ODT

	I am trying to install a SLIP tcp-ip driver on a system that
is currently using a Western Digital 8003 for ethernet. They need to be used
concurrently. 

Steps Performed were:

	mkdev tcp

	added a SLIP driver
	defined the tty
	set the source and destination IP address
	set baud rate to 9600
	used the SLIP Interface default netmask

when the Kernel was re-linked and the system re-booted, it hung up at TCP
initialization. Please respond on sco.opendesktop, I don't trust MMDF yet.
	Thanks
	Alan Anderson (901) 762-6068
	United Dominion Building
	6000 Poplar Suite 400
	Memphis, TN 38119
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 01:14:20 GMT
From:      portal!cup.portal.com!lan@apple.com  (Los Altos Networks)
To:        tcp-ip@nic.ddn.mil
Subject:   TELEBIT NETBLAZER



          LOS ALTOS NETWORKS IS PLEASED TO PRESENT THE FOLLOWING
          NEW PRODUCTS INFORMATION:   	


			T E L E B I T   N E W S   R E L E A S E

                 TELEBIT ANNOUNCES DIAL-UP INTERNETWORKING
              NetBlazer(tm) is the first in a family of products 


SUNNYVALE,  Calif.,  INTEROP '90, October 8, 1990  --  Telebit Corporation,
pioneer of the high-speed dial-up modem, introduced today the  industry's
first automated dial-up TCP/IP router.   The  NetBlazer(tm)   integrated
communications server is the first product to use modems and the  public
switched telephone network (PSTN) to automatically provide virtual  wide
area networking for TCP/lP-based ethernets.  By automating the modems'
connection establishment, the NetBlazer offers seamless wide area  network
connections between diverse computers and/or local area networks (LANs).

In addition to its virtual  routing functions, NetBlazer also integrates
traditional terminal server capabilities, LAN-based modem sharing,  a  56K
bps leased line connection, dial back-up, and ethernet to ethernet routing
functions, all in a single product.

The introduction of the NetBIazer represents the next major step in
Telebit's strategic diversification and fuels the new dial-up
internetworking marketplace.

NetBlazer Answers Customers' Demands

Prior to NetBlazer, expanding networks was a time consuming  and  costly
process due to technical obstacles.  NetBlazer, however, represents  the
marriage of the power of internetworking to the flexibility of the PSTN.  
As a result, the enterprise wide network has greatly increased  flexibility
because the PSTN offers immediate, low-cost, on-demand access.  NetBlazer
enables an organization to expand its network to any location in the  world
where there is a public telephone system. This flexibility creates a number
of applications including telecommuting, which is the ability of NetBlazer
to bring the network into the users' home, allowing them to become a node
on the network using their personal computer or workstation in cobination
with a  modem.  Yet another application is the ability to  cost effectively
connect remote sites on the PSTN as opposed to incurring the expense of a
leased  line.  This, for example, enables large companies to tie their
smaller offices together in a virtual wide area network.

"We chose to begin with support for TCP/IP and Ethernet because  our
customers asked for a product that combines open systems standards in high-
speed  modems with today's most widely installed open system  networking
protocols, TCP/IP, and media, Ethernet.  NetBlazer's open architecture will
allow support for other networking protocols and media as the  market
demands," said Michael Ballard, Director of Telebit's Network Systems unit.

Cost Effectiveness is Major Benefit to Customers

NetBlazer is a cost-effective wide area networking tool with  combined
functionality that offers numerous additional features to the end-user.
Some of these include three levels of security, multi-vendor connectivity,
and on-board SNMP network management software. "Our aim with this new dial-
up internetworking product is to provide the customer with more  solutions
within a single product (NetBlazer), easing the expense and  technical
obstacles associated with using different devices to provide these
communications services," said Ballard.

Telebit is introduced NetBlazer at Interop '90,  a  major  conference  and
exhibition for the internetworking industry.

Prices for the NetBlazer begin at $2,995, not including modem(s), and increase
depending on the configuration. The product includes a one-year warranty on
parts and labor. NetBlazer will be avaiiable by the end of November 1990.  

Telebit  Corporation designs,  manufactures and markets advanced high-speed
products for dial-up networking and wide-area communications. The company's
proprietary digital signal processing technologies provide  extremely
reliable error-free communications across the worldwide switched telephone
network.  Telebit markets its products worldwide through distributors,
original equipment manufacturers and value-added resellers.

Located in Sunnyvale, California, Telebit is a publicly held corporation and
is  traded on the National Association of Security Dealers  Automated
Quotations (NASDAQ) OTC market under the symbol TBIT. 


                                    ###
Telebit and NetBlazer are registered trademarks or credits of  Telebit
Corporation.  Other trademarks or credits used are those of their respective
holders.

LOS ALTOS NETWORKS IS AN AUTHORIZED AND STOCKING TELEBIT
VALUE-ADDED DISTRIBUTOR PROVIDING UNIX DATA COMMUNICATIONS
PRODUCTS AND SERVICES.

FOR MORE INFORMATION ON THIS AND ALL TELEBIT PRODUCTS, PLEASE
CALL 1-415-941-8031.

==============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \||   \\|
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                 NTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 08:12:14 -0400
From:      barns@gateway.mitre.org
To:        craig@bbn.com (Craig Partridge)
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: question about SMTP MX records
Ouch, Craig, I hope I didn't hear you say that every host X that is
an MX for another host Y is required to support the percent hack,
that is, treat user%Y@X equivalently to user@Y?  It works in most
places, probably, but I don't remember this ever being raised as
even a proposed requirement...

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 02:13:27 GMT
From:      sgi!root@ucbvax.Berkeley.EDU  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   MX-capable sendmail for Iris 4D machines
In response to requests from some of our customers, a prototype version
of MX-capable sendmail for Silicon Graphics Iris 4D series computers is
now available for anonymous ftp from SGI.COM [192.48.153.1].

This version of sendmail is based upon Berkeley sendmail version 5.64
and includes the IDA and BIND enhancements.

A compressed tar file containing the sendmail binary, the
sendmail.hf file, a skeleton sendmail.cf, and a self explanatory
README file can be found in the ftp directory under the pathname
sgi/sendmail/MX_sendmail/MX_sendmail.tar.Z

Those wishing to experiment with this code should note that it is to
be considered an unsupported prototype and that the following disclaimers
apply in full:

----------
This software is provided without support and without any obligation on
the part of Silicon Graphics, Inc. to assist in its use, correction,
modification or enhancement.  There is no guarantee that this software
will be included in future software releases.  

THIS SOFTWARE IS PROVIDED "AS IS" WITH NO WARRANTIES OF ANY KIND
INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A
PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE
PRACTICE.

In no event will Silicon Graphics, Inc. be liable for any lost revenue or 
profits or other special, indirect and consequential damages, even if 
Silicon Graphics, Inc.  has been advised of the possibility of such damages.
----------

Please address all comments and observations to: mxcomments@sgi.com


		Robert L. Stephens
		Silicon Graphics Inc.
		Mountain View, CA
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 10:36:53 -0500
From:      "Craig A. Finseth" <fin@unet.unet.umn.edu>
To:        don@usna.navy.MIL
Cc:        aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL
Subject:   [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
   Is that monitoring done by SunNet Manager?  Has anyone had any experience
   with this package?

No, it is a package that I wrote.  I wanted one that worked, not one
that was pretty.  I don't know anything about SunNet.

Craig

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 11:48:04 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        qualcom.qualcomm.com!edmund@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  POP3 client for a pc
The latest version of our software (Version 2.05, released two days ago)
includes a POP3 client. 
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 08:20:25 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        aggarwal@NISC.JVNC.NET, stev@FTP.COM, stewart%xyplex.com@RELAY.CS.NET
Cc:        snmp@NS.PSI.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
 > From snmp-ok-forw@nisc.psi.net Thu Oct 25 20:44:29 1990
 > From: aggarwal@nisc.jvnc.net (Vikas Aggarwal)
 > To: stev@ftp.COM, stewart@xyplex.COM
 > Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
 > Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
 > 
 > >> SNMP was not used as much as it could have been for one simple reason. no
 > >> matter what people tell you, the tools currently on the market are not easy
 > >> to use.
 > 
 > Another fact is that systems supporting SNMP do not consider snmp as a
 > high priority task- as a result I have  routers that do not respond to

To all of those box builders (including Racal Interlan :-)

To structure your in-box priorities in such a way as to make management
(and, for bridges and routers, Spanning tree and your routing protocols)
run at a lower priority than the "main" purpose of the box (e.g.
forwarding packets for bridges/routers) is ABSOLUTELY BASS ACKWARDSLY
WRONG. As Vikas described in his memo - when a network starts to depart
for the Twinkie zone, the bridge/router may spend absolutely 100% of
its time bridging/routing. Regardless of the efficiency of the network
management protocol and it underlying transport, the NM packets
will not be processed by the box. The manager will not be able to
find out what's wrong, nor will s/he be able to take effective
action (similarly for bridges - if the max out at 100% doing bridging, 
then spanning tree packets get ignored and the spanning tree
algorithm breaks and you may wind up with loops in the net, meaning
that offered load will increase - can you say melt down?)

When everything else is going completely bonkers, NM, etc, 
MUST WORK. One of the reasons that NM protocols and agent load
must be kept small is to reduce the amount of work that the
box must do at this highest priority.

Now, I hear the masses crying out - "I don't want NM to be highest
priority - then anybody with a network management station can
bring a box to its knees". Well, I hate to say this but, if 
someone has an NM station, they can do this anyway (set ifOperStatus.*
to down). Besides which, this is not a problem of network management,
this is a problem of security. If you have unauthorised people doing NM
on your network, then you have a security problem, NOT a NM protocol problem.

Btw, this is not just smoke, this is heat and light. Here at Interlan,
we learned the hard way that what I've just said is true. During development
of our bridges, under heavy load, our bridges would lock up from a NM/Spanning
Tree point of view.  NM said the bridges were down. For the "working" bridges,
spanning tree indicated that those bridges failed. Yet there they were,
forwarding packets..... In fact, sometimes they would lock up so hard
that even the local console would stop working. The only way we had of solving
the problems was to partition the network until things got better.

Cheers
Frank Kastenholz
Racal Interlan

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 12:01:55 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        barns@gateway.mitre.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: question about SMTP MX records

> Ouch, Craig, I hope I didn't hear you say that every host X that is
> an MX for another host Y is required to support the percent hack,
> that is, treat user%Y@X equivalently to user@Y?

RFC 1123 doesn't explicitly require it, but it suggests that support
for the %-hack is expected (the discussion in Section 5.2.16 being
my primary source).

Craig
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 12:07:03 -0400
From:      magill@operations.dccs.upenn.edu (PennNet Tech. Services)
To:        fin@unet.unet.umn.edu
Cc:        aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Subject:   Re: SNMP monitors
>>      I do realize  that an overloaded  router should be  addressed, but  if
>>      SNMP  could  gaurantee me a  reply if a router  was UP  and doing  its
>>      primary funtion, I would stop  using ping to  monitor our routers  and
>>      pay *serious* attention to snmp based  monitoring programs, as opposed
>>      to *saying* I use   SNMP to prove  that  I  am  in sync with   the new
>>      technologies that exist.
>>
>>      That is to say, is there  someone out  there who relies *only* on SNMP
>>      to monitor the net ? Or will  'ping' be used as  a monitoring tool for
>>      the rest of IP's life ?
>
>   I see no reason why it is desirable to stop using ping (or, more
>   precisely, the ICMP Echo mechanism).  Most checking just wants to know
>   "are you there" and the ICMP Echo mechanism does that with much less
>   overhead than SNMP ever could.
>
>   For example, the network monitoring here at the U uses ICMP Echo for
>   most checking, reserving SNMP for those "higher level" tasks such as
>   checking routing tables and interface configurations.  The software
>   also knows not to perform the higher level checks unless the device is
>   known to be up.  (It also knows not to check hosts behind a down
>   router, but that is not related to SNMP).
>
The problem with ping in a trouble situation is just exactly what is
described in the last paragraph. One doesn't simply want to know
if the router exists, but rather one wants to know "what the hell it
is doing!" One needs to look a the routing tables or to up or down
an interface, for example.

A device that can't tell me what it is doing simply because "it's too
busy" is one that is about to crash - or maybe it already did - or 
maybe it's simply routing the same packet over and over again - or
maybe it isn't routing anything, just replying to the ICMP echo!

While the routers in question seem to be pretty damm reliable and we
usually discover via the telephone that it is possible to get from
here to there but at reduced performance level because the router is
"too busy routing". ie it's OVERLOADED. And had begun to perform a
clasic utility process called "load shedding". Maybe that means that
these routers aren't quite as reliable as we thought they were,
or maybe it means that we have too much traffic, or maybe it means 
that all the traffic is bogus.

Without SNMP access and statistical information, we have no way of
knowing what is happeing. We can only try the forensic approach and
reconstruct things after the crisis goes away and we get our queries
answered.

Knowing that "something exists" is not part of network management.
Knowing what something is doing IS. It is not enough to simply know
that something is "working" one must know that it is "working correctly".

A "network technician" may only need to know that "something exists",
but a "network manger" needs to know what is going on.

(That's also my beef with the present "Network Management Stations".
They are "trouble shooting tools", not "management tools".)

William H. Magill                         Manager, PennNet Technical Services
Data Communications and Computing Services (DCCS)  University of Pennsylvania
Internet: magill@dccs.upenn.edu                   magill@eniac.seas.upenn.edu
          magill@upenn.edu 

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 12:33:42 PDT
From:      braden@venera.isi.edu
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Cc:        iab@venera.isi.edu, iesg@venera.isi.edu
Subject:   IAB meeting minutes available
Minutes of the June 1990 IAB meeting are now available for anonymous
FTP from host venera.isi.edu with the pathname:

   pub/IABmins.jun90.txt
   

Bob Braden
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 11:12:47 EDT
From:      "Mr. Donald W. Garner (CADIG  STAFF) " <don@usna.navy.MIL>
To:        "Craig A. Finseth" <fin@unet.unet.umn.edu>
Cc:        aggarwal@nisc.jvnc.net, stev@ftp.com, stewart@xyplex.com, snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL
Subject:   Re:  [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
>For example, the network monitoring here at the U uses ICMP Echo ...

Is that monitoring done by SunNet Manager?  Has anyone had any experience
with this package?
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 07:54:04 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@BLOOM-BEACON.MIT.EDU  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP/IP over ether weirdness
In article <8945@pitt.UUCP> field@elvis.cs.pitt.edu (Gus) writes:
>
>I've got an application that would like to send the largest UDP packet
>it can.  (sun3 - sun3 running 4.0.3 over 10MB ethernet).  The only
>reference to max UDP packet size is in the RPC section where it says
>the max size the UDP transport mechanism can handle is 8K bytes.
>(sendto () does not return EMSGSIZE until I try to send >9000
>bytes per datagram).  Anyway, when I send 8K byte packets, sendto ()
>doesn't complain, but the packets never arrive at the receiver.  In
>fact, if I attempt to send a datagram larger than 2048 bytes, it never
>arrives at the receiver.  Running etherfind on a third machine, and
>watching the traffic between the UDP src and dst's I see:
>
>-----
>2048 byte packet:
>
> 1514  udp pebbles	 wilma		       1788       4343
>* 610  udp
>
>This datagram is delivered correctly to the destination application.
>   
>-----
>2049 byte packet:
>
> 1066  udp pebbles	 wilma		       1790       4343
>* 611  udp
>
>Now, something is definitely wrong here.  
>
>-----
>
>
>So, what is the limit on UDP size messages (besides the 16 bit length
>field limit)?  Is 2048 bytes per UDP datagram the limit?
>
>Thanks
>Brian
>-----
>field@cs.pitt.edu

Sending more than (1500-UDP&IP header length) over an ethernet connection
requires IP to fragment the data upon transmission. This isn't a very
common case, since protocols like TCP automatically reduce transmitted
packets to a reasonably size (like 1K or 536 bytes). Since IP isn't called
to fragment upon transmission very often, it isn't very well tested.
Even a UDP based protocol like TFTP automatically blocks data into 512 data
bytes, so IP never has to fragment here either.

I remember having similar weird problems when testing an IP implementation.
In order to test the IP reassembly,we sent UDP packets from a Sun 3/80
that were roughly 2K in length. At a certain size, things just didn't
work right, and after several hours of head scratching and network monitoring
we finally deduced that something was amiss in the Sun UDP transmission.
We didn't pursue the thing further, though; we had no intention of debugging
the whole Sun network code! :-) I don't even remember at what size things
went wrong, but your 2K rings a bell...

-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 08:49:29 GMT
From:      mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@uunet.uu.net  (Peter Mutsaers /100000)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
craig@bbn.com (Craig Partridge) writes:

>>There may well be another reason not to use TCP. I for example am busy
>>with distributing programs over dozens of workstations. Every program
>>must be able to talk to any other one, 30 TCP connections is often the
>>maximum possible.
>>I could automatically close a connection if a new one must be opened, but
>>how do I know if no data is to be read, or underway, to the connection
>>I want to close?

>So building a "reliable UDP" is essentially as difficult as doing a TCP.
>And the only reason to do it is that your operating system constrains the
>number of connection blocks you can get, while the UDP interface allows
>you more connection blocks, because you can put the connection blocks in
>your application's memory space, rather than your kernel space (which is
>putting dumb restrictions on you).

But suppose I want 1000's of processes to be able to communicate. Couldn't
the overhead of just having that many connections become to big if
only few of them communicate at the same time? It would be very helpful 
if I could use TCP indeed, but have a kind of a 'safe' close, which does
indicate if more data could be underway.
Besides, for my particular application I use the select() system call, which
only operates on the lowest 32 file descriptors.

--
Peter Mutsaers                          email:    muts@fysaj.fys.ruu.nl     
Rijksuniversiteit Utrecht                         nmutsaer@ruunsa.fys.ruu.nl
Princetonplein 5                          tel:    (+31)-(0)30-533880
3584 CG Utrecht, Netherlands                                  
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 16:27:21 PDT
From:      jkrey@venera.isi.edu
To:        munnari.oz.au!uhccux!okumura@uunet.uu.net
Cc:        jkrey@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Please Help Me ! ! !
Chad,

You should find a copy of the "Hitchhiker's Guide to Internet"
(RFC1118) in your email.  Happy reading.

Joyce 


-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 10:17:03 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)



 >So if you could open a TCP connection to an IP multicast address, and
 >figure out how to handle the remote ends cleanly at the sender, you'd be
 >pretty far along.  > (And 1 sending workstation gets, at worst, 100
 >acks from 100 receivers -- less if receivers ack every 2nd segment).
 >I believe Van Jacobson and Jon Crowcroft looked at this problem in
 >more detail and may well have something more to add.

 Craig,

 we kind of figured out the small change necessary to TCP

essentially, you send to multicast address, but receive acks from each
member of the multicast groups individual clas a-c addresses

you have a tcpcb per member, and run each connection state machine as
normal, but link the tcpcb's so you know its a group communcation

to start the whole shebang, you send a syn to group, you get syn acks
back and gradually build up the set of tcpcb's (instead of just
alocating one at start)...when you have the full group connection, you
then allow the sender to do writes on the socket...

each write may block if we are still flow controlled or not acked on
any one connection...

for a many to one (i.e. lotsa folks sending to us) you can overload
the readv interface, and return a vector of single reads...

it shouldnt take a bright person with BSD source more than a day to
change, and a week to debug...

the same thing could be done with broadcast, without the multicast IP,
but is certainly a VERY BAD IDEA:-)

 jon

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 12:06:02 GMT
From:      usc!bbn.com!craig@ucsd.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <1666@ruunsa.fys.ruu.nl> muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) writes:
>
>>So building a "reliable UDP" is essentially as difficult as doing a TCP.
>>And the only reason to do it is that your operating system constrains the
>>number of connection blocks you can get, while the UDP interface allows
>>you more connection blocks, because you can put the connection blocks in
>>your application's memory space, rather than your kernel space (which is
>>putting dumb restrictions on you).
>
>But suppose I want 1000's of processes to be able to communicate. Couldn't
>the overhead of just having that many connections become to big if
>only few of them communicate at the same time?

Let me repeat my assertion, slightly differently.  IF you want reliability,
THEN you have no choice but to have connection blocks.  If you have 1,000's
of processes continuously talking, you will have 1,000s (or more) connection
blocks.  If they are not continuously talking, then you can just as easily
deallocate TCP connection blocks as "reliable UDP" connection blocks.

>Besides, for my particular application I use the select() system call, which
>only operates on the lowest 32 file descriptors.

This has suddenly become a UNIX discussion, but read the manual page
again.  Select uses arbitrary sized bitmasks, and takes a parameter
telling it how large the bitmasks passed to it are.  [32 is just the
maximum size some systems support].

Craig
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 11:17:03 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)


 >So if you could open a TCP connection to an IP multicast address, and
 >figure out how to handle the remote ends cleanly at the sender, you'd be
 >pretty far along.  > (And 1 sending workstation gets, at worst, 100
 >acks from 100 receivers -- less if receivers ack every 2nd segment).
 >I believe Van Jacobson and Jon Crowcroft looked at this problem in
 >more detail and may well have something more to add.

 Craig,

 we kind of figured out the small change necessary to TCP

essentially, you send to multicast address, but receive acks from each
member of the multicast groups individual clas a-c addresses

you have a tcpcb per member, and run each connection state machine as
normal, but link the tcpcb's so you know its a group communcation

to start the whole shebang, you send a syn to group, you get syn acks
back and gradually build up the set of tcpcb's (instead of just
alocating one at start)...when you have the full group connection, you
then allow the sender to do writes on the socket...

each write may block if we are still flow controlled or not acked on
any one connection...

for a many to one (i.e. lotsa folks sending to us) you can overload
the readv interface, and return a vector of single reads...

it shouldnt take a bright person with BSD source more than a day to
change, and a week to debug...

the same thing could be done with broadcast, without the multicast IP,
but is certainly a VERY BAD IDEA:-)

 jon

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 13:30:36 GMT
From:      mcsun!inria!mirsa!jerry.inria.fr!huitema@uunet.uu.net  (Christian Huitema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
The subject of reliable broadcast protocols had been adressed in the early 80's
in two different contexts, i.e. satellite networks and distributed systems. 

An interesting approach to the use of broadcast addresses for distributed
systems (in fact, broadcast LANs) is that of Dr. Maxemchuck, which proposed a
token passing "conference" protocol. Basically, the station which receives the
token synchronize first with the previous stations, requesting a copy of all
"missed" messages; options are to deliver this copy "point to point" or
globally. The procedure uses a single packet counter, and maintains a global
ordering of the messages -- which is indeed very useful for managing
consistently a given systems. It sort of minimizes the ack flow, as acks are
only transmitted during the token exchange; there is however a large overhead
in semi silent systems, due to the rotations of the token.

As far as satellite network are concerned, a quite exhaustive work was
conducted at INRIA in the NADIR project between 1981 and 1985, for devolopping
a performant and reliable "bulk broadcasting" protocol. In this protocol, the
need for "1 ACK per station per packet" was alleviated by assuming a constant
(unidirectional) message flow; the ACK are explicitly requested at well spaced
"check points", e.g. at end of file. An option is to use unsollicited "NACKs"
in order to request rapid resynchronisation of a particular recipient; another
option to pass a list of "missing packets ids" upon a check point. These
protocol variants have been described in several papers by the members of the
project, e.g. J-L. Grange', I. Valet, J. Radureau or myself. The project is now
terminated, and I am not aware of any continuation work.

The use of either of these techniques in an internet (by constrast with a
simple LAN or a controlled satellite channel) would pose at least two severe
problems:

* a group composition problems: in order to control the reception by "a group",
one must be able to individually identify all the members of a group. What if
this membership changes in the course of time?

* a potentially severe flow control problem: when the routes to the members of
the group have widely different capacities, how does one organize the slow down
of the transmission to match the most constrained channel?

Anyhow, this could be the basis of an interesting research work...

Christian Huitema
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 22:39:09 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        allan@cisco.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Intelligent bridges vs. routers
Allan Leinwand of cisco writes:
> 
> I can think of a few downfalls other than broadcast storms:
> 
>    1.  an intelligent bridge will not separate your address space like a
> router.  Thus, your two subnets will exist on one logical LAN.  This
> may result in configuring routers to understand this situation.
> 
Alan, it is disingenuous to argue the case of routers vs bridges on the 
basis of the damage that bridges inflict on the router.  

More importantly, routers impose an absolutely necessary management
overhead on the installer/user of the router, while bridges can be
plug and play (for the simple bridging functions).  I have seen articles
written by network managers of two major corporations ogling over their
routers and all the wonderful ingenious schemes that they came up with
to partition their subnets and address spaces so that they could use
their routers.  While they struggled to deal with organizational movements
and the subsequent impact on address allocations, they could have simply
moved the users in a bridged environment and be done with it.

The burden of planning and administering a routered system is neglected
by purveyors of routers to the detriment of innocent users who view 
routers as a better alternative to bridges.  More about this issue later.

>    2.  a bridge will not allow you to control the network for security
> reasons as well as a router if you are running multiple protocols (such
> as IP and DECnet).  With a bridge all of your security control is usually
> based upon the MAC level address of a host.  Keeping up with boards
> swaps and changing MAC addresses can become a configuration nightmare.
> With a router, the security can usually be setup to understand the
> network protocol level addresses.  This usually makes security
> management a bit easier.
> 
Here too, you are furthering half truths.  Stopping at the network
layer is not the magical solution.  You imply that the MAC address
is insufficient, yet you make the point that protocol independence is
a necessary attribute of security.   I agree with your assertion that
the router can more finely control its activity.  Today's bridges, however,
offer filtering options which can effectively accomplish the same task,
via protocol filtering and masking.  Moreover, we find it quite usefule
to specify the MAC address of those machines which we permit to access
the net, regardless of the protocols they use.  I can also argue that
the next layer up would offer an even finer level of control, and stopping
at the IP layer is not necessarily the optimal answer.  Kerberos offers
an even better answer.

The conclusion is that routers offer a different, finer granularity, and
more complex form of access control, which may be appropriate in certain
cases.

>    3.  dare I say this?  With many routers having SNMP agents, this
> gives you a basis for network management.  Yet, (contradicting myself
> :-)) some bridges now answer SNMP.
> 
In the 89 Interop, we demonstrated several bridges with SNMP management.  This
argument is clearly a red herring.

>    4.  the cost of a low end, two port router (which has router
> functionality AND bridge functionality) may surprise you....
> 
Touche.  Your recent announcement is indeed a triumph and an innovation.
It still does not replace bridges.  You do not need to denigrate bridges
in order to gain a place for routers  -- they are not head to head
competitors.  In competitive situations, vendors often pitch one
against the other, based on the rule that you sell what you have, or
what will win the bid.  Nevertheless, routers have a role in backbone
applications, in wide area applications, and in cases where the address
management features are fruitfully applicable.  Bridges have an equally
important role in subnet traffic management, and providing connectivity
behind the backbone, within a building, or within a facility.  Bridges
will remain easier and cheaper to operate simply because they operate
at lower levels than routers.  Similarly, repeaters operate at an even
lower level, and are correspondingly easier to administer.

> Thanks,
> 
> Allan Leinwand
> cisco Systems
> leinwand@cisco.com
> 
You're welcome.

-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 16:01:55 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: question about SMTP MX records


> Ouch, Craig, I hope I didn't hear you say that every host X that is
> an MX for another host Y is required to support the percent hack,
> that is, treat user%Y@X equivalently to user@Y?

RFC 1123 doesn't explicitly require it, but it suggests that support
for the %-hack is expected (the discussion in Section 5.2.16 being
my primary source).

Craig

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 23:05:13 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        cpw%snow-white@LANL.GOV (C. Philip Wood)
Cc:        tcp-ip@nic.ddn.mil, peterf@lanslide.hls.com (Peter Filice), mark@elmer.hls.com (Mark Gang)
Subject:   Re: SNMP monitors]
Several messages have recently flamed SNMP, perhaps as a reaction
to or byproduct of the Marshall and Karl debate society.  The comments
are incongruous since both ICMP and SNMP and other techniques have
a role to play in the process of installing, monitoring, maintaining,
testing and diagnosing a network.

Although SNMP is a relatively recent development, and is a popular
protocol targeted at network management applications, its developers
never claimed that it should replace all other techniques and
applications.  It also does not address all network managment
issues.  The flavor of universal ompnipotence and the consequent
exclusion of all other methods, techniques and applications is 
a byproduct of simplistic jounalistic reporting that afflicts our
industry, and of marketing hype.

SNMP is intended to manage operational networks.  The fact that
a router between manager X and device Y has failed does not preclude
the manager station from using out-of-band (i.e. non ethernet) 
transmission channels to reach device Y.  The lack of robustness
is to a large extent an application design shortcoming, not an
attribute of the protocol.  

The layering of the protocol in its most popular incarnation (over
UDP) is also not an inherent aspect of the protocol, although it
is highly recommended.  Poor network design may have as much to do
with preventing the operation of SNMP 'links' to managed devices, as
does the depedence on IP.  

Clearly, however, it is necessary to use tools other than and in addition 
to SNMP to bring up the network.  These include Ping.  At a higher layer, it
may be necessary to use PING-LIKE techniques to bounce data from EIA ports
for example.  Here again SNMP is not directly applicable.  

The conclusions are:

	1. SNMP is a useful, interoperable protocol
	2. It is not the sole and universal protocol
	3. SNMP is not a replacement for well thought out, practical
	   management applications  -- it is an application tool
	4. Poor design of network facilities and fallback routes is
	   not an attribute of the protocol.
 

-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 1990  22:48 MDT
From:      "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
To:        Jan.Engvald@LDC.LU.SE
Cc:        WANCHO@WSMR-SIMTEL20.ARMY.MIL, TCP-IP@NIC.DDN.MIL
Subject:   LANtastic on the backbone
Jan,

Artisoft added support to use the Ethernet-2 compatible packets in
"all recent versions" of their AILANBIOS by the use of the /XEROX
option on the AILANBIOS command line.  If you type AILANBIOS /HELP and
XEROX shows up in the list of switches, your copy supports the option.

--Frank
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 16:55:59 GMT
From:      Z.Wang@CS.UCL.AC.UK (Zheng Wang)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable Datagram Protocols

The easiest way of getting a "reliable datagram" is to run IP over TCP :-)

Zheng

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 17:23:16 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   How can you tell when too many ethernet collisions are occuring?

Does anyone have any information (or can you point me at some) regarding the
number of expected ethernet collisions given some network utilization.  I can
well imagine one needs to consider (the distribution of) frame size and access
patterns.  I'm interested in knowing when the number of collisions occuring is
excessive.

Any info is appreciated.  Thanks.
mb

booloo@lll-crg.llnl.gov
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 17:59:41 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!buit13!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP monitors
In article <9010251553.AA02760@nisc.jvnc.net>
 aggarwal@NISC.JVNC.NET (Vikas Aggarwal) writes:
>
>Another fact is that systems supporting SNMP do not consider snmp as a
>high priority task- as a result I have  routers that do not respond to
>SNMP  is they are busy passing  traffic. As a  consequence, during the
>better parts of  most afternoons, I would  have sites change status to
>"unknown" or "down" all the time because the routers would not respond
>to SNMP.
>
	SNMP should be given higher priority as ICMP usually is, but
that does not guarantee that CPU utilization will be requested by the
network management station.  Perhaps you are lucky that your routers
are telling you something you need to know that you otherwise would
not ask.  Even though you are unable to get your routers to respond to
SNMP queries, this situation is indirectly giving you network
management information that you could use.

	Go forth and upgrade your router CPUs and add memory or go get
skinnier pipes for your overwrought routers.

	--Kent
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Oct 90 17:55:59 +0100
From:      Zheng Wang <Z.Wang@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram Protocols
The easiest way of getting a "reliable datagram" is to run IP over TCP :-)

Zheng
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 21:29:56 GMT
From:      amdahl!datta@apple.com  (Diptish Datta)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet echo negotiation question
Does any one out there know of two machines communicating with the
telnet protocol and not using remote echo? If so, then the remote server
should not be echoing characters typed in at the client and the local
client should echo the keyboard entries to the screen - right?
Well, I have a lana analyzer trace of a MVS machine logging in to a
Unisys unix machine. The MVS machine seems to negotiate no remote echo
but it looks to me like the remote machine echoes data any way.

Here is what the echo option negotiation looks like:

C   <------  will echo          S
L            dont echo ------>  E
I   <------  wont echng the server not to echo
E            dont echo ------>  V
N            wont echo ------>  E
T   <------  dont echo          R

The way I read this is that the server offers to echo, the client refuses,
and server agrees.
Then the client says that he wont echo and server says no problem.

Then I see the login prompt from the server and the user id data from the
client. The server then echoes the user id right back!

Basically the Unisys machine seems to have negotiated no remote echo but
echoes anyway. Does any one out there have an explanation?

Mail direct to me at datta@amdahl.uts.amdahl.com
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 90 22:54:55 GMT
From:      munnari.oz.au!uhccux!okumura@uunet.uu.net  (Chad Okumura)
To:        tcp-ip@nic.ddn.mil
Subject:   Thanks for the HHGs

	Hi.  This is chad...thanks for sending me all the stuff on 
the Hitchhiker's guide to Internet...you can all stop now...my mbox
is overloaded already...THANKS SOOOO MUCH ! ! !  I appreciate you
your prompt responses....

===============================================================================
--chad					|  "A cat will blink when struck
University of Hawaii			|   with a hammer."
Computing Center			|
===============================================================================
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 90 01:37:04 GMT
From:      portal!cup.portal.com!lan@apple.com  (Los Altos Networks)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Misposting Apology

	We would like to acknowledge and apologize for our wreckless
	misuse of the network and, in particular, this newsgroup.  Our
	lack of proper netiquette and knowledge of network guidelines
	has given us a hard lesson, but one that will also serve as a
	good lesson to us on the proper treatment of the network and
	its community of users.

	We have been properly repremanded by the network users,
	authority, and the Portal Communications supervisors, and
	will adhere to their guidelines, as well.

	Once again, we are sorry for this inconvenience.  We thank you
	for your comments, suggestions, opinions, and patience in 
	concerns to our trespass.

	Los Alto Networks
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 90 07:12:00 GMT
From:      eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Batched SMTP (was Reliable Datagram ??? Protocols)
Phil Karn <karn@envy.bellcore.com> writes,
in article <1990Oct25.165545@envy.bellcore.com>:
>>> While we're on the subject of piggybacking, another thing I would
>>> really like to see is widespread use of batched SMTP on the Internet.
>>> I think the number of packets it takes for most SMTP implementations
>>> to transfer a short mail message is criminal, especially when the
>>> message has several recipients on the same system.  There's no reason
>>> that you shouldn't be able to send a series of SMTP commands in a
>>> single TCP segment and receive a series of responses, except that many
>>> SMTP servers inexplicably blow up when you try this. Given that TCP is
>>> supposed to be a reliable byte stream protocol, the designers of these
>>> systems must have gone well out of their way to keep this from working.

If you do this, it isn't SMTP.

RFC821, page 37:

   4.3.  SEQUENCING OF COMMANDS AND REPLIES

      The communication between the sender and receiver is intended to
      be an alternating dialogue, controlled by the sender.  As such,
      the sender issues a command and the receiver responds with a
      reply.  The sender must wait for this response before sending
      further commands.

In recently standardized parlance, the session is two-way alternate
(a.k.a. half-duplex) with implicit turn giving.

I assume that you mean that batching should be done as follows:

In the first segment, send

	HELO
	MAIL
	RCPT...

wait for and check incoming 250 results, then

	DATA
	<blast>
	.
	QUIT

in the next segment if all went well, otherwise send a QUIT, only.

So we have this minimal packet exchange with a conforming SMTP server:

	  SMTP Client			  SMTP Server
	SYN
					SYN+ACK + "220"
	ACK + "HELO/MAIL/RCPT..."
					ACK + "250"
	ACK
					"250"
{	ACK
					"250"		}  repeat
	ACK + "DATA/msg/./QUIT"
					ACK + "354"
	ACK
					"250"
	ACK
					FIN + "221"
	FIN+ACK
					ACK

We could be really, really optimistic and assume that the server was
aware of the status of the incoming queue, and make it like this:

	  SMTP Client			  SMTP Server
	SYN
					SYN+ACK + "220"
	ACK + "HELO/MAIL/RCPT..."
					ACK + "250/250/250..."
	ACK + "DATA/msg/./QUIT"
					ACK + "354/250/221"
	ACK+FIN
					FIN+ACK
	ACK

Alternatively, we could be really perverse and do this:

	  SMTP Client			  SMTP Server
	SYN + "HELO/MAIL/RCPT..."
					SYN+ACK + "220/250/250/250..."
	ACK+FIN + "DATA/msg/./QUIT"
					ACK+FIN "354/250/221"
	ACK

There are several immense problems in this scheme, and the very desire
to minimize use of sequence number space like this.

Unless we tell TCP not to send ACKs before we have written all we need
to it and do a PUSH, replies will not be piggy-backed on ACKs, and
those will be two segments instead of one.

Unless the SMTP server knows that there is more input, it can't delay
the PUSH until all input is processed, which will be separate segments
with separate ACKs, unless the SMTP client knows that more is coming,
and can tell TCP not to ACK until it writes more data and does a PUSH.

Unless we redefine SMTP to allow commands before the 220 reply, we
can't send HELO before we get it.

Unless we redefine SMTP to allow commands to be sent before the reply
to the previous command has been received, we can't group commands.

Unless we disregard the wasted processing and the behavior when
receiving an out-of-sequence RCPT by the server when the MAIL is
rejected, we can't group MAIL and the first RCPT.

Unless we're very brilliant with respect to the individual 25x and 55x
replies to the RCPTs, we shouldn't group them.

Unless we ignore all sorts of local problems at the server side, we
can't group DATA and the message, and in particular, we can't group
DATA, the message, AND the final dot.

Unless we demand only one connection per message or ignore message
delivery problems at a late stage, we shouldn't group the final dot
and the QUIT.

Unless the STMP server is able to recognize the QUIT properly, it
can't set the FIN bit in the last data segment.

Unless we have support for half-closing connections, the SMTP client
can't group the FIN and the QUIT, again unless you redefine SMTP not
to acknowledge the QUIT with a 221.

I think I have pointed to several severe problems in control and
status information propagation between TCP and the application, some
problems in end-to-end application acks of operations, and that these,
by themselves, make it very inappropriate to squeeze the living
daylight out of SMTP.  In result, I think that we will produce a lot
of hair on the client side to take care of a server which thinks it's
seeing and replying to individual commands, and that the gain in
number of packets will be minimal, such as three, in the common case.

				 ---

Rather, if you want a fast, inexpensive mail transfer protocol, define
one with two pieces of information transferred and acked:

	Envelope

	Message

One pair per exchange, and the FIN bit used as the end-of-message
indicator, if you can handle one-sided close operations gracefully.
Most operating systems doesn't support this feature.  (I.e. the last
data segment has FIN set, but it still awaits a data segment with the
other side's FIN segment.)  It could go like this:

	  FMDP client			  FMDP server
	SYN + Envelope
					SYN+ACK + Envelope OK
	ACK+FIN + Message
					ACK+FIN + Message OK
	ACK

FMDP stands for "Futuristic Message Delivery Protocol".

Most probably, you will get something on the order of:

	  FMDP client			  FMDP server
	SYN
					SYN+ACK
	ACK
	Envelope
					ACK
					Envelope OK
	ACK
	Message
					ACK
	FIN
					ACK
					Message OK
	ACK
					FIN
	ACK

If you know the size of the message, you can send that information in
the envelope and relieve yourself of the one-sided close problem.

I believe this scheme has been used in a different set of protocols,
which has its own set of fans, not necessarily on this list/group.

				 ---

I like SMTP the way it is.  That doesn't mean I dislike improvements,
just don't call them SMTP, and don't expect my SMTP client or server
to accept your bogus idea of what the underlying transport protocol
provides and I therefore have to accept at a higher layer.  Just
because ARM (Arpanet Reference Model) doesn't have a session layer,
doesn't mean it isn't implicit in some of the protocols.  ARM just
doesn't think it's worth a whole layer.  That's why.  Try pulling the
plug at the Session layer to the mighty Priests of the Holy Seven, and
they'll react with even more rationale for it's existence than I have
provided above.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427
--
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Oct 90 12:04:32 EDT
From:      Christopher Maeda <cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU>
To:        lll-crg.llnl.gov@lll-winken.llnl.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   How can you tell when too many ethernet collisions are occuring?
Roy Maxion did a paper on this in the last Fault Tolerant Computing
Conference (FTCS-20).  Basically, he keeps a vector of expected values
for collisions (also load, packet counts, etc) for each monitoring
epoch (currently 1 minute).  Newly observed data is compared with the
expected values and alarms are triggered if the values are not
consistent with expectations.  Note that the meaning of "consistent
with expectations" is a topic of current research.  One heuristic is
if the number of collisions is 3 stds above the mean.  The models are
also updated to take new observations into account using a kind of
exponential regression

Chris

ps:

Maxion, Roy A., Anomaly Detection for Diagnosis.  In 20th
International Symposium on Fault-Tolerant Computing (FTCS20),
(1990) 20-27.
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Oct 90 21:10:01 MDT
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        jhereg!imp
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet & IPX
In reply to your message of 25 Oct 90 01:14:41 GMT
-------
> This is correct, but does not guarantee coexistence.  Remember that all VAX
> Ethernet controllers are Version 2 devices, NOT 802.3 devices.  Netware, on
> the other hand, DEFAULTS to 802.3 operation.  While you can certainly run
> both protocols simultaneously on the same cable, if you want to gateway the
> two environments, you have to backpatch the IPX card drivers with a utility
> called 'econfig.'  Basically, econfig allows you to select whether you want
> your Novell net to run using Ethernet Version 2 (type field IPX=8037) or
> 802.3 (length field).

Actually, what Novell calls 802.3 is not quite what the rest of the world
thinks of as 802.3.  Novell is 802.3 at the MAC level and used the 802.3
length field.  They do not then use an 802.2 LLC layer as the rest of the
world does and thus frequently cannot coexist on a true 802.3 based LAN.

In any mixed environment, it would probably be best to econfig all the
Netware systems anyway since there are systems that have problems dealing
with the Novell broadcast packets that also appear to have both LSAP values
(destination and source) being the broadcast SAP.

Its too bad Novell chose to implement something that almost follows the IEEE
standards rather than doing the nearly trivial additional work to do it
"right".

Doug McCallum
dougm@ico.isc.com
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 90 16:04:32 GMT
From:      cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   How can you tell when too many ethernet collisions are occuring?

Roy Maxion did a paper on this in the last Fault Tolerant Computing
Conference (FTCS-20).  Basically, he keeps a vector of expected values
for collisions (also load, packet counts, etc) for each monitoring
epoch (currently 1 minute).  Newly observed data is compared with the
expected values and alarms are triggered if the values are not
consistent with expectations.  Note that the meaning of "consistent
with expectations" is a topic of current research.  One heuristic is
if the number of collisions is 3 stds above the mean.  The models are
also updated to take new observations into account using a kind of
exponential regression

Chris

ps:

Maxion, Roy A., Anomaly Detection for Diagnosis.  In 20th
International Symposium on Fault-Tolerant Computing (FTCS20),
(1990) 20-27.

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 90 20:02:47 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How can you tell when too many ethernet collisions are occuring?
In article <9010271814.AA17575@ucbvax.Berkeley.EDU>, cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda) writes:
> Roy Maxion did a paper on this in the last Fault Tolerant Computing
> Conference (FTCS-20).  Basically, he keeps a vector of expected values
> for collisions (also load, packet counts, etc) ...


This work is interesting for detecting anomalies like suddenly broken
hardware, but how do you know if your net is "normally" overloaded?  If you
have 90% collisions every day between 10 am and 4 pm, the envelope/standard
deviation calculation will tell you that everything is just peachy.

We've been using a rule of thumb that says if more than 30% of an active
station's packets collide, it is time to split the network.  That is, does
it make sense to say things are bad if the quotient of the "Opkts" and
"Coll" columns of netstat are >= .3, provided Opkts>100,000?  Ethernets
that met this criterion here have been painfully slow.

(Yes, rather BSD-network-UNIX oriented.  Sorry.)


Vernon Schryver,    vjs@sgi.com
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Oct 90 17:42:47 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   ISDN RRs/RFC 1183 opinions sought
I'm curious about people's opinions on the ISDN provisions of RFC 1183,
"New DNS RR Definitions", C. Everhart, L. Mamakos, R. Ullmann, P.
Mockapetris.  Do people think these RRs are useful?  Are they likely to
be used?  How were they intended to be used?  How would these integrate 
routing protocols?

The description in RFC 1183 seems a bit confusing to me.  In particular,
 domains like "Relay.Prime.COM" are used, rather than domains like
IN-ADDR.ARPA.  I imagine the intended purpose of the ISDN RR is to be
able to automatically establishe connections over an ISDN link upon
receipt of the first IP packet.  I would think that you would want to do
lookups by IP address, although I can imagine looking for a PTR record
first and then looking for a corresponding ISDN record.

I also find it confusing exactly how the RT record is intended to work.

Here's one scenario that I think these might be useful in.  Imagine two
isolated island networks NA and NB, such as might exist in two companies
or universities.  Each island network has a one or more routers, maybe
RC and RD, with ISDN connections which can establish links to other
networks.  Now let's say I try to telnet from one non-ISDN machine HE on
network NA to a non-ISDN machine HR on network NB.  One way I could
imagine things working is that router RC might advertise a default route
to hosts on its network including HE.  So, when I telnet, HE would send
its packets to RC.  Now, when RC received the packet addressed to HF, it
might look up RRs for HF and it might find an RT RR for RD.  Looking up
RD it might find an ISDN RR with RD's number.  It could then forward the
packet through to RD, which would then forward it to HF.  HF's response
would hopefully be sent back through RD (due to having corrrect updated
routing information) which would then realize that it already has a
connection open to RC, and would simply send it through.

When we start scaling this simple example up, I see a lot of problems
start popping up.  Imagine I just have a single host (at home maybe)
with an ISDN connection.  Now, I want to telnet to a host which is
somewhere on the Internet, behind maybe dozens of router hops.  It's
hard to imagine that every host on the internet will have an RT RR in
the DNS.  If I were a random site with hosts on the Internet, but no
ISDN connections, what RT RR would I want to advertise?  There might be
thousands of other hosts/routers on the Internet with ISDN connections. 
Which would I choose, and how?

Drew
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 90 11:35:17 GMT
From:      eru!hagbard!sunic!mcsun!ukc!slxsys!dircon!sys0001@BLOOM-BEACON.MIT.EDU  (Ben Knox)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP on SCO
I have some questions about TCP/IP on SCO UNIX:
 
1. If I have two PCs running UNIX, will I need to buy two separate copies
of SCO's TCP/IP package -- one for each system? (or can I buy one copy but
two serial numbers/activation keys).
 
2. If I want to later upgrade to NFS, will I need two separate copies of that
as well?
 
3. Which Ethernet cards are supported. Which is the most reliable, best
supported etc (and least likely to conflict with other hardware -- especially
Adaptec 1542B disk controller and VEGA 8-bit VGA card)?
 
4. Is it possible to use (cheaper) unbranded Ethernet cards?

5. What is the difference between thicknet and thin-net? What is 10BASET?
 
6. Can I perform backup to tape across the network under TCP/IP (using tar,
ctar or...?)?
 
7. Is it possible to use one of the PD TCP/IP packages on a DOS PC to
perform TCP logins and file transfers with SCO's package? If so, which is
best for this purpose?
 
8. What are 'packet drivers' and TCP/IP boot PROMS ...do I need them?
 
9. Are there any other things I should consider before buying and installing
the network?

10. Can anyone recommend any good books or papers which cover the practical 
aspects of TCP/IP Lans, bridging between lans, ethernet etc?
 
My configuration is: SCO UNIX 3.2.2 on two 16MHz 386s (these may be upgraded
to faster systems at a later date).
 
Please reply by email.

Thank you!

-- 
sys0001@dircon.UUCP   or   sys0001%dircon@ukc.ac.uk
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Oct 90 19:38:58 PST
From:      christopher raczka <chris@ecdnt5.enet.dec.com>
To:        tcp-ip@nic.ddn.mil
Subject:   RE: Internet/NSFNet proposal to be run by IBM -- call to action!
Cc: DECWRL::"chris@ecdnt5.enet.dec.com", chris
 
 
I think many people share Karl Denninger's feelings and Karl you are right
people will have to speak up an be heard
 
I also think the "other side" of the story does need to be told and this
much I do know...
 
Sometime in September, Merit, IBM Corp, and MCI established Advanced
Network and Services Inc. (ANS)
 
ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET
backbone under subcontract to Merit
 
Allan Weis was named President and CEO
 
IBM and MCI are funding ANS, and Merit is providing Network Operations,
Network engineering, network planning and network services.
 
I'm not sure if Eric Aupperle (Merit President) reads this newsgroup
but it would be interesting to hear Merit's feelings on this, both
as a compnay and some personal feelings
 
Anyone from Merit care to offer any insight?
 
regards,
christopher raczka
DIGITAL Equipment
e-mail: chris@ecdnt5.enet.dec.com
phone:  313-347-5108
=============================================================================
My opinions DO NOT reflect those of DIGITAL Equipment Corporation
and sometimes vice versa
=============================================================================
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 06:22:54 -0800
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        ddsw1!karl@gargoyle.uchicago.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Internet/NSFNet proposal to be run by IBM -- call to action!
>This is a call to action by all interested parties.

>There is wind of a proposal stirring in Washington that would place the
>NSFNet backbone, and eventually the entire government-run part of the
>Internet, into the hands of IBM.

>IBM has supposedly pledged to run this on a non-profit basis for some
>number of years.   Of course, the number that's being bandied about is
>small, like "2".....

This is, more or less, standard for Government service contracts.  Two years
on the basic contract with 1 to 3 optional extensions of 1 year each.

>Anyone want to bet how long the Internet remains accessible to non-IBM
>people?  Or whether the Internet ends up another Prodidy, with active
>censorship?  Whether you'll have to buy an IBM system to hook into it,
>since they might decide that TCP/IP is no longer any good and now it's
>time to go to SNA or worse?

I guess we could have Digital with DECnet, ALL-IN-FUN, or OSI; Apple with
AppleTalk; Novell with NETWARE; usw.

>Folks, if you love the Internet, and want to see it expand and grow, we need
>to insure that a few things happen:

>1)      The "acceptable use" policy on the NSFNet needs to be scrapped.
>        Sure, this will bring problems.  But it will also mean that
>        commercial companies can tie in, pay their fair share, and make sure
>        that the network capacity has the funding to continue to grow.

>2)      The backbone needs to be run as a regulated commodity.  Perhaps even
>        run by the Government, strange as that may seem.  The goal of
>        universal connectivity is not that far off right now, but there are
>        companies and special interests who would like to see that never
>        happen.  We MUST insure that it does.

It is run by the Government!  How does the Government provide technical sup-
port and services?  Does it hire people to do it?  No.  It issues contracts
to profit or non-profit companies and consortiums.

>3)      We must maintain and increase our lead as the information-processing
>        leader in the world.  It's the only area of superiority that we have
>        left in world markets.  A universally-accessible Internet is one way
>        to achieve this goal.  Face it, the "bright minds" aren't all in
>        colleges or doing business with schools or the government.  Many are
>        in private industry or independant, and they should have access to
>        this resource as well.

I believe we might be superior in farming.  I suspect we may be ahead in
networking only because of the absence of Harvard Business School graduates
and their short term management philosophies.

>4)      Finally, a freely accessible information exchange medium may be the
>        second-best guarantee of freedom in this country (the first being
>        the ability of the people to depose a despotic government).  By
>        keeping the passing of information from coast to coast available,
>        fast and cheap, we keep the people informed.

>How to proceed:
>        1)      A tax on access devices for the network may be the best
>                way to fund it.  I'm not sure about this, but it seems as
>                though a "user fee" is one of the better ways to pay for the
>                connectivity that we all enjoy and want to see furthered.

The AT&T solution.  Assign a $2.00 monthly access fee on every modem regardless
of usage.  A wonderful solution!

>        2)      General subsidy isn't a bad idea either, but it's not ideal.
>                Selling it to the general public will be difficult,
>                especially with the things that hit the press now and again
>                about X-rated GIF sites and the like.

>        3)      Keep control in the hands of the many, or in the hands of a
>                non-profit corporation funded EXCLUSIVELY to run this beast.
>                Giving it to IBM or another pseudo-government company is as
>                good as letting the fox loose in the henhouse -- the
>                potential for abuse and profiteering is just too great to
>                ignore.

And now back to the MCI and IBM consortium who've proposed a non-profit corp-
oration funded EXCLUSIVELY to run this beast.  I wonder what a "pseudo-govern-
ment" company is?  Large?

Merton

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 90 17:53:50 GMT
From:      mcsun!inria!ircam!mf@uunet.uu.net  (Michel Fingerhut)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: French experience needed
Since I was the one to use this expression in a disgruntled article
about routing, let me confirm Erik Naggum's reply: "a fat lot of good
it does to me!".  Now back to tcp-ip (which is not about "talking
colloquial Parisian in public") business.
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 90 19:09:17 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@tut.cis.ohio-state.edu  (Matthias Urlichs)
To:        tcp-ip@nic.ddn.mil
Subject:   Batching vs lock-step
In comp.protocols.tcp-ip, article <1990Oct25.165545@envy.bellcore.com>,
  karn@thumper.bellcore.com writes:
< 
< While we're on the subject of piggybacking, another thing I would
< really like to see is widespread use of batched SMTP on the Internet.
< I think the number of packets it takes for most SMTP implementations
< to transfer a short mail message is criminal, especially when the
< message has several recipients on the same system.  There's no reason
< that you shouldn't be able to send a series of SMTP commands in a
< single TCP segment and receive a series of responses, except that many
< SMTP servers inexplicably blow up when you try this. Given that TCP is
< supposed to be a reliable byte stream protocol, the designers of these
< systems must have gone well out of their way to keep this from working.
< 
The problem is that on top of TCP there's the C stdio library which tends to
buffer your data when a program does an fgets().

After reading the first request, said program is likely to say "wait on the
 _connection_ for ten minutes until data become available".
No programmer bothers to examine the stdio buffer first becase
- the protocol is supposed to be lock-step anyway,
- examining a stdio buffer on whether it contains data is not standardized,
- the alternative is to use alarm() and signal(), but longjmp()ing from a
  signal handler back into a program, bypassing the stdio library on the way
  out, may not be what the system designers had in mind.

A side effect of this is that sending a single character to such an
implementation, and leaving the TCP stream open, will hang it indefinitely.
;-)

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 90 22:04:32 GMT
From:      ddsw1!karl@gargoyle.uchicago.edu  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet/NSFNet proposal to be run by IBM -- call to action!
This is a call to action by all interested parties.

There is wind of a proposal stirring in Washington that would place the 
NSFNet backbone, and eventually the entire government-run part of the 
Internet, into the hands of IBM.

IBM has supposedly pledged to run this on a non-profit basis for some 
number of years.   Of course, the number that's being bandied about is
small, like "2".....

Anyone want to bet how long the Internet remains accessible to non-IBM
people?  Or whether the Internet ends up another Prodidy, with active
censorship?  Whether you'll have to buy an IBM system to hook into it, 
since they might decide that TCP/IP is no longer any good and now it's 
time to go to SNA or worse?

Folks, if you love the Internet, and want to see it expand and grow, we need
to insure that a few things happen:

1) 	The "acceptable use" policy on the NSFNet needs to be scrapped.
	Sure, this will bring problems.  But it will also mean that
	commercial companies can tie in, pay their fair share, and make sure
	that the network capacity has the funding to continue to grow.

2)	The backbone needs to be run as a regulated commodity.  Perhaps even
	run by the Government, strange as that may seem.  The goal of
	universal connectivity is not that far off right now, but there are
	companies and special interests who would like to see that never
	happen.  We MUST insure that it does.

3)	We must maintain and increase our lead as the information-processing
	leader in the world.  It's the only area of superiority that we have
	left in world markets.  A universally-accessible Internet is one way
	to achieve this goal.  Face it, the "bright minds" aren't all in
	colleges or doing business with schools or the government.  Many are
	in private industry or independant, and they should have access to
	this resource as well.

4)	Finally, a freely accessible information exchange medium may be the
	second-best guarantee of freedom in this country (the first being
	the ability of the people to depose a despotic government).  By
	keeping the passing of information from coast to coast available, 
	fast and cheap, we keep the people informed.

How to proceed:
	1)	A tax on access devices for the network may be the best
		way to fund it.  I'm not sure about this, but it seems as
		though a "user fee" is one of the better ways to pay for the
		connectivity that we all enjoy and want to see furthered.

	2)	General subsidy isn't a bad idea either, but it's not ideal.
		Selling it to the general public will be difficult,
		especially with the things that hit the press now and again
		about X-rated GIF sites and the like.

	3)	Keep control in the hands of the many, or in the hands of a
		non-profit corporation funded EXCLUSIVELY to run this beast.
		Giving it to IBM or another pseudo-government company is as
		good as letting the fox loose in the henhouse -- the
		potential for abuse and profiteering is just too great to
		ignore.

Get involved NOW folks.  I didn't know about this until last night, and it
knocked my socks off.  People I've talked to think this is a universally bad
thing, but they don't know how to stop it.  I suggest that a million loud
voices would have a significant impact.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
Macro Computer Solutions, Inc.   "Quality Solutions at a Fair Price"
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 90 22:43:19 GMT
From:      stan!marvin!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: question about SMTP MX records
In article <9010270002.AA00258@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>RFC 1123 doesn't explicitly require it, but it suggests that support
>for the %-hack is expected (the discussion in Section 5.2.16 being
>my primary source).

However, in existing practice there is at least one mailer that uses
the % for a gateway between internet and decnet.  The address of the
form "imp%node.decnet@twg.com" will cause mail to be sent to NODE::IMP
from the internet host TWG.COM.  This being the case, mail sending
programs should not assume that <a%b@c> is the same as "<@c:a@b>".

Warner
--
Warner Losh		imp@Solbourne.COM
How does someone declare moral bankruptcy?
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 08:58:37 -0600
From:      "Craig A. Finseth" <fin@unet.unet.umn.edu>
To:        Gene.Saunders@West.Sun.COM
Cc:        snmp@nisc.nyser.net, tcp-ip@NIC.DDN.MIL
Subject:   SNMP monitors, clarification
Recently, Mr. Donald W. Garner (CADIG  STAFF) <don@usna.navy.MIL> asked:

>  >For example, the network monitoring here at the U uses ICMP Echo ...

>  Is that monitoring done by SunNet Manager?  Has anyone had any experience
>  with this package?

and I responded with:

>   Is that monitoring done by SunNet Manager?  Has anyone had any experience
>   with this package?

>No, it is a package that I wrote.  I wanted one that worked, not one
>that was pretty.  I don't know anything about SunNet.

Apparently my reply was worded so as to be ambiguous.  Unfortunately,
one of the interpretations (not the intended one) caused offense to
people at Sun Microsystems.  I apologize for the unintended offense.

The first part of my statement "I wanted one that worked, not one that
was pretty" referred to the package that I wrote, the second part
referred to the "SNMP graphics tools packages" that were mentioned to
in the original posting by Stev Knowles on 24 October.

The statement that I am not familiar with SunNet Manager is true.
Since I am not familiar with it, I do not know what category it falls
into (other than proprietary software, which makes it uninteresting to
us (:-)).  Hence, I did not forsee the ambiguity.

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 625 0006 problems
130 Lind Hall, 207 Church St SE		+1 612 626 1002 FAX
Minneapolis MN 55455-0134, U.S.A.

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 01:22:24 GMT
From:      zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick@tut.cis.ohio-state.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
Since TCP handles all errors, flow control, etc., about all your
trivial framing protocol needs to be is a byte count followed by the
data.  As long as your TCP implementation pushes every write (which is
typical of those that I know), this is about all you need.  In order
to catch coding errors, it's probably a good idea to include some way
of catching missynchronization, like some tacking on a -1 word at the
end of each message.

The esthetics of this do not bother me.  Converting messages to
streams and back will be a no-op in the simple case, and useful in
other cases.  That is, if you do single query and response, TCP will
simply send off your packets one by one, handling only the sorts of
issues you'd really rather not have to handle for yourself, such as
retransmission.  If you send more than one datagram in a given
direction (e.g. you respond to a query with lots of data), then
combining datagrams, sequencing, etc., are useful.  If TCP were really
a high-overhead thing, I'd worry about this, but lots of smart people
are putting lots of time into optimizing TCP.  They have almost
certainly done a better job than you will do.  The main places I
recommend avoiding TCP are when queries are being sent to varying
destinations, e.g. named, or when you need to use broadcasts.
And frankly I sometimes think it would have been better to have
done named only over TCP.
-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 01:33:54 GMT
From:      sdd.hp.com!mips!prls!pyramid!csg@ucsd.edu  (Carl S. Gutekunst)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1
and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build
a truly commercial TCP/IP service, give excellent service, and charge less
than $2000/month for it.

NSFNet is the government's network. Let them have it for anyone who wants to
live under the government's terms and conditions. Just as the Europeans are
throwing off the yokes of their PTTs, it's time for us to throw off the yoke
of state-sponsored communications networks, and start building our own.

<csg>
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 02:55:57 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@ucsd.edu  (Paul Graham)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
karl@mcs.MCS.COM (Karl Denninger) writes:
|There is wind of a proposal stirring in Washington that would place the 
|NSFNet backbone, and eventually the entire government-run part of the 
|Internet, into the hands of IBM.

people who are *really* concerned about this should first subscribe to,
and get the archives of, the commercialization/privitization mailing
list (com-priv-requests@psi.com).  this plan is generally well known
in the networking community and while there is no clear consensus i
don't think the degree of alarm displayed by the previous posting is
necessary.  in any event com-priv is an excellent place to move this
discussion since many of the movers and shakers are active there.

-- 
pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet)
opinions found above are mine unless marked otherwise.
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 11:04:08 EST
From:      Charles Lynn <clynn@BBN.COM>
To:        Phil Karn <bellcore-2!envy!karn@rutgers.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols
Doesn't TCP require the connection to be in the ESTABLISHED state before
it is permitted to deliver data to the application?  If so, I think B
cannot see the data until it gets the ACK of its SYN from A, thus the
response from B cannot be includes with B's SYN ACK.

Charlie
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 15:40:29 -0500
From:      Scott Brim <swb@chumley.TN.Cornell.EDU>
To:        sblair@synoptics.com (Steven Blair)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: *looking for implementations of RFC-1112*
We (Cornell, gated) and Proteon are both working on implementing routing
multicast packets in OSPF; Steve Deering's involved too.  After we get
that nailed down Cornell plans on building multicast support into either
BGP or IDPR.  although I expect the inter-administration protocols to be
significantly more difficult.  The algorithms are more or less worked
out for doing all of this, but it'll be a while.
							Scott

	I have several users who've recently become aware of RFC1112 written
	by S.Deering of Stanford(1989) on Host Extensions on IP Multicasting.
	
	We're reviewing the paper for possible interest. Questions are:
	
	1) Has any router/bridge company done this? If not, are any
	working on it.
	
	2) Are there any networks supporting this at this time? Or in
	the future?
	
	3) Any more interesting comments you can add to this.
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 07:48:43 GMT
From:      cs.utexas.edu!wuarchive!emory!rsiatl!jgd@tut.cis.ohio-state.edu  (John G. DeArmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
karl@ddsw1.MCS.COM (Karl Denninger) writes:

>This is a call to action by all interested parties.

>There is wind of a proposal stirring in Washington that would place the 
>NSFNet backbone, and eventually the entire government-run part of the 
>Internet, into the hands of IBM.

This is part of the disgusting Senator from my home state, Albert Gore,
Sr as part of his supernet that will cure all the nation's technology
ills, make is a world competator and brush our teeth, all in one
fell swoop.

He is being "assisted" by that "gentleman" we've all come to know
and loathe, (bob?) Abernathy of the Houston Chronicle.  Remember
the Great Internet Smut Controversy of 1990. Yep, same guy.
He posted to a mailing list the articles he wrote for the paper on the 
subject.  I didn't keep an archive copy but here's what I remember:

IBM and >>> Compuserv <<< have steped forward and volunteered to sink
about 10 million into the management effort.

They are proposing to institute a "user fee" schedule based on 
the quantity of data transmitted.

BUT they still propose to keep the network "closed" and only available
to those who have a "need" to be on there.

In other words, enjoy the Internet while it lasts because will soon
become a mutant offspring of an incestuous inbreeding of IBM, Compuserv,
and the government.  Can you imagine an ftp session that is billed by
the hour and by the bytes transfered all the while, advertisements 
scroll across the screen?  No smileys.

As is typical of Gore, he proposed to dump buckets of money into the 
project and create a backbone of gigabit-per-second links that no one
but the government could afford to interface to.  He calls upon those
old worn phrases of motherhood, apple pie, and another Apollo-like mission
to the moon of networks.

The articles that Abernathy writes glow so from yellow journalism that 
I feel that I need my cobalt glasses just to read them.  Even as
he promotes this grandois scheme, he executes a perfect self-pat-on-the
back by noting that a "controversy" has grown out of the exclusive
investigative article by the Chronicle.  Then he uses the previous
dose of yellow to justify a "remedy".  And we know how the Democrats
"remedy" a problem.  At least our wallets do.  Perhaps someone else on the 
list will post a couple of Abernathy's articles.

What to do?  As usual, make noise.  Lobby for incremental funding to
handle the growth of the internet, incremental funding for higher
speed technologies and the creation of a mechanism for commercial users with 
research as opposed to business need to get on the net.  Lobby for the 
congress to do that but otherwise leave what works alone.

And hey, if anyone out there has enough money to buy a congresslime, then
please do so.

(and just in case Abernathy wants to quote me out of context.) This
article is copyright 1990 John De Armond.  All rights reserved.
No journalistic use whatsoever permitted.

John

-- 
John De Armond, WD4OQC  | "The truly ignorant in our society are those people 
Radiation Systems, Inc. | who would throw away the parts of the Constitution 
Atlanta, Ga             | they find inconvenient."  -me   Defend the 2nd
{emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st.
-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 08:44:42 GMT
From:      pacbell.com!pacbell!indetech!fiver!palowoda@ucsd.edu  (Bob Palowoda)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
From article <1990Oct28.220432.521@ddsw1.MCS.COM>, by karl@ddsw1.MCS.COM (Karl Denninger):
> This is a call to action by all interested parties.
> 
> There is wind of a proposal stirring in Washington that would place the 
> NSFNet backbone, and eventually the entire government-run part of the 
> Internet, into the hands of IBM.

  This is a very bad idea. For one the Internet, NFSFNet, and all the
other local networks stand for something opposite of the corporate
sturctures. Don't get me wrong I think IBM is a good company but they
do not have a policy for controling goverment resources.     

> IBM has supposedly pledged to run this on a non-profit basis for some 
> number of years.   Of course, the number that's being bandied about is
> small, like "2".....

  If what you mean by "run" as in IBM runs the networks. NO this cannot
do. If they want to help why not give cash or equiptment donations to
NSFNet just as any other large corporation (i.e. Xerox) would give
to a public broadcasting station.   

> Anyone want to bet how long the Internet remains accessible to non-IBM
> people?

 I believe IBM has thier own network(s).

> Or whether the Internet ends up another Prodidy, with active
> censorship?

  This also brings up a point of conflict in interest. 

> 	3)	Keep control in the hands of the many, or in the hands of a
> 		non-profit corporation funded EXCLUSIVELY to run this beast.
> 		Giving it to IBM or another pseudo-government company is as
> 		good as letting the fox loose in the henhouse -- the
> 		potential for abuse and profiteering is just too great to
> 		ignore.

 I agree 100 percent. 

> Get involved NOW folks.  I didn't know about this until last night, and it
> knocked my socks off.  People I've talked to think this is a universally bad
> thing, but they don't know how to stop it.  I suggest that a million loud
> voices would have a significant impact.

  Is there any goverment email address we can write to about this?

---Bob

-- 
Bob Palowoda   palowoda@fiver              |   *Home of Fiver BBS*
Home {sun}!ys2!fiver!palowoda              | 415-623-8809 1200/2400
     {pacbell}!indetech!fiver!palowoda     |     An XBBS System                
Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 09:53:30 GMT
From:      schoenw@tubsibr.uucp (Juergen Schoenwaelder)
To:        comp.protocols.tcp-ip
Subject:   What is a SNMP community?

We have some confusion about the definition of a SNMP (Simple
Network Management Protocol) community. RFC 1157 says:

   "A pairing of an SNMP agent with some arbitrary set of SNMP
    application entities is called an SNMP community."

We think of a community as a management station with a set of
network elements running SNMP agents. Can anyone help us to
understand the definition given in RFC 1157 ?

-----
Juergen Schoenwaelder   (schoenw@tubsibr.uucp)
Technische Universitaet Braunschweig, Inst. f. Betriebssysteme & Rechnerverbund
Bueltenweg 74/75,  3300 Braunschweig, Germany, Tel. +0049 531 / 391-3101

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 10:00:46 GMT
From:      eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Batching vs lock-step
In article <cyt^f2.ck6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:

   The problem is that on top of TCP there's the C stdio library which tends to
   buffer your data when a program does an fgets().

   After reading the first request, said program is likely to say "wait on the
    _connection_ for ten minutes until data become available".
   No programmer bothers to examine the stdio buffer first becase
   - the protocol is supposed to be lock-step anyway,
   - examining a stdio buffer on whether it contains data is not standardized,
   - the alternative is to use alarm() and signal(), but longjmp()ing from a
     signal handler back into a program, bypassing the stdio library on the way
     out, may not be what the system designers had in mind.

   A side effect of this is that sending a single character to such an
   implementation, and leaving the TCP stream open, will hang it indefinitely.
   ;-)

I didn't get this.  Are you saying you switch between stdio routines
and raw socket reads at some point after the first fgets?

Why would anyone do this?

I've used the stdio library, which presents to me a stream of
characters, to read from sockets bound to a TCP port, and this maps
very elegantly on top of TCP, which is also a stream.  I haven't had
problems of any kind.

In particular, I can't think of any real situation where your "side
effect" would occur.

What are you doing?

Phil Karn wrote:
> Given that TCP is supposed to be a reliable byte stream protocol,
> the designers of these systems must have gone well out of their way
> to keep this from working.

If the above scenario is real, I agree completely with Phil, here.

I've seen NNTP get slightly confused when GNUS (a GNU Emacs news
reader) stuffed a whole bunch of command lines down its throat, and
the cause was that NNTP used select(2) to wait for input.  Apparently,
it read the data into a large buffer, strchr'ed for '\n', replaced it
with a '\0', and parsed the command.  Of course, this failed miserably
when GNUS was waiting for more than one reply code.  I don't think
this implies that the programmer has gone out of his way to keep it
from working, since he's only supposed to get one command line at a
time.  Anyway, it works with a conforming NNTP client, although a bit
on the "be conservative in what you accept and liberal in what you
send" side.

--
[Erik Naggum]		Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY
	I disclaim,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427
--
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 10:22:32 GMT
From:      eru!hagbard!sunic!news.funet.fi!funic!fuug!tuura!timok@bloom-beacon.mit.edu  (Timo Kettunen)
To:        tcp-ip@nic.ddn.mil
Subject:   JSB MultiView DeskTop 1.2 Network Supplement? What is it?

 Hi there,
 
I've got following problem:
 
When I'am trying to establish connection with JSB MultiView
DeskTop v1.2 via SCO TCP/IP to NFS-server using PC-NFS 3.0.1 on my
286 AT as a TCP/IP software  providing the connection, I experience
following error message:  	

	"JSB MultiView DeskTop Network Supplement not installed" 

 
and I'am unable to create the connection.
 
Does this message indicate that I lack the supplement on my AT
or on the host? What does this supplement contains? I have configured
the host to which I'm going to get the connection on my AT in \NFS\HOSTS file.
 
The connection works fine when I use FTP Software PC/TCP v2.04 as a
TCP/IP software providing the connection.


Thanks for any kind of help!

 
 	-timo-


-- 
-------------------------------------------------------------------------------
Timo Kettunen 	| +358-0-567 3143        | As the world becomes more primitive,
Nokia Data      | timok@yj.data.nokia.fi | it's treasures become more fabulous.
General Systems	| 			 |  -- Kiss Me Deadly, USA, 1955
-------------------------------------------------------------------------------
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 16:02:08 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Packet Driver for PRONET
Does anyone know the whereabouts of a packet driver that would let me run
TCPIP over PRONET with Proteon's cards??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 16:03:46 EST
From:      jordan@Morgan.COM (Jordan Hayes)
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
Christopher Raczka <chris@ecdnt5.enet.dec.com> writes:

	I also think the "other side" of the story does need to be told
	and this much I do know...  Sometime in September, Merit, IBM
	Corp, and MCI established Advanced Network and Services Inc.
	(ANS) ANS, a NOT FOR PROFIT organization, is to manage and
	operate the NSFNET backbone under subcontract to Merit

Funny to see the NOT FOR PROFIT emphasis.

Wasn't NYSERNET also started that way?

/jordan
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 20:35:40 -0500
From:      Hans-Werner Braun <hwb@merit.edu>
To:        tcp-ip@nic.ddn.mil
Cc:        hwb@merit.edu
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
This discussion is somewhat based on somewhat unreal assumptions. What
happened some while ago was that the partnership that manages and operates
the NSFNET on behalf of and under a cooperative aggreement with the
National Science Foundation have created a new company to be more responsive
to the everchanging requirements of the Internet. While IBM is one of the
three parent corporations of this new company, they do not control it at all.
There is only one IBM person on the Board of Directors who has no more rights
than any of the other seven members. Also, IBM is putting money *into* this
company and not getting money out of it. Just like the comment someone else made
here or on the com-priv mailing list where other companies contribute to PBS
stations for benefits like visibility and such. Given the non-for-profit nature
of the new company it would not even be legal for IBM to have a revenue stream
coming in from that company. There is absolutely no desire to be more 
restrictive on the network than there are restrictions today and there is
also no desire to abandon current protocols. Over time, the network should
even support more protocols, like OSI CLNP in parallel to IP, as demonstrated
on the NSFNET backbone already. Also, over time people should look into ways
to abandon as many traffic restrictions as possible. All this is an evolving
process and won't happen over night and this new company is just one of several
who are trying to foster the evolution of the Internet. There are other
companies that came earlier, there are likely more to come in the future,
all of which play important parts of the network. Soooo, IBM running the
NSFNET and/or the Internet is really a little far fetched.

	-- Hans-Werner
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 20:36:12 PST
From:      chuck@hls.com (Chuck Maricle)
To:        dougm@ico.isc.com, jhereg!imp@ico.isc.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet & IPX
Sort of like their NetBios.

Chuck MAricle
SE Houston
-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 19:40:07 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
I suspect that the notion of reliable and group membership 
dealt not with the ephemeral group that exists while a message
is being multicast, but rather with the commercial application 
that requires the confirmation that all members of a designated
group obtained the set of messages to which they were entitled.

Examples include updates of Price Lists, of Catalogs, of
reservations, of inventories, etc.  

The presumption in XTP is that all those who are alive, awake
and listening will received the multicast "reliably".  XTP does
not, to my knowledge, address itself to the administration of 
a group which is addressed by a multicast.
-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 14:24:14 GMT
From:      usc!bbn.com!cosell@ucsd.edu  (Bernie Cosell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
karl@ddsw1.MCS.COM (Karl Denninger) writes:

}This is a call to action by all interested parties.

}There is wind of a proposal stirring in Washington that would place the 
}NSFNet backbone, and eventually the entire government-run part of the 
}Internet, into the hands of IBM.

..

}Anyone want to bet how long the Internet remains accessible to non-IBM
}people?  

I'll take that bet --- I suspect this would never happen.

]Or whether the Internet ends up another Prodidy, with active
}censorship?

This is a possibility, but 'censorship' is a bit strong here.  Fact is
that we're using the network's comm resources for purposes quite a bit
beyond the intent of the folks who chartered the thing.  This is,
sooner or later, going to come to a head: either the screws will be
tightened, restricting the network to its narrowly-defined actual
purposes [the case that you fear], or else some set of folk will manage
to get the 'powers-that-be' [actually it is the 'powers-that-pay'] to
acknowlegd the utility of the network in its broader uses.

I, actually, think that the latter is fairly unlikely: as the gov't
financial world gets more constrained, it will prove harder and harder
to defend the somewhat amorphous 'general good' served by running the
communications service, especially in the face of _concrete_ research
projects having to be discontinued for lack of funds.

Whether you'll have to buy an IBM system to hook into it, 
}since they might decide that TCP/IP is no longer any good and now it's 
}time to go to SNA or worse?

This is spectacularly unlikely.  If anything, TCP/IP will be abandoned
in favor of ISO stacks, but even that is not going to happen any time
soon.

}Folks, if you love the Internet, and want to see it expand and grow, we need
}to insure that a few things happen:

}1) 	The "acceptable use" policy on the NSFNet needs to be scrapped.
}	Sure, this will bring problems.  But it will also mean that
}	commercial companies can tie in, pay their fair share, and make sure
}	that the network capacity has the funding to continue to grow.

What would you replace the policy with?  I think that the NSF charter
constrains their budget to be used as grants to further research.  I'd
bet that they can divert funds to running a communications service only
as long as such a service more-or-less directly supports their research
mandate.  [I know that we had such a problem with ARPANET funding, way
back when: when it became obvious that the ARPANET, per se, had become
a communications service and not a subject of research in and of itself
[indeed, if we did any real messing-around with the ARPANET we got
near-instantaneous complaints from all over the world! :-)], ARPA got
unhappy about funding it for precisely those two reasons: (1) it was
beyond ARPA's mandate, and so would not withstand Congressional
scrutiny, and (2) it preempted funds from other (real) research
projects.  The result was that the ARPANET operation was transferred to
DCA,a nd eventually resulted in the ARPANET being decommitted entirely
[the argument being that that sort of general comm facility was not an
appropriate activity for the gov't to be running]


}2)	The backbone needs to be run as a regulated commodity.  Perhaps even
}	run by the Government, strange as that may seem.  The goal of
}	universal connectivity is not that far off right now, but there are
}	companies and special interests who would like to see that never
}	happen.  We MUST insure that it does.

I think you'll have a VERY hard time making a really rational case for
this.  There are commercial alternatives to the gov't-subsidized
internet, and one might argue that there might well be more of 'em, and
they'd be more economical, if the gov't weren't gigantically perturbing
the market by making so much capacity available 'for free' [that is,
'paid for by someone else'].  The easiest way to achieve your goal [of
universial connectivity] is to be exploring ways to PAY for the sort of
communications services you envision, rather than just thumping the
drum that the gov't should provide it.


}4)	Finally, a freely accessible information exchange medium may be the
}	second-best guarantee of freedom in this country (the first being
}	the ability of the people to depose a despotic government).  By
}	keeping the passing of information from coast to coast available, 
}	fast and cheap, we keep the people informed.

Granted.  The only debate is the perennial one: WHO SHOULD PAY.  Why not
argue for a self-supporting communications service, instead of a
taxpayer-supported one.  The problem with the gov't-run solution is the
obvious ones that crop up whenever you let the gov't run stuff:
    1) if they pay for it, they'll expect to have some say about what it is
       used for.
    2) if they pay for it, they'll make blanket rules about how it is glued
       together
The problem with (2) is that (via the taxes we pay) we're all going to have
to subsidize this communications facility even if it doesn't serve our
purposes.  As for (1), one need only look at the 55mph stuff and the DFWF
extortion programs to see how overall nasty it can be to suckle at the
gov't's teat.


}	1)	A tax on access devices for the network may be the best
}		way to fund it.  I'm not sure about this, but it seems as
}		though a "user fee" is one of the better ways to pay for the
}		connectivity that we all enjoy and want to see furthered.

If this is adequate to PAY for the network [I cannot imagine that it is ---
do you have any clue how expensive the operating costs for something like
this is?], why not simply have it be privately operated?  Then the gov'ts
opinion on what the net does, and what people send over it, becomes
irrelevant.

}	2)	General subsidy isn't a bad idea either, but it's not ideal.
}		Selling it to the general public will be difficult,
}		especially with the things that hit the press now and again
}		about X-rated GIF sites and the like.

Bingo.

}	3)	Keep control in the hands of the many, or in the hands of a
}		non-profit corporation funded EXCLUSIVELY to run this beast.
}		Giving it to IBM or another pseudo-government company is as
}		good as letting the fox loose in the henhouse -- the
}		potential for abuse and profiteering is just too great to
}		ignore.

Perhaps.  Going back to your original 'the sky is falling' cry, you
only say "... into the hands of IBM".  What does that mean?  In the
past, in the various networks that have contracted out to be 'run'
[including the long-standing contract from ARPA, and later DCA, to BBN
to operate the ARPANET and the MILNET, and one from NSF to operate the
old CSNET] have been quite clear as to the responsibilites and
prerogatives of the operations-entity.  I cannot believe that NSF
either would want, or would be legally allowed, to turn over the policy
and planning of the NFSnet to IBM: the purpose of the network would
still be as it was [to serve NSF's research interests] and only the NSF
can evaluate and balance those purposes.

It feels to me that you're doing two things here, neither of which
serves us well: first is blowing the "danger" all out of proportion.
Second, I think you're vastly underestimating just how much it costs to
run one of these things. [and so you're being a bit cavalier at just
how easy it would be to find enough money to make this 'non profit
corp' to actually be able to pay its bills].

Instead of pushing for MORE gov't involvement in usenet, what is wrong
with pushing for LESS: how about we eschew those 'free' govt-supplied
links [which we really, probably, oughtn't have been using for rec.pets
in the first place] and instead push to have more "pay for play"
links?  If we make our own communications arrangments [which could
include using Telenet, or even, as you suggest, starting some kind of
non-profit corp to provide some kind of backbone facilities], in
addition to getting the connectivity you want, we have two BIG other
advantages: (1) we don't have to keep groveling before Congress for
funds, and (2) we don't have to duck reporters.

  /Bernie\
-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Oct 90 23:32:01 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        Robert Ullmann <Ariel@relay.prime.com>, TCP/ISDN list <tcp-isdn@list.prime.com>, TCP/IP list <TCP-IP@nic.ddn.mil>
Subject:   Re: RFC1183 ISDN and RT
> Excerpts from mail: 29-Oct-90 re: RFC1183 ISDN and RT Robert
> Ullmann@Relay.Pri (4646)

> > From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
> >
> > I also find it confusing exactly how the RT record is intended to work.
> >
> > Here's one scenario that I think these might be useful in.  Imagine two
> > isolated island networks NA and NB, such as might exist in two companies
> > or universities.  Each island network has a one or more routers, maybe
> > RC and RD, with ISDN connections which can establish links to other
> > networks.  Now let's say I try to telnet from one non-ISDN machine HE on
> > network NA to a non-ISDN machine HF on network NB.  One way I could
> > imagine things working is that router RC might advertise a default route
> > to hosts on its network including HE.  So, when I telnet, HE would send
> > its packets to RC.  Now, when RC received the packet addressed to HF, it
> > might look up RRs for HF and it might find an RT RR for RD.  Looking up
> > RD it might find an ISDN RR with RD's number.  It could then forward the
> > packet through to RD, which would then forward it to HF.  HF's response
> > would hopefully be sent back through RD (due to having correct updated
> > routing information) which would then realize that it already has a
> > connection open to RC, and would simply send it through.

> The routers, of course, don't see datagrams as requests/responses, but
> route in each direction independently. (datagrams from HF in the example
> route back to HE much as the original path from HE to HF was set up)
> Usually this will result in the same path in both directions, but it
> doesn't have to. (no, I don't think that is a problem: given a choice
> between not reaching a host, and reaching it by an asymmetrical path,
> I'll take the latter :-)

I had intended to mention this problem, but I forgot.  I do think that
this might be a problem, particularly if there is only one ISDN
connection into a net.  If there is an asymmetrical path, the other
router may try to establish a connection and get a busy signal.  What if
NB had two routers, RD and RG, both of which typically advertised routes
to NA/HE/RC.  Now, if RC established it's one and only connection with
RD, but somehow the response packet got routed to RG, there would be a
problem.  Unfortunately I don't see a good solution other than having a
routing protocol which made sure this doesn't happen.  Perhaps RD and RG
ought to advertise routes to NA/HE/RC with a very high metric when they
do not have connections established, and change to a low metric upon
connection establishment in order to avoid asymmetry.


> Good example. First, note that your host is going to need an initial
> default route to bootstrap itself: another host (the one at work,
> presumably, or perhaps a service like uunet or PSI). It has to know
> a priori the Internet and ISDN or X.25 address of that host.

Presumably the ISDN and X.25 addresses would be configured at startup
time as hints to your local DNS resolver.


> Second case: you are on a net _not_ advertised to the core. No,
> they can't reach you if they don't use RT/ISDN themselves. But
> they couldn't reach you anyway ... (<grin>)

I don't believe they could reach you even if they did use RT/ISDN
themselves, unless every other router between them and the router to
which RT/ISDN refers also uses RT/ISDN.

Drew
-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 20:23:03 EST
From:      Robert Ullmann <Ariel@Relay.Prime.COM>
To:        TCP/ISDN list <tcp-isdn@List.Prime.COM>, TCP/IP list <TCP-IP@NIC.DDN.MIL>, Drew Daniel Perkins <ddp+@andrew.cmu.edu>
Subject:   re: RFC1183 ISDN and RT
Hi,

[ I am copying a larger than usual amount of text from the previous
message, and sending to both TCP-IP and TCP-ISDN; I think the discussion
can/should continue on TCP-ISDN.

To subscribe to TCP-ISDN, send a note (content irrelevent) to
TCP-ISDN-Subscribe@List.Prime.COM ]

Re RFC1183, ISDN, X.25, and RT records:

> From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
>
> I also find it confusing exactly how the RT record is intended to work.
>
> Here's one scenario that I think these might be useful in.  Imagine two
> isolated island networks NA and NB, such as might exist in two companies
> or universities.  Each island network has a one or more routers, maybe
> RC and RD, with ISDN connections which can establish links to other
> networks.  Now let's say I try to telnet from one non-ISDN machine HE on
> network NA to a non-ISDN machine HF on network NB.  One way I could
> imagine things working is that router RC might advertise a default route
> to hosts on its network including HE.  So, when I telnet, HE would send
> its packets to RC.  Now, when RC received the packet addressed to HF, it
> might look up RRs for HF and it might find an RT RR for RD.  Looking up
> RD it might find an ISDN RR with RD's number.  It could then forward the
> packet through to RD, which would then forward it to HF.  HF's response
> would hopefully be sent back through RD (due to having correct updated
> routing information) which would then realize that it already has a
> connection open to RC, and would simply send it through.

For someone who finds it confusing, you have given a perfect example :-)

The routers, of course, don't see datagrams as requests/responses, but
route in each direction independently. (datagrams from HF in the example
route back to HE much as the original path from HE to HF was set up)
Usually this will result in the same path in both directions, but it
doesn't have to. (no, I don't think that is a problem: given a choice
between not reaching a host, and reaching it by an asymmetrical path,
I'll take the latter :-)

Note that they don't have to be "isolated island networks" for this
to be useful: for example, Prime runs its internal net using a private
X.25 network, configured as part of several PSDNS; some (most) of
Prime's traffic would be inappropriate on the Internet-proper (to, say,
one of our customers), being purely commercial.

> When we start scaling this simple example up, I see a lot of problems
> start popping up.  Imagine I just have a single host (at home maybe)
> with an ISDN connection.  Now, I want to telnet to a host which is
> somewhere on the Internet, behind maybe dozens of router hops.  It's
> hard to imagine that every host on the internet will have an RT RR in
> the DNS.  If I were a random site with hosts on the Internet, but no
> ISDN connections, what RT RR would I want to advertise?  There might be
> thousands of other hosts/routers on the Internet with ISDN connections.
> Which would I choose, and how?
> Drew

Good example. First, note that your host is going to need an initial
default route to bootstrap itself: another host (the one at work,
presumably, or perhaps a service like uunet or PSI). It has to know
a priori the Internet and ISDN or X.25 address of that host.

For hosts that do not have RT or ISDN records, you continue to use
the default(s). This may be desired behavior anyway, since reaching
connected-internet hosts is probably best accomplished via your
work/service. By "connected-internet", I mean hosts on nets known
to the core routers.

How do they reach you? Two cases. In the first case, you have an
IP address on a net advertised to the core (by your service host);
they reach you by routing in the normal way, your service host
finds you a priori.

Second case: you are on a net _not_ advertised to the core. No,
they can't reach you if they don't use RT/ISDN themselves. But
they couldn't reach you anyway ... (<grin>)

About every host (or domain, using wildcards at some level) having
RT or X.25/ISDN records: IMHO, an ISDN interface is going to be
commonplace soon; sites (even hosts) that do not have their own
will be very unusual indeed. (Put Down the Flame-Thrower, Sir!
Go back and take note of the "IMHO" :-)

IMHO: (<-- note again :-) with the extension of the Internet into
more and more commercial domains, and extensive use that would
be completely unacceptable to the research Internet (Prime and
customers exchanging EDI, for example), the new routing core
must be based on the ISDN, with real unrestricted access between
organizations.

Best Regards,
Robert Ullmann
Prime Computer, Inc.
+1 508 620 2800 ext 1736
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 16:04:08 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Reliable Datagram ??? Protocols

Doesn't TCP require the connection to be in the ESTABLISHED state before
it is permitted to deliver data to the application?  If so, I think B
cannot see the data until it gets the ACK of its SYN from A, thus the
response from B cannot be includes with B's SYN ACK.

Charlie

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 17:37:00 GMT
From:      elroy.jpl.nasa.gov!usc!wuarchive!umich!accuvax.nwu.edu!casbah.acns.nwu.edu!eecs.nwu.edu!matt@lll-winken.llnl.gov  (Matt Larson)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for utility to monitor RIP packets
I am looking for a UNIX utility that will listen for all the RIP
packets on a network and display their contents.  I am essentially
trying to duplicate the output of a cisco router with RIP debugging
turned on.  The output looks something like:

Received RIP update from xxx.xxx.xxx.xxx:
  network yyy.yyy.yyy.yyy in n hops
  network zzz.zzz.zzz.zzz in m hops
  ...

This would be really handy on a large network with no ciscos.  I know
that gated has a debugging mode, but it doesn't provide quite the
information that I am looking for.

If anyone knows of a utility to do something like this, I would be
interested to hear about it.  If I can't find one, I'm going to write
it myself.  Of course, if it has already been written, then I'm not
going to bother.

Thanks for any information,

--
Matt Larson, Distributed Systems Analyst
Academic Computing and Network Services, Northwestern University
matt@acns.nwu.edu   (708) 491-5366
-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 18:20:22 GMT
From:      baw@terminator.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Cheap (or Free) TCP-IP for VMS


I'm trying to get a few departments of my company to get together to
help finance an Internet connection and unfortunately not all of them
have money to pay for the connection and the TCP-IP software for VMS.
(One of the machines we need it for is a Vax 6440, soon to be traded in
for a Vax 9000)

Is there any free or very cheap TCP-IP software for VMS available?
Telnet and FTP would be the only applications they need.

I'm already familiar with DEC's UCX, Wollengong, TGV, Fusion & Process Software,

Unfortunately they are just too expensive.


I'd appreciate any pointers and I will gladly summarize for the net.

regards,

Brian Wolfe
Rush Medical Center
Chicago, IL 
bwolfe@rpslmc.edu
(312)-942-5781
--
-------------------------------------------------------------------------
Brian Wolfe                    Internet: baw@terminator.cc.umich.edu
Systems Analyst                UUCP:     {rutgers,uunet}!sharkey!hfhrv!brian
Henry Ford Hospital 	       Voice:    (313)-876-7461

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 18:52:57 GMT
From:      ken@cu-arpa.cs.cornell.edu  (Ken Birman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
In article <9010251640.AA01218@hpsdel.sde.hp.com>
   wunder@HPSDEL.SDE.HP.COM (Walter Underwood) writes:
>I'm surprised that no one has mentioned Cornell's ISIS system....

... I don't normally follow this group, but someone pointed out the
two postings that mention ISIS, so I am including some information on
our system, below.  The version of ISIS mentioned here (V2.1) has been
available since early September and is apparently quite solid. You can
copy it anonymously from several places and it does solve the reliable
broadcast (and datagram!) problems.  

As noted in this posting, there is also a newsgroup for ISIS-related
discussion.  It tends to run in broadcast mode, but questions can certainly
be posted there and one of my group members will respond, or I will.

We have a forthcoming commercial release of ISIS, from a company
called ISIS Distributed Systems Incorporated.  Email to me for details
and I can see to it that you get on the IDS mailing list.  The company
version of ISIS is somewhat extended over the public one, and faster
in some modes of use, but the public copy should be fine for figuring
out what ISIS is all about.  In fact, many companies are using ISIS
as part of distributed systems products now.  The product will be priced
"aggressively", and has some nice distributed application management
utilities layered over it.

As noted below, all the ISIS papers and the manual are available upon
request, and many can be copied anonymously if you have a postscript 
printer.

Ken Birman (reply to me, as I can't afford to follow any more newsgroups!)

--- ISIS V2.1 blurb ---

This is to announce the availability of a public distribution  of
the  ISIS  System,  a  toolkit for distributed and fault-tolerant
programming.  The initial version of ISIS runs on  UNIX  on  SUN,
DEC,  GOULD, AUX  and  HP  systems; ports to other UNIX-like
systems are planned for the future.  No kernel changes are needed
to support ISIS; you just roll it in and should be able to use it
immediately.  The current implementation of ISIS performs well in
networks of up to about 100-200 sites.  Most users, however, run on
a smaller number of sites (16-32 is typical) and other sites connect
as "remote clients" that don't actually run ISIS directly. In this
mode many hundreds of ISIS users can be clustered around a smaller
set of ISIS "mother sites"; many users with large networks favor
such an architecture.


--- Who might find ISIS useful? ---

You will find ISIS useful if you  are  interested  in  developing
relatively sophisticated distributed programs under UNIX (eventu-
ally, other systems too).  These include programs that distribute
computations over multiple processes, need fault-tolerance, coor-
dinate activities  underway  at  several  places  in  a  network,
recover  automatically from software and hardware crashes, and/or
dynamically reconfigure while maintaining some  sort  of  distri-
buted  correctness  constraint at all times.  ISIS is also useful
in building certain types of distributed real time systems.

Here are examples of problems to which ISIS has been applied:

   o On the factory floor, we  are  working  with  an  industrial
     research  group  that is using ISIS to program decentralized
     cell controllers.  They need to arrive at a modular, expand-
     able, fault-tolerant distributed system.  ISIS makes it pos-
     sible for them to build such a system without a huge invest-
     ment  of  effort.  (The ISIS group also working closely with
     an automation standards consortium called  ANSA,  headed  by
     Andrew Herbert in Cambridge).

   o As part of a network file system, we built an  interface  to
     the  UNIX  NFS (we call ours "DECEIT") that supports tran-
     sparent file  replication  and  fault-tolerance.   DECEIT
     speaks NFS protocols but employs ISIS internally to maintain
     a consistent distributed state.  For  most  operations,  
     DECEIT  performance is at worst 50-75% of that of a normal NFS
     -- despite supporting file replication and fault-tolerance.
     Interestingly, for many common operations, DECEIT substantially
     outperforms NFS (!) and it is actually fairly hard to come up
     with workloads that demonstate replication-related degradation.

   o A parallel "make" program.  Here, ISIS  was  used  within  a
     control  program that splits up large software recompilation
     tasks  and  runs  them  on  idle  workstations,   tolerating
     failures  and  dynamically  adapting  if  a  workstation  is
     reclaimed by its owner.

   o A system for monitoring and reacting to sensors scattered around
     the network, in software or in hardware.  This system, Meta, is
     actually included as part of our ISIS V2.1 release.  We are adding
     a high level language to it now, Lomita, in which you can specify
     reactive control rules or embed such rules into your C or Fortran
     code, or whatever.

   o In a hospital, we have looked at using ISIS to manage repli-
     cated data and to coordinate activities that may span multi-
     ple machines.  The problem here is  the  need  for  absolute
     correctness:  if a doctor is to trust a network to carry out
     orders that might impact on patient health, there is no room
     for  errors due to race conditions or failures.  At the same
     time, cost considerations argue for distributed systems that
     can  be  expanded  slowly  in  a fully decentralized manner.
     ISIS addresses both of these issues: it makes it far  easier
     to  build  a reliable, correct, distributed system that will
     manage  replicated  data  and  provide  complex  distributed
     behaviors.  And, ISIS is designed to scale well.

   o For programming numerical algorithms.  One group at  Cornell
     used  ISIS  to  distribute  matrix  computations  over large
     numbers of workstations.  They did this because the worksta-
     tions were available, mostly idle, and added up to a tremen-
     dous computational engine.  Another group, at LANL, uses ISIS
     in a parallel plasma physics application.

   o In a graphics rendering application.  Over an extended period,
     a Cornell graphics group (not even in our department) has used
     ISIS to build distributed rendering software for image 
     generation.  They basically use a set of machines as a parallel
     processor, with a server that farms out rendering tasks and
     a variable set of slave computing units that join up when their
     host machine is fairly idle and drop out if the owner comes
     back to use the machine again.  This is a nice load sharing
     paradigm and makes for sexy demos too.

   o In a wide-area seismic monitoring system (i.e. a system that
     has both local-area networks and wide-area connections between
     them), developed by a company called SAIC on a DARPA contract.
     The system gathers seismic data remotely, preprocesses it, and
     ships event descriptions to a free-standing analysis "hub", which
     must run completely automatically (their people in San Diego don't like
     to be phoned in the middle of the night to debug problems in Norway).
     The hub may request data transfers and other complex computations,
     raising a number of wide-area programming problems.  In addition, the
     hub system itself has a lot of programs in various languages and
     just keeping it running can be a challenge.

   o On brokerage and banking trading floors.  Here, ISIS tends to be
     an adjunct to a technology for distributing quotes, because the
     special solutions for solving that specific problem are so fast
     that it is hard for us to compete with them (we normally don't
     have the freedom of specifying the hardware... many "ticker plant
     vendors" wire the whole floor for you).  However, to the extent
     that these systems have problems requiring fault-tolerance, simple
     database integration mechanisms, dynamic restart of services, 
     and in general need "reactive monitoring and control" mechanisms,
     ISIS works well.  And, with our newer versions of the ISIS protocols,
     performance is actually good enough to handle distribution of 
     stock quotes or other information directly in ISIS, although 
     one has to be a bit careful in super performance intensive settings.
     (The commercial ISIS release should compete well with the sorts of
     commercial alternatives listed above on a performance basis, but
     more than 10 trading groups are using ISIS V2.1 despite the fact that
     it is definitely slower!).

The problems above are characterized by several features.  First,
they  would all be very difficult to solve using remote procedure
calls or transactions against some shared  database.   They  have
complex,  distributed  correctness constraints on them: what hap-
pens at site "a" often requires a coordinated action at site  "b"
to  be  correct.   And,  they do a lot of work in the application
program itself, so that the ISIS communication mechanism  is  not
the bottleneck.

If you have an application like this, or are interested in taking
on  this  kind  of  application,  ISIS  may be a big win for you.
Instead of investing resources in building an environment  within
which  to  solve  your application, using ISIS means that you can
tackle the application immediately,  and  get  something  working
much faster than if you start with RPC (remote procedure calls).

On the other hand, don't think of ISIS as competing with RPC or
database transactions.  We are oriented towards online control and
coordination problems, fault-tolerance of main-memory databases, etc.
ISIS normally co-exists with other mechanisms, such as conventional
streams and RPC, databases, or whatever.  The system is highly portable
and not very intrusive, and many of our users employ it to control some
form of old code running a computation they don't want to touch at
any price.


--- What ISIS does ---

The ISIS system has been under development for several  years  at
Cornell  University.   After  an  initial  focus on transactional
"resilient objects", the emphasis shifted in 1986  to  a  toolkit
style  of  programming.   This approach stresses distributed con-
sistency in applications that  manage  replicated  data  or  that
require  distributed  actions  to  be taken in response to events
occurring in the system.  An "event" could be a user request on a
distributed service, a change to the system configuration result-
ing from a process or site failure or recovery, a timeout, etc.

The ISIS toolkit uses a subroutine call style  interface  similar
to  the interface to any conventional operating system.  The pri-
mary difference, however, is  that  ISIS  functions  as  a  meta-
operating  system.   ISIS system calls result in actions that may
span multiple processes and machines in the  network.   Moreover,
ISIS  provides  a  novel  "virtual  consistency"  property to its
users.  This property makes it easy to build  software  in  which
currently  executing processes behave in a coordinated way, main-
tain replicated data, or otherwise satisfy a system-wide correct-
ness  property.   Moreover,  virtual synchrony makes even complex
operations look atomic,  which  generally  implies  that  toolkit
functions  will  not  interfere  with  one another.  One can take
advantage of this to develop distributed ISIS software in a  sim-
ple  step-by-step style, starting with a non-distributed program,
then adding  replicated  data  or  backup  processes  for  fault-
tolerance  or higher availability, then extending the distributed
solution to support dynamic reconfiguration, etc.  ISIS  provides
a  really  unique style of distributed programming -- at least if
your distributed computing problems run up against the issues  we
address.   For  such  applications, the ISIS programming style is
both easy and intuitive.

ISIS is really intended for, and is good at, problems  that  draw
heavily  on  replication of data and coordination of actions by a
set of processes that know about one  another's  existence.   For
example,  in  a factory, one might need to coordinate the actions
of a set of machine-controlled drills at  a  manufacturing  cell.
Each  drill  would  do  its  part of the overall work to be done,
using a coordinated  scheduling  policy  that  avoids  collisions
between  the  drill heads, and with fault-tolerance mechanisms to
deal with bits breaking.  ISIS is ideally suited to solving prob-
lems  like  this  one.  Similar problems arise in any distributed
setting, be it local-area network software for the  office  or  a
CAD  problem,  or  the  automation of a critical care system in a
hospital.

ISIS is not intended for transactional database applications.  If
this  is  what  you  need, you should obtain one of the many such
systems that are now available.  On the other hand, ISIS would be
useful  if  your  goal  is to build a front-end in a setting that
needs databases.  The point is that  most  database  systems  are
designed  to  avoid interference between simultaneously executing
processes.  If your application also  needs  cooperation  between
processes  doing  things  concurrently at several places, you may
find this aspect hard to solve  using  just  a  database  because
databases  force  the  interactions to be done indirectly through
the shared data.  ISIS is good for solving this kind of  problem,
because  it  provides  a direct way to replicate control informa-
tion, coordinate the actions of the front-end processes,  and  to
detect and react to failures.

ISIS itself runs as a user-domain program on  UNIX  systems  sup-
porting  the  TCP/IP protocol suite.  It currently is operational
on SUN, DEC, GOULD and HP versions of UNIX.  Language  interfaces
for C, C++, FORTRAN, and Common LISP (both Lucid and Allegro) are
included, and a new C-Prolog interface is being tested now.  Recent 
ports available in V2.1 include AUX for the Apple Mac. II, AIX on the
IBM RS/6000 and also the older PC/RT.  A Cray UNICOS port is (still)
under development at LANL, and a DEC VMS port is being done by
ISIS Distributed Systems, Inc.

ISIS runs over Mach on anything that supports Mach but will probably
look a little unnatural to you if you use the Mach primitives.  We
are planning a version of ISIS that would be more transparent in a
Mach context, but it will be some time before this becomes available.
Meanwhile, you can use ISIS but may find some aspects of the interface
inconsistent with the way that Mach does things.

The actual set of tools includes the following:

   o High performance mechanisms supporting lightweight tasks  in
     UNIX,  a  simple message-passing facility, and a very simple
     and  uniform  addressing  mechanism.   Users  do  not   work
     directly  with things like ports, sockets, binding, connect-
     ing, etc.  ISIS handles all of this.

   o A process "grouping" facility, which  permits  processes  to
     dynamically  form and leave symbolically-named associations.
     The system serializes changes  to  the  membership  of  each
     group: all members see the same sequence of changes.  Groups
     names can be used as a location-transparent address.

   o A suite of  broadcast  protocols  integrated  with  a  group
     addressing  mechanism.   This  suite  operates in a way that
     makes it look as if all broadcasts are received  "simultane-
     ously"  by  all  the members of a group, and are received in
     the same "view" of group membership.

   o Ways of obtaining distributed executions.   When  a  request
     arrives in a group, or a distributed event takes place, ISIS
     supports any of a variety of execution styles, ranging  from
     a  redundant computation to a coordinator-cohort computation
     in which one process takes the requested actions while  oth-
     ers back it up, taking over if the coordinator fails.

   o Replicated data with 1-copy consistency guarantees.

   o Synchronization   facilities,  based  on  token  passing  or
     read/write locks.

   o Facilities for watching a for a process or  site  (computer)
     to fail or recover, triggering execution of subroutines pro-
     vided by the user when the  watched-for  event  occurs.   If
     several  members  of  a  group watch for the same event, all
     will see it at the same "time" with respect to arriving mes-
     sages  to  the group and other events, such as group member-
     ship changes.

   o A facility for joining  a  group  and  atomically  obtaining
     copies of any variables or data structures that comprise its
     "state" at the instant before the  join  takes  place.   The
     programmer who designs a group can specify state information
     in addition to the state automatically maintained by ISIS.

   o Automatic restart of applications when a  computer  recovers
     from  a crash, including log-based recovery (if desired) for
     cases when all representatives of a service fail  simultane-
     ously.

   o Ways to build transactions or  to  deal  with  transactional
     files  and  database  systems external to ISIS.  ISIS itself
     doesn't know about files or transactions.  However, as noted
     above, this tool is pretty unsophisticated as transactional 
     tools go...

   o Spooler/long-haul mechanism, for saving data to be sent to a
     group next time it recovers, or for sending from one ISIS LAN
     to another, physically remote one (e.g. from your Norway site
     to your San Diego installation).  Note: ISIS will not normally
     run over communication links subject to frequent failures, al-
     though this long-haul interface has no such restrictions.

Everything in ISIS is fault-tolerant.  Our programming manual has
been  written  in  a tutorial style, and gives details on each of
these mechanisms.  It includes examples  of  typical  small  ISIS
applications and how they can be solved.  The distribution of the
system includes demos, such as the parallel  make  facility  men-
tioned  above;  this  large  ISIS application program illustrates
many system features.

To summarize, ISIS provides a broad  range  of  tools,  including
some  that  require algorithms that would be very hard to support
in other systems or to implement by hand.  Performance  is  quite
good:  most  tools require between 1/20 and 1/5 second to execute
on a SUN 3/60, although the actual  numbers  depend  on  how  big
processes  groups get, the speed of the network, the locations of
processes involved, etc.  Overall, however, the system is  really
quite fast when compared with, say, file access over the network.
For certain common operations  a  five  to  ten-fold  performance
improvement  is expected within two years, as we implement a col-
lection of optimizations.  The system scales well with  the  size
of  the  network,  and  system overhead is largely independent of
network size.  On a machine that is not participating in any ISIS
application, the overhead of having ISIS running is negligible.

In certain communication scenarios, ISIS performance can be quite
good.  These involve streaming data within a single group or certain
client-server interaction patterns, and make use of a new BYPASS
communication protocol suite.  Future ISIS development is likely
to stress extensions and optimizations at this level of the system.
In addition, a lot of effort is going into scaling the system
to larger environments.

--- You can get a copy of ISIS now ---

Version V2.1 of ISIS is now fully operational and  is  being  made
available  to the public.  This version consists of a C implementations
for UNIX, and has been ported to AIX, SUN, UNIX, MACH, ULTRIX, Gould UNIX,
HP-UX, AUX and APOLLO UNIX  (release 10.1).  Performance is uniformly good.
A 400 page tutorial and sys- tem  manual  containing  numerous  programming
examples  is also available.  Online manual pages are also provided.

The remainder of this posting focuses on how to get ISIS, and how
to get the manual.  Everything is free except bound copies of the
manual.  Source is included, but the  system  is  in  the  public
domain, and is released on condition that any ports to other sys-
tems or minor modifications remain in  the  public  domain.   The
manual  is  copyrighted  by the project and is available in hard-
copy form or as a DVI file, with figures available  for  free  on
request.

We have placed a compressed TAR images in the following places:
 * cu-arpa.cs.cornell.edu (anonymous login, binary mode pub/ISISV21.TAR.Z)
 * Doc: cu-arpa.cs.cornell.edu (pub/ISISV21-DOC.TAR.Z)
 * uunet.uu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z)
 * mcsun.eu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z)
Also available are DVI and PS versions  of  our  manual.   Bound
copies  will  be  available at $25 each.  A package of figures to
glue into the DVI version will be provided free of charge.

A tape containing ISIS will be provided upon  payment of a charge to
cover our costs in making the tape.  Our resources are limited and
we do not wish to do much of this.


--- Copyright, restrictions ---

V2.1 of ISIS is subject to a restrictive copyright; basically, you can
use it without changing it in any way you like, but are not permitted
to develop "derivative versions" without discussing this with us.
V2.1 differs substantially from V1.3.1, which was released in the public
domain and remains available without any restrictions whatsoever.

On the other hand, whereas previous versions of ISIS required export
licenses to be sent to certain eastern-block countries, the present
version seems not to be subject to this restriction.  Contact the US
Dept. of Commerce for details if you plan to export ISIS to a country
that might be subject to restrictions.  Any place in Europe, Japan, etc.
should be fine and no license is required.

--- Commercial support ---

We are working with a local  company,  ISIS  Distributed  Systems
Inc.,  to  provide  support services for ISIS.  This company will
prepare distributions and work to fix  bugs.   Support  contracts
are  available  for an annual fee; without a contract, we will do
our best to be helpful but make no promises.  Other services that
IDS  plans  to  provide will include consulting on fault-tolerant
distributed systems design, instruction on how to work with ISIS,
bug  identification  and  fixes,  and  contractual joint software
development projects.  The company is also prepared to port  ISIS
to   other  systems  or  other  programming  languages.   Contact
"birman@gvax.cs.cornell.edu" for more information.


--- If you want ISIS, but have questions, let us know ---

Send mail to isis@cs.cornell.edu, subject  "I  want  ISIS",
with electronic and physical mailing details.  We will send you a
form for acknowledging agreement with the conditions for  release
of the software and will later contact you with details on how to
actually copy the system off our machine to yours.


--- You can read more about ISIS if you like ---

The following papers and documents are  available  from  Cornell.
We don't distribute papers by e-mail.  Requests for papers should
be transmitted to "isis@cs.cornell.edu".

  1. Exploiting replication.  K. Birman and T. Joseph.  This is a
     preprint  of  a  chapter  that will appear in: Arctic 88, An
     advanced course on operating systems, Tromso,  Norway  (July
     1988).  50pp.

  2. Reliable broadcast protocols.   T.  Joseph  and  K.  Birman.
     This  is a preprint of a chapter that will appear in: Arctic
     88, An advanced course on operating systems, Tromso,  Norway
     (July 1988).  30pp.

  3. ISIS: A distributed programming  environment.  User's  guide
     and  reference  manual.   K.  Birman, T. Joseph, F. Schmuck.
     Cornell University, March 1988.  275pp.

  4. Exploiting virtual synchrony  in  distributed  systems.   K.
     Birman and T. Joseph.  Proc. 11th ACM Symposium on Operating
     Systems Principles (SOSP),  Nov.  1987.  12pp.

  5. Reliable communication in  an  unreliable  environment.   K.
     Birman and T. Joseph.  ACM Transactions on Computer Systems,
     Feb. 1987.  29pp.

  6. Low cost management of  replicated  data  in  fault-tolerant
     distributed systems.  T. Joseph and K. Birman.  ACM Transac-
     tions on Computer Systems, Feb. 1986.  15pp.

  7. Fast causal multicast.  K. Birman, A. Schiper, P. Stephenson.
     Dept. of Computer Science TR, May 1990.

  8. Distributed application management.  K. Marzullo, M. Wood, R.
     Cooper, K. Birman.  Dept. of Computer Science TR, June 1990.

We will be happy to provide reprints of these papers.  Unless  we
get  an  overwhelming  number of requests, we plan no fees except
for the manual.  We also maintain a mailing list for  individuals
who  would  like to receive publications generated by the project
on an ongoing basis.  The last two papers can be copied using FTP
from cu-arpa.cs.cornell.edu.

If you want to learn about the virtual synchrony as  an  approach
to  distributed computing, the best place to start is with refer-
ence [1].  If you want to learn more about the ISIS system,  how-
ever,  start  with the manual.  It has been written in a tutorial
style and should be easily accessible to anyone familiar with the
C programming language.  References [7] and [8] are typical of our
recent publications (there are others -- contact Maureen Robinson
for details). 
-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 20:52:44 GMT
From:      usc!samsung!olivea!sun-barr!newstop!male!texsun!vector!egsner!mic!supernet!cluther@ucsd.edu  (Clay Luther)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:

>Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1
>and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build
>a truly commercial TCP/IP service, give excellent service, and charge less
>than $2000/month for it.

><csg>

Since when was $2000/month cheap?  This is more than most people in the US
make in a month!  $2000/month is in no way cheap, with triple astericks.  It
is well out of the reach of the common man and beyond the means of many small
companies that would profit greatly by having internet access.

Internet will not be cheap until it drops to say, $100/month, or less.


-- 
Clay Luther, Postmaster          cluther@supernet.haus.com 
  postmaster@supernet.haus.com   clay.luther@supernet.haus.com
  Harris Adacom Corporation      MS 23, PO Box 809022, Dallas, Tx 75380-9022
  214/386-2356                   Your mileage may vary.  Void where prohibited.
-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 21:02:08 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver for PRONET

Does anyone know the whereabouts of a packet driver that would let me run
TCPIP over PRONET with Proteon's cards??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 21:10:06 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable Datagram ??? Protocols
In article <1990Oct25.165545@envy.bellcore.com> karn@thumper.bellcore.com writes:
>There's no reason
>that you shouldn't be able to send a series of SMTP commands in a
>single TCP segment and receive a series of responses, except that many
>SMTP servers inexplicably blow up when you try this. Given that TCP is
>supposed to be a reliable byte stream protocol, the designers of these
>systems must have gone well out of their way to keep this from working.

Five years ago, my internet host was a PDP-11/70 running PWB UNIX
(vintage 1978, for those who don't know their history).  The wonderful
folks at BBN had somehow managed to make this beast talk TCP/IP, and
had provided implementations of TELNET, FTP, and SMTP.  The SMTP code
blissfully assumed that every read() call would return exactly one
line of text, and this assumption was correct about 90% of the time.
Eventually I wanted the other 10% to work and I added buffering to the
SMTP daemon independent of TCP, but nobody had gone to any great
effort to produce the broken implementation; it was just plain old
lazy programming.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Domain: Makey@Logicon.COM    UUCP: {ucsd,nosc}!snoopy!Makey
-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 21:13:54 GMT
From:      mintaka!spdcc!spdcc.com!raisch@eddie.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Industrial Computing Society - Call for Papers

*********************    INDUSTRIAL COMPUTING SOCIETY    *********************
*********************  >>>>>   CALL FOR PAPERS   <<<<<   *********************

The Industrial Computing Society (ICS), an international network of people
involved in industrial applications of computers, announces the first annual
Industrial Computing Conference (ICC/91) to be held in conjunction with the
ISA conference in Anaheim, California on October 28-31, 1991.

We are actively recruiting session developers, as well as paper sessions,
panel discussions, workshops, and roundtables that cover industrial computing
hardware, software, peripherals and integration.  Specific platforms addressed
will include hardened computers, PLCs, DCSs, and mainframe level computing.
All sessions will concentrate on technology and applications; promotional
sessions are strictly forbidden.

            >>>>> SUGGESTED TOPICS
            CIM Technology
            Industrial Computing: Technology and Applications
            Distributed Control Systems
            Programmable Logic Controllers
            Flexible Manufacturing Systems
            Case Studies of Automation Applications
            Networking: Industrial LANs, Communications Protocols, MAP/TOP,
                        Ethernet, Fieldbus
            MRP and Manufacturing Information Systems
            Manufacturing Databases
            Artificial Intelligence, Expert Systems, Neural Networks
            Selecting a Computer-based Control System
            Data Acquisition and Control
            Statistical Process Control
            Operator Interfaces
            Operating Systems for Plant Floor Control
            Bus Interfaces in Computer-based Control Systems
            Automation Standards Development
            Robotics, Machine Vision

You may make a submission for a conference session by completing an ISA/ICC
"Intent to Present" form.  These forms can be obtained from Shari Worthington,
ICC/91 Assistant Program Chair, by calling (508)755-5242 or FAXing to
(508)795-1636.

            >>>>> DEADLINES
            Paper Sessions (to be published in ICC proceedings):
                        - Abstracts due 1 DEC 1990
                        - Draft Papers due 8 FEB 1991
                        - Camera-ready Manuscripts due 3 JUN 1991
            Panel Discussions, Workshops, Roundtables (not published):
                        - Abstracts due 1 DEC 1990
                        - Final List of Session Speakers due 3 JUN 1991
************
**  FREE  **  SOCIETY MEMBERSHIP
************
For a limited time, FREE first-year founding memberships are available in the
Industrial Computing Society.  For an application form, contact:

                        Industrial Computing Society
                        c/o Instrument Society of America
                        PO Box 12277
                        Research Triangle Park, NC 27709
                        Telephone (919) 549-8411

E-mail inquiries may be directed to Ken Crater (ken@control.com), member,
ICS Steering Committee, and will be forwarded to the appropriate officer.
Please be patient.

---------------------------------------------------------------------------
Ken Crater  --  member, Steering Committee, ICS
Control Technology Corporation, Hopkinton, MA 01748
-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 22:52:31 GMT
From:      njin!uupsi!schoff@rutgers.edu  (Martin Schoffstall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
I don't think that eveyone needs to scrap the NSFNet right now, especially
since it is free.  What we need to consider are several levels of
service/capabilities/restrictions in the US and Internationally.

For those organizations willing to abide by the restrictions let them
have the academic regionals and NSFNet.  For those who don't let
them leave and migrated to TYMNET, TELENET, ALTERNET, PSINET, and XYZNet.

Of course in october 92 when the NSFNet funding is finished there will
probably be even more choices.  Because as a good friend of mine said
once:  who can compete with free?

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

>Karl, there is a *much* simpler solution. Scrap NSFNet. We don't need it. T1
>and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build
>a truly commercial TCP/IP service, give excellent service, and charge less
>than $2000/month for it.
>
>NSFNet is the government's network. Let them have it for anyone who wants to
>live under the government's terms and conditions. Just as the Europeans are
>throwing off the yokes of their PTTs, it's time for us to throw off the yoke
>of state-sponsored communications networks, and start building our own.
-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 90 22:57:31 GMT
From:      njin!uupsi!schoff@rutgers.edu  (Martin Schoffstall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
>
>  Is there any goverment email address we can write to about this?
>
>---Bob

You can start with steve@note.nsf.gov who is responsible for
"infrastructure", but as pointed out in another posting, com-priv@psi.com
is where this is being discussed in depth, and both the government
and the participants are all at least watching.

Marty
-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 01:03:33 GMT
From:      usc!samsung!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@ucsd.edu  (Matthias Urlichs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Batching vs lock-step
In comp.protocols.tcp-ip, article <ENAG.90Oct29110031@hild.ifi.uio.no>,
  enag@ifi.uio.no (Erik Naggum) writes:
< In article <cyt^f2.ck6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
< 
<  The problem is that on top of TCP there's the C stdio library which tends to
<  buffer your data when a program does an fgets().
< 
<  After reading the first request, said program is likely to say "wait on the
<   _connection_ for ten minutes until data become available".
<  [...]
<    A side effect of this is that sending a single character to such an
<    implementation, and leaving the TCP stream open, will hang it indefinitely.
<    ;-)
< 
< I didn't get this.  Are you saying you switch between stdio routines
< and raw socket reads at some point after the first fgets?
< 
No, I said (and quite a few programs actually do it) that the programs
alternate between reading via stdio and using select() on the raw socket.

< In particular, I can't think of any real situation where your "side
< effect" would occur.
< 
Consider a program which does:
- while(TCP stream OK)
-   select(TCP stream, 10 minutes)
-   fgets(stream, data)
-   process (data)

Now if you send a single character to this program, the select call will say
OK, but the fgets() will hang, waiting for a Newline.
Alterntely, if you send two short lines, the fgets will read both into its
buffer (and return the first to the program), and next time 'round the select
will block.

< I've seen NNTP get slightly confused when GNUS (a GNU Emacs news
< reader) stuffed a whole bunch of command lines down its throat, and
< the cause was that NNTP used select(2) to wait for input.  Apparently,
< it read the data into a large buffer, strchr'ed for '\n', replaced it
< with a '\0', and parsed the command.  [...]

It's far simpler -- see above.

<   Anyway, it works with a conforming NNTP client, although a bit
< on the "be conservative in what you accept and liberal in what you
< send" side.
< 
That seems to be the problem. ;-)

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/
-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 01:23:03 GMT
From:      Ariel@RELAY.PRIME.COM (Robert Ullmann)
To:        comp.protocols.tcp-ip
Subject:   re: RFC1183 ISDN and RT

Hi,

[ I am copying a larger than usual amount of text from the previous
message, and sending to both TCP-IP and TCP-ISDN; I think the discussion
can/should continue on TCP-ISDN.

To subscribe to TCP-ISDN, send a note (content irrelevent) to
TCP-ISDN-Subscribe@List.Prime.COM ]

Re RFC1183, ISDN, X.25, and RT records:

> From: Drew Daniel Perkins <ddp+@andrew.cmu.edu>
>
> I also find it confusing exactly how the RT record is intended to work.
>
> Here's one scenario that I think these might be useful in.  Imagine two
> isolated island networks NA and NB, such as might exist in two companies
> or universities.  Each island network has a one or more routers, maybe
> RC and RD, with ISDN connections which can establish links to other
> networks.  Now let's say I try to telnet from one non-ISDN machine HE on
> network NA to a non-ISDN machine HF on network NB.  One way I could
> imagine things working is that router RC might advertise a default route
> to hosts on its network including HE.  So, when I telnet, HE would send
> its packets to RC.  Now, when RC received the packet addressed to HF, it
> might look up RRs for HF and it might find an RT RR for RD.  Looking up
> RD it might find an ISDN RR with RD's number.  It could then forward the
> packet through to RD, which would then forward it to HF.  HF's response
> would hopefully be sent back through RD (due to having correct updated
> routing information) which would then realize that it already has a
> connection open to RC, and would simply send it through.

For someone who finds it confusing, you have given a perfect example :-)

The routers, of course, don't see datagrams as requests/responses, but
route in each direction independently. (datagrams from HF in the example
route back to HE much as the original path from HE to HF was set up)
Usually this will result in the same path in both directions, but it
doesn't have to. (no, I don't think that is a problem: given a choice
between not reaching a host, and reaching it by an asymmetrical path,
I'll take the latter :-)

Note that they don't have to be "isolated island networks" for this
to be useful: for example, Prime runs its internal net using a private
X.25 network, configured as part of several PSDNS; some (most) of
Prime's traffic would be inappropriate on the Internet-proper (to, say,
one of our customers), being purely commercial.

> When we start scaling this simple example up, I see a lot of problems
> start popping up.  Imagine I just have a single host (at home maybe)
> with an ISDN connection.  Now, I want to telnet to a host which is
> somewhere on the Internet, behind maybe dozens of router hops.  It's
> hard to imagine that every host on the internet will have an RT RR in
> the DNS.  If I were a random site with hosts on the Internet, but no
> ISDN connections, what RT RR would I want to advertise?  There might be
> thousands of other hosts/routers on the Internet with ISDN connections.
> Which would I choose, and how?
> Drew

Good example. First, note that your host is going to need an initial
default route to bootstrap itself: another host (the one at work,
presumably, or perhaps a service like uunet or PSI). It has to know
a priori the Internet and ISDN or X.25 address of that host.

For hosts that do not have RT or ISDN records, you continue to use
the default(s). This may be desired behavior anyway, since reaching
connected-internet hosts is probably best accomplished via your
work/service. By "connected-internet", I mean hosts on nets known
to the core routers.

How do they reach you? Two cases. In the first case, you have an
IP address on a net advertised to the core (by your service host);
they reach you by routing in the normal way, your service host
finds you a priori.

Second case: you are on a net _not_ advertised to the core. No,
they can't reach you if they don't use RT/ISDN themselves. But
they couldn't reach you anyway ... (<grin>)

About every host (or domain, using wildcards at some level) having
RT or X.25/ISDN records: IMHO, an ISDN interface is going to be
commonplace soon; sites (even hosts) that do not have their own
will be very unusual indeed. (Put Down the Flame-Thrower, Sir!
Go back and take note of the "IMHO" :-)

IMHO: (<-- note again :-) with the extension of the Internet into
more and more commercial domains, and extensive use that would
be completely unacceptable to the research Internet (Prime and
customers exchanging EDI, for example), the new routing core
must be based on the ISDN, with real unrestricted access between
organizations.

Best Regards,
Robert Ullmann
Prime Computer, Inc.
+1 508 620 2800 ext 1736

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Oct 90 07:47:11 EST
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        hwb@MERIT.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
 > From tcp-ip-RELAY@NIC.DDN.MIL Tue Oct 30 07:05:31 1990
 > From: Hans-Werner Braun <hwb@merit.edu>
 > To: tcp-ip@nic.ddn.mil
 > Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action!
 > Cc: hwb@merit.edu
 > 
 > all of which play important parts of the network. Soooo, IBM running the
 > NSFNET and/or the Internet is really a little far fetched.

Awwwwww, and I just threw out my System/370 Yellow Cards with the EBCDIC Encodings :-)
-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Oct 90 11:17:52 -0500
From:      tmallory@BBN.COM
To:        Bernie Cosell <usc!bbn.com!cosell@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!

The IBM/NSFnet discussion has, for some reason or another, brought to mind the
ATT divestiture boondoggle.  I used to be able to get basic phone service for
$4.50/month that allowed people to call me, and to make a few local calls in
the bargain, and they threw in the phone rental too!  The most similar service
now is $14.46, and I have to buy and service my own phone.  The inexpensive
rate was apparently made possible by charging extra for long-distance service
in order to subsidize universal access, but it seems to me that a lot of
individuals benefitted, where now you have to be a business in order to save
money.

There's got to be a connection: at the very least it's not clear that allowing
a single company to run the show will necessarily be bad.

Tracy
-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Oct 90 11:47:06 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Driver for PRONET
    Does anyone know the whereabouts of a packet driver that would let me run
    TCPIP over PRONET with Proteon's cards??

To my knowlege, there have never been any Class 2 (ProNET-10) packet drivers.
Given that at least PC-IP and NCSA support the basic packet formats, it
wouldn't be hard to do one, but you'd probably want Netware support too...

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

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 05:21:14 GMT
From:      usc!bbn.com!drilex!dricejb@ucsd.edu  (Craig Jackson drilex1)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <1990Oct28.220432.521@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
>This is a call to action by all interested parties.
>
>There is wind of a proposal stirring in Washington that would place the 
>NSFNet backbone, and eventually the entire government-run part of the 
>Internet, into the hands of IBM.

It would seem to me, in the absence of *much* more detailed information,
that this is just so much conspiracy theory.

>Anyone want to bet how long the Internet remains accessible to non-IBM
>people?  Or whether the Internet ends up another Prodidy, with active
>censorship?  Whether you'll have to buy an IBM system to hook into it, 
>since they might decide that TCP/IP is no longer any good and now it's 
>time to go to SNA or worse?

Assuming that IBM has made such a proposal, why should they spend money
to turn something working in to something that doesn't work?  Not that
I think that IBM has turned out many good products over the years, but
they don't exist solely to torture computer programmers--they're actually
trying to make a buck.  Quite a few, in fact.

The principal reason why IBM would volunteer to run the NFSNet, etc would
be to enhance their standing in the academic technical community.  This
would encourage them to do a good job--the 'net' community is not one
that is easily swayed by appealing to a CEO or two.

<Karl goes on to propose that the net be turned into a government thing,
paid for like roads.  Let's hope nobody gets to send their packets over
the Mianus River bridge.>

>Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
>Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
>Macro Computer Solutions, Inc.   "Quality Solutions at a Fair Price"

P.S. I know people who love Prodigy--just because it can give them
a stock quote quickly.  As for the active censorship, it seems from
reports that they are a bit touchy about criticism.  However, any company
with "deep pockets" who does not actively censor a bbs service is
a bunch of fools--there are simply too many people willing to file
a civil suit or criminal charges over all sorts of nonsense.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Oct 90 14:01:58 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        jordan@Morgan.COM (Jordan Hayes)
Cc:        tcp-ip@nic.ddn.mil, com-priv@psi.com
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
Jordan,

Circa 1985 (half the lifetime of operational tcp/ip ago) a number
of non-profit organizations and consortiums were put together
to address the perceived needs, the included NYSERNet, SURANET,
BARRNET, etc, they were started as non-profits for the reasons
of that period.  In the same period UUNET started.

In 1990 PSINet fissioned off of NYSERNet, and it would appear ALTERNet
fissioned off of UUNET, for a number of reasons.  For PSINet they
included:  investment in infrastructure, tax issues including new
IRS reporting and the concept of taxation on "unrelated business
income" for a non-profit, and the concept of fair business practices,
where a non-profit for many reasons (including taxation, but also
liability) competes with commercial organizations unfairly.

[This is why RPI pays no taxes on its physical plant or income, except
	on the portion that is related to its growing technology park]

It has been rumored that a number of the mid-levels are discussing ways
to turn their services into for-profit endeavors for possibly many
of the reasons of above.

But ironically we have a "back to the future" movement of ANS repeating
what was done in 1985, hence the A in ANS "Advanced".  But of course
this is the story for 1990, we'll see how things evolve.

Marty

PS:  There is a great ANS marketing article in the Link Letter
(contact nsfnet-linkletter-request@merit.edu) front page, complete with
a picture of "Uncle Al", children, (but no flag) supported
by NSF Grant No. NCR 8720904 no less (at least according to
the publication)

PPS:  I thought I'd cc com-priv on this.

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

 Christopher Raczka <chris@ecdnt5.enet.dec.com> writes:

 	I also think the "other side" of the story does need to be told
 	and this much I do know...  Sometime in September, Merit, IBM
 	Corp, and MCI established Advanced Network and Services Inc.
 	(ANS) ANS, a NOT FOR PROFIT organization, is to manage and
 	operate the NSFNET backbone under subcontract to Merit

 Funny to see the NOT FOR PROFIT emphasis.

 Wasn't NYSERNET also started that way?

 /jordan
-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 30 October 1990 11:36am ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFnet to be run by IBM -- call to action!
> Christopher Raczka <chris@ecdnt5.enet.dec.com> writes:
>
>         I also think the "other side" of the story does need to be told
>         and this much I do know...  Sometime in September, Merit, IBM
>         Corp, and MCI established Advanced Network and Services Inc.
>         (ANS) ANS, a NOT FOR PROFIT organization, is to manage and
>         operate the NSFNET backbone under subcontract to Merit
>
> Funny to see the NOT FOR PROFIT emphasis.
>
> Wasn't NYSERNET also started that way?
>
> /jordan

First, the new structure (as I understand it) is pretty strange:
   Merit holds the NSFnet grant
   --> ANS holds a sub-contract to manage the grant
       --> Merit was hired by ANS to operate the network

Looks to me that ANS is a rather unneccessary intermediary!  This is IBM's
point of control.

Second, note the incorporation of ANS.  Merit is a Michigan academic
non-profit consortium.  MCI is also a Michigan company.  But ANS is
incorporated in New Jersey (near IBM).  The new president was hired
directly from IBM (a former VP there).  As far as I can ascertain,
ANS exists solely to pay this fellow's salary.

Third, when I suggested a few months ago that NIS.NSF.NET be moved to
to a more capable machine (because of problems accessing the RFCs
stored there), I was informed that IBM wouldn't allow the use of
non-IBM equipment in the NOC.  It seems to me that IBM is already
firmly in (political) control.

Fourth, has anyone actually looked at the ANS incorporation charter?
Is ANS *really* a non-profit?  By what definition?  How are the
corporate directors selected?

Fifth, I've heard of the NYSERnet/PSI debacle, but don't know the history.
Could someone take the time to post a summary of events to this group?

Sixth, I'll go read the com-pri archive at PSI.com, but believe this
discussion is appropriate to this group, as the general network
administration/questions base.

Bill Simpson
   09998was@msu.bitnet
   09998was@ibm.cl.msu.edu

[ANS is usually pronounced the same as the bodily orifice -- a particularly
bad choice of acronym.  Of course, ANSI was already taken....]
-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Oct 90 13:40:50 EST
From:      "Michael J. Saletnik - Local Unix Wizard's Apprentice" <icarus@End.Tufts.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Programming question
Hi.  I've got a question for all the experienced TCP/IP programmers out there.
I've been trying to find this in the manuals, but I can't anywhere.
I'd greatly appreciate confirmation of my technique and answers to the
random questions..
In any case:
System: Sun 3/50,3/180
OS: SunOS 4.1

Given a bound and listening socket, can I use
	fcntl(socket, F_SETFL, FNDELAY);
to cause it to be non-blocking, and that way when
I call accept() I'll either get back a new socket
for a new connection, or errno = EWOULDBLOCK
And when do I make the fcntl() call?

Given a newly connected socket from an accept(),
do I use
	fcntl(socket, F_SETFL, FASYNC);
to enable SIGIO signals, and
	fcntl(socket, F_SETOWN, getpid());
to point those signals at my process, and
	signal(SIGIO, handler);
to establish my handler?  What order should these
be?

Finally, if my signal handler is declared
	handler(sig, code, scp, addr)
	int sig, code;
	struct sigcontext *scp;
	char *addr;
how can I find out which socket (or file descriptor)
caused that signal?

	Thanks in advance,
				Michael J. Saletnik
				icarus@end.tufts.edu
-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 11:21:30 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!philapd!ssp18!aruit@bloom-beacon.mit.edu  (A. de Ruiter)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for X.25 network cards and NetBIOS/TCP/IP software
Dear Netreaders,

I am searching for X.25 network cards and NetBIOS software which can make use
of these X.25 network cards.

Our application runs at this moment on NetBIOS over TCP/IP via NI5210 in an
ethernet network.  We want, without adaptations in our application, to
support beside ethernet also X.25, by changing the version of TCP/IP ( and
NetBIOS ) and the network card.

We do not support MCA and EISA, but only XT and AT bus in our 386 PCs.

Please email me more information about X.25 network cards and NetBIOS and/
or TCP/IP software which support X.25 ( and ethernet ).

Thank you in advance and kind regards.

+----------------------------------------------------------------------------+
|                                        |Philips Information Systems        |
|  _                       __            |Optical Filing Systems, BK-C2      |
| /_| __ /_ _  __  __/_   /__)   ./_ _  _|Anton de Ruiter                    |
|/  |/ /(_ (_)/ / (_/(-' / \ (_//(_ (-'/ |Post Office Box 245                |
|                                        |7300 AE  Apeldoorn, The Netherlands|
|                                        |-----------------------------------|
|     __                  __             |Internet: aruit@idca.tds.philips.nl|
|    /  )_  /_ ._ _  /   /_ ./  .__ __   |UUCP    : ..!mcsun!philapd!aruit   |
|   (__//_)(_ /(_(_|(_  /  /(_ // /(_/   |Phone   : 31 55   433514 (Business)|
|      /                           _/    |Phone   : 31 5486 18199  (Home)    |
|                                        |Fax     : 31 55   433488           |
+----------------------------------------------------------------------------+
-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 14:30:55 GMT
From:      att!devildog!jrallen@ucbvax.Berkeley.EDU  (Jon Allen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for utility to monitor RIP packets
In article <775@casbah.acns.nwu.edu> matt@acns.nwu.edu writes:
>I am looking for a UNIX utility that will listen for all the RIP
>packets on a network and display their contents.  I am essentially
>trying to duplicate the output of a cisco router with RIP debugging
>turned on.  The output looks something like:
>
>Received RIP update from xxx.xxx.xxx.xxx:
>  network yyy.yyy.yyy.yyy in n hops
>  network zzz.zzz.zzz.zzz in m hops
>  ...

Actually, most 4.XX based TCP/IP implementations used on various
flavors of UNIX have options to the 'routed' command to print out
just the information you are talking about.  All packets received
by routed (and those sent out) are printed.

I don't have the man page handy, but on System V I have used the -t or
log option to output this information.  This has proved to be a very
useful debugging tool on networks with many routers exchaning info.

-Jon
jrallen@devildog.att.com
-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 16:17:52 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!


The IBM/NSFnet discussion has, for some reason or another, brought to mind the
ATT divestiture boondoggle.  I used to be able to get basic phone service for
$4.50/month that allowed people to call me, and to make a few local calls in
the bargain, and they threw in the phone rental too!  The most similar service
now is $14.46, and I have to buy and service my own phone.  The inexpensive
rate was apparently made possible by charging extra for long-distance service
in order to subsidize universal access, but it seems to me that a lot of
individuals benefitted, where now you have to be a business in order to save
money.

There's got to be a connection: at the very least it's not clear that allowing
a single company to run the show will necessarily be bad.

Tracy

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 16:33:39 GMT
From:      comp.vuw.ac.nz!windy!srwmcln@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet echo negotiation question
Many implementations of Telnet are broken in one way or another, often in the
area of echo (or other option) negotiation. A common problen is that some
refuse to allow, no remote/no local echo. Then there is the 8 bit binary
situation......

Many implementations are just copies of other broken implementations, and
so it goes on.
 
Clive.
-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 18:07:06 GMT
From:      usc!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!tartarus.uchicago.edu!faustus@ucsd.edu  (Kurt Ackermann)
To:        tcp-ip@nic.ddn.mil
Subject:   cross-post on this topic
On the IBM-NSFNet discussion, cross-post to 

comp.org.eff.talk

This group will have interesting insights and contributions
to make as well, and it falls within their general scope of
discussions.

BTW, EFF is the Electronic Frontier Foundation, well worth
looking into... :-)

I told them to look in news.admin, etc. to get the 
conversation so far...



Kurt Ackermann

"Grey, dear friend, are all your theories;  --Mephisto. in
 the golden tree of life is green!"           Goethe's Faust
-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 19:08:47 GMT
From:      mstan!jordan@uunet.uu.net  (Jordan Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
Clay Luther <cluther@supernet.haus.com> writes:

	Since when was $2000/month cheap?

Since when have you priced Internet access?

PSI charges $60k/year for T1.

I'm sure most of the other ones are similar.

/jordan
-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 19:40:16 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   Re: Internet/NSFnet to be run by IBM -- call to action!

> Christopher Raczka <chris@ecdnt5.enet.dec.com> writes:
>
>         I also think the "other side" of the story does need to be told
>         and this much I do know...  Sometime in September, Merit, IBM
>         Corp, and MCI established Advanced Network and Services Inc.
>         (ANS) ANS, a NOT FOR PROFIT organization, is to manage and
>         operate the NSFNET backbone under subcontract to Merit
>
> Funny to see the NOT FOR PROFIT emphasis.
>
> Wasn't NYSERNET also started that way?
>
> /jordan

First, the new structure (as I understand it) is pretty strange:
   Merit holds the NSFnet grant
   --> ANS holds a sub-contract to manage the grant
       --> Merit was hired by ANS to operate the network

Looks to me that ANS is a rather unneccessary intermediary!  This is IBM's
point of control.

Second, note the incorporation of ANS.  Merit is a Michigan academic
non-profit consortium.  MCI is also a Michigan company.  But ANS is
incorporated in New Jersey (near IBM).  The new president was hired
directly from IBM (a former VP there).  As far as I can ascertain,
ANS exists solely to pay this fellow's salary.

Third, when I suggested a few months ago that NIS.NSF.NET be moved to
to a more capable machine (because of problems accessing the RFCs
stored there), I was informed that IBM wouldn't allow the use of
non-IBM equipment in the NOC.  It seems to me that IBM is already
firmly in (political) control.

Fourth, has anyone actually looked at the ANS incorporation charter?
Is ANS *really* a non-profit?  By what definition?  How are the
corporate directors selected?

Fifth, I've heard of the NYSERnet/PSI debacle, but don't know the history.
Could someone take the time to post a summary of events to this group?

Sixth, I'll go read the com-pri archive at PSI.com, but believe this
discussion is appropriate to this group, as the general network
administration/questions base.

Bill Simpson
   09998was@msu.bitnet
   09998was@ibm.cl.msu.edu

[ANS is usually pronounced the same as the bodily orifice -- a particularly
bad choice of acronym.  Of course, ANSI was already taken....]

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 22:17:29 GMT
From:      sdcc6!jclark@ucsd.edu  (John Clark)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <9010301830.AA08855@ucbvax.Berkeley.EDU> tmallory@BBN.COM writes:
+
+There's got to be a connection: at the very least it's not clear that allowing
+a single company to run the show will necessarily be bad.

May Teddy Roosevelt roll over in his grave and shoot a bull moose!

The only reason it was so 'good' is because ATT was so 'restricted'
by the government. Don't think for a minute that ATT wouldn't have
raised the price to what the market could bear if it had had the
chance.
-- 

John Clark
jclark@ucsd.edu
-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 23:05:01 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!csg@ucsd.edu  (Carl S. Gutekunst)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
>I don't think that eveyone needs to scrap the NSFNet right now, especially
>since it is free.

Beg yer pardon? That's for Universities. Doesn't NSFNet charge something like
$5000/month just in fees, not including network equipment costs?

<csg>
-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 90 23:11:57 GMT
From:      voder!pyramid!csg@ucbvax.Berkeley.EDU  (Carl S. Gutekunst)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
>Since when was $2000/month cheap?

We were talking about NFSNet. Your "common man" can't connect to it at all.
If you're talking about 1.544Mbps worldwide TCP/IP connections, with routing,
nameservice, and network administration all done for you, $2000 per month is
very cheap. And the price will continue to drop.

On-the-order-of $100 per month Internet access is out there, too. Isn't that
what PSI is doing? But you aren't going to support a supercomputer or several
hundred sessions off that.

<csg>
-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 00:33:00 GMT
From:      usc!julius.cs.uiuc.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Driver for PRONET
In article <9010300553.AA25380@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:

   Does anyone know the whereabouts of a packet driver that would let me run
   TCPIP over PRONET with Proteon's cards??

As far as I know, there is no packet driver for any Proteon cards, nor is
anyone working on one.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.
-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Oct 90 09:29:59 PST
From:      braden@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
I would like to suggest that IBM-bashing, no matter how enjoyable a 
pastime for some, is not an appropriate use of this mailing list.
Besides, it is very BORING.

Bob Braden

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Oct 90 10:08:53 PST
From:      braden@venera.isi.edu
To:        clynn@bbn.com, jbvb@ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols

	You're right:  RECEIVE calls are supposed to be queued until the connection
	reaches ESTABLISHED (RFC 793, pg 58).  The discussion of OPEN, SEND and
	RECEIVE in that section seems somewhat out of line with the requirement
	elsewhere in the RFC that TCPs accept data with the initial SYN, because
	it appears that the API specified in section 3.9 can't generate it (SENDs
	are queued until the connection reaches ESTABLISHED as well).

	I will raise this as an issue with the HR WG.  My own initial feeling
	is that the API's restriction is unnecessary, and could be relaxed at
	considerable benefit to the Internet...

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

James,

I believe that the API defined in RFC-793 was intended to describe
the MINIMUM set of capabilities required of an implementation; in
fact, there are weasel-words about that in the RFC.  Thus, it was
not intended to be a "restriction"; an implementation could go
beyond it, to include for example, a call: OPENandSEND(...).

I also believe, however, that the detailed protocol description
in RFC-793 is inconsistent in a number of little ways with the
5-packet minimum request-response exchange that TCP could in
principle provide:

    1.   SYN, req-data, FIN ----->  
    2.                   <--------- SYN, ACK
    3.   ACK -------->  (deliver data to application)  
    4.                   <---------  ACK, rep-data, FIN   
    5.   ACK -------->   

There are problems both in the state diagram and in the event
processing rules.  Although some of the early research TCP's could
handle this 5-packet exchange, the issue did not get a lot of attention
when the DoD put the heat on the research group to tie down the TCP
spec.  Maybe there is a job here for Host Requirements Man (leaps
tall buildings at a single bound, etc). 

Pardon me while I wax philosphical for a moment.

The early TCPs were all designed to implement "what the protocol meant"
(as Charlie Lynn can attest).  The words in RFC-793 were written later,
and getting them exactly right was (and is!) HARD.  Witness the Milspec
spectacle.  Implementors are still advised to implement what the
protocol means, not what the spec says.

It is arguably a defect of TCP as a protocol (and an advantage of TP4?)
that TCP is very subtle, and therefore it is complex and difficult to
describe in detail.  Writing an efficient and fully correct TCP ab
initio is still a great programming challenges, I believe (as I think
you will agree, James!)  I wonder of there are ANY fully correct
implementations of the (entire) TCP protocol in the world today?

Bob Braden
    

    
    
-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Oct 90 11:11:59 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        Charles Lynn <clynn@BBN.COM>
Cc:        tcp-ip@nic.ddn.mil, Phil Karn <bellcore-2!envy!karn@rutgers.edu>
Subject:   Re:  Reliable Datagram ??? Protocols
    From: Charles Lynn <clynn@BBN.COM>

    Doesn't TCP require the connection to be in the ESTABLISHED state before
    it is permitted to deliver data to the application?  If so, I think B
    cannot see the data until it gets the ACK of its SYN from A, thus the
    response from B cannot be includes with B's SYN ACK.

You're right:  RECEIVE calls are supposed to be queued until the connection
reaches ESTABLISHED (RFC 793, pg 58).  The discussion of OPEN, SEND and
RECEIVE in that section seems somewhat out of line with the requirement
elsewhere in the RFC that TCPs accept data with the initial SYN, because
it appears that the API specified in section 3.9 can't generate it (SENDs
are queued until the connection reaches ESTABLISHED as well).

I will raise this as an issue with the HR WG.  My own initial feeling
is that the API's restriction is unnecessary, and could be relaxed at
considerable benefit to the Internet...

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

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 02:57:43 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uhccux!okumura@ucsd.edu  (Chad Okumura)
To:        tcp-ip@nic.ddn.mil
Subject:   HELP  ! ! ! ! !

	Can anyone out there tell me where I can find a copy of 
'lharc' ???  or better yet...send me a copy???  I need this 
file in order to look at the gif files I've just gotten.  Also, 
how do I ftp to SIMTEL20.arpa??? I have tried the command:
'ftp SIMTEL20.arpa', but this doesn't seem to work....Thanks
in advance...

--chad
University of Hawaii
Computing Center
-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 04:38:49 GMT
From:      usc!samsung!emory!stiatl!srchtec!mra@apple.com  (Michael Almond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <1990Oct29.205244.2051@supernet.haus.com> cluther@supernet.haus.com (Clay Luther) writes:
>csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>
>>and 64K DDS lines are ***cheap*** these days, so cheap that UUNet can build
>>a truly commercial TCP/IP service, give excellent service, and charge less
>>than $2000/month for it.
>Internet will not be cheap until it drops to say, $100/month, or less.

	Well I don't know when the price will drop to $100/month, but you
can get Internet access at $250/month, which isn't bad.  We here at Search
are planning to join the Internet through PSINet.  They charge $250/month
for dialup SLIP, I think eventually they'll have ISO once it is stable.

	With a NetBlazer at your sight, it is almost as good as a dedicated
line connection.

	As time goes by the prices of the hardware will drop an maybe we'll
reach the $100/month mark.


---
Michael R. Almond                                  mra@srchtec.uucp (registered)
search technology, inc.				        emory!stiatl!srchtec!mra
Atlanta, Georgia                                         (404) 441-1457 (office)
.'.'.'.'.'.'.'.'.'.'.'.'.'. Georgia Tech Alumnus .'.'.'.'.'.'.'.'.'.'.'.'.'.'.'.
-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Oct 90 12:39:07 PST
From:      guyton%condor@rand.org
To:        mstan!jordan@uunet.uu.net (Jordan Hayes)
Cc:        tcp-ip@nic.ddn.mil, guyton%condor@rand.org
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
> PSI charges $60k/year for T1.
>
> I'm sure most of the other ones are similar.

Fyi, our Los Nettos bill (T1) is $60k for 1st year, about $30k
per year after that.  [initial estimates, we've been on for
a couple years now and I've not gone back to check to see
how accurate the estimates turned out]

-- Jim Guyton
   guyton@Rand.org

p.s. Los Nettos := LA area region, gateway'd to Cerfnet.  No NSF funding
-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 05:23:49 GMT
From:      att!emory!rsiatl!jgd@ucbvax.Berkeley.EDU  (John G. DeArmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
dricejb@drilex.UUCP (Craig Jackson drilex1) writes:

>It would seem to me, in the absence of *much* more detailed information,
>that this is just so much conspiracy theory.

Well Senate Bill 1976 may be a conspiracy but is a damn threatening one.
Read my previous post to see how theory is reduced to practice.

>Assuming that IBM has made such a proposal, why should they spend money
>to turn something working in to something that doesn't work?  

You ever used IBM products?  If you have, how can you ask that question?

>they're actually trying to make a buck.  Quite a few, in fact.

Precicely.  Which has NOTHING to do with our being able to actually
USE what they provide for us.  Witness, the PC Jr.  Or any Series/1.
Etc.

>The principal reason why IBM would volunteer to run the NFSNet, etc would
>be to enhance their standing in the academic technical community.  

No, according to IBM's news release, they will be in it along with 
Compu$erve and McGraw-Hill and others STRICTLY to make a buck.

><Karl goes on to propose that the net be turned into a government thing,
>paid for like roads.  Let's hope nobody gets to send their packets over
>the Mianus River bridge.>

No, I hope the net turns into something like the Interstate system here
in Atlanta.  Here, the goverment (more or less) builds enough roads
to keep up with growth.  I can hit I-75 (a 10 lane interstate), get 
onto the perimeter I-285 (another 10 lane interstate) and be 30 miles
across town in not much more than 30 minutes.  Yes, it does congest
during times of high usage but it is also one of the main fuelers
of growth in the metro area.  A properly designed and managed FREE
data highway could do the same thing on a national basis.

John


-- 
John De Armond, WD4OQC  | "The truly ignorant in our society are those people 
Radiation Systems, Inc. | who would throw away the parts of the Constitution 
Atlanta, Ga             | they find inconvenient."  -me   Defend the 2nd
{emory,uunet}!rsiatl!jgd| with the same fervor as you do the 1st.
-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 08:13:04 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <4562@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. DeArmond) writes:
...
>>Assuming that IBM has made such a proposal, why should they spend money
>>to turn something working in to something that doesn't work?  
>
>You ever used IBM products?  If you have, how can you ask that question?
:-) :-) :-)

>>they're actually trying to make a buck.  Quite a few, in fact.
>
>Precicely.  Which has NOTHING to do with our being able to actually
>USE what they provide for us.  Witness, the PC Jr.  Or any Series/1.
>Etc.
>
>>The principal reason why IBM would volunteer to run the NFSNet, etc would
>>be to enhance their standing in the academic technical community.  
>
>No, according to IBM's news release, they will be in it along with 
>Compu$erve and McGraw-Hill and others STRICTLY to make a buck.
EXACTLY!!!!! Please remember that IBM is not interested in making
anything else but money! If the machine works, it's an added bonus, but not
really part of the specification :-) :-). If they could have made money
marketing peas they would have done so ("oh, you want a container to transport
the peas home in? well that is an optional extra").

                                       
-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Oct 1990 16:49:18 EST
From:      "Michael H. Morse" <mmorse@z.nsf.gov>
To:        tcp-ip@NSF.GOV
Subject:   Problem with Xmodem and 3Com terminal server
I am having a problem getting Xmodem to work between a Sun workstation
and a PC running a terminal emulator.

The PC uses a modem and a dial-up line to communicate, but it cannot
get to the workstation directly because the workstation has no serial
ports.  Instead, the PC logs on to some other host, and then uses
telnet to get to the workstation.

We have a 3Com terminal server that is normally used in this situation,
but we've found that Xmodem does not work (the PC nacks everything it
gets) in this configuration.  However, if the PC logs onto one of our
Ultrix hosts, and in effect uses it for a terminal server to telnet to
the workstation, Xmodem works fine.  Subsequent tests have absolved the
terminal emulator (on the PC) and the xmodem program on the
workstation, leaving suspicion around the telnet implementation
on the terminal server.

I suspect this has something to do with parity, since the ASCII
characters transmitted by Xmodem, and received by the PC are
identical.  Has anybody run into a similar problem? Any information on
how telnet reacts when raw mode is selected would be appreciated.

Thanks in advance.

--Mike

-- 

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
                                       Telephone: (202) 357-7659
                                             FAX: (202) 357-7663
-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 11:50:45 GMT
From:      mcsun!inria!bull.bull.fr!cediag!Patrick.Hayes@uunet.uu.net  (Patrick Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <9010290338.AA14240@decpa.pa.dec.com> chris@ecdnt5.enet.dec.com (christopher raczka) writes:
>Sometime in September, Merit, IBM Corp, and MCI established Advanced
>Network and Services Inc. (ANS)
> 
>ANS, a NOT FOR PROFIT organization, is to manage and operate the NSFNET
>backbone under subcontract to Merit
Shades of D.D. Harriman and "The Man Who Sold The Moon"...

Pat
#include <standard.disclaimer>
--

+-------------------------------+-----------------------------------------+
| Patrick Hayes                 |  EMail :  Patrick.Hayes@cediag.bull.fr  |
| BULL CEDIAG                   |     or                   hayes@bull.fr  |
| 68, Route de Versailles       |     or    ...!mcvax!inria!bullfr!hayes  |
| F-78430 Louveciennes FRANCE   |    Tel : (33 1) 39 02 49 55             |
+-------------------------------+-----------------------------------------+
-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 13:54:06 GMT
From:      usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!kehoe@ucsd.edu  (Brendan Kehoe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: HELP  ! ! ! ! !
In <10090@uhccux.uhcc.Hawaii.Edu>, okumura@uhccux.uhcc.Hawaii.Edu writes:
>	Can anyone out there tell me where I can find a copy of 
>'lharc' ???  or better yet...send me a copy???

  Redirected to comp.sys.ibm.pc.




Brendan Kehoe | Soon: brendan@cs.widener.edu [ Well, in 1990 I hope. ]
For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu
"It's a distinctly non-trivial task to decompile a stripped, encrypted binary
 into something that can be understood." - Keith Bostic, on the Internet worm
-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Wed 31 Oct 90 23:20:04-PST
From:      William Chops Westfield <BILLW@mathom.cisco.com>
To:        mmorse@z.nsf.gov
Cc:        tcp-ip@NSF.GOV
Subject:   Re: Problem with Xmodem and 3Com terminal server
Even when transferring text files, XMODEM needs a clear 8-bit path to
accomadate its block counts and checksum.  By definition, telnet is a
7 bit protocol, and you must negotiate "binary" mode to get an 8-bit
path.  The terminal server may be refusing binary mode negotiations,
may just do binary incorrectly, or may just need configured differently.

Also, some telnet implementations ignore the "7-bit" definition, and
routinely send 8 bit data anyway.  This is useful, but means that a
telnet terminal server strictly adhering to the standard might not work
as well as one with a more flexible interpretation.  The Hosts Requirement
document was carefully worded to allow 8-bit transmission, as long as
you were doing actual "parity".

Bill Westfield
cisco Systems.
-------
-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 17:32:58 GMT
From:      swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!sunee!erick@ucsd.edu  (Erick Engelke)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Driver for PRONET
In article <9010301647.AA01687@ftp.com> jbvb@ftp.com writes:
>>
>>    Does anyone know the whereabouts of a packet driver that would let me run
>>    TCPIP over PRONET with Proteon's cards??
>>
>To my knowlege, there have never been any Class 2 (ProNET-10) packet drivers.
>Given that at least PC-IP and NCSA support the basic packet formats, it
>wouldn't be hard to do one, but you'd probably want Netware support too...
>

We run a big proNET 10 system with about 20 interconnected token rings.
We found the most useful solution was to make a packet driver which
fully emulates the Ethernet card.  Other than multicasts, this is actually
quite easy.  This allows us to use PC-IP, NCSA, etc. in the mode they were
written and tested in-Ethernet mode.  Unfortunately, our driver must also
handle our local routing, network card demultiplexing, etc., so it is
not particularly useful for you.  If you are interested in doing the 
work yourself, I could mail you some tips.

Erick
Network Systems Manager
Faculty of Engineering
University of Waterloo
-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 18:07:30 GMT
From:      manager@cai.com
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: Cheap (or Free) TCP-IP for VMS

In article <1990Oct29.182022.2227@terminator.cc.umich.edu>, baw@terminator.cc.umich.edu (Brian Wolfe) writes:
> I'm trying to get a few departments of my company to get together to
> help finance an Internet connection and unfortunately not all of them
> have money to pay for the connection and the TCP-IP software for VMS.
> (One of the machines we need it for is a Vax 6440, soon to be traded in
> for a Vax 9000)
> 
> Is there any free or very cheap TCP-IP software for VMS available?
> Telnet and FTP would be the only applications they need.
> 
> Brian Wolfe
> Rush Medical Center
> Chicago, IL 
> bwolfe@rpslmc.edu
> (312)-942-5781

I highly recommend Carnegie Mellon Universities CMU-TEK TCP/IP.  The following
information is from the latest newsletter:

	Kdren Heilman
	(412)268-5896
	KH55@andrew.cmu.edu
	Carnegie Mellon University
	4910 Forbes Avenue UCC 124
	Pittsburgh, PA 15213

	$125 for the license
	add $25 for TK50
	add $25 for Purchase Order
	add $50 for outside US

Requests to get on the mailing list go to 'cmu-tek-tcp-request@andrew.cmu.edu'.
The mailing list is 'cmu-tek-tcp@andrew.cmu.edu'. To preempt some common
questions:

	1. It doesn't do NFS.
	2. It can do TELNET, FTP, Domain Name Service, LPR
	3. It works with (at least) VMS 4.7 through 5.4.
	4. Most of it is in Bliss, sources are included.
	5. The pre-compiled system provides for a DEC Ethernet driver.
	6. You can build an IP-over-DECnet driver, a SLIP driver, and
           and IP-over-X.25 driver, but you may experience great anguish
           in getting them to work in your environment.
        7. There is a DECwindows transport for CMU-TEK TCP/IP, so your
           favorite Unix box can be an X client to your VAXstation.

I have absolutely no affiliation with CMU. I am providing this information of
my own free will in hopes of improving the quality of your network life. 
Flames to /dev/null, NLA0:, or whatever passes for your local bitbucket.

-- 
Todd Aven
Manager, Mid-range Computer Services
Computer Associates International

Internet:	manager@cai.com
UUCP:		uupsi!usgcdh!manager

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 18:15:13 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <1990Oct31.081304.14531@lth.se>, e85rw@efd.lth.se (Ricard Wolf)
writes:
> EXACTLY!!!!! Please remember that IBM is not interested in making
> anything else but money! If the machine works, it's an added bonus, but not
> really part of the specification :-) :-). If they could have made money
> marketing peas they would have done so ("oh, you want a container to transport
> the peas home in? well that is an optional extra").

The government would be much less responsive.  At least if you needed a container
from IBM or whomever you could get one.  With the government running things
you might get a container if you could prove that everyone needed one and
then only after the peas had spoilt.

Things work well because we have a org that is not keeping a strick close
eye on things.  With the budget in the shambles that it is in, do you really
think that the US government is not going to take a much more active role
in the who/what/when/where of the network?  Is this really what you all want?

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 90 18:33:08 GMT
From:      bywater!dagobah!mis@uunet.uu.net  (Mark Seiden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFnet to be run by IBM -- call to action!
as usual, several of the important little details seem to be
wrong...

09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes:

>[...] note the incorporation of ANS.  Merit is a Michigan academic
>non-profit consortium.  MCI is also a Michigan company.  But ANS is
>incorporated in New Jersey (near IBM).  The new president was hired
>directly from IBM (a former VP there).  As far as I can ascertain,

new jersey is near ibm, in new york?  it's also near washington dc...
what relevance does state of incorporation have other than limiting
director's liability in the case of a nonprofit?  this is a non-issue.

weis' most interesting job was at ibm research where he directed the
computing systems department (i.e. the comp center and research
internet as well as tcp and nsfnet development)...

by the way, he retired after 30 years at ibm.

>ANS exists solely to pay this fellow's salary.
 
i suspect you haven't tried too hard to "ascertain" that there seem to be
several other employees.  the ex-ibm corporate officers reportedly are
precluded from any "right of return" to ibm should something go awry.
they do seem to be hiring, or at least looking.

>Third, when I suggested a few months ago that NIS.NSF.NET be moved to
>to a more capable machine (because of problems accessing the RFCs
>stored there), I was informed that IBM wouldn't allow the use of
>non-IBM equipment in the NOC.  It seems to me that IBM is already
>firmly in (political) control.

i agree that a good test of independence is how equipment is chosen.
i believe ANS was founded partly because of frustration experienced in
getting a difficult job done within the confines of large
organizational politics.  the problem you cite (if accurately) would
be a perfect example of how hard such things would be to do this
within IBM (or many other large organizations) compared with as an
independent entity.

>Fourth, has anyone actually looked at the ANS incorporation charter?
>Is ANS *really* a non-profit?  By what definition?  How are the
>corporate directors selected?

yeah, i've heard it really is, though i haven't looked. nonprofit is
an IRS term. i'm not sure what x value is (for 501c(x) of the tax
code).  looked to me like the directors were a pretty good
distribution of folks.

>[ANS is usually pronounced the same as the bodily orifice -- a particularly
>bad choice of acronym.  Of course, ANSI was already taken....]

thanks for your delicacy in pointing out this important issue to all
of us... (now go away...) i usually pronounce it like the Brooklyn
department store: A&S.

>>dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>>they're actually trying to make a buck.  Quite a few, in fact.

>john dearmond replies:
>Precicely.  Which has NOTHING to do with our being able to actually
>USE what they provide for us.  Witness, the PC Jr.  Or any Series/1.
>Etc.

(what an idiotic argument.) yes, companies make mistakes sometimes,
and in retrospect it's easy to point them out. these people are 
supposed to be independent of ibm.

>>The principal reason why IBM would volunteer to run the NFSNet, etc would
>>be to enhance their standing in the academic technical community.  

>john dearmond replies:

>No, according to IBM's news release, they will be in it along with 
>Compu$erve and McGraw-Hill and others STRICTLY to make a buck.

well, i'll bet john is the usual loose cannon on the facts.  what did
that quote say EXACTLY? it isn't legal for IBM to derive special
benefit from the *nonprofit* status of ANS.  in particular, taking
money out of ANS isn't possible.  maybe the partners are thinking
they'll make more money in the longterm if there's a better internet.
there are lots of products and services that can't be provided without
a better internet.  so what?  some others of us will doubtless benefit
as well...

(well, at least he didn't call anybody a slut this time)...
-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Wed 31 Oct 90 23:44:51-EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        tcp-ip@nic.ddn.mil, smds@nri.reston.va.us, frame-relay@nri.reston.va.us
Cc:        lynch@A.ISI.EDU, ekearney@interop.com
Subject:   SMDS Interest Group Meeting
There will be a one day meeting on Nov 15 at the Red Lion Inn in San Jose, CA
open to anyone interested in potentially forming a working group to further
the avaiability of SMDS service both in the US and internationally.  The
intention is to have the "interest group" be composed of users, service
providers (local and long distance carriers), computer manufacturers and
router/switch manufacturers.  Essentially we all have a stake in seeing
to it that such an "offering of service" is defined and provided in a way
that is useful for both buyers and sellers.  If you are interested in 
coming to this meeting, please contact Elaine Kearney at 415-941-3399
or as ekearney@interop.com for further meeting details.  We have set
aside a room for 200 for this meeting and if that is not enough we need to
know soon.  

Dan
-------

END OF DOCUMENT