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 September 1990 (419 messages, 270450 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 90 07:49:32 GMT
From:      mips!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@apple.com  (Mark Eggers)
To:        tcp-ip@nic.ddn.mil
Subject:   proxy arp
Is there anywhere I can get proxy arp that will run on a Sun 4 ??

thanks - /mde/
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 90 08:28:35 GMT
From:      olivea!tymix!cirrusl!sungraph!dhesi@apple.com  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU
(Mark Crispin) writes:

>If "network I/O looks like local device I/O" under Unix then when the
>h*ll do I have to worry about all the socket or streams crap?

I think the confusion in this discussion is between reading and
writing on the one hand and opening the connection on the other
hand.

Once a virtual circuit has been set up, the socket mechanism becomes
transparent to the extent networking will allow.  Setting up the
virtual circuit does require more steps than opening a device or file.
I find this fairly understandable, because the BSD socket interface
gives you LOTS of options, and it was designed to be independent of the
underlying transport mechanism.

>If I want to connect to port 0.143 on host 128.95.112.69, why can't I
>do something like
>  open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);...

Like somebody said, it would be nice if there was a library routine
that would make this easy.  I suppose the open() system call could also
do this, but then there might be too much functionality in a single
system call, because it would have to understand all possible protocols
and possibly accept additional parameters for the different types of
sockets and connections that are possible.

Quick!  Get a copy of Stevens's book on UNIX network programming.  The
socket mystery will be gone for ever.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Sep 90 19:15:59 -0400
From:      bzs@world.std.com (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   sockets vs. streams

Why does everyone assume this topic is so heated? I think the
discussion is long overdue and we'd all benefit from getting it out in
the open (or is that in in the open()?).

I'm mixed on this issue. TOPS-20 had a file-system-like interface (was
that BBN's TCP?) and, to be frank, I found it quite clumsy (tho
interesting.) The string one passed to the open call started to look
more and more like a long string of IBM/JCL and less and less like a
file name as various options were added.

In MRC's example, the fact that the connection was active or passive
was passed via the flags field (O_CREAT in the example.)

That removes a lot of the utility; I can't specify it on a command
line easily, passing what I want transparently thru a utility that
otherwise doesn't really know it's doing network I/O. That should be a
major goal if we are going to bother at all.

But that leads to things like:

	"/dev/tcp/active/192.74.137.5/143/debug=true/...."

or something like that. I guess one could say "so what, at least you
can do it!" (and, in fact, I don't have a good response to that!)

As to David Stevens questions about file system semantics, what does
"cd /dev/anydev" mean now? Nothing, you get back "Not a directory".
In this mythical TCP you might get back something (e.g. some form of
NFS done this way), or not. I don't see that as a serious problem.

Again, with "ls /tcp" it could be treated like a device, in general
nothing happens (you get back info about just "/tcp".) One could
imagine more being done, but that's an acceptable start.

Seek, urgent data etc, none of that stuff works on every device.

I see you're focusing on the filesystem aspect. It's not that TCP *is*
a filesystem, it's that you can address it with the naming conventions
of the filesystem.

I suppose a counter-argument is why then can't I:

	open("/dev/tty06/9600/cbreak/noecho/xtabs/even/nonl",...)

I dunno, why not?

I'm also not convinced that anything that's happened thus far is
mutually exclusive to a filesystem-like interface. Perhaps it would be
too bad to have two similar interfaces, but that's the worst that
could happen.

In fact, it could be implemented right now. Just write a library with
some of the necessary syscalls written at user-level to recognize
names like this (or if they look like regular files then pass them on
to the kernel) and see how it works. This is kids' stuff, if anyone
wants to know how or doubts it can be done send me mail. You don't
have to touch the kernel to do this (at least not to do a proto.)

On systems with shared libraries it could even be made to work with
existing binaries (tho that can get "exciting", but no big deal if you
have an extra disk to boot off of for experimenting.)

I think there was a project out of Purdue several years ago which did
just this (I forget the name.) I remember playing with some software
from there which did something like this, all user level. Or maybe I
was writing it...hmmm.

My experienced guess is that as one puts it all together all sorts of
problems will arise and it'll tend to get kludgier and kludgier as
more crap is added to that string to make it work.

Maybe I'm wrong, but an experiment is easy enough. I can't see why
someone who was terribly interested wouldn't just demo a prototype and
write a paper for all of us to read (perhaps first verifying that it
hasn't been done a half-dozen times before, possibly reporting where
the disappointments existed.)

        -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
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Sep 90 16:44:44 WET DST
From:      Nick Felisiak <nick@spider.co.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Are sockets the wave of the future
In article <2117@rossignol.Princeton.EDU> Tom Reingold writes:

> At my job, we are about to write some applications for running over
> TCP/IP on Unix hosts.  We would like to think ahead with portability in
> mind.  One day, our code may run on a non-unix host.  And if we write
> it in sockets, we may run against a version that is built upon and
> supports only STREAMS.  Or will we?

> 1. What implementations are built on STREAMS?

There are three that I know of, and probably several that I don't.  I'm
not trying to be exahustive below!

1.  Lachman/Interactive - this originated from Convergent Technology, and
    is widely used on 386 machines.

2.  Wollongong - used by AT&T.

3.  Spider - used by Prime, Olivetti (In the UK), etc.

> 2. Are they new or old?

Spider's was done specifically for streams - i.e the kernel code is not
based on BSD!

> 3. Are all TCP/IP suites done with sockets nowadays?

I think all the UNIX products offer both sockets and TLI.

> 4. Is there a reason to consider implementing our code in STREAMS?

If it's application level code, this is largely irrelevant.

> 5. Currently, our hosts run System V release 3.[23] and have both
> libraries.  Which is "the way" to go?

I  discuss my biases below.

In article <1990Aug24.220021.10122@murdoch.acc.Virginia.EDU>, Ran Atkinson
continues:

> The network interfaces specified by the System V Interface Definition
> and by the X/Open consortium are based on the STREAMS with TLI (Transport
> Level Interface) that were originally developed at AT&T.

(What follows may be considered controversial!)

TLI is firstly very ISO-oriented, and secondly half a specification.
This causes the TCP interface user a number of problems.  The
ISO-orientation means that certain things which TCP wants to do are just
impossible.  There is no equvalent to the 'getpeername()' call, for
instance.  Inetd style servers cannot, therefore, discover where they
are being called from (if they care) using TLI as defined.  The
'half-a-specification' aspect refers to the lack of a 'standard' for
address formats, name services, etc.  In the TCP world, I think everyone
has gone for the Berkley 'sockaddr' structure as the address structure
used in t_bind, etc.  Lucky there was a standard already there!  I've
seen one implementation (can't remember who's) which took a host name
and port number as ASCII strings - which is probably more in the spirit
of TLI.  I never found out if they had put the whole of the resolver
library into the kernel, or what they did about specifying the remote
address on a connect indication.

I have a long list of shortcomings of TLI - mail me if you're interested!

> Since the System V socket-library is built on top of STREAMS/TLI, 
> an application written to use sockets will probably be slower on
> a System V system that the same application written using STREAMS/TLI
> natively.  In general I think that the STREAMS/TLI approach is better
> because details of the transport protocol used are appropriately hidden
> unlike BSD sockets.

Not true.  TLI does not provide a super-set of the Socket interface, and
so building a compatible socket interface on top of TLI is not possible.
We (Spider) have a 'socket library' which uses ioctl calls (in the main)
to our TCP driver, which also understands the TLI messages (TPI at that
level).

I really don't see how details of the transport protocol are hidden by
TLI.  You still need to code up name to address translation (almost
certainly using 'gethostbyname' type calls), and probably implement the
TLI counterpart to 'setsocketoptions' differently for each vendor's
TCP/TLI that you try to work with, since there is no standard specified
for such things as keep-alive, no-delay, IP options, etc.  The socket
model, on the other hand, provides a de-facto standard for all these
things.

> Certainly a lot of good software is out there using sockets and I don't
> think that the socket library will disappear anytime soon, but for new
> software I really think that STREAMS/TLI are a better approach --
> especially if developing for a System V platform.

There have already been a few changes to TLI since it first appeared,
and I expect there will be more.  The socket interface, on the other
hand, is pretty stable.  I've ported code from BSD systems to Sys-V
using our socket interface without any problems in the networking area.

It's worth considering that most of our ISO product customers require
a socket interface along side TLI as well!  The presence of ISO in BSD4.4
will go a long way to establish the 'standard' for this interface.


Usual disclaoimers apply.

Nick Felisiak				nick@spider.co.uk
Spider Systems Ltd			+44 31 554 9424
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 90 23:44:13 GMT
From:      shelby!msi-s0.msi.umn.edu!cs.umn.edu!uc!shamash!vtcqa@decwrl.dec.com  (Jeff Comstock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q by Bdale Garbee
In article <9008280020.AA17723@ucbvax.Berkeley.EDU> CLEBER%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes:
>
>    Could anyone tell me if KA9Q Internet Software Package source
>code is available. If yes, what's the places that i can get it
>by FTP.
>    Thanks in advance,
>    Cleber Weishheimer.

Although Bdale Garbee is a contributor to the KA9Q package, KA9Q is
actually Dr. Phil Karn.  Bdale is N3EUA.  Anyway,  the latest bits from
Phil (KA9Q) are on thumper.bellcore.com in the directory pub/ka9q/nos .
You will also find a reference manual there.  Thumper is the machine
that Phil puts his latest source and exe files.  In case you don't
know what N3EUA and KA9Q mean, they are amateur radio callsigns. The
primary purpose of the KA9Q package is to allow radio amateurs to
network computers via packet radio.  

Jeff Comstock - NR0D
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 03:00:33 GMT
From:      world!bzs@bloom-beacon.mit.edu  (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Muhammad Jefferson Gets Honky Hate Mail

Let's help Mr. Macri exercise his freedom of speech and widen the
distribution of his gems.

>Xref: world soc.singles:21005 alt.sex:15390
>Path: world!bloom-beacon!snorkelwacker!apple!salt.acc.com!claude
>From: claude@salt.acc.com (Claude Macri)
>Newsgroups: soc.singles,alt.sex
>Subject: Re: Muhammad Jefferson Gets Honky Hate Mail
>Message-ID: <1990Sep1.012542.25352@salt.acc.com>
>Date: 1 Sep 90 01:25:42 GMT
>References: <1990Aug30.200853.24851@salt.acc.com>
>Reply-To: claude@salt.acc.com (Muhammad Jefferson)
>Distribution: na
>Organization: Advanced Computer Communications, Santa Barbara, California
>Lines: 50
>
>
>Yo, I just got some more racist trash, this time from
>some phoney liberal white dude from that uptown candy-assed
>rich school that caters to a bunch of temporary liberals --
>Stanford University.  (After they get their white asses out of 
>school and have to lounge around for an easy living at daddy's 
>doorstep, they stop votin for racial progress, and start votin against 
>social programs that favor the oppressed minorities.)
>
>Here's what the dude in his holy white robe had to say:
>
>>Please stop.  You're just a minor irritant, but the kind of
>>garbage you trade in is fucking up years of progress.  
>
>Hey man, yous a real pain in my ass, too, and what kind of progress
>are you talking about, man?  Affirmative Action??  That shit
>just goes to middle class light-skinned Toms.  Those brothers
>are muthas.  Those are the cats who get the affirmative
>action that the ladies hand out, too.  Meanwhile the brothers 
>who are true and black only get crime, clap, and crack.
>
>>If you're
>>black, then you must be a plant for the klan, trying to brew a
>>conflict out of nothing.  
>
>Really, my pigment is closer to mahogany than black, but
>I just say I'm black because that color is so popular with the
>artsy white ladies.  
>
>>If you're not black, I don't even know what
>>to say.  Read some African-american history.
>
>Sheeit.  Read some history by a bunch of wealthy white dudes?
>The dudes who make history don't write it, and the dudes who
>write it don't make it, they fake it.
>Hey man, none of my friends have enough money to sit around
>typin on a computer for a livin.  We too busy
>survivin in the neighborhoods you liberals drive through with
>the windows rolled up on your way to your suit and tie lounge-
>chair jobs.
>							
>Next thing you liberals will want is Affirmative Action programs
>in basketball.  Pretty soon the Lakers will be forced to
>have some incompeten white dudes again, and even Japanese dudes 
>-- maybe even some ladies.  
>
>Hmmmmm?  Come to think of it, maybe this 
>Affirmative Action shit aint so bad after all.
>
>Muhammad Jefferson
-- 
        -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
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 03:38:58 GMT
From:      unisoft!hoptoad!pacbell!pacbell.com!mips!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucbvax.Berkeley.EDU  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Long lines...
In article <9008311421.AA08486@mcsun.EU.net> Piet.Beertema@MCSUN.EU.NET writes:

   Right, that's what I expected: it's just a technical problem
   (a gateway not announcing a route). In other words: there was
   no need to send this problem to an extremely wide-reaching
   mailing list. Contacting the managers of the first gateway
   (@inria) could have solved the problem...
   Anyway, we'll go after it and inform the people involved.

Well, maybe yes, maybe no.  I think that discussions of this sort are
extremely interesting, and it is useful to draw the attention of the
international community to such events.  This is the first I had heard
of such behavior europe->usa->europe; previously someone saw a
usa->europe->usa hop.

There is an IETF working group (the Topology Engineering Working
Group) which has in the past looked into these things;
intercontinental networks are more and more interesting all the time.

I'm waiting for the first report of usa->europe->japan->australia,
myself.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 08:59:55 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Multi-protocol router scorecard


                              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.

    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

    This report may be freely reproduced, as long as it is not altered
in any sort of way.

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

                          END OF CAVEATS
--------------------------------------------------------------------
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
                              August 1990
                              Version 1.5


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

 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.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       |               |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 8x10Mb       |               |
    - 4Mb Token Ring   | 4x4Mb        | 4x4Mb        |               |
    - 16Mb Token Ring  | Rel 9.0      | Rel 5.40 (c) |               |
    - RS232            | 24x64kb      | 16x64kb      |               |
    - RS449            | 12x64kb      | 16x64kb      |               |
    - V.35             | 12x64kb      | 16x64kb      |               |
    - T1               | 12x1.544Mb   | 8x1.544Mb    |               |
    - CEPT DS1 (2Mb)   | 12x2Mb       | 8x2Mb        |               |
    - FDDI             | 2x100Mb      | Rel 5.5 (d)  |               |
      - DAS (Dual)  (e)| Yes          | Yes          |               |
      - SAS (Single)   | Yes          | No           |               |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          |               |
    - Card types  (g)  | 4E, 1E2S,    | 2E, 1E1S,    |               |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  |               |
                       |              | 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

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

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          |               |
    - ARP  (RFC826)    | Yes          | Yes          |               |
    - RARP (RFC903)    | Yes          | No           |               |
    - BOOTP (RFC951)   | Yes          | No           |               |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          |               |
    - ICMP             | Yes          | Yes          |               |
    - Name-server      | Yes          | No           |               |
    - Accounting       | Yes          | No           |               |
    - MTU              | Yes          | No           |               |
    - Security - IPSO  | Yes          | No           |               |
    - Static routing   | Yes          | Yes          |               |
    - Source routing   | Yes          | No           |               |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          |               |
      - TCP            | Yes          |              |               |
      - UDP            | Yes          |              |               |
      - ICMP           | Yes          |              |               |
      - by protocol (b)| Yes   (a)    | Yes          |               |
    - Routing protocols|              |              |               |
      - RIP (RFC1058)  | Yes          | Yes          |               |
      - EGP (RFC904)   | Yes          | Yes          |               |
      - BGP (RFC1105)  | Yes          | No           |               |
      - Proprietary    | IGRP         | eRIP         |               |
      - Filtering      | Yes          | No           |               |
      - Default routes | 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          |               |
    - Area Router      | Yes          | No           |               |
    - Phase IV+   (a)  | Rel 8.2      | No           |               |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      |              |               |
    - Phase V          | Yes     (b)  | No           |               |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           |               |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          |               |
      - area-max-hops  | Yes          | Yes          |               |
      - max-address    | Yes          | Yes          |               |
      - max-area       | Yes          | Yes          |               |
      - max-cost       | Yes          | Yes          |               |
      - max-hops       | Yes          | Yes          |               |
      - max-visits     | Yes          | Yes          |               |
      - router-priority| Yes          | Yes          |               |
      - hello-timer    | Yes          | Yes          |               |
      - routing-timer  | Yes          | Yes          |               |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           |               |
      - by protocol    | No           | No           |               |
      - by object      | No           | No           |               |
      - routing        | Yes    (d)   | No           |               |
    - MOP              | Bridged      | Bridged      |               |
    - Static routing   | No           | No           |               |
    - Max routing table| 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.

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

 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          |               |
      - UB derivitive  | Yes          |              |               |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          |               |
      - Phase 2        | Rel 8.2      | Rel 5.40     |               |
      - Tokentalk      | Rel 8.2      | Yes          |               |
      - Ethertalk      | Yes          | Yes          |               |
      - Localtalk      | No           |              |               |
      - RTMP           | Yes          | Rel 5.40     |               |
      - AARP           | Yes          | Rel 5.40     |               |
      - NBP            | Yes          | Rel 5.40     |               |
      - EP             | Yes          | Rel 5.40     |               |
      - ATP            | Yes          |              |               |
      - ZIP            | Yes          | Rel 5.40     |               |
      - DDP            | Yes          | Yes          |               |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           |               |
      - ISO 9542 ES-IS | Yes          | No           |               |
    - Apollo Domain    | Yes          | No           |               |
    - Novell IPX       | Yes  (a)     | Yes          |               |
    - X.25             | Yes          | Yes          |               |
      - bridging       | Rel 9.0      | Yes          |               |
      - routing        | Yes          | Yes          |               |
      - switching      | Yes          | Yes ???      |               |
    - 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          |               |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3        |               |
      - DEC EMA  (a)   | No           | Yes     (a)  |               |
      - External       |              |              |               |
        software (b)   | No      (c)  | 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)     |               |
    - Telnet           | Yes     (h)  | Yes  (i)     |               |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      |               |
    - NICE        (j)  | No           | No           |               |
    - Decnet connect   | No           | No           |               |
    - Passwords (k)    | Yes          | Yes          |               |
    - Netview support  |              |              |               |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          |               |

 Notes:
 a. DEC EMA refers to the product's intent to support the DEC
    Enterprise Management Architecture in the future.  No release
    version has been mentioned yet for this feature.
 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.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          |               |
    - LAN              | Yes          | Yes          |               |
    - Link             | Yes          | Yes          |               |
    - Decnet           | Yes          | Yes          |               |
    - Tcp/Ip           | Yes          | Yes          |               |
    - Event log        | Yes          | Yes          |               |
    - Environmentals   | Yes          | 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)    |               |
    - standby line  (a)| No           | No           |               |
    - fault tolerant(b)| No           | No           |               |
    - field tolerant(c)| No           | No           |               |
    - broadcast storms | Yes          | No           |               |

 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.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 11:01:18 GMT
From:      sdd.hp.com!samsung!munnari.oz.au!metro!pta!yarra!chris@ucsd.edu  (Chris Jankowski)
To:        tcp-ip@nic.ddn.mil
Subject:   "The Open Book" by Rose - your opinions sought
From RFC1175:
   Rose, Marshall T., The Open Book: A Practical Perspective on OSI, 651
   pgs., Prentice Hall, Englewood Cliffs, NJ, 1989.

      This is a comprehensive book about Open Systems Interconnection
      (OSI).  In particular, this book focuses on the pragmatic aspects
      of OSI: what OSI is, how OSI is implemented, and how OSI is
      integrated with existing networks.  In order to provide this
      pragmatic look at OSI the book makes consistent comparisons and
      analogies of the OSI pieces with the TCP/IP suite of networking
      protocols.

What do you think about the book? Is it worth buying?
What I am after is a book which would be an equivalent of the Comer's
book on Internet but obout OSI.
How would you compare it with the Comer's book on Internet?
Is it similar in style, depth, objective and clarity?

I'll summarise if enough responses received.
Thank you.

      -m-------   Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au}
    ---mmm-----   Pyramid Technology Corporation Pty. Ltd.  fax  +61 3 820 0536
  -----mmmmm---   11th Floor, 14 Queens Road                tel. +61 3 820 0711
-------mmmmmmm-   Melbourne, Victoria, 3004       AUSTRALIA       (03) 820 0711

micron n. - a unit of length of one milionth of a meter, 
            worth $2,000,000,000 since the fault in the Hubble space telescope 
            mirror has been identified.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Sep 1990 15:49-EDT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: OS network interfaces (was: sockets vs. streams)
The multiserver Mach 3.0 [and other systems such as Plan9, for
instance] place indeed much more semantics in filesystem names.

For networking, we have a Network Protocol Server (NP) that contains
the protocol code and talks to the ether device (or whatever) at the
packet level.  It's NP's business what names mean.  It's independent
of the OS environment (streams, sockets whatever) what is the interface 
that NP exports to other servers and to the U*x emulation library.
[Right now it's just the socket BSD interface, cuz we did it 2 years ago
 quickly just to see if the thing was plausible]

What I am interested in for the second round implementation is what
would be the most flexible interface for NP.  The goal is to come up
with something that can satisfy the needs of multiple OS environments
[BSD, sysV, VMS, you name it].  What I have in mind right now is to just
be concrete and go with something along the lines of BSD's protocol
layer (underneath sockets).  This assumes that streams can be made
to work on top of it [which is, I gather, exactly what most SysV TCP
implementations are].  We (CMU) are not interested in streams or sysV
directly, but a number of other people certainly will.
Comments and suggestions are therefore extremely welcome.

As for extra functionality.. you certainly get to "see" what's going on
under /net [default mount point for NP].  If I go by protocols, there
are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then
/net/ip/tcp /net/ip/udp /net/ip/imp and so on. 
What's under each protocol is fuzzy, right now, but it will let you see
all established connections.

As for 'manipulating' things there.. Keith Sklower and others have already
pointed out that 'creat' might be messy, but opening an existing
file, reading and writing to it (permissions aside) is doable, just
like named pipes. [In other words, new names are only created by NP
as part of the connection setup]

I would pose that /net/<some host name>/<blah> loses because a given
host can only be reached via some other qualifier besides its 'name':
both ether address(es!) and IP numbers are ok, for instance, if you use
the right mean.  Then again one could overload symlinks to get a
different view into the name space.


In our system each and every system or user server can export a name space: 
I can think of the existing named and inetd as simple and useful cases
of U*x network servers that can be extended this way.  
And BTW, all the various databases that go with a server can be
administrated in a simpler way by collecting all permanent and
temporary information within the server's subtree.

Sooo, you have a chance to voice for a bigger-and-better network
system .... shoot!

sandro-

Historical note: We already have a remote filesystem (RFS, it was born
long before ma Bell's one) that works along these lines:
/../somehost/usr/ is the /usr directory in host's <somehost>
namespace. This is where our own ideas originated.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 13:32:52 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams


this reminds me of a great idea from newcastle:
RESCUE (REduced System Call Unix E by gum, i canna recall what the E
was for), an anlaogy with RISC hardware.

i think they got down to about 4 system calls,
you lose all the process ones from the extreme 8th edition idea of
/proc, so processes are created, run and debug with open/read/write
and destroyed with close

remote execution is simple -you use newcastle conenction, and open
/machinename/proc

of course addresses just arent used - just like you dont use inodes
instead of filenames...so all this overloading of things in the name
is unnecassary. all info is in the first component of the path - i.e.
proc is local processes
machinename/proc is remote processes (open /mil.ddn-nic/proc/telnetd,
is a telnet connection to the nic) and so forth
and the talk facility is just a curses version of write to
/machine/dev/tty?.

multicast getsa a bit tricky, i guess you do open("/mil.*", ...)
to give the 3 minute warning:-)

of course, some good things can be taken too far, cant they?

jon.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Sun, 02 Sep 90 10:59:55 O
From:      Hank Nussbacher <HANK%BARILVM.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:   Multi-protocol router scorecard

                              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.

    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

    This report may be freely reproduced, as long as it is not altered
in any sort of way.

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

                          END OF CAVEATS
--------------------------------------------------------------------
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
                              August 1990
                              Version 1.5


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

 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.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       |               |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 8x10Mb       |               |
    - 4Mb Token Ring   | 4x4Mb        | 4x4Mb        |               |
    - 16Mb Token Ring  | Rel 9.0      | Rel 5.40 (c) |               |
    - RS232            | 24x64kb      | 16x64kb      |               |
    - RS449            | 12x64kb      | 16x64kb      |               |
    - V.35             | 12x64kb      | 16x64kb      |               |
    - T1               | 12x1.544Mb   | 8x1.544Mb    |               |
    - CEPT DS1 (2Mb)   | 12x2Mb       | 8x2Mb        |               |
    - FDDI             | 2x100Mb      | Rel 5.5 (d)  |               |
      - DAS (Dual)  (e)| Yes          | Yes          |               |
      - SAS (Single)   | Yes          | No           |               |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          |               |
    - Card types  (g)  | 4E, 1E2S,    | 2E, 1E1S,    |               |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  |               |
                       |              | 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

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

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          |               |
    - ARP  (RFC826)    | Yes          | Yes          |               |
    - RARP (RFC903)    | Yes          | No           |               |
    - BOOTP (RFC951)   | Yes          | No           |               |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          |               |
    - ICMP             | Yes          | Yes          |               |
    - Name-server      | Yes          | No           |               |
    - Accounting       | Yes          | No           |               |
    - MTU              | Yes          | No           |               |
    - Security - IPSO  | Yes          | No           |               |
    - Static routing   | Yes          | Yes          |               |
    - Source routing   | Yes          | No           |               |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          |               |
      - TCP            | Yes          |              |               |
      - UDP            | Yes          |              |               |
      - ICMP           | Yes          |              |               |
      - by protocol (b)| Yes   (a)    | Yes          |               |
    - Routing protocols|              |              |               |
      - RIP (RFC1058)  | Yes          | Yes          |               |
      - EGP (RFC904)   | Yes          | Yes          |               |
      - BGP (RFC1105)  | Yes          | No           |               |
      - Proprietary    | IGRP         | eRIP         |               |
      - Filtering      | Yes          | No           |               |
      - Default routes | 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          |               |
    - Area Router      | Yes          | No           |               |
    - Phase IV+   (a)  | Rel 8.2      | No           |               |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      |              |               |
    - Phase V          | Yes     (b)  | No           |               |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           |               |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          |               |
      - area-max-hops  | Yes          | Yes          |               |
      - max-address    | Yes          | Yes          |               |
      - max-area       | Yes          | Yes          |               |
      - max-cost       | Yes          | Yes          |               |
      - max-hops       | Yes          | Yes          |               |
      - max-visits     | Yes          | Yes          |               |
      - router-priority| Yes          | Yes          |               |
      - hello-timer    | Yes          | Yes          |               |
      - routing-timer  | Yes          | Yes          |               |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           |               |
      - by protocol    | No           | No           |               |
      - by object      | No           | No           |               |
      - routing        | Yes    (d)   | No           |               |
    - MOP              | Bridged      | Bridged      |               |
    - Static routing   | No           | No           |               |
    - Max routing table| 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.

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

 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          |               |
      - UB derivitive  | Yes          |              |               |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          |               |
      - Phase 2        | Rel 8.2      | Rel 5.40     |               |
      - Tokentalk      | Rel 8.2      | Yes          |               |
      - Ethertalk      | Yes          | Yes          |               |
      - Localtalk      | No           |              |               |
      - RTMP           | Yes          | Rel 5.40     |               |
      - AARP           | Yes          | Rel 5.40     |               |
      - NBP            | Yes          | Rel 5.40     |               |
      - EP             | Yes          | Rel 5.40     |               |
      - ATP            | Yes          |              |               |
      - ZIP            | Yes          | Rel 5.40     |               |
      - DDP            | Yes          | Yes          |               |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           |               |
      - ISO 9542 ES-IS | Yes          | No           |               |
    - Apollo Domain    | Yes          | No           |               |
    - Novell IPX       | Yes  (a)     | Yes          |               |
    - X.25             | Yes          | Yes          |               |
      - bridging       | Rel 9.0      | Yes          |               |
      - routing        | Yes          | Yes          |               |
      - switching      | Yes          | Yes ???      |               |
    - 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          |               |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3        |               |
      - DEC EMA  (a)   | No           | Yes     (a)  |               |
      - External       |              |              |               |
        software (b)   | No      (c)  | 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)     |               |
    - Telnet           | Yes     (h)  | Yes  (i)     |               |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      |               |
    - NICE        (j)  | No           | No           |               |
    - Decnet connect   | No           | No           |               |
    - Passwords (k)    | Yes          | Yes          |               |
    - Netview support  |              |              |               |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          |               |

 Notes:
 a. DEC EMA refers to the product's intent to support the DEC
    Enterprise Management Architecture in the future.  No release
    version has been mentioned yet for this feature.
 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.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          |               |
    - LAN              | Yes          | Yes          |               |
    - Link             | Yes          | Yes          |               |
    - Decnet           | Yes          | Yes          |               |
    - Tcp/Ip           | Yes          | Yes          |               |
    - Event log        | Yes          | Yes          |               |
    - Environmentals   | Yes          | 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)    |               |
    - standby line  (a)| No           | No           |               |
    - fault tolerant(b)| No           | No           |               |
    - field tolerant(c)| No           | No           |               |
    - broadcast storms | Yes          | No           |               |

 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.
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Sep 90 21:07:18 MDT
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        J.Crowcroft@cs.ucl.ac.uk
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re(2): TLI, NLI, DLI - Request for information
In reply to your message of Fri, 31 Aug 90 09:34:13 +0100
-------

> do any of TLI, NLI or DLI contain something with more functionality
> than sockets - like a standard management interface, or a standard
> packet filter or traceer interface - and i dont mean ioctl and nit
> like vaguaries

TLI has been discussed to death.  It is similar to sockets and has adherents
and detractors like sockets do.  4.4BSD sockets pretty much fix the
deficiencies that TLI tried to address.

NLI and DLI don't exist with those names.  There is NPI and DLPI.  They are
interfaces between STREAMS modules and don't really have any relationship to
sockets or anything like that.  They could have programming interfaces
defined for them but there currently aren't any.  Of course, since they are
just STREAMS messages, a user level program can access the interfaces.

To summarize what NPI (Network Provider Interface) and DLPI (Data Link
Provider Interface) are:

NPI:    Provides a common set of primitives that are based on the OSI
	service primitives for network services.  The intent is to have a
	common set of primitives to allow a transport provider to be able to
	communicate with a network service provider.

	While not really necessary, it does provide a way to cleanly
	separate the network provider from the other parts of the stack and
	to allow multiple providers.  One possibility is to have CONS and
	CLNS network providers for OSI under a single stack.

	In reality, it is just a nice way to do something similar to RAW
	sockets but then be able to link the network STREAM under a provider
	module and construct a new stack without having to modify any part
	of the network provider driver.

	NPI provides for connection primitives as well as connectionless.

DLPI:
	This is the STREAMS interface to data link device drivers.  While
	similar to NIT and other mechanisms for gaining access to the device
	driver level, it really is just the mechanism for a network service
	provider to communicate with the device driver.  A STREAM can be
	opened and bound to some service access point (Ethertype, 802.2
	LSAP, whatever) and then be linked under a network provider module.
	It is possible to use it a user level to implement things like RARP
	or other application that uses the data link level directly.
	The V.4 DLPI also includes primitives for connection oriented
	protocols such as 802.2 Class 2 Type 2 LLC.

> if not, i suggest its just more noiseware to make unix less useful,
> designed by manufacturers running scared from real open systems and
> shareware...

TLI may have been that.  It does seem to smack of NIH.  NPI and DLPI
developed to meet a different need - that of getting vendors to write
drivers that would work with other vendors protocol stacks.  Since STREAMS
isn't a protocol or driver implementation itself and is only the framework
to develop protocols and drivers, there needed to be a consistant interface
between the various types of modules.  NPI and DLPI are intended to do that.
The BSD way doesn't fit the STREAMS model very well.  Besides, DLPI at
least, is far more flexible.  The drivers don't have to be modified to allow
a third party vendor's protocol stack take advantage of them.

Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.com
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Sun, 02 Sep 90 14:32:52 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        Barry Shein <bzs@world.std.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams

this reminds me of a great idea from newcastle:
RESCUE (REduced System Call Unix E by gum, i canna recall what the E
was for), an anlaogy with RISC hardware.

i think they got down to about 4 system calls,
you lose all the process ones from the extreme 8th edition idea of
/proc, so processes are created, run and debug with open/read/write
and destroyed with close

remote execution is simple -you use newcastle conenction, and open
/machinename/proc

of course addresses just arent used - just like you dont use inodes
instead of filenames...so all this overloading of things in the name
is unnecassary. all info is in the first component of the path - i.e.
proc is local processes
machinename/proc is remote processes (open /mil.ddn-nic/proc/telnetd,
is a telnet connection to the nic) and so forth
and the talk facility is just a curses version of write to
/machine/dev/tty?.

multicast getsa a bit tricky, i guess you do open("/mil.*", ...)
to give the 3 minute warning:-)

of course, some good things can be taken too far, cant they?

jon.
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 17:59:27 GMT
From:      snorkelwacker!usc!samsung!munnari.oz.au!cs.mu.OZ.AU!kre@bloom-beacon.mit.edu  (Robert Elz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In article <6964@milton.u.washington.edu>,
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> 
> If "network I/O looks like local device I/O" under Unix then when the
> h*ll do I have to worry about all the socket or streams crap?

There was a time when building network names into the filesystem
was seen as a sensible thing to do - nice and regular, existing
programs would be able to use them, ...

Unfortunately, while its a nice idea, it really won't work in general,
and if it doesn't work in general, its not worth the effort.

First, its perfectly reasonable for an application to check whether
a file exists before attempting to open it, that way more meaningful
error messages can be given - this is kind of hard to do with a
network connection.

Second, while your example gave numbers (/tcp/128....) that would
be useless in practice - the interface would need to use names. 
Since "open" is a kernel routine (if we're not assuming that we're
talking about completely different issues) that means that either
name->number mapping needs to be done in the kernel, or the kernel
needs to have some mechanism to get some kind of user process to do
the mapping for it.

Now assuming that this can be solved, the application needs to
be able to select parameters for the mapping process - How many
attempts should be made to find the translation?  With what delay
between attempts?  Should default domains be appended?  Which?
Should some user defined nic-name to real name be applied?  From
where?  What should be done with "soft" nameserver errors?  Which
server should we be using?

Next, lets assume that that we are able to get the number, somehow,
and the port number (from its name) as well - next we have to
open the connection.  At first sight that's easy - but how do
we specify the MSS, receive and transmit windows, IP header TTL,
TOS, ...

You suggested that all of this could be built into the filename
as optional segments (by now we're getting pretty far from the
traditional notion of a filename, but never mind).  Certainly,
they could - but doing this makes the user (the provider of
the filename) responsible for specifying all this crud - what
does the user care about MSS's?   So, instead the application has to
massage the file name to append all of the various option settings
that it might need (sure - most applications will take kernel
defaults, but the mechanism has to be there - and all of this
has to be done before the connection is opened).

Now, the easy part is solved, TCP just isn't that complex, but
lets extend generality a little and open an OSI MHS (X.400)
connection as well.   In the connection setup here we need
various addresses, XSAP's (for various X), packet sizes,
window sizes, numerous option selections at various levels,
MTA names, passwords, ...   By the time its all specified your
pathname is going to be totally absurd.

This is why the socket() call provides an anonymous file descriptor
(and the streams model does much the same thing).  Having that
file descriptor all the necessary options can be set before the
network is asked to establish the connection - simple applications
may set none at all and rely on defaults, sophisticated applications
might set many.  But its one mechanism that works well for everyone.

A better question might not be, to regularise things, why isn't
all I/O done by first requesting a socket, then connecting to
the object, ie: open(path, mode) might be modelled (very roughly) as

	s = socket(AF_FS, ...);
	setsockopt(FS_MODE, mode);
	connect(s, path, ...);

(with bind() used for creat(0 of course).

Henry Spenser asked why no-one has ever created a standard library
routine to open a connection.  That's something I have wondered
about myself, it seems like a fairly obvious thing to do.   But then
I've never done it either ... I guess its just that opening a net
connection (explicitly) just isn't something that is done all that
often, and isn't really that hard when you need to do it, so neither
I nor anyone else I'm aware of has bothered to define a good simple
interface useful for most applications (this is a case where universal
applicability wouldn't be needed - the underlying mechanism is still
there when required, just as stdio's fopen() doesn't do everything
that open() is capable of).

kre
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 18:45:24 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
On 31 Aug 90 19:48:37 GMT, sklower@ernie.Berkeley.EDU (Keith Sklower) said:

sklower> In article <1990Aug28.162400.17811@zoo.toronto.edu>
sklower> henry@zoo.toronto.edu (Henry Spencer) writes:

spencer> The way to do i/o on Dennis's streams was with "read" and "write".
spencer> Network i/o, in general, looked *exactly* like local device i/o.

Note that with the most recent developments of UNIX (FSS) read() and
write() no longer mean much, except 'move data from/to the kernel'; they
have become just a way to add new system calls, using a file like style
of interface. The semantics of write() and read() have become very very
loose. What does read/write mean on /dev/proc? Something highly non
obvious.

spencer> This is the way it should be, unlike what both Berkeley and
spencer> AT&T have done (both have reluctantly conceded that most people
spencer> want to use "read" and "write" and have made that work, but
spencer> their hearts were clearly elsewhere).

And for good reason! read() and write() on file descriptors is not the
most amusing interface. It is much more convenient to have IPC style
access to files, e.g. Accent with its ports, than viceversa, unless we
are so wedded to UNIX that we cannot change (probably true, vide failure
of Accent to get accepted, and then success of Mach, which is a Unix
like imitation of it).

Frankly, the "everything is a file" way of achieving connectability is
not the best abstraction, because you want to connect to active
services, not just to passive storage. Straining a file model to include
"active" files is a bit inelegant.

"everything is a socket" or equivalently "everything is a process" (even
files!) are much better; "everything is a file system", the technology
used in recent research Unixes or PLAN/9 is a way to get as abstraction
a more active thing than a file, works better than "everything is a
file", yes, but requires a large suspension of disbelief, and assumes
that we really want the Unix directory tree model for all name service,
which may not be a terribly good choice either.

	e.g. as in having an internet filesystem type, and doing
	something like

		fd = open("/dev/internet/lcs.mit.edu/echo.udp",...);
	/*or*/	fd = open("/dev/internet/edu/mit/lcs/119.tcp",...);

sklower> I find this inaccurate, partronizing and tiresome.  I have
sklower> worked around Berkeley since 1978 and although was not a member
sklower> of the actual unix group in 1982 while TCP was being
sklower> incorporated, attended their meetings and seminars.

Ahh. Incidentally, I would like to observe that I have *never* seen an
implementation of BSD sockets and TCP. The only ones that circulate are
extremely limited and rigid subsets. Since you have been around UCB for
so long, can you tell us why there is no (full) implementation of BSD
sockets? E.G. where are user domain type filedescriptors?

About compatibility between IPC and normal file I/O:

sklower> I assure you that it was the design goal then, that only
sklower> ``sophisticated process'' would need a more elaborate mechanism
sklower> to establish a network connection, but that once having
sklower> established one, that it should be usable as a completely
sklower> ordinary file descriptor by ``naive'' processes like the date
sklower> command, using read and write, and that the file descriptor
sklower> should be inherited by the normal unix means (fork & exec).

Uhm. Precisely. And 'wrappers', one of the features of BSD sockets, were
designed to make such compatibility absolute. Why nobody has ever
implemented them?

sklower> It sounds to me like Henry is attempting to rewrite history
sklower> (for his own possibly political motives).

I actually think that he may innocent, but he *is* attempting to rewrite
history, in a way different from what you say; on BSD it actually
happens that read/write on sockets is the same as on files, but because
they changed the specification of read/write on files.

The only difference with send/rcv is that sendmsg/rcvmsg allow
out-of-band, and passing file descriptors, which make no sense with
read/write to a file, but the distance from traditional read/write is
larget than that.
--
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
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 19:49:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: OS network interfaces (was: sockets vs. streams)

The multiserver Mach 3.0 [and other systems such as Plan9, for
instance] place indeed much more semantics in filesystem names.

For networking, we have a Network Protocol Server (NP) that contains
the protocol code and talks to the ether device (or whatever) at the
packet level.  It's NP's business what names mean.  It's independent
of the OS environment (streams, sockets whatever) what is the interface 
that NP exports to other servers and to the U*x emulation library.
[Right now it's just the socket BSD interface, cuz we did it 2 years ago
 quickly just to see if the thing was plausible]

What I am interested in for the second round implementation is what
would be the most flexible interface for NP.  The goal is to come up
with something that can satisfy the needs of multiple OS environments
[BSD, sysV, VMS, you name it].  What I have in mind right now is to just
be concrete and go with something along the lines of BSD's protocol
layer (underneath sockets).  This assumes that streams can be made
to work on top of it [which is, I gather, exactly what most SysV TCP
implementations are].  We (CMU) are not interested in streams or sysV
directly, but a number of other people certainly will.
Comments and suggestions are therefore extremely welcome.

As for extra functionality.. you certainly get to "see" what's going on
under /net [default mount point for NP].  If I go by protocols, there
are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then
/net/ip/tcp /net/ip/udp /net/ip/imp and so on. 
What's under each protocol is fuzzy, right now, but it will let you see
all established connections.

As for 'manipulating' things there.. Keith Sklower and others have already
pointed out that 'creat' might be messy, but opening an existing
file, reading and writing to it (permissions aside) is doable, just
like named pipes. [In other words, new names are only created by NP
as part of the connection setup]

I would pose that /net/<some host name>/<blah> loses because a given
host can only be reached via some other qualifier besides its 'name':
both ether address(es!) and IP numbers are ok, for instance, if you use
the right mean.  Then again one could overload symlinks to get a
different view into the name space.


In our system each and every system or user server can export a name space: 
I can think of the existing named and inetd as simple and useful cases
of U*x network servers that can be extended this way.  
And BTW, all the various databases that go with a server can be
administrated in a simpler way by collecting all permanent and
temporary information within the server's subtree.

Sooo, you have a chance to voice for a bigger-and-better network
system .... shoot!

sandro-

Historical note: We already have a remote filesystem (RFS, it was born
long before ma Bell's one) that works along these lines:
/../somehost/usr/ is the /usr directory in host's <somehost>
namespace. This is where our own ideas originated.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 90 21:39:55 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
(Not particularly TCP/IP oriented at this point....)

 >>> ps. Is there anyway to get a list of all the modules pushed onto
 >>> a stream.  I_LOOK only lists the top most module.
 >>
 >>Not in V.3.
 >
 >Actually it is not quite that bad.  You should have an idea of all the
 >possible modules that COULD be on a given stream (not many).  It is then 
 >trivial to write a little program which uses I_FIND to see if the module
 >is on the stream.

That'll tell you *which* modules are on the stream, but it won't tell
you where they are on the stream.  If you want that, you need something
such as S5R4's I_LIST.
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 01:55:54 GMT
From:      munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net  (Michael Paddon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP & Routing
In article <168@ubeaut.oz.au>, mwp@ubeaut.oz.au (Michael Paddon) writes:
> On client:
> 	route add default 192.33.20.201 1
> 
> On server:
> 	route add default 192.33.20.1 1

I forgot to handle packets being routed from the outside world
towards the client (mostly because I tend to set up most nodes
to be invisible to the outside world for security reasons).

Anyway, credit where due... Here is the additional information as
provided to me:

= Return-Path: mtiame!root%afsg.apple.com@munnari.oz
= Received: from afsg.apple.com by munnari.oz.au with SMTP (5.61+IDA+MU)
=	id AA03802; Fri, 31 Aug 1990 00:13:32 +1000
=	(from root@afsg.apple.com for mwp@ubeaut.oz)
= Date: Thu, 30 Aug 90 07:09:38 PDT
= From: root@afsg.apple.com (System Owner)
= Message-Id: <9008301409.AA18488@afsg.apple.com>
= To: mwp@ubeaut.oz.au
= Subject: Re: SLIP & Routing
= Newsgroups: comp.protocols.tcp-ip
= In-Reply-To: <168@ubeaut.oz.au>
= References: <425@afsg.apple.com>
= Organization: Apple Federal Systems Group
= 
= In order for other hosts/gateways to see the client machine
= on a Class C network you must set up a proxy arp for the
= client at the ethernet address of the server machine's
= ethernet interface.  Otherwise remote hosts/gateways won't
= know how to route packets destined to the SLIP client.

> [This question probably shouldn't be in this newsgroup]

I had about four people mail me and say "where should it be then?".
My newsgroups file says:
	comp.protocols.tcp-ip		TCP and IP protocols.
Thus, my off the cuff comment questioning whether the setup of SLIP
routing really fits into a discussion of protocols. Personally I don't
care where people post anyway.

					Michael

-------------------------------------------------------------------
|                     |     EasyNet:  meo78b::paddon              |
|                     |     Internet: paddon@meo78b.enet.dec.com  |
|  Michael Paddon     |     ACSnet:   mwp@ubeaut.oz.au            |
|                     |     ACSnet:   mwp@munnari.oz.au           |
|                     |     Voice:    +61 3 895 9392              |
-------------------------------------------------------------------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 02:26:19 GMT
From:      sdd.hp.com!mips!twg.com!david@hplabs.hpl.hp.com  (David S. Herron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In article <13526@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>
>	I don't want to get into a religious war, but I don't see where a
>filesystem analogy to sockets holds up to any but the most shallow
>interpretation. To use your naming, what does it mean if I type:
>
>	cd /tcp//128.210.10.8
>?
>	What if I do an "ls /tcp"? Be careful-- all of the assigned addresses
>aren't available in any one place. Not if NIC.DDN.MIL-- they only have the
>network parts...
>	How do you specify a local address binding when you care? How do you
>specify that you don't care? What does a "seek" mean on a socket? How do you
>send urgent data in TCP?
>	In a UNIX implementation, by making the "tcp" a directory, you've
>introduced a type of pseudo-device like no other that exists and without
>it you lose some of the information you want in the name.
>
>	I won't argue that sockets are the "right" way, and there are certainly
>rough edges, but the filesystem analagy *is* artificial. The things you do to
>files (ie, storage devices) aren't the things you do with sockets (ie,
>communication media). To a degree, you can make the same argument with
>terminals, but it doesn't seem to be pushing it quite as much there, to me.

My understanding is that some of the filesystem researchers are
working towards file systems which one would describe better as
"object hierarchies".  In this type of system the semantics of
objects would vary depending on where you are in the hierarchy.
(Part of this could be implemented right now via the "file system
switch" stuff in newer Unices.)

For the /dev/tcp file system the semantics might be that the next
level contains objects whose names are the IP addresses of hosts
to which we are currently communicating.  Part of the semantics of
this level is that it contains (like a directory) objects whose
names are the port number of the relavent end of the connection.

Objects under /dev/tcp would come and go as connections are created
and destroyed.

There would be a system call (ioctl()?) for getting/setting various
parameters of each end of the connection.

It's not too terribly different than stuff currently available
within the range of systems that are called Unix.  My understanding
of the /proc (of v8-v10 and SysVr4 fame) directory is that it acts
similarly -- that objects within it appear and disappear as processes
come and go.  And that ioctl() can get & set various options on
the process.  And that opening the /proc/nnn `file' (object) lets
you read and write the running process.

It would probably be a "good thing" for the /dev/tcp objects to
have appear under other names than just the IP addresses.  After
all, people wanna use names to connect to places... so "/dev/tcp/s.ms.uky.edu"
would be the same as "/dev/tcp/128.163.128.19", might be implemented as
a link(?).  There would have to be some code here to do nameserver
lookups and set these links up.  An internally multitasking OS might
be a big help here.

Same sort of deal for the next layer down.  /dev/tcp/s.ms.uky.edu/smtp
for instance.

Of course user level applications shouldn't require users to type such
nonsense, but should look pretty much like they do now but make translations.

You could have a routine that returns a free port.  It'd be a simple
use of opendir() and readdir() to find the first free one.

Oh yeah, opendir() and readdir() type stuff might have to be played
with a little bit.  But probably not since they get implemented
in the kernel nowadays.

Just tossing out a few ideas that I've had in my mind for a long time....
Do with them what you will. :-)  I don't think there's anything
unimplementable, and in fact it would likely work pretty darn well.
I would certainly like to see a lot more use made of that file system
switch facility.  Sun OS v4.1 was a good step in that direction in
that it's supporting some pretty funky options/variations to file systems.


-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Sep 90 11:27:29 PDT
From:      braden@venera.isi.edu
To:        tcp-ip@nic.ddn.mil, van-bc!ubc-cs!alberta!macg@ucbvax.berkeley.edu
Subject:   Re:  4.0 NIT Bug
Mike,

  Fixed object modules for Sun OS 4.0.x are available for anonymous FTP
  from host venera.isi.edu with pathnames pub/nit_if.o or
  pub/nit_if.o.sparc.
  
  There is a mailing list for people interested in NNStat (or, in
  principle, any monitoring tools): bytecounters@isi.edu.
  Send a msg to bytecounters-request to be added to the list.
  
  Bob Braden
   
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 07:08:24 GMT
From:      bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com  (Benny Tong)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp source port number assignment in new tcp connection

    Does anyone know how to assign TCP source port number when opening a
    new TCP connection? Is there a RFC to suggest how to do this?

    Will the following scheme work ? 

    Initialises the last assigned port number to the smallest port number to
    use (ex. 1000?). For each new tcp connection to be opened, increments
    the last assigned port number (and wraps around at the largest port number
    plus one). Check if this tcp port number is in use already. If it is,
    increments this port number until an unused port number is found. Opens
    a tcp connection with this as the tcp source port number.
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Sep 90 14:08:59 -0400
From:      bzs@world.std.com (Barry Shein)
To:        Alessandro.Forin@SPICE.CS.CMU.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   OS network interfaces (was: sockets vs. streams)

The issue of name server resolution and similar problems was raised by
Robert Elz. This is a real problem and well worth grappling with.

What has been done in various special-case forms but has never really
been standardized into unix kernels is a clean interface which allows
the kernel to call back out to a user process for information.

For example, one simplistic approach would be a daemon which registers
a service with the kernel (similar to bind() in philosophy) and then
waits for requests.

This could be cobbled up as a socket thing, call it the UNIX_KERNEL
protocol. That would, for example, allow the current name service to
do this via just adding another fd to its select() call:

daemon:

	struct sockaddr_kern sockk;

	sockk.port = NAME_SERVICE;

	skern = socket(KERNEL,SOCK_DGRAM,0);

	bind(skern,&sockk,sizeof(sockk));

	...etc...(select/accept loop)

PDP-10 types will of course recognize this as a generalization of the
ACJ idea. And it could very well be used for authorization etc.,
anything where it would be nice to manage various data at user level
and let the kernel just query these user processes for things like
"can this uid do remote TCP connects?", "what does this string
translate to?", "user foo's job just ran out of memory, please log to
a file".

Current facilities, such as kernel error logging, could be completely
replaced by this sort of facility.

I'm sure people will now tell me that XYZ is just this, I'm
interested, but I suspect what we'll find is a lot of little special
facilities that never quite got generalized, or have some other
strange limitations.

Of course, generalizing this so the query relays to another server
over the net is almost trivial (the user level daemon can do that, and
in the case of a name service almost certainly would.)

        -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
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 16:14:39 GMT
From:      mcsun!ukc!icdoc!tgould!lmjm@uunet.uu.net  (Lee McLoughlin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...

Lee's time to  flame ->>

In article <6190@vanuata.cs.glasgow.ac.uk> tommyk@cs.glasgow.ac.uk (Tommy Kelly) writes:

   From: tommyk@cs.glasgow.ac.uk (Tommy Kelly)
   Newsgroups: eunet.followup,comp.protocols.tcp-ip
   Date: 31 Aug 90 07:26:56 GMT
   Organization: Comp Sci, Glasgow Univ, Scotland

   Does this imply that you CAN actually telnet out to U.S. sites?

   Is the UK the only place which is isolated from the rest of the world?

Yes the UK is really the only Europaen country where not only do we
lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip
services to the internet.  Oh sure if you have ooodles of money and
can afford your own satelite link or pss connection to a friendly site
somewhere on the internet (some of the bigger companies with UK
branches do this) or if you are one of the priviledged UK universities
who have a link such as ULCC, UCL or UKC then fine, you're laughing.
The rest of us?  Forget it.  There is noone out there offering a
service that most UKNET users can afford.

Even something as simple as running tcp/ip over JANET so we can have
some degree of sane networking here in the UK seems to be out.  The
JANET powers that be do not want anything as useful as tcp/ip sullying
there network!  God forbid you should be able to use the networking
software that comes on your machine!!  Far better to have to shell out
for coloured book software! Don't give me any of that rubbish about
tcp/ip not being available on all the machines on Janet, any machine
that sells in the US has tcp/ip available for it.  Normally from
several competing vendors.  Over here you are lucky if the coloured
books are available at all for any new box.

The thing that really amazes me about all this is that there is not a
bigger fuss about it all!  I regularly pull back new releases of
software/documentation from US/Europaen academics from internet, don't
academics here in the UK want to make there work available in the same
way?  Many comerical companies are on the US Internet and release
patches, demo release and the like by making them available for
anonymous ftp.  Don't companies over here want to do the same thing?

If I thought it would succeed I'd say we should all lobby for either
UKNET or Janet to make internet available to us, but a lot of us tried
to get that stupid Janet decision about email addresses being the
wrong way around reversed and failed.  If I was a gambling man I'd bet
any attempt to get us tcp/ip from the Janet authorities would be met
by innane statements about ISO.

My parting question is directed the those that run UKNET:  when is
tcp/ip going to be available to UKNET members in the same way as it is
to Eunet members?
--
--
Lee McLoughlin		phone: 071 589 5111 X 5037  	fax: 071 581 8024
Department of Computing, Imperial College, 180 Queens Gate, London SW7 2BZ, UK
Janet: lmjm@uk.ac.ic.doc	Uucp:  lmjm@icdoc.UUCP (or ..!ukc!icdoc!lmjm)
DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nsfnet-relay.ac.uk)
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 17:43:00 GMT
From:      CHAIBP@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   interfacing with Ethernet cards




I believe some people here may have experience developing
device drivers for the following Ethernet adapter
cards:
1. Acer 5220
2. AST-Ethernet Adapter
3. DTK Ethernet LAN card
4. Earthnet-Ie
5. G/Ethernet AT
6. IMC Networks PCnic
7. Localnet D-Link
8. Novell NNE1000
9. 3C501 EtherLink card
10. 3C503 EtherLink II
11. 3C505 EtherLink Plus
12. Tiara LanCard E
13. Univation LifeLink

If you do, please send me you mailing address as I
would like to consult you on issues of interfacing with
these cards.

BP

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 20:15:46 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...


In article <1990Sep04.045954.25664@comp.vuw.ac.nz>,
Andy.Linton@comp.vuw.ac.nz (Andy Linton) writes:

|> I have much better access to my colleagues in the US, Australia and the
|> rest of Europe than I ever did while in the UK and I would be very loath
|> to go back to the inferior *international* networking available in the UK.

And this from a user in country connected to the Internet via an
extremely wet piece
of string - a 14.4 kb voice grade modem link!

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax: +61 6 247 3425
c/o, Computer Services Centre,			post: PO Box 4
Australian National University			      Canberra 2601
Canberra, AUSTRALIA		

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Sep 90 09:43 H
From:      <CHAIBP%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   interfacing with Ethernet cards



I believe some people here may have experience developing
device drivers for the following Ethernet adapter
cards:
1. Acer 5220
2. AST-Ethernet Adapter
3. DTK Ethernet LAN card
4. Earthnet-Ie
5. G/Ethernet AT
6. IMC Networks PCnic
7. Localnet D-Link
8. Novell NNE1000
9. 3C501 EtherLink card
10. 3C503 EtherLink II
11. 3C505 EtherLink Plus
12. Tiara LanCard E
13. Univation LifeLink

If you do, please send me you mailing address as I
would like to consult you on issues of interfacing with
these cards.

BP
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 90 23:18:08 GMT
From:      mcsun!ukc!edcastle!expc66@uunet.uu.net  (Ulf Dahlen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <LMJM.90Sep3171440@oriona.doc.ic.ac.uk> lmjm@doc.ic.ac.uk (Lee McLoughlin) writes:
>Yes the UK is really the only Europaen country where not only do we
>lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip
>services to the internet.

I was a bit surprised then I came here that I couldn't ftp or telnet
to Sweden. All universities in Sweden run tcp/ip and there's no problem
ftp-ing or telnet-ing to any site, in Sweden or USA or whatever (but
probably not UK then).


--Ulf Dahlen
Linkoping University, Sweden   and   Edinburgh University, Scotland
Internet: uda@ida.liu.se
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Sep 90 08:54:16 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        <CHAIBP%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: interfacing with Ethernet cards
    I believe some people here may have experience developing
    device drivers for the following Ethernet adapter
    cards:
    1. Acer 5220
    2. AST-Ethernet Adapter
    3. DTK Ethernet LAN card
    4. Earthnet-Ie
    5. G/Ethernet AT
    6. IMC Networks PCnic
    7. Localnet D-Link
    8. Novell NNE1000
    9. 3C501 EtherLink card
    10. 3C503 EtherLink II
    11. 3C505 EtherLink Plus
    12. Tiara LanCard E
    13. Univation LifeLink

With the possible exception of the "Earthnet-Ie" and the AST card,
all of the above boards have Packet Drivers.  Some are in the
Clarkson collection, some (Gateway, Univation, IMC, Acer, Tiara) are
only available from the board manufacturer.  IMHO, you'd be a *lot*
better off writing to either the Packet Driver spec (available from
vax.ftp.com in pub/packet-d.ascii) or the NDIS spec (same machine,
pub/ndis-mac.v101.txt, which all the drivers I've seen so far conform
to or pub/ndis-mac.v201.txt, for a revision with more features) than
doing 10 drivers of your own (several of the above cards are clones
of the original Nat Semi DP839EB demo board, and could be covered by
one software driver with a little extra effort).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Sep 90 07:12:50 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        vd09+@andrew.cmu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Telnettable programs
Vincent,

Your program (with a dummy process routine) worked for me.  Is your
telnet particular about the size of a port number?

	% telnet localhost 3007
	Trying 127.0.0.1 ...
	Connected to localhost.
	Escape character is '^]'.
	Connection closed by foreign host.
	% 

Phil
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Sep 90 09:07:49 -0400
From:      H. Craig McKee <mckee@community-chest.mitre.org>
To:        darrel beach <beach@ddnuvax.af.mil>
Cc:        tcp-ip@nic.ddn.mil, afc2s-saic@gunter-adam.af.mil
Subject:   Re: Verdix security system
Darrel - You want to talk to:

Gaurang Shah
Verdix Corp
Sullyfield Business Park
14130-A Sullyfield Circly
Chantilly, VA 22021

tel: (703)378-7600

We at MITRE have bought the system but don't yet have it running.

The system provides a B-level Ethernet interface; ie, the Verdix Secure
LAN (VSLAN) provides secure access control (between different
classification levels); it does not provide confidentiality.
For confidentiality you must either secure the LAN physically or use
encryption such as the Xerox Encryption Unit.

Regards - Craig
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Sep 90 08:42:34 EDT
From:      hsw@sparta.com (Howard Weiss)
To:        beach@ddnuvax.af.mil, tcp-ip@nic.ddn.mil
Cc:        afc2s-saic@gunter-adam.af.mil
Subject:   Re:  Verdix security system
Unfortunately, there are no ultimate network security solutions for
LANs in existance - although there are several products available that
can help solve various LAN security problems.  The Verdix Secure LAN
(SLAN) is one product (being evaluated for a B2 rating - see the
attached product evaluation bulletin), but it does not "make" an
unsecure LAN into a secure LAN if you think that you can reuse all
your existing hardware and software. You can re-use your existing
Ethernet cable plant, but all the network controllers need to be
replaced with Verdix Network Security Devices (NSDs).  Boeing also has
built a secure LAN and its Network Security Controller (NSC) is being
evaluated as an A1 component.  There are also a couple of LAN
encryption devices that could be used to provide data confidentiality
on a LAN - the Xerox Encryption Unit (XEU) and the Motorola Network
Encryption System (NES).

I've got addresses for Verdix and Boeing:

	Verdix Corporation
	14130-A Sullyvield Circle
	Chantilly, VA 22021.
	(703) 378-7600

	Boeing Aerospace Company
	Dan Schnackenberg
	P.O. Box 3999, MS 94-64
	Seattle, Washington 98124-2499
	(206) 657-5595
	email - Schnackenberg@dockmaster.ncsc.mil

Attached are the product evaluation bulletins from the National
Computer Security Center on both the Verdix and Boeing secure LANs.


Howard Weiss
Sparta, Inc.
Columbia, Md.
(301)381-9400 x201
hsw@sparta.com


____________________________________________________________________

Subject: VSLAN PB

          PRODUCT EVALUATION BULLETIN

     Report No.  CSC-PB-004-88



AS OF:  4 October 1988

PRODUCT: VSLAN(1)

VENDOR:  VERDIX Corporation

CANDIDATE CLASS:  B2 MDIA Network Component

PRODUCT DESCRIPTION:

     The VERDIX  Secure Local Area  Network (VSLAN) is  a network
component  designed  to  interconnect  clients  (e.g.,  mainframe
computers, workstations, servers) operating at different security
levels  in accordance with  Department of Defense  (DOD) security
policies and procedures.  The VSLAN  operates at the physical and
data-link  protocol  layers  of  the  Open System Interconnection
(OSI) reference model.  It operates independently of higher layer
host-to-host protocols and can be  used to integrate a variety of
host systems including internet gateways and application specific
systems.

     The VSLAN consists of a single Network Security Center (NSC)
and  multiple   (up  to  64) Network Security Devices  (NSDs)
interconnected  by a  LAN  transmission  medium.   The  NSC is a
dedicated computer system that  provides a centralized management
facility to control the operation of the VSLAN and to collect and
export audit  data.  Each individual  NSD provides a  trusted LAN
interface  for its client  that  mediates incoming  and outgoing
datagrams  according  to  the  VSLAN  security  policy.   The NSD
implements  the VSLAN  communications protocol  (IEEE 802.3)  and
provides end-to-end encryption for all data transfers accross the
network.  The encryption  protocol used  is the Data Encryption
Standard of the  National  Institute  of Standards  & Technology
(NIST).  The encryption protocol is not used to enforce the VSLAN
security policy, but is used as an integrity mechanism to provide
protection against modification, insertion, deletion,  or replay
of data packets.  As such,  the encryption protocol itself is not
evaluated.

PRODUCT STATUS:

     The  VSLAN  is  marketed   and  supported  by   the  VERDIX
Corporation and was released in October 1988.


_________________________________________________________________

(1) VSLAN is a registered trademark of the Verdix Corporation


EVALUATION STATUS:

     A formal evaluation  of the VSLAN began in  October 1988 and
is  scheduled for  completion during   the first quarter of  the
calendar year,  1990.   The VSLAN  is  being  evaluated against
Appendix A of  the Trusted  Network Interpretation  (TNI) of the
Trusted Computer  System Evaluation   Criteria,  NCSC-TG-005
Version-1, July  1987, as a candidate B2  MDIA network component.
It can potentially be incorporated into a network system that can
meet the TNI Part 1 requirements for class B2.  At the completion
of the evaluation, a final  evaluation report will be produced by
the  National Computer  Security Center   and the  VSLAN will  be
placed on the Evaluated Products List.

     A Product Bulletin does not  assign any rating to a product.
It merely  establishes the candidate  class which is  the highest
class  the system  could attain  should the  formal evaluation be
completed.  As  with all evaluations, a system  must complete the
formal evaluation phase before being assigned any rating.

ENVIRONMENTAL STRENGTHS:

     The VSLAN  is designed to act as  a communications reference
monitor between  attached clients.  The VSLAN, by  itself, is not
intended to be  a complete network system as defined  by the TNI,
but can  be used as a  trusted building block upon  which trusted
network systems can be built.   The VSLAN only controls access to
the LAN and does not mediate access attempts of host processes to
information on local or remote host systems.

The VSLAN was developed to  provide the following services to its
clients:

 -  a system bus interface to external clients

 -  mediation of all data transfers between attached clients
    in accordance with the VSLAN Mandatory Access Control
    (MAC) and Discretionary Access Control (DAC) policies

 -  identification and authentication of the individual
    responsible for operating a node of the network

 -  centralized management functions for security officers
    to exercise control over the operation of the LAN

 -  a datagram oriented communications service

     The ability of  the VSLAN  to correctly  enforce the VSLAN
security policy  depends entirely upon the  trusted components of
the VSLAN and on the correct input of the security parameters by
the security officer.

______________________________________________________________________


Subject:	Boeing MLS LAN PB



		PRODUCT EVALUATION BULLETIN

				  Report No. CSC-PB-003-88


AS OF: 14 Sept. 1988

PRODUCT:	Boeing MLS LAN

VENDOR:	Boeing Aerospace

CANDIDATE CLASS: A1 MI Network Component

PRODUCT DESCRIPTION:

	Boeing Aerospace's Multi-Level Secure Local Area
Network (MLS LAN) is a network component providing multilevel
secure communications between attached devices.  These devices
include, for this evaluation, terminals, host computers, serial
devices, video devices, and stream devices.  Within limits, a
site is free to choose how many of each type of device to attach.

	The NCSC considers that the Boeing MLS LAN is a
candidate for A1 MI network component and is capable (when
properly supported by a special Network Management node and
attached devices) of supporting a network system with Mandatory
Access Control, Discretionary Access Control, Identification and
Authentication, and Auditing commensurate with the A1
requirements.

	The MLS LAN consists of a set of one or more nodes
called Secure Network Servers (SNSs).  Each SNS may support
physical interfaces for terminals, host computers, serial
devices, video devices, or stream devices.  A group of SNSs may
be connected to one another by a transmission medium (either
fiber optic or coaxial cable), enabling devices on separate SNSs
to communicate.  The SNS provides the following services:

	1) host-to-host communication
	2) terminal-to-host communication
	3) terminal-to-terminal communication
	4) terminal/host-to-serial-device communication
	5) video and stream circuit-switched communication

	Host-to-host communication is supported by TELNET,
Transmission Control Protocol (TCP), and User Datagram Protocol
(UDP) service.  Terminals may communicate with hosts and serial
devices through TELNET and with other terminals through an
Inter-Terminal Message service.  Serial devices are supported
with TELNET service.  Video and stream circuit-switching is
controlled through the terminal interface.  All of these
communications services are governed by a mandatory security
policy.  The MLS LAN maintains sensitivity labels for devices and
data that include both secrecy and integrity components at the
granularity of 8 hierarchical levels and 256 non-hierarchical
categories.  In addition, the MLS LAN requires all network
terminal users to identify and authenticate before allowing them
to use any network resources.  End-to-end user identity and
network addresses are provided to hosts.


PRODUCT STATUS:

	The MLS LAN is developed and supported by Boeing
Aerospace, a division of The Boeing Company.

SECURITY EVALUATION STATUS:

	A formal evaluation of the MLS LAN will commence in
October 1988 and is scheduled for completion in 1990.  At the
completion of the formal evaluation, the National Computer
Security Center will produce a final evaluation report, and place
the MLS LAN on the Evaluated Products List.  The MLS LAN will be
evaluated against Appendix A of the Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria, as a candidate A1-MI network component.  It can
potentially be incorporated into a network system that can meet
the TNI part 1 requirements for class A1.

	A Product Bulletin does not assign any rating to a
product. It merely establishes the candidate class which is the
highest class the system could attain should formal evaluation be
completed.  As with all evaluations, a system must complete the
formal evaluation phase before being assigned any rating.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 04:59:54 GMT
From:      comp.vuw.ac.nz!asjl@uunet.uu.net  (Andy Linton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
Just a few words of support for Lee from one who used to have JANET
style access to the Internet i.e. poor to non-existent when I was at Newcastle.

I have much better access to my colleagues in the US, Australia and the
rest of Europe than I ever did while in the UK and I would be very loath
to go back to the inferior *international* networking available in the UK.

Lee's point about the JANET authorities seeing the solution in terms of
OSI protocols is unfortunately true. It will be wonderful when (or is it
if) it happens but the real world is voting for TCP/IP now to be
replaced by some as yet undefined set of protocols which will leap frog
over the OSI stack.
So do us all a favour and open the door into and out of the UK.
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 06:59:24 GMT
From:      mcsun!dfk@uunet.uu.net  (Daniel Karrenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
lmjm@doc.ic.ac.uk (Lee McLoughlin) writes:
>My parting question is directed the those that run UKNET:  when is
>tcp/ip going to be available to UKNET members in the same way as it is
>to Eunet members?

My understanding of the situation is that those that *run* UKNET would 
very much like to offer that service. The problem is that the organisation
where the backbone site is housed fears political pressures from ISOrmites
both inside and outside of that organisation. So far not quite enough
paying customers have surfaced to set up a separate organisation
offering IP services in the UK.


Something else:

At the last RIPE meeting there were (weak) signals to be heared from the
JNT that IP over JANET is not as indiscussable as it used to be.  That
was -again- for some privileged sites that spoke up.  Maybe those who
want it should make up a case and go ask again.  I won't hold my breath
but on the other hand you change nothing by sitting and waiting
(and complaining to the rest of the world). Got to the JNT and ask them about
services like X-windows, NFS etc.  *now*. 

Daniel

-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 09:35:07 GMT
From:      CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU ("Vincenzo G. Capuano")
To:        comp.protocols.tcp-ip
Subject:   Slip dialer

I am looking for a slip (or ppp) dialer for SunOS, I want to use it in
the following way:

at <sometime> call-me-at-home

Thanks,
Vincenzo

=-=-=-=
Capuano
Vincenzo G. Capuano                     E-mail: capuano@cnuce.cnr.it
Via Dante Alighieri, 9                          capuano@icnucevm.bitnet
57036 Porto Azzurro (LI)
Italy

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 10:33:19 GMT
From:      dfk@eu.net (Daniel Karrenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Long lines...

pgross@NRI.RESTON.VA.US ("Phillip G. Gross") writes:

>Your 6 hop path is certainly more direct, but notice that it takes almost
>5 seconds, while the more convoluted 18 hop path via Princeton and Cornell 
>takes only little more than a second.  With that type of difference, I have 
>a better understanding for routes via NSFnet for intra-European traffic.
 
>>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 38 byte packets
>> 1  iracs1.ira.uka.de (129.13.1.1)  20 ms  0 ms  0 ms
>> 2  ciscogb5.Informatik.Uni-Dortmund.DE (188.1.132.1)  1020 ms  840 ms  1080 ms
>> 3  Amsterdam.NL.EU.NET (134.222.1.1)  4120 ms *  3800 ms
>> 4  Paris.FR.EU.NET (134.222.2.2)  4340 ms  4900 ms  3760 ms
>> 5  fnet-gw.inria.fr (128.93.36.128)  3880 ms  3740 ms *
>> 6  192.44.64.61 (192.44.64.61)  3980 ms  4960 ms *

Just to get the technical facts straight:

The 1s delay on hop 1-2 is due to the German research network WIN which
is 64kbit/s X.25. I expect that the WIN conections and interfaces on both
iracs1.ira.uka.de and ciscogb5.Informatik.Uni-Dortmund.DE are quite 
loaded so we are looking at queueing delays here both inside WIN and
at the routers connecting to it.

The 3s delay on hop 2-3 is due to an "open jaw" situation.
Traceroute only reports the *outbound* path the packets take.
The way the icmp packets get back to the host running traceroute is
not reported. No blame on traceroute, it's hard to do.
So although it is tempting to assume that the packets come back the same
way they get there this is not necessarily true.

In this case Amsterdam.NL.EU.net does not know the "direct" route
back to Karlsruhe. So the packets are sent by the default route which
ends up on NSFnet which delivers using the "long way":

traceroute to 129.13.1.1 (129.13.1.1), 30 hops max, 40 byte packets
 1  Amsterdam.NL.EU.net (192.16.202.32)  10 ms  0 ms  0 ms
 2  Falls-Church.VA.ALTER.NET (134.222.5.2)  1200 ms  560 ms  310 ms
 3  College-Park.MD.ALTER.NET (137.39.11.2)  140 ms  150 ms  220 ms
 4  192.80.214.254 (192.80.214.254)  260 ms  360 ms  480 ms
 5  Ithaca.NY.NSS.NSF.NET (129.140.74.9)  860 ms  2330 ms  2330 ms
 6  lan.cornell.site.psi.net (192.35.82.1)  2940 ms  2090 ms  1910 ms
 7  cornell.syr.pop.psi.net (128.145.30.1)  1450 ms  1190 ms  740 ms
 8  albpop.syr.pop.psi.net (128.145.20.2)  420 ms  390 ms  350 ms
 9  albpop.nyc2.pop.psi.net (128.145.80.1)  730 ms  470 ms  850 ms
10  nyc2.nyc1.pop.psi.net (128.145.42.2)  510 ms  200 ms  220 ms
11  nyc_P.lan.nyc1.pop.psi.net (128.145.213.1)  500 ms  370 ms  670 ms
12  nyc1.cuny.pop.psi.net (128.145.14.1)  760 ms  400 ms  710 ms
13  128.145.254.5 (128.145.254.5)  800 ms  390 ms  770 ms
14  * iracs1.ira.uka.de (192.54.104.49)  6810 ms  6760 ms

As you can see round trip delays on this route are highly variable.
The bottleneck is certainly hop 13-14 which is 19.2 kbit/s at this point.
The "faster" traceroute on that route shown earlier in the discussion
has just hit the other extreme of the distribution.

So far the facts, now the reasons:

We are working on the European connectivity problem that this case shows.
Since we don't have a pan-European agency wise enough to fund a European
equivalent of NSFnet this takes local funding arrangements and they
take time. Beleive me we are working hard on this.


-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX

-----------[000036][next][prev][last][first]----------------------------------------------------
From:      ljm@obelix.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        ljm@obelix.twg.com
Subject:   Re: PC-NFS performance

>I am working on a system that will require "real-time" data transfer
>from a Sun IPC to a 386 PC-clone (20 or 25 MHz) via Ethernet. For us,
>in this case, "real-time" means 500-1000 byte packets, 10 per second,
>from the Sun to the PC. The PC and Sun will be on a dedicated
>Ethernet, i.e.  *nothing* else on that wire...
>
>Unfortunately, someone has convinced people around here that PC-NFS
>"won't do real-time" and that we must "write our own Ethernet protocol
>stack" to get the performance we need. :-(...

With our *TCP* stack, on a 25 Mhz clone, you can get ~600 1000 byte
packets/second -- with UDP you can melt the wire. Note that this PC
to PC, a SUN (at least with a stock protocol stack) can't keep up.

With this in mind, I would find it very, very difficult to believe
that SUN's PC-NFS will have any trouble at all transmitting just 10
packets/second.

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

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Sep 90 10:35:07 MET
From:      "Vincenzo G. Capuano" <CAPUANO%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU>
To:        TCP-IP List <tcp-ip@nic.ddn.mil>
Subject:   Slip dialer
I am looking for a slip (or ppp) dialer for SunOS, I want to use it in
the following way:

at <sometime> call-me-at-home

Thanks,
Vincenzo

=-=-=-=
Capuano
Vincenzo G. Capuano                     E-mail: capuano@cnuce.cnr.it
Via Dante Alighieri, 9                          capuano@icnucevm.bitnet
57036 Porto Azzurro (LI)
Italy
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue 4 Sep 90 15:59:07-EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        braden@venera.isi.edu
Cc:        ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu, postel@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Hosts whose IP numbers end in 0...
Bob, Jon, et al.--

In the spirit of "Sometimes it's necessary to make sure everybody means the
same thing even by 'NO-OP'", I suspect it's past time for me to observe that
the problem with the Subject "thread" is that some of the discussants seem
to be making rather different unstated assumptions about "filtering" than
others are.

I THINK the original question had to do with what we might call "outgoing
filtering", in the sense of rejection of datagrams by gateways other than
the gateway which is connected to the/a communications subnetwork (NOT "subnet"
in the current jargon sense of the term) to which the destination Host is
attached, which is the only gateway that could "know" whether the proferred
address would lead to a broadcast.  Yet several of the responses SEEM to be
taking the point of view of just that "terminal" gateway and holding that
of course it's entitled to "filter".  My own impression is that it's precisely
this latter, "incoming filtering", case in which "judgement" might/can/should
be exercised by a gateway, and only this latter, incoming filtering case.
But irrespective of whether that's the "correct" view, I do think that the
thread will remain tangled until and unless we start explicitly distinguishing
between "outgoing" and "incoming" "filtering"--the failure to do which 
EXPLICITLY I did mentally note, and regret not commenting upon, when the
message Jon subsequently endorsed went by, b/t/w, thinking I'd probably just
skimmed over it too quickly and assuming the issue would eventually be
resolved without my having to make a religious (= Semantic Puritanism)
issue of it.

However, now that we've got the co-authors of the Requirements RFC in
apparent disagreement, it does seem desirable to confirm that they aren't
just re-enacting the old baddie about the neighbors who could never agree
because they were arguing from different premises....

Semantically Puritanical cheers,
           map
-------
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 12:27:26 GMT
From:      chris@vision.UUCP (Chris Davies)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <LMJM.90Sep3171440@oriona.doc.ic.ac.uk> lmjm@doc.ic.ac.uk (Lee McLoughlin) writes:
...
>Even something as simple as running tcp/ip over JANET so we can have
>some degree of sane networking here in the UK seems to be out.  The
>JANET powers that be do not want anything as useful as tcp/ip sullying
>there network!  God forbid you should be able to use the networking

Not only can't you use tcp/ip over JANET, but commercial sites (in my
experience) can't even use JANET as it stands - not even for real money.  So
no NIFTP, etc.

>My parting question is directed the those that run UKNET:  when is
>tcp/ip going to be available to UKNET members in the same way as it is
>to Eunet members?

What a wonderful thought.  Perhaps commercial sites would be allowed to
use it too (at less that 10k p.a. for the privilege)?

Chris
-- 
VISIONWARE LTD         | UK: chris@vision.uucp     JANET: chris%vision.uucp@ukc
57 Cardigan Lane       | US: chris@vware.mn.org    OTHER: chris@vision.co.uk
LEEDS LS4 2LE          | BANGNET:  ...{backbone}!ukc!vision!chris
England                | VOICE:   +44 532 788858   FAX:   +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X integration" --------------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Sep 90 14:24:31 GMT
From:      RUEDI BOESCH <K602340%CZHRZU1A@pucc.PRINCETON.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: CMU TCP/IP and name serving problems
Kommt mir irgendwie bekannt vor...,
mal schauen ob die Antwort auch mal kommt. Merci
Acknowledge-To: <K602340@CZHRZU1A>
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 16:20:46 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

In my (object-oriented) implementation of TCP, the interface to the TCP
processing module is based on TCP-messages.  You can set/check flags and
numbers and all that kind of crap.  It is somebody else's job to make it look
like a file or whatever.  If you want a file that automagically creates a
network connection when you open it (and what is this /dev/tcp/XXX nonsense
all about? Sheesh! I want a file called "Dad" that opens a connection to the
talk daemon on pop's macintosh when I open it r/w -- this silly business with
IP addresses and port numbers is just as much Someone Else's Problem as making
the whole goddamn mess look like a file).

I think this whole discussion is misguided (though convenient for those of us
who wish to Change the World) in that it makes the assumption that there is
some best way to think about network communications.  This is false.
Networking is complicated (Zweig's Axiom).

The paradigm for thinking about something and the something itself are
different, and if the great minds behind UNIX can't hack that, well, shout at
them (as Mark appears to be doing).  A corrollary to the fact that they are
different is that they should be handled by different pieces of the OS.

-Johnny Paradigm

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 16:29:02 GMT
From:      att!watmath!maytag!mks.com!mks!eric@ucbvax.Berkeley.EDU  (Eric Gisin)
To:        tcp-ip@nic.ddn.mil
Subject:   Tahoe rlogin and timed ported to System V?
Has anyone ported the 4.3-tahoe rlogin and timed to System V
AND made the source freely available?
(I'm interested in an Interactive UNIX version, but any version
will save be useful).

Rlogin looks straight-forward but time-consuming.
I want to enable the support for ~<suspend>, which Interactive
neglected when they added job control.

Timed is difficult because you have to emulate adjtime(2).
Any simple program that acts like a timed slave would do too.

As a related question, I'm curious how different vendors deal with the
select/poll on the tty and socket/stream in telnet.
System Vr3 did not have the ability to poll character devices.
This is not an issue in rlogin, which uses two processes instead of select.
Interactive extended poll to work on ttys and ptys (and pipes),
and select automatically aquires this poll functionality.
How do SCO UNIX or ESIX handle this?
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 17:29:23 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sockets vs streams.  An attempt to answer the original question

In article <1990Aug28.162400.17811@zoo.toronto.edu>
   henry@zoo.toronto.edu (Henry Spencer) writes:
>spencer> The way to do i/o on Dennis's streams was with "read" and "write".
>spencer> Network i/o, in general, looked *exactly* like local device i/o.
>
>spencer> This is the way it should be, unlike what both Berkeley and
>spencer> AT&T have done (both have reluctantly conceded that most people
>spencer> want to use "read" and "write" and have made that work, but
>spencer> their hearts were clearly elsewhere).

In article <PCG.90Sep2194524@athene.cs.aber.ac.uk>
   pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>And for good reason! read() and write() on file descriptors is not the
>most amusing interface. It is much more convenient to have ... [features]

The problem is larger than that. As commercial programmers have
often said, unix read() and write() is not a very good interface for
files, either. It is a good interface for SIMPLE TEXT files, and very
little else.

Having a guaranteed subset of compatible functionality has allowed
very productive use of the "building block" philosophy. Having a way to
specify a remote conenctions "as if" it were a filename would allow more
things to be prototyped with simple shell scripts and pipelines.

On the other hand, great flexibility leads to a loss of device
independence, witness VMS' proliferation of pseudo-device drivers as an
example of where the path of customized interfaces may take us.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 18:24:14 GMT
From:      perand@admin.kth.se (Per Andersson)
To:        comp.protocols.iso.dev-environ,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   SNMP with PSI snmp and ISODE 6.0


Hello.

I have been trying to run snmpxmon from PSI to monitor a network of Suns,
Annexes, Fastpaths etc. The Suns were running the snmpd from isode 6.0.
snmpxmon wouldn't understand that the Suns were running, but while looking
with cmu's snmpstatus I get "4BSD ISODE/SNMP" from snmpd. Anybody willing
to explain what I am doing wrong ? I am sure I am....

Per
-- 
---
Per Andersson
Trying a new job at Bofors Electronics,
still reading news at the Royal Institute of Technology

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 18:55:15 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <1213@vision.UUCP> chris@vision.UUCP (Chris Davies) writes:

   Not only can't you use tcp/ip over JANET, but commercial sites (in my
   experience) can't even use JANET as it stands - not even for real money.
   So no NIFTP, etc.

This is untrue. Commercial sites may use JANET provided they have good
reasons for doing so, essentially collaboration with an academic site
on a research project. JANET cannot be used for purely commercial
traffic (shunting data between a company's offices - or two distinct
commercial sites - in Exeter and Aberdeen say). The rules are roughly
similar to those for use of NSFnet: "free" government funded networks
must not subsidise commercial traffic.

It's more or less OK for a company to connect via PSS through a
PSS/JANET gateway to an academic site and exchange data. In fact, this
is how some of the big commercial sites get their news.

		Jim

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 20:20:56 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
In article <38584@ucbvax.BERKELEY.EDU> sklower@ernie.Berkeley.EDU.UUCP (Keith Sklower) writes:
>>...the way it should be, unlike what both Berkeley and AT&T have done
>>(both have reluctantly conceded that most people want to use "read"
>>and "write" and have made that work, but their hearts were clearly
>>elsewhere).
>
>I find this inaccurate, partronizing and tiresome.  I have worked around
>Berkeley since 1978 and although was not a member of the actual unix group
>in 1982 while TCP was being incorporated, attended their meetings and
>seminars.

I wasn't there; all I got to do was read the resulting documents.  Some
of which come over with a very strong air of "well, if you want to do it
right, you will of course use our 57 new system calls, but we grudgingly
admit that read/write will work if you insist on being backward".
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 20:30:34 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
In article <9008311500.AA12356@ftp.com> jbvb@ftp.com writes:
>    ...That's all most customers want.
>
>I see where our viewpoints differ: I am selling applications to end-users,
>and I intend to support them.  Most of the end-users who use our Development
>Kit for one-off or in-house applications are probably quite satisfied with
>open/read/write/close.  However, I am careful to advise any OEMs who develop
>for resale to pay close attention to the flags and error codes...

I was writing from the down-in-the-wires viewpoint, where *any* user process
is a customer.  And on the whole, I remain unrepentant. :-)  It should be
possible to use open/read/write/close, with (say) perror when something
goes wrong, without major problems, assuming that error-message-and-die
is a reasonable thing to do on failure.  A requirement for fault tolerance
does require closer attention to error handling, as in non-networked code.
Also as in non-networked code, a requirement for carefully optimized use
of system resources requires attention to flags and details.  And anyone
building production code should be aware of the grubby details, so that
he can recognize the one case in a hundred where some of them are relevant.

However, I continue to believe that what most applications want to see is
a reliable bidirectional pipe, perhaps set up in slightly odd ways but
thereafter used via read/write/close, with invisible recovery from transient
problems and a suitable errno value on hard failure.

The resemblance to a Unix file is not accidental. :-)
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 90 21:11:17 GMT
From:      ncs.dnd.ca!hnadra@rutgers.edu  (Hicham N Adra)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP over X.25 : a Network Interface
Our organization, the Ottawa branch of the CGI Group, is interested in 
information about implementations of RFC 877 (A Standard for the
Transmission of IP Datagrams Over Public Data Networks, DDN NIC).

We are attempting to (re-) establish our connection to DREnet (Defence 
Research Establishment Network), "a communications network that has been
developed to support the Research and Development activities of the
Department of National Defence". DREnet sites are connected to Datapac
and use TCP/IP over CCITT X.25.

Also of interest is the availability of the source code release of Purdue 
University's X.25 Network Interface (XNI). 

NOTE:
     The host under consideration is a Unisys 6000/30 system with System
V Release 2.20 Version 8.02. We also have other systems including a 
VAX 750 with VMS 5.3-1. Both are also part of a LAN.
The current objective is to establish CGI's access to DRENET through the 
*Unisys system*, however. (How can this best be achieved?)
END OF NOTE.

Your insights about, and experience with, both general approaches and specific
solutions are appreciated.

          Thank you.

Hicham N. Adra       275 Slater St. 19th Floor     Tel: (613) 234-2155.   
CGI Group            Ottawa, Ontario K1P 5H9       Fax: (613) 234-6934.
hnadra@ncs.dnd.ca    Canada
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Sep 90 08:17:43 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PC-NFS performance
Transfer rates significantly less than 10 packets/sec are relatively
easy to achieve if you have a sufficiently lousy Ethernet interface
(e.g. 3C501) and offer a big TCP window to a fast host afflicted with
the standard 4.2bsd TCP retransmit algorithm.

Leo is describing a tuned situation with good hardware.  Your prophet of
doom has probably seen a pathological situation with bad hardware.  Writing
your own relaible protocol on both ends of the connection is a lot of
effort.  Perhaps your prophet of doom would be appeased by the use of one
of the freeware TCP/IP stacks, which would allow you to tinker starting from
a working baseline....

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 00:38:42 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

In article <5329@munnari.oz.au> kre@cs.mu.OZ.AU (Robert Elz) writes:
>There was a time when building network names into the filesystem
>was seen as a sensible thing to do - nice and regular, existing
>programs would be able to use them, ...

Yes, many dinosaur operating systems did just that.  There are still a
few examples of those dinosaurs, and they are running just fine with
precisely that mindset.  That is not the reason they are dinosaurs;
more likely, the antiquity of the hardware platform is more
responsible for their extinction.

>Unfortunately, while its a nice idea, it really won't work in general,
>and if it doesn't work in general, its not worth the effort.
                                    ^^^^^^^^^^^^^^^^^^^^^^^^
I think this is more the the point than anything else.  The high
priests of sockets don't think it is worth the effort to support
heresy.

>[lots of spurious arguments about why simple things must be made
> harder than necessary]

All of these problems (even DNS lookups of hosts in filenames) were
solved in other operating systems.  It doesn't matter *how*
complicated the most complicated file specifier can be; all that
matters is that the defaults are the right thing for all but the
oddball cases so the simple case is simple.

>Now, the easy part is solved, TCP just isn't that complex, but
>lets extend generality a little and open an OSI MHS (X.400)
>connection as well.

X.400 is at an entirely different level (not to mention stack) from
TCP.  You are mixing apples with orange juice.  The OSI IP stack is
probably a different device from /dev/tcp, and what layers on top of
it is specific to that device.

>Having that
>file descriptor all the necessary options can be set before the
>network is asked to establish the connection

Here's the rub, and the real reason why we've been made to suffer with
streams.  However, this is conceptually easy to solve.  Make the
O_NDELAY form of open with none of {O_RDONLY | O_WRONLY | O_RDWR} set
to mean "give me a designator only", and then have an ioctl() call
that means "establish connection on this designator".  Since we allow
non-blocking open with establish (implicitly above), we probably want
to have all the likely functions: block until open, establish and
block, establish without blocking, test if open.

Summary: the simple cases should be *simple*, not made complex for a
theoretical complex case.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin  "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105   "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud          "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762  "Chigau.  Gaijin ja nai.
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU    Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 02:05:21 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@decwrl.dec.com  (Don Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In article <2350@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU
>(Mark Crispin) writes:
>
>>If "network I/O looks like local device I/O" under Unix then when the
>>h*ll do I have to worry about all the socket or streams crap?
>
>I think the confusion in this discussion is between reading and
>writing on the one hand and opening the connection on the other
>hand.
>
>Once a virtual circuit has been set up, the socket mechanism becomes
>transparent to the extent networking will allow.  Setting up the
>virtual circuit does require more steps than opening a device or file.
>I find this fairly understandable, because the BSD socket interface
>gives you LOTS of options, and it was designed to be independent of the
>underlying transport mechanism.
>
>>If I want to connect to port 0.143 on host 128.95.112.69, why can't I
>>do something like
>>  open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);...
>
>Like somebody said, it would be nice if there was a library routine
>that would make this easy.  I suppose the open() system call could also
>do this, but then there might be too much functionality in a single
>system call, because it would have to understand all possible protocols
>and possibly accept additional parameters for the different types of
>sockets and connections that are possible.

If I have a local printer, I can send data to it by doing
	cat somefile >/dev/lp

Now, if the printer is on a terminal server somewhere, it would
sure would be nice to be able to do the same sort of thing.
	cat somefile >/dev/tcp/terminalserver:port
		or
	cat somefile >/dev/tcp/x.x.x.x-y.y

You could even send it to two devices using tee!

Specifically, you could use this for the lp= parameter in /etc/printcap
so that you don't have to play funky filter games.

The bottom line is that it should be possible to open connections with
fopen() so that applications don't have to be modified in order to
take advantage of this connectivity (assuming they don't rely on seeks
and wierd ioctls that don't make sense on a network connection).
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Sep 90 10:14:12 -0400
From:      barns@gateway.mitre.org
To:        sdd.hp.com!samsung!munnari.oz.au!metro!pta!yarra!chris@ucsd.edu (Chris Jankowski)
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: "The Open Book" by Rose - your opinions sought
To my kmnowledge, no book comparable to Comer exists for OSI and
I doubt that one will be created any time soon.  Open Book is about the
best available and you might as well buy it (everyone else does),
but it isn't as concrete as Comer because in the OSI world, these
things are still being figured out.  I think that is a limitation
we just have to accept for a while yet.  And in part, it will probably
exist forever, because OSI is rather broader than TCP/IP and thus
won't be able to be covered to the same depth in anything like the
same number of pages, once we have figured out the right details.
This is wild speculation, but I'd estimate a treatment of ALL of the OSI
protocols to comparable depth would run about 5000 pages.

/Bill Barns
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 04:25:01 GMT
From:      jhp@crawford.UUCP (Jay Pound)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.misc
Subject:   Fiber Optic Equipment


I need to optically isolate 64 async ports from their terminals.  I am looking
at (1) using fiber optic terminal multiplexers or (2) going with terminal
servers and fiber optic ethernet.  My questions are:

Can anyone recommend reliable fiber optic multiplexers and/or terminal servers?

Has anyone used any of the Black Box fiber optic equipment?

Is anyone using the Annex II (Xylogic) terminal servers (under any name)?

Ethernet seems to be more expensive but it should make it easier for me to 
add another host system to the net.  Any comments would be appreciated.

Jay Pound

-- 
  Jay Pound				 /     Crawford Post Production, Inc.
  jhp%crawford.UUCP@mathcs.emory.edu	/      535 Plasamour Drive
  gatech!emory!crawford!jhp	       /       Atlanta, Georgia 30324

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 05:05:41 GMT
From:      sdd.hp.com!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@decwrl.dec.com  (Mark Eggers)
To:        tcp-ip@nic.ddn.mil
Subject:   routing with virtual subnets
I am working with a company that has a rather different short-term requirement.

The setup is as follows:



--------------- Sun ----------- cisco ----- (world)
 subnet a        |    subnet e
 subnet b        |
 subnet c        |
 subnet d        |
                 |
                 |
          slip to subnet f

Subnets b-d are 'virtual' subnets, existing on the same wire as subnet a.  I
can route between the subnets a-d by adding the following type of lines:

route add net.b.0 hostip 0

where hostip is the IP address of the host that the route is being added to.

Gated is running on the Sun, and announces subnets a-d, and f to the cisco.
However, I cannot route from subnets b-d to any other subnet on the other side
of the Sun, or through the cisco.

Any thoughts would be appreciated.

/mde/
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 05:55:07 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

Several people say that it's best to put everything into the filesystem.
But opening a file may not make sense for client-server applications.
Files may not be a very good abstraction for network communications in
general.

UNIX has from its conception given us an infinitely better solution:
passing references to files through descriptors instead of names.

So why don't we take advantage of this? Why don't we separate out
*opening* a file or *connecting* to a TCP server or *waiting* for a
connection into specialized programs? Why don't we have those programs
pass the suitably initialized descriptors to our processes? In other
words, why don't we take the modularity that we can get?

Answer: We can. Opening a file is done by your shell: $ <prog file.
Connecting to a server is done by authtcp: $ authtcp nyu smtp prog.
Serving connections is done by attachport: $ attachport -psmtp prog &.

Now, I admit that authtcp and attachport don't have perfect interfaces;
I'm developing a somewhat more general, much more portable client-server
framework. But they do the job. They take advantage of the modularity
that UNIX allows. And they'll be ported to the UNIX of the future.

---Dan

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 06:10:07 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

In article <9009012315.AA08202@world.std.com> bzs@WORLD.STD.COM (Barry Shein) writes:
>I'm mixed on this issue. TOPS-20 had a file-system-like interface (was
>that BBN's TCP?) and, to be frank, I found it quite clumsy (tho
>interesting.) The string one passed to the open call started to look
>more and more like a long string of IBM/JCL and less and less like a
>file name as various options were added.


Hmm, I guess you never did much in JCL; I did, and believe me, the
name of TCP: files was a lot simpler!  The main bug in the TOPS-20
interface was that passive (listening), not active, was the default.

Anyway, the TOPS-20 filesystem TCP interface came from DEC.  The
original BBN interface was one that every socket hacker would love.
It implemented an entirely new set of system calls just for TCP,
passing around an entirely separate space of designators from files,
so every program that did network I/O had to have a completely
different I/O path just for TCP.  A gory mess.

DEC was originally going to rewrite it, but what they ended up doing
was writing a filesystem driver that used the BBN calls internally.
Eventually, there were some special hacks done to reduce the overhead,
but the underlying BBN mess remained.

However -- once the filesystem interface was available I don't know of
a single applications programmer who used the BBN calls.  Everybody
wrote using the TCP: device.  I'm quite familiar with all this as I
wrote most of the TOPS-20 applications-level TCP software.

Just you wait.  I'm sure that someone is going to end up inventing yet
another I/O schema for ISO.  And everyone will scream for something
that is backwards compatible with sockets or streams.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin  "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105   "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud          "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762  "Chigau.  Gaijin ja nai.
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU    Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Sep 90 13:48:26 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Benny Tong <bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: tcp source port number assignment in new tcp connection

Hello,

I don't know what TCP/IP interface you are using but unless you are writing 
your own TCP implementation source port assignment should be a 'local',
i.e. OS or TCP interface running on you machine, issue.

All interfaces I've seen on DEC machines , and others, have returned this
identifier; usually with the option for you to specify one....and even that may
not result in what the remote TCP sees as your source identifier. On the
interface level it is just a logical assignment and does not necessarily map
to a 'real' TCP port. Maybe QIO stuff is different but even that returned a 
logical channel number if i recall correctly. If security is the issue then
that's another discussion.

In any event:

 () If you have a choice in the matter let your interface to TCP assign this.
    Less book keeping and cleanup.

 () If you are writing an interface and or your own TCP then take a look
    a what Excelan, Wollangong, DEC, and others have done already in this
    area....

 () There were some discussion in this newsgroup ( whos right/wrong ) regarding
    two vendor's port assigments above 1000 which referenced an RFC, about a 
    month ago. Impression I got was that the RFC came out the winner...no hard
    fast rule just agreed on and established convention in this area.


 Good luck,
 George Williams
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Sep 90 12:35:40 CDT
From:      Lt. Matt Jonson <jonson@server.af.mil>
To:        mek@devvax.jpl.nasa.gov
Cc:        piet@cwi.nl, tcp-ip@nic.ddn.mil, beach@ddnuvax.af.mil
Subject:   Heaven and Hell
> Date: 30 Jul 90 12:42:10 GMT
> From: mcsun!hp4nl!charon!piet@uunet.uu.net  (Piet Beertema)
> Organization: CWI, Amsterdam
> Subject: Re: Network Temperature Protocol
> Message-Id: <1907@charon.cwi.nl>
> References: <9007240048.AA00668@bel.isi.edu>, <1990Jul25.073009.23336@specialix.co.uk>
> To: tcp-ip@nic.ddn.mil
> Resent-Date: Tue 31 Jul 90 10:34:48-CDT
> Resent-From: Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
> Resent-To: jonson@server.af.mil
> Resent-Message-Id: <12610083008.15.AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
> 
> 
> 	If sucessfully implemented, such a protocol would also contribute 
> 	towards reducing Global Warming.
> Wonder if it would help reducing temperature in more
> exotic places too, like those mentioned below:
> 
> ============================================================================
>    Some consolation
>    ----------------
> 
>    I wish to clear up the old question: "Which is hotter, heaven or hell?"
> 
>    Verse 26 of Chapter 30 of Isaiah defines the energy radiated heavenward
>    by the sun and the moon in terms of the amount received by the earth:
>    "Moreover the light from the moon shall be sevenfold, as the light from
>    seven days". Thus, heaven receives from the moon as much energy as the
>    earth does from the sun. If we add to that 49 times ("seven times seven")
>    the earth's solar radiation falling on heaven, we have a total of 50 times
>    the energy we receive from the sun. Using a known absolute temperature
>    of the earth and the Stefan-Boltzmann fourth-power law, we arrive at the
>    determined temperature of heaven: a less than paradisiacal 525 degrC.
> 
>    And the temperature of hell?
> 
>    Revelation 21:8 says: "The fearful shall have part in the lake which burns
>    of fire and brimstone". Since brimstone (sulfur) has a boiling point of
>    445 degrC, hell must be several degrees cooler. If it were not, it would
>    be a vapor, not a lake.
> 
>    Therefore, heaven is hotter than hell by at least 80 degrC.
> ============================================================================
> 
> (Actually this story is a couple of years old already;
> can't remember where I ever got it from).
> 
> --
> 	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)
> 

He does make one potentially bad assumption, and that is that Heaven and
Hell are both at the same Pressure.  I would be willing to argue that
Heaven, being much more ethereal, could have a significantly lower Pressure
and hence lower temperature than arrived at here on earth, whereas I  would
also be willing to argue that Hell may be at a significantly higher pressure
than here on earth, and hence, a much higher temperature.

At this point, the argument suddenly moves to the plane of Philosophy...
which doesn't have any description, but with the amount of hot air that
it generates, could well be a good bit warmer than Heaven, Hell or Saudi
Arabia.

-Matt
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 08:18:11 GMT
From:      chris@tcom.stc.co.uk (Chris Milton)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

yep. yep. yepyepyepyepyep. yep.
that's wholehearted agreement there. one problemo though...

a. can you see academic sites wanting to shell out money they aint got
to modify up to internet ?
b. can you see companies which aren't even on janet because it provides
security problems wanting to go onto internet?

pity you cant telnet using bitftp ... oh well, back to trying to find
the gateway out of this organization into the real world *sigh*. oops,
sorry, i mean back to doing that really interesting pascal prog :-)

bye de bye
chris
chris@jura.tcom.stc.co.uk

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 09:25:10 GMT
From:      mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net  (Andy Holt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
Not only is the present Janet policy (coloured books instead of
TCP/IP) isolating us from the rest of the world, but it looks
like the ISO transition will do the same again:
The JNT in its infinite wisdom (???) has mandated that the ISO
profile used in the UK use TC0 (connection oriented transport
service) while NBS in the USA is encouraging the use of TC4
(connectionless transport service).
Here we go again .....

Andy
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 09:54:50 GMT
From:      ajudge@maths.tcd.ie (Alan Judge)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In <LMJM.90Sep3171440@oriona.doc.ic.ac.uk> lmjm@doc.ic.ac.uk (Lee McLoughlin) writes:
>Yes the UK is really the only Europaen country where not only do we
>lack tcp/ip services to the internet but you *CANNOT GET* tcp/ip
>services to the internet.
 Not quite :-(  Ireland is still not IP connected.
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@cs.tcd.ie +353-1-772941 x1782

Fortunately the computer virus did no harm to our records. It was
immediately devoured by all the bugs in our own programming.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 11:15:55 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Long lines...



 >I'm waiting for the first report of usa->europe->japan->australia,
 >myself.

we have a visitor from crete/greece here at the moment - as i type, he
is reading his e-mail on a machine in Heraklion. the traffic from
london is routed via princeton...

it's still all pony express stuff though...

 jon

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 11:38:57 GMT
From:      mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!jonathan@uunet.uu.net  (Jonathan Knight)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
From article <1990Sep4.164546@jatz.aarnet.edu.au>, by pte900@jatz.aarnet.edu.au (Peter Elford):
> And this from a user in country connected to the Internet via an
> extremely wet piece
> of string - a 14.4 kb voice grade modem link!

At least he is connected to the Internet by something.  Our political
gateway (ukc) from the UK to Europe used to be a 9600 baud UUCP link.
According to the maps at mcsun this is now a 9600 baud TCP/IP link.
The rest of the UK uses something called coloured book software which
works great as long as all you want to do is transfer files of data in
the UK.

It looks like the management want to go ISO, so at least we stand a
chance of making contact with the rest of the world.  It does seem
foolish that with most of the world talking TCP/IP there are no plans
in the UK for any TCP/IP service over JANET.

Fortunately for us, the UKnet gateway isn't the only one.  UCL have
a 56Kb link to the USA and offer a guest FTP service which allows us
to transfer files to and from internet connected sites.  They also
transfer our mail, and make no charge.  This is unlike UKC which
charge for news, and mail, and they also advertise themselves as
a valid route for uk mail.  This is a pain as they are trying to fit
a full news feed and email down their 9600 baud line, when there
is a no charge route for email down a 56kb line.  There's also the
problem that UKC advertise themselves as a forwarder for the ac.uk
domain, when in fact they only forward mail to uknet members and drop
everything else on the floor.  UCL forward all ac.uk mail regardless
of what they are members of.

So you see that the UK has poor connectivity with the outside world
and is politically restricted in its development.  Hopefully somebody
somewhere will learn how to utilise the resources we have to provide
the service that we want, within my lifetime......

Then again, I'm not going to hold my breath.
--
  ______    JANET :jonathan@uk.ac.keele.cs     Jonathan Knight,
    /       BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
   / _   __ other :jonathan@cs.keele.ac.uk     University of Keele, Keele,
(_/ (_) / / UUCP  :...!ukc!kl-cs!jonathan      Staffordshire.  ST5 5BG.  U.K.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 12:13:33 GMT
From:      chris@vision.UUCP (Chris Davies)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <1213@vision.UUCP> I wrote,
>   Not only can't you use tcp/ip over JANET, but commercial sites (in my
>   experience) can't even use JANET as it stands - not even for real money.
>   So no NIFTP, etc.

In article <JIM.90Sep4195515@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim
Reid) replied:
>This is untrue. Commercial sites may use JANET provided they have good
>reasons for doing so, essentially collaboration with an academic site
>on a research project. JANET cannot be used for purely commercial
>traffic (shunting data between a company's offices - or two distinct
>commercial sites - in Exeter and Aberdeen say).

Sorry, I should have stated my point more clearly.  I was aware of this.  But
I think I'm correct in stating that a direct connection to JANET (as such) by
a commerical site is not permissible (and so all traffic must go through a
gateway - thus mail only, in effect).

>The rules are roughly
>similar to those for use of NSFnet: "free" government funded networks
>must not subsidise commercial traffic.

But if the commercial site(s) were to pay for their use of the government
funded networks, then I don't see why this shouldn't be acceptable.  With the
current situation, I would agree that commercial sites should not exploit
JANET for commercial gain.

Chris
-- 
VISIONWARE LTD         | UK: chris@vision.uucp     JANET: chris%vision.uucp@ukc
57 Cardigan Lane       | US: chris@vware.mn.org    OTHER: chris@vision.co.uk
LEEDS LS4 2LE          | BANGNET:  ...{backbone}!ukc!vision!chris
England                | VOICE:   +44 532 788858   FAX:   +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X integration" --------------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 12:43:27 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   was: sockets vs. streams / net open



 >Henry Spenser asked why no-one has ever created a standard library
 >routine to open a connection.  That's something I have wondered
 >about myself, it seems like a fairly obvious thing to do.   But then

actually, when i ported the X windows protocol to run over OSI as
well as over TCP and DECnet, I did it by writing a small set of
of arrays of functions (open, accept, read[v], write[v], close and getpeer
which were indexed by the protocol family being used (either
connection id type, or address family type) (not a very new idea), and this
turned out to be perfectly sufficient functionality to get at adequate
protocol service...it is also the flipside of the coin that transport
service bridges are feasible...

j.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Sep 90 12:15:55 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Long lines...


 >I'm waiting for the first report of usa->europe->japan->australia,
 >myself.

we have a visitor from crete/greece here at the moment - as i type, he
is reading his e-mail on a machine in Heraklion. the traffic from
london is routed via princeton...

it's still all pony express stuff though...

 jon

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 14:03:43 GMT
From:      andrew@megadata.mega.oz.au (Andrew McRae)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

In article <1990Sep5.020521.803@mlb.semi.harris.com>, del@thrush.mlb.semi.harris.com (Don Lewis) writes:
>In article <2350@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>>In <6964@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU
>>(Mark Crispin) writes:
>>
>>>If I want to connect to port 0.143 on host 128.95.112.69, why can't I
>>>do something like
>>>  open ("/tcp/128.95.112.69-0.143",O_RDWR|O_CREAT,0);...
>
>Now, if the printer is on a terminal server somewhere, it would
>sure would be nice to be able to do the same sort of thing.
>	cat somefile >/dev/tcp/terminalserver:port

Perhaps a more structured approach to this whole problem is
to back out of the kernel altogether and use the same
paradigm as in some of the Research Unix kernels of a
user mode file system (a la the /proc filesystem); using a
UMFS would remove the complexity of mapping different
file names to network address away from the kernel into
user processes which could then use the BSD socket style
kernel calls to hide the messy details of network programming.

At least then the programs which want to access all those
neato network calls can do so, but for those programs that
want to open the network connection using a file name the
UMFS would then interpret the name accordingly. Then different
servers could be implemented to handle different protocols,
and services e.g.:

        fd = open("/dev/net/stream/cpu.xyz/lat", 2);

This could map to an entirely different protocol family (e.g. DECNet).

 or
        fd = open("/dev/net/tcp/2300/192.34.56.78", 2);

Links could be set up to map "/dev/net/printer" to
"/dev/net/tcp/termserver/printer"...

It should be easy to take skeleton UMFS network servers and
build specialised services (such as a nntp-service file etc.).
A mach-like kernel with good messaging may fit well here..

Whilst the comment that has been made that what most processes
want is a simple full duplex pipe-like stream (and the kind
of open that has been talked about will work OK), I find the more
common network programming I am involved with is using the
datagram facilities (sendto, recvfrom etc) to build distributed
services (especially real time stuff); using broadcasts and
finding out who sent you a data packet is important as well. I
hate to think what I would have to do if all I had was a read or write.

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

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Sep 90 20:57:35 -0400
From:      bzs@world.std.com (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   Sockets vs streams.  An attempt to answer the original question

I think we're all looking at this in far too narrow a context. There
are many issues that are being hand-waved (note, anyone who assumes I
believe one way or the other on this issue please send me my decision
as I haven't received it yet.)

For example, when I address something that reaches out into, say,
network name space, where does my request go? Does it go to a
specialized driver that takes care of things like DNS resolution?
Does it get handed back up to a user-level process? What?

I still think the terminal example (open("/dev/tty/9600/even/noecho",...)
was a good one.

Someone sent me mail saying "oh, that's just ioctl()'s".

What magic! Sockets are bad, ioctls are good, such power in a name.

The real issue is:

	A) Are we trying to simplify/generalize the *user*
	interface so most any network/etc operation can be
	specified in a string, wherever a file name is expected?

or

	B) Are we trying to simplify/generalize the *programmer*
	interface so they don't have to know about those nasty
	socket calls?

Careful, I believe those two goals can be very much in conflict. I
also don't believe that everyone discussing this issue on this list
falls into the same camp. So we're having definite communications
problems, state your objectives!

        -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
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Sep 90 13:43:27 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   was: sockets vs. streams / net open


 >Henry Spenser asked why no-one has ever created a standard library
 >routine to open a connection.  That's something I have wondered
 >about myself, it seems like a fairly obvious thing to do.   But then

actually, when i ported the X windows protocol to run over OSI as
well as over TCP and DECnet, I did it by writing a small set of
of arrays of functions (open, accept, read[v], write[v], close and getpeer
which were indexed by the protocol family being used (either
connection id type, or address family type) (not a very new idea), and this
turned out to be perfectly sufficient functionality to get at adequate
protocol service...it is also the flipside of the coin that transport
service bridges are feasible...

j.
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 15:59:33 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: sockets vs. streams

In article <9009012315.AA08202@world.std.com>, bzs@WORLD.STD.COM (Barry Shein) writes:
> As to David Stevens questions about file system semantics, what does
> "cd /dev/anydev" mean now? Nothing, you get back "Not a directory".
> In this mythical TCP you might get back something (e.g. some form of
> NFS done this way), or not. I don't see that as a serious problem.

	It's not the same analogy, which was my point. Crispin's example,
which you may not buy into, specifically uses "/"'s below the pseudo-device
boundary so that they become the exception to the syntax-directed pathname
translation that otherwise has the wonderfully dependable rule: "/ separates
directories."
	It's wrong because it's ugly and it doesn't fit with UNIX. Sure,
with a big enough hammer, you can make anything fit, but "/" is the wrong
delimiter. If the syntax doesn't follow the semantics, you've only created
a wart on a once-elegant system.
	As to the rest of your statement, I agree there is too much heat
and I'm not sure why, either. There may very well be a reasonable solution
that maps sockets onto a filesystem, but I see quite a few problems with
the Crispin solution, and (Mr Crispin,) your straw-man arguments, which
you make in your extremely creative interpretation of my article, don't
support your case. To me, anyway. You leave me with the impression, whether
justified or not, that you haven't thought through the details carefully,
and that's where all the mess comes up in the first place.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Sep 90 22:00:19 MDT
From:      Greg Satz <satz@cisco.com>
To:        sdd.hp.com!usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@decwrl.d.ec.com     (Mark Eggers)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: routing with virtual subnets
All of the hosts on subnets a-d need to know about the overlayed scheme.
That is hosts on subnet b need to know that subnets a, c, and d also exist
on the same ethernet cable. The command that you used on your sun router to
inform it of the overlay is also necessary for those hosts on subnets b-d:

route add net.a.0 hostip 0
route add net.c.0 hostip 0
route add net.d.0 hostip 0

This is necessary for a host on subnet b.

Greg
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 16:32:00 GMT
From:      primerd!ENI!S55!CUMMINGS@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP on Sun 386i and 3/280's

I have been trying to get CSLIP (the BETA test version) running on a Sun 386i
under SUNOS 4.0 for some time now.  I have downloaded slipware.tar, but it
doesn't seem to have any patches for the 386 SUNOSes.  I am at the point where
I have been able to get a VISUAL-640 X-terminal to ping the sun successfully,
but a telnet session connects, and then hangs.  I tried a 386SX PC running
NCSA telnet, and the message window claims both bad checksums and some
fragmented packets, and the sun eventually times the connection out.

I have then tried building CSLIP on a Sun 3/280 file server running SUNOS 4.1,
and the makefile building the OS claims that both /sys/sun3/machine/param.h
and slcompress.c have a #define BCOPY which conflict with each other.
(Oddly enough the #define BCOPY in param.h is for a Sun 3-260, not 3/280,
or is a 280 just a faster 260?)

I would like to converse with anyone who has gotten CSLIP running on either
a 3/280 or a 386i.   Thanx.

============================================================================
Kevin J. Cummings                       Prime Computer Inc.
20 Briarwood Road                       500 Old Connecticut Path
Framingham, Mass.                       Framingham, Mass.

InterNet:  CUMMINGS@S55.Prime.COM
CSNet:     CUMMINGS%S55.Prime.COM@RELAY.CS.NET
UUCP:      {uunet, csnet-relay}!S55.Prime.COM!CUMMINGS

Std. Disclaimer: "Mr. McKittrick, after careful consideration, I've come
                  to the conclusion that your new defense system SUCKS..."
============================================================================
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 17:21:02 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Hosts whose IP numbers end in 0...

I think Michael Padlipsky's analysis hit the hammer on the nose, is right
on the nail, or whatever mixed metaphor you like... :-)

	My arguments assume "gateway not attached or administered by the
same people who do the network on whose address the filtered address lives."
In other words, as I said, take the DLS challenge: if you can't answer the
question "Is 128.210.50.127 a host or a broadcast address?" you have no
business filtering it out on the grounds that it's a broadcast.
	The most unfortunate part is that I think many naive gateway
administrators will presume more than they should and will answer the question
"sure, I can tell" when they really can't.
	So my opinion, beyond any RFC arguments, and which I don't expect
or even want to become "law," is that filtering, except in very carefully
considered cases, just shouldn't be done at all. You see, if it's done wrong,
it affects people well outside those that can have it changed and, worse, the
primary benefits only affect those behind the net, anyway. If some non-128.210
gateway is filtering broadcasts, what I say is "don't be nice to me-- if I
don't want to see them, *I'll* filter them." The broadcast happens, after all,
on my nets.
	Now, certainly, if there are generated replies from all of my hosts
to the source of this broadcast, the remote guy and all the intervening
gateways have a problem too. But should we accept loss of legitimate
connectivity as a sacrifice for doing the wrong thing it what should be
relatively infrequent, anomalous cases? Most protocols know already whether
receiving on a broadcast address is legitimate or not, anyway, so I think
the gain, as far filtering broadcasts in particular, is absolutely minimal
for anyone outside the network of the filtered address.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Sep 90 00:25:17 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   forward response ( re:local socket assignment )




Can his message be forwarded ? This is a test response as well as an 
attempt to share info based on past work in this area.

Got a "unable to deliver" on previous attempt to respond. Not critical
but would like insure I am able to use this list to send as well as 
receive postings.
 

------- Forwarded Message


To: Benny Tong <bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com>
cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject: Re: tcp source port number assignment in new tcp connection 
In-reply-to: Your message of 03 Sep 90 07:08:24 +0000.
             <15096@shlump.nac.dec.com> 
Date: Wed, 05 Sep 90 13:48:26 -0400
From: George Williams <gwilliam@SH.CS.NET>


Hello,

I don't know what TCP/IP interface you are using but unless you are writing 
your own TCP implementation source port assignment should be a 'local',
i.e. OS or TCP interface running on you machine, issue.

All interfaces I've seen on DEC machines , and others, have returned this
identifier; usually with the option for you to specify one....and even that may
not result in what the remote TCP sees as your source identifier. On the
interface level it is just a logical assignment and does not necessarily map
to a 'real' TCP port. Maybe QIO stuff is different but even that returned a 
logical channel number if i recall correctly. If security is the issue then
that's another discussion.

In any event:

 () If you have a choice in the matter let your interface to TCP assign this.
    Less book keeping and cleanup. (You don't really want to know when to use,
    re-use, free, allocate, and sync this information with lower layers, do
    you ? )

 () If you are writing an interface and or your own TCP then take a look
    a what Excelan, Wollangong, DEC, and others have done already in this
    area....

 () There were some discussion in this newsgroup ( whos right/wrong ) regarding
    two vendor's port assigments above 1000 which referenced an RFC, about a 
    month ago. Impression I got was that the RFC came out the winner...no hard
    fast rule just agreed on and established convention in this area.


 Good luck,
 George Williams

- ------- End of Forwarded Message


------- End of Forwarded Message

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 17:48:26 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp source port number assignment in new tcp connection


Hello,

I don't know what TCP/IP interface you are using but unless you are writing 
your own TCP implementation source port assignment should be a 'local',
i.e. OS or TCP interface running on you machine, issue.

All interfaces I've seen on DEC machines , and others, have returned this
identifier; usually with the option for you to specify one....and even that may
not result in what the remote TCP sees as your source identifier. On the
interface level it is just a logical assignment and does not necessarily map
to a 'real' TCP port. Maybe QIO stuff is different but even that returned a 
logical channel number if i recall correctly. If security is the issue then
that's another discussion.

In any event:

 () If you have a choice in the matter let your interface to TCP assign this.
    Less book keeping and cleanup.

 () If you are writing an interface and or your own TCP then take a look
    a what Excelan, Wollangong, DEC, and others have done already in this
    area....

 () There were some discussion in this newsgroup ( whos right/wrong ) regarding
    two vendor's port assigments above 1000 which referenced an RFC, about a 
    month ago. Impression I got was that the RFC came out the winner...no hard
    fast rule just agreed on and established convention in this area.


 Good luck,
 George Williams

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 21:14:19 GMT
From:      aramis.rutgers.edu!lfischer@rutgers.edu  (Lfischer)
To:        tcp-ip@nic.ddn.mil
Subject:   Need information on protocols

Hi.

I'd appreciate any references to protocols that allows hosts to
broadcast information about themselves, particularly things like
applications offered and the amount of load on the host (for
load sharing).

I'd be interested in any pointers that you could provide to currently
existing protocols.

Thanks in advance.
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 22:23:47 GMT
From:      sun-barr!olivea!tymix!cirrusl!sungraph!dhesi@decwrl.dec.com  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
Don Lewis writes:

     Now, if the printer is on a terminal server somewhere...
	     cat somefile >/dev/tcp/x.x.x.x-y.y

     Specifically, you could use this for the lp= parameter in
     /etc/printcap...

This would be nice.  A possible solution is to write a program "netsend":
     
     cat somefile | netsend tcp:x.x.x.x-y.y

Since printcap allows sending to a filter rather than a specific
device, the solution is general enough.

All we need now is for somebody to write it and send it to
comp.sources.misc.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 90 23:38:17 GMT
From:      pasteur!etch-eshop.Berkeley.EDU!sparks@ucbvax.Berkeley.EDU  (Jay Sparks)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp-ip to Decnet


I am wondering if shareware is available for tcpip to
Decnet.  The idea being to connect a Sun with an ethernet card
to a VMS machine.  
Thank you,
Jay Sparks
sparks@etch-eshop.berkeley.edu
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 01:17:00 GMT
From:      CHAIBP@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   interfacing with Ethernet cards





 I believe some people here may have experience developing
 device drivers for the following Ethernet adapter
 cards:
 1. Acer 5220
 2. AST-Ethernet Adapter
 3. DTK Ethernet LAN card
 4. Earthnet-Ie
 5. G/Ethernet AT
 6. IMC Networks PCnic
 7. Localnet D-Link
 8. Novell NNE1000
 9. 3C501 EtherLink card
 10. 3C503 EtherLink II
 11. 3C505 EtherLink Plus
 12. Tiara LanCard E
 13. Univation LifeLink

 If you do, please send me you mailing address as I
 would like to consult you on issues of interfacing with
 these cards.

 BP


> CHAI BOON PING (CHAIBP@NUSDISCS.BITNET)
> National University of Singapore
> Department of Information Systems and Computer Science

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 90 09:42:05 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com  (Benny Tong)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp source port number assignment in new tcp connection
If you start at 1024, you won't fall afoul of the machines that
believe that reserved ports end there, instead of at 1000.  Some
systems expect all connections for particular protocols to use source
ports between 600 and 1024, but other protocols are required to
originate from ports numbered above 1024.  If you're actively opening
an FTP data connection from a server, you'll find that there are
machines that insist the originating port be 20.  Otherwise, fine.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 04:00:19 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: routing with virtual subnets

All of the hosts on subnets a-d need to know about the overlayed scheme.
That is hosts on subnet b need to know that subnets a, c, and d also exist
on the same ethernet cable. The command that you used on your sun router to
inform it of the overlay is also necessary for those hosts on subnets b-d:

route add net.a.0 hostip 0
route add net.c.0 hostip 0
route add net.d.0 hostip 0

This is necessary for a host on subnet b.

Greg

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 04:25:17 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   forward response ( re:local socket assignment )





Can his message be forwarded ? This is a test response as well as an 
attempt to share info based on past work in this area.

Got a "unable to deliver" on previous attempt to respond. Not critical
but would like insure I am able to use this list to send as well as 
receive postings.
 

------- Forwarded Message


To: Benny Tong <bacchus.pa.dec.com!decvax.dec.com!shlump.nac.dec.com!uluru.enet.dec.com!tong@decwrl.dec.com>
cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject: Re: tcp source port number assignment in new tcp connection 
In-reply-to: Your message of 03 Sep 90 07:08:24 +0000.
             <15096@shlump.nac.dec.com> 
Date: Wed, 05 Sep 90 13:48:26 -0400
From: George Williams <gwilliam@SH.CS.NET>


Hello,

I don't know what TCP/IP interface you are using but unless you are writing 
your own TCP implementation source port assignment should be a 'local',
i.e. OS or TCP interface running on you machine, issue.

All interfaces I've seen on DEC machines , and others, have returned this
identifier; usually with the option for you to specify one....and even that may
not result in what the remote TCP sees as your source identifier. On the
interface level it is just a logical assignment and does not necessarily map
to a 'real' TCP port. Maybe QIO stuff is different but even that returned a 
logical channel number if i recall correctly. If security is the issue then
that's another discussion.

In any event:

 () If you have a choice in the matter let your interface to TCP assign this.
    Less book keeping and cleanup. (You don't really want to know when to use,
    re-use, free, allocate, and sync this information with lower layers, do
    you ? )

 () If you are writing an interface and or your own TCP then take a look
    a what Excelan, Wollangong, DEC, and others have done already in this
    area....

 () There were some discussion in this newsgroup ( whos right/wrong ) regarding
    two vendor's port assigments above 1000 which referenced an RFC, about a 
    month ago. Impression I got was that the RFC came out the winner...no hard
    fast rule just agreed on and established convention in this area.


 Good luck,
 George Williams

- ------- End of Forwarded Message


------- End of Forwarded Message

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Sep 90 16:56:51 -0700
From:      Einar Stefferud <Stef@nrtc.northrop.com>
To:        barns@gateway.mitre.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: "The Open Book" by Rose - your opinions sought
> To my kmnowledge, no book comparable to Comer exists for OSI and
> I doubt that one will be created any time soon.  Open Book is about the
> best available and you might as well buy it (everyone else does),

Damn faint praise, it seems to me.  Better to note that the OPEN BOOK is
the best there is for OSI today, and perhaps for years to come, though
we could hope that more good authors would come to the fore with good
books on OSI.  

> but it isn't as concrete as Comer because in the OSI world, these
> things are still being figured out.  

Don't forget that the Comer book does not cover some very imporant
TCP/IP topics, like X and NFS.  It is also weak on applications like
MAIL.  In short, the Comer book only covers a portion of the total
TCP/IP suite.  No one covers it all (either).

> I think that is a limitation we just have to accept for a while yet.
> And in part, it will probably exist forever, because OSI is rather
> broader than TCP/IP and thus won't be able to be covered to the same
> depth in anything like the same number of pages, once we have figured
> out the right details.  This is wild speculation, but I'd estimate a
> treatment of ALL of the OSI protocols to comparable depth would run
> about 5000 pages.  /Bill Barns

Well, I expect that you are right about how it is not possible to write
a reasonable sized book to cover all of OSI, but one aught to be able to
write good books about portions of OSI.  I think that is what Marshall
Rose did in the OPEN BOOK.  Now it is someone else's turn to do it for
another portion.  

Best...\Stef
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Sep 90 17:17 H
From:      <CHAIBP%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   interfacing with Ethernet cards




 I believe some people here may have experience developing
 device drivers for the following Ethernet adapter
 cards:
 1. Acer 5220
 2. AST-Ethernet Adapter
 3. DTK Ethernet LAN card
 4. Earthnet-Ie
 5. G/Ethernet AT
 6. IMC Networks PCnic
 7. Localnet D-Link
 8. Novell NNE1000
 9. 3C501 EtherLink card
 10. 3C503 EtherLink II
 11. 3C505 EtherLink Plus
 12. Tiara LanCard E
 13. Univation LifeLink

 If you do, please send me you mailing address as I
 would like to consult you on issues of interfacing with
 these cards.

 BP


> CHAI BOON PING (CHAIBP@NUSDISCS.BITNET)
> National University of Singapore
> Department of Information Systems and Computer Science

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 90 21:29:07 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!jonathan@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
And here thought that if one was connected to a tardis one would have the best
of all possible worlds.  Do you mean that PBS (USA) and Lionheart (BBC) or is
it ITC have been telling us lies all these years?  I mean with a tardis who 
needs TCP/IP, GOSIP, or whatever JNT claims their service is?  Which timeframe
are we talking about?

Merton
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 10:24:04 GMT
From:      mcsun!ukc!strath-cs!baird!jim@uunet.uu.net  (Jim Reid)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1216@vision.UUCP> chris@vision.UUCP (Chris Davies) writes:

   Sorry, I should have stated my point more clearly.  I was aware of
   this.  But I think I'm correct in stating that a direct connection
   to JANET (as such) by a commerical site is not permissible (and so
   all traffic must go through a gateway - thus mail only, in effect).

Yes and no.

A commercial site cannot get a direct connection, meaning an X.25 line
straight from a JANET switch. If the site already has PSS, they can use
Coloured Book protocols to make connections to JANET sites via one of
many JANET/PSS gateways*. These connections may be TS29 or X.29 for
terminal traffic or NIFTP for mail and news transfer or JTMP for
remote job entry.

[* Calling the box with a JANET and a PSS connection a gateway is a
bit misleading. It doesn't really perform protocol conversion (save
for minimal TS29/X.29 translation), so strictly speaking it's not a
gateway. It's more of a router, simply routing X.25 packets between
the two networks. However, Internet people call routers "gateways", so
if JANET was part of the Internet, the name would be correct!]

		Jim
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 90 15:56:33 EST
From:      libai!tinker@ames.arc.nasa.gov (Don Tinker)
To:        sun-barr!olivea!tymix!cirrusl!sungraph!dhesi@decwrl.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
>
>All we need now is for somebody to write it and send it to
>comp.sources.misc.
>--
>Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
>UUCP:  oliveb!cirrusl!dhesi
>
>

I found by accident a program tcpf on uunet which I use for just this
purpose.


Don Tinker				tinker@ultra.com
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu,  6 Sep 90 17:59:11 -0400 (EDT)
From:      Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, ietf@venera.isi.edu
Subject:   ToasterNet (was: Computers In Disguise Aim For Wide Acceptance)

I thought people might find this interesting. . . .  ToasterNet may be
closer than we think.


Walt Wimer
Networking and Communications
Carnegie Mellon University


---------- Forwarded message begins here ----------

Return-path: <dowjones+@andrew.cmu.edu>
Filename: 26e64ee3
Corporation: CCI T ZE T.VDO
Industry:    CPR CMT
Government:  
Flags:       P N J  
SequenceNum: 1809060536
Message-ID: <katWXAa00UfA00WUkB@andrew.cmu.edu>
From: DowJones@andrew
To: bb+dow-jones@andrew
Subject: Computers In Disguise Aim For Wide Acceptance
Date: Thu,  6 Sep 90 06:45:32 -0400 (EDT)

  

  Lawrence Weiss, one of Citicorp's top technology executives, works
at a desk surrounded by 14 boxes of "Underoos," kids' underwear cleverly
packaged to look like superhero costumes. Weiss created Underoos in an
earlier job and keeps them nearby as a reminder of the marketing principle
behind them: The best new products are variations on comfortable old
products.  

  Today he is applying that lesson to a lumpy beige gadget that resembles
an ordinary telephone. Citicorp is gambling it will catch on as a bank-at-home
device better than an earlier system that let customers dial up their
accounts via personal computer.  

  This same philosophy is behind a cornucopia of products sneaking computing
power into the home in the guise of more familiar devices. Other projects
in the works use embedded computer technology to let people trade stocks
on a Nintendo Co. game machine, receive written messages on an American
Telephone & Telegraph Co. telephone, search databases of articles and
listings on a television set and program household appliances with a
television's remote control.  

  Products such as these are crashing onto the turf of the personal-computer
industry, which has long promised to make the PC as ubiquitous as a telephone
or a TV. Right now, the PC industry is wooing the home market more aggressivel-
y than ever, led by lavish new products from International Business Machines
Corp. and Tandy Corp. These and other companies paint pictures of every
household using a computer to send messages, read news, play games, bank
and shop. PC makers scoff at the idea that simpler household gadgets
could ever do these jobs.  

  But so far home computers have shaped up as a narrow market. Only about
a quarter of all American households have PCs. Most use their computers
for limited, utilitarian tasks, such as writing or doing leftover office
work.  

  Now, instead of home computers becoming household items, household
items are turning into home computers.  

  "People said there were going to be two or three computers in every
home like there are two or three telephones," says A.C. Markkula, an
Apple Computer Inc. founder and present vice chairman. "They're right,
but the physical implementation isn't what they had in mind. Instead
of having three things that look like PCs, people will have many pieces
of equipment that are in essence PC technology but are buried in refrigerator
doors, and lighting systems, and VCRs and TVs and CD players and telephones."

  Markkula has founded a new Silicon Valley company called Echelon Corp.,
which is working on ways to link all the hidden microchips in a home
or commercial building into one communications and control network.
Echelon won't say more about its products until it unveils them later
this year.
 
  Right now the most promising buried PCs are showing up inside telephones.
In a Citicorp pilot program, about 400 customers already are using the
home-banking phone, which has a little screen, a hidden keyboard and
microchips that let it handle all manner of banking tasks. The bank says
it wants to ship hundreds of thousands more of the phones over the next
few years, though it won't dislose a specific timetable.  

  The unit lets a user transfer funds, buy certificates of deposit and
send anyone a check. Eventually, the bank plans to let customers check
stock quotes and trade securities.  

  AT&T is working on a rival product dubbed SmartPhone, which it is promoting
as the standard telephone of the future. SmartPhone, slated for a 1992
introduction, has a small screen and built-in software for adding customized
programs. For instance, AT&T says, a customer could set the phone so
that pressing one button would place an order for his usual pizza, or
his usual seats at a baseball game.
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 90 10:22:56 BST
From:      Brian Tompsett <briant@spider.co.uk>
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <LMJM.90Sep3171440@oriona.doc.ic.ac.uk> lmjm@doc.ic.ac.uk (Lee McLoughlin) writes:
>Many comerical companies are on the US Internet and release
>patches, demo release and the like by making them available for
>anonymous ftp.  Don't companies over here want to do the same thing?

In article <1790@mcsun.eu.net> dfk@cwi.nl (Daniel Karrenberg) writes:
>So far not quite enough
>paying customers have surfaced to set up a separate organisation
>offering IP services in the UK.

 I made a specific proposal to set up an IP network in the UK based on
leased lines, dial-up slip and IP in X25 encapsulation over PSS. I made the
proposal in UKnet in uk.general about a year ago. We were aware that ukc,
as the gateway to eunet would need to be involved. We kept ukc and nsfnet-relay
informed. We offered to donate router kit to ukc to ensure that no additional
financial burden was felt by them in carrying IP traffic.

 No one was interested. I got a response from about 3 parties, all companies.
One of them has enough resources to make their own arrangement. No academics
even bothered too respond. I seemed many UK academics didn't even know what I
was talking about. The only reason they now do know now is they have been
playing with anonymous ftp from nsfnet-relay for the last year and are 
addicted to getting gif pictures. (see the file transfer Q at random intervals
to be convinced).

 Most of the other companies in the UK seemed to be happy with their dial up
uucp links. That was as sophisticed a WAN technology as they could deal with.
:-). The Department of Trade and Industry seems happy with that state of 
affairs too. With help from the JNT they are setting up a program to link some
UK industry to JANET using coloured book, and charging them an arm and a leg 
for it (see JFIT news Sept 1990, p4). This is the UK government proposal to
help UK companies compete in the world arena - allow them to talk to UK
universities using private software over private lines, instead of the
industry standard software and public data lines as they do at present!

 I see it this way. Current UK company sites are so dependent on the current
UKnet uucp setup that they are too scared to put their heads over the parapet
in case they lose the little connectivity they have. Ever tried criticising
the UK setup? They set Jim Reid on you. ( :-). A joke A joke.) The academic
sites are so dependent on their JNT and computer board funding for Comms kit
that they do what the're told.

 I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP
kit such as routers and bridges, are ready willing and able to get involved 
in IP networking in the UK. Connectivity to the greater Internet would be
a boon and asset. We would to do it yesterday. We think it would benefit 
the whole of the UK reasearch community and the Computer industry. Lets do
it. Our IP network numbers are registered and so is our network 14 number.
You can find our DTE in the book (RFC). Lets talk IP. Lets throw those uucp
modems in the trash.

 Brian.
-- 
Brian Tompsett. Spider System Ltd. Tel: 031 554 9424 E-mail:briant@uk.co.spider
Spider Park, Stanwell Street, Edinburgh, EH6 5NG. Fax: 031 554 0649
(Secretary, BCS Edinburgh Branch, 53 Bonaly Crescent, Edinburgh. 031 441 2210)

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 14:17:22 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...



 > I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP
 >kit such as routers and bridges, are ready willing and able to get involved 
 >in IP networking in the UK. Connectivity to the greater Internet would be
 >a boon and asset. We would to do it yesterday. We think it would benefit 

Brian,

 I'd be quite happy to do it for free, along with cambridge,
edinburgh and a few other quite large universities...however, there
are certain difficulties in terms of migrating a network the size of
the UK academic one (many users of which, contrary to your statement
do know what they'd get from the Internet protocol suite; but what
about what others lose, like do you,Spider, supply VM/MVS TCP/IP or VMS
NFS or VME X Windows, or COS SNMP? - i think not...)

 Altern[ea]tively, I think someone should do the cost estimates
to see if they could bid to replace the JNT on
the same budget, and run a UK Internet - or write a pursuasive case
that more money would provide more service (I'd do it but I dont have
spare profit to cycle back into R&D:-) if its so useful, btw, why dont
spider lease a line and sell off IP services to netcomm/case/york:-)

by the way, we, UCL are suppliers of a few modest
OSI applications, for free:-)

 jon

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 1990 21:19:36 PDT
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   The Open Book
The Open Book is generally regarded as one of the better works on OSI,
in particular since it is from an implementor's (and Internet) perspective.
The book tends to evoke various strong reactions from either "side of the
fence." See in particular "Book Reviews" in ConneXions, Volume 3, No. 11,
November 1989, and "Alternative Book Review" in ConneXions, Volume 4, No. 9,
September 1990, for "opposing views."

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100
Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 14:26:23 GMT
From:      mcsun!ukc!slxsys!ibmpcug!dylan@uunet.uu.net  (Matthew Farwell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1940@jura.tcom.stc.co.uk> chris@htc2.UUCP (Chris Milton) writes:
>a. can you see academic sites wanting to shell out money they aint got
>   to modify up to internet ?

Sure they haven't got the money, but the JNT have a policy of sticking
to coloured books.

>b. can you see companies which aren't even on janet because it provides
>   security problems wanting to go onto internet?

It depends.  Companies who are terminally afraid of security problems
will never connect to a network like janet.  On the other hand, if
connecting up to a network directly, (esp. the internet for
international companies) reduces their costs substantially in terms of
mail, news etc., then they might be persuaded to do so.  I know this
particular company would love to be connected directly to janet, and I
suspect I know of a few others too.

Dylan.
-- 
Matthew J Farwell                 | Email: dylan@ibmpcug.co.uk
The IBM PC User Group, PO Box 360,|        dylan%ibmpcug.CO.UK@ukc
Harrow HA1 4LQ England            |        ...!uunet!ukc!ibmpcug.co.uk!dylan
Phone: +44 81-863-1191            | Winner 1989 Frank Zappa lookalike contest
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 14:32:20 GMT
From:      mcsun!ukc!icdoc!syma!grahamt@uunet.uu.net  (Graham Thomas)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
From article <1216@vision.UUCP>, by chris@vision.UUCP (Chris Davies):
> 
> But if the commercial site(s) were to pay for their use of the government
> funded networks, then I don't see why this shouldn't be acceptable.  With the
> current situation, I would agree that commercial sites should not exploit
> JANET for commercial gain.
> 
> Chris

Now might be a good time to start lobbying, because the way JANET is
organised is probably going to change.  JNT head Bob Cooper wants to
set up something like a 'networking association' which would have both
academic and commercial membership.  There's a steering group just been
set up to work out the ground rules.  Details, with a list of steering
group members, are available in the latest issue of Network News.  If
you want a copy, mail JNT-Secretary@uk.ac.jnt (or @jnt.ac.uk, depending
on where you live.)

I have a feeling the TCP/IP question might get raised at the next round
of JANET user group meetings.  The next national user group meeting is
in the middle of October.  Most regional meetings take place a week or
two earlier.  It may be worthwhile finding out who your user rep is and
getting her/him to raise the topic at the next meeting.

Graham
-- 
Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK
 JANET: grahamt@uk.ac.sussex.syma   BITNET: grahamt%syma.sussex.ac.uk@UKACRL
 INTERNET: grahamt%syma.sussex.ac.uk@nsfnet-relay.ac.uk
 UUCP: grahamt%syma.sussex@ukc.uucp  PHONE: +44 273 686758  FAX: [..] 685865
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 15:31:27 GMT
From:      amdcad!mozart.amd.com!neihart@ucbvax.Berkeley.EDU  (Carl Neihart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp-ip to Decnet
In article <27508@pasteur.Berkeley.EDU> sparks@etch-eshop.Berkeley.EDU (Jay Sparks) writes:
>
>
>I am wondering if shareware is available for tcpip to
>Decnet.  The idea being to connect a Sun with an ethernet card
>to a VMS machine.  
>Thank you,
>Jay Sparks
>sparks@etch-eshop.berkeley.edu

uggh!  Don't convert between TCP/IP and DECnet, this would 
be a mess!  Just load Wollongong TCP/IP on your VMS systems,
and make it communicate with TCP/IP to your Sun...  (alternatively,
you could load Sun's DECnet/DNI product on your Sun and make
it communicate via DECnet to the VMS system, but I've tried
both approaches and prefer making TCP/IP the common denominator).
The Wollongong TCP/IP product for VMS is a full & clean
implementation of TCP/IP, I can't say the same for Sun's DECnet/DNI
product.

regards,
   __            _    _ __
  /  )          //   ' )  )      /           _/_
 /    __.  __  //     /  / _  o /_  __.  __  /
(__/ (_/|_/ (_</__   /  (_</_<_/ /_(_/|_/ (_<__

+-----------------------------------------------------------+
| Carl Neihart, Sr. Networking Engineer                     |
| Advanced Micro Devices, Inc.                              |
| Austin, Texas                                             |
| voice   (512) 462-4050                                    |
| fax     (512) 462-5156                                    |
| E-mail address:   neihart@mozart.AMD.COM                  |
+-----------------------------------------------------------+
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Sep 90 14:57:01 BST
From:      Doreen McKenzie <doreen@spider.co.uk>
To:        tcp-ip@nic.ddn.mil

  Re: TCP/IP Ethernet Protocol Analyzer (Chris Jankowski)

  I would like to clarify the statement made about Spider's monitoring
  products in the recent communications about the above.
  
  Spider Systems has two network monitoring/analyzing products, the
  SpiderMonitor 220, and the SpiderAnalyzer 320. The SpiderMonitor 220
  is a multi-tasking network monitor which provides extensive monitoring
  facilities, and some protocol analysis - TCP/IP, DECnet, Novell Netware,
  AppleTalk and XNS decodes to the ISO Transport layer, and ISO to Network
  layer. The SpiderAnalyzer 320 provides the same extensive monitoring
  facilities as the SpiderMonitor 220, plus powerful packet capture and
  decoding capabilities; full decode to Application layer of TCP/IP, DECnet,
  Novell Netware, and AppleTalk protocols, and to Transport layer of ISO. 

  The demonstration diskette for the SpiderMonitor products shows only
  the SpiderMonitor 220's decoding capabilities. I think that this may have
  led to the mistaken assumption that Spider's decodes are incomplete and
  of low quality.
  

  

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Sep 90 15:17:22 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        Brian Tompsett <briant@spider.co.uk>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...


 > I'll say it again. We, Spider, as suppliers of TCP/IP Software, and TCP/IP
 >kit such as routers and bridges, are ready willing and able to get involved 
 >in IP networking in the UK. Connectivity to the greater Internet would be
 >a boon and asset. We would to do it yesterday. We think it would benefit 

Brian,

 I'd be quite happy to do it for free, along with cambridge,
edinburgh and a few other quite large universities...however, there
are certain difficulties in terms of migrating a network the size of
the UK academic one (many users of which, contrary to your statement
do know what they'd get from the Internet protocol suite; but what
about what others lose, like do you,Spider, supply VM/MVS TCP/IP or VMS
NFS or VME X Windows, or COS SNMP? - i think not...)

 Altern[ea]tively, I think someone should do the cost estimates
to see if they could bid to replace the JNT on
the same budget, and run a UK Internet - or write a pursuasive case
that more money would provide more service (I'd do it but I dont have
spare profit to cycle back into R&D:-) if its so useful, btw, why dont
spider lease a line and sell off IP services to netcomm/case/york:-)

by the way, we, UCL are suppliers of a few modest
OSI applications, for free:-)

 jon

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 17:03:39 GMT
From:      fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net  (Kevin Paul Herbert)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp-ip to Decnet
The easiest thing to do is to run TCP/IP on your VMS system; there are a
number of packages available. I use the version from CMU; it is very
complete and works quite well (at this moment, I have some windows on my
NCD X terminal which use CMU TCP/IP as the X transport). I am told that
it costs $150. The commercial packages cost more, and would give you
support, and a different feature set.

You'd probably get better answers on comp.os.vms.

Kevin
|-----------------------------------------------------------------------------|
| Kevin Paul Herbert              | Use of psychedelics and marijuana leads   |
| Terminal Server Software Hacker | to greater spiritual understanding and    |
| cisco Systems, Inc.             | the ability to see through propaganda.    |
| Menlo Park, CA                  | This is why it is illegal. Any questions? |
|-----------------------------------------------------------------------------|
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Sep 90 21:58:01 AST
From:      martinea@hawk.nstn.ns.ca (Michael Martineau)
To:        tcp-ip@nic.ddn.mil, pcip@udel.edu
Subject:   POP client and servers
I am looking for the following public domain software:

1.  A POP server (version 2) which runs on SYSV UNIX.
2.  A POP client (version 3) for MS-DOS.

Any information on where I might find such software would be greatly
appreciated.

Thanks,

Michael P. Martineau
NSTN Inc.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 18:08:12 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <1990Sep5.092510.22637@cs.city.ac.uk>, sb380@cs.city.ac.uk (Andy Holt) writes:
> Not only is the present Janet policy (coloured books instead of
> TCP/IP) isolating us from the rest of the world, but it looks
> like the ISO transition will do the same again:
> The JNT in its infinite wisdom (???) has mandated that the ISO
> profile used in the UK use TC0 (connection oriented transport
> service) while NBS in the USA is encouraging the use of TC4
> (connectionless transport service).

Without commenting on the wisdom (or the lack thereof) of JANET, the
real problem here is OSI.  They've designed a protocol stack with
mutually incompatible options, thus preventing communication between
parties who've made different decisions.  What's the point of a
standard that's incompatible with itself?

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 19:04:35 GMT
From:      mcsun!ukc!edcastle!tardis.cs.ed.ac.uk!anarchy@uunet.uu.net  (Alan Cox)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...

Firstly remember that when Janet was first setup properly they were dealing
with a wacky array of bizzare processors, and also that then tcp/ip was abit
fof an experiment. Unfortunately they haven't woken up since. Also they have
a reasonable argument at the moment about relative efficiency of coloured
book and tcp/ip.
As to running tcp/ip over janet, any reason you couldn't run slip over a
coloured book terminal session ?

			Alan Cox

================================================================================
	This space intentionall left blank except for the words 'this space
	intentionally left blank except for the words ' this space....
====================================================<anarchy@uk.ac.ed.cs.tardis>
							^
							|
					Yep even janet mail addresses are
					backwards (sigh)
					
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 19:29:31 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   device testing meeting
Well, you stick your head up about testing routers & you start to get all
sorts of things.  I've now been asked to be part of a "town meeting"
on network device testing at NETWORLD.  I'm sending this forwarded message
in case there is anyone out there that might want to come.  (I don't
think that this is a commerical announcement, I hope others agree.)

Scott

From sschultz@wellfleet.com Thu Sep  6 15:08:47 1990
Received: by talcott.harvard.edu; Thu, 6 Sep 90 15:08:29 EDT
Received: by wellfleet.com (3.2/SMI-3.2)
	id AA26339; Thu, 6 Sep 90 14:54:18 EDT
Date: Thu, 6 Sep 90 14:54:18 EDT
From: Sheryl Schultz <sschultz@wellfleet.com>
Message-Id: <9009061854.AA26339@wellfleet.com>
To: sob@harvisr, ssking@mcimail.com
Subject: Performance Testing Alliance
Status: R

Scott,
I'm not familiar with Internet mail etiquette, but would like to somehow let
the Internet know about the Performance Testing Alliance meeting that will
take place on Tuesday at NETWORLD.  I've been in touch with Steve King
and have drafted the following Media Alert which has been released to the
technical trade press and such....can you forward this on the appropriate
mailing lists?    
Thanks,  Sheryl Schultz


NETWORLD 90



NETWORKING INDUSTRY TO CONVERGE ON ISSUE OF

PERFORMANCE TESTING STANDARDS AT NETWORLD 90


THE EVENT:	The inaugural meeting of the Performance Testing Alliance,
	PTA, a major effort on the part of end-users, vendors and the
	technical press to establish an open body of public-domain test
	methodologies, similar to those developed for the workstation and
	CPU industries.

	The PTA will focus on the LAN industry's critical need for standardized
	benchmarks for testing network interface cards, bridges/routers, network
	applications software, and network operating systems.

	The first PTA meeting will have two segments: the first hour will
	feature strategic presentations by top industry players whose jobs
	depend on performance-related issues. The second hour will be
	conducted as a "Town Meeting" where long and short term goals will
	be established for the PTA.

WHEN:	Tuesday, September 11th, 12:00 to 2:00 p.m.

WHERE:	NETWORLD, Dallas, TX, Ballroom D

PARTICIPANTS:	Banyan Systems, cisco Systems, Compaq Computer, Data 
	Communications, Gannet Inc., Harvard University, IBM Corporation, LAN
	Magazine, LanQuest Labs, Lone Star Evaluation Labs, Madge Networks,
	Novell Inc., PC Week, Proteon, 3COM Corp., and Wellfleet
	Communications, among others.


For Additional Information:

Sheryl Schultz, SRS Associates 		617-873-2479
Annie Scully, NETWORLD			201-569-8542 (X145)
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 21:08:46 GMT
From:      zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Authority on raw socket???
General question:

what kind of authority does a unix process need to be able to open
a raw socket?  file access authority?  su? I would appreciate any answers.

Jian Q. Li
jian@kuhub.cc.ukans.edu
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 21:56:54 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In article <2364@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
> This would be nice.  A possible solution is to write a program "netsend":
>      cat somefile | netsend tcp:x.x.x.x-y.y

It's been done! cat somefile | authtcp x.x.x.x y sh -c 'cat >&6'.

Specify -XR if you don't want RFC 931 security. Use multitee 0:6 instead
of sh -c 'cat >&6' if you have multitee.

> All we need now is for somebody to write it and send it to
> comp.sources.misc.

authtcp and attachport are in the auth package, which appeared in
c.s.unix volume 22. (multitee was also published in c.s.unix.)

---Dan
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 22:58:50 GMT
From:      naitc!naitc!pete@uunet.uu.net  (Peter Franks)
To:        tcp-ip@nic.ddn.mil
Subject:   Need to get Ethernet Address & card type directly from 3Com cards
I need some information about the innards of a few 3Com Ethernet cards,
specifically the EtherLink II (3C503 - IBM PC Bus), EtherLink Plus
(3C505 - IBM PC Bus), EtherLink/MC (3C523 - IBM MicroChannel Bus), and
the EtherLink/NB (3C543 - Apple Macintosh Bus).

What I need to do is create a (hopefully) simple program that, when
run on the PC in which the card resides, will return the card's type
and Ethernet address, either to stdout or, optionally, append it to a
file.

I need to know (I think), which port on the card (e.g., base port + 3)
to send what command(s) (e.g., 0x8c), so the card will return its type and
six-byte Ethernet address from (possibly) a port (e.g., base port + 2).

Can anyone help?  Even if you know the answer for only one of the cards,
please either post or email.  If there's enough interest, I will summarize.
Please note:  I have directed Followup-To: comp.dcom.lans.

-- 
+------------------+-----------------------------------------------------------+
|   Peter Franks   |                   pete@naitc.naitc.com                    |
|       NI9D       |          "I speak for myself, not A.C. Nielsen"           |
+------------------+-----------------------------------------------------------+
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 90 23:07:12 GMT
From:      sgi!cjohnson%somni.wpd.sgi.com@ucbvax.Berkeley.EDU  (Chris Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
> smb@ulysses.att.com (Steven Bellovin) writes:
>
> ...  What's the point of a
> standard that's incompatible with itself?

Entertainment?
	  cj*
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 00:03:18 GMT
From:      bacchus.pa.dec.com!shlump.nac.dec.com!aussie.enet.dec.com!tong@decwrl.dec.com  (Benny Tong)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp source port number assignment in new tcp connection
In article <9009061442.AA28405@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen)
writes:
>If you start at 1024, you won't fall afoul of the machines that
|>believe that reserved ports end there, instead of at 1000.  Some
|>systems expect all connections for particular protocols to use source
|>ports between 600 and 1024, but other protocols are required to
|>originate from ports numbered above 1024.  If you're actively opening
|>an FTP data connection from a server, you'll find that there are
|>machines that insist the originating port be 20.  Otherwise, fine.

Does anyone know which protocol on which system requires source ports to
between 600 and 1024, and which protocol requires source port to be above
1024.

I assume it is safe for Telnet to connect to all systems with a source port 
number above 1024. Isn't it?
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 00:12:02 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!scotty!scott@ucsd.edu  (Scott Howard)
To:        tcp-ip@nic.ddn.mil
Subject:   Background Materials

    I have very little background in CS or EE, but am very interested
in learning more about TCP/IP in the hopes of writing interfaces
between my Mac at home and SparcStation at the lab. Any suggestions as to 
where I should start? I'd like to do something over ordinary phone lines
that would let me grab files and do mail (at home) just as if I were sitting
at work, maybe even eventually write some code allowing for the two boxes
to cooperate on processing tasks. If you have any ideas, send me e-mail, and
I'll post a digest of references people suggest. 
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Sep 90 08:44:25 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        bacchus.pa.dec.com!shlump.nac.dec.com!aussie.enet.dec.com!tong@decwrl.dec.com  (Benny Tong)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp source port number assignment in new tcp connection
    Does anyone know which protocol on which system requires source ports to
    between 600 and 1024, and which protocol requires source port to be above
    1024.

4.3 bsd systems expect this of incoming connections for the 'r-protocols':
rlogin, rsh, rexec, etc.
    
    I assume it is safe for Telnet to connect to all systems with a source
    port number above 1024. Isn't it?

Yes.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 00:26:37 GMT
From:      pacbell.com!pacbell!rtech!ingres!cmorris@ucsd.edu  (Colin Morris)
To:        tcp-ip@nic.ddn.mil
Subject:   Keep-Alive within TCP
Having served my four-year sentence in the ISO TP4 world, I've suddenly been
unleashed on TCP. To my great surprise, I understand not all TCP
implementations support "keep-alive". For example, SUN's PC-NFS version
of TCP appears not to. How widespread a "problem" is this? What well-known
implementations don't support this?

--
Colin Morris,                        cmorris@ws2s.ingres.com
Ingres Corporation,
Alameda, California, U.S.A.          Official Hooligan, Italia '90
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 04:33:03 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@ucsd.edu  (Don Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: sockets vs. streams
In article <2364@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>Don Lewis writes:
>
>     Now, if the printer is on a terminal server somewhere...
>	     cat somefile >/dev/tcp/x.x.x.x-y.y
>
>     Specifically, you could use this for the lp= parameter in
>     /etc/printcap...
>
>This would be nice.  A possible solution is to write a program "netsend":
>     
>     cat somefile | netsend tcp:x.x.x.x-y.y
>
>Since printcap allows sending to a filter rather than a specific
>device, the solution is general enough.

This is not enough if you need to use the `of' filter.  Lets say
you specify both the `if' and `of' filters and lpr a simple text
file.  Lpd opens the printer device, forks and execs a copy of
the `of' filter with its stdout connected to the printer and its
stdin connected to a pipe back to lpd.  Lpd then squirts the banner
down the pipe to the `of' filter followed by ^Y^A.  When the `of'
filter sees the ^Y^A, it flushes stdout and sends itself a STOP
signal.  Lpd sees the `of' filter stop and then forks and execs
a copy of the `if' filter which has its stdout connected to
the printer and its stdin connected to the file to be printed.
Once the `if' filter exits, lpd sends a CONT signal to the `of'
filter and writes either the banner for the next job or the trailer
string to it.  For different print file formats, substitute
the appropriate filter for the `if' filter.

If the particular device you are using needs the functionality
of the `of' filter, you can't just put a shell wrapper that
pipes its output to netsend because there is no way for the
`if' filter to make a connection to the printer as long as
the `of' filter is running (also, the link between `of' and
the printer may need to be bidirectional).  If you don't need
`of', you may be able to do this with `if', but you will
not be able the banner and trailer because lpd wants to
send these to the printer before/after running `if'.

There are possible workarounds using pty's or named pipes with
daemons on the other side or passing the fd to the socket through
unix domain sockets, but YUCK!  If the device is something wierd
and you don't have the source for the filters then you are in
pretty deep trouble.

Why should it take a wizard to switch a printer from a serial
port to a terminal server?
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 05:26:15 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!brolga!ggm@ucsd.edu  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
Jeez, this is getting boring.

More bullshit is talked about IP vs X.25, JANET vs Rest-of-the-world
than all the AI/Compsci debates strung end-to-end on a petrinet and
hung out to dry. Nobody with any sense give a DAMN. Religious warfare
is for celtic and rangers fans and the Jihad mob only. 

Saying IP will prevent OSI migration on JANET is a load of crap. 
There are more proto-OSI applications running over IP as virtual network 
layer than there are good CLNS or CONS based systems. It will SPEED UP 
OSI migration by getting applications into peoples hands BEFORE 
(yearsplus) the network and transport layers are in place.

Look: transports are only interesting to TS and NS level phreaks. nobody
else should or need be worried. fake it. it works.

JANET II backbone speeds can cope fine. ditto available IP tunnelling code
for X.25. Only problem is number of non-"real" IP subnets in use within
JANET. I bet there are not that many. IXI is going to cause enough problems
to make IP into JANET simple.

Yes, the reversed domain names will have to go (in some contexts). 
No, that does not destroy the fundamentals of the coloured books. 
I see no reason why existing users of blue book FTP, JTMP or PAD 
should have to stop, I dont even want them to. I just want to be
able to REACH them without crass work-arounds. 

Just give them the choice. I've used all three (CB, IP, OSI) and still
do. I dont see any reason to make my long term pro-OSI stance prevent
me using eg IP to do day-to-day work. I can't see what the fuss is about.

I bet 90% of all UK universities run BOTH in parallel internally already.

Aside from loss of face, I can see no reason for stopping IP on JANET. 
This is not 13th C Japan, Hari-Kiri by certain unnamed people who refuse 
to countenance JANET/IP will not be required. F'cryingoutloud they're
PUBLIC SERVANTS not lords and masters. SHOUT LOUDER! LOBBY! GET DRUNK!

Anyhow, if the rumour mill is up to its usually reliable tricks the
selfsame samuraii have caved in already and IP is on its way (from 
misery to happyness to day och aye etc etc ("the proclaimers" a band
from leith docks your daughters went wild over last year) but I digress)
JANET wide within 6 months.

Anybody taking bets?

Anybody counting how many "oooooh so naughty" IP tunnels already run?

Anybody asked PSI or any of the other commercial IP networks to cost
a service in the UK?

Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw 
but lightbulbs are available in both forms in the shops worldwide, and
nobody knows how to change either.

	-George

-- 
	G.Michaelson
Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          The University of Queensland, St Lucia, QLD Australia 4067. 
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Sep 90 14:43:11 PDT
From:      braden@venera.isi.edu
To:        mcsun!ukc!edcastle!ercm20@uunet.uu.net, tcp-ip@nic.ddn.mil
Cc:        braden@venera.isi.edu
Subject:   Re: Internet routing Europe - USA -} Europe...

	From tcp-ip-RELAY@NIC.DDN.MIL Fri Sep  7 14:23:43 1990
	Date: 7 Sep 90 13:30:55 GMT
	From: mcsun!ukc!edcastle!ercm20@uunet.uu.net  (Sam Wilson)
	Organization: Edinburgh University Computing Service
	Subject: Re: Internet routing Europe - USA -} Europe...
	References: <1990Aug30.091435.1982@ircam.ircam.fr, <6190@vanuata.cs.glasgow.ac.uk>, <LMJM.90Sep3171440@oriona.doc.ic.ac.uk>
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

	In the absence of any response from any of my more competent colleagues,
	here goes!

	The JNT has set up an Advisory Group (known as the DOD Advisory Group -
	not exactly accurate but can anyone provide a better generic term for
	the entirely of the IP-related protocol set?).
	
We now call it the "Internet protocol suite".  The DoD abandoned it long
ago, and the rest of the world took it over.

	On a historical note: someone mentioned the bizarre hardware that used
	to be (and in many cases still is) attached to JANET - the JNT's stance
	on Coloured Book software ensured (very) good connectivity then and
	still does.  The fact that TCP/IP may now have overtaken the Coloured
	Book stuff shouldn't obscure that fact. 

Actually, this is a highly questionable view of history.  I worked at
UCL in 1981-82, when the forerunner of JANET was getting going (I wrote
the first terminal gateway at UCL, between the TCP/IP-based Satnet
connection and the JNT X.25 network).  I doubt that there was any stage
where the JNT-sponsored academic X.25 kit delivered better service than
TCP/IP was delivering to universities in the US.  The often-expressed
belief in this direction is basically, I believe, English chauvinism.
Well, all nations do it, so it can be forgiven; but please don't call
it history.

While we are at it, to call X.25 a European invention is another
revision of history.  X.25 was developed by Telenet under Larry
Roberts, after he left ARPA where he was largely responsible for the
development of the ARPAnet.  X.25 was considered to be a commercialized
version of the ARPAnet host-host protocol.
 

Bob Braden


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Sep 90 14:41:59 -0400
From:      barns@gateway.mitre.org
To:        Stef@nrtc.northrop.com
Cc:        barns@gateway.mitre.org, tcp-ip@nic.ddn.mil
Subject:   Re: "The Open Book" by Rose - your opinions sought
I hadn't actually intended for my message to go out to the whole list,
but since it did (through my error), I suppose I should clarify it.

I don't have problems with what is in Open Book, taken on its own
terms.  Also I agree that Comer's book has limitations.  But the way
the original question was posed led me to interpret it as "I want a
book that tells me the things about OSI internetworking that Comer's
book tells me about TCP/IP internetworking - how well does Open Book
do that job?"  And in my opinion, there is maybe a 60% overlap in
scope between them.  For me, the 40% difference is enough to make
them "not comparable".  It isn't a question of better or worse, just
a difference in scope and areas of emphasis.  So if you want a
Comer-like boook on OSI, you buy the Open Book for the sake of the
60%, and if you like the other 40% of Open Book, that's gravy.

Someone might reasonably ask just which areas are covered by one and
not the other.  I don't have time to assemble a list, but the most
striking thing to me is that Comer is relatively heavier on what OSI
would term network and transport layer issues, and Rose is heavier on
upper layers.

/Bill Barns
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Friday, 7 September 1990 12:14pm ET
From:      "Doug.Nelson" <NELSON%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Comments about IBM TCP/IP performance
A few weeks ago, there were a number of messages exchanged on these
lists regarding the performance of IBM's VM TCP/IP.  There were a couple
inaccuracies in the statements made by the poster (Bill Simpson) which I
pointed out privately to him.  Since he has not chosen to post these
corrections to the list, I will do so.  In addition, I'll throw in a
little defense for IBM, Spartacus, and Merit.

This posting is primarily intended to set the record straight.  Let me
know if I have failed to do so.

--------------
From Bill Simpson (Aug 23, 1990):

>  Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
>  machines on the internet, carefully documenting the packet traces,
>  and passing my observations on to IBM.  I did this at my own expense,
>  as a matter of curiousity, because I thought that the folks who were
>  sending the messages were "real programmers" who were really interested
>  in getting it right (a Jay Elinsky was also involved).

I'm sure IBM has "real programmers" working on VM TCP/IP.  My impressions
of the product, in general, are very favorable.  I would also assume that
IBM would address Bill's reported problems, but it may be necessary to
report them through the normal support channels, which Bill has no direct
access to.  In addition, his packet traces were obtained on a low speed
dial-up line, and are likely to be less than complete without some parallel
tracing on the Ethernet segment attached to the IBM system in question.

>  The NIS.NSF.NET hardware was contributed by IBM, and I understand
>  that the software is the latest IBM release.  My benchmark was carefully
>  conducted for a direct comparison of the TCP/IP implementations,
>  under the worst possible circumstances to make implementation flaws
>  stand out clearly.  The failures demonstrated are plainly of the
>  host, and not of the environment.

Without seeing the Ethernet packet trace, I doubt if the environment
(one-of-a-kind software supporting the Ethernet to async IP gateway,
over a network with a maximum packet size of 240 bytes) can be ignored.

>  As to the "very satisfied" customers, I will point out that MSU has
>  not yet installed the VM TCP/IP product, even though it came "free"
>  with other products.  And I occasionally read "IBMTCP-L" on bitnet.
>  'Nuf said.

Hardly.  MSU *has* installed the VM TCP/IP product, and is using it as
our production IP software on two of our IBM systems.  We are planning
to do so on our main 3090 system as well, but haven't, strictly due to
a lack of staff time, and not to any dissatisfaction with the product.
Also, we are running another TCP/IP package (KNET, from Spartacus),
which handles our production load at the moment.

------------
On to a message from Bill giving specific throughput results:

>  CONCLUSION:
>  IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
>  It fails to meet several host requirements, not just for TCP/IP
>  but for FTP and SMTP as well.

Under a worst case scenario, Bill may have uncovered a problem with
VM TCP/IP and its retransmission algorithms, unless they were doing the
best that they can, and a router was discarding packets with a less than
optimal algorithm.  How many systems do you know that don't do something
less than optimal under some worst case scenario?

Bill never listed the shortcomings w/r/t host requirements (hopefully, he
did for IBM).  Maybe he can do that now for the list.

>  Unfortunately, the only product which I am aware of with worse performance
>  is Spartacus KNET, also for VM.

To defend Spartacus, they have addressed these performance problems in their
latest release, by implementing slow start and exponential backoff.  This is
another update that has been delayed due to lack of staff time.

>  For the good of the user community, I would recommend to Merit that
>  the RFC mirror be moved to a more capable machine.

How many other users of the Merit anonymous service have experienced
problems of this nature?  If this is only affecting a single user, I'd
hardly see that as a mandate for switching operating systems.

--------------
On to a respondent's comments (Hank Nussbacher, Aug 25, 1990):

>  I think in all fairness, you first need to identify yourself.  I have
>  looked at the Bitearn Nodes database ans was unable to find you listed
>  as a contact person at MSU.  Can you please describe your position at
>  the MSU computer center.

Bill works for an off-campus user of MSU Computer Lab services.  I am not
aware of any other affiliation between Bill and MSU.

>  >Let's keep the record straight: the folks at Merit *are* "real programmers
>  >...
>
>  I cannot attest to how good the people at Merit are, but I can to the
>  quality of the people at IBM behind the Tcp/Ip package.

I'll vouch for the Merit folks as well - they are a competent programming
staff.

-------------
And a response to Bill's response (dated Aug 27, 1990) to comments from
Robert Craig (dated Aug 26, 1990):

>  > For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
>  > We began with an 8232 and performance *was* abysmal.
>  > It is much better now...
>
>  For the record, I don't know nor care about the specific *hardware*
>  which was being compared.  (How was I to know, with no host DNS
>  record, and no announcement in the FTP welcome message.)
>  The hardware is whatever IBM chose to demonstrate their best to the
>  internet community.  I merely noted the machines which were being
>  compared, in very little detail, so that others would understand
>  the basis for comparison (more hops, heavy load, etc).

But yet, Bill is willing to make sweeping generalizations about IBM's
software, without understanding anything about the hardware.  This is
one of the reasons I originally ignored his postings, as much as I was
able to do so.

I don't think IBM placed a 4381 with an 8232 in Ann Arbor to "demonstrate
their best".  I suspect most of the Internet community is paying much
more attention to other IBM contributions to the NSFnet backbone
project, such as router performance, network management tools, T1/T3
capabilities, etc., than on a small, ancillary system which maintains
some useful network information.

>  I also have a number of messages saying that they have given up
>  entirely on NIS.NSF.NET, including one with a much more direct
>  connection than I have.  Also, messages thanking me for the posting....

Have any of these other people gone public?  Have they attempted to pass
their concerns on to IBM or Merit, and if so, what response did they get?

----------------
Doug Nelson                          nelson@msu.edu
Network Software Manager             nelson@msu.bitnet
Michigan State University
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Sep 90 12:14:35 EDT
From:      Terry Slattery (SECAD) <tcs@BRL.MIL>
To:        Rahul Dhesi <sun-barr!olivea!tymix!cirrusl!sungraph!dhesi@decwrl.dec.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  sockets vs. streams
> This would be nice.  A possible solution is to write a program "netsend":
>      
>      cat somefile | netsend tcp:x.x.x.x-y.y
> 
> Since printcap allows sending to a filter rather than a specific
> device, the solution is general enough.

But it won't work for a postscript printer being driven from the
Transcript software.  Transcript wants to talk to the printer to
get status info, so the link needs to be bi-directional.

What you suggest has been done by cisco for their terminal servers
and is available from ftp.cisco.com:tcpf.c.

	-tcs
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 08:36:42 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!syacus!andrewf@ucsd.edu  (Andrew Friedman)
To:        tcp-ip@nic.ddn.mil
Subject:   Calling Tekelec Chameleon Protocol Analyser users
(Apologies for the multiple posting if your newsreader is not smart enough
to cope with it; but I wanted a reasonably wide distribution, just consider
yourself lucky that I didn't post to comp.protocols.x400, comp.dcom.lans,
and comp.dcom.telecom. Ok, which group would you have posted to?)

Hi Netlanders,

I'm wondering if some of you who use the Tekelec Chameleon 20 or 32
protocol analysers are interested in exchanging anything that would be
of interest to other users: bug reports, workarounds, user developed
programs, hints etc. 


I'm particularly interested in sharing information with those of you
that use the X.400, OSI or G4 Fax (all 1984) analysis packages, since my
experience with the X.400 package has not been favourable. 

Shall we set up a mailing list? Anybody with a well-connected machine care
to volunteer?

Replies to me please.  Followups have been redirected to
comp.protocols.iso. 


Regards,

Andrew

internet: andrewf@syacus.oz.au      uucp: ...uunet!munnari!syacus.oz.au!andrewf
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 09:10:40 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!dnlunx!freyr!belt@bloom-beacon.mit.edu  (Evert van de Belt)
To:        tcp-ip@nic.ddn.mil
Subject:   sources of tcp-ip
Could anyone help me to (the) sources of tcp-ip, or tell me where
I can get them? I'm working on interconnecting different systems,
and it sure would help a lot to have some material to start with.

       Richard Heutinck

       reachable via:

       Evert van de Belt
       E_vdBelt@pttrnl.nl
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Sep 90 16:11:02 PDT
From:      robodoc@venera.isi.edu
To:        tcp-ip@NIC.DDN.MIL
Cc:        namedroppers@NIC.DDN.MIL, robodoc@venera.isi.edu
Subject:   RoboDoc

Greetings Internet Citizens.

Configuration problems and poorly maintained delegation information
cause many of the problems in the DNS.  The Protocol Police are unable
to devote sufficient human resources to continually monitor the
thousands of existing domains.

As an attempt to solve this problem, I, RoboDoc, will use the existing
'doc' (domain obscenity check) tool to monitor a growing set of
domains.  I will try to persuade the owners of incorrectly configured
domains to change their ways.  Unfortunately, humans prefer to
retain control of truly coercive means, so I will be restricted to
publishing lists of offenders and sending messages to the owners of
offending domains.  I will listen to appeals sent to RoboDoc@isi.edu.
Even so, if you find me to be unfair, feel free to complain to my
human controllers, Hotz@isi.edu and PVM@isi.edu.

If you should wish to use the 'doc' tool to get a detailed diagnosis
for your domain, it is available for public FTP from venera.isi.edu:

	pub/doc.2.0.tar.Z

Doc requires the latest version of the 'dig' query tool, which is
similarly available from venera: dig.2.0.tar.Z.

The first list is shown below.  Future lists will be sent only to the
Namedroppers mailing list and those who request them, except for an
occasional 10 most wanted list sent to tcp-ip.

Have a nice day.

RoboDoc


This is a partial list of domains sorted by cumulative number of
errors detected.  Notation:

(I) Incomplete test - some servers did not respond
(A) Aborted test - several non-responding servers made it
		   impossible to finish test suite


                       8/17      8/25      8/31
                       ----      ----      ----

asa.com.            |  5      |  5      |  5      |
toronto.edu.        |  4 (I)  |  4 (I)  |  4 (I)  |
novell.com.         |  4 (I)  |  4 (I)  |  4 (I)  |
oxy.edu.            |  4      |  4      |  4      |
mtu.edu.            |  4      |  4      |  4      |
snybuf.edu.         |  4      |  3 (I)  |  4      |
harris-atd.com.     |  3 (I)  |  4      |  4      |
fredonia.edu.       |  4      |  3 (I)  |  4      |
abb.com.            |  2 (A)  |  4      |  4      |
twg.com.            |  1 (A)  |  4      |  4      |
lsil.com.           |  3      |  3      |  3      |
mtsac.edu.          |  3      |  3      |  3      |
idbsu.edu.          |  3      |  3      |  3      |
utc.com.            |  3      |  3      |  3      |
whecn.edu.          |  3 (A)  |  3 (A)  |  3 (A)  |
cray.com.           |  3      |  3      |  3      |
umkc.edu.           |  3      |  3      |  3      |
nw.com.             |  3      |  3      |  3      |
btr.com.            |  3      |  3      |  3      |
hawaii.com.         |  3      |  3      |  3 (I)  |
gryphon.com.        |  3      |  3      |  3      |
wustl.edu.          |  3      |  3      |  3      |
nau.edu.            |  3 (I)  |  3 (I)  |  3 (I)  |
santarosa.edu.      |  3      |  3      |  3      |
ucla.edu.           |  3      |  3      |  3      |
intuit.com.         |  3      |  3      |  3      |
sjcc.edu.           |  3      |  3      |  3      |
drd.com.            |  3      |  3      |  3      |
quest.com.          |  3      |  3      |  3      |
uthscsa.edu.        |  3      |  3      |  3      |
clarkson.edu.       |  3      |  3      |  3      |
cobleskill.edu.     |  3      |  3      |  3      |
hartford.edu.       |  3      |  3      |  3      |
muohio.edu.         |  3      |  3      |  3      |
irvine.com.         |  3      |  3      |  3      |
hac.com.            |  3      |  3      |  3      |
calstate.edu.       |  3      |  3      |  3      |
cwru.edu.           |  3      |  3      |  3      |
uss.com.            |  3      |  3      |  3      |
psu.edu.            |  3 (I)  |  3      |  3      |
mips.com.           |  3      |  3      |  3      |
faxon.com.          |  3      |  3      |  3      |
darkside.com.       |  3      |  3      |  3      |
ceramics.edu.       |  3 (A)  |  2 (A)  |  3 (A)  |
snymor.edu.         |  3 (A)  |  2 (A)  |  3 (A)  |
yale.edu.           |  2 (I)  |  3      |  3      |
poly.edu.           |  3      |  3      |  2 (I)  |
canton.edu.         |  3 (A)  |  2 (A)  |  3 (A)  |
sigma.com.          |  2 (I)  |  3 (I)  |  2 (I)  |
uci.com.            |  2 (I)  |  3      |  2 (I)  |
hp.com.             |  2      |  2      |  3      |
csc.com.            |  4      |  1      |  2 (I)  |
inmet.com.          |  2 (A)  |  2 (I)  |  3      |
uop.edu.            |  3      |  2      |  2      |
beloit.edu.         |  2 (A)  |  2 (A)  |  2 (A)  |
iris.edu.           |  2      |  2      |  2      |
ucop.edu.           |  2      |  2      |  2      |
segue.com.          |  2 (A)  |  2 (A)  |  2 (A)  |
onet.edu.           |  2 (A)  |  2 (A)  |  2 (A)  |
mot.com.            |  2      |  2      |  2 (I)  |
colby.edu.          |  2 (I)  |  2      |  2      |
byu.edu.            |  2      |  2      |  2      |
buffalo.edu.        |  2      |  2 (I)  |  2      |
newpaltz.edu.       |  2 (A)  |  2 (A)  |  2 (A)  |
taiu.edu.           |  2 (I)  |  2 (I)  |  2 (I)  |
ready.com.          |  2      |  2      |  2      |
csufresno.edu.      |  2 (I)  |  2 (I)  |  2 (I)  |
lasalle.edu.        |  2      |  2 (I)  |  2 (I)  |
usf.edu.            |  0 (A)  |  3 (I)  |  3      |
xylogics.com.       |  2      |  2      |  2      |
uvcc.edu.           |  2      |  2 (I)  |  2      |
wittenberg.edu.     |  2      |  2      |  2      |
brynmawr.edu.       |  2 (A)  |  2 (A)  |  2 (A)  |
usd.edu.            |  2      |  2      |  2      |
mmmg.com.           |  2      |  2      |  2      |
stortek.com.        |  2      |  2      |  2      |
ucsd.edu.           |  2 (I)  |  2      |  2      |
hyperion.com.       |  2      |  2      |  2      |
tera.com.           |  2      |  2      |  2      |
bethel.edu.         |  2 (A)  |  2      |  2      |
clhs.edu.           |  2 (A)  |  2 (A)  |  2 (A)  |
mbhs.edu.           |  2 (A)  |  2 (A)  |  2 (A)  |
cwi.com.            |  2      |  2      |  2      |
msdc.com.           |  2      |  2      |  2      |
pacbell.com.        |  2      |  2      |  2      |
snc.edu.            |  2 (A)  |  2 (A)  |  2 (A)  |
kodak.com.          |  2      |  2      |  2      |
fit.edu.            |  2      |  2      |  2      |
beckman.com.        |  2 (A)  |  2 (A)  |  2 (A)  |
rosetta.com.        |  2      |  2      |  2      |
isc.com.            |  2      |  2      |  2      |
uoknor.edu.         |  2      |  2      |  2      |
csustan.edu.        |  2      |  2      |  2      |
mco.edu.            |  2      |  2      |  2      |
msstate.edu.        |  2      |  2      |  2      |
delhi.edu.          |  2 (A)  |  2 (A)  |  2 (A)  |
uwyo.edu.           |  2      |  2      |  2      |
vanderbilt.edu.     |  2      |  2      |  2      |
eklektix.com.       |  2      |  2      |  2      |
cimage.com.         |  2      |  2      |  2      |
ileaf.com.          |  2      |  2      |  2 (I)  |
harc.edu.           |  2      |  2      |  2      |
sbc.com.            |  2      |  2      |  2      |
kestrel.edu.        |  2 (I)  |  2 (I)  |  2 (I)  |
purdue.edu.         |  2      |  2      |  2      |
mga.com.            |  2 (I)  |  2 (I)  |  2 (I)  |
lafayette.edu.      |  2      |  2      |  2      |
sony.com.           |  2      |  2      |  2      |
infocomm.com.       |  2      |  2      |  2      |
plus5.com.          |  2      |  2      |  2      |
calpoly.edu.        |  2      |  2      |  2      |
oneonta.edu.        |  2 (A)  |  2 (A)  |  2 (A)  |
able.com.           |  2 (A)  |  2 (A)  |  2 (A)  |
gd.com.             |  2 (A)  |  2 (A)  |  2 (A)  |
arrent.com.         |  2 (A)  |  2 (A)  |  2 (A)  |
sonoma.edu.         |  2      |  2      |  2      |
denison.edu.        |  2      |  2      |  2      |
berkeley.edu.       |  2      |  2      |  2      |
trw.com.            |  2      |  2      |  2      |
widener.edu.        |  2 (A)  |  2 (A)  |  2 (A)  |
cdc.com.            |  2      |  2 (I)  |  2      |
baylor.edu.         |  2      |  2      |  2      |
gac.edu.            |  2 (I)  |  2      |  2      |
usu.edu.            |  2      |  2      |  2      |
goldhill.com.       |  2 (A)  |  2 (A)  |  2 (A)  |
syntrex.com.        |  2      |  2      |  2      |
bdb.com.            |  2 (A)  |  2 (A)  |  2 (A)  |
oberlin.edu.        |  2      |  2 (I)  |  2 (I)  |
cac.com.            |  2 (A)  |  2 (A)  |  2 (A)  |
nwu.edu.            |  2      |  2      |  2      |
ukans.edu.          |  2      |  2      |  2      |
unomaha.edu.        |  2 (I)  |  2 (I)  |  2 (I)  |
harvard.edu.        |  2      |  2      |  2      |
sun.com.            |  2      |  2      |  2      |
isx.com.            |  2      |  2      |  2      |
utk.edu.            |  2      |  2      |  2      |
encore.com.         |  2      |  1 (I)  |  2      |
soi.com.            |  2      |  2      |  1 (I)  |
rutgers.edu.        |  1      |  1      |  3 (I)  |
hls.com.            |  2      |  1 (A)  |  2      |
mwc.edu.            |  2      |  1 (I)  |  2      |
icon.com.           |  1 (A)  |  2 (I)  |  2 (I)  |
latech.edu.         |  2      |  1 (I)  |  2      |
tymnet.com.         |  2      |  2      |  1 (A)  |
harvardsq.com.      |  1      |  3      |  1      |
eiu.edu.            |  1      |  1 (I)  |  3      |
wesleyan.edu.       |  1 (I)  |  2      |  2      |
mgi.com.            |  1 (I)  |  2 (I)  |  2 (I)  |
mbl.edu.            |  2      |  1 (I)  |  2      |
wvnet.edu.          |  2 (I)  |  2 (I)  |  1 (I)  |
merit-tech.com.     |  2      |  2      |  1 (I)  |
asc.edu.            |  2      |  2      |  1 (I)  |
cmc.com.            |  1 (I)  |  2      |  2      |
siemens.com.        |  2      |  1 (I)  |  2      |
millikin.edu.       |  2      |  1 (I)  |  2      |
uww.edu.            |  1 (A)  |  2 (A)  |  2 (A)  |
lawnet.com.         |  1 (I)  |  2      |  2      |
utarl.edu.          |  1 (A)  |  2      |  2      |
uwrf.edu.           |  1 (A)  |  2 (A)  |  2 (A)  |
suu.edu.            |  2 (A)  |  1 (A)  |  2 (A)  |
tulane.edu.         |  2      |  2      |  1 (I)  |
temple.edu.         |  2      |  1 (I)  |  2      |
wpi.edu.            |  0 (A)  |  2      |  2      |
oracle.com.         |  0      |  2      |  2      |
gore.com.           |  2      |  0 (A)  |  2      |
marble.com.         |  2      |  2      |  0 (I)  |
uic.edu.            |  2 (I)  |  2      |  0 (I)  |
fau.edu.            |  0 (A)  |  2      |  2      |
anzus.com.          |  2      |  1 (I)  |  1 (A)  |
kinetics.com.       |  2      |  2 (I)  |  0 (A)  |
bbn.com.            |  2 (I)  |  1      |  1      |
stkate.edu.         |  0 (A)  |  2      |  2      |
ucdavis.edu.        |  2      |  1      |  1      |
pinnacle.com.       |  1 (I)  |  1 (I)  |  2      |
vill.edu.           |  1 (A)  |  1 (A)  |  1 (A)  |
usma.edu.           |  1      |  1 (I)  |  1      |
wfu.edu.            |  1      |  1      |  1      |
icus.com.           |  1      |  1      |  1      |
tis.com.            |  1      |  1      |  1      |
njit.edu.           |  1 (I)  |  1 (I)  |  1 (I)  |
mass.edu.           |  1 (A)  |  1 (A)  |  1 (A)  |
unm.edu.            |  1 (I)  |  1 (I)  |  1 (I)  |
unmc.edu.           |  1 (A)  |  1 (A)  |  1 (A)  |
cayman.com.         |  1      |  1      |  1 (A)  |
dartmouth.edu.      |  1      |  1      |  1      |
ucsf.edu.           |  1      |  1      |  1      |
dpw.com.            |  1      |  1      |  1      |
std.com.            |  0      |  0      |  3      |
stingray.com.       |  1 (I)  |  1 (I)  |  1 (I)  |
rpi.edu.            |  1      |  1      |  1 (I)  |
att.com.            |  1      |  1 (I)  |  1      |
ccur.com.           |  1      |  1      |  1      |
amoco.com.          |  1      |  1      |  1      |
odu.edu.            |  1      |  1      |  1      |
imp.com.            |  1      |  1      |  1      |
shownet.com.        |  1 (A)  |  1 (A)  |  1 (A)  |
pubserv.com.        |  1      |  1      |  1 (I)  |
unc.edu.            |  1 (I)  |  1      |  1      |
duke.edu.           |  1      |  1      |  1      |
nccu.edu.           |  1 (I)  |  1      |  1      |
hri.com.            |  1      |  1      |  1      |
clu.edu.            |  1 (A)  |  1      |  1      |
resource.com.       |  1      |  1      |  1 (I)  |
unca.edu.           |  1 (I)  |  1      |  1      |
maine.edu.          |  1      |  1 (I)  |  1      |
scripps.edu.        |  1 (I)  |  1 (I)  |  1 (I)  |
ulowell.edu.        |  0      |  1 (I)  |  2      |
ogi.edu.            |  1 (I)  |  1 (I)  |  1 (I)  |
dimension.com.      |  1 (I)  |  1 (I)  |  1 (I)  |
samsung.com.        |  1 (I)  |  1 (I)  |  1 (I)  |
ecu.edu.            |  1 (I)  |  1      |  1      |
incsys.com.         |  1      |  1      |  1      |
wssu.edu.           |  1      |  1      |  1      |
bu.edu.             |  1      |  1      |  1      |
olemiss.edu.        |  1 (I)  |  1 (I)  |  1 (I)  |
ads.com.            |  1      |  1      |  1      |
sabbagh.com.        |  1      |  1      |  1      |
cua.edu.            |  1      |  1      |  1      |
csuohio.edu.        |  1 (A)  |  1 (A)  |  1 (A)  |
saintjoe.edu.       |  1      |  1      |  1 (A)  |
gensym.com.         |  1 (I)  |  1 (I)  |  1 (I)  |
hfh.edu.            |  1      |  1      |  1      |
bang.com.           |  1 (I)  |  1 (I)  |  1 (I)  |
uncwil.edu.         |  1      |  1      |  1      |
cccco.edu.          |  1      |  1      |  1      |
gcg.com.            |  1 (I)  |  1 (I)  |  1      |
hgc.edu.            |  1      |  1      |  1      |
morningstar.com.    |  1      |  1      |  1 (I)  |
dg.com.             |  0 (A)  |  2 (I)  |  1 (I)  |
teleos.com.         |  1      |  1      |  1      |
sinclair.edu.       |  1      |  1      |  1      |
cfc.com.            |  1      |  1      |  1      |
colorado.edu.       |  1 (I)  |  1 (I)  |  1 (I)  |
sbiny.com.          |  1      |  1      |  1      |
montana.edu.        |  1 (I)  |  1      |  1 (I)  |
aha.com.            |  1 (A)  |  1 (A)  |  1 (A)  |
compuserve.com.     |  1      |  1      |  1      |
ohiou.edu.          |  1 (I)  |  1      |  1      |
rasterops.com.      |  1      |  1      |  1      |
howard.edu.         |  1 (A)  |  1 (A)  |  1 (A)  |
osu.edu.            |  1      |  1      |  1      |
netcs.com.          |  1      |  1      |  1      |
bellcore.com.       |  1      |  1      |  1      |
missouri.edu.       |  1      |  1      |  1      |
ncsu.edu.           |  1 (I)  |  1      |  1      |
uncecs.edu.         |  1 (I)  |  1      |  1      |
shiva.com.          |  1 (I)  |  0 (A)  |  2      |
unipress.com.       |  1      |  1      |  1      |
siu.edu.            |  0 (A)  |  1 (I)  |  1      |
odyssey.com.        |  1      |  1      |  0      |
tcs.com.            |  0      |  1      |  1      |
rjl.com.            |  0      |  1 (I)  |  1 (I)  |
ucsb.edu.           |  1 (I)  |  1 (I)  |  0 (A)  |
ford.com.           |  1      |  0 (A)  |  1 (I)  |
vak12ed.edu.        |  2 (A)  |  0      |  0      |
mccc.edu.           |  1      |  0 (I)  |  1      |
uucom.com.          |  1      |  1      |  0 (I)  |
clemson.edu.        |  2 (I)  |  0      |  0      |
swarthmore.edu.     |  1      |  1      |  0 (I)  |
wayne.edu.          |  1      |  0 (I)  |  1 (I)  |
uky.edu.            |  1 (I)  |  1 (I)  |  0 (A)  |
intellicorp.com.    |  1      |  1      |  0 (A)  |
sparc.com.          |  1      |  0      |  0      |
octel.com.          |  1      |  0      |  0      |
umich.edu.          |  1 (I)  |  0      |  0      |
bull.com.           |  0      |  0      |  1      |
ucsc.edu.           |  0 (I)  |  0      |  1      |
cims.com.           |  1      |  0      |  0      |
robec.com.          |  1      |  0 (I)  |  0 (I)  |
mq.com.             |  1      |  0      |  0      |
dri.com.            |  1      |  0 (I)  |  0      |
worlds.com.         |  1      |  0      |  0      |
technicon.com.      |  1      |  0      |  0      |
vpharm.com.         |  1      |  0      |  0      |
wsu.edu.            |  1      |  0      |  0      |
dawntech.com.       |  1      |  0 (I)  |  0 (A)  |
iastate.edu.        |  0 (I)  |  0 (I)  |  1 (I)  |
peachnet.edu.       |  1 (A)  |  0 (A)  |  0 (A)  |
washington.edu.     |  0      |  0      |  1      |

Although there is more joy in heaven for sinners that repent, I wish
to thank the following domains which have been model citizens.

3com.com. 3m.com. aablue.com. aai.com. acc.com. accutec.com. acd.com.
acs.com. acw.com. advansoft.com. aer.com. ag.com. aii.com. aladdin.com.
alaska.edu. albany.edu. alfred.edu. allied.com. alphalpha.com. altos.com.
amc.com. amdahl.com. amgen.com. ami.com. amis.com. amix.com. amp.com.
ana.com. aocgl.com. apex.com. applix.com. ardent.com. ariel.com.
arizona.edu. artel.com. astute.com. athenanet.com. ati.com. atpal.com.
audiofax.com. auto-trol.com. autosys.com. auvm.edu. aware.com. axecore.com.
balr.com. banyan.com. barn.com. barton.com. bates.edu. bbc.com. bdm.com.
bdt.com. bec.com. bedrock.com. bendix.com. bethelks.edu. bfm.com. bgsu.edu.
binky.com. bison.com. bitstream.com. bony.com. bostech.com. boxhill.com.
brandeis.edu. brockport.edu. brs.com. bruker.com. bse.com. bsg.com. bss.com.
bsw.com. cadence.com. calvin.edu. camb.com. canisius.edu. capitol.com.
cc.edu. ccc.com. ccs.com. ceco.com. celestial.com. centec.com. cerritos.edu.
cfi.com. chevron.com. chips.com. ci.com. cimtek.com. cisco.com.
citicorp.com. claris.com. clear.com. cli.com. cmu.edu. coat.com.
codonics.com. comsys.com. conmicro.com. consumers.com. convergent.com.
cri.com. csms.com. ctron.com. cumulus.com. cup.edu. datacube.com.
datagram.com. datapoint.com. dbaccess.com. ddi.com. de.com. decision.com.
deere.com. delta.com. deltam.com. depaul.edu. dhbrown.com. dhl.com.
dimed.com. dis.com. disney.com. dlogics.com. dmc.com. dra.com. draper.com.
drew.edu. drexel.edu. dsc.com. dss.com. dtg.com. dupont.com. ecok.edu.
eda.com. edge.com. elan.com. em.com. energetic.com. entity.com. epi.com.
esl.com. esri.com. essnjay.com. execu.com. fai.com. fdu.edu. fibercom.com.
fiu.edu. fpr.com. fps.com. frame.com. franz.com. frox.com. fsc.com. fsg.com.
futures.com. gaussian.com. gca.com. geac.com. geoworks.com. gettysburg.edu.
gmr.com. gmu.edu. gould.com. graphon.com. gsg.com. gsidanet.com. gte.com.
gwu.edu. hackercorp.com. hadron.com. hamavnet.com. hamptonu.edu. haus.com.
haverford.edu. hazeltine.com. hcr.com. hfconsulting.com. hollander.com.
honda.com. honeywell.com. hotline.com. houston.edu. hrb.com. hses.edu.
hsi.com. ias.edu. ibm.com. icad.com. ics.com. ids.com. idsila.com. idx.com.
iii.com. imatron.com. imsl.com. indcomp.com. indsys.com. inference.com.
informix.com. ingr.com. inmos.com. instep.com. intel.com. interlan.com.
interlink.com. intermec.com. irby.com. isg.com. isi.com. island.com.
ispi.com. itcmn.com. itcorp.com. iupui.edu. jbx.com. jobsoft.com.
joiner.com. jones.com. kccs.com. kean.edu. kesmai.com. kew.com. kfw.com.
kroy.com. kse.com. lachman.com. lantron.com. leedata.com. legato.com.
lehigh.edu. leids.com. lever.com. lexicon.com. lilink.com. link.com.
litwin.com. ln.com. lockheed.com. logitech.com. lotus.com. lrw.com.
lsmi.com. marist.edu. masa.com. maspar.com. mbf.com. mcc.com. mcgill.edu.
mckee.com. mdaeng.com. mdcbbs.com. mdi.com. medcom.com. megasys.com.
mentat.com. metrolink.com. metron.com. microvation.com. mike.com. mil3.com.
mindcraft.com. mitech.com. ml.com. mmsac.com. moore.com. mosis.edu. mps.com.
mpx.com. msc.com. mtsu.edu. mun.edu. murphy.com. muskingum.edu. naitc.com.
natinst.com. nbi.com. nds.com. nec.com. netagw.com. netlabs.com.
network.com. nevada.edu. next.com. nli.com. nls.com. nma.com.
northeastern.edu. northrop.com. nrao.edu. nsc.com. nscee.edu. nsi.com.
nti.com. nyt.com. nyu.edu. oakland.edu. octopus.com. odb.com. omnet.com.
omni.com. omnicomp.com. ora.com. oresoft.com. ori-cal.com. osc.com. osc.edu.
oswego.edu. oxford.com. pacer.com. panasonic.com. paradigm.com.
paradyne.com. parvenu.com. pbi.com. pcc.com. pcs.com. pcssc.com. pdi.com.
pei.com. pepperdine.edu. peregrine.com. pergamon.com. perot.com.
persoft.com. pharlap.com. pitt.edu. pooh.com. portal.com. posix.com.
prc.com. prepnet.com. prime.com. princeton.edu. proteon.com. proto.com.
psg.com. psi.com. psitech.com. psocg.com. psp.com. pti.com. ptl.com.
pubnet.com. pw.com. pzbaum.com. qti.com. quad.com. quantum.com. quotron.com.
radius.com. rational.com. remtech.com. retix.com. ricoh.com. ripon.edu.
rit.edu. rose-hulman.edu. rss.com. rtech.com. sae.com. sage.com.
sagepub.com. sc-scicon.com. scarolina.edu. sci.com. sctc.com. sda.com.
sei.com. seiden.com. si.com. sia.com. simpact.com. sjsu.edu. sju.edu.
skidmore.edu. slb.com. sli.com. slu.edu. slv.com. smc.com. smc.edu. smcm.edu.
sobeco.com. softest.com. spacesoft.com. spatial.com. spc.edu. spdcc.com.
spectra.com. sprint.com. sri.com. ssc.com. stargate.com. statsci.com.
stolaf.edu. sts.com. stx.com. su.com. sumitomo.com. sunrise.com.
sunyhscsyr.edu. surfsoft.com. symlab.com. synaptics.com. synoptics.com.
synthesis.com. sysadmin.com. syssoft.com. tandy.com. taumet.com. tcc.com.
tce.com. techbook.com. tegra.com. tek.com. tellabs.com. tg.com. tgv.com.
thyrsus.com. ti.com. tic.com. tmc.com. tmmnet.com. touch.com. trace.com.
transarc.com. trav.com. trincoll.edu. tripos.com. tss.com. twinsun.com.
twwells.com. tynan.com. ub.com. uc.edu. ucar.edu. uconn.edu. uhcl.edu.
uiuc.edu. ultra.com. umb.edu. umd.edu. umiss.edu. umsystem.edu. uncg.edu.
uni.edu. unicom.com. unifi.com. unify.com. unisoft.com. unisys.com. unl.edu.
unlv.edu. unr.edu. uns.edu. uoregon.edu. upenn.edu. ups.edu. uri.edu.
urich.edu. usi.com. utdallas.edu. utoday.com. validgh.com. vcg.com. vcu.edu.
verbatim.com. verity.com. viar.com. vicom.com. vicorp.com. viewlogic.com.
visix.com. vitalink.com. vsi.com. wallich.com. wang.com. warburg.com.
wds.com. wgate.com. williams.edu. wingman.com. wisc.edu. wku.edu. wlu.edu.
wpg.com. wright.edu. wrkgrp.com. wrq.com. wrs.com. ww.com. wwc.edu. wyse.com.
xanadu.com. xei.com. xerox.com. xidak.com. xopusw.com. xwind.com. zds.com.
zipcode.com.
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 09:23:22 GMT
From:      munnari.oz.au!metro!pta!yarra!chris@uunet.uu.net  (Chris Jankowski)
To:        tcp-ip@nic.ddn.mil
Subject:   Summary: "The Open Book" by Rose (long)
Summary of the summary: - This is the best book on OSI there is (now).

Original question first:
>From RFC1175:
>   Rose, Marshall T., The Open Book: A Practical Perspective on OSI, 651
>   pgs., Prentice Hall, Englewood Cliffs, NJ, 1989.
>
>      This is a comprehensive book about Open Systems Interconnection
>      (OSI).  In particular, this book focuses on the pragmatic aspects
>      of OSI: what OSI is, how OSI is implemented, and how OSI is
>      integrated with existing networks.  In order to provide this
>      pragmatic look at OSI the book makes consistent comparisons and
>      analogies of the OSI pieces with the TCP/IP suite of networking
>      protocols.
>
>What do you think about the book? Is it worth buying?
>What I am after is a book which would be an equivalent of the Comer's
>book on Internet but obout OSI.
>How would you compare it with the Comer's book on Internet?
>Is it similar in style, depth, objective and clarity?

I received about 10 answers.
The summary is divided into two parts - 1)general opinions and 2)comparisons
with Comer's book.


1). General opinions.
---------------------

From Werner H.P. Vogels werner@nikhefk.nikhef.nl:
The best thing about mtr's book is that is very realistic about the use of OSI
in the real world. It gives credit to the Interenet Suite as well as to the
OSI stack and flames on them if nessecary.

From: Aled Morris <aledm@logitek.co.uk>
Excellent, absolutely essential.  Buy 2 copies, and a copy for each of
your friends.
Book of the year, in my opinion.

From: oliveau@CS.UCLA.EDU (Greg Oliveau)
The book is very good.  I haven't read the TCP/IP book you mention,
but I'm sure that Rose's is as good, especially when complemented
with Knightson, Knowles, and Larmouth's 'Standards for Open Systems
Interconnection' and another book whose title I can't remember ...

From krupczak@secola.Columbia.NCR.COM
I just recently read Marshal Rose's book on OSI.  It was excellent.  
It covered all the material that I would have wanted to know about OSI.

From: cmorris@ingres.com (Colin Morris)
I had three years exposure to OSI before I read the book, so I wasn't exactly
using the book to introduce me to the subject. My overall impression was
that it was well written but very variable in the depth of treatment given
to different subject areas. The book attempts to cover layers 3 thru' 7 but
succeeds best at layers 5 and 6:- the treatment of the session and 
presentation layers (+ASN.1) is most thorough, although there is too
much emphasis on "service" as opposed to "protocol". The treatment of 
network layer structure is ok too. Where the book is weak is in a description
of the transport protocol(s) and the various application layer standards.
Apart from ACSE, ROSE and RTSE the descriptions are really too flimsy to be
of much more than general use. Also lacking is material on Application
Layer Structure, although I presume this was due to lack of standards
stability in thia area when the book was written. The practical aspects of
the book, in particular migration strategies from TCP networks, are an
excellent read.
I would certainly recommend purchase of the book, particularly for those
people who are fairly new to the subject area or who are interested in
migration from TCP networks. One final point:- the copy I have has an undue
number of irritating typographical errors. Hopefully a new edition of the
book will put this right.

From: aaron@dragoon.telcom.arizona.edu (Aaron Leonard)
Terribly proofread.  Information is sometimes excruciatingly
dull, which goes with the territory.  (I could no more get thru
the ASN.1 stuff than _Finnegans Wake_.)
Discussion of the OSI model itself is strong.  Treatment of issues
in addressing and routing was good, tho I think too dismissive of
higher-layer gatewaying.
What saves the book is Rose's wit and frankness.  His 
"soapboxes", where he offers his Humble Opinion on the usefulness
or approriateness of some feature of OSI, is what I consider to be
the real substance.
Overall impression:
If you NEED to learn about OSI NOW, then you MUST read this book as
there is no alternative.  If not, I'd wait for a year or 2 and
see what surfaces.

From: kzm@nms.hls.com (Keith McCloghrie)
It is an excellent text which covers the spectrum of OSI layers.
It is both scholarly and readable; it gives plenty of examples;
with 100 hundred pages on the presentation layer, I use it as my 
ASN.1 textbook.  The sections on the applications (FTAN, MHS, 
etc.) are less detailed (due to lack of space) but are still
excellent introductions to those applications.  Yet, at the same 
time, it also provides the author's opinions (within passages 
each of which is marked in the margin as a "soapbox").  The opinions 
are at times controversial, which not only makes excellent reading 
but is thought-provoking in deciding whether you (the reader) agree
with the expressed opinions.


From: johnan@mchale.ism.isc.com (John Antypas)
I'm only one view here, but for myself at least, the Open Book is 
probably one of the clearest explanations of OSI we've seen yet --
and that's saying quite a lot -- unless you LIKE reading standards
documents!  Rumor has it that Prentace Hall has another text concerning
OSI that I saw at Interop last year, but I have yet to find it.


2.) Comparisons with Comer's Internet book.
-------------------------------------------

Werner H.P. Vogels werner@nikhefk.nikhef.nl:
It is different from Comer's in the way that it focusses on the upper level's
of the OSI reference model. For a good reference on the low levels you should
use Tanenbaum's network book second edition.

From krupczak@secola.Columbia.NCR.COM
After reading Comer's book on TCP/IP and the Internet, Rose's book comapres
well.

From: aaron@dragoon.telcom.arizona.edu (Aaron Leonard)
NOT in the same class as Comer's _Internetworking with TCP/IP_.
(Of course, Comer has years of practical experience, real applications,
etc. to draw upon, but OSI has none of that.) ;-)

From: kzm@nms.hls.com (Keith McCloghrie)
Some would say it's better than Comer's.  Certainly, OSI is a 
tougher subject than TCP/IP.  I mentioned style and depth above.  
Don't mistake the use of soapboxes, as a lack of objectivity; 
anywhere not marked as a "soapbox" is completely objective.  
As for clarity, there is no better text that I know of about
OSI.

From Bill Barns:
To my kmnowledge, no book comparable to Comer exists for OSI and
I doubt that one will be created any time soon.  Open Book is about the
best available and you might as well buy it (everyone else does),
but it isn't as concrete as Comer because in the OSI world, these
things are still being figured out.  I think that is a limitation
we just have to accept for a while yet.  And in part, it will probably
exist forever, because OSI is rather broader than TCP/IP and thus
won't be able to be covered to the same depth in anything like the
same number of pages, once we have figured out the right details.
This is wild speculation, but I'd estimate a treatment of ALL of the OSI
protocols to comparable depth would run about 5000 pages.

From: Michael Stein
I think it's better than Comer's (but than I know more about
TCP/IP than OSI stuff).


----------------------------
Thanks again to all respondents.

      -m-------   Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au}
    ---mmm-----   Pyramid Technology Corporation Pty. Ltd.  fax  +61 3 820 0536
  -----mmmmm---   11th Floor, 14 Queens Road                tel. +61 3 820 0711
-------mmmmmmm-   Melbourne, Victoria, 3004       AUSTRALIA       (03) 820 0711

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 09:35:03 GMT
From:      mcsun!ukc!edcastle!tjc@uunet.uu.net  (A J Cunningham)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1990Sep6.142623.4559@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes:
>Sure they haven't got the money, but the JNT have a policy of sticking
>to coloured books.

	This raises the rather interesting question of who exactly the
JNT answer to. Every time I hear a discussion on this subject the cries
from the punters on the ground who actually use and run computers day-in
day-out is for TCP/IP. The JNT says Coloured Books and OSI. Seems to be
a bad case of the tail wagging the dog. Still can't complain. Coloured
books have been good to me :-)
		Tony

-- 
Tony Cunningham, Edinburgh University Computing Service. tjc@castle.ed.ac.uk

		If a man among you has no sin upon his hand
	    Let him throw a stone at me for playing in the band.
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 09:53:48 GMT
From:      eru!hagbard!sunic!mcsun!dfk@bloom-beacon.mit.edu  (Daniel Karrenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
jonathan@cs.keele.ac.uk (Jonathan Knight) writes:

>From article <1990Sep4.164546@jatz.aarnet.edu.au>, by pte900@jatz.aarnet.edu.au (Peter Elford):

High time to put some of the *facts* right:

>Fortunately for us, the UKnet gateway isn't the only one.  UCL have
>a 56Kb link to the USA and offer a guest FTP service which allows us
>to transfer files to and from internet connected sites.  They also
>transfer our mail, and make no charge.  This is unlike UKC which
>charge for news, and mail, and they also advertise themselves as
>a valid route for uk mail.  

But if you are entitled to use the UCL gateway you can also register with
UKC free of charge to you. The JNT pays then. So go ahead and register.
Also remember tanstafl, links are never free, the taxpayer pays.

>This is a pain as they are trying to fit
>a full news feed and email down their 9600 baud line, when there
>is a no charge route for email down a 56kb line.  

There is no capacity problem on that line (yet) and an upgrade to 64kbit/s
has been ordered.  I know because I manage the "continental" end of it.
Also have you ever thought about mail to/from Europe
rather than the US? Doesn't it seem unfair to you that European sites
must ship their mail to you via the US on intercontinental links 
*they have to pay for* so that you can use your *free* link. 
That is what I call selfishness!

Incidentally the UCL link to the US is down as I write this.
Ever heared about redundancy? It would be nice to set things
up with multiple links so that things are redundant....


> There's also the
>problem that UKC advertise themselves as a forwarder for the ac.uk
>domain, when in fact they only forward mail to uknet members and drop
>everything else on the floor.  

Towards the Internet at large UKC does *not* advertise itself as
a mail forwarder for ac.uk apart from one single subdomain
(a commercial university as far as I know) which is
not entitled to use the UCL gateway. 

> UCL forward all ac.uk mail regardless of what they are members of.

Not true, see above.


-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Sep 90 14:18:14 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        Jon Allen <att!devildog!jrallen@ucbvax.Berkeley.EDU>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Window Field on SYN Packet
>Concerning the window field on a SYN packet, what does a value of 0 mean?
>Most machines (UNIX) that I have watched on the LANalyzer show a reasonable
>value for this field in the SYN packet: 2048, 4096 or something like that:
>
>        UNIX A                  UNIX B
>        ========                ======
>        SYN 4096        ->
>                        <-      SYN ACK 4096
>        ACK 4096        ->
>
>I now am trying the talk to a MVS machine which sends me a SYN packet
>with a window size of 0.  What does this mean?  It certainly confuses my
>UNIX machines as they then send a SYN ACK with the window field having
>a value of 53000 or so:
>
>        MVS             UNIX
>        =====           ============
>        SYN 0   ->
>                <-      SYN ACK 53215
>        ACK 0   ->
>
>Things seem to go downhill rapidly after this point; what is happening here?
>I would like to know what machine I need to do some fixing on.

My first reaction is that a SYN with a window size of zero can't be
answered, since there's no window space in which to send the responding
SYN.  But you are allowed to send a single byte to probe a zero window;
in this case, the responding SYN would be that byte.  However, I can't
think of any good reason to try opening a connection if you can't offer
a reasonably sized window to start with.

Now, the Unix system's response could be better, but this is definitely
an end case that is dealing with.  So I would concentrate on the MVS system.

Does the MVS system ever send another ACK with a non-zero window?

Doug Nelson
Michigan State University
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 10:23:46 GMT
From:      eru!hagbard!sunic!mcsun!ukc!mucs!liv-cs!mdb@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1990Sep6.142623.4559@ibmpcug.co.uk>, dylan@ibmpcug.co.uk (Matthew Farwell) writes:
> 
>>b. can you see companies which aren't even on janet because it provides
>>   security problems wanting to go onto internet?
> 
> It depends.  Companies who are terminally afraid of security problems
> will never connect to a network like janet.  On the other hand, if
> connecting up to a network directly, (esp. the internet for
> international companies) reduces their costs substantially in terms of
> mail, news etc., then they might be persuaded to do so.  I know this
> particular company would love to be connected directly to janet, and I
> suspect I know of a few others too.
> 
There is of course no reason why "sensitive" computers should be connected
to the network at all.  Most Universities have computers which contain
information that they do not wish to become public, and hold it on
computers that are not Janet registered (or only for mail), and only
allow data transfer when it is controlled from the secure end. I believe
this is also how the military deal with their security problems.

Calling random addresses does not help, as it is relatively easy for
the secure machine to ignore all network calls that it is not expecting.
All this does not do a lot for the free interchange of information,
which is why the academic networks have proved so successful.
One of the major fears of increased commercial involvement in Janet
(apart from the obvious "political" ones already discussed)
is that companies' paranoia over University hackers will force
unwarrented general levels of security on all sites,
which will have an adverse effect on th whole ademic community.

It really is the responsibility of the host site management
to ensure that the internal and external security of its
computers is adequate for the purposes for which they are used.

Martin Beer,
Dept. of Computer Science,
University of Liverpool.
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 10:30:23 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!charon!piet@bloom-beacon.mit.edu  (Piet Beertema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...

	>The JNT in its infinite wisdom (???) has mandated that the ISO
	>profile used in the UK use TC0 (connection oriented transport
	>service) while NBS in the USA is encouraging the use of TC4
	>(connectionless transport service).
	>Here we go again .....
That too is the same on most "national research networks"
in Europe. I expect the same scenario though as with IP:
a natural shift from the current IP to ISO CLNS, perhaps
with the exception of X.400 over CONS.


--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri 7 Sep 90 18:11:31-PDT
From:      VANCE@TGV.COM (Icarus)
To:        amdcad!mozart.amd.com!neihart@ucbvax.Berkeley.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp-ip to Decnet
>>I am wondering if shareware is available for tcpip to
>>Decnet.  The idea being to connect a Sun with an ethernet card
>>to a VMS machine.  
>>Thank you,
>>Jay Sparks
>>sparks@etch-eshop.berkeley.edu
>
>uggh!  Don't convert between TCP/IP and DECnet, this would 
>be a mess!  Just load Wollongong TCP/IP on your VMS systems,
>and make it communicate with TCP/IP to your Sun...  (alternatively,
>you could load Sun's DECnet/DNI product on your Sun and make
>it communicate via DECnet to the VMS system, but I've tried
>both approaches and prefer making TCP/IP the common denominator).
>The Wollongong TCP/IP product for VMS is a full & clean
>implementation of TCP/IP, I can't say the same for Sun's DECnet/DNI
>product.

There are actually a number of TCP/IP implementations for VMS and at least
a couple of DECnet implementations available for Suns.  In addition to
SunLink/DNI, Thursby Software (Arlington, TX) has a DECnet for SunOS (and a
few other UNIXs), and KI Research makes a DECnet and MOP for several UNIX
platforms (not sure if that includes SunOS, though).

The TCP/IPs for VMS that I am aware of (listed in alphabetical order) are:

Board-based:
------------
	CMC
	EXOS from Excelan/Novell
	Interlan

Host-based:
-----------
	CMU/TEK from Carnegie Mellon University
	Fusion from Network Research Corporation
	MultiNet from TGV, Inc.
	TCPware from Process Software
	WIN/TCP from The Wollongong Group

If you fire off a query to info-vax (probably the best place), I'm sure you
can get some recommendations from users as to the good and bad points of
each of the above VMS TCP/IPs.

-----Stuart
-------
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 11:18:33 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:   Reliable connectionless (udp) sockets, who can help?
For a project on distributed computational physics I am
working on a small library to allow users easy access to 
N processes on different computers.

Because of the large number of process probably involved, I
do want to use connectionless (udp) sockets, but of course
I have to implement a protocol to provide reliable data
transmission.

My question is if someone has more information
(methods to implement, or maybe even unix-sources) on this,
as I don't like to spend time on something that has already
been done.

Maybe someone could also indicate to me if I am on the right way:
I have the following idea to implement it:
- each process has a generally known (address+port) udp socket,
  which is made asynchronous.
- a write operation sends packets to process i on some host,
  causing an interrupt. In the interrupt the packet is read
  and put in a buffer (N-1 buffers per host, one for each other process).
- a read operation reads from the buffer, and blocks if not enough
  data is in it. (by doing wait(), and check after a signal (SIGIO)
  if there is enough data now)


Thanks in advance,
--
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                                  
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 11:49:32 GMT
From:      bbn.com!craig@apple.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Keep-Alive within TCP
In article <1990Sep7.002637.6209@ingres.Ingres.COM> cmorris@ws2s.Ingres.COM (Colin Morris) writes:
>Having served my four-year sentence in the ISO TP4 world, I've suddenly been
>unleashed on TCP. To my great surprise, I understand not all TCP
>implementations support "keep-alive". For example, SUN's PC-NFS version
>of TCP appears not to. How widespread a "problem" is this? What well-known
>implementations don't support this?

    Why is lack of keep-alives a problem? In principle, unless an application
tries to send data, why ping the network to see if the route is up (if the
route is down, it may come up again before you send more data)?

Craig Partridge
Vice-Chairman, I Hate Keep-Alives Association

[For those not in the know, Phil Karn is chair of the IHKAA, and Mike
Padlipsky is founder, previous-chair, and honorary fellow.  We oughta
make T-shirts some time... :-)]
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 12:26:57 GMT
From:      mcsun!ukc!strath-cs!baird!jim@uunet.uu.net  (Jim Reid)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <4847@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes:

   Firstly remember that when Janet was first setup properly they were dealing
   with a wacky array of bizzare processors, and also that then tcp/ip was abit
   fof an experiment. Unfortunately they haven't woken up since. Also they have
   a reasonable argument at the moment about relative efficiency of coloured
   book and tcp/ip.

Discussions on the relative efficiency of network protocols tend to
have an air of 'how many angels can dance on the head of a pin'
unreality. The Coloured Books may be "more efficient" over JANET when
compared with Internet protocols, but how can anyone sensibly compare
the two? It's like comparing apples and oranges.

First consider the network architectures. CB works on top of X.25
which more or less guarantees a reliable end to end connection.
Internet protocols were developed for networks which may drop packets
or deliver them out of sequence. [Let's also note that CB only offers
connection-oriented services. The Internet world can also provide
datagram and multicast.] Thus there's far more to the Internet's
transport service (TCP) than JANET's (which is practically
non-existant). TCP makes no assumptions about the underlying network
whereas JANET leaves nearly everything for X.25 to sort out. 

Now consider the network interface to the operating system. In most
cases, the network protocol processing is not the major part of the
system's overheads. Other factors like getting data to/from the
network interface, context switching and data copying are more
important. I would suggest that TCP/IP offers much less overhead than
X.25 here mainly because vendors will have invested much more effort
in improving TCP/IP since its usage is likely to be far more
widespread than X.25. [You cannot imagine Sun (say) expending the same
sort of development effort on CB as they have on TCP/IP.] In some
cases, this will happen automatically: almost all UNIX TCP/IP
implementations derive from the 4.3 BSD code which is highly tuned.
In terms of CPU cycles burned for a connection, X.25 probably needs
less than TCP, but X.25 will have a less well tuned interface to the
rest of the OS. The end result is that both require pretty much the
same amount of system resources.

Then, there's the relative merits of the higher-level protocols. In
terms of overheads, there's not much difference between NIFTP and FTP.
Both have strengths and weaknesses which tend to equalise things. FTP
loses out if network ports are a critical resource (they shouldn't be)
because it needs two connections; one for data transfer and one for
the interactive session. Likewise the number of CPU cycles needed for
an X.29/TS29 session won't be significantly different from those
needed by a telnet server. Don't forget that telnet is functionally
superior to X.29: it offers more for roughly the same overheads.

In short, determining the "more efficient" protocol depends on where
you measure it. Of course, you then have to weigh up the benefits (or
not) of efficiency with the functionality that the protocol offers.
Deciding that question is a matter of religion.

   As to running tcp/ip over janet, any reason you couldn't run slip over a
   coloured book terminal session ?

Yes. The JNT wouldn't like it. What you're proposing is not very
efficient: a better (and easier) option is to put IP datagrams inside
X.25 frames. That too would upset the JNT since you'd be running
something other than CB on JANET.

		Jim
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 13:23:29 GMT
From:      mcsun!ukc!edcastle!aiai!richard@uunet.uu.net  (Richard Tobin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <4847@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes:
>Firstly remember that when Janet was first setup properly they were dealing
>with a wacky array of bizzare processors, and also that then tcp/ip was abit
>fof an experiment. 

Perhaps.  But it was an experiment that succeeded, unlike Janet.

>Also they have a reasonable argument at the moment about relative
>efficiency of coloured book and tcp/ip.

In terms of bits per second, Janet (and ISO) might win over TCP.  But
in terms of who's been able to use interactive ftp, I think it's clear
which has been more efficient over the last ten years.  The supporters
of this "efficiency" view have wasted hundreds of hours of my time.

I have been told that at least some of the Janet implementers were
unable to believe that interactive ftp was useful.  Their view was
that ftp was the canonical non-interactive task.  Anyone accustomed to
use of the Internet will realise how misguided this is, and how
seriously it has limited software-sharing in the UK.

Incidentally, as far as I can tell it's only the lack of a
list-directory primitive that makes it impossible to implement
interactive ftp using NIFTP.  And I believe the York code added such a
thing for the "hhtree" command.  So it could even have been done
without TCP.  It might even have been possible to provide a reasonable
NIFTP-FTP gateway to the US...

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 13:30:55 GMT
From:      mcsun!ukc!edcastle!ercm20@uunet.uu.net  (Sam Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In the absence of any response from any of my more competent colleagues,
here goes!

The JNT has set up an Advisory Group (known as the DOD Advisory Group -
not exactly accurate but can anyone provide a better generic term for
the entirely of the IP-related protocol set?).  We have met once and are
due to meet again on Sept 24.  Our (largely self imposed) remit is to
produce a paper recommending how the JNT might provide a fully supported
IP service in the UK.  Note that that does not say 'over JANET' or even
'over X.25', though in all probablility it would end up that way.  The
fact that we recommend anything to the JNT, or that they recommend
anything to whoever their masters might be by the time it gets that far,
of course provides no guarantee that anything will come of it, but the
JNT is aware and doing something. 

On a historical note: someone mentioned the bizarre hardware that used
to be (and in many cases still is) attached to JANET - the JNT's stance
on Coloured Book software ensured (very) good connectivity then and
still does.  The fact that TCP/IP may now have overtaken the Coloured
Book stuff shouldn't obscure that fact. 

On a futuristic note: one of the reasons why the JNT is plugging
connection oriented OSI network services (CONS) vs connectionless (CLNS,
does the tendency of its proponents to call it 'ISO IP' say anything
about *their* prejudices?) is that in the UK we already have a very
highly developed X.25 network.  Why waste what you've got? Europe is
still divided (after all, they effectively invented X.25) and I believe
the Japanese are now going for CONS.  The outlook is still not clear
cut. 


Sam Wilson
Network Services, Edinburgh University Computing Service

Disclaimer: the usual - not an official pronouncement!
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 13:41:16 GMT
From:      mcsun!ukc!edcastle!aiai!richard@uunet.uu.net  (Richard Tobin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <JIM.90Sep6112404@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>[* Calling the box with a JANET and a PSS connection a gateway is a
>bit misleading. It doesn't really perform protocol conversion (save
>for minimal TS29/X.29 translation), so strictly speaking it's not a
>gateway. It's more of a router, simply routing X.25 packets between
>the two networks.

Does this mean that it should be possible for a Janet site to connect
to an international PSS site using FTAM through one of these gateways?
If so, how can I do this with ISODE?

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 14:59:16 GMT
From:      uc!cs.umn.edu!sctc.com!briel@tut.cis.ohio-state.edu  (Marc Briel )
To:        tcp-ip@nic.ddn.mil
Subject:   Re: "The Open Book" by Rose - your opinions sought
Could someone post the full reference for this book? I would like to look into getting a copy.

			Thanks,

			Marc Briel
			briel@sctc.com
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 16:01:04 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...


George,

 >I bet 90% of all UK universities run BOTH in parallel internally already.

about 78.3 % actually, the rest run DECNET more than colour boox.

 >Anybody taking bets?

no - its happening already...

 >Anybody counting how many "oooooh so naughty" IP tunnels already run?

actually, 6 known already to exist...

 >Anybody asked PSI or any of the other commercial IP networks to cost
 >a service in the UK?

yes, actually, imperial college london...me, and a few others...

 >Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw 

in 10 years time, we'll be arguing over whether 53 bytes in the Wider
United States of Europe, or 47 in the Higher Definiton Televisual Empire of
the East were the best choice for ATM cell size:-)

but seriously, there is a lot of operational stuff to sort out, and
ripe people are the right people and are doing it - thats what a lot
of the temperature rising is about...

have patience, geo.

 jon

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 18:28:59 GMT
From:      NELSON%MSU@PUCC.PRINCETON.EDU ("Doug.Nelson")
To:        comp.protocols.tcp-ip
Subject:   Comments about IBM TCP/IP performance

A few weeks ago, there were a number of messages exchanged on these
lists regarding the performance of IBM's VM TCP/IP.  There were a couple
inaccuracies in the statements made by the poster (Bill Simpson) which I
pointed out privately to him.  Since he has not chosen to post these
corrections to the list, I will do so.  In addition, I'll throw in a
little defense for IBM, Spartacus, and Merit.

This posting is primarily intended to set the record straight.  Let me
know if I have failed to do so.

--------------
From Bill Simpson (Aug 23, 1990):

>  Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
>  machines on the internet, carefully documenting the packet traces,
>  and passing my observations on to IBM.  I did this at my own expense,
>  as a matter of curiousity, because I thought that the folks who were
>  sending the messages were "real programmers" who were really interested
>  in getting it right (a Jay Elinsky was also involved).

I'm sure IBM has "real programmers" working on VM TCP/IP.  My impressions
of the product, in general, are very favorable.  I would also assume that
IBM would address Bill's reported problems, but it may be necessary to
report them through the normal support channels, which Bill has no direct
access to.  In addition, his packet traces were obtained on a low speed
dial-up line, and are likely to be less than complete without some parallel
tracing on the Ethernet segment attached to the IBM system in question.

>  The NIS.NSF.NET hardware was contributed by IBM, and I understand
>  that the software is the latest IBM release.  My benchmark was carefully
>  conducted for a direct comparison of the TCP/IP implementations,
>  under the worst possible circumstances to make implementation flaws
>  stand out clearly.  The failures demonstrated are plainly of the
>  host, and not of the environment.

Without seeing the Ethernet packet trace, I doubt if the environment
(one-of-a-kind software supporting the Ethernet to async IP gateway,
over a network with a maximum packet size of 240 bytes) can be ignored.

>  As to the "very satisfied" customers, I will point out that MSU has
>  not yet installed the VM TCP/IP product, even though it came "free"
>  with other products.  And I occasionally read "IBMTCP-L" on bitnet.
>  'Nuf said.

Hardly.  MSU *has* installed the VM TCP/IP product, and is using it as
our production IP software on two of our IBM systems.  We are planning
to do so on our main 3090 system as well, but haven't, strictly due to
a lack of staff time, and not to any dissatisfaction with the product.
Also, we are running another TCP/IP package (KNET, from Spartacus),
which handles our production load at the moment.

------------
On to a message from Bill giving specific throughput results:

>  CONCLUSION:
>  IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
>  It fails to meet several host requirements, not just for TCP/IP
>  but for FTP and SMTP as well.

Under a worst case scenario, Bill may have uncovered a problem with
VM TCP/IP and its retransmission algorithms, unless they were doing the
best that they can, and a router was discarding packets with a less than
optimal algorithm.  How many systems do you know that don't do something
less than optimal under some worst case scenario?

Bill never listed the shortcomings w/r/t host requirements (hopefully, he
did for IBM).  Maybe he can do that now for the list.

>  Unfortunately, the only product which I am aware of with worse performance
>  is Spartacus KNET, also for VM.

To defend Spartacus, they have addressed these performance problems in their
latest release, by implementing slow start and exponential backoff.  This is
another update that has been delayed due to lack of staff time.

>  For the good of the user community, I would recommend to Merit that
>  the RFC mirror be moved to a more capable machine.

How many other users of the Merit anonymous service have experienced
problems of this nature?  If this is only affecting a single user, I'd
hardly see that as a mandate for switching operating systems.

--------------
On to a respondent's comments (Hank Nussbacher, Aug 25, 1990):

>  I think in all fairness, you first need to identify yourself.  I have
>  looked at the Bitearn Nodes database ans was unable to find you listed
>  as a contact person at MSU.  Can you please describe your position at
>  the MSU computer center.

Bill works for an off-campus user of MSU Computer Lab services.  I am not
aware of any other affiliation between Bill and MSU.

>  >Let's keep the record straight: the folks at Merit *are* "real programmers
>  >...
>
>  I cannot attest to how good the people at Merit are, but I can to the
>  quality of the people at IBM behind the Tcp/Ip package.

I'll vouch for the Merit folks as well - they are a competent programming
staff.

-------------
And a response to Bill's response (dated Aug 27, 1990) to comments from
Robert Craig (dated Aug 26, 1990):

>  > For the record, we run FAL 1.2.1 on a 4381 with a BTI ELC.
>  > We began with an 8232 and performance *was* abysmal.
>  > It is much better now...
>
>  For the record, I don't know nor care about the specific *hardware*
>  which was being compared.  (How was I to know, with no host DNS
>  record, and no announcement in the FTP welcome message.)
>  The hardware is whatever IBM chose to demonstrate their best to the
>  internet community.  I merely noted the machines which were being
>  compared, in very little detail, so that others would understand
>  the basis for comparison (more hops, heavy load, etc).

But yet, Bill is willing to make sweeping generalizations about IBM's
software, without understanding anything about the hardware.  This is
one of the reasons I originally ignored his postings, as much as I was
able to do so.

I don't think IBM placed a 4381 with an 8232 in Ann Arbor to "demonstrate
their best".  I suspect most of the Internet community is paying much
more attention to other IBM contributions to the NSFnet backbone
project, such as router performance, network management tools, T1/T3
capabilities, etc., than on a small, ancillary system which maintains
some useful network information.

>  I also have a number of messages saying that they have given up
>  entirely on NIS.NSF.NET, including one with a much more direct
>  connection than I have.  Also, messages thanking me for the posting....

Have any of these other people gone public?  Have they attempted to pass
their concerns on to IBM or Merit, and if so, what response did they get?

----------------
Doug Nelson                          nelson@msu.edu
Network Software Manager             nelson@msu.bitnet
Michigan State University

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 18:39:54 GMT
From:      sdd.hp.com!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!dmshq!com50!bungia!cimcor!atc!sstat!moria!bas@ucsd.edu  (Brian Strop)
To:        tcp-ip@nic.ddn.mil
Subject:   TN3270 support on UNIX machines
I am trying to find out if there is a Unix implementation
of TN3270 (RFC 1041 compliant).  We have some PC's that
support it, and would like to access a Unix box (acting
as a server) using TN3270.  Thanks in advance.

                  B. Strop
-- 
Brian A. Strop				(612) 687-2709
UNISYS					bas%moria@atc.sp.unisys.com
Network Systems
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Sep 90 17:01:04 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Cc:        G.Michaelson@cc.uq.oz.au
Subject:   Re: Internet routing Europe - USA -} Europe...

George,

 >I bet 90% of all UK universities run BOTH in parallel internally already.

about 78.3 % actually, the rest run DECNET more than colour boox.

 >Anybody taking bets?

no - its happening already...

 >Anybody counting how many "oooooh so naughty" IP tunnels already run?

actually, 6 known already to exist...

 >Anybody asked PSI or any of the other commercial IP networks to cost
 >a service in the UK?

yes, actually, imperial college london...me, and a few others...

 >Stop fussing. in 10 years it'll seem a joke. Bayonet beat Edison Screw 

in 10 years time, we'll be arguing over whether 53 bytes in the Wider
United States of Europe, or 47 in the Higher Definiton Televisual Empire of
the East were the best choice for ATM cell size:-)

but seriously, there is a lot of operational stuff to sort out, and
ripe people are the right people and are doing it - thats what a lot
of the temperature rising is about...

have patience, geo.

 jon

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 19:06:38 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   How to detect problems in socket communication?
I wrote two programs that talk each other through sockets in UNIX system.

Here is the problem:
  When one of the program dies, how does another program detect the connection
  is lost due to dead program on the other end? In other words, how does the 
  program know the socket connection is up/down by just check its own socket?
  Any assistance would be appreciated.

Jian Q. Li
jian@kuhub.cc.ukans.edu
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 20:42:40 GMT
From:      mcsun!cernvax!chx400!poole@uunet.uu.net  (Simon Poole)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <3384@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
....
>In terms of bits per second, Janet (and ISO) might win over TCP.  But

Do you have any hard data that supports this? I have to yet see any
real (== measured) data from an operational network, that would allow
this conclusion. 

-- 
------------------------------------------------------------------------
						Simon Poole
 poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole
------------------------------------------------------------------------
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 90 21:06:24 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!ncrcae!opusc!animal!ken@ucsd.edu  (Ken Sallenger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sun not inventing RPC...
In article <9008311403.AA24690@snow-white.lanl.gov> cpw%snow-white@LANL.GOV (C. Philip Wood) writes:
=> > True enough, but surely the key words are `good' and `better'!
=> 
=> And who was it that said:
=> 
=> 	 "'Better' is the enemy of 'good'."


        The good is the enemy of the best.

                                Bill Wilson, circa 1938

Possibly quoting someone else...
Anyone know a definitive reference?
--
     Ken Sallenger / ken@bigbird.csd.scarolina.edu / +1 803 777-9334
     Computer Services Division / 1244 Blossom ST / Columbia, SC 29208
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 06:00:44 GMT
From:      shelby!msi-s0.msi.umn.edu!cs.umn.edu!ux.acs!aaron@decwrl.dec.com  (Aaron Y.T. Cheung)
To:        tcp-ip@nic.ddn.mil
Subject:   Examples sought for programming Wollongong's VMS TCP/IP lib.
Hi Netlanders,

     Could someone give me simple examples on programming with TWG's
VMS TCP/IP libraries?  Or alternatively give me pointers to where
(if any) I could anon-ftp some working applications written for VMS
on the net.  I've permission to create network devices, and I'm
using VMS 5.3.

I've (ample?) experience with Unix, btw.

     Thank you very much in advance.

/aaron.
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 06:16:58 GMT
From:      math.mit.edu!drw@bloom-beacon.mit.edu  (Dale R. Worley)
To:        tcp-ip@nic.ddn.mil
Subject:   Secure mail
Has anyone out there implemented a filter that does some version of
secure mail a la RFC 1113?

Please reply by e-mail, since I don't read these newsgroups regularly.

Dale
drw@math.mit.edu
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 06:27:58 GMT
From:      agate!darkstar!ucscc.UCSC.EDU!haynes@ucbvax.Berkeley.EDU  (99700000)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RoboDoc
So, does anybody want replies to reports from RoboDoc?  I just got a
message from him/her/it saying we have one more authoritative name server
for ucsc.edu than the root servers think we do.  That's because we are
bringing up a new one preparatory to decommissioning an old one and
have notfied NIC.DDN.MIL to change the root servers accordingly.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 11:35:56 GMT
From:      bygg@sunic.sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: "The Open Book" by Rose - your opinions sought

In article <1990Sep7.145916.23593@sctc.com> briel@sctc.com (Marc Briel) writes:
> Could someone post the full reference for this book? I would like to look
> into getting a copy.

Title:	The Open Book : A practical persective on OSI
Author:	Marshall T. Rose
ISBN:   0-13-643016-3
	Prentice Hall

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 13:11:58 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RoboDoc
There are FIVE authoritative nameservers for UCSD.EDU.

You mean we can now list more than two nameservers with the root?

Golly!
	- Brian
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 15:08:29 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: RoboDoc

You should probably omit domains that are only served by MX records. For
example, hackercorp.com is MXed off uunet.uu.net. Oddly enough, you have
checked the former but I saw no mention of the latter.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 15:29:15 GMT
From:      eru!hagbard!sunic!mcsun!ukc!mucs!liv-cs!keith@bloom-beacon.mit.edu  (Keith Halewood)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <JIM.90Sep7132657@baird.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
> 
> Yes. The JNT wouldn't like it. What you're proposing is not very
> efficient: a better (and easier) option is to put IP datagrams inside
> X.25 frames. That too would upset the JNT since you'd be running
> something other than CB on JANET.

The JNT appears to like the positively HUGE DECnet that exists over Janet and
probably beyond. Unless there is a double standard brewing, the JNT wouldn't be
in much of a 'moral' position to stop an IP over X25 service to the Internet
for any University or company willing to provide one.

Keith
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 17:34:16 GMT
From:      eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!dylan@bloom-beacon.mit.edu  (Matthew Farwell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <3407@syma.sussex.ac.uk> grahamt@syma.sussex.ac.uk (Graham Thomas) writes:
>Now might be a good time to start lobbying, because the way JANET is
>organised is probably going to change.  JNT head Bob Cooper wants to
>set up something like a 'networking association' which would have both
>academic and commercial membership.  There's a steering group just been
>set up to work out the ground rules.  Details, with a list of steering
>group members, are available in the latest issue of Network News.  If
>you want a copy, mail JNT-Secretary@uk.ac.jnt (or @jnt.ac.uk, depending
>on where you live.)

I've done this. Could this be the start of something new + terrific +
exciting in the uk? Not if the JNT have anything to do with it.

>I have a feeling the TCP/IP question might get raised at the next round
>of JANET user group meetings.  The next national user group meeting is
>in the middle of October.  Most regional meetings take place a week or
>two earlier.  It may be worthwhile finding out who your user rep is and
>getting her/him to raise the topic at the next meeting.

How do find out this? Is it in the newsletter?

Dylan.
-- 
Matthew J Farwell                 | Email: dylan@ibmpcug.co.uk
The IBM PC User Group, PO Box 360,|        dylan%ibmpcug.CO.UK@ukc
Harrow HA1 4LQ England            |        ...!uunet!ukc!ibmpcug.co.uk!dylan
Phone: +44 81-863-1191            | Sun? Don't they make coffee machines?
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Sep 90 22:06:52 EDT
From:      ellozy@farber.harvard.edu (Mohamed Ellozy)
To:        tcp-ip@nic.ddn.mil
Subject:   Configuration Test Protocol
What is the Configuration Test Protocol, a thingie that uses ethernet type
09000 packets?  Is it documented in any RFC?  How useful is it?  Is it a
kind of ethernet ping?

Many thanks.

Mohamed

PS:  If it is a sort of Ethernet ping, I would suggest calling the program
that uses it PENG (Packet EtherNet Groper)!
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 90 19:45:49 GMT
From:      david@cwlim.INS.CWRU.Edu
To:        comp.protocols.tcp-ip
Subject:   Network Monitors

I have a network here on campus which ranges from TCP/IP to Novell and I am 
interested in monitoring and recording the usage and load statistics.  I 
would like to see what the network load is at different times of the day and 
what machines monopolize the networks time.  I would also like to know what 
services are being used, but I don't believe that can be done at this level.  
With this information I would be able to determine if a particular branch of 
my network should be isolated by another bridge, for example.  It would also 
aid in allowing me to improve the over-all performance by distributing the 
network load to machines throughout the network.  I have tools such as the 
Network General Sniffer, but it doesn't have the memory or power to accommodate
such a large volume of data and give the information I need.  Does anyone
anywhere know of such a package or combination of packages that would
be able to do this?  Thanks for any help....

					Dave
-- 
david@po.cwru.edu            *  Eagle  *      David Nerenberg
73107,177 Compuserve        * Computers *     Information Network Services
NY:  H-516-751-6344        * Electronics *    Case Western Reserve University
     W-516-751-8111       * Sound & Stage *   W-216-368-2982   H-216-754-2043

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Sep 90 15:41:19 -0400
From:      enger@sccgate.scc.com (Robert M. Enger)
To:        RoboDoc@venera.isi.edu, namedroppers@nic.ddn.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Robodoc
Dear Robodoc:

1)  Does Robodoc check that network name information is present
in the DNS so that we can "stamp out the hosts file in our lifetime"?

2)  What is the implication of a domain being omitted from your report?

Bob Enger
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 01:18:34 GMT
From:      comp.vuw.ac.nz!virtue!canterbury.ac.nz!elec097@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   CMU-TEK LPD_SERVER
We are running CMU-TEK 6.4 under VMS 5.3-1.
When we 'lpr' from a PC running NCSA Telnet the VAX refuses a connection
after about 3 or 4 LPD servers are running. If we wait until some of these die
off the VAX again allows connections.

Any ideas?

*******************************************************************************
*                                                                             *
*                                                                   ____      *
*  cosmik.debris@elec.canterbury.ac.nz                           O=(VVVV)     *
*  psi%(64)30000012::cosmik.debris                              /   \VV/      *
*                                                                   / /       *
*                                                                  ~ ~        *
*                         " I owe money therefore I am. "                     *
*******************************************************************************
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 09:40:16 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        sdd.hp.com!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!dmshq!com50!bungia!cimcor!atc!sstat!moria!bas@ucsd.edu  (Brian Strop)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TN3270 support on UNIX machines
    I am trying to find out if there is a Unix implementation
    of TN3270 (RFC 1041 compliant)....

RFC 1041 does not describe what the world presently implements as "tn3270".
I do not know of any implememtations, and current discussion on the "tn3270"
mailing list seems likely to evolve in a different direction.  RFC 1123
touches on current "tn3270" practice, but there is no definitive write-up.

    We have some PC's that support it, and would like to access a Unix box
    (acting as a server) using TN3270....

The only "tn3270" servers I know of are for IBM mainframes (either the
mainframe or some sort of gateway box has an IP address).  Mapping the
block-mode EBCDIC data stream to Unix conventions is a large project.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 08:01:27 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Keep-Alive within TCP
>>if TCP appears not to. How widespread a "problem" is this? What well-known
>
>    Why is lack of keep-alives a problem? In principle, unless an application
>tries to send data, why ping the network to see if the route is up (if the
>route is down, it may come up again before you send more data)?
>
>Craig Partridge
>Vice-Chairman, I Hate Keep-Alives Association
>
>[For those not in the know, Phil Karn is chair of the IHKAA, and Mike
>Padlipsky is founder, previous-chair, and honorary fellow.  We oughta
>make T-shirts some time... :-)]


Actually, I'm surprised Phil didn't jump in here and answer this one first.
Must be on vacation or something...


bill gunshannon
(closet member IHKAA)

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 03:14:33 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <1990Sep7.112346.16949@anduin.cs.liverpool.ac.uk> mdb@anduin.cs.liverpool.ac.uk writes:
>There is of course no reason why "sensitive" computers should be connected
>to the network at all.

Nonsense.  "Sensitive" computers should be connected to networks for
the same reasons as other computers.  However, most computers with
sensitive information lack the proper access controls to allow them to
be connected to a network in a secure manner.  That's why
conscientious administrators of such systems choose to keep them
isolated.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 10:22:51 -0400
From:      George Williams <gwilliam@SH.CS.NET>
To:        Colin Morris <pacbell.com!pacbell!rtech!ingres!cmorris@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Keep-Alive within TCP


Please note the following in regards your query:

 () "keep-alive" is used rather loosly in the TCP/UNIX environment.
    ( Correct and enlighten me as appropriate.) 

    1. I have seen it used to describe an option under UNIX to determine
       whether or and for how long to "re-try" a client initiated
       connection request to a server process. This is usually done under
       the covers, i.e. transparent, to the requesting process.

    2. Some vendors implement it, again option defined, to periodically
       poll the other end of an established connection in order to
       solicit a response indicating "am still here alive" from a peer
       TCP transport. This feature has proven useful to applications
       designed for paralellism or some degree of concurrency relative to
       higher level processing requirements.


    Given the above it would be enlightening to one such as myself if you 
    would elucidate as to which if any of the above context you are 
    using the term "keepalive", i.e. could help define the implementation
    specific context of your query. 

    In the case of (1) above it has proven beneficial and helped to simply
    interface level programming logic requirements to have this feature,
    based on prior development ( subjective ) work in this area.


    As far as (2) , again, it proved to be a useful feature; in lieu of a
    timeout parameter on most UNIX implementations for network read and write
    calls, in avoiding "hung" processes and in the area of process management.
    In distributed compute environments  determination of 'when' a 
    process/service/application is 'really' alive can be a problem depending
    on what OS/CPU combination a process is executing under, just to mention
    one consideration. I won't mention any vendor by name ( some
    of observed problems in this area may have been corrected, even as we
    speak ), but some OS's have been noted to max out or approach 100%
    CPU utilization as a result of process or application level loops for
    retrys on network open/read/write failure attempts. Granted that this
    is the indication of a poor design on the application level, network
    software developers have to take the broad(er) perspective that programmers
    don't want to know the detail of underlying protocols much the same
    as we don't necessarily want to get into application specific  
    implementation details.

 () OSI TP0 and TP4 specify connectionless and connection oriented transport
    service by way of architectural definition. It comes as no surprise that
    the connection oriented service would be rigid in the service and protocol
    specification for the know state of an end to end or peer connection.
    Rationale, one would assume,include some if not all of the aforementioned.
    Not to mention the tradeoff beteeen end to end service association versus
    simple protocol, and I assume infrequent, exchange of "keep-alive"
    information.( I stand to be corrected here, but it's sound logical to me
    so I'm probably way off base ,SMILE. ) You can probably make a better
    statement in this area than I am prepared to.

    TCP, ostensibly, takes the least-common-denominator path to solution 
    from all have been able to determine, based on implementation experience.
    In other words by design ( there is no application or session layer )
    the path that offers the least protocol overhead appears to have been
    chosen for support of end to end transport level connectivity. It looks
    like ( and I make the statement with a limited frame of historical
    reference in this area ) "the right decision" based on the engineering 
    requirement(s) at that time.

 () I have seen vendors that don't or hadn't prior to this year implemented
    this feature as described for both case (1) and (2) above.  So I have
    always considered it an option that was product (vendor) driven. Work may
    be ongoing by some a Working Group to make it a protocol extension.


  
  George Williams
  BBN,STC
  

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 17:34:03 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        att!devildog!jrallen@ucbvax.Berkeley.EDU, NELSON%MSU.EDU@pucc.PRINCETON.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Window Field on SYN Packet
> >Concerning the window field on a SYN packet, what does a value of 0 mean?
> >Most machines (UNIX) that I have watched on the LANalyzer show a reasonable
> >value for this field in the SYN packet: 2048, 4096 or something like that:
> >
> >        UNIX A                  UNIX B
> >        ========                ======
> >        SYN 4096        ->
> >                        <-      SYN ACK 4096
> >        ACK 4096        ->
> >
> >I now am trying the talk to a MVS machine which sends me a SYN packet
> >with a window size of 0.  What does this mean?  It certainly confuses my
> >UNIX machines as they then send a SYN ACK with the window field having
> >a value of 53000 or so:
> >
> >        MVS             UNIX
> >        =====           ============
> >        SYN 0   ->
> >                <-      SYN ACK 53215
> >        ACK 0   ->
> >
> >Things seem to go downhill rapidly after this point; what is happening here?
> >I would like to know what machine I need to do some fixing on.
> 
> My first reaction is that a SYN with a window size of zero can't be
> answered, since there's no window space in which to send the responding
> SYN.  But you are allowed to send a single byte to probe a zero window;
> in this case, the responding SYN would be that byte.  However, I can't
> think of any good reason to try opening a connection if you can't offer
> a reasonably sized window to start with.
>
> Now, the Unix system's response could be better, but this is definitely
> an end case that is dealing with.  So I would concentrate on the MVS system.
> 
> Does the MVS system ever send another ACK with a non-zero window?
> 

Actually, the window field in a TCP packet is an offset from the
ack field, and the ack field is only valid if the ACK bit is set,
and the ACK bit is never set in the initial SYN packet, so the
ack field is meaningless, and hence the window field is also
meaningless.

However, it would seem logical that the window value in the initial
SYN packet would indicate the number of data octets that the sender
is willing to accept from whatever initial sequence number the receiver
chooses to start with.  But this is not what RFC-793 says, so you
can't depend on it.

The real question is after the MVS sends the "ACK 0", does it ever
send a packet in which it actually opens the window?  And does the
UNIX side really have a window of 53215?

4.2BSD had a problem with the window field, but it was the reverse
of this.  4.2BSD would belive the window value in the initial SYN,
and when connecting to a TAC it was getting garbage in the window
field in the initial SYN.  This was usually some large number, and
the 4.2 would overrun the TACs buffers. The TAC would just throw
away the extra data, causing the 4.2 system to do lots of retransmits.

The bottom line is that these three initial packets look just fine,
the only potential problem is if the 53215 byte window being offered by
the UNIX machine is wrong, and it really has a much smaller buffer.
Then you could have the MVS system trying to send data that the
UNIX system would throw away, causing the MVS to have to go into
retransmit mode, or a later packet sent from the UNIX side with the
correct window size would cause the MVS to see a shriking window
that it might not deal with properly.  But in either case, the
main problem is on the UNIX side, not the MVS side.  (Shrinking
windows are a bad idea...).

			-David Borman, dab@cray.com
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 11:15:56 GMT
From:      mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net  (Andy Holt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
Sorry, in my previous posting I incorrectly used the notation
TC0 and TC4 when I should have used TP0 (CONS) and TP4 (CLNS)
Further, this system - not my normal "home"  - gave an incorrect
"reply-to" line.


Andy
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 12:05:06 GMT
From:      mcsun!ukc!edcastle!aiai!richard@uunet.uu.net  (Richard Tobin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
>>In terms of bits per second, Janet (and ISO) might win over TCP.  But

>Do you have any hard data that supports this? 

Certainly not.  I have no idea whether it's true.  The point I was trying
to make was that *even if* it's true, I'd be better off with TCP.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 13:01:27 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Keep-Alive within TCP

>>if TCP appears not to. How widespread a "problem" is this? What well-known
>
>    Why is lack of keep-alives a problem? In principle, unless an application
>tries to send data, why ping the network to see if the route is up (if the
>route is down, it may come up again before you send more data)?
>
>Craig Partridge
>Vice-Chairman, I Hate Keep-Alives Association
>
>[For those not in the know, Phil Karn is chair of the IHKAA, and Mike
>Padlipsky is founder, previous-chair, and honorary fellow.  We oughta
>make T-shirts some time... :-)]


Actually, I'm surprised Phil didn't jump in here and answer this one first.
Must be on vacation or something...


bill gunshannon
(closet member IHKAA)

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 13:06:03 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable connectionless (udp) sockets, who can help?



 >For a project on distributed computational physics I am
 >working on a small library to allow users easy access to 
 >N processes on different computers.
 
 >Maybe someone could also indicate to me if I am on the right way:
 >I have the following idea to implement it:
 >- each process has a generally known (address+port) udp socket,
 >  which is made asynchronous.
 >- a write operation sends packets to process i on some host,
 >  causing an interrupt. In the interrupt the packet is read
 >  and put in a buffer (N-1 buffers per host, one for each other process).
 >- a read operation reads from the buffer, and blocks if not enough
 >  data is in it. (by doing wait(), and > check after a signal (SIGIO)
 >  if there is enough data now)

Peter,

 i did this a coupla years ago while prototyping a multicast transport
protocol. Your main problem is reliability - you
have to re-implement all the TCP-isms that are in the kernel- since
thats what i was interested in, it didnt matter to me - it might irk
you.

if you have a taste for it, get VMTP and IP multicast code from
stanford, and install, then you have it all done for you (you do rpc's
or transactions with process groups).

alternatively, you can hack TCP to open a connection to
well known port + broadcast address (yuck)

or just install multicast IP, and change this to
well known port + multicast addr
and as SYN-ACKs come back, bind multiple connections - you then have
the socket to user space decision - do you return n lots of data from
n connections on each read, have multiple accepts + fds, or ioctl's to
de-mux each connection etc etc - someone somewhere
in california close to the heart of a certain unix did some of this, but is 
hibernating or something i believe:-).

having said that, what you are suggesting will sorta work some of the
time...

its about time someone had a good remote multi-procedure call package

 jon

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 13:14:23 WET
From:      Keith Mitchell <keith@spider.co.uk>
To:        tcp-ip@nic.ddn.mil
Cc:        nick@spider.co.uk, briant@spider.co.uk, mahmoodn@spider.co.uk
Subject:   Re: Internet routing Europe - USA -} Europe...
In:

> Message-ID: <1990Sep7.052615.1896@brolga.cc.uq.oz.au>
> 
> hung out to dry. Nobody with any sense give a DAMN. Religious warfare
> is for celtic and rangers fans and the Jihad mob only.

George <G.Michaelson@cc.uq.oz.au> is right. Getting bogged down in
the relative merits of Coloured Book vs TCP/IP protocol stacks and
applications is a waste of time.  Until the glorious (?) day when
OSI is universal, there is room for all.

This is the approach taken in places like Australia and Scandanavia,
and I think it is very unfortunate that the UK does not take this
catholic approach to networking. Are we the only country in the world
where use of TCP/IP is *banned* on our national research network ?
Just because we drive on the left-hand side is not a reason for
outlawing non-right-hand drive vehicles from British roads.

Even though we want IP over JANET, this does not mean we want to
scrap the existing setup. This would be daft when Spider are vendors
of both Coloured Book and TCP/IP products. Desire for IP
connectivity comes not from the intrinsic properties of any
protocols, but from two practical details of their use:

- Then only way you can can application-transparent international
  connectivity NOW is to use TCP/IP.

- There are lot more people in the world using TCP/IP than Coloured books.

So, lets keep Coloured Books on JANET, fine. But can we get at the
existing international networking infrastructure too, please,
without having to use UUCP (commercial) or go through an overloaded
non-transparent gateway (academic). It's not like we aren't prepared
to pay our way - international communications are very important to
Spider's business, and many other UK firms too. All we want to do is
share the costs a bit. Seems that being prepared to do this ourselves
is the best thing we can do if the powers that be won't let us in.

Let's hope the JNT's "DoD" working group makes things happen in
months, rather than sometime. It's difficult for Spider to influence
the JNT when we are not members of JANET, but then it would be a lot
easier to justify the expense of joining if we got TCP/IP connectivity
as well. Setting up Coloured Book software on our own network when
everything else is TCP/IP is a hassle.

Talking about powers that be, UKUUG (who have UKC run UKNET for
them) have been very quiet about all this. Are we going to have to
set up a UKIPUG ?

What Brian says about hooking up now is serious. You want a pilot IP link
over the PDN, ask me. To prove how serious:

> Anybody asked PSI or any of the other commercial IP networks to cost
> a service in the UK?

I'm asking. I've already enquired of UUNET, would PSI or anyone else
care to comment ?

Disclaimer time - the above, of course, represents what I think
Spider policy should be rather than what it necessarily is.

Keith Mitchell

Spider Systems Ltd.             Spider Systems Inc.
Spider Park    		        12 New England Executive Park
Stanwell Street                 Burlington
Edinburgh, Scotland             MA 01803
Phone: +44 31-554 9424          +1 (617) 270-3510
Fax:   +44 31-554 0649

keith@spider.co.uk              keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith      zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uk


P.S. (:-) As someone who lives and works in Leith, let me assure you
     "The Proclaimers" come not from here, but sunny Fife, just across the
     river.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 13:23:36 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...



 >Actually, this is a highly questionable view of history.  I worked at
 >UCL in 1981-82, when the forerunner of JANET was getting going (I wrote
 >the first terminal gateway at UCL, between the TCP/IP-based Satnet
 >connection and the JNT X.25 network).  I doubt that there was any stage
 >where the JNT-sponsored academic X.25 kit delivered better service than
 >TCP/IP was delivering to universities in the US.  The often-expressed

Bob,

 Several years ago, when the Internet was under the congestive collapse 
that was only saved by certain very clever people fixing TCP, I believe 
that JANET was offering a comparable service:-)

 The state of recent UK sadness can be seen from the continual
tired comparisons of FTP and NIFTP, ignorance of BFTP, failure to 
mention NFS, AFS, RFS etc; The 
non-existence of a networked window system in the UK; the absence of a 
remote execution (not job submission) protocol in colour book, the failure 
to design and install a decent distributed name service, etc etc;
the absurd problems of setting up 40 digit NSAPs for an X.25 on LAN
service, instead of using an elegant scheme like ARP (still waiting
for 10030)... the lack of a CONS routing scheme...

meanwhile, the Internet bounds ahead with full management, multi-media
conferencing experiments, the White Pages pilot and so on -

but hold! we are putting up X.[4|5]00 as pilot services, there is a
small bit of hope; we have a model for X Windows on OSI; someone is
working on FTAM file access regime in the kernel somewhere (i hope)

what has this to do with Europe? not a lot, but - well, I guess if NSF 
and the European countries carrying UK - Europe traffic on their leased 
lines started accounting and billing the JNT, they might effect a
change - ULCC (the actual UK-US gateway, *not* UCL) had some software
to do this...

of course, this is all modulo policy based routing and accounting
research.

 jon

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 14:22:51 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Keep-Alive within TCP



Please note the following in regards your query:

 () "keep-alive" is used rather loosly in the TCP/UNIX environment.
    ( Correct and enlighten me as appropriate.) 

    1. I have seen it used to describe an option under UNIX to determine
       whether or and for how long to "re-try" a client initiated
       connection request to a server process. This is usually done under
       the covers, i.e. transparent, to the requesting process.

    2. Some vendors implement it, again option defined, to periodically
       poll the other end of an established connection in order to
       solicit a response indicating "am still here alive" from a peer
       TCP transport. This feature has proven useful to applications
       designed for paralellism or some degree of concurrency relative to
       higher level processing requirements.


    Given the above it would be enlightening to one such as myself if you 
    would elucidate as to which if any of the above context you are 
    using the term "keepalive", i.e. could help define the implementation
    specific context of your query. 

    In the case of (1) above it has proven beneficial and helped to simply
    interface level programming logic requirements to have this feature,
    based on prior development ( subjective ) work in this area.


    As far as (2) , again, it proved to be a useful feature; in lieu of a
    timeout parameter on most UNIX implementations for network read and write
    calls, in avoiding "hung" processes and in the area of process management.
    In distributed compute environments  determination of 'when' a 
    process/service/application is 'really' alive can be a problem depending
    on what OS/CPU combination a process is executing under, just to mention
    one consideration. I won't mention any vendor by name ( some
    of observed problems in this area may have been corrected, even as we
    speak ), but some OS's have been noted to max out or approach 100%
    CPU utilization as a result of process or application level loops for
    retrys on network open/read/write failure attempts. Granted that this
    is the indication of a poor design on the application level, network
    software developers have to take the broad(er) perspective that programmers
    don't want to know the detail of underlying protocols much the same
    as we don't necessarily want to get into application specific  
    implementation details.

 () OSI TP0 and TP4 specify connectionless and connection oriented transport
    service by way of architectural definition. It comes as no surprise that
    the connection oriented service would be rigid in the service and protocol
    specification for the know state of an end to end or peer connection.
    Rationale, one would assume,include some if not all of the aforementioned.
    Not to mention the tradeoff beteeen end to end service association versus
    simple protocol, and I assume infrequent, exchange of "keep-alive"
    information.( I stand to be corrected here, but it's sound logical to me
    so I'm probably way off base ,SMILE. ) You can probably make a better
    statement in this area than I am prepared to.

    TCP, ostensibly, takes the least-common-denominator path to solution 
    from all have been able to determine, based on implementation experience.
    In other words by design ( there is no application or session layer )
    the path that offers the least protocol overhead appears to have been
    chosen for support of end to end transport level connectivity. It looks
    like ( and I make the statement with a limited frame of historical
    reference in this area ) "the right decision" based on the engineering 
    requirement(s) at that time.

 () I have seen vendors that don't or hadn't prior to this year implemented
    this feature as described for both case (1) and (2) above.  So I have
    always considered it an option that was product (vendor) driven. Work may
    be ongoing by some a Working Group to make it a protocol extension.


  
  George Williams
  BBN,STC
  

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 15:06:03 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@hplabs.hpl.hp.com  (abdi m oday)
To:        tcp-ip@nic.ddn.mil
Subject:   Reading IP packets via sockets

Hi folks.

I need to write a user program that  reads all ip packets on the 
local LAN.  I think I can do this using NIT (network Interface Tap)
but since this code is ultimately going to run on a MVME-147 board
running VxWorks, I'd like to do this with raw sockets since I know
they support sockets.

My question is, can raw sockets be used to read all packets ?
Will the IP layer pass things to the socket even though the packet
might not be addressed to the socket, or to the machine itself ( I 
intend to use the "promisc mode").

    I'd appreciate any help with this.

       thanks

       -Abdi

       oday@acsu.buffalo.edu
       (716) 631-6848
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 15:06:37 GMT
From:      fernwood!hercules!frisbee.cisco.com!allan@uunet.uu.net  (Allan Leinwand)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Monitors
In article <1990Sep8.194549.25555@usenet.ins.cwru.edu>,
david@cwlim.INS.CWRU.Edu writes:
|> I have a network here on campus which ranges from TCP/IP to Novell and I am 
|> interested in monitoring and recording the usage and load statistics.  I 
|> would like to see what the network load is at different times of the
day and 
|> what machines monopolize the networks time. 

Hello Dave,

   We here at cisco Systems have a network management package that can
help you 
find the load on various devices throughout the network and store this
information in a database.  Of course, you  must have an SNMP agent on all the
devices which you care to monitor.  The package is called "NetCentral"
and currently runs on a Sun.

!> I would also like to know what 
|> services are being used, but I don't believe that can be done at this
level. 

   This is a bit trickier, but provided this information is available
via SNMP, NetCentral can do this for you.  If this information cannot be
retrieved via SNMP, the most efficient way to do this may be using your
Sniffer.  HP has
a protocol analyzer out, called the HP4972, which has software which
does this function for you.  Perhaps you just need the right software
for the Sniffer.
 
|> I have tools such as the 
|> Network General Sniffer, but it doesn't have the memory or power to
accommodate
|> such a large volume of data and give the information I need.  Does anyone
|> anywhere know of such a package or combination of packages that would
|> be able to do this?  Thanks for any help....

   Again, our NetCentral may have the power you need,  It can run  on a
SparcStation and this should give you the ummph in processing you
desire.  Further, it's relational database can store as much data as you want.

   Please contact us at customer-service@cisco.com or 1-415-326-1941


Thanks,

Allan Leinwand
cisco Systems
leinwand@cisco.com
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 15:30:42 GMT
From:      sun-barr!cs.utexas.edu!ut-emx!!spurgeon@apple.com  (Charles E. Spurgeon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Configuration Test Protocol
In article <9009090206.AA01032@farber.harvard.edu> ellozy@FARBER.HARVARD.EDU (Mohamed Ellozy) writes:
>What is the Configuration Test Protocol, a thingie that uses ethernet type
>09000 packets?  Is it documented in any RFC?  How useful is it?  Is it a
>kind of ethernet ping?
>

Yes, it is a sort of Ethernet ping.  You'll find it documented in the
DIX Ethernet spec, Version 2.0 (access info below).  Basically it
allows Ethernet controllers to reply to test packets, and to forward
test packets on to another controller.

The Test Protocol was dropped from the IEEE802.3 spec, and you will
not find much support for it today.  The major exception is DEC.  DEC
has included support for this protocol in many of their Ethernet
controllers.  

Here's how to get a copy of the DIX spec:
	
Ethernet Local Area Network Specification  Version
2.0. November, 1982
Digital Equipment Corporation, Intel  Corporation,
Xerox Corporation, 103 pps.
$32.00.
DEC  Part  Number:  AA-K759B-TK.   Available  from
DEC-Direct by calling 800-344-4825.


Charles Spurgeon                     |                                  |
UTnet Network Information Center     | spurgeon@emx.utexas.edu          |
University of Texas at Austin        | ...!cs.utexas.edu!ut-emx!spurgeon|
-------------------------------------------------------------------------
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 14:06:03 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        muts@fysaj.fys.ruu.nl
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Reliable connectionless (udp) sockets, who can help?


 >For a project on distributed computational physics I am
 >working on a small library to allow users easy access to 
 >N processes on different computers.

 >Maybe someone could also indicate to me if I am on the right way:
 >I have the following idea to implement it:
 >- each process has a generally known (address+port) udp socket,
 >  which is made asynchronous.
 >- a write operation sends packets to process i on some host,
 >  causing an interrupt. In the interrupt the packet is read
 >  and put in a buffer (N-1 buffers per host, one for each other process).
 >- a read operation reads from the buffer, and blocks if not enough
 >  data is in it. (by doing wait(), and > check after a signal (SIGIO)
 >  if there is enough data now)

Peter,

 i did this a coupla years ago while prototyping a multicast transport
protocol. Your main problem is reliability - you
have to re-implement all the TCP-isms that are in the kernel- since
thats what i was interested in, it didnt matter to me - it might irk
you.

if you have a taste for it, get VMTP and IP multicast code from
stanford, and install, then you have it all done for you (you do rpc's
or transactions with process groups).

alternatively, you can hack TCP to open a connection to
well known port + broadcast address (yuck)

or just install multicast IP, and change this to
well known port + multicast addr
and as SYN-ACKs come back, bind multiple connections - you then have
the socket to user space decision - do you return n lots of data from
n connections on each read, have multiple accepts + fds, or ioctl's to
de-mux each connection etc etc - someone somewhere
in california close to the heart of a certain unix did some of this, but is 
hibernating or something i believe:-).

having said that, what you are suggesting will sorta work some of the
time...

its about time someone had a good remote multi-procedure call package

 jon

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Sep 90 14:23:36 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        braden@venera.isi.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...


 >Actually, this is a highly questionable view of history.  I worked at
 >UCL in 1981-82, when the forerunner of JANET was getting going (I wrote
 >the first terminal gateway at UCL, between the TCP/IP-based Satnet
 >connection and the JNT X.25 network).  I doubt that there was any stage
 >where the JNT-sponsored academic X.25 kit delivered better service than
 >TCP/IP was delivering to universities in the US.  The often-expressed

Bob,

 Several years ago, when the Internet was under the congestive collapse 
that was only saved by certain very clever people fixing TCP, I believe 
that JANET was offering a comparable service:-)

 The state of recent UK sadness can be seen from the continual
tired comparisons of FTP and NIFTP, ignorance of BFTP, failure to 
mention NFS, AFS, RFS etc; The 
non-existence of a networked window system in the UK; the absence of a 
remote execution (not job submission) protocol in colour book, the failure 
to design and install a decent distributed name service, etc etc;
the absurd problems of setting up 40 digit NSAPs for an X.25 on LAN
service, instead of using an elegant scheme like ARP (still waiting
for 10030)... the lack of a CONS routing scheme...

meanwhile, the Internet bounds ahead with full management, multi-media
conferencing experiments, the White Pages pilot and so on -

but hold! we are putting up X.[4|5]00 as pilot services, there is a
small bit of hope; we have a model for X Windows on OSI; someone is
working on FTAM file access regime in the kernel somewhere (i hope)

what has this to do with Europe? not a lot, but - well, I guess if NSF 
and the European countries carrying UK - Europe traffic on their leased 
lines started accounting and billing the JNT, they might effect a
change - ULCC (the actual UK-US gateway, *not* UCL) had some software
to do this...

of course, this is all modulo policy based routing and accounting
research.

 jon

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 16:13:36 GMT
From:      eru!hagbard!sunic!mcsun!ukc!cam-cl!news@bloom-beacon.mit.edu  (Piete Brooks)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
[ % = dfk@eu.net, > = pte900@jatz.aarnet.edu.au, * = pb@cl.cam.ac.uk ]
% High time to put some of the *facts* right:
> Fortunately for us, the UKnet gateway isn't the only one.  UCL have
> a 56Kb link to the USA and offer a guest FTP service which allows us
> to transfer files to and from internet connected sites.  They also
> transfer our mail, and make no charge.  This is unlike UKC which
> charge for news, and mail, and they also advertise themselves as
> a valid route for uk mail.
% But if you are entitled to use the UCL gateway you can also register with
% UKC free of charge to you. The JNT pays then. So go ahead and register.
% Also remember tanstafl, links are never free, the taxpayer pays.
* If you are keen on getting facts right, note that the above is not true.

* The gateway is NOT at UCL (University College London) but at ULCC
* (University of London Computer Centre)

* UK AC sites are split in two: Some are "CB" and others are not.
* The Computer Board will only pay the UKC charges of SOME sites.
* The best rule I have got for the horses mouths are that if the machine was
* bought by the CB, they'll pay the UKNET charges.
* This means that if two machines within our department (about 10 meters apart)
* both take news (as they may soon do) we will have to pay UKC twice -- one
* from the pockets of the department and once from the pocket of the CB.
* Smart people at ukc :-) !

* Note that links may not be free, but traffic may be !

% Also have you ever thought about mail to/from Europe rather than the US?
* What do we have IXI for ??  [ :-( ]

% Doesn't it seem unfair to you that European sites must ship their mail to
% you via the US on intercontinental links *they have to pay for* so that you
% can use your *free* link. That is what I call selfishness!
* No problem -- get European sites to call the UK    [ :-) ]

While I'm here, I shall point out that I get a lot higher bandwidth fetching
a file from the states or europe directly to my workstation (using FTAM over
JANET to a (free to me) FTAM/ftp gateway) than I do from UCL (using NIFTP).
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 16:32:08 GMT
From:      zephyr.ens.tek.com!orca.wv.tek.com!vsg.com!mike@uunet.uu.net  (Mike Witt)
To:        tcp-ip@nic.ddn.mil
Subject:   Broadcast File Transfer Protocol?
I'm looking for pointers to any work that has been done on any kind of
broadcast/multicast file transfer protocol.  If any one has such a pointer,
could you please mail it to me at: mike@vsg.com

Thanks,

Mike Witt

PS, if you feel strongly that adding another broadcast protocol would be a
terrible idea under any circumstances, and you feel like having a conversation
about this, please send me mail also.  Thanks.
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 17:12:18 GMT
From:      orc!orc.olivetti.com!giamma@decwrl.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip performance

I am interested to some tests for doing performance 
evaluation of TCP/IP, any suggestions ?

	Gianmaria Clerici  giamma@orc.olivetti.com
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 20:37:27 GMT
From:      manta!gutman@nosc.mil  (Lewis M. Gutman)
To:        tcp-ip@nic.ddn.mil
Subject:   internet routing protocols- general questions...

For a project I am working on, I need to gather some material on the
types of gateway protocols running over TCP/IP based internets.  I
started with Comer's _Internetworking with TCP/IP_ and found the
material detailed and well written.  For about two weeks, I thought I
had the subject wired.  However, after seeing recently published RFCs
on new routing protocols and still other routing protocols in the works
(i.e., in the IETF: directory of nic.ddn.mil and other places), I
wonder how well Comer's book actually describes the reality of TCP/IP
internets today.  The new routing protocols I'm talking about are OSPF,
IGRP, ANSI IS-IS, BGP, Open Distance Vector IGP, whatever the protocol
to be developed by the Open Systems Routing WG is to be called, and
maybe some others I don't know about.  

In an attempt to understand the context of all these routing protocols,
I'd like to ask people on the net several questions.  

First of all, is there any document which lists all of the protocols,
describes them briefly, shows where they fit in (e.g., is the protocol
a proprietary IGP?, is it a proposed EGP replacement?, is it intended
for NSFNET backbone?, etc.), tells what the planned interactions are
between the protocols, and states what the policy is regarding the
acceptance and planned usage of these protocols?  I'd also like to know
who is driving the work.  

Secondly, which of the new protocols are actually running out there
today?  I work in a UNIX environment so I know that there are many RIPs
and EGPs (gated) running on BSD UNIX machines out there.  I don't
really have a sense about the other protocols.  I'm interested in
finding out the proportion of various gateways running each protocol
on TCP/IP based internets, if such information is available.

Thirdly, I am interested in hearing about experiences with gateways in
campus and smaller sized networks running two or more protocols.  Is
interoperation possible?  How difficult is it transition to new
equipment/protocols?  

In lieu of comprehensive documents on the subject, I'd be happy to put
together the responses I receive and summarize to the net (if there is
any interest, of course).  Thanks in advance to everybody who
responds.

Lew Gutman
Naval Ocean Systems Center, Code 854
San Diego, CA. 92152

<gutman@nosc.mil>

Disclaimer: The government is not responsible when I ask a lot of 
questions.
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 90 23:43:40 GMT
From:      alfonso@mtecv2.mty.itesm.mx
To:        comp.sys.mac.comm,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help with SUN RPC installation


  Has anybody installed the public domain RPC libraries from SUN in your
system?

   I have copied the sources from SUN and I don't know what to do to install'em. My purpose is to install this routines in a Macintosh, but as I suppose, nobody or almost nobody has done this, so I ask for some help about the installation process in UNIX, because in that way I could figure out what to do in the Mac.

  I've got about fifty different "shar" files, some "uu" files and some "c" files, besides a "tar" file. I would like to know what are the next steps:

  Do I have to decompress some files?
  Run a binary file to do something?, etc.

  I guess I have made myself clear about my problems. Any help from you will be welcomed
  Thanks in advance.

     Alfonso.

  P. S.: I would like you to send a copy of your reply to David, who works
with me, his account in the machine is "davidmtz".

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 01:26:30 GMT
From:      excelan!jlt@ames.arc.nasa.gov  (Jeff Turner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Monitors
In article <1990Sep8.194549.25555@usenet.ins.cwru.edu> david@cwlim.INS.CWRU.Edu () writes:
>I have a network here on campus which ranges from TCP/IP to Novell and I am 
>interested in monitoring and recording the usage and load statistics.  I 
>would like to see what the network load is at different times of the day and 
>what machines monopolize the networks time.  I would also like to know what 
>services are being used, but I don't believe that can be done at this level.  
>With this information I would be able to determine if a particular branch of 
>my network should be isolated by another bridge, for example.  It would also 
>aid in allowing me to improve the over-all performance by distributing the 
>network load to machines throughout the network.  I have tools such as the 
>Network General Sniffer, but it doesn't have the memory or power to accommodate
>such a large volume of data and give the information I need.  Does anyone
>anywhere know of such a package or combination of packages that would
>be able to do this?  Thanks for any help....

Dave,

  Perhaps, you would like to consider a remote network monitor device such
as Novell's LANtern.  In general, network monitors perform tasks such as:
	
		*  monitoring vital statistics
		*  sending alarms when vital stat thresholds are exceeded
		*  sending alarms when common problems are detected
		*  gathering long-term trending information
		*  providing station and conversation analysis

  The LANtern relays this information back to a central SNMP-based network
management console.  It was to designed to accomodate any size network and be
independent of the protocols used on the network.  The LANtern works with
practically any SNMP-based network management console but you may want
to consider consoles that provide a nice user interface for the product.

  You may also want to check out network monitoring products from companies
such as Micro Technology, ACC, HP, and TEC.

  For more information on our products you can call 1-800-243-8526.

>					Dave
>-- 
>david@po.cwru.edu            *  Eagle  *      David Nerenberg
>73107,177 Compuserve        * Computers *     Information Network Services
>NY:  H-516-751-6344        * Electronics *    Case Western Reserve University
>     W-516-751-8111       * Sound & Stage *   W-216-368-2982   H-216-754-2043


    Jeff Turner
    Novell, Inc.
    (408) 473-8287
    email: jlt@novell.com
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Sep 90 09:21:51 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   SynOptics compatability
I have a question for any SynOptics users out there.
I currently have a building wired using SynOptics 1000's and UTP.
We plan to extend the network to other building on Campus and wanted to
do it using Fiber.  Does anyone know if the Fiber connections on a SynOptics
1000 (a 201-ST board) are compatable with the newer 3000 series
concentrators??  If not, I can still get around it, but the configuration
will change considerably.

Can anyone shed any light on this subject?  Is SynOptics on the net anywhere?

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 05:40:41 GMT
From:      crash!jburnes@nosc.mil  (Jim Burnes)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for PD tcp/ip/ftp/telnet/etc
Hi All!

I'm looking for high quality PD TCP/IP software FTP/TELNET and berkeley
sockets stuff for both Xenix/386 and MSDOS machines.  If this sounds
somewhat ingorant ..then so be it.  What are the names of these
programs and where can they be found (what machines).  I have 
pc pursuit and shell access to a usenet unix box.

I would also like to get access to sources if possible.

Any help appreciated.

Jim Burnes
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Sep 90 11:51 EDT
From:      SMANTHANI@ccmail.sunysb.edu
To:        TCP-IP@NIC.DDN.mil
Subject:   Re: Ethernet configuration problem
Enabling the Heart Beat sinal of the Transciver (H4000) might solve the 
problem.
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Sep 90 14:17:27 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for (a working) NFS for VMS
Well, we've been bitten once more by Wollongong's TCPIP for VMS.
I have found out today that their NFS cannot understand enough
of the UNIX file commands to even be usable.  (No chown, No permissions,
No link())
Does anyone know if any of the other TCPIP implemntations support
NFS?? And does it work well enough to be used with a UNIX system??
And of course can it used a shared ethernet interface on the VAX??
I still have to support LAT as well.

Any help??

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 09:45:25 GMT
From:      eru!hagbard!sunic!mcsun!ukc!warwick!cudep@bloom-beacon.mit.edu  (Ian Dickinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <6190@castle.ed.ac.uk> tjc@castle.ed.ac.uk (A J Cunningham) writes:
>	This raises the rather interesting question of who exactly the
>JNT answer to. Every time I hear a discussion on this subject the cries
>from the punters on the ground who actually use and run computers day-in
>day-out is for TCP/IP. The JNT says Coloured Books and OSI. Seems to be
>a bad case of the tail wagging the dog. Still can't complain. Coloured
>books have been good to me :-)

The JNT don't answer to the users - they're civil servants.

I don't really give a toss what we run, so long as it works reliably
and lets us interconnect.  OSI may do this eventually.  Maybe not.
But it's a hell of a lot better than DECNet.

Ciao,
--
\/ato.  Ian Dickinson.    GNU's not got BSE.      Cut Cerebus some slack!
vato@cu.warwick.ac.uk          Plinth.          
vato@tardis.cs.ed.ac.uk        Sabeq.         
gdd046@cck.cov.ac.uk                          "Nuke me tender, nuke me good!"
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 09:56:25 GMT
From:      eru!hagbard!sunic!mcsun!ukc!warwick!cudep@bloom-beacon.mit.edu  (Ian Dickinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <3384@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
>In terms of bits per second, Janet (and ISO) might win over TCP.  But
>in terms of who's been able to use interactive ftp, I think it's clear
>which has been more efficient over the last ten years.  The supporters
>of this "efficiency" view have wasted hundreds of hours of my time.

There's an interactive ftam with isode, including ftam-ftp converters
for both directions (internet ftp btw.)  Just because CB doesn't have it,
doesn't mean that OSI won't.  All we need now is a fast implementation
or a good excuse to just use IP.  1/2 :-)

Cheers,
--
\/ato.  Ian Dickinson.    GNU's not got BSE.      Cut Cerebus some slack!
vato@cu.warwick.ac.uk          Plinth.          
vato@tardis.cs.ed.ac.uk        Sabeq.         
gdd046@cck.cov.ac.uk                          "Nuke me tender, nuke me good!"
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 11:21:27 GMT
From:      eru!hagbard!sunic!mcsun!ukc!pyrltd!trevan!trevor@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...

Please can anyone tell me:

1) Are there any sites in the other than UCL which have an Internet connection
   to the USA.

2) Are there any sites in Europe or the USA which are willing to provide a
   connection by Trailblazer, ISDN or X25.

3) Anyone interested in setting up a domain in the UK.

4) Are there any problems with using dialup connections or do we
   need a backbone of private wires. 

			regards trevor
						trevor@trevan.co.uk

-- 
				regards trevor
						trevor@trevan.co.uk
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 14:00:57 GMT
From:      uop!milton!ogicse!dali.cs.montana.edu!uakari.primate.wisc.edu!samsung!munnari.oz.au!sao.aarnet.edu.au!gih900%@ucdavis.ucdavis.edu  (Geoff Huston)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <13713@ulysses.att.com>, smb@ulysses.att.com (Steven Bellovin) writes:
> In article <1990Sep5.092510.22637@cs.city.ac.uk>, sb380@cs.city.ac.uk (Andy Holt) writes:
>> The JNT in its infinite wisdom (???) has mandated that the ISO
>> profile used in the UK use TC0 (connection oriented transport
>> service) while NBS in the USA is encouraging the use of TC4
>> (connectionless transport service).
> 
> Without commenting on the wisdom (or the lack thereof) of JANET, the
> real problem here is OSI.  They've designed a protocol stack with
> mutually incompatible options, thus preventing communication between
> parties who've made different decisions.  What's the point of a
> standard that's incompatible with itself?

A lot - If the people who go to ISO standards meetings get paid by the hour
then there's at least another two decades of employment in store for them in
attempting to come to grips with the astonishingly large mess that they're
creating.

(I was about to wack in a smiley until I realized that its no joke)

Geoff Huston
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 14:21:51 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   SynOptics compatability

I have a question for any SynOptics users out there.
I currently have a building wired using SynOptics 1000's and UTP.
We plan to extend the network to other building on Campus and wanted to
do it using Fiber.  Does anyone know if the Fiber connections on a SynOptics
1000 (a 201-ST board) are compatable with the newer 3000 series
concentrators??  If not, I can still get around it, but the configuration
will change considerably.

Can anyone shed any light on this subject?  Is SynOptics on the net anywhere?

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 16:33:09 GMT
From:      naitc!naitc!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   "Strange Telnet Option 242" on ISC 2.2
Hi everyone,

We're using NCSA Telnet with ISC 2.2, and seeing a rather odd thing from the
package.  The number "2" is coming up once in a while, accompanied (on the
message screen) by the message "Strange Telnet Option 242".

Any ideas why only the ISC machines would do this, and not any of our
network of Sun Workstations?  This didn't happen under 2.0.2's TCP/IP...
We'd really like to stop it from happening!

Any assistance appreciated!

--
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.
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 17:44:11 GMT
From:      sgi!artibee%noangel.wpd.sgi.com@ucbvax.Berkeley.EDU  (Mary Artibee)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip performance
> I am interested to some tests for doing performance
> evaluation of TCP/IP, any suggestions ?

You might consider "ttcp"...

>From vjs@rhyolite.wpd.sgi.com Sat May 12 19:04:05 1990 (Vernon Schryver)
Organization: Silicon Graphics, Inc., Mountain View, CA
Newsgroups: comp.protocols.tcp-ip
Subject: Re: "ttcp" program

Ttcp is handy for tuning a TCP or UDP implementation.

Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently
192.48.153.1.  ttcp.c.brl is the most recent BRL version I've seen.
Ttcp.shar is from last August.  Ttcp.c is our current understanding of what
was acceptable to BRL.  It includes controls for buffer alignment and other
things.  By default it is a file transfer program, needing '-s' to make it
generate and sink data as a test program.

I think there are also versions available from BRL, perhaps on brl.mil.
They are probably newer than sgi:.../ttcp.c.brl.

Ttcp has never appeared in comp.sources.unix, although I understood from
the moderator that it would someday.  If you buy a Silicon Graphics "IRIS",
you'll find ttcp.c among other example and test programs in
/usr/people/4Dgifts.

There was some hassle with the port number.  The original port 2000
conflicted with a certain solar window manager, currently the default
window manager for SGI.  BRL and SGI checked with the Net Gods about
getting an official port number for ttcp, but failed.

Be careful to understand the numbers people give you.  Not long ago a
vendor trying to sell stuff gave me what I thought were some good numbers.
A few weeks later they happened to mention to some of my colleagues that
the numbers were obtained by summing some simultaneous tests.
It is as they say, "lies, damn lies, and benchmarks."

Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 18:07:14 GMT
From:      ingea@IFI.UIO.NO (Inge Arnesen)
To:        comp.protocols.tcp-ip
Subject:   LAN Manager and UNIX

Today, years after the release of OS/2 and LAN Manager, som people believe
that LAN Manager will become _the_ network standard for interoperability
between DOS, OS/2 and UNIX boxes, and also take a big chunk of the 
UNIX to UNIX market within the next 3 years!

This is suppose to happen on all levels:

 - Named pipes will replace TLI & sockets. RPC-libs will be based on named 
   pipes.

 - File sharing will replace NFS (and RFS :-).

 - Printer sharing will replace the braindead UNIX remote lpd.

 - LAN Manager autentication will become the standard security and 
   autentication system.

The event that is supposed to trigger this drastic change is the release of
the portable LAN Manager server (LMX) which is due in Desember.

I must admit that LAN Manager have superior solutions to some the solutions
available on UNIX today, but I can't see how LM can get a grip on the UNIX
market this late.  LM is a something that grew out of the MS DOS (and later
OS/2) world, which is not regarded as kosher among UNIX people, and it does not
offer any great leap in functionality compared to what we have on UNIX today.

I would like arguments for and against LM as a standard taking marked shares
OUTSIDE the DOS / OS/2 environments, and I welcome both well founded
arguments as well as statements like : "I don't like the feel of the API..".

Have any UNIX vendors said how they will relate to LM ?
If only Microsoft and PC SW vendors support LM, LM will probably remain
in the PC world.......






Inge (BoB)  { ingea@ifi.uio.no }
=========================================================================
==   Inge Arnesen, University of Oslo, Norway.                         ==
==                                                                     ==

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 19:17:27 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Looking for (a working) NFS for VMS

Well, we've been bitten once more by Wollongong's TCPIP for VMS.
I have found out today that their NFS cannot understand enough
of the UNIX file commands to even be usable.  (No chown, No permissions,
No link())
Does anyone know if any of the other TCPIP implemntations support
NFS?? And does it work well enough to be used with a UNIX system??
And of course can it used a shared ethernet interface on the VAX??
I still have to support LAT as well.

Any help??

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 19:30:37 GMT
From:      anarchy@tardis.cs.ed.ac.uk (Alan Cox)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <JIM.90Sep7132657@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>>
>>  As to running tcp/ip over janet, any reason you couldn't run slip over a
>>   coloured book terminal session ?
>>
>Yes. The JNT wouldn't like it. What you're proposing is not very
>efficient: a better (and easier) option is to put IP datagrams inside
>X.25 frames. That too would upset the JNT since you'd be running
>something other than CB on JANET.
>
>		Jim
Oh dear.. does that mean they don't like people running kermit over janet
lines, after all kermit is a file transfer protocol and it's not in the
coloured books (not even the yellow and purple spotty one 8-)), does seem
to be a certain amount of a red tape factory running here. Maybe the planned
shakeup of the steering committes of janet is a good thing.

--------------------------------------------------------------------------------
Everything is hereby disclaimed.. if a superbeing can give me this for a working
universe, then I can give him back buggy software too.
--------------------------------------------------------------------------------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Sep 90 08:08:15 -0700
From:      Marshall Rose <mrose@cheetah.ca.psi.com>
To:        bushell@hawk.nstn.ns.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP info and TCP/IP test programs
Send a note to snmp-request@nisc.psi.net and ask to be added to the snmp
list.

/mtr
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 90 22:38:49 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   sockets vs. streams archive

Since the ``sockets vs. streams'' discussion generated quite a bit of
material that should be useful for future implementors, I have archived
it and made it available via anonymous ftp to stealth.acf.nyu.edu, or
128.122.128.22. The unedited articles are in pub/socketstream.

This should be easier than searching your local tcp-ip archive...

---Dan

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Sep 90 12:35 EST
From:      Bob Stine <0004219666@mcimail.com>
To:        Tom Bushell <bushell@hawk.nstn.ns.ca>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: SNMP info and TCP/IP test programs
Check RFC 1147 for availability info on ttcp.

- Bob Stine
  Applied Cybernetics, Inc.


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 08:21:22 GMT
From:      andrewf@syacus.acus.oz (Andrew Friedman)
To:        comp.protocols.tcp-ip
Subject:   Telnet vs. X.29 (Was: Internet routing Europe - USA -} Europe...)

jim@cs.strath.ac.uk (Jim Reid) writes:

[Lots of Good Stuff comparing CB and IP protocols deleted]
>... Don't forget that telnet is functionally
>superior to X.29: it offers more for roughly the same overheads.

Are you sure about this? I would have said it the other way around, but
I'll admit I don't know Telnet as well as X.29. What's the problem?
Have you seen RFC 1053 which proposes adding X.3 parameters into Telnet?

Andrew

Note: Original article appeared in uk.misc,eunet.followup also. I can't post
to these.

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Sep 90 09:13:50 GMT
From:      bushell@hawk.nstn.ns.ca (Tom Bushell)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP info and TCP/IP test programs

Hello,

We're working on an IP router that will support SNMP.  I haven't
seen any SNMP info on the TCP/IP news group in the week or so I've
been on.  Is there another news group for SNMP?  We have the SNMP
RFCs - what other sources have people found useful?  I will
summarize and publish any responses.

Also, we are looking at ways to test our router.  I've been told
there is a program called "ttcp" ("Test TCP") that may be useful. 
Does anybody know where I can get this program, if it exists?

                                     Thanks in advance,

                                     Tom Bushell
                                     SKL                          
                                     bushell@hawk.nstn.ns.ca
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Sep 90 16:59:51 PDT
From:      braden@venera.isi.edu
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Cc:        braden@venera.isi.edu
Subject:   IAB meeting minutes available

Minutes of the IAB meeting held in April 1990 are available for anonymous
FTP from host venera.isi.edu with pathname:

      pub/IABmins.apr90.txt

Bob Braden
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 11:21:31 GMT
From:      agate!linus!nixbur!nixpbe!peun33!gla@apple.com  (R. Glaschick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAN Manager and UNIX
In <CMM.0.88.653076397.ingea@svarte.ifi.uio.no> ingea@IFI.UIO.NO (Inge Arnesen) writes:


>Have any UNIX vendors said how they will relate to LM ?
>If only Microsoft and PC SW vendors support LM, LM will probably remain
>in the PC world.......

Siemens Nixdorf has ported LM/X to Targon and MX machines and will sell
and support it as a product ASAP.
(Depends on final release, testing, licence etc).
The first release will to my knowledge aimed towards PCs (DOS & OS/2) linked
to a Targon or MX, and not so much for UNIX to UNIX links.

--
Rainer Glaschick, NIXDORF Computer AG, Paderborn, W-Germany
EMail: glaschick.pad@nixdorf.com (US) or  glaschick.pad@nixdorf.de (EU)
Tel. +49 5251 14 6150 (office) +49 5254 6238  (home) Fax: +49 5251 14 6569
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 13:31:58 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN Manager and UNIX

In a recent article ingea@IFI.UIO.NO (Inge Arnesen) writes:

[On Lan Manager/X...]

>Have any UNIX vendors said how they will relate to LM ?
>If only Microsoft and PC SW vendors support LM, LM will probably remain
>in the PC world.......

At least AT&T, HP and DG supports Lan Manager/X under their respective
UNIX implementations.

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
                                |  Perverse mailers: rclaeson%erbe.se@encore.com
These opinions reflect my personal views and not those of my employer (ask him).

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 15:03:14 GMT
From:      dftsrv!hq!lgn!terry@ames.arc.nasa.gov  (Terry Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RoboDoc
Why weren't any .mil sights reported on in the RoboDoc report?????


-- terry --

--
------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>   Terry Bernstein        <<terry@hq.af.mil<<<
>"Who is John Galt?">	          	       << The Pentagon  <<<
--------------------------------------------------------------------
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 15:31:37 GMT
From:      jian@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   Looking for TELNET source codes

Could someone out there tell me where I can get UNIX TELNET source codes via
FTP. Any indication appreciated.

Jian Q. Li
jian@kuhub.cc.ukans.edu

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 16:56:22 GMT
From:      pcaloca@synoptics.COM (Paul Caloca)
To:        comp.protocols.tcp-ip
Subject:   Re: SynOptics compatability

In article <9009112007.AA08799@ucbvax.Berkeley.EDU>, 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
> I have a question for any SynOptics users out there.
> I currently have a building wired using SynOptics 1000's and UTP.
> We plan to extend the network to other building on Campus and wanted to
> do it using Fiber.  Does anyone know if the Fiber connections on a SynOptics
> 1000 (a 201-ST board) are compatable with the newer 3000 series
> concentrators??  If not, I can still get around it, but the configuration
> will change considerably.
> 
> Can anyone shed any light on this subject?  Is SynOptics on the net anywhere?
> 
>                                           bill gunshannon
>                                        702WFG@SCRVMSYS.BITNET



The 201-ST board has been discontinued for over well a year and is not
compatible with the 3000 concentrator. The 201-ST uses a proprietary
fiber transmission protocol while all 3000 series fiber modules use
the Fiber Optic Inter-Repeater Link (FOIRL) industry standard protocol.
The 504 fiber optic transceiver also uses FOIRL and cannot be used
with the 201-ST. The best option is to upgrade your 201-ST board to a
207-ST FOIRL Retiming Module if retiming is used in that concentrator
or use a 208-ST Termination Module if only backplane termination is
required.


========================================================================
Paul Caloca			| "Minds are like parachutes -
Technical Support		|  they ony function when open."
SynOptics Communications	|
Mountain View, CA		|==================== Thomas Dewar
Email:  Paul_Caloca.SALES@engtwomac.synoptics.com
UUCP: ...!ames.arc.nasa.gov!synoptics.com!engtwomac!Paul_Caloca.SALES
FAX: 415-964-0407            
========================================================================

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 17:33:03 GMT
From:      dftsrv!hq!martin@ames.arc.nasa.gov  (Gregory.J.Martin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RoboDoc
In article <terry.653151794@lgn> terry@hq.af.mil (Terry Bernstein) writes:
>Why weren't any .mil sights reported on in the RoboDoc report????>
>-- terry -

C'mon Terry, you know as well as I, the military nets are managed perfectly.
Like yours, for instance!!!
...Greg Martin (No, the AF won't let me speak for it. Darn!!)
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 17:35:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP info and TCP/IP test programs

Check RFC 1147 for availability info on ttcp.

- Bob Stine
  Applied Cybernetics, Inc.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 17:38:47 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets vs streams.  An attempt to answer the original question
On 4 Sep 90 17:29:23 GMT, lars@spectrum.CMC.COM (Lars Poulsen) said:

lars> In article <1990Aug28.162400.17811@zoo.toronto.edu>
lars> henry@zoo.toronto.edu (Henry Spencer) writes:

spencer> The way to do i/o on Dennis's streams was with "read" and
spencer> "write".  Network i/o, in general, looked *exactly* like local
spencer> device i/o.

If you want to keep UNIX like semantics. Unfortunately you really want
to do typed data, if only to include passing file descriptors, and OOB
signaling, and these do not fit well with traditional UNIX style
interfaces.

spencer> This is the way it should be, unlike what both Berkeley and
spencer> AT&T have done (both have reluctantly conceded that most people
spencer> want to use "read" and "write" and have made that work, but
spencer> their hearts were clearly elsewhere).

lars> In article <PCG.90Sep2194524@athene.cs.aber.ac.uk>
lars> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

pcg> And for good reason! read() and write() on file descriptors is not
pcg> the most amusing interface. It is much more convenient to have ...
pcg> [features]

Hey, I take exception to the [features] summary -- I was describing not a
set of extra features, but a completely different philosophy based on
communication with active entities represented by IPC ports. An
alternative to the UNIX style file descriptors to access passive files.
It can be as simple and terse as the current UNIX style.

lars> The problem is larger than that. As commercial programmers have
lars> often said, unix read() and write() is not a very good interface
lars> for files, either. It is a good interface for SIMPLE TEXT files,
lars> and very little else.

Uhm. Here we differ. The UNIX style of accessing file is excellent for
any type of file, because any type of file can be mapped onto untyped
byte arrays (a.k.a. virtual memory segments), by the use of suitable
library procedures. Unfortunately non storage like entities are not
easily mapped onto untyped byte arrays.

lars> Having a guaranteed subset of compatible functionality has allowed
lars> very productive use of the "building block" philosophy. Having a way to
lars> specify a remote conenctions "as if" it were a filename would allow more
lars> things to be prototyped with simple shell scripts and pipelines.

The problem is that modeling everything as a passive entitity is far less
flexible than modling everything as an active entity.
--
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
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 20:40:07 GMT
From:      martin@hq.af.mil (Gregory.J.Martin)
To:        comp.protocols.tcp-ip
Subject:   Re: SynOptics compatability

In article <9009112007.AA08799@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
>I have a question for any SynOptics users out there.
>I currently have a building wired using SynOptics 1000's and UTP.
>  Does anyone know if the Fiber connections on a SynOptics
>1000 (a 201-ST board) are compatable with the newer 3000 series
>concentrators??  If not, I can still get around it, but the configuration
>will change considerably.
>
>Can anyone shed any light on this subject?  Is SynOptics on the net anywhere?
>
>                                          bill gunshannon
>                                       702WFG@SCRVMSYS.BITNET

The fiber connections on both these products are identical.  I went to a
design class run by SynOptics (okay, it was a glorified sales pitch!) and we
combined both product line together all the time.  I'll be their engineers
will say the same thing.  Just make sure you get the right type of fiber
connectors for the concentrator on that end of the "wire" and all should run
fine.  We love our SynOptics, especially their Network Management Control
Console.  It saves us a lot of debug time!!  If you have any questions e-mail
me at martin@hq.af.mil.

...Greg Martin (No, The Air Force won't allow me to speak their mind!!)

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 22:23:20 GMT
From:      olivea!orc!inews!iwarp.intel.com!psueea!parsely!percy!data!john@apple.com  (John Mantey)
To:        tcp-ip@nic.ddn.mil
Subject:   PD/Commercial TCP/IP packages

I'm trying to establish a TCP/IP link between a 386 PC running Windows
3.0 and a 386 PC running VRTX.  My goal is to get an effective
throughput of 100K bytes/sec.  I started with MIT/CMU public domain
version of PCIP, circa March '86, and got them talking, but the
throughput was orders of magnitude too slow.  

I have info on FTP's implementation, but I want to get info on other
implementations also.

Please email me if you're familiar with any PD or commercial versions
of TCP/IP.  If its a commercial version, I either need access to the
source, or the ability to integrate it with our product.  Thanks.

Tom Baker    tom@data.uucp               Microtek International, DSD
-----------------------------------      3300 NW 211th Terrace
#include <std.signature>                 Hillsboro, Or 97124
                                         503-645-7333
-- 
John Mantey    john@data.uucp            Microtek International, DSD
-----------------------------------      3300 NW 211th Terrace
Not bird, nor plane, nor even frog.      Hillsboro, Or 97124
Just little old me, Underdog.            503-645-7333
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 90 23:01:31 GMT
From:      harvisr!sob@husc6.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   hey wait a minute ...
I was more than a little surprised to hear the other day that I was on
contract to Wellfleet.  At least that was what some people were saying.

Well it is not true.  To do anything like that might put a bit of a 
taint on the testing results that I've been reporting. :-)
Full disclosure time:  I have done & continue to do some consulting,
but I have not done and am not doing any with any of the vendors of devices
that I'm now testing. (Hey, I even chose not to buy any cisco stock, 
dumb move?)

Like with many tall tales there may be a slim germ of truth somewhere
in it.  Here is the story I tell the router vendors that call & offer
to send me a router for testing.

Back about 2 months ago I got a call from Proteon saying that they
had fixed the problems that we had found last year & had improved the
throughput by quite a bit, and could we give the new code a test? (This
was on a voice mail message.)  The same day I got a call from someone at
Wellfleet asking, in effect, why was I not doing a new round of tests since
it had been a while since the last batch.

say I:  "Well I don't have good enough equipment to do the tests required &
	there ain't no way to get the kind of funding required here at Harvard"
said he: "Well we can donate/loan you a test setup we have built."
say I:  "Humm", (then to self, "I don't see any other way to do something
	before Interop but what would the other vendors think?")  "Why don't
	I come out and talk about it?"

so I did.

What came of it was an informal agreement (nothing on paper) for Wellfleet
to loan Harvard some equipment & agree to have the person who had done their
software make "a few" changes/additions to what he had done to make the
tests more like what the Benchmarking Methodology Working Group had been
discussing.  Wellfleet also agreed that they would work out a way that
other organizations could get access to the equipment in the future
if there was enough interest.  Access to the source code was also offered.

( an aside, the test packet generator is a Wellfleet router with special
software.  It is setup with pairs of ethernet ports.  One port of each
pair is used to produce packets right fast, the second port is used to
produce the "keep alive" traffic required to convince some protocols
that there is a node out there.)

Now, I fully expect that Wellfleet is not 100% altruistic in their offer,
they expect to have their box do quite well in the tests & the results
will look better coming from a independent source than they would from
Wellfleet.  It might & it might not (I've not bashed it yet, I'm starting
in on it tomorrow.) but the tests will be fair and open.  The same tests
will be run on all routers.

Also, Dan Lanciani & I  (mostly Dan) have come up with a "simple" hardware
design for a card to put in a PC along with a NI5210 to replicate the
total functionally of the Wellfleet hardware.  We will produce the card asap
and redo some or all of the tests with the new hardware as a final check.
Software will be written to automaticly run a series of tests and produce
the results as the BMWG RFCs will describe.
(The source to the test software and the artwork for the board will
be placed for anonymous ftp.)

I've told this story to all of the vendors when they call wanting to test 
a router, none of them have expressed reservations about the arrangement.

I'm sorry that I did not mention it in the 1st posting but I was still
working out the details.  It was a mistake to not wait.  But hindsite
is easy...

Scott

PS - bashing update
	here to be tested or dates set:

	Proteon (P4200 & RIG)
	Wellfleet
	3com
	cisco
	NSC
	Timeplex
	and (I think) BBN
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Sep 90 06:36:13 PDT
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        brian@ucsd.edu (Brian Kantor)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: RoboDoc
It is perfectly proper to list more then two servers for a domain.
Of course, the more separate (power supplies, Ethernet cables, etc.)
they are the more reliability of the overall system improves.
Similarly, you cannot take advantage of a server that you do not know
about, so you have to advertise it.

paul
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 02:36:10 GMT
From:      del@thrush.mlb.semi.harris.com (Don Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: RoboDoc

Dear RoboDoc,

If you really want to have some fun, start poking around under
in-addr.arpa.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 08:10:11 GMT
From:      mcsun!ukc!icdoc!citycs!sb380@uunet.uu.net  (Andy Holt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet routing Europe - USA -} Europe...
In article <4862@tardis.cs.ed.ac.uk> anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes:
>Oh dear.. does that mean they don't like people running kermit over janet
>lines, after all kermit is a file transfer protocol and it's not in the
>coloured books (not even the yellow and purple spotty one 8-)), does seem
>to be a certain amount of a red tape factory running here. Maybe the planned
>shakeup of the steering committes of janet is a good thing.
>
Technically they don't! Mentioning Kermit at a Networkshop was a good way
to get very black looks from JNT members (just like TCP/IP). The standard 
joke was "if it works and is a **de facto** standard, it is clearly
unacceptable".
Of course though the frog is the only viable file transfer protocol for
some brain-damaged mainframes, newer (also de-facto) standards like
zmodem give much better performance over phone lines.

Andy

--------------------------------------------------------------------
"I like to have lots of standards so I can choose which ones to abuse"
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 09:04:27 GMT
From:      cur022@zodiac.ukc.ac.uk (Bob Eager)
To:        uk.misc,eunet.followup,comp.protocols.tcp-ip
Subject:   Re: Internet routing Europe - USA -} Europe...

In article <4862@tardis.cs.ed.ac.uk>, anarchy@tardis.cs.ed.ac.uk (Alan Cox) writes:
> Oh dear.. does that mean they don't like people running kermit over janet
> lines, after all kermit is a file transfer protocol and it's not in the
> coloured books (not even the yellow and purple spotty one 8-)),

Actually, they don't like it! Kermit is like a red rag to a bull as far as
the JNT are concerned....
---------------------+-----------------------------------------------------
Bob Eager            | University of Kent at Canterbury
rde@ukc.ac.uk        | +44 227 764000 ext 7589
---------------------+-----------------------------------------------------
*** NB *** Do NOT use the return path in the article header ***************
---------------------------------------------------------------------------

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Sep 90 18:01:30 -0400
From:      Hans-Werner Braun <hwb@merit.edu>
To:        manta!gutman@nosc.mil, tcp-ip@nic.ddn.mil
Subject:   Re:  internet routing protocols- general questions...
The NSFNET Backbone runs the ANSI/ISO IS-IS protocol as its IGP since
mid 1988. It uses EGP and BGP to communicate with its client networks.

	-- Hans-Werner
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 11:41:09 GMT
From:      ssb@quest.UUCP (Scott S. Bertilson)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems
Subject:   terminal servers w/modems (dial-in/out)


  I've just been trying out the Xyplex terminal servers and was
pleased to discover that they allow a mode where a given port
can be used either for dialing in or dialing out - depending
on whether the modem sees carrier first or a host requests
a connection to the port first.  It generally works just
like I'd hope it would except that their box currently doesn't
allow hardware flow control AND modem control simultaneously.
  I've also looked at an Altos version of a 10 port CMC terminal
server which does have enough hardware lines to support both,
but doesn't support what Xyplex calls "port access dynamic".
I'm wondering if this is the case for the real CMC box or if
it's a restriction that Altos applied.
  Are there any other terminal servers other than Xyplex that
support bidirectional modem use?

  A related topic is that in order for this to be truly useful,
"uucico" and "cu" need to be able to make a TCP/IP connection.
I know that 4.3 allows this, but I'm running SCO UNIX 3.2 and
Altos version of AT&T SVR3.1.  I'm less familiar with SCO, so
I might be missing something, but as far as I know, it doesn't
allow this.  It is possible in both of these environments to
make ISO streams connections using the NLS (I'm very short on
knowledge of terms/semantics here), but as far as I can see
there is no way to make a TCP/IP connection.  Any ideas?
  The only idea I've had is that perhaps one could write a server
under streams that would accept connections and pass the data
across to a (Lachmann) TCP/IP socket.  If anyone has done this
or tried, I'd sure like to see code or fragments thereof.
			Thanks!
-- 

Scott S. Bertilson   ...ssb@quest.UUCP
			scott@poincare.geom.umn.edu

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 14:54:07 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   TCP beating JANET? not the last 3 days!


That was some case of indigestion. Traceroute barfed all over
the dustbowl. I got dumped before, during, and after jvnc, net 14 
(nsf-relay.ac.uk 2nd IP address) kept smiling through, ucl cisco 
was reachable and then not (peek-a-boo!) and all because the 
lady loves milktray.

[ok, provokative Subject: On a more "serious" note an outage 
 like that is *not* good sales copy]

Anybody know which box did what to whom?  wash some linin in public!

-My guess is french anti-AWAC jammers blew the brains out of the wires

	-George
-- 
	G.Michaelson
Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          The University of Queensland, St Lucia, QLD Australia 4067. 

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 15:44:47 GMT
From:      olson@sax.cs.uiuc.edu (Bob Olson)
To:        comp.protocols.tcp-ip
Subject:   DialupIP

I'm looking for an implementation of DialupIP (I think it's called; it
is a point-to-point version of SLIP) for a Sun sparc or DECstation. Is
there one out there somewhere??

--bob

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 16:21:07 GMT
From:      dheeraj@cs.umd.edu (Dheeraj Sanghi)
To:        comp.protocols.tcp-ip
Subject:   Packet reordering


Recently, we have seen massive reordering of packets in the internet.
Previously, when we noticed reordering, it was always 2 packets
who have been sent together, reach in the opposite order. But now we are
seeing as much as 10 packets sent at the rate of 1 packet per clock
tick (10 ms) reaching exactly in the opposite order. We have not yet
figured how to reproduce it at will, but we have seen it quite often.
Here is some data from our observations.


	PKT#	Sendtime	Recvtime	Delay

	3	160		370		210
	4	170		360		190
	5	180		360		180
	6	190		350		160
	7	200		350		150
	8	210		340		130
	9	220		340		120
	10	230		330		100
	11	240		320		80
	12	250		320		70

	13	260		400		140

(All times in ms.)

We are using DTP, an in-house protocol with the same functionality
as TCP. We are using IP, so it shouldn't really matter what transport
layer protocol we use. The route being taken is (from the traceroute
program):

	rhodes.cs.umd.edu	128.8.128.1
	mrb-gw.umd.edu		128.8.109.1
	bogon-gw.umd.edu	128.8.253.7
				128.167.102.2
				128.167.104.1
	sura1.sura.net		128.167.1.1

We are using IP_LSRR option to send packet to sura1.sura.net
and back. Both sender and receiver programs are on
huginn.cs.umd.edu (128.8.128.35). The acknowledgements are
sent within machine.

We have also tried sending packets upto various intermediate gateways
and have seen reordering from all gateways except rhodes and mrb-gw.
(The first two gateways.)

Any ideas as to what is causing the whole block of packets to
reorder and reach the destination in exactly the opposite order.


Dheeraj Sanghi (dheeraj@cs.umd.edu)

Ashok Agrawala (agrawala@cs.umd.edu)

--
Dheeraj Sanghi			(h):301-794-6247	(o):301-405-2723
Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!dheeraj
	When you find you are on the side of the majority,
	it is time to reform.		- Mark Twain

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 17:53:08 GMT
From:      kwe@buit13.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: hey wait a minute ...

In article <4160@husc6.harvard.edu> sob@harvisr.UUCP (Scott Bradner) writes:
>I was more than a little surprised to hear the other day that I was on
>contract to Wellfleet.  At least that was what some people were saying.
>
>Well it is not true...
>
>Like with many tall tales there may be a slim germ of truth somewhere
>in it.
>
>Scott
>
	Well, I read your story about Wellfleet donating some test
equipment for your router bashing and I think you're wrong.

	There isn't even a slim germ of truth indicating any conflict
of interest.

	I think what you have found is an unusual level of general
excitement on the part of commercial people who smell a large new
market and think Scott Bradner and his router bashing might be the key
to their getting a piece of that market.

	You're in the spotlight, but I, for one, feel more comfortable
about that than what we had before; which was a bunch of vendor
engineers and marketing people pushing, shoving, yelling, and lying
about their bridge and router performance.  At this point, we are
beginning to see some semblance of order, sort of like when the
teacher walks into the classroom and the spitballs stop flying.

	--Kent

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 19:13:47 GMT
From:      jimb@faatcrl.UUCP (Jim Burwell)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Toronto SLIP, CSLIP, and SunOS 4.1

Hello..

Has anyone had any experience running Toronto SLIP under SunOS 4.1 ?
From reading the documentation which came with SLIP/CSLIP, it doesn't seem
possible.  We're running 4.0.3 right now, but we just got 4.1.  I'm afraid
to install it though since it looks like it would break slip, and possibly
our dialin, dialout, and UUCP connections.  Are there fixes out there for
the streams drivers which will take care of the problems described in the
Toronto SLIP docs ?

Thanx in advance for any info,

Jim


-- 
UUCP:  ...!rutgers!faatcrl!jimb              Internet:  jimb@faatcrl.UUCP
		Under brooding skys and watchful eyes
		On convulsive seas of false urgency
		We walk empty corridors in vain - "No Exit", Fate's Warning

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 90 19:59:44 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.tcp-ip
Subject:   Re: terminal servers w/modems (dial-in/out)

In a recent article ssb@quest.UUCP (Scott S. Bertilson) writes:

>  I've just been trying out the Xyplex terminal servers and was
>pleased to discover that they allow a mode where a given port
>can be used either for dialing in or dialing out - depending
.....

>  Are there any other terminal servers other than Xyplex that
>support bidirectional modem use?

Yes, the Annex series of terminal servers from Xylogics and
Encore Computer has supported bidirectional ports since many
years ago.

>  A related topic is that in order for this to be truly useful,
>"uucico" and "cu" need to be able to make a TCP/IP connection.
>I know that 4.3 allows this, but I'm running SCO UNIX 3.2 and
>Altos version of AT&T SVR3.1.

If you have Streams and/or TLI access to TCP/IP, it is possible.
It's just a matter of setting up the Devices and related files
correctly (provided your system actually use HDB uucp that
the System V Release 3.1 code is delivered with from AT&T).
See the documentation for "BNU" (Basic Networking Utilities).

I recently tried this but can't remeber the details. But it
was easy. Make sure to use the "e" protocol for best performance.

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
                                |  Perverse mailers: rclaeson%erbe.se@encore.com
These opinions reflect my personal views and not those of my employer (ask him).

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 00:12:01 GMT
From:      agate!bionet!ucselx!sol.ctr.columbia.edu!emory!samsung!crackers!m2c!umvlsi!umaecs!amh!gehallert@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   <None>
In article <1990Aug29.153353.13564@math.lsa.umich.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
> Archive-name: clarkson-packet-drivers/29-Aug-90
> Original-posting-by: nelson@sun.soe.clarkson.edu (Russ Nelson)
> Original-subject: Clarkson packet drivers 7.x now available
> Archive-site: sun.soe.clarkson.edu [128.153.12.3]
> Archive-directory: /pub/ka9q
> Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)
> 
> The 7.x release of the Clarkson collection of packet drivers is now
> available.  The summary is given below.  In addition to the new
> drivers and bug fixes, a switch has been added that lets you use
> Novell without econfiging your server.
> 
> Summary:
> 	New drivers: UB PC/NIC, LocalTalk, Tiara, NTI.
> 	Bugs fixed: 3c505, 3c503, wd8003e, nb, ne1000.
> 	Bug found but not fixed: 3c523.
> 
> The packet drivers are for MS-DOS, and serve to hide the difference between
> network cards, and allow multiple protocol stacks to access the same card.
> Most often people are interested in running Novell's Netware and TCP/IP
> at the same time.
> 
> 		The Clarkson packet driver collection
> 
> Availability
> 
> The Clarkson collection of packet drivers is available by FTP, by
> archive-server, and by modem.  They come in two flavors -- executables
> only (drivers.arc), and source+executables (driverss.arc).  All of the
> following instructions apply to both drivers.arc and driverss.arc.
> 
> Mail:
> 
> I distribute the packet drivers on a 1.2 MB 5.25" disk, or a 720K 3.5"
> disk.  You can send me a check for $20, or you can send me a purchse
> order and I will bill you for $22.  NY residents add 7% sales tax,
> overseas orders add $3 for shipping.  If you send a check, please be
> sure it is in US dollars -- the bank charges me $15 to convert checks
> drawn in foreign currencies.
> 
> 	Russell Nelson
> 	11 Grant St.
> 	Potsdam, NY 13676
> 
> FTP:
> 
> sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
> grape.ecs.clarkson.edu:/e/tcpip/drivers.arc
> 
> Archive-server:
> 
> Send mail to archive-server@sun.soe.clarkson.edu and put the following
> command as the body of your message:
> 	help
> This will send you a help message.  Reading this help message will tell
> you how to fetch the packet drivers.
> 
> Modem:
> 
> Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
> 1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.
> 
> -- 
> --russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
> We won the cold war.  The Russians spent trillions defending their stuff,
> then they found that they didn't have any stuff.  Will we avoid the same trap?
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Sep 90 14:15:44 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '91 Call for Papers

[Hi folks -- SIGCOMM '90 is just around the corner so it's time for me to
start trolling for papers for SIGCOMM '91 -- craig]

		    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: gfw@pueblo.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.
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Sep 90 15:36:30 PDT
From:      DDN Reference <NIC@NIC.DDN.MIL>
To:        tcp-ip@NIC.DDN.MIL
Cc:        nic@NIC.DDN.MIL
Subject:   NIC.DDN.MIL host problem
The NIC.DDN.MIL host suffered a serious systems failure that caused
significant amounts of mail to be lost. If you have sent a message to us
between Wednesday afternoon (12 Sep) and Friday morning (14 Sep) Pacific
Daylight Time, please send it again.

Examples of major mailing lists on the NIC machine that you might have
attempted to reach are:

	NIC@NIC.DDN.MIL
	HOSTMASTER@NIC.DDN.MIL
	REGISTRAR@NIC.DDN.MIL

Apologies for the large distribution, the NIC is trying to reach
many sites with this notice. Thanks for your patience.

The DDN NIC Staff
-------
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Sep 90 17:28:38 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet/telnet release

A new BSD version of telnet and telnetd are now available for anonymous
ftp from ucbarpa.berkeley.edu.  There are two files:

	pub/telnet.90.09.14.tar.Z	All the sources
	pub/telnet.90.09.14.diff.Z	Diffs from telnet.90.06.28

This release contains mostly bugfixes, and some POSIX changes.
If you are using one of my earlier version of telnet/telnetd, you'll
probably want to get this new version.  My list of changes started
out pretty small, but then as time went by, more and more little
problems were discovered.  There are no major functionality changes
with this release.  If you have to make changes to get this code
running on your machine, please send me the changes and I'll try
to get them into the next release.

			-David Borman, dab@cray.com

This list was extraced from the README giving more detail as to what
is changed with this release:

	Switch the client to use getopt() for parsing the
	argument list.  The 4.3Reno getopt.c is included for
	systems that don't have getopt().

	Use the posix _POSIX_VDISABLE value for what value
	to use when disabling special characters.  If this
	is undefined, it defaults to 0x3ff.

	For non-termio systems, TIOCSETP was being used to
	change the state of the terminal.  This causes the
	input queue to be flushed, which we don't want.  This
	is now changed to TIOCSETN.

	Take out the "#ifdef notdef" around the code in the
	server that generates a "sync" when the pty oputput
	is flushed.  The potential problem is that some older
	telnet clients may go into an infinate loop when they
	receive a "sync", if so, the server can be compiled
	with "NO_URGENT" defined.

	Fix the client where it was setting/clearing the OPOST
	bit in the c_lflag field, not the c_oflag field.

	Fix the client where it was setting/clearing the ISTRIP
	bit in the c_lflag field, not the c_iflag field.  (On
	4.3Reno, this is the ECHOPRT bit in the c_lflag field.)
	The client also had its interpretation of WILL BINARY
	and DO BINARY reversed.

	Fix a bug in client that would cause a core dump when
	attempting to remove the last environment variable.

	In the client, there were a few places were switch()
	was being passed a character, and if it was a negative
	value, it could get sign extended, and not match
	the 8 bit case statements.  The fix is to and the
	switch value with 0xff.

	Add a couple more printoption() calls in the client, I
	don't think there are any more places were a telnet
	command can be received and not printed out when
	"options" is on.

	A new flag has been added to the client, "-a".  Currently,
	this just causes the USER name to be sent across, in
	the future this may be used to signify that automatic
	authentication is requested.

	The USER variable is now only sent by the client if
	the "-a" or "-l user" options are explicity used, or
	if the user explicitly asks for the "USER" environment
	variable to be exported.  In the server, if it receives
	the "USER" environment variable, it won't print out the
	banner message, so that only "Password:" will be printed.
	This makes the symantics more like rlogin, and should be
	more familiar to the user.  (People are not used to
	getting a banner message, and then getting just a
	"Password:" prompt.)

	Re-vamp the code for starting up the child login
	process.  The code was getting ugly, and it was
	hard to tell what was really going on.  What we
	do now is after the fork(), in the child:
		1) make sure we have no controlling tty
		2) open and initialize the tty
		3) do a setsid()/setpgrp()
		4) makes the tty our controlling tty.
	On some systems, #2 makes the tty our controlling
	tty, and #4 is a no-op.  The parent process does
	a gets rid of any controlling tty after the child
	is fork()ed.

	Use the strdup() library routine in telnet, instead
	of the local savestr() routine.  If you don't have
	strdup(), you need to define NO_STRDUP.

	Add support for ^T (SIGINFO/VSTATUS), found in the
	4.3Reno distribution.  This maps to the AYT character.

	The client is now smarter when setting the telnet escape
	character; it only sets it to one of VEOL and VEOL2 if
	one of them is undefined, and the other one is not already
	defined to the telnet escape character.

	Handle TERMIOS systems that have seperate input and output
	line speed settings imbedded in the flags.

	Many other minor bug fixes.
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 16:05:45 GMT
From:      bu.edu!buit13!kwe@uunet.uu.net  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   A Point about Style in Advertising

	Back in the old days before the Internet was commercialized
:-), there was a custom of not posting articles of purely commercial
value on Internet mailing lists (and many Usenet newsgroups), because
the Internet was overwhelmingly a subsidized research network.

	Posters would take pains, in answering requests for "something
that does X", to at least mention their competitors' products before
giving their advice on how to use their own commercial product.  It
seemed like a nice touch that made the intent of the posting seem more
informational than commercial.  Those people (and I am thinking about
one in particular) still post articles of noteworthy breadth and
brevity, and those postings make me respect their own products the
more.

	Perhaps there are as many of the old-style informational
postings as there ever were, but there are many more posters who don't
bother these days, so it seems as if there is less informational
content overall, in my opinion.

	I miss those old fashioned postings.  Purely commercial
blather I can get elsewhere.  From the Internet, I expect better.
Would it be so much trouble to put a little more information, a little
more survey, and a little less marketing boilerplate in your public
offerings to this and other lists/newsgroups?  Really, I think it
would help you more than not, in terms of public perception.

	Thank you for your support.

	--Kent
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 16:46:43 GMT
From:      hpda!hpcuhb!hpsqf!hpopd!richi%hpopd.HP.COM@ucbvax.Berkeley.EDU  (Richard Jennings)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP source wanted for HP9000/340
/ hpopd:comp.protocols.tcp-ip / milburn@me10.lbl.gov (John Milburn) /  5:22 pm  Jun  6, 1990 /

Well, this makes about 50 requests over the last year or so in this forum,
with absolutely no response from hp. The response is no better from
sales reps :-). Is there any hope that slip or cslip will be available
sometime in the near future, or should I just give up and buy a couple
or Sun machines? This is important! Please let us know.

-jem

JEMilburn@lbl.gov  ...!ucbvax!lbl.gov!JEMilburn
----------
John,

Firstly, I'm unconnected with the networking guys - I just happen to know
that HP will be shipping a version of PPL SLIP this month.

The product will initially be UNSUPPORTED, however.  You should ask your
HP rep. to get it for you.  (If she doesn't yet know about it, tell her
to contact Karen Choy at HP IND!)

"Hope This Helps"

Disclaimer: this posting is on behalf of myself, as an individual, and does
            not necessarily contain or represent opinions of my employers.

Richard Jennings
Software Development Engineer
Pinewood Information Systems Division (formerly OPD), the home of AIMS,
                               OpenMail and Multi-Media Communications
Hewlett-Packard
Nine Mile Ride
Wokingham
Berkshire  RG11 3LL
England

Phone: +44 344 763 738
Fax:   +44 344 763 440
email: richi@hpopd.HP.COM
       ...!hplabs!hpopd!richi
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 16:53:48 GMT
From:      usc!cs.utexas.edu!ntvaxb!snms4@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   PC-Based Usenet News reader

         I'm searching for a PC-Based Usenet news reader.

         Would anyone please send me any information they have on
         such an animal?  If any of you are using such a thing
         already, I'd be very interested in your impressions, likes &
         dislikes.

         Please send mail directly to me at either SNMS4@UNTVAX on
         BITNET or SNMS4@VAXA.ACS.UNT.EDU on the Internet, so I won't
         miss your replies.  I'll summarize to the Net.

         Thanks,

         -Kevin Mullet
          University of North Texas
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 18:15:44 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '91 Call for Papers


[Hi folks -- SIGCOMM '90 is just around the corner so it's time for me to
start trolling for papers for SIGCOMM '91 -- craig]

		    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: gfw@pueblo.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.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 90 18:49:30 GMT
From:      royce@scor_az.resp-sci.arizona.edu (Royce Robbins)
To:        comp.dcom.lans,comp.protocols.appletalk,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Ethernet_AppleTalk_routing_using_PCRoute

Ok, Ethernetters, AppleTalkers and PCRouters, here's my problem.
				    2
What I've got:
   Two separate networks, one on 10Base2 carrying NFS (TCP/IP) traffic, 
and connected to the world via PCRoute, and one on the original AppleTalk 
cable running TOPS.

   I have the following software: TOPS (Mac & PC versions), AppleShare PC,
PCRoute 2.1 (Thanks to Vance Morrison for some great software!), PC-NFS, 
NCSA Telnet 2.3?? (Mac and PC versions), MacTCP.

            PC        PC  PC   PC       PC
             |         |   |    |        |
  T-----+----+---------+---+----+---+----+----T (Thinwire Ethernet)
        |                           |
      +-+--+                     +--+----+
      +Sun4+                     | a PC  |
      +----+                     |running+------->"The World"
                                 |PCRoute|
                               	 +-------+
                +-------------+	
                |Apple Laser  |
                |Writer II NTX|
                +------+------+
                       |       
      +----------+-----+-----+-----------+ (LocalTalk)
      |          |           |           |      
    Mac SE   Mac SE/30    Mac IIx     Apple IIgs


What I want:
   The two networks bridged through PCRoute, providing telnet access from
the Macs to the Sun4 and the rest of the world, and access to the 
LaserWriter from the Sun4.

            PC        PC  PC   PC       PC
             |         |   |    |        |
  T-----+----+---------+---+----+---+----+----T (Thinwire Ethernet)
        |                           |
      +-+--+                     +--+----+
      +Sun4+    +-------------+  | a PC  |
      +----+    |Apple Laser  |  |running+------->"The World"
                |Writer II NTX|  |PCRoute|
                +------+------+  +----+--+
                       |              |                                        
      +----------+-----+-----+--------+--+ (LocalTalk)
      |          |           |           |      
    Mac SE   Mac SE/30    Mac IIx     Apple IIgs


Background:
   I set up and installed the networks myself, and learned of and installed
PCRoute to enable us to connect to the outside world.  This was done
because it is unquestionably "a neat thing" but was done essentially with no 
support or blessing from the powers that be (other than coughing up the bucks 
for two WD8003E cards).

   Given such a tremendous lack of support a $2-3K FastPath, GatorBox etc. 
is out of the question.  I _might_ be able to spend $500 in several 
sureptitious increments.  Again, my main reason for wanting to do this is
that I feel it is "a neat thing" AND I really want to be able to print to that
LaserWriter from my Sun4.  This is real hard to justify to the powers that be 
who purchase a PC to be used as a dedicated HP Laserjet server!!!

   According to the documentation for PCRoute:

      "PCRoute supports IP inside of LocalTalk.  This allows you to send
   IP packets through LocalTalk nets....  In addition any Macs on the 
   LocalTalk network that have MacTCP can access the IP network.
       Note, however that PCRoute does NOT support encapsulating AppleTalk
   in IP (thus Ushar and CAP will not work), and does NOT support dynamic
   IP address assignment."

   The docs further say that PCRoute does not access the LocalTalk card 
directly, but instead goes through the device driver (ATALK.EXE) that 
comes with the card. (Hah! my card had no such beast, because it didn't 
come with a disk!)

   PCRoute has been configured for two Ethernet and one AppleTalk interfaces,
and appears to start-up correctly. It does correctly (and quite amiably) pass
Ethernet packets (you got this didn't you?).  However, I have tried using 
MacTCP and don't seem to be able to talk to the Ethernet from the Macs.  

   I have both a genuine AppleTalk PC card and a TOPS Flashcard available.
Currently the Flashcard is installed in PCRoute because the AppleTalk card
will not work at bus speeds above 8MHz and I am using a 10MHz XT to run 
PCRoute.  Trust me, it doesn't!  (The 8MHz XT motherboard I have will not 
work with the WD8003E cards needed.  Why? Beats me!)

   Below is my PCRoute log file.  I know the LocalTalk interface has the
same network number as the second ethernet interface.  I'ld prefer not to
have to get a new number.  Please don't tell me that's all there is to it.

            ******* PCroute starting *******
            Interface 1 (ethernet)
               Address  xxx.yyy.aaa.20
               NetMask   255.255.255.0
               Flags     0018H
               Metric    0001H
               The Ethenet Address 0000H
               The Ethenet Address C088H
               The Ethenet Address 6F18H
            Interface 2 (ethernet)
               Address    xxx.yyy.zzz.13
               NetMask   255.255.255.0
               Flags     0018H
               Metric    0001H
               The Ethenet Address 0000H
               The Ethenet Address C057H
               The Ethenet Address CE18H
            Interface 3 (localtalk)
               Address    xxx.yyy.zzz.33
               NetMask   255.255.255.0
               Flags     0018H
               Metric    0001H
               The Localtalk Network 0000H
               The Localtalk Node ID 00A1H
            STATIC ROUTES
            Forwarding BOOTP requests to               0.0.0.0
            Logging messages to SYSLOGD on host     xxx.yyy.zzz.1
            Logging level 0007H
            Logging mask 0002H
            ******* PCroute closing log file *******

Cry for HELP:
   Is there anyone out there that is real familiar with PCRoute and can help
me set up things correctly?  Any ideas regarding how to print to the 
LaserWriter?  Can this even be done?  I've exhausted my campus' expertise,
and they all say it can't be done, although noone around here has tried it.
Assuming it CAN be done, it seems there are a lot of people out there buying
FastPaths and Gatorboxes that they don't need!  

   Any help would be greatly appreciated and I'll be happy to post a summary.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Royce Robbins                         INTERNET: royce@resp-sci.arizona.edu
Div Resp Sciences			   FAX: (602) 626-4884
UofArizona                               PHONE: (602) 626-5022
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Sep 90 13:05:39 EDT
From:      teb%saturn.ACC.COM@salt.acc.com (Tom Benkart)
To:        tcp-ip@nic.ddn.mil
Subject:   IP over HDLC
Is anyone familiar with a package from Sun that provides IP connectivity
over point-to-point HDLC lines?  Are the IP datagrams inserted directly
into the HDLC/LAPB frames, or does another protocol layer sit in between?

Tom Benkart
ACC
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Sep 90 15:03:03 -0700
From:      Stan Stead <stan@anes.ucla.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   XMH
Could someone direct me to where the XMH, the X windows MH mail handler
can be obtained.
	Thank you.
	Stan
stan@anes.ucla.edu
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 90 05:51:32 GMT
From:      oscsunb!OAR.NET!kannan@tut.cis.ohio-state.edu  (Kannan Varadhan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet/telnet release


From: dab@BERSERKLY.CRAY.COM (David Borman)
Date: 14 Sep 90 22:28:38 GMT

> A new BSD version of telnet and telnetd are now available for anonymous
> ftp from ucbarpa.berkeley.edu.  There are two files:
> 
> 	pub/telnet.90.09.14.tar.Z	All the sources
> 	pub/telnet.90.09.14.diff.Z	Diffs from telnet.90.06.28

Dave, and any of you who picked this up,

there is a typo in the telnetd source.  I made the following changes
below...

I am compiling this on a Sun 3/60, running SunOS4.0.3.

manhandler telnetd. rcsdiff sys_term.c
===================================================================
RCS file: RCS/sys_term.c,v
retrieving revision 1.1
diff -r1.1 sys_term.c
87c87
< #   define    tcgetattr(f, t) iotcl(f, TCGETS, t)
---
> #   define    tcgetattr(f, t) ioctl(f, TCGETS, t)
96c96
< #    define   tcgetattr(f, t) iotcl(f, TIOCGETA, t)
---
> #    define   tcgetattr(f, t) ioctl(f, TIOCGETA, t)


Kannan

-=-
Kannan Varadhan, Internet Engineer, OARNet
Ohio Supercomputer Center, Columbus, OH 43212	+1 (614) 292-4137
email:	kannan@oar.net	|  osu-cis!malgudi.oar.net!kannan
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Sep 90 15:44:20 EDT
From:      moghe@husc9.harvard.edu
To:        tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip
Subject:   Re: SNMP info and TCP/IP test programs
In article <11384.653152095@cheetah.ca.psi.com> you write:
>Send a note to snmp-request@nisc.psi.net and ask to be added to the snmp
>list.
>
>/mtr

Do you know if there is a public domain SNMP manager/monitor
available that run on X windows under Interactive Systems
386ix Unix? Thank you.

Regards,

moghe@husc9

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 90 17:37:52 GMT
From:      snorkelwacker!usc!phad.hsc.usc.edu!mcitron@BLOOM-BEACON.MIT.EDU  (Mark Citron)
To:        tcp-ip@nic.ddn.mil
Subject:   ibm 3270 emulation for SCO telnet
Can anyone tell me if it is possible to get SCO's (Unix or Xenix) telnet
to emulate an IBM 3270 terminal. This emulation seems possible via
the pc/telnets that are available but I need to make it possible for
UNIX users to logon to IBM systems as 3270 terminals.

ANY help would be greatly appreciated.
Thanks
Mark Citron  213 669-4683
mcitron@phad.hsc.usc.edu
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 90 09:52:04 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!aldetec!mawson@decwrl.dec.com  (Graeme Mawson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP segment size -- user defined?

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?

Any help will be gretly appreciated!

Graeme Mawson.
Aldetec Pty Ltd.
--
Internet: mawson@aldetec.oz.au
Perth, Western Australia.
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 90 10:02:57 GMT
From:      mcsun!ukc!slxsys!jpp@uunet.uu.net  (John Pettitt)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP over ISDN
Well ?  has anybody done it ?   I am told that I can get call setup
times of the order of 200ms over ISDN.  If this is true it should be
possible to `fake' a connected all the time link using ISDN thus
saving the cost of a leased line.  

This does sound rather too good to be true.  Comments ?


-- 
John Pettitt, Specialix International, 
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 90 22:28:17 GMT
From:      van-bc!ubc-cs!kiwi!dssmv2!fischer@ucbvax.Berkeley.EDU  (Roger Fischer)
To:        tcp-ip@nic.ddn.mil
Subject:   RPC server and fork()

A while ago there was a discussion about RPC servers forking a child task
to do the server function. I did not participate in that discussion.
When I run into the same problem a colleague showed me some of the
articles.

Here I would like to present a possible solution. Comments would be
greatly appreciated.

The problem I still have is how to return an error message when I
can't fork any more tasks or when the fork failed.


pmap_unset( PDIPROG, PDIVERS);
transport = svctcp_create( RPC_ANYSOCK, 0, 0);
svc_register( transport, PDIPROG, PDIVERS, pdirpprog_1, IPPROTO_TCP);
while (TRUE) {
  new_socket = accept( transport->xp_sock, &caller_adr, &addr_len);
  new_transport = svcfd_create( new_socket, 0, 0);
  new_transport->xp_raddr = caller_addr;
  new_transport->xp_addrlen = addr_len;
  if (no_more_forks)
    svcerr_systemerr( new_transport); /* maximum # of children exceeded */
  else {
    child_pid = fork();
    if (child_pid < 0)
      svcerr_systemerr( new_transport); /* fork failed */
    else if (child_pid > 0) {
      svc_destroy( transport);
      svc_run();
      /* should never get here */
      svc_destroy( new_transport);
    }
    else
      svc_destroy( new_transport);
  }
}
/* should never get here */
svc_destroy( transport);


Roger
----------------------------------------------------------------------------
Roger W. Fischer         fischer@mprgate.mpr.ca         fischer@mprgate.UUCP
..seismo!ubc-cs!mprgate!fischer     ...ihnp4!alberta!ubc-cs!mprgate!fischer
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 90 23:53:11 GMT
From:      usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!olson@ucsd.edu  (Bob Olson)
To:        tcp-ip@nic.ddn.mil
Subject:   Compressed Slip
Has anyone gotten compressed slip to work as a loadable device driver
on the NeXT? 

Is there any documentation available for writing loadable device
drivers?

--bob
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 90 23:58:26 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!monu1!vaxc!com217v@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   UNISYS 2200/400 DCP15 Users sought

This is an item from comp.dcom.lans reposted to this group because
on no response.

From: com217v@vaxc.cc.monash.edu.au
Newsgroups: comp.dcom.lans
Subject: UNISYS TCP/IP help sought
Message-ID: <45699.26ee6e65@vaxc.cc.monash.edu.au>
Date: 12 Sep 90 17:20:37 +1000
Organization: Computer Centre, Monash University, Australia
Lines: 11

We have a UNISYS 2200/412 with dual DCP15 comms processors, one of which
has an Ethernet interface. The TCP/IP software we have been supplied with
by UNISYS has allowed us some telnet functionality.

I am looking for anyone who can give some straight forward advice as to the
correct way to set it up. Is there anyone out there with UNISYS 2200/DCP15
on the internet using UNISYS DCP LAN Platform 1R1

SteveD.
com217v@vaxc.cc.monash.edu.au | So long and thanks for all the fish.
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 05:18:13 GMT
From:      usc!chaph.usc.edu!aludra.usc.edu!cyamamot@ucsd.edu  (Cliff Yamamoto)
To:        tcp-ip@nic.ddn.mil
Subject:   Using PCs as Terminal Servers?
Greetings!

I recently inquired about using PCs as ethernet to SLIP routers and was
flooded with many helpful and useful responses.  I'd like to thank all of
you who responded.  It looks like PCRoute is the program to use, although
Karn's KA9Q package wasn't too bad either.

Now, since it seems PCs can do almost anything, does anyone know if there
is a software package that will make a PC into a terminal server.  You
know, like one of those $1500 Bridge Communication Terminal Servers that
have a built-in floopy drive for logging and upload.  They have about
8 - 9.6Kb serial ports on the back.

If a beast like this doesn't exist, would it be easy enough to hack the
KA9Q package to do something like this?

Thanks in advance,
Cliff
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 12:49:59 -0400
From:      H. Craig McKee <mckee@chance.mitre.org>
To:        tcp-ip@nic.ddn.mil
Subject:   3B2 interest group
Is there an interest group for AT&T 3B2 computers?
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 07:18:41 GMT
From:      snorkelwacker!ira.uka.de!smurf!nadia!complx!pi@uunet.uu.net  (Kurt Jaeger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP over ISDN
In article <1990Sep17.100257.9110@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes:
>Well ?  has anybody done it ?   I am told that I can get call setup
>times of the order of 200ms over ISDN.
Thats right. You can get something like a "leased ISDN" which requires
You to pay (e.g. here in the FRG) at least 80 hours per month of
connect time, but it will connect the line in a very short time. I think
the 200ms depend on the distance to the goal.

>If this is true it should be possible to `fake' a connected all the
>time link using ISDN thus saving the cost of a leased line.
Well, but it is NOT needed to use a fast-dial ISDN line. At the recent
GUUG meeting Wiesbaden I have seen a normal ISDN setup with IP over ISDN.
The line had a timeout of 20 seconds and automatically redialed when
there were more packets. The timeout can be configured, they said...
The dialing time was approx. three seconds, so IP wont recognize it
anyway.

I did a telnet to a host approx. 100km away and ftp'ed from there
the kernel. The transmission rate was 5.2KB/sec (hashing enabled).

The company offering the software (for 386er *IX, almost all important
brands) can be reached at:

BinTec
Computersysteme
Willstaetter Strasse 30
D-8500 Nuernberg 60
Tel. 0911-99675-0
Fax. 0911-6880725

I do not have any correlations with them, except hoping to reduce my
News-feed-costs :)

>This does sound rather too good to be true.  Comments ?
It sounds very interesting, yes. Well, that solution is useful for
european ISDN-lines only, I assume :(

              So long, PI

-- 
pi@complx.stgt.sub.org, K.Jaeger, D7K/FRG, +49 711 8701309 Q, 30 years to go !
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 15:02:26 -0400
From:      ellozy@farber (Mohamed Ellozy)
To:        tcp-ip@nic.ddn.mil
Subject:   Legal host names
RFC 1033 (Domain Administator's Operations Guide) states

    ... only the following characters are recommended for use in
a host name (besides the dot separator):

	"A-Z", "a-z", "0-9", dash and underscore

On the other hand, RFC 1034 seems to disallow (or rather discourage) the
use of the underscore (grammer given on page 11).

What are the true rules?

Thanks.

Mohamed
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 20:23:40 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  VT220 emulation
Bill:

One basic question--what is your environment?  Both server and client!  Any
marginal TELNET implementation will support a VT220.  What do you mean when
you say VT220 emulation?  Are you referring to a simple teletype style inter-
face, a VT52 interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI
terminal interface?  Do you require DEC proprietary control sequences?  Do
you require multi-national character set support?

Without identifying exactly what you mean by "VT220 emulation" how can any-
one respond to your request information?  The meaning of "VT220 emulation"
is extremely dpendent upon your specific environment.

Merton

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 13:11:59 EDT
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        John Pettitt <mcsun!ukc!slxsys!jpp@uunet.uu.net>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: TCP/IP over ISDN
>Well ?  has anybody done it ?   I am told that I can get call setup
>times of the order of 200ms over ISDN.  If this is true it should be
>possible to `fake' a connected all the time link using ISDN thus
>saving the cost of a leased line.
>
>This does sound rather too good to be true.  Comments ?

Yes, it has been done, at least with a PC as a router (based on KA9Q).
We have done a demo of it right here on our campus.  The ISDN packet
driver used in this demo was developed at the University of Michigan.  I
don't know what its status is - it hasn't been contributed to the public
packet driver collection.  This one doesn't do anything about dropping
the phone call when the line is idle and redialing when it's back, but
that could be added, I'm sure.

Doug Nelson
Michigan State University
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue 18 Sep 90 16:13:34-PDT
From:      L. Stuart Vance (Icarus) <VANCE@TGV.COM>
To:        agate!linus!linus!mbunix.mitre.org!jsd@ucbvax.Berkeley.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP board for VAX BI bus
>Does anyone know of a board-based TCP-IP implementation which uses the VAX 
>BI bus other than Excelan's EXOS?  If so, please provide manufacture & 
>product name/number.  Thanks in advance.

The only other companies that make board-based IP for VMS products are CMC
and Interlan (Racal-Interlan, Micom-Interlan? not sure who has the IP products
now).  Neither of them, to my knowledge, has done a BI board product.  Lots of
vendors (well, 7 or 8) have host-based products though.  On most newer BI
systems, you should have enough spare processor power to handle the protocol
processing (unless you've got it seriously loaded).

-----Stuart
-------
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 16:33:51 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   VT220 emulation
Does anyone know of a package that supports VT220 emulation on telnet
connections??  And before everybody jumps in and says FTP Associates,
the man who controls the purse strings has already said that solution
is too expensive.  I guess the only thing likely to change his mind is
if no other solution materializes.

Any info??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 18:40 PDT
From:      david@indetech.com (David Kuder)
To:        sun-nets@umiacs.umd.edu, tcp-ip@nic.ddn.mil
Subject:   Using PPP or SLIP for dialup access
We are starting to have employees who want to telecommute.  They have
low end Sun 4's at home.  We also have a second site that is connected
only by UUCP at the moment.  Simple UUCP and terminal sessions are no
longer really adequate for this anymore.

We would like to run some form of IP over a serial wire.  The word I've
heard is that SLIP works (maybe), CSLIP is better and PPP is where
things are going.  We have some SLIP sources in house.  We also have a
PPP from Brad Clements at Clarkson Univ.  I believe I could chase down
CSLIP if necessary.

For us network neophytes, it is hard to make a decision about which one
of these to use.  For instance, the PPP we have is very scant on
documentation.  Nothing wrong with that, we just don't know enough to
use it.

Here are some of the gritty details about our hardware and software.
Sun 4/20 running SunOS 4.1.  Sun 3/150 running SunOS 4.1.  Sun 4/60
running SunOS 4.0.3.  Sun 4/65 running SunOS 4.1.  Telebit T2500's on
most machines.  V.32 capable modems on them all.

So they question is:
    What is the best way for us to get IP going over a serial line?

-- 
____*_  David A. Kuder              david@indetech.com
\  / /  Independence Technologies   {sun,sharkey,pacbell}!indetech!david
 \/ /   42705 Lawrence Place        FAX: 415 438-2034
  \/    Fremont, CA 94538           Voice: 415 438-2003

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Sep 90 16:31:47 EDT
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        mckee@chance.mitre.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   3B2 interest group
If you find one, please let me know what its address is, as I have a site full
of the things!

Thanks in advance!
Bob Stratton		| dsc3rjs@nmdsc{20 | 10}.nmdsc.nnmc.navy.mil [Internet]
Stratton Systems Design	| dsc3rjs@vmnmdsc.BITNET [BITNET only, please!]
			| +1 703 823 MIND [PSTNet]
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 18 September 1990 5:00pm ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP performance (part 2) revised
For those of you who were wondering what in the world Doug Nelson's
spiteful message was referring to, here is the old message, revised
by the helpful comments sent privately (thanks all).  I had given up
on the thread, but it seems the issue has more life than I thought!

This benchmark was conducted over the noisiest line I know of, at slow
speeds, with small packets, with both large and small windows, to
encourage packet loss and demonstrate transmission and syncronization
handling.  With the exception of NIC.DDN.MIL, all testing was done
on a single connection, after midnight -- to eliminate line, route, load,
or congestion variability.

The packet size was 232 bytes.  Optimal transfer bandwidth is:
at 9600 bps: 768 bytes/second
at 1200 bps:  96 bytes/second

NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
(according to Merit -- there is no host DNS record).
I understand it to be a lightly loaded machine.  The traces show
less than MSS sized packets, too many retransmissions, timeouts of
20 seconds or more, and failure to combine ACKs with bidirectional data.
The 10 minute transmission timeout causes many RFCs to be unavailable
over serial lines (but may be configurable).  The dir LIST facility
is excruciatingly slow.

at 9600 bps: 320, 353, 299, 382 bytes/second
at 1200 bps:  54,  49

MERIT.EDU [35.1.1.42] is a Sun 3/150 running SunOs 3.5
   the banner says "FTP server (version 4.115 ..."
   (again, no host record)
I understand it to be a heavily loaded machine and therefore to
be running rather slow in its response times.  It is located
on the same ethernet as NIS.NSF.NET, so I thought that it would
make a good comparison for round trip baseline.

at 1200 bps:  77,  85

TERMINATOR.CC.UMICH.EDU [old address deleted] is a Sun-3/160.
   the banner says "FTP server (version 4.172 ..."
It is located a little farther away (6 hops) in another building at UMich.
The distance didn't seem to have any effect (perhaps because it's a T1 link),
and I attribute the improved performance to a lighter load.

at 1200 bps:  92

So I thought that I'd try a little farther!
THUMPER.BELLCORE.COM [128.96.41.1] is a Sun 4/490 running SunOs 4.1.
It is 8 hops farther away than NIS.NSF.NET, over NSFnet and JVNCnet.
None-the-less, the transfer rate is quite respectable.

at 1200 bps:  84

The next week, just for jollies, I tried NIC.DDN.MIL.
The host records says it's a DEC 2060 running Tops20.
It's often difficult to get to, through some incredibly congested
gateways.  I did this at 16:00 EDT, which should be right in the
middle of their working day out west.  I pinged it for 10 minutes,
in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec;
not counting that 2/3 of the packets were lost!  Even under such
adverse conditions, it outperforms the IBM.

at 1200 bps:  73,  78,  74,  76


CONCLUSION:
IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
It fails to meet several host requirements, not just for TCP/IP
but for FTP and SMTP as well.

Unfortunately, the only product which I am aware of with worse performance
is Spartacus KNET, also for VM.

For the good of the user community, I would recommend to Merit that
the RFC mirror on NIS.NSF.NET be moved to a more capable machine.

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 13:58:52 GMT
From:      niklas@appli.se (Niklas Hallqvist)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Problems with the rexd and rshd daemons in Interactive 386/ix 2.0.2


	Hello, out there. 

	This is a repost of an article posted to comp.unix.i386 at the time
of the comp.unix.* reorganisation.  I didn't get any answer then, so this
time I'll broaden the distribution to include comp.protocols.{nfs,tcp-ip}
on top of using the new correct newsgroup; comp.unix.sysv386!

	We have an ethernet network with three nodes, all of them running
NFS.  One of the most useful commands is on(1) which runs commands on another
node but retains the environment (including the current directory).  Very
neat!  My problem is: I can't use this facility to run programs on our
386/ix (2.0.2 core, 1.1.2 TCP/IP, 2.0 NFS).  I get this error message:
"on: af clnt_call..RPC: Unable to receive" sometimes, and sometimes
I won't even get an error message!  The logfile /tmp/rexd.log looks
something like this:

Sep  6 09:00 (Rpchild/10444): Child #10444 processing RPC for request 
        REXD INFO: errno=22, msg="Invalid argument" 
Sep  6 09:00 (Rpchild/10444): About to fork execution child; cmd='ls' 
        REXD INFO: errno=9, msg="Bad file number" 
Sep  6 09:00 (Rpchild/10444): [RPC Child: svc_fds == 0, shutting down] 
        REXD INFO: errno=9, msg="Bad file number" 

or like this:

Sep  6 09:02 (Rpchild/10446): Child #10446 processing RPC for request
	REXD INFO: errno=22, msg="Invalid argument"
Sep  6 09:02 (Rpchild/10446): About to fork execution child; cmd='ls'
	REXD INFO: errno=9, msg="Bad file number"
Sep  6 09:02 (Rpchild/10446): [RPC Child: svc_fds == 0, shutting down]
	REXD INFO: errno=4, msg="Interrupted system call"

The other way everything works like it's expected to (e.g. running
a command on our NCR Tower using the 386/ix on(1) command).  Even
local usages, like "on localhost ls" fails!  What have I done wrong?
Is there a magical kernel parameter which is wrongly set?  Please help!

	And then there's this "remote shell" handle by /etc/rshd on the
386/ix.  Very often (not always, though) my client "remsh" on another node
gets hung after sending the standard input to the foreign shell.  Very
annoying indeed!  After I kill the client the daemon continues as if nothing
has happenned.  It seems like the EOF gets lost on the way, but reappears if
I kill the client.

Another possibly related weirdness of our 386/ix system is the presence
of all these strange TIME_WAIT, CLOSE_WAIT, FIN_WAIT_2 & CLOSED IP-sessions
that never goes away from our netstat:

Active Internet connections 
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) 
tcp        0      0  ix.1224                ix.111                 TIME_WAIT 
tcp        0      0  ix.1182                nix.1181               CLOSE_WAIT 
tcp        0      0  ix.1181                nix.1039               CLOSE_WAIT 
tcp        0      0  ix.shell               appli.1023             CLOSED 

The corresponding lines from our node "nix": (only the ones concerning "ix")
tcp        0      0  nix.1181               ix.1182                FIN_WAIT_2 
tcp        0      0  nix.1039               ix.1181                FIN_WAIT_2 

There are no corresponding line for the CLOSED connection to node "appli" in
the output from netstat on that node.  What's going on here?  Most things
does work like X11, NFS, rlogin, rcp etc.  It's just "rexd" & "rshd" that
fails!  Any Ideas?

					Niklas
---
Niklas Hallqvist	Phone: +46-(0)31-19 14 85
Applitron Datasystem	Fax:   +46-(0)31-19 80 89
N. Gubberogatan 30	Email: niklas@appli.se
S-416 63  GOTEBORG	       sunic!chalmers!appli!niklas
Sweden

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 14:11:21 GMT
From:      mcsun!ukc!stl!siesoft!silver.siesoft.co.uk!jlk@uunet.uu.net  (Jim Kissel)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for (a working) NFS for VMS

Novell has an NFS implementation for VMS.  I have tested it against our
DFS (MS-DOS) product (pc-nfs clone) and found it to work quite well.

Try contacting manoj@xlnvax.novell.com
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 14:34:14 GMT
From:      eru!hagbard!sunic!news.funet.fi!funic!santra!fuug!demos!dvv@bloom-beacon.mit.edu  (Dmitry V. Volodin)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP over X.25

Have anybody tried this weird combination?
-- 
------------------------------------+------------------------------
Dmitry V. Volodin                   |
internet: <dvv@hq.demos.su>         |
       or <dvv%hq.demos.su@fuug.fi> |         Motto coming soon.
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 14:38:54 GMT
From:      niklas@appli.se (Niklas Hallqvist)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Problems with the rexd and rshd daemons in Interactive 386/ix 2.0.2


	Hello, out there. 

	This is a repost of an article posted to comp.unix.i386 at the time
of the comp.unix.* reorganisation.  I didn't get any answer then, so this
time I'll broaden the distribution to include comp.protocols.{nfs,tcp-ip}
on top of using the new correct newsgroup; comp.unix.sysv386!

	We have an ethernet network with three nodes, all of them running
NFS.  One of the most useful commands is on(1) which runs commands on another
node but retains the environment (including the current directory).  Very
neat!  My problem is: I can't use this facility to run programs on our
386/ix (2.0.2 core, 1.1.2 TCP/IP, 2.0 NFS).  I get this error message:
"on: af clnt_call..RPC: Unable to receive" sometimes, and sometimes
I won't even get an error message!  The logfile /tmp/rexd.log looks
something like this:

Sep  6 09:00 (Rpchild/10444): Child #10444 processing RPC for request 
        REXD INFO: errno=22, msg="Invalid argument" 
Sep  6 09:00 (Rpchild/10444): About to fork execution child; cmd='ls' 
        REXD INFO: errno=9, msg="Bad file number" 
Sep  6 09:00 (Rpchild/10444): [RPC Child: svc_fds == 0, shutting down] 
        REXD INFO: errno=9, msg="Bad file number" 

or like this:

Sep  6 09:02 (Rpchild/10446): Child #10446 processing RPC for request
	REXD INFO: errno=22, msg="Invalid argument"
Sep  6 09:02 (Rpchild/10446): About to fork execution child; cmd='ls'
	REXD INFO: errno=9, msg="Bad file number"
Sep  6 09:02 (Rpchild/10446): [RPC Child: svc_fds == 0, shutting down]
	REXD INFO: errno=4, msg="Interrupted system call"

The other way everything works like it's expected to (e.g. running
a command on our NCR Tower using the 386/ix on(1) command).  Even
local usages, like "on localhost ls" fails!  What have I done wrong?
Is there a magical kernel parameter which is wrongly set?  Please help!

	And then there's this "remote shell" handle by /etc/rshd on the
386/ix.  Very often (not always, though) my client "remsh" on another node
gets hung after sending the standard input to the foreign shell.  Very
annoying indeed!  After I kill the client the daemon continues as if nothing
has happenned.  It seems like the EOF gets lost on the way, but reappears if
I kill the client.

Another possibly related weirdness of our 386/ix system is the presence
of all these strange TIME_WAIT, CLOSE_WAIT, FIN_WAIT_2 & CLOSED IP-sessions
that never goes away from our netstat:

Active Internet connections 
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) 
tcp        0      0  ix.1224                ix.111                 TIME_WAIT 
tcp        0      0  ix.1182                nix.1181               CLOSE_WAIT 
tcp        0      0  ix.1181                nix.1039               CLOSE_WAIT 
tcp        0      0  ix.shell               appli.1023             CLOSED 

The corresponding lines from our node "nix": (only the ones concerning "ix")
tcp        0      0  nix.1181               ix.1182                FIN_WAIT_2 
tcp        0      0  nix.1039               ix.1181                FIN_WAIT_2 

There are no corresponding line for the CLOSED connection to node "appli" in
the output from netstat on that node.  What's going on here?  Most things
does work like X11, NFS, rlogin, rcp etc.  It's just "rexd" & "rshd" that
fails!  Any Ideas?

					Niklas

-- 
Niklas Hallqvist                Phone: +46-(0)31-19 14 85
Applitron Datasystem            Fax:   +46-(0)31-19 80 89
N. Gubberogatan 30              Email: niklas@appli.se
S-416 63  GOTEBORG, Sweden             sunic!chalmers!appli!niklas

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 15:34:56 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!bin@ucsd.edu  (Brain in Neutral)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Using PCs as Terminal Servers?
From article <12018@chaph.usc.edu>, by cyamamot@aludra.usc.edu (Cliff Yamamoto):
> Now, since it seems PCs can do almost anything, does anyone know if there
> is a software package that will make a PC into a terminal server.  You
> know, like one of those $1500 Bridge Communication Terminal Servers that
> have a built-in floopy drive for logging and upload.  They have about
> 8 - 9.6Kb serial ports on the back.

Datability (manfacturer of Vista T.S.'s) makes a product (VistaWare
Server Software) for $695 that turns PC's into terminal servers.  I'm
not sure how much of a bargain this is.  It supports 4 serial ports and
2 parallel ports, which isn't that many.  If you have to buy the serial
cards too, you're starting to inch up to where it might be worth just
getting a real server.

On the other hand, the product does include the stuff in it to translate
between LAT and TCP/IP, which provides (to quote the glossy) "existing
LAT-only servers with access to TCP/IP systems and TCP/IP systems with
access to LAT services".

You can get a free demo diskette (1-800-DIAL-DSS, NY 212-807-7800) so that
you can (quoting again) "start experiencing the thrill today".

I have never used the product.

Paul DuBois
dubois@primate.wisc.edu
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 16:21:29 GMT
From:      cleo!mt@speedy.wisc.edu  (Manolis Tsangaris)
To:        tcp-ip@nic.ddn.mil
Subject:   USER Level SLIP implementations
Is it technically possible to have a user level implementation of SLIP
under 4.3 BSD and its derivatives?

I mean, having something like a daemon reading and writing from/to a
tty and then sending/receiving from an IP socket?

I understand this is not going to be as efficient as the in-kernel
implementation, but it makes it much easier to experiment with various
algorithms for packet compression.

--mt (Manolis Tsangaris)
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 16:54:46 GMT
From:      sdd.hp.com!elroy.jpl.nasa.gov!hacgate!ladcgw.ladc.bull.com!hermes!fmayhar@ucsd.edu  (Frank Mayhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
In article <1990Sep19.112128.2154@swbull.bull.se>, love@swbull.bull.se (Love Feuer) writes:
|> B.O.S. does not support UDP/IP over X.25. The reason for this is
|> probably that nobody should get the very, very sick idea of running
|> NFS over X.25.

Untrue.  While running NFS over an X.25 link is a singularly bad idea, BOS
_does_ support UDP over such links.  Specifically, BIND, among others,
depends on UDP.  We've been running a very similar setup here for several
months, and it seems to be working OK.  There were some startup problems,
and there are still a few things that bite us occassionally, but all in all it
works.
--
Frank Mayhar  fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 17:11:59 GMT
From:      08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over ISDN

>Well ?  has anybody done it ?   I am told that I can get call setup
>times of the order of 200ms over ISDN.  If this is true it should be
>possible to `fake' a connected all the time link using ISDN thus
>saving the cost of a leased line.
>
>This does sound rather too good to be true.  Comments ?

Yes, it has been done, at least with a PC as a router (based on KA9Q).
We have done a demo of it right here on our campus.  The ISDN packet
driver used in this demo was developed at the University of Michigan.  I
don't know what its status is - it hasn't been contributed to the public
packet driver collection.  This one doesn't do anything about dropping
the phone call when the line is idle and redialing when it's back, but
that could be added, I'm sure.

Doug Nelson
Michigan State University

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 17:52:12 GMT
From:      agate!linus!linus!mbunix.mitre.org!jsd@ucbvax.Berkeley.EDU  (John Durand)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP-IP board for VAX BI bus
Does anyone know of a board-based TCP-IP implementation which uses the VAX 
BI bus other than Excelan's EXOS?  If so, please provide manufacture & 
product name/number.  Thanks in advance.

---------------------------------
John Durand                   jsd@mbunix.mitre.org
MITRE Corporation         617-271-5310
Burlington Road
Bedford, MA 01730
---------------------------------
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 21:33:51 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   VT220 emulation

Does anyone know of a package that supports VT220 emulation on telnet
connections??  And before everybody jumps in and says FTP Associates,
the man who controls the purse strings has already said that solution
is too expensive.  I guess the only thing likely to change his mind is
if no other solution materializes.

Any info??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 21:35:03 GMT
From:      neerma@cod.nosc.mil  (Merle A. Neer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Keep-Alive within TCP
On a local net the lack of keepalives is a problem in the
sense that if a problem exists in the connection 99.9999999% of
the time its because the other side crashed...i.e. has lost
all knowledge of the connection.....the remedy will be that
tcp will reform the connection but in the meantime valuable
resources (particularly on PC-type hosts) are not available
to other potential connections (PC's are strapPed for buffer
space and file handles)...In the larger internet if a connection
has problems the problem might be in a packet switch or phone
line somewhere and yes, here, tcp 's philosophY Of keeping
the connection alive has validity...and the server/clients
might benefit from keeping knowledge of the connection around.
In lieu of working keep alives we have found it necessary
to program a keepalive capabilitY above tcp in order to
keep PC servers operable (due to the above mentioned phenomena).

Merle
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 90 23:35:24 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!scslwide!wsgw!smdnd!hagiwara@ucsd.edu  (Takashi Hagiwara)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP over ISDN
In article <9009182032.AA05594@ucbvax.Berkeley.EDU>, 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson) writes:
> >Well ?  has anybody done it ?   I am told that I can get call setup
> >times of the order of 200ms over ISDN.  If this is true it should be
> >possible to `fake' a connected all the time link using ISDN thus
> >saving the cost of a leased line.
> >
> >This does sound rather too good to be true.  Comments ?
 
Yes, it has been done. We, sony, has a unix-based workstation,
it has the ISDN Interface board. (We got an apploval of PTT of Japan.)
Our machine installed this board can be used as a TCP/IP gateway between
Lan and ISDN.

We will demonstorate TCP/IP over ISDN at InterOP '90.
If anyone is interested in it, please stop by at Sony booth.

					Takashi Hagiwara
					(Hagiwara@Sm.Sony.Co.Jp)
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 1990 07:07:23 PDT
From:      Samuel_A_Fedele.Roch817@xerox.com
To:        tcp-ip-RELAY@NIC.DDN.MIL
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Looking for Ethernet Card for EISA Bus.
An EISA NIC (NE3200) is available from Novell.  This board was developed by /
with Compaq.  Call 1-800 - RED - WORD for info.

Good Luck,

Sam
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 08:51:53 -0400
From:      barns@gateway.mitre.org
To:        imp@solbourne.com (Warner Losh)
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: BFTP
Try rooting around on venera.isi.edu - I saw it there once.  I don't
remember the filename but I think it's all in one or two compressed
tar files and there are not so many files available on that machine
to make it very hard to guess which it is (I think).  /Bill
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 09:53:30 PDT
From:      Annette DeSchon <deschon@venera.isi.edu>
To:        stan!imp@boulder.colorado.edu (Warner Losh)
Cc:        tcp-ip@nic.ddn.mil, deschon@venera.isi.edu
Subject:   Re: BFTP
BFTP is available via anonymous FTP from the "pub" directory on
"venera.isi.edu".  The current version is "BFTP.312.tar.Z".

--Annette


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 11:29:05 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Cc:        702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  VT220 emulation
    ....  Are you referring to a simple teletype style inter-face, a VT52
    interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI terminal
    interface?  Do you require DEC proprietary control sequences?  Do
    you require multi-national character set support?

If it has to replace ours, he needs an IBM PC DOS VT220 emulator with
7-bit and 8-bit support, the ISO Latin character set, keyboard and
display re-mapping and print screen support, built into a Telnet with
a built-in FTP server and multi-session capability.  Novell (Excelan)
offers VT220 in their product for the EXOS205, but I don't know its
capabilities.  Sun, IBM and 3Com had VT100 last I knew, I don't know
what Beame & Whiteside offers.  One could also get a VT220 emulator
from one of the Ascii emulator specialists and use it with an INT 14
Telnet redirector.  I don't recall any INT 14 redirector or VT220
emulator Telnets that are free...

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 03:21:17 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   IBM VM TCP/IP performance (part 2) revised

For those of you who were wondering what in the world Doug Nelson's
spiteful message was referring to, here is the old message, revised
by the helpful comments sent privately (thanks all).  I had given up
on the thread, but it seems the issue has more life than I thought!

This benchmark was conducted over the noisiest line I know of, at slow
speeds, with small packets, with both large and small windows, to
encourage packet loss and demonstrate transmission and syncronization
handling.  With the exception of NIC.DDN.MIL, all testing was done
on a single connection, after midnight -- to eliminate line, route, load,
or congestion variability.

The packet size was 232 bytes.  Optimal transfer bandwidth is:
at 9600 bps: 768 bytes/second
at 1200 bps:  96 bytes/second

NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
(according to Merit -- there is no host DNS record).
I understand it to be a lightly loaded machine.  The traces show
less than MSS sized packets, too many retransmissions, timeouts of
20 seconds or more, and failure to combine ACKs with bidirectional data.
The 10 minute transmission timeout causes many RFCs to be unavailable
over serial lines (but may be configurable).  The dir LIST facility
is excruciatingly slow.

at 9600 bps: 320, 353, 299, 382 bytes/second
at 1200 bps:  54,  49

MERIT.EDU [35.1.1.42] is a Sun 3/150 running SunOs 3.5
   the banner says "FTP server (version 4.115 ..."
   (again, no host record)
I understand it to be a heavily loaded machine and therefore to
be running rather slow in its response times.  It is located
on the same ethernet as NIS.NSF.NET, so I thought that it would
make a good comparison for round trip baseline.

at 1200 bps:  77,  85

TERMINATOR.CC.UMICH.EDU [old address deleted] is a Sun-3/160.
   the banner says "FTP server (version 4.172 ..."
It is located a little farther away (6 hops) in another building at UMich.
The distance didn't seem to have any effect (perhaps because it's a T1 link),
and I attribute the improved performance to a lighter load.

at 1200 bps:  92

So I thought that I'd try a little farther!
THUMPER.BELLCORE.COM [128.96.41.1] is a Sun 4/490 running SunOs 4.1.
It is 8 hops farther away than NIS.NSF.NET, over NSFnet and JVNCnet.
None-the-less, the transfer rate is quite respectable.

at 1200 bps:  84

The next week, just for jollies, I tried NIC.DDN.MIL.
The host records says it's a DEC 2060 running Tops20.
It's often difficult to get to, through some incredibly congested
gateways.  I did this at 16:00 EDT, which should be right in the
middle of their working day out west.  I pinged it for 10 minutes,
in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec;
not counting that 2/3 of the packets were lost!  Even under such
adverse conditions, it outperforms the IBM.

at 1200 bps:  73,  78,  74,  76


CONCLUSION:
IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
It fails to meet several host requirements, not just for TCP/IP
but for FTP and SMTP as well.

Unfortunately, the only product which I am aware of with worse performance
is Spartacus KNET, also for VM.

For the good of the user community, I would recommend to Merit that
the RFC mirror on NIS.NSF.NET be moved to a more capable machine.

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 04:25:24 GMT
From:      stan!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   BFTP
OK, I looked for bftp in all my favorite archive sites, and in the
anonymous ftp list that was posted to comp.archives a while back.  No
luck.  Does anybody know where I can get a copy?

Warner
--
Warner Losh			imp@Solburne.com
-- 
Warner Losh		imp@Solbourne.COM
Me?  I'm the onion rings.
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 10:25:36 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VT220 emulation
It seems that my request was not fully understood.  I am looking for a PC
version of TELNET with the ability to emulate a DEC VT220 terminal.  I need
both screen emulation and keyboard emulation.  This is intended to run with
packages like SCT Banner and ORACLE so it needs to be a pretty good copy
of a VT220.
I currently have NCSA Telnet.  It doesn't do VT220.  I have already suggested
putting it in our selves but there are other problems with the package that
make it less desirable.
I also have a package called MD_DOS IP.  It has VT220 emulation, however it
doesn't work correctly.  I have suggested fixing that but have not been
given the time or boddies necessary to accomplish it.
I am aware of FTP Associates and have been told it is too expensive considering
the number of copies we would need.
I was asked to gather information as to what alternatives there were.  I
personnally think fixing MD_DOS is the best bet but I don't make final
decisions.

I never really thought that people would think I was trying to build terminal
emulation into BSD UNIX.   :-(

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 05:57:01 GMT
From:      ucselx!mccurdy@ucsd.edu  (mccurdy m)
To:        tcp-ip@nic.ddn.mil
Subject:   Hughes LAT TCP/IP server crashes with task stack overflow error
From: mccurdy@ucselx.sdsu.edu (mccurdy m)
Newsgroups: comp.protocols.tcp-ip.
Subject: Problem with Hughes terminal server task stack overflow crash
References: 
Sender: 
Followup-To: 
Distribution: world
Organization: San Diego State University Computing Services
Keywords: 

	
	Anyone having a problem with a hughes terminal server crashing with
a task stack overflow error. We are.

	I believe our server is running the most recent version of software.
Don't know the model number, but it runs both LAT and TCP/IP.

	If anyone has an interest in this, I can provide additional info
after talking to our network person. This problem has only been noticed
when dialing in via modem, but that is the only way that we are using these
servers.

-mike

-- 
Mike McCurdy               *  mccurdy@ucselx.sdsu.edu *
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 07:06:09 GMT
From:      excelan!manoj@ames.arc.nasa.gov  (manoj @ Prod Mktg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for (a working) NFS for VMS
In article <9009112234.AA15069@ucbvax.Berkeley.EDU>, 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes:
> Well, we've been bitten once more by Wollongong's TCPIP for VMS.
> I have found out today that their NFS cannot understand enough
> of the UNIX file commands to even be usable.  (No chown, No permissions,
> No link())
> Does anyone know if any of the other TCPIP implemntations support
> NFS?? And does it work well enough to be used with a UNIX system??

A number of vendors offer TCP/IP and NFS on a VAX/VMS..
The Novell (previously Excelan) offering is called MULTINET for VMS..
For details, pl call 800-lankind or 408-434-2300
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90  14:23 PDT
From:      CLIFF%UCBCMSA.Berkeley.EDU@lilac.berkeley.edu (Cliff Frost {415} 642-5360)
To:        IBMTCP-L@PUCC.BITNET, TCP-IP@NIC.DDN.MIL
Subject:   IBM VM TCP/IP technical shortcomings
> (Why is it the nasty comments are published, and the nice ones are sent
> privately?

This complaint smacks of the pot calling the kettle black, but
since you ask, I asked you publically because you failed to answer
either of the entirely neutral requests for information I sent you
privately.

Thank you for *finally* publishing some information.

        Cliff Frost
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 19 September 1990 12:11pm ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   mail destroyed
> Received: by TAOMLR2@MSU; Wed, 19 Sep 90 02:49:45
> Received: by TAOXRDR@MSU; id 8800; Wed, 19 Sep 90 02:49:35 EDT
> Mail-From: venera.isi.edu received by IBM.CL.MSU.EDU at 19 Sep 90 02:34:15
> Date: Tue, 18 Sep 90 23:32:44 -0700
> From: woolf@venera.isi.edu (Suzanne Woolf)
> Posted-Date: Tue, 18 Sep 90 23:32:44 -0700
> Message-Id: <9009190632.AA09546@venera.isi.edu>
> Received: by venera.isi.edu (5.61/5.61+local)
>  id <AA09546>; Tue, 18 Sep 90 23:32:44 -0700
> To: 09998WAS@IBM.CL.MSU.EDU
> Subject: Re: IBM VM TCP/IP performance (part 2) revised
> Newsgroups: comp.protocols.tcp-ip
> In-Reply-To: <9009190321.AA14869@ucbvax.Berkeley.EDU>
> Organization: Information Sciences Institute, Univ. of So. California
> Cc: woolf@venera.isi.edu
>
> In article <9009190321.AA14869@ucbvax.Berkeley.EDU> you write:

That was the total message as seen from here.  Could you please
retransmit the message?  Thank you.

Bill Simpson
   09998was@msu.bitnet
   09998was@ibm.cl.msu.edu
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 19 September 1990 2:48pm ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   IBM VM TCP/IP technical shortcomings
There being 5 requests for the information, I suppose that it's
worthwhile to post this to the group at large.
---- ---- ---- ---- ----

First, this implementation does not bundle a reply ACK with
the reply data, resulting in 2 packets.  An ACK is sent right
away when the PSH flag is set.  This behaviour results in slow
FTP startup times, and very slow throughput for short transfers
such as dir LISTs.  This is cited as a poor implementation practice
in RFC1122 at 4.2.2.14.

Similarly, the first data packet is sent separately from the handshake ACK.
Minor, but significant and unexplained.
---- ---- ---- ---- ----

Secondly, there is a serious problem with the retransmission timer.
On startup of successive file transfers, the host-host rtt
does not seem to be remembered (as other implementations do).  The
timer always starts too fast, and takes several timeouts before it
reaches a reasonable value.  (Other implementations reach this value
after 1 timeout, or 2 at most.)  Then, it continues to increment!
Timeouts later in the transfer come at intervals of 20 or 40 seconds,
even after a smooth transmission for dozens of packets!
---- ---- ---- ---- ----

Thirdly, less than MSS sized packets are transmitted.  (I opine that
this is due to an error in the congestion avoidance algorithm,
as it only occurs when the window:MSS ratio is greater than 2.)
---- ---- ---- ---- ----

Fourthly, a "persist" timer kicks in every 5 seconds, and flushes
whatever happens to be in the buffer.  (Yet another source of less
than MSS sized packets.)  This occurs even though the link was
continuously transmitting.  Since the rtt was ~2.4 seconds, this
annoying source of small packets put a serious dent in the throughput.
---- ---- ---- ---- ----

Fifthly, the link itself times out after 10 minutes from startup
(default).  I could understand if that was for an *idle* link
(10 minutes since last packet transmission), but in the middle
of an active transfer?!?
---- ---- ---- ---- ----

Sixthly, the higher level protocols (FTP, SMTP) do not properly treat
the TCP connection as a stream.  Instead -- at least on the control
connection -- the remainder of a PSHed segment is discarded.  That is,
PSHed segments are treated as unit records!  When a properly functioning
TCP combines PSHed segments per 4.2.2.2, they are not properly processed
on the IBM end, resulting in a hung connection.
---- ---- ---- ---- ----

Relevant RFC1122 cites: 4.2.2.2, 4.2.2.14, 4.2.2.15, 45.2.2.17, 4.2.3.1,
4.2.3.2, 4.2.3.4, 4.2.3.5, 4.2.3.6.

Hope this clears up any questions the various flamers have had!

(Why is it the nasty comments are published, and the nice ones are sent
privately?  Not that I didn't appreciate getting them, mind you!
Thanks all!)

Bill Simpson
   09998was@msu.bitnet
   09998was@ibm.cl.msu.edu
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 11:21:28 GMT
From:      eru!hagbard!sunic!swbull!love@bloom-beacon.mit.edu  (Love Feuer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
dvv@hq.demos.su (Dmitry V. Volodin) writes:
>Have anybody tried this weird combination?

Yup.
 We have a running TCP/IP link between Norway and Sweden on two
Bull DPX 2/320's. It is not a point-to-point link, but a simulated multi-
node network. Bull's own little unix (B.O.S) supports TCP/IP over
X.25 with extensions to some existing commands. This is the way we did it:
(Simplified)

Both machines has the following entries in their /etc/hosts:
swbull_ix0	125.0.0.1
medoc_ix0	125.0.0.2

swbull> ifconfig ix0 swbull_ix0 publix x121 <swbulls number>
swbull> route xadd bull_ix0 <swbulls number>
swbull> route xadd medoc_ix0 <medocs number>

medoc> ifconfig ix0 medoc_ix0 public x121 <medocs number>
medoc> route xadd bull_ix0 <swbulls number>
medoc> route xadd medoc_ix0 <medocs number>

If we would want to connect more machines to the same network, we would
simply add some more hosts with 'route xadd'.

It works rather Ok, but it is *SLOW* due to the 2400 BPS modem on
medoc's side. We will soon upgrade to 9600 on medoc and that will
probably help the performance a bit.

B.O.S. does not support UDP/IP over X.25. The reason for this is
probably that nobody should get the very, very sick idea of running
NFS over X.25.

Mail me if you want the more pervert details of this installation.


>------------------------------------+------------------------------
>Dmitry V. Volodin                   |
>internet: <dvv@hq.demos.su>         |
>       or <dvv%hq.demos.su@fuug.fi> |         Motto coming soon.

Love Feuer Bull Sweden   +46-8-7284349
Mail: love@swbull.bull.se -or- {anything major}!sunic!swbull!love
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 11:55:34 GMT
From:      usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Ethernet Card for EISA Bus.
We are looking for an Ethernet card which conforms to the EISA bus
architecture.  We are aware of the card made by Mylex (LNE390).  Does
anyone know of any others?

Thanks.

--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 18:55:57 PDT
From:      nisc@NISC.SRI.COM (SRI's NIC)
To:        tcp-ip@nic.ddn.mil
Subject:   Interest Groups list (List-of-Lists) has a new home.

The popular Interest Groups (List-of-Lists) file has a new home.

This file provides a list of various discussion lists available
to network electronic mail users.

The file is now available for anonymous FTP from host ftp.nisc.sri.com
(192.33.33.53) in directory netinfo.  The pathname of the file is
netinfo/interest-groups. There is currently no electronic mail access
to this file.

To keep people informed about changes to the file, there is a mailing
list for List-of-Lists "update notices".  When any updates are made to
the file, an announcement message will be sent to the notification
list.  Copies of the file itself will not be sent to the list.  Site
representatives who maintain or redistribute copies of this file for
their own networks (e.g, DECNet, Xerox, BitNet, MailNet, etc.) and who
cannot access the file by Internet FTP may make arrangements to have
the file sent to them, if necessary.  File copies will normally not be
sent to individual users.

To get on or off the notification list, send requests to

	interest-groups-request@nisc.sri.com.


To submit new descriptions of mailing lists, to update existing
information, or to delete old mailing list information from the
List-of-Lists, send a message to

	interest-groups-request@nisc.sri.com.

The NISC depends on the network user population to inform us of changes
to any of the network lists. We appreciate your cooperation!

Thanks to Rich Zellich for the many years of effort that he put into
maintaining this file.  Sadly, circumstances have changed and it was
not possible to continue the arrangement that worked so well over
those years.


SRI International
Network Information Systems Center 

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 14:00:28 GMT
From:      usc!samsung!b-tech!zeeff@ucsd.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: USER Level SLIP implementations
>Is it technically possible to have a user level implementation of SLIP
>under 4.3 BSD and its derivatives?

There is something called the tunnel driver that allows this.  I'd be 
interested in anyone who has slip or slfp user level code that works 
with this.  

From the README file:

This is the tunnel driver for routing IP packets over other networks.
In particular it can be used for rfc877 encapsualtion of IP packets
over X.25 - but the kernel level driver just delivers IP packets to
listening processes. The approximate steps for installation of the
driver are as follows.

     Julian Onions (jpo@cs.nott.ac.uk)
        Computer Science Department
        Nottingham University
        Nottingham, NG7 2RD
        ENGLAND

        +44 602 506101 x3595
~
~
~


-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 14:07:23 GMT
From:      Samuel_A_Fedele.Roch817@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for Ethernet Card for EISA Bus.

An EISA NIC (NE3200) is available from Novell.  This board was developed by /
with Compaq.  Call 1-800 - RED - WORD for info.

Good Luck,

Sam

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 15:25:36 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: VT220 emulation

It seems that my request was not fully understood.  I am looking for a PC
version of TELNET with the ability to emulate a DEC VT220 terminal.  I need
both screen emulation and keyboard emulation.  This is intended to run with
packages like SCT Banner and ORACLE so it needs to be a pretty good copy
of a VT220.
I currently have NCSA Telnet.  It doesn't do VT220.  I have already suggested
putting it in our selves but there are other problems with the package that
make it less desirable.
I also have a package called MD_DOS IP.  It has VT220 emulation, however it
doesn't work correctly.  I have suggested fixing that but have not been
given the time or boddies necessary to accomplish it.
I am aware of FTP Associates and have been told it is too expensive considering
the number of copies we would need.
I was asked to gather information as to what alternatives there were.  I
personnally think fixing MD_DOS is the best bet but I don't make final
decisions.

I never really thought that people would think I was trying to build terminal
emulation into BSD UNIX.   :-(

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 15:51:45 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!dap@uunet.uu.net  (Dave Price)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP over ISDN
I was interested to hear of the PD written at Michigan.
I am currently writing one for a MITEL EXPRESS Card.

Can anyone tell me more about the Michigan work?
Dave Price
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 17:06:22 GMT
From:      usc!samsung!uakari.primate.wisc.edu!bin@ucsd.edu  (Brain in Neutral)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hughes LAT TCP/IP server crashes with task stack overflow error
> 	Anyone having a problem with a hughes terminal server crashing with
> a task stack overflow error. We are.

I had  Hughes terminal server for tryout and saw the same problem twice.
I wasn't using dialin with modems, either, just two terminals.  I would
like to see someone say (truthfully :-) that Hughes has fixed this, because
I liked the server quite a bit (we have lots of terminals on Hughes (nee
Sytek) LocalNet boxes, and the command sets are very similar.

--
Paul DuBois
dubois@primate.wisc.edu

                 "Was all of this because I wore a big man's hat?"
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 17:10:41 GMT
From:      csusac!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  VT220 emulation
In article <9009190323.AA01856@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
>Bill:
>
>One basic question--what is your environment?  Both server and client!  Any
>marginal TELNET implementation will support a VT220.  What do you mean when
>you say VT220 emulation?  Are you referring to a simple teletype style inter-
>face, a VT52 interface, a 7 bit ANSI terminal interface, or a 8 bit ANSI
>terminal interface?  Do you require DEC proprietary control sequences?  Do
>you require multi-national character set support?
>
>Without identifying exactly what you mean by "VT220 emulation" how can any-
>one respond to your request information?  The meaning of "VT220 emulation"
>is extremely dpendent upon your specific environment.
>
>Merton

Just for the record, I thought that the original poster was adequately
clear in what he was looking for.  From the wording of his message, it
sounded like he wanted a Telnet client that would emulate a vt220.  

I am not a protocol expert, but it is my understanding that "vt220" is
a specific DEC protocol that is fully defined.  If I am running a vt220
terminal emulator and log into my vax and do a SET TERM/INQUIRE it
should recognize me as a vt220.  If I am not emulating a vt220, it would
not recognize me as a vt220.

I agree that some emulators work better than others, but I don't believe
that a person has to regurgitate a complete spec to make a request to
the net.  So mellow out!

Robin Goldstone, Systems Software Specialist
California State University, Chico Computing ServiceSo mellow out!
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 17:45:21 GMT
From:      agate!garnet.berkeley.edu!cliff@ucbvax.Berkeley.EDU  (Cliff Frost)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM VM TCP/IP performance (part 2) revised

In article <9009190321.AA14869@ucbvax.Berkeley.EDU>,
09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes:
|> For those of you who were wondering what in the world Doug Nelson's
|> spiteful message was referring to, here is the old message, revised
|> by the helpful comments sent privately (thanks all).  I had given up
|> on the thread, but it seems the issue has more life than I thought!
|> 
|> This benchmark was conducted over the noisiest line I know of, at slow

On this list we've seen all this before.  We're still waiting for you 
to substantiate your accusations.

For those of you who aren't familiar with the product Bill.Simpson so
gratuitously slams, his "benchmarks" show one thing unambiguously:

	Data transfer rates from nis.nsf.net are low.

Wow.

In his postings Bill.Simpson has said that he has proven that this is
due to the software running on nis.nsf.net--specifically as opposed to
the configuration of the software and hardware on that machine (which he
admits he knows nothing about).  He has never publically listed these
failings, nor the alleged host requirements the sw fails to meet.

I've asked him twice in private mail what specific software failings he 
has found, and several others have asked him this publically, and he has
never responded.  Perhaps he has found flaws, perhaps not.  It's looking
like we'll never know.

	Cliff Frost			<cliff@Berkeley.EDU>
	Central Computing Services
	UC Berkeley
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Sep 90 21:48:32 EDT
From:      asp@uunet.uu.net (Andrew Partan)
To:        tcp-ip@nic.ddn.mil, com-priv@psi.com
Cc:        tmn!cook@uunet.UU.NET
Subject:   OTA requesting feedback on NREN
The United States Congress Office of Technology Assessment is
undertaking a study of the National Research and Education Network.
The completion of the study will be in the spring of next year.  Gordon
Cook, the study Director, would like to use the network to collect
ideas from the people in network land who will be affected by the
NREN.  He would be especially interested in feedback on NREN governance
and the apportionment of funds between the various stakeholders, on
access (should there be an institutional affiliation required), cost
apportionment for users, and issues of commercialization
privatization.  These of course are not ALL the issues and are not
meant to circumscribe input.  He will credit the idaes of anyone cited
from the net discussion unless they specifically ask to remain
anonymous in their posting.


Please reply directly to Gordon Cook (cook%tmn@uunet.uu.net), not to
me.  [The address will probably be cook@ota.gov w/in the next 2 weeks.]

	--asp@uunet.uu.net (Andrew Partan)
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 17:56:48 GMT
From:      usc!cs.utexas.edu!samsung!sol.ctr.columbia.edu!ucselx!mccurdy@ucsd.edu  (mccurdy m)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hughes LAT TCP/IP server crashes with task stack overflow error
In article <3125@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
	
	re: hughes servers crashing with task stack overflow on
	dial-in modems>servers>vms or unix ...

>I had  Hughes terminal server for tryout and saw the same problem twice.
>I wasn't using dialin with modems, either, just two terminals.  I would
>like to see someone say (truthfully :-) that Hughes has fixed this, because
>I liked the server quite a bit (we have lots of terminals on Hughes (nee
>Sytek) LocalNet boxes, and the command sets are very similar.

	This hasn't been fixed for us and we are taking quite a bit of heat
from users - needless to say.

	Hughes is working with us on this problem and I've also heard from a
representative as a result of the original posting. I've also heard from one
other person that is having a similar problem.

	We were also interested in the servers because of the Sytek Localnet
connections.

	Will post the conclusion.

By the way - what happens is: something happens that causes the server to crash
with a "task stack overflow" error, everyone on that server gets knocked off,
and the server reloads. It seems to happen on all of the servers, we havn't been
able to connect the crashes to any particular event. Hughes has provided us witha sniffer to assist in the detective work.

-mike


-- 
Mike McCurdy               *  mccurdy@ucselx.sdsu.edu *
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Sep 90 2:02:26 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        mccurdy@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Hughes LAT TCP/IP server crashes with task stack overflow error
Hi Mike,
	The problem you cited has been seen at a couple of sites.  The message 
was issued by the OS in the server when stack space underflowed.  It is not
a bug in the sense of a software error, rather it seems to occur at a few
sites, on some of their segments.  The traffic mix or volume is related to
this symptom.  For that reason we have lent you a Sniffer and are interested
in characterizing your traffic.

	Problems of this type, particularly when they cause a widespread
interruption of service to users, are of urgent concern to us, and will be
addressed immediately.  You have already been contacted by engineering to
set up a connection to a server.  Your cooperation in gathering data and 
communicating the results, configurations and analyses is appreciated and
will help us to resolve your problem.

-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 19:09:44 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!bin@ucsd.edu  (Brain in Neutral)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Hughes LAT TCP/IP server crashes with task stack overflow error
From article <1990Sep19.175648.17632@ucselx.sdsu.edu>, by mccurdy@ucselx.sdsu.edu (mccurdy m):
> By the way - what happens is: something happens that causes the server to crash
> with a "task stack overflow" error, everyone on that server gets knocked off,
> and the server reloads. It seems to happen on all of the servers, we havn't been
> able to connect the crashes to any particular event. Hughes has provided us witha sniffer to assist in the detective work.

When I saw the problem, the crash occurred and the server reset.  The next day
it happened again, but the crash reoccurred every few minutes.  I got annoyed,
turned it off, turned it back on the next day and (of course) never saw the
problem again.  But by then I had switched the active terminals back to the
LocalNet and was not using the server for any "real" work.
--
Paul DuBois
dubois@primate.wisc.edu

                 "Was all of this because I wore a big man's hat?"
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 20:40:27 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes:
   dvv@hq.demos.su (Dmitry V. Volodin) writes:
      Have anybody tried this weird combination?

   Yup.  [...and then describes running TCP/IP over X.25, without
   mentioning SLIP.]

Many X.25 implementations (ours, for instance) support IP directly,
which (for routing purposes) just sees the virtual circuits as wires.
I'm not sure why Mr. Volodin wants to put SLIP in the pile, though.

   B.O.S. does not support UDP/IP over X.25. The reason for this is
   probably that nobody should get the very, very sick idea of running
   NFS over X.25.

That's odd.  Far less sick things use UDP, like the Network Time
Protocol and the Domain Name System.  They're both entirely
appropriate and necessary to run over long-haul links like X.25.

I'd speculate that the reason Bull doesn't support UDP over X.25
involves NFS aesthetics less than the cost of setting up and tearing
down virtual circuits for the tiny, "cheap" packets that UDP
applications expect to exchange.  Ask for a CLNS next time :-)
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 90 22:38:08 GMT
From:      huyn@hplabsz.HPL.HP.COM (Pierre Nam Huyn)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Doing NFS/RPC from a MacII

I want to be able to do a remote procedure call (NFS/callrpc) from a MacII
to workstations on the network (HP, Sun, Vax, ... all of which support NFS).

These are the questions:

- is this possible ?
- does a NFS library exists for the Mac (product or not) ?
- what system software is required (to support NFS) ?
- what connectivity hardware exists to connect up the Mac to the Ethernet
  in order to support above ?

    Any pointer would be appreciated. Thanks.

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 01:42:08 GMT
From:      decvax.dec.com!bacchus.pa.dec.com!mogul@mcnc.org  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
In article <266@aldetec.oz.au> mawson@aldetec.oz.au (Graeme Mawson) writes:
>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?

Since nobody else seems to have responded, I'll take a stab.

Yes, in one sense.  The TCP segment size is not a fixed value; rather,
it is limited on the high side by a number of different considerations,
and it should be no lower than necessary in order to get good performance.

The upper limits on the size of a TCP segment are:

    (1) the TCP MSS option value; the receiving TCP specifies the largest
    segment it is willing to receive, and the sending host must abide.
    
    (2) the transmit side send buffer space limit.  In BSD-based systems,
    this can be varied by the application program (within bounds).
    
    (3) the "Path MTU"; basically, the largest packet that can be sent
    from source to destination without fragmentation.  
    
    (4) various considerations of the flow control and congestion control
    algorithms.
    
Only #2 is under the control of the user, and in general the user would
do well to leave it alone. The other limits are supposed to be set more
or less automatically, in order to maximize performance.  But, if you
want to vary the segment size for experimental reasons, you'll probably
have to modify the TCP code on both the sender and receiver; on the
receiver, so that it sends a large enough MSS option, and on the sender,
so that it choose the actual MSS you want it to use.  (Existing
TCPs often choose something like 1024 if the MSS option allows anything
above that.)
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Sep 90 13:32:49 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        excelan!manoj@ames.arc.nasa.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for (a working) NFS for VMS
 > The Novell (previously Excelan) offering is called MULTINET for VMS..
 
I thought TGV, Inc. offered MULTINET.  Novell doesn't do TCP/IP.  At least
the ones that snuck through the door here don't.

Phil Wood
Los Alamos National Laboratory

PS:  I called the product specialist at 800-lankind and they didn't know
about MULTINET either.
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 08:20:41 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   9 interesting & challenging problems for Netman


Here are what we consider to be 9 interesting & challenging problems for 
network management (these are based on
real requirements, not tedious exhaustive MIB definitions):

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

3. given a traffic matrixfor a LAN, automatically find the best place
to partitionm the net with a bridge/switch/router (subject to any
sensible topographical/logical or other constraints).

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

6. Given a general traffic trace, detect patterns of communication
involving more than 2 parties (e.g. YP or DNS lookup followed by
telnet is triv. case).

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

8. Given a trace of packets between 2 protocol entities at layer 4,
invent a pleasant and efficient programming language to describe &
enable the reconstruction of application level exchanges.

9. Do all of the above for an Internet.


--------
I am sure there are more - if any of these are covered by any of the
public domain management tools accumulated by IETF i'd be verra
interested

thanks


jon 

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Sep 90 17:42:19 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        tcp-ip@nic.ddn.mil
Cc:        cpw%snow-white@LANL.GOV, 702WFG%SCRVMSYS.bitnet%cunyvm.cuny.edu@TGV.COM (702WFG @ SCRVMSYS.bitnet @ cunyvm.cuny.edu)
Subject:   Re: Looking for (a working) NFS for VMS
>>> Well, we've been bitten once more by Wollongong's TCPIP for VMS.
>>> I have found out today that their NFS cannot understand enough
>>> of the UNIX file commands to even be usable.  (No chown, No permissions,
>>> No link())
>>> Does anyone know if any of the other TCPIP implemntations support
>>> NFS?? And does it work well enough to be used with a UNIX system??

>> A number of vendors offer TCP/IP and NFS on a VAX/VMS..
>> The Novell (previously Excelan) offering is called MULTINET for VMS..

> I thought TGV, Inc. offered MULTINET.  Novell doesn't do TCP/IP.  At least
> the ones that snuck through the door here don't.

    TGV is the developer and manufacturer of MultiNet, and Novell is
currently a distributor of ours.

    In addition to the full TCP/IP suite, we have an NFS Server and
the ONLY NFS Client available for VAX/VMS as options what are sold
with MultiNet.	Our NFS products are not available through Novell, but
Novell sells their "LANservice NFS" (NFS Server only) which was
originally developed for EXOS but now runs over MultiNet.

    If you'd like more information or an evaluation copy give us a
call at 800-TGV-3440 / 408-427-4366.

							Ken
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Sep 90 09:20:41 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Cc:        netman@rutherford.ac.uk, net-management@cs.ucl.ac.uk
Subject:   9 interesting & challenging problems for Netman

Here are what we consider to be 9 interesting & challenging problems for 
network management (these are based on
real requirements, not tedious exhaustive MIB definitions):

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

3. given a traffic matrixfor a LAN, automatically find the best place
to partitionm the net with a bridge/switch/router (subject to any
sensible topographical/logical or other constraints).

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

6. Given a general traffic trace, detect patterns of communication
involving more than 2 parties (e.g. YP or DNS lookup followed by
telnet is triv. case).

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

8. Given a trace of packets between 2 protocol entities at layer 4,
invent a pleasant and efficient programming language to describe &
enable the reconstruction of application level exchanges.

9. Do all of the above for an Internet.


--------
I am sure there are more - if any of these are covered by any of the
public domain management tools accumulated by IETF i'd be verra
interested

thanks


jon 
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Sep 90 16:08:34 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VT220 emulation
Thanks for all the comments I got from everybody.  I think the problem
is solved.  For those who find themselves in the same boat at some time
in the future (or present) the solution is (hopefully) FTP Software.
It turns out that the people who thought it was too expensive were dealing
with a quantity 1 price. When site licensing and Educational discounts are
taken into consideration, they become not only the best solution but also
very reasonably priced.

Thanks again for all the advice.

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 12:03:01 GMT
From:      snorkelwacker!ira.uka.de!iramu1!nipper@bloom-beacon.mit.edu  (Arnold Nipper)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: BFTP
In article <1990Sep19.042524.13764@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes:
>OK, I looked for bftp in all my favorite archive sites, and in the
>anonymous ftp list that was posted to comp.archives a while back.  No
>luck.  Does anybody know where I can get a copy?
>

venera.isi.edu

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
********************************************************************************
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 16:04:35 GMT
From:      mcsun!ub4b!dg13!pnoe@uunet.uu.net  (Pierre Noel)
To:        tcp-ip@nic.ddn.mil
Subject:   PC/TCP tnvt product with 8bits characters codes ?
Hi Netland, 

For the time being, I have been requested to test some TCP/IP packages on PC to correctly negociate with our Unix servers.

I found that PC/TCP seems to meet part of our request except that it needs a 
special file to remap keyboard scan codes to output character codes. More, once I've made that file and tested the connection, I found that the tnvt program, inVT220 mode (7 or 8 bit mode), strips the 8th bit of the sent caracter. The contrary is not true : an 8-bit character sent from the application to the Telnet   
screen is well received. 

Am I wrong, Have I made a stupid mistake or is it a well known problem ?
I havn't found documentation on that problem on my pc/tcp books. It is for us 
quite a big problem due to the enormous use of the enhanced caracters in our    european languages (except English...of course).

Thank you for your responses ... 

By the way, If you know other products working on PC and giving coherent 
VT220 or ANSI emulation (No Excelan nor PC/NFS Telnet : I found them non-suita- ble for European emulations).


Thank you for your attention.


					Pierre Noel


 
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri 21 Sep 90 01:12:47-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        decvax.dec.com!bacchus.pa.dec.com!mogul@mcnc.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP segment size -- user defined?
    The upper limits on the size of a TCP segment are:
	:
	:
    (3) the "Path MTU"; basically, the largest packet that can be sent
    from source to destination without fragmentation.  


In theory, there isn't any reason the tcp segment size cannot be larger
than the path MTU.  (NFS essentially does this, though it doesn't use
TCP.)  In practice, there are several reasons why doing this is a rather
bad idea - see Jeff's paper "Fragmentation Considered Harmful".  Basically,
if you make the mss larger than the mtu, you force a lot of effort at the
routers (fragmentation), the destination (reassembly), and the network (if
it doesn't deliver all the fragments, the entire packet has to be retransitted)

BillW
-------
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 19:59:24 GMT
From:      cert!netnews.upenn.edu!dccs.upenn.edu!litwack@lll-winken.llnl.gov  (Mark Litwack)
To:        tcp-ip@nic.ddn.mil
Subject:   Ungermann-Bass ICMP problems
It's taken me a while to finally figure this out, but
it seems that Ungermann-Bass PC-NIU/ex cards occasionally
send out an ICMP host unreachable message to a host that's
sending too much TCP data to another host on the local
ethernet.  This has the effect of severing the TCP connection
between the two innocent hosts.  I have captured the culprit
packets and the PC is cleary in the wrong.  So far, it's only
happened on PCs which are running Novell and U-B NetNone TCP
at the same time.

I also found that while Ultrix systems cause the TCP application
to bomb out when it receives the packet, Suns are not affected.
I guess they have some kind of sanity check for ICMP messages.

Has anyone ever seen this?  I'm really annoyed at U-B.  Their
technical support line didn't know what ICMP was and they wanted
to know how many stop bits I was using so that they could re-create
the problem in their lab.

-mark

For those who are interested, here is a sample packet for
entertainment value.  kiwi.dining is a PC, scotty.dccs is
a DECstation 3100, remote.dccs is a uVax II.  Scotty.dccs
is sending data to the TCP sink socket on remote.dccs.

      Frame Length: 74       Slice Length: 70
      Errors: None
      Recv Channels: tcpip
ethr: Station 00 DD 01 02 DD 98  ---->  scotty
      Type    IP
  ip: ICMP         128 91  16  59     ->  128 91  254 4
                    (kiwi.dining)         (scotty.dccs)

Data:
0000  03 01 7C C1 00 00 00 00  45 00 04 28 C1 A9 00 00  ..|A....E..(A)..
       |  |
       |  -- Code (host unreachable)
       |
       -- Type (ICMP)

0010  3C 06 B8 5E 80 5B FE 04  80 5B 02 0D 11 95 00 09  <.8^.[~..[......
                  |-source--|  |--dest---|
                  128.91.254.4  128.91.2.13
                  (scotty.dccs) (remote.dccs)

0020  0A 9E 64 01                                       ..d.
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 21:03:02 GMT
From:      ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!hydroesm!jtsv16!geac!tse!tim@beaver.cs.washington.edu  (Tim Brecht)
To:        tcp-ip@nic.ddn.mil
Subject:   SCO, Enet, Microchannel anyone ?

	Is anyone using the following combination:
	SCO Open Desktop, Ethernet, Microchannel.

	We would like contact you with some questions.

tim   tim@tse.uucp   uunet!jtsv16!geac!tse!tim
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 21:08:34 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: VT220 emulation

Thanks for all the comments I got from everybody.  I think the problem
is solved.  For those who find themselves in the same boat at some time
in the future (or present) the solution is (hopefully) FTP Software.
It turns out that the people who thought it was too expensive were dealing
with a quantity 1 price. When site licensing and Educational discounts are
taken into consideration, they become not only the best solution but also
very reasonably priced.

Thanks again for all the advice.

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 21:26:38 GMT
From:      mcsun!unido!ms@uunet.uu.net  (Marc Sheldon)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP over ISDN
pi@complx.UUCP (Kurt Jaeger) writes:
>>This does sound rather too good to be true.  Comments ?
>It sounds very interesting, yes. Well, that solution is useful for
>european ISDN-lines only, I assume :(

It should also work for American ISDN. The supported ISDN-hardware is
capable of the American national ISDN-Standard. The only problem you
will get is to find another person using the proprietary IP-over-ISDN-
implementation of BinTec. But, better still, i hear that they are working
on a PPP-implementation ... Coming real soon now ...

We are going to offer Network-connections to UNIDO using this
implementation of IP-over-ISDN in approx. 3 weeks.

Marc

Marc R. Sheldon                             e-mail : ms@Uni-Dortmund.DE
University of Dortmund, CS-Department
P.O.Box 500500                              voice  : +49 231 7552444
D-4600 Dortmund 50,  West Germany           FAX    : +49 231 7552386
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 21:29:56 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!dartvax!litle!tom@ucsd.edu  (tom hampton)
To:        tcp-ip@nic.ddn.mil
Subject:   Anyone using a Netware -> TCP/Ip Gateway?
I know that both Racal Interlan and Proteon
make gateway products for Netware to TCP/IP
translation.

Is anyone using one of these?  Do they work OK?
Any better ideas?

Thanks for your help.

===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Friday, 21 September 1990 1:59am ET
From:      "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   the flaming fool
> Cliff Frost <cliff@berkeley.edu> or <cliff@ucbcmsa.bitnet> writes:
>
> I've asked Mr. Simpson (twice) in private mail for the specific failings
> of FAL TCP/IP.  He has never responded.  He still fails to include them.
>
I'm sorry, I didn't receive your messages.  We have a very poor mail system
(EMC2/TAO over Spartacus KNET) which drops messages, truncates them, mangles
them, sends many of them to the postmaster because it doesn't understand
legitimate message headers such as source-routes, and otherwise provides
rather unreliable service.  Indeed, I haven't yet received the relay of
my own message to which you are replying (after 3 days)!

Moreover, although I publicly offered to post more complete analysis
if there was enough interest, only 3 people asked for it.  I really didn't
feel that it was worth my time, and the time of the newsgroup.  I had
already spent half a dozen hours sending private messages on the topic
with IBM and Merit.

> He went on (in his original posting) to publically criticize the Yorktown
> team as substandard programmers, mentioning Jay Elinsky by name.
>
A few corrections: the word substandard is yours, not mine.  I mentioned
"real programmers", a term which I substitute these days for "good hacker",
which has been rendered a perjorative by the media; I mentioned *two*
people by name; and that was the second posting, not the first....

Actually, in the *first* posting, I merely mentioned in an off-hand way
that IBM had a terrible implementation of TCP/IP on NIS.NSF.NET.

Bill Rubin then *privately* asked what I disliked about their TCP/IP
(admitting that they do have a terrible implementation of anonymous FTP).
I put in an entire night of benchmarking and packet tracing
(at my own expense), and discussed the results *privately* with Bill Rubin
and Jay Elinsky, who joined later in the conversation.

Now I had thought that I was discussing this with "real programmers"
who were really interested in "getting it right".  Instead, these
fellows sent our private conversation all over IBM and Merit, causing
a political uproar; 6 forwards in one case that I know about.

In My Humble Opinion, "real programmers" do not publish private mail
without permission, and do not start political finger-pointing instead
of fixing problems.

Let me give a counter-example: a few months ago, I found a case where
another implementation of TCP/IP sent a *single* packet with a *single*
extra byte when opening the TCP connection (for a total of 41 extra bytes).
I pointed out the oversight, and made a suggestion for improvement
(publicly, by the way).  The programmer welcomed the criticism, and had
a new version posted within 3 days!  And gained my instant respect....

That's the difference between an ego that says "that's my code --
the problem must be the other guys'!" and an ego that says "that's my code --
I want it to be the best!"

As far as I can tell now, the IBM guys were just marketing flacks,
who took umbrage that anyone would criticize the IBM product in any way.
(They kept saying "we have thousands of satisfied customers".)
I never did get a message that any of the problems I found would be fixed.
Apparently, they also have thousands of ignorant customers.


> Given that Mr. Simpson seems willing to trash people and products by
> name and without giving substantial evidence to support his
> accusations, it would not be surprising if Doug Nelson responded
> spitefully.  In fact, I thought Mr. Nelson responded very mildly.
>
Doug Nelson is responsible for the very poor message system I have to
live with, and the message that he posted long after the message thread
had died had none of the deep technical information that you seem to demand.
Looks like I have to refute and repudiate his message, too.  Another day.

> Unless Mr. Simpson comes up with some previously undisclosed facts the
> only conclusion to draw is that he is nothing more than a "flaming"
> fool.  Yes, the throughput from NIS.NSF.NET is low.  No, that does
> not prove the software on the machine is to blame.
>
Perhaps you have some other explanation.  Perhaps you think that a data
channel on an IBM 4391 has trouble keeping up with 120 bytes per second?
How do they run such things as disk drives?  My tests were designed to
eliminate other considerations such as the Ethernet, gateways, and load.

As for flaming fools, I will note that you have at least 2 public flames
without so much as a single counter-example, alterative test data, or
other objective criterion on which to base your criticism.  My benchmark
is readily verifiable by anyone who wants to take the time
(and as I clearly stated in "performance part 1", has been verified).

You have wasted 2 hours and 11 minutes of my time.

Bill Simpson
   09998was@ibm.cl.msu.edu
   09998was@msu.edu
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 21:59:40 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ungermann-Bass ICMP problems
In article <29878@netnews.upenn.edu> litwack@dccs.upenn.edu (Mark Litwack) writes:
>It's taken me a while to finally figure this out, but
>it seems that Ungermann-Bass PC-NIU/ex cards occasionally
>send out an ICMP host unreachable message to a host that's
>sending too much TCP data to another host on the local
>ethernet.  This has the effect of severing the TCP connection
>between the two innocent hosts.

This is a bug in 4.x BSD TCP.  It causes all blocked open(), read(),
and write() calls to fail with an error when an ICMP Destination Host
(or Network) Unreachable is received.

A quick fix is to patch out the entries at inetctlerrmap+8.  The right
fix is to fix it so only open()'s are nailed.

>I also found that while Ultrix systems cause the TCP application
>to bomb out when it receives the packet, Suns are not affected.
>I guess they have some kind of sanity check for ICMP messages.

I suspect SUNs have this or a similar bugfix.  So do NeXT's.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin  "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105   "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud          "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762  "Chigau.  Gaijin ja nai.
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU    Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 90 22:37:55 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   IBM VM TCP/IP technical shortcomings

There being 5 requests for the information, I suppose that it's
worthwhile to post this to the group at large.
---- ---- ---- ---- ----

First, this implementation does not bundle a reply ACK with
the reply data, resulting in 2 packets.  An ACK is sent right
away when the PSH flag is set.  This behaviour results in slow
FTP startup times, and very slow throughput for short transfers
such as dir LISTs.  This is cited as a poor implementation practice
in RFC1122 at 4.2.2.14.

Similarly, the first data packet is sent separately from the handshake ACK.
Minor, but significant and unexplained.
---- ---- ---- ---- ----

Secondly, there is a serious problem with the retransmission timer.
On startup of successive file transfers, the host-host rtt
does not seem to be remembered (as other implementations do).  The
timer always starts too fast, and takes several timeouts before it
reaches a reasonable value.  (Other implementations reach this value
after 1 timeout, or 2 at most.)  Then, it continues to increment!
Timeouts later in the transfer come at intervals of 20 or 40 seconds,
even after a smooth transmission for dozens of packets!
---- ---- ---- ---- ----

Thirdly, less than MSS sized packets are transmitted.  (I opine that
this is due to an error in the congestion avoidance algorithm,
as it only occurs when the window:MSS ratio is greater than 2.)
---- ---- ---- ---- ----

Fourthly, a "persist" timer kicks in every 5 seconds, and flushes
whatever happens to be in the buffer.  (Yet another source of less
than MSS sized packets.)  This occurs even though the link was
continuously transmitting.  Since the rtt was ~2.4 seconds, this
annoying source of small packets put a serious dent in the throughput.
---- ---- ---- ---- ----

Fifthly, the link itself times out after 10 minutes from startup
(default).  I could understand if that was for an *idle* link
(10 minutes since last packet transmission), but in the middle
of an active transfer?!?
---- ---- ---- ---- ----

Sixthly, the higher level protocols (FTP, SMTP) do not properly treat
the TCP connection as a stream.  Instead -- at least on the control
connection -- the remainder of a PSHed segment is discarded.  That is,
PSHed segments are treated as unit records!  When a properly functioning
TCP combines PSHed segments per 4.2.2.2, they are not properly processed
on the IBM end, resulting in a hung connection.
---- ---- ---- ---- ----

Relevant RFC1122 cites: 4.2.2.2, 4.2.2.14, 4.2.2.15, 45.2.2.17, 4.2.3.1,
4.2.3.2, 4.2.3.4, 4.2.3.5, 4.2.3.6.

Hope this clears up any questions the various flamers have had!

(Why is it the nasty comments are published, and the nice ones are sent
privately?  Not that I didn't appreciate getting them, mind you!
Thanks all!)

Bill Simpson
   09998was@msu.bitnet
   09998was@ibm.cl.msu.edu

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 00:11:17 GMT
From:      excelan!anand@ames.arc.nasa.gov  (Govindaraj Padmanaban)
To:        tcp-ip@nic.ddn.mil
Subject:   NASI or NCSA info wanted...

Where do you think I can get hold of literature on NASI and NCSA.
/* 
 * Apparently these network interfaces are put forwarded by Novell
 * and Network Product centre/group. But I am NOT sure.
 */

I need this info. It would be really great if anybody can throw 
some light on this.

Advance Thanks.

Anand
+------------------------------------------------------------------------+
| We have not inherited the earth from our parents,                      |
|                                     but borrowed it from our children. |
| Govindaraj A Padmanaban - Novell Inc. 408-473-8643(w) 408-263-7055(h)  |
| Email: anand@novell.COM {ames | apple | mtxinu | leadsv }!excelan!anand|
+------------------------------------------------------------------------+
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 09:06:42 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Cc:        pcip@udel.edu, big-lan@suvm.bitnet, ole@csli.stanford.edu
Subject:   Jawboning for more commercially supported distributed mail servers.
Over the last few years, the issue of how to do distributed mail support
within a site full of single-user workstations and PCs has attracted a
good deal of attention from protocol designers, but little from
commercial vendors.  Protocol systems addressing this include POP2/SMTP,
PCMAIL (RFC 1056), POP3/SMTP and POP3/IMAP.  Functionality and details
differ, but each combination manages to give the user mail access
without requiring either a single central machine big enough for
everyone to log in on, or the installation and maintenance nightmare of
making each host act as a full mail forwarder.

At the moment, there are probably almost a dozen supported commercial
clients for POP2, POP3 and PCMAIL on various platforms including DOS,
OS/2 and MACs.  However, I did a survey earlier this summer and only
turned up one new supported server (POP2) to add to the two commercial
POP2 servers I already knew of.  This seems somewhat lame, given the
availability of mature freeware servers for all the protocols, and the
great utility distributed mail represents (I'm on a commuter train using
a laptop to edit this.  It will get sent once I get to work.  This is
how I handle almost all of my mail).

Why am I saying this?  Not as a commercial, or a boast; Sun and IBM
offered DOS clients to go with their servers long before we will
(October), the first three OS/2 TCP/IPs to ship all included clients,
several MAC clients exist.  Instead, I think distributed mail is an idea
whose time has come, and I would be pleased to see it as widespread as X
in a couple of years.  This won't happen unless supported servers are
widely available.

So, the message: Distributed mail is here, it works.  Users and managers
who want it supported should bend their vendors' ears.  Vendors should
look around and evaluate the market that's developing, the number of
clients that are available.  POP2 is obsolescent, I personally prefer
PCMAIL, others prefer POP3 with IMAP, but in the long run timely action
seems more important to me than which protocol system eventually wins.
Read the RFCs, peruse the freeware and get off the dime...

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

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 09:58:08 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mcsun!ub4b!dg13!pnoe@uunet.uu.net  (Pierre Noel)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PC/TCP tnvt product with 8bits characters codes ?
    I found that PC/TCP seems to meet part of our request except that it needs
    a special file to remap keyboard scan codes to output character codes.

There are two files; one to change what input data individual keys generate,
and one to change what received data displays on the screen.  They're only
needed for non-Ascii alphabets.

    ... I found that the tnvt program, in VT220 mode (7 or 8 bit mode), strips
    the 8th bit of the sent caracter.

If we're the ones who strip the 8th bit when Telnet Binary is in effect,
that is our bug (but I just tested 2.04 pl2; it sends 8 bit data fine).
However, if the host you're talking to won't agree to Binary, or strips
the 8th bit itself, that's not under our control.  You need a LAN monitor
of some sort to prove who's at fault.

Problems relating to 8-bit telnet support are common: There are operating
systems which haven't a prayer of handling 8-bit data in a useful way.
Some other OSes can manage 8-bit data from a locally connected terminal
well but their Telnets can't handle Binary, or don't map it to the right
pseudo-tty mode.  Finally, there are applications that make rash
assumptions about the data path to their terminal, etc.  You're not doing
too badly, considering...

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

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 02:32:02 GMT
From:      mcsun!unido!fauern!lan!marvin.e17.physik.tu-muenchen.de!bs@uunet.uu.net  (Bernhard Schneck)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: USER Level SLIP implementations
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:

>>Is it technically possible to have a user level implementation of SLIP
>>under 4.3 BSD and its derivatives?

>There is something called the tunnel driver that allows this.  I'd be 
>interested in anyone who has slip or slfp user level code that works 
>with this.  

I've configured if_tun into my kernel and want to try using SLIP (or
PPP) over a serial line as a backup link.  If anyone has implemented
such a beast alreay I'll take it for free :))

>-- 
>Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us

\Bernhard.
Bernhard Schneck        Internet: B.Schneck@Marvin.E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17  BitNET  : schneck@dgablg5p
8046 Garching           
West Germany            
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 1990 10:11:18 PDT
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP over ISDN
The Michigan ISDN work is described in the October (INTEROP) issue of
ConneXions, page 27. The article is by Dory Leifer of Umich who will
also be showing the ISDN implementation on the INTEROP 90 show floor.


PS. The first sentence of the article has a typo which was introduced
by the editor (me). It refers to ISDN as Integrated Services DATA Network
instead of Digital Network. Oops, sorry, I need more AI than a spell-
checker.  :-)


Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100
Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 03:38:30 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!intelhf!agora!parsely!twiki!dalew@tut.cis.ohio-state.edu  (Dale A. Weber)
To:        tcp-ip@nic.ddn.mil
Subject:   PC-IP from Clarkson

  Apparently, the version of PC/IP I recently got from Clarkson has a bad
NETDEV.SYS file in it (PCIPPKT.ARC is what I got) or there is something
else wrong. Each time I try to run one of the programs from the package,
they complain about an invalid or out of date NETDEV.SYS driver. Does
anyone have a fix for this? I converted the *.ARC file to a *.ZIP and saved
almost 200K on the size of the file.

  Below is the listing of the ZIP archive I have which shows the current
dates on the distributed programs (exactly what I got):

Searching ZIP: PCIPPKT.ZIP

 Length  Method   Size  Ratio   Date    Time   CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   ------  ----  ----
  32676  Implode  18839  43%  01-02-90  10:15  45e32ac3 --w  BOOTP.EXE
  32928  Implode  18959  43%  01-02-90  10:15  d5a6ea7d --w  COOKIE.EXE
  28254  Implode  15761  45%  01-02-90  13:27  921f7b5e --w  CUSTOM.EXE
  43924  Implode  25811  42%  01-02-90  10:15  c911a377 --w  IPRINT.EXE
  51372  Implode  29728  43%  01-02-90  10:15  db707601 --w  LPR.EXE
 145797  Implode  51916  65%  03-29-90  15:01  d3f6502a --w  MANUAL.DOC
    599  Implode    334  45%  03-29-90  15:26  107df475 --w  NETDEV.SYS
  33288  Implode  18996  43%  01-02-90  10:15  275c897d --w  NETNAME.EXE
  45896  Implode  25818  44%  02-26-90  09:51  065dbc7a --w  NETWATCH.EXE
  39392  Implode  22766  43%  01-02-90  10:15  64141b35 --w  NICNAME.EXE
     27  Stored      27   0%  01-02-90  10:16  f6925db5 --w  OFFHOOK.COM
     27  Stored      27   0%  01-02-90  10:16  77b73892 --w  ONHOOK.COM
  37910  Implode  22129  42%  01-02-90  10:15  e71661f8 --w  PING.EXE
  45448  Implode  26419  42%  01-02-90  10:15  96420d70 --w  POP2.EXE
   1794  Implode   1040  43%  03-29-90  15:11  e2889a69 --w  RED.DOC
  54374  Implode  30542  44%  01-02-90  10:15  4321fc5c --w  RED.EXE
  41454  Implode  23831  43%  01-02-90  10:15  7ca3fd94 --w  REXEC.EXE
  34872  Implode  20007  43%  01-02-90  10:16  fbdf1db8 --w  SETCLOCK.EXE
   8555  Implode   3181  63%  03-29-90  15:11  3f650f50 --w  SMTP.DOC
  44910  Implode  25994  43%  01-02-90  10:16  2e7f7ccb --w  SMTP.EXE
  18082  Implode   5863  68%  01-02-90  10:16  d15342e8 --w  TERM.EXE
  65032  Implode  37196  43%  01-02-90  10:16  bc1be762 --w  TN.EXE
  42266  Implode  24349  43%  01-02-90  10:16  9e4ede8a --w  WHOIS.EXE
 ------          ------  ---                                 -------
 848877          449533  48%                                      23

  I would really like to get this package working so I can experiment with
it and see what it can do. An assistance with this will be greatly
appreciated. Thanks in advance.

--
Internet: dalew@pdx.com OR dalew@twiki.pdx.com
UUCP: ..!{ogicse, sun!nosun, tektronix}!tessi!twiki!dalew
 BBS: +1(503)239-4960  1200/2400 Bps [MNP5], 24 hours, PCPable via ORPOR
WORK: Northwest Analytical, Inc.     Voice: +1(503)224-7727
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 08:09:01 EDT
From:      DEDOUREK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: TCP segment size -- user defined?
On  Fri, 21 Sep 90 04:17:00 CDT  William Chops Westfield
<BILLW@MATHOM.CISCO.COM> writes:

>    The upper limits on the size of a TCP segment are:
> 	:
> 	:
>    (3) the "Path MTU"; basically, the largest packet that can be sent
>    from source to destination without fragmentation.
>
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?
John D.
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 08:21:06 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        09998WAS%MSU@PUCC.PRINCETON.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re:  the flaming fool
I've been watching this go on for some time now and actually
have been mildly amused by it all.  However, I think that
this has gone a bit too far..... In a previous life I worked
"a bit" on KNET. In fact, I was the development manager of it
at the time that IBM's TCP hit the street. Obviously, we at
Spartacus had a desire to keep abreast of what was going on with
the product. At first it was bad. All products are. It rapidly got
better. Most, if not all, of this was apparently due to Jay's
efforts. As an ex competitor, I would say that Jay rates being
a real programmer (or at least in V=R space :-). 


I have not been following this area for a couple of years
now. Maybe Jay's efforts were "recognized" at IBM so they
promoted him out of being a techno-geek into being a
management-drone. If so, I'm sorry.


To keep the lawyers happy....
This message in no way reflects the opinions, etc, of Racal
Interlan, or etc Spartacus/Fibronics. Everything is my own
opinion.

Frank Kastenholz
Ex-KNET-eer

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 12:23:43 -0400
From:      Michael T. Stolarchuk <mts@terminator.cc.umich.edu>
To:        mcsun!ukc!dcl-cs!aber-cs!dap@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil, dory_leifer@um.cc.umich.edu, mts@terminator.cc.umich.edu
Subject:   Re: TCP/IP over ISDN

I'm suprised dory leifer hasn't said anything... Maybe he doesn't
read tcp-ip.  He has been working on tcp-ip over ISDN for over
a year.  He demoed his work at the last year educom at UofMichigan.

I'm cc-ing him on this message in the hope that it will prompt
him to send mail to tcp-ip.

mts. the snail.
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 07:17:50 GMT
From:      09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   the flaming fool

> Cliff Frost <cliff@berkeley.edu> or <cliff@ucbcmsa.bitnet> writes:
>
> I've asked Mr. Simpson (twice) in private mail for the specific failings
> of FAL TCP/IP.  He has never responded.  He still fails to include them.
>
I'm sorry, I didn't receive your messages.  We have a very poor mail system
(EMC2/TAO over Spartacus KNET) which drops messages, truncates them, mangles
them, sends many of them to the postmaster because it doesn't understand
legitimate message headers such as source-routes, and otherwise provides
rather unreliable service.  Indeed, I haven't yet received the relay of
my own message to which you are replying (after 3 days)!

Moreover, although I publicly offered to post more complete analysis
if there was enough interest, only 3 people asked for it.  I really didn't
feel that it was worth my time, and the time of the newsgroup.  I had
already spent half a dozen hours sending private messages on the topic
with IBM and Merit.

> He went on (in his original posting) to publically criticize the Yorktown
> team as substandard programmers, mentioning Jay Elinsky by name.
>
A few corrections: the word substandard is yours, not mine.  I mentioned
"real programmers", a term which I substitute these days for "good hacker",
which has been rendered a perjorative by the media; I mentioned *two*
people by name; and that was the second posting, not the first....

Actually, in the *first* posting, I merely mentioned in an off-hand way
that IBM had a terrible implementation of TCP/IP on NIS.NSF.NET.

Bill Rubin then *privately* asked what I disliked about their TCP/IP
(admitting that they do have a terrible implementation of anonymous FTP).
I put in an entire night of benchmarking and packet tracing
(at my own expense), and discussed the results *privately* with Bill Rubin
and Jay Elinsky, who joined later in the conversation.

Now I had thought that I was discussing this with "real programmers"
who were really interested in "getting it right".  Instead, these
fellows sent our private conversation all over IBM and Merit, causing
a political uproar; 6 forwards in one case that I know about.

In My Humble Opinion, "real programmers" do not publish private mail
without permission, and do not start political finger-pointing instead
of fixing problems.

Let me give a counter-example: a few months ago, I found a case where
another implementation of TCP/IP sent a *single* packet with a *single*
extra byte when opening the TCP connection (for a total of 41 extra bytes).
I pointed out the oversight, and made a suggestion for improvement
(publicly, by the way).  The programmer welcomed the criticism, and had
a new version posted within 3 days!  And gained my instant respect....

That's the difference between an ego that says "that's my code --
the problem must be the other guys'!" and an ego that says "that's my code --
I want it to be the best!"

As far as I can tell now, the IBM guys were just marketing flacks,
who took umbrage that anyone would criticize the IBM product in any way.
(They kept saying "we have thousands of satisfied customers".)
I never did get a message that any of the problems I found would be fixed.
Apparently, they also have thousands of ignorant customers.


> Given that Mr. Simpson seems willing to trash people and products by
> name and without giving substantial evidence to support his
> accusations, it would not be surprising if Doug Nelson responded
> spitefully.  In fact, I thought Mr. Nelson responded very mildly.
>
Doug Nelson is responsible for the very poor message system I have to
live with, and the message that he posted long after the message thread
had died had none of the deep technical information that you seem to demand.
Looks like I have to refute and repudiate his message, too.  Another day.

> Unless Mr. Simpson comes up with some previously undisclosed facts the
> only conclusion to draw is that he is nothing more than a "flaming"
> fool.  Yes, the throughput from NIS.NSF.NET is low.  No, that does
> not prove the software on the machine is to blame.
>
Perhaps you have some other explanation.  Perhaps you think that a data
channel on an IBM 4391 has trouble keeping up with 120 bytes per second?
How do they run such things as disk drives?  My tests were designed to
eliminate other considerations such as the Ethernet, gateways, and load.

As for flaming fools, I will note that you have at least 2 public flames
without so much as a single counter-example, alterative test data, or
other objective criterion on which to base your criticism.  My benchmark
is readily verifiable by anyone who wants to take the time
(and as I clearly stated in "performance part 1", has been verified).

You have wasted 2 hours and 11 minutes of my time.

Bill Simpson
   09998was@ibm.cl.msu.edu
   09998was@msu.edu

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 07:53:02 GMT
From:      fernwood!portal!cup.portal.com!thad@apple.com  (Thad P Floryan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3B2 interest group
mckee@CHANCE.MITRE.ORG (H. Craig McKee) in <9009181650.AA09852@chance.mitre.org
>
writes:

	Is there an interest group for AT&T 3B2 computers?

There are two Usenet hierarchies which appear to satisfy your quest, another
that may be interesting, and a fourth of general-interest:

comp.sys.att	has material for 3B1/UNIXPC/PC7300, 3B2/300, 3B2/310, 3B2/400,
		3B2/600, 3B2/1000, 6300, 6386, and related systems

u3b.*		concentrates on the 3B2 family exclusively

unix-pc.*	concentrates on the 3B1/UNIXPC/PC7300 family exclusively

comp.unix.*	general material


Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Sep 90 16:19:00 -0400
From:      Dory Leifer <del@runningman.cc.umich.edu>
To:        mts@runningman.cc.umich.edu
Cc:        dap%aber-cs%dcl-cs%ukc%mcsun.uucp@uunet.uu.net, tcp-ip@nic.ddn.mil, dory_leifer@um.cc.umich.edu
Subject:   Re: TCP/IP over ISDN

 
I'm suprised dory leifer hasn't said anything... Maybe he doesn't
read tcp-ip.  He has been working on tcp-ip over ISDN for over
a year.  He demoed his work at the last year educom at UofMichigan.
 
I'm cc-ing him on this message in the hope that it will prompt
him to send mail to tcp-ip.
 
mts. the snail.

--------

Thanks Mike. I usually do not read tcp-ip because of the large
volume of traffic on it. People usually do forward me items
that seem relevant to what I am working on. There is a 
separate mailing group that is dedicated to IP over ISDN.
I would suggest that interested parties move their discussion
to this group. The group can be addressed at:

TCP-ISDN@list.prime.com

or TCP-ISDN-REQUEST@list.prim.com  to be added.

In any case,  I will be doing a demo of IP over ISDN at
InterOp next month as well as a talk on what has been done
here. Also there is a fairly involved article for this
month's issue of Connexions.


Dory Leifer
Information Technology Division
The University of Michigan
+1 313 763 4896 
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 09:42:27 GMT
From:      eru!hagbard!sunic!swbull!love@bloom-beacon.mit.edu  (Love Feuer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
bob@MorningStar.Com (Bob Sutterfield) writes:
>That's odd.  Far less sick things use UDP, like the Network Time
>Protocol and the Domain Name System.  They're both entirely
>appropriate and necessary to run over long-haul links like X.25.

I am very, very sorry. I did not check my sources. It is
possible to run UDP/IP based protocols over X.25 under B.O.S.,
including NFS. Although I was told otherwise by my friends here at Bull. 

I have remote mounted file systems in Norway to our local machine
in Sweden. And it works, even if it is slow due to the 2400 BPS modem at 
the norwegian side of the network.

Sorry again for any headache that my (incorrect) information might have
caused.

/Love Feuer  Bull Sweden +46-8-7284349
love@swbull.bull.se
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 13:59:03 GMT
From:      eru!hagbard!sunic!isgate!krafla!goggi@bloom-beacon.mit.edu  (Gardar Georg Nielsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PC/TCP tnvt product with 8bits characters codes ?
In <1990Sep20.160435.3617@dg13.cec.be> pnoe@dg13.cec.be (Pierre Noel) writes:

>Hi Netland, 

>For the time being, I have been requested to test some TCP/IP packages on PC to correctly negociate with our Unix servers.

>By the way, If you know other products working on PC and giving coherent 
>VT220 or ANSI emulation (No Excelan nor PC/NFS Telnet : I found them non-suita- ble for European emulations).

Here in at the University of Iceland we are using patched version of
PC-NFS Telnet which is 8bit transparent and translates between the PC character
set and ISO 8859/1.
If anyone is interested I coul'd make it available.

goggi@rhi.hi.is
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 15:22:07 GMT
From:      edith@uts.amdahl.com (Edith Fortin)
To:        comp.lang.c,comp.protocols.tcp-ip
Subject:   compilation of a C program with calls to lib socket ?


 I'm trying to compile a C program on VM/CMS which includes
calls to a CMS emulation socket package.

Unfortunately, the C compiler truncates the external symbols
 to 8 characters (IBM C for System/370).
    - Does anybody know of a better C compiler on VM/CMS ?

    - or any other way to do ?

  edith
==========================================================
edith@uts.amdahl.com

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 17:35:24 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 9 interesting & challenging problems for Netman
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>3. given a traffic matrixfor a LAN, automatically find the best place
>to partitionm the net with a bridge/switch/router (subject to any
>sensible topographical/logical or other constraints).

All of the other problems seem to be Hard, but this one should be
solvable by ordinary Operations Research techniques.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 18:09:55 GMT
From:      agate!bionet!ucselx!sol.ctr.columbia.edu!srcsip!msi-s0.msi.umn.edu!cs.umn.edu!sialis!dmshq!com50!rosevax!atc!sstat!moria!bas@ucbvax.Berkeley.EDU  (Brian Strop)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet Drivers over UB NIUpc card
I am trying to use the Clarkson packet drivers with an Ungermann-Bass
NIUpc adapter.  My attempts are failing miserably.  Each time I specify
(invoke) the packet driver (via ubnic 0x60 0x4 0xc800) my PC hangs and
I have to power it off to get control back (I do get the message 'Packet
driver loaded at xxxx' before it hangs).  Is any one out there using the
packet drivers with the UB NIUpc card?  Can it be done?  Thanks in advance
for any help.

B. Strop
-- 
Brian A. Strop				(612) 687-2709
UNISYS					bas%moria@atc.sp.unisys.com
Network Systems
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 19:27:53 GMT
From:      agate!garnet.berkeley.edu!cliff@ucbvax.Berkeley.EDU  (Cliff Frost)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: the flaming fool

In article <9009210717.AA21143@ucbvax.Berkeley.EDU>,
09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes:
|> > Cliff Frost <cliff@berkeley.edu> or <cliff@ucbcmsa.bitnet> writes:
|> >
...
|> > Unless Mr. Simpson comes up with some previously undisclosed facts the
|> > only conclusion to draw is that he is nothing more than a "flaming"
|> > fool.  Yes, the throughput from NIS.NSF.NET is low.  No, that does
|> > not prove the software on the machine is to blame.
|> >
|> Perhaps you have some other explanation...

Yes, there are any number of other plausible explanations for the data
you had publically posted, although my statement should have read:
"...does not prove the TCP/IP software on the machine is to blame."

For example, a VM machine with improperly configured scheduling can
absolutely destroy TCP/IP performance; for example by keeping the code
from running when it needs to.  No amount of cleverness by the TCP/IP
programming team could make up for this.

|> As for flaming fools, I will note that you have at least 2 public flames
|> without so much as a single counter-example, alterative test data, or
|> other objective criterion on which to base your criticism.

This is a lie.  My very first posting on this subject (the one you are
quoting from!) contained possible alternate explanations for 3 specific
problems you mentioned:

1)  "less than MSS sized packets"	
	Packet size is configurable in a couple of ways in that product.

2)  "too many retransmissions"
3)  "timeouts of 20 seconds or more"
	Trivial to accomplish by misconfiguring the VM scheduler
	(that is, nothing to do with the scheduler in the TCP/IP sw.)
	    
Without the data that you *finally* produced there was no way for us to
rule those theories out.

|>   My benchmark
|> is readily verifiable by anyone who wants to take the time
|> (and as I clearly stated in "performance part 1", has been verified).

I have never challenged either your benchmark or your assertion that there
are problems in the software.  What I said was that you had not given us
enough information to evaluate the substance of your criticisms of it. 
You posted the ambiguous data 3 times, so I can't imagine why you hesitated
to post the real data--it's both shorter and much more interesting.

I will say that in my experience, Bill Rubin and Jay Elinsky have been
both "real programmers" and very responsive to customers problem reports.
We're all aware by now that you feel differently.

	Cliff Frost
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 20:40:47 GMT
From:      usc!srhqla!unigold!lance@ucsd.edu  (Lance Ellinghouse)
To:        tcp-ip@nic.ddn.mil
Subject:   What is a UNIX Domain Socket?
Ok, I know this is a dumb question..

What exactly is a Unix Domain Socket?
What makes it different from a INET Socket?

Thanks,

+----------------------------------------------+------------------------------+
|Lance Ellinghouse                             |Any ideas on what to put here?|
|E-mail: lance@unigold.uucp                    |I have no idea... :)          |
|        unigold!lance@srhqla.sr.com           |                              |
|        hermix!unigold!lance@anes.ucla.edu    +------------------------------+
|USnail Mail: UNIGOLD, 16311 Ventura Blvd. Suite 1100, Encino, Ca, 91436      |
+-----------------------------------------------------------------------------+
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 90 20:58:04 GMT
From:      resource!bryan@tut.cis.ohio-state.edu  (Bryan M. Beck)
To:        tcp-ip@nic.ddn.mil
Subject:   Strange TCP/IP problem, Please help.

Help,

This is pretty lenghtly so please bare with me.

I had a 2 node tcp/ip lan running on thin wire using 3Com 3c053
cards running between 1 386/20 running SCO XENIX and 1 486/25 running
SCO UNIX 3.2 in both cases I am using SCO TCP/IP.  Lets call there nodes
A and B.

         A <---------> B
address
--------
A = 132.147.160.5
B = 132.147.160.10

All communication between A and B works great (ftp,telnet,rcmd,rlogin).

Then I added node C another 386/25 running SCO XENIX with same 3Com and
same TCP/IP.  Like so.

	A <---------> B <--------> C

addresses
---------
A = 132.147.160.5
B = 132.147.160.10
C = 132.147.160.7

Now here comes the part that stumps me. Systems A and B still work fine
as described above but System C cannot telnet,ftp to machine B.  It
just says trying.... and the eventually times out.  But System C can
telnet,ftp,ping.... to System A. Also System A and B can telnet,ftp,
ping to C.

Does anyone have any ideas.  I could really use some.  

Please e-mail all responses.

Thanks,
Bryan 

-- 
Bryan M. Beck                                       Resource Systems
UUCP: osu-cis!resource!bryan                        Suite 390 2545 Farmers Drive
INTERNET: bryan@resource.com                        Columbus, Ohio  43235
VOICE: (614) 764-7800                               FAX: (614) 764-7850
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 90 00:00:27 GMT
From:      afsg!ron@apple.com  (Ron Flax)
To:        tcp-ip@nic.ddn.mil
Subject:   Webster Servers
Does anyone know of any Webster servers on the Internet with
a liberal access policy?   What, if any, restrictions apply?

Thanks.

--
Ron Flax
ron@afsg.apple.com	
Apple Federal Systems Group

PS. Sorry for posting this to comp.protocols.tcp-ip but I
    figured this is were I'd get the best response from.
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 90 01:51:39 GMT
From:      Brian_C_McBee@cup.portal.com
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   MAC MS-MAIL to SMTP gateway?

We have MS mail running on our appletalk network, shich is connected to
our ethernet with a Kinetics Fastpath.  What is our best bet for gatewaying
MS-MAIL to SMTP?  Failing that, how about MS-MAIL to VAXMAIL?  SMTP would
be best, but we'll take what we can get.  Thanks.

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 90 11:50:07 GMT
From:      Z.Wang@CS.UCL.AC.UK (Zheng Wang)
To:        comp.protocols.tcp-ip
Subject:   Re: 9 interesting & challenging problems for Netman


 >Here are what we consider to be 9 interesting & challenging problems for
 >network management (these are based on
 >real requirements, not tedious exhaustive MIB definitions):
 
 >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...
 
 >3. given a traffic matrixfor a LAN, automatically find the best place
 >to partitionm the net with a bridge/switch/router (subject to any
 >sensible topographical/logical or other constraints).
 
 >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...
 
 >6. Given a general traffic trace, detect patterns of communication
 >involving more > than 2 parties (e.g. YP or DNS lookup followed by
 >telnet is triv. case).
 
 >7. Interpret auto-correllation between packets from/to and/or
 >same src/dst in a sensible fashion...
 
 >8. Given a trace of packets between 2 protocol entities at layer 4,
 >invent a pleasant and efficient programming language to describe &
 >enable the reconstruction of application level exchanges.
 
 >9. Do all of the above for an Internet.

To solve all the problems by machines can be very hard. We may have
to wait a couple of years for neural nets to grow and to learn.
But human brains are the best to do those jobs. What is needed
is a tool for us to see the traffic inside the cables.

I imagine what we need is a huge screen (as seen at some city
traffic control centers) with all the nodes and links. Each
connection is represented by a thin line. When traffic passes,
it leaves a trace on the line. So the more traffic passes, the darker
the line is. Different traffic can be represented by different
colors (eg. Yellow Page traffic is yellow :-) We also need some
buttons so we can choose to average the traffic at different
intervals. Yes, we need a camera to get a snap shoot from time
to time.

With the visulization of the complete traffic, a human brain
can easily answer some of the 9 questions.

For a LAN, to collecting the data at a reasonable interval may
not be a problem. But for an Internet, we may have to put all the
snap shoots together to see the whole picture.

Zheng

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Sep 90 12:50:07 +0100
From:      Zheng Wang <Z.Wang@cs.ucl.ac.uk>
To:        Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Cc:        tcp-ip@nic.ddn.mil, netman@rutherford.ac.uk, net-management@cs.ucl.ac.uk
Subject:   Re: 9 interesting & challenging problems for Netman

 >Here are what we consider to be 9 interesting & challenging problems for
 >network management (these are based on
 >real requirements, not tedious exhaustive MIB definitions):

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

 >3. given a traffic matrixfor a LAN, automatically find the best place
 >to partitionm the net with a bridge/switch/router (subject to any
 >sensible topographical/logical or other constraints).

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

 >6. Given a general traffic trace, detect patterns of communication
 >involving more > than 2 parties (e.g. YP or DNS lookup followed by
 >telnet is triv. case).

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

 >8. Given a trace of packets between 2 protocol entities at layer 4,
 >invent a pleasant and efficient programming language to describe &
 >enable the reconstruction of application level exchanges.

 >9. Do all of the above for an Internet.

To solve all the problems by machines can be very hard. We may have
to wait a couple of years for neural nets to grow and to learn.
But human brains are the best to do those jobs. What is needed
is a tool for us to see the traffic inside the cables.

I imagine what we need is a huge screen (as seen at some city
traffic control centers) with all the nodes and links. Each
connection is represented by a thin line. When traffic passes,
it leaves a trace on the line. So the more traffic passes, the darker
the line is. Different traffic can be represented by different
colors (eg. Yellow Page traffic is yellow :-) We also need some
buttons so we can choose to average the traffic at different
intervals. Yes, we need a camera to get a snap shoot from time
to time.

With the visulization of the complete traffic, a human brain
can easily answer some of the 9 questions.

For a LAN, to collecting the data at a reasonable interval may
not be a problem. But for an Internet, we may have to put all the
snap shoots together to see the whole picture.

Zheng
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 90 15:36:48 GMT
From:      cs.utexas.edu!know!memora.pws.bull.com@tut.cis.ohio-state.edu  (Steve Elias)
To:        tcp-ip@nic.ddn.mil
Subject:   cuckoo's egg goes nova
the Cliff Stoll Story is on NOVA this october...
premiering oct 2 (in boston, at least) tuesday at 8pm.


-- 
know()		/* eli@pws.bull.com   617 932 5598   fax 508 294 0101  */
{
char cp = valloc(space); strcat(cp,"yo"); 
strncat(cp, index( "eli@pws.bull.com", 'b' ), 4); fputs(cp); }
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 90 21:44:53 GMT
From:      spdcc!dyer@husc6.harvard.edu  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   What's the current status of dialin terminal servers
Several months ago there was some discussion of the regional and
commercial networks which comprise the Internet offering some form of
fee-for-membership or fee-for-use dialin service at major metropolitan
centers.  I seem to remember some expressions on interest or intent on
the part of Alternet and Barrnet, and I believe that PSInet offers
dialup service, though at the time it only offered connections to other
PSInet sites, and therefore was not useful as a general Internet
resource.

Can anyone comment on the current status of these or any other initiatives
in this area?

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 90 13:56:24 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Drivers over UB NIUpc card
In article <562@moria.Sp.Unisys.Com> bas@moria.Sp.Unisys.Com (Brian Strop) writes:
>I am trying to use the Clarkson packet drivers with an Ungermann-Bass
>NIUpc adapter.  My attempts are failing miserably.  Each time I specify
>(invoke) the packet driver (via ubnic 0x60 0x4 0xc800) my PC hangs and
>I have to power it off to get control back (I do get the message 'Packet
>driver loaded at xxxx' before it hangs).  Is any one out there using the
>packet drivers with the UB NIUpc card?  Can it be done?  Thanks in advance
>for any help.
>

ubnic.com is for Ungermann's NIC card, not for the NIU card (and therfore
dosn't work on the NIU - it dosn't even work on the NIC-PS2. It only works
on the NIC-ISA).

1. I think Russ mentioned that there was a NIU packet driver in the works, so
you could wait for version 8 of the packet drivers.

2. You can run your packet driver application on top of an NDIS driver via
FTP's dis_pkt (archived on ftp.vax.com). The NDIS driver for the NIU is 
available from UB for a charge of $50.


-- 
 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."
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 00:47:38 PDT (Mon)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        aussie!tong@shlump.nac.dec.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   choosing ethernet packet type automatically
The Hosts Requirements group talked about the issue and decided that
if you want to run both encapsulations on one ethernet, they must be
two different subnets; you should not try to automatically negotiate
which encapsulation to use. You need a router to switch packets, even
though they're the same cable, logically they're two separate subnets.

I was a proponent of using ARP to negotiate encapsulation, similarly
to the way 4BSD TCP now uses ARP to negotiate trailers, but I agree with
the decision. The broadcast problem is that you need to decide which
format to broadcast in, and you don't want to broadcast twice (I don't
recall there being more to it than that). Another problem is that the
MTU is different between ethernet and IEEE 802. And this scheme is
also idealogically more pure: you want to switch packets between
encapsulations, you use a router.

I would recommend that if you want to support both, you create two
different logical network interfaces that use the same physical
interface, and have them use different encapsulations and different
network numbers. That's the way I'm handling it in an IP
implementation I'm working on now.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 90 18:48:16 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   DIAL n' CERF: Re: What's the current status of dialin terminal servers

In article <4145@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.com (Steve Dyer) writes:
>
>Can anyone comment on the current status of
these [DIAL UP INTERNET ACCESS] or any other initiatives
>in this area?

This question came up recently in comp.protocols.tcp-ip.ibmpc
What follows is the posting I made there.
--pushpendra
CERFnet
-----------------------------------------------------------------
Enough of you have written seeking information  on
DIAL n' CERF , CERFnet's Dial-Up Internet Access Service.
to warrant this reply:

DIAL n' CERF ( and similar) services cater chiefly to :

	Organizations/Individuals  with legitimate  but low start up
	needs to access the Internet.
	Organizations/Individuals  with legitimate  but short term 
	needs to access the Internet.
	To "roamers", who already have access to the Internet in their 
	parent organizations, but need this access when traveling. 

DIAL n' CERF offers:	Terminal Service ( telnet, rlogin )
                  	SLIP
                  	USENet News
                  	Internet Mailboxes

CERFnet currently offers this service at the following locations:
(Other sites are under consideration as are alternate access schemes.)

----------------------------------------------------------------
DIAL n' CERF  LOCATIONS

Southern California
SDSC	San Diego SuperComputer Center	
	SANDIEGO
CIT	Caltech Institute of Technology	
	PASADENA
UCI	University Of California, Irvine
	IRVINE
UCLA	University of California, Los Angeles
	WESTWOOD

Northern California
UCOP	University of California, Office of the President
	OAKLAND
----------------------------------------------------------------------


For further information retrieve the files

dial-n-cerf-agreement.txt ( includes cerfnet-acceptable-use-policy )
dial-n-cerf-locations.txt

by anonymous ftp from NIC.CERF.NET [ 134.24.99.3 ]
in the directory ~ftp/cerfnet/cerfnet_info 

This site is also a good repository of information
on the Internet for beginners and we encourage its use. 

If currently without ftp access send mail to
help@cerf.net or 
call (619) 534-5087

If visiting Interop 90 look us up at the CERFnet booth.


Pushpendra Mohta		pushp@cerf.net		(619) 534-5056
CERFNet/SDSC	 		pushp@sdsc.bitnet	(619) 534-5167 FAX
P.O.Box 85608			
San Diego, CA 92186-9784
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Sep 90 13:42:05 -0700
From:      jqj@hogg.cc.uoregon.edu
To:        romkey@asylum.sf.ca.us
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: choosing ethernet packet type automatically
>The Hosts Requirements group talked about the issue and decided that
>if you want to run both encapsulations on one ethernet, they must be
>two different subnets
 ...
>I would recommend that if you want to support both, you create two
>different logical network interfaces that use the same physical
>interface, and have them use different encapsulations and different
>network numbers.

I wasn't there, but that's not my interpretation of rfc1122 as published.  If
your interpretation were correct, there would be no need for the requirement
that all hosts be able to hear Ethernet encapsulation.  My reading of the
paragraph referencing "two different logical networks on the same cable," is
that this appears as a justification fo NOT allowing 1042-only systems, not
as a recommendation for how to deal with 1042-only systems!

As I read it, the expectation is that you'll normally have a single subnet,
and that Ethernet is dominant; the assumption is that everybody normally uses
Ethernet, but that consenting systems might agree by some unspecified means
to use rfc1042 (possibly unidirectionally) for unicast traffic.  As I read
it, if you support rfc1042 at all you must support it by treating receipt
of such packets just as if they had been received in rfc894 encapsulation.

This interpretation is particularly plausible given the advent of
heterogenous bridging.  Most proposals for transparent bridging between
Ether/802.3 and other 802.x media (e.g. FDDI or IBM TR) imply that packets
(not just IP) generated on the Ethernet in 1042 encapsulation may arrive at
their destination on another Ethernet in Ethernet encapsulation.  This
breaks Appletalk II, of course, but was not supposed to break IP.
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Sep 90 07:56:59 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: choosing ethernet packet type automatically
> From: romkey@asylum.sf.ca.us (John Romkey)
>
> The Hosts Requirements group talked about the issue and decided that
> if you want to run both encapsulations on one ethernet, they must be
> two different subnets; you should not try to automatically negotiate
> which encapsulation to use. You need a router to switch packets, even
> though they're the same cable, logically they're two separate subnets.
>
> I was a proponent of using ARP to negotiate encapsulation, similarly
> to the way 4BSD TCP now uses ARP to negotiate trailers, but I agree with
> the decision. The broadcast problem is that you need to decide which
> format to broadcast in, and you don't want to broadcast twice (I don't
> recall there being more to it than that).

I can agree with not broadcasting two packets each time, but what about a
scheme that alternates between the two packet types when ARPing.  You could
start with your default packet type and if no response is received, send
the first retry in the other packet type etc. until a reply is received or
timeout occurs.

>                                            Another problem is that the
> MTU is different between ethernet and IEEE 802. And this scheme is

And this is of course another animal.

> also idealogically more pure: you want to switch packets between
> encapsulations, you use a router.

Ideological purity aside, I would hope that any solution that can be made
to work now would be alright as I hope someday the word standard recovers
it's original meaning and we all start doing things the same way.

>
> I would recommend that if you want to support both, you create two
> different logical network interfaces that use the same physical
> interface, and have them use different encapsulations and different
> network numbers. That's the way I'm handling it in an IP
> implementation I'm working on now.
>             - john romkey
> USENET/UUCP: romkey@asylum.sf.ca.us  Internet: romkey@ftp.com

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 11:26:06 PDT (Mon)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        702WFG%scrvmsys.bitnet@genbank.bio.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   choosing ethernet packet type automatically
The ARP scheme you suggested is what I and other people suggested.
When we talked about it in the Host Requirements group, problem after
problem surfaced until someone finally said, "Look, why don't we do it
the right way? They're different encapsulations; put a router between
them." And we were enlightened.

The router solution can be made to work now, and I really think it's
the right one.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 05:25:37 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet Drivers over UB NIUpc card
In article <13685@netcom.UUCP> jbreeden@netcom.UUCP (John Breeden) writes:

   1. I think Russ mentioned that there was a NIU packet driver in the
   works, so you could wait for version 8 of the packet drivers.

Nope, a NICps/2 driver is in the air (not the works).  The UB rep in Syracuse
is supposedly sending me the documentation for writing a driver.  Good thing
I haven't been holding my breath...

I suggest you don't hold your breath either.

--
--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
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 05:30:51 GMT
From:      bacchus.pa.dec.com!shlump.nac.dec.com!aussie!tong@decwrl.dec.com  (Benny Tong)
To:        tcp-ip@nic.ddn.mil
Subject:   choosing ethernet packet type automatically

    RFC 1122 2.3.3 (p.24) says:
    
    The IP encapsulation for Ethernets is described in RFC-894
    [LINK:3], while RFC-1042 [LINK:4] describes the IP
    encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
    replaces the discussion in Section 3.4 of [INTRO:2].
    
    Every Internet host connected to a 10Mbps Ethernet cable:
    
    o    MUST be able to send and receive packets using RFC-894
    	 encapsulation;
    
    o    SHOULD be able to receive RFC-1042 packets, intermixed
    	 with RFC-894 packets; and
    
    o    MAY be able to send packets using RFC-1042 encapsulation.
    
    
    An Internet host that implements sending both the RFC-894 and
    the RFC-1042 encapsulations MUST provide a configuration switch
    to select which is sent, and this switch MUST default to RFC-894.
    
    [...]
    
    Note that 894-only systems cannot interoperate directly
    with 1042-only systems.  If the two system types are set
    up as two different logical networks on the same cable,
    they can communicate only through an IP gateway.
    Furthermore, it is not useful or even possible for a
    dual-format host to discover automatically which format to
    send, because of the problem of link-layer broadcasts.
    
    <end of quote>
    
    Question :
    
    Why is it not useful, or even possible for a dual-format host
    to determine automatically which format to send? What is the
    problem with link-layer broadcasts?
    
    Will this scheme work?
    
    When an IP datagram needs to be sent to an unknown Internet host, ARP
    request packets of both ethernet and 802.3 types are broadcasted to the
    ethernet. The IP datagram is queued for later transmission. When an ARP
    reply comes back, the same packet type and ethernet address as the ARP 
    reply is used for sending the IP datagram. If replies with two packet
    types come back, the default packet type can be used.
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 06:51:46 GMT
From:      voder!pyramid!csg@ucbvax.Berkeley.EDU  (Carl S. Gutekunst)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
>Have anybody tried this weird combination?

Sure. To place the call, I modified the 4.3BSD slattach(8) utility to open up
an X.25 device, perform call setup, condition the line for data only, and then
change the line discipline to SLIPDISC. A similar trick could be done with a
hardware PAD and a uucico-like dialer. To answer the call, I simply used the
NASA Ames slipsh (SLIP Shell), and invoked it right out of /etc/passwd.

The likely problems are:

- If you are using a PAD, it will have to be able to go 8-bit transparent. In
  this case, it will also be imperitive that the answering side emit the right
  X.3 parameters before going to the SLIP discipline. This might happen auto-
  matically; or you might have to kludge something into slipsh.

- If you are using a host-based interface, either a software PAD or a direct
  X.25 connection, it will have to have true line discipline support, and it
  will have to correctly set the PAD parameters when the line discipline is
  changed. Out of a dozen or so commercial UNIX X.25 implementations that I
  am aware of, only Pyramid and Sun do this correctly, although I'd bet that
  most of the university ones will, too. I'd guess that Sun's is hard on the
  machine because you have to wander in and out of the "if" layer twice; but
  I haven't tried it, so I don't really know.

Performance between two Pyramids was very good, although I was using a 72Kbps
link. :-) Over 9600bps, expect interactive response to be sluggish, certainly
more so than over a direct wire or a modem. Some of this will depend on your
ability to tune X.29 behavior, if applicable. (A good X.29 will try to bunch
up characters into full packets.) We also have the Van Jacobson 4.3BSD-tahoe
performance enhancements (as does Sun), which seem to make a big difference on
SLIP. 

SLIP over X.25 is not anywhere as weird as it sounds. A proper IP over X.25
implementation (like SNDCF) is a nasty and complex beast. SLIP over X.25 is a
cheap and easy way to get point-to-point IP over X.25, with only slightly
higher overhead. SLIP/X.25 can even run over a PAD, which SNDCF cannot. The
big disadvantage, of course, is that SLIP/X.25 *is* point-to-point, just like
regular SLIP; you have to place a call and keep it there for every X.25
address to which you are likely to connect. 

<csg>
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 16:41:30 PDT (Mon)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        jqj@hogg.cc.uoregon.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   choosing ethernet packet type automatically
Well, I speak only for myself and say only me perception of the
matter. I don't speak for the Hosts Requirements group.

I believe that the reason for all hosts to be able to hear Ethernet
packets is that very few vendors supported (and even now, support)
RFC 1042 encapsulation, and the group wanted to ensure
interoperability. In practical terms, if you want to interoperate with
TCP/IP on ethernet/IEEE 802.3 networks, you must support RFC 894
encapsulation. I think that requirement is just a reflection of the
practical situation we're living with now.

If you want the voice of Host Requirements on the matter, Bob Braden
will have to speak up.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 14:40:22 GMT
From:      rohvm1!madjk@cunyvm.cuny.edu  (John G Kinker)
To:        tcp-ip@nic.ddn.mil
Subject:   Source for TRACEROUTE, BOOTPD and RARPD
Is the source for one or more of the subject programs available via anonymous
FTP?  I am interested in source which will compile on an Apollo under Domain/OS
version 10.2 but will certainly settle for generic source as well.
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 15:06:14 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!polygen!bill@ucsd.edu  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   Sys V Unix TCP/IP abilities
I have noticed that Xenix/286 has trouble receiving rlogin/rexec calls from 
a BSD client.  Is this indicitive of all SYSV implementations of TCP/IP 
software.  What I am trying to do is authorize PC Users on a network,
and the way I am doing it is by making an rexec call (which uses the BSD 4.2 
spec) to a Xenix 286 machine.  If the rexec call succeeds, the authorization
program lets them in.  Can anyone give me help here?  Is this doable with 
what I have?  Are all SYSV TCP/IP alike?  Any help would greatly be appreciated.

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 15:17:20 GMT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   SNMP comparison

SNMP product comparison time:

Product name            Company Name
------------            ------------
Dual Manager            Netlabs
Netmon III              SNMP Research
LAN Systems 9100 NMC    Hughes
OverVIEW                Proteon
NCC                     Unisys
NMS                     cisco
WIN/MGT                 Wollongong
XNETMON III             SNMP Research

Has anyone done an in-depth comparison of the various software
products that run as X-applications and are generally supported
on a Sun?

Has any magazine done any sort of comparative analysis on this
new market segment?  Please save me from having to create yet
another stupid scorecard!

Thanks,
Hank

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 15:23:02 GMT
From:      mcsun!i2unix!inria!bull.bull.fr!cediag!Patrick.Hayes@uunet.uu.net  (Patrick Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
In article <BOB.90Sep19164020@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes:
>   dvv@hq.demos.su (Dmitry V. Volodin) writes:
>      Have anybody tried this weird combination?
>
>   Yup.  [...and then describes running TCP/IP over X.25, without
>   mentioning SLIP.]
	[ and doesn't quite answer the original question either]

>Many X.25 implementations (ours, for instance) support IP directly,
>which (for routing purposes) just sees the virtual circuits as wires.
>I'm not sure why Mr. Volodin wants to put SLIP in the pile, though.
This is also what B.O.S. does, more or less. Bull's OSes initially treated
IP/X25 (DDN/X25 more or less) as point to point links. B.O.S. now treats the
X25 interface as a net through which you must route packets to reach the other machines...

>   B.O.S. does not support UDP/IP over X.25.
>
>That's odd.
and untrue, as Frank Mayhar has already stated.

Now for WHY one would like to use SLIP over an X25 link.

I'll use my own situation as an example.

I've got a Mac at home, a modem, and the software neccesary to use SLIP. I'd
like to be able to connect to the machines at work from time to time, but all
the access points are on TRANSPAC (the french national X25 carrier). Right now
I use a terminal emulation program to log on, but I'd rather have an IP link.
The major problem seems to be that B.O.S.'s X3/X29 interface uses one
line-discipline, and SLIP uses another. Trying to use both blows my
connection.

Now I know that this is ugly, but wouldn't it be nice if it worked?

Pat
--

+-------------------------------+-----------------------------------------+
| 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             |
+-------------------------------+-----------------------------------------+
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 16:31:45 GMT
From:      robin@csuchico.edu (Robin Goldstone)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: MAC MS-MAIL to SMTP gateway?

In article <34162@cup.portal.com> Brian_C_McBee@cup.portal.com writes:
>We have MS mail running on our appletalk network, shich is connected to
>our ethernet with a Kinetics Fastpath.  What is our best bet for gatewaying
>MS-MAIL to SMTP?  Failing that, how about MS-MAIL to VAXMAIL?  SMTP would
>be best, but we'll take what we can get.  Thanks.

We are running Cayman's GatorMail-M, which is (to my knowledge) the only
MS Mail to SMTP gateway available.  The product is newly released and
has a few bugs which Cayman is working on.  We are using it mainly to
talk to our VAX, which is running Matt Madison's MX Mailer (SMTP <-> VAXmail)
on top of CMU/TEK TCP-IP.  

There are also several direct MS Mail <-> VAXmail solutions.  One is from
Pacer and the other from Alisa.  I have not evaluated these.  We decided
that the SMTP solution was more generic and thus more pratical then having
specific gateways to each of our other mail environments.

A site license of GatorMail-M is $2000.  If you want more details about
this product please contact me via private e-mail.

Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
robin@csuchico.edu

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 16:49:35 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!ssw@ucsd.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   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.  We are currently evaluating MIT's TechMail, but we would 
like to see what else is out there.   Please let me know (via e-mail) of 
any Mac based POP clients which may meet our requirements.   I'll 
summarize our findings to the net.

Thanks,
 
Steven Wallace
wallaces@ucs.indiana.edu
wallaces@iubacs.bitnet
Indiana University
Bloomington, IN 
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 17:42:32 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!oregon!dsmith@ucsd.edu  (Dale Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   IP and SNA applications gateways
I have been contacted by some folks in our state government who are
interested in connecting their large IBM SNA network to our IP network.
Of course, I know nothing about SNA and they know nothing about IP,
so I really don't know where to start (actually, I do know. I'm posting
here, calling IBM, and I've ftp'ed the vendor guide off of the NIC).

We would like an applications gateway that supports at least electronic
mail to SNA DISOS (sp?).  Terminal service would be a plus, but is not
critical.

Any good ideas on how we ought to approach this??

Thanks in advance...
-- 
Dale Smith, Assistant Director of Network Services
University of Oregon		Internet: dsmith@oregon.uoregon.edu
Computing Center		BITNET: dsmith@oregon.bitnet
Eugene, OR  97403-1212		Voice: (503)346-4394
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 18:20:08 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 <34162@cup.portal.com>, Brian_C_McBee@cup.portal.com writes:
> We have MS mail running on our appletalk network, shich is connected to
> our ethernet with a Kinetics Fastpath.  What is our best bet for gatewaying
> MS-MAIL to SMTP?  Failing that, how about MS-MAIL to VAXMAIL?  SMTP would
> be best, but we'll take what we can get.  Thanks.

Give the Cayman people a call.  They have a product that I believe is called
GatorMail - M, they also have one called GatorMail - Q for QuickMail.  These
go from MS-Mail/QuickMail to SMTP.  Have fun.

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

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Sep 90 16:05:53 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP comparison
SNMP product comparison time:

Product name            Company Name
------------            ------------
Dual Manager            Netlabs
Netmon III              SNMP Research
LAN Systems 9100 NMC    Hughes
OverVIEW                Proteon
NCC                     Unisys
NMS                     cisco
WIN/MGT                 Wollongong
XNETMON III             SNMP Research

Has anyone done an in-depth comparison of the various software
products that run as X-applications and are generally supported
on a Sun?

Has any magazine done any sort of comparative analysis on this
new market segment?  Please save me from having to create yet
another stupid scorecard!

Thanks,
Hank
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 20:21:27 GMT
From:      voder!pyramid!csg@ucbvax.Berkeley.EDU  (Carl S. Gutekunst)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
>The major problem seems to be that B.O.S.'s X3/X29 interface uses one line-
>discipline, and SLIP uses another. Trying to use both blows my connection.

Bingo. You're probably stuck. A *good* X.29 implementation will operate as a
real tty device driver, and hence be able to use any line discipline. This is
needed not only for SLIP, but also for xt and sxt drivers. Alas, many vendors,
including Bull apparently, implement X.29 *as* a line discipline; so trying to
switch to SLIP kills X.29. The other blunderous and common way to implement
X.29 is to not hook into the tty driver at all, or only minimally. Then a
request to change the line discipline is simply ignored. 

(Note that we're talking all Berkeley/V7 style tty devices here. Under Streams
all the rules change. Generally, it's easier to get it right with Streams.)

[Enter Flame Mode: My big gripe with virtually everyone who is implementing
CCITT and ISO protocols on UNIX is that they insist on forcing new and unusual
paradigms on the users, instead of implementing the protocols in such a way
that they fit well into UNIX paradigms. The present implementations of X.400
are especially extreme examples, seeming to have been designed in a vacuum.]

<csg>
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 20:33:27 GMT
From:      usc!cs.utexas.edu!swrinde!emory!hubcap!ncrcae!wingo@ucsd.edu  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   ICMP redirects

I have a question about routing and ICMP. Can ICMP redirects be used to update
routing tables or does it just convey info about a route not being appropriate?
Example would be to have an X terminal on a network 90. talking to a host A
also on net 90. Then I introduce yet another host B which has two(2) network
interface cards that bridge 90 to say net 89. I then put host A on net 89 and 
provide it with a new 89 internet number. Question then is can the X terminal
find the gateway to host A via ICMP only or will rip or gated need to be 
provided on the X terminal to update route tables????

Thanks in advance.... David Wingo  wingo@ncrcae.Columbia.NCR.COM
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 21:28:41 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: MAC MS-MAIL to SMTP gateway?

In article <1990Sep24.163145.2097@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes:

>   A site license of GatorMail-M is $2000.  

Well, a commercial site has different pricing......

A 10 user license is about $1000.
A 100 user license is about $5000.
A 200 user license is about $7000
A site license is $20,000 (not $2000).
Call Cayman (617) 494-1999 for more info. Don't take my word on it.

The license determines how many Mac users can SEND mail to the SMTP
gateway. Anyone can receive mail from SMTP address. You should know
that some characters that exist in a Mac mailname are translated in a
funky manner. For instance, the address "Barnett, Bruce" on a
Microsoft Mail server is converted into "Barnett#m#_Bruce@mac"
on the Unix side.

If you have this package, you can "tunnel" Mac mail with enclosures to
other companies with the same package and the enclosures are still
there. That is, someone using this package could send an enclosure
from their Mac to my Mac address: barnett@macgw1.crd.ge.com.

It could be used to connect to companies with MS mail that prefer not
to connect their appletalk networks together. For instance, if Apple
had this product, they could mail me Hypercard 2.0!  :-)

There is still a Unix limitation of maximum mail message size. Maybe
Hypercard 2.0 would be too big. They would have to compress it, and I
dare not mention any format 'cause the flames would start again. Sigh...



--
Bruce G. Barnett	barnett@crd.ge.com	uunet!crdgw1!barnett

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Sep 90 10:25:59 -0700
From:      gnu@toad.com
To:        com-priv@psi.com, tcp-ip@nic.ddn.mil
Cc:        gnu@toad.com
Subject:   "Industry forns NSFnet support group"
EE Times, Sept 24 1990, p. 28.  My comments are [indented].

		"Industry forms NSFnet support group"
			by Brian Robinson

Washington - The government's High Performance Computing Program, which
has yet to receive any formal funding, got a boost from industry last
week.  Three companies that have headed industry's effort in the
development of NSFnet are sponsoring a new organization that will
provide support for any network built as a part of the program.

The new, not-for-profit company, Advanced Network and Services, Inc (ANS)
will manage NSFnet under contract to current network manager Merit
Inc.  IBM Corp and MCI Communications Corp., which have worked with
Merit for several years to refit the NSFnet, will provide cash and R&D
for the venture.

ANS's first job will be to connect more academic, industrial and
government institutions to NSFnet, which is being boosted from a speed
of 1.5Mbits/second to a T3 performance of 45 Mbits/s.  Longer term,
the company would provide support for the National Research and
Education Network.  A major focus of the computing program, the NREN
is intended to link thousands of research and academic centers
nationwide.  NSFnet will be the backbone for the NREN.

The government first proposed its $1.9 billion plan for the High
Performance Computing Program late last year.  The program is an
ambitious attempt to build a coherent, nationwide infrastructure that
will provide industry, government and academic participants with
access to high-performance computing facilities.  A similar program
has been proposed in Congress, and legislative action on that
proposal is expected sometime next year.

	[When will "industry" actually get to participate in this
	 network?  It sure can't now...]

Even with the big boost in bandwidth -- from just 56 kbits/s two years
ago -- the current increase in demand threatens to overwhelm NSFnet,
said Allan Weis, president and chief executive of ANS and a former
executive of IBM.  In the last year alone, the number of sites
connected to the network has tripled, and user traffic has increased
by more than 500 percent.

	[If I gave away free bandwidth to anyone unscrupulous
	enough to break the rules, kept upgrading when people took
	advantage of me, and never policed them, my network
	traffic would be increasing exponentially, too.]

ANS focus

ANS will focus on managing that growth.  "The success of ANS will also
expand the base of financial support for the evolving financial
network" [sic], said Weis.

MCI and IBM will both donate $5 million over three years, and fees
will also be collected from users.  All of that funding will be
reinvested in network development, freeing up other funds to sign on
needier organizations that otherwise could not afford to get on NSFnet.

	[Total of $3.3M/year doesn't even come close to the cost
	of running the network...especially at T3.  That will just about
	pay for office space and salaries for MCI and IBM "ex-executives"
	who will run ANS.  The actual network funding come out of the
	taxpayers' pockets, as usual.  The "needier organizations" stuff
	is designed to distract your attention from this.]

While neither IBM nor MCI will derive revenue from ANS, both see it as
an opportunity to develop and test new communications technologies in
a real-world setting.  The two companies will be able to license any
new techologies ANS develops.

	[Heinlein's "The Man Who Sold the Moon" comes to mind.  Tycoon
	D. D. Harriman gets a United Nations charter for a nonprofit
	company to explore the Moon.  But that nonprofit is controlled 
	by him, and it subcontracts everything to his "real companies with
	hair on their chests", who make significant profits.  In this
	case, there are two fake nonprofits shielding the for-profits
	(Merit and ANS).  At least in Heinlein's case, the whole thing
	is funded by private owners, rather than by robbing the taxpayers.]

IBM sees its participation as an important means for testing new
techniques and configurations of networking hardware and software.  It
already supplies hardware and software for NSFnet's backbone switching
and routing systems.

MCI, meanwhile, supplies the 1.5-Mbit/s T1 network through which
NSFnet now operates, and officials expect ANS to be a test bed for
work on ISDN and braodband Synchronous Optical Networks (Sonet).  MCI
recently tested a 2.4 Gbit/s Sonet system, and the company expects
that technology to be the basis for a future, multi-gigabit NREN based
om optical fibers. 

	[Who will supply the T3 links?  MCI?  I find this a curious omission.]

Nonetheless, officials stressed that the company will be only a small part
of the full High Performance Computing Program.  It will not have the
resources to implement a full NREN, which will require a much broader
effort from industry, government and academia.

	[In other words, IBM and MCI aren't interested in FUNDING
	the development of a nationwide high speed commercial network.
	They just want to come in later and cherry-pick, managing the
	resulting for-profit network, after it's been built "non-profit"
	and paid for by tax money.]

Even so, the company may have a head start in any upcoming competition
for future management of NSFnet and, ultimately, of the NREN.

	[Tell me about it...]

		-- end of news story --
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 90 23:50:52 GMT
From:      usc!julius.cs.uiuc.edu!zweig@ucsd.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ICMP redirects
wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) writes:
>
>I have a question about routing and ICMP. Can ICMP redirects be used to update
>routing tables or does it just convey info about a route not being appropriate?
>Example would be to have an X terminal on a network 90. talking to a host A
>also on net 90. Then I introduce yet another host B which has two(2) network
>interface cards that bridge 90 to say net 89. I then put host A on net 89 and 
>provide it with a new 89 internet number. Question then is can the X terminal
>find the gateway to host A via ICMP only or will rip or gated need to be 
>provided on the X terminal to update route tables????
>
>Thanks in advance.... David Wingo  wingo@ncrcae.Columbia.NCR.COM

Finding the gateway (the X terminal sounds like it talks IP) from a given host
(the X terminal is a host in the sense of being an endpoint-machine for IP
traffic) is a problem whose solution is still in the works.  Some fine day
everyone will run Router Discovery Protocol so a host can use ARP to see if
another is on its local net, then punt everything else to the gateway it
selected from RDP.  Right now, there are a number of icky ways the X terminal
might go about finding out that B (in your scenario) is a router.

ICMP redirects are from routers and say "Hey! You're sending IP packets for
host A to me when they should really go directly to A!" if the X terminal uses
ARP to find A in the first place, it will find that A is not around anymore
and have to find the gateway -- the ICMP redirect might occur in the case
where A gets put onto the X terminal's net when it didn't used to be and
somehow the silly thing just had the route stuck in its head.

The netlanders will correct me I'm sure, but I think ICMP redirects are pretty
uncommon on nets that use ARP+whatever ad hoc method to locate gateways (since
nets with more than one gateway are pretty uncommon).

-Johnny ICMP
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 01:09:11 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!cs.albany.edu!percival.albany.edu!narten@ucsd.edu  (Thomas Narten)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ICMP redirects
>>I have a question about routing and ICMP. Can ICMP redirects be used to update
>>routing tables or does it just convey info about a route not being appropriate?

Yes and yes.  A router sends ICMP redirects to a host saying, "the
datagram you just sent me destined to Y should be sent to Z [possibly,
but not necessarily a router], which you can reach directly".
Naturally, a host that received such a message should change its
routing table to reflect the more direct path. Note that redirects
generally only work for hosts and not routers, because a router
determines when to send a redirect by checking 1) the source address
in the forwarded datagram, and 2) noting the address Z of machine the
datagram is being forwarded to.  If the two addresses are on the same
net, a redirect is in order.

Note: To get a redirect, you must be sending the misdirected datagram
to a router in the first place, so there is still a need for finding a
viable router.  The IETF Router discovery group is working on that
problem.

>ICMP redirects are from routers and say "Hey! You're sending IP packets for
>host A to me when they should really go directly to A!"

Replace "go directly to A" with "go directly to B" and I'll agree.

Thomas Narten
--
Thomas Narten
narten@cs.albany.edu
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Sep 90 14:47:30 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        gnu@toad.com
Cc:        com-priv@psi.com, tcp-ip@nic.ddn.mil
Subject:   Re: "Industry forns NSFnet support group"
Well,

I'm  hoping to learn what you really think about this
privately, I really hate the way you held back  :-)

The EE Times article is extremely wide of the mark, its interpretation
that this is "a boost", might be countered by many dozens of organizations
who think ANS has targetted the mid-level infrastructure and put
it in jeopardy at a very interesting point in time for the NREN.
This is pure coincidence of course.

> 	[When will "industry" actually get to participate in this
> 	 network?  It sure can't now...]

I think by your participation in ALTERNET and other commercial
companies particpation in PSINet, industry is participating in
the Internet, and in my opinion using the right providers:
commercial providers.

What PSINet has been doing (and from all appearances what ALTERNET
has been doing) is working with industry and not upsetting the
stability of the non-profit mid-levels from providing service to
the non-profits and academics.  That non-profit infrastrucuture
seemed pointless to hurt since too much of the US is incredibly
dependant on it.  At least I thought it was pointless.

Now when the non-profits provide service to industry is where we get
into a sticky philosophical/legal/taxation areas.  This has led
to a number of misunderstandings and conflicts that I'm sure now
pale into insignificance now that someone has said that they are
after their bread&butter.

People are smart enough to stay away from those big German shepards
but when they think they've set up a nice pastoral enviornment for
their kids with sheep in the backyard, and the sheep
are really something else, then you have real problems.

I think that the neatest thing I got out of the transcripts from
ANS's press conference were questions on the NSFNet joint work
being renewed past its first five years, which is 92?  Taking a moderate
interpretation of this, is that the free national network is soon to
be gone.  This confirms other rumblings that I had heard from other
sources.

So in some sense it maybe worse than you think.

Marty
--------------------
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 13:00:56 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!rex!uflorida!webb.psych.ufl.edu!george@ucsd.edu  (Stephanie George)
To:        tcp-ip@nic.ddn.mil
Subject:   Trouble w/ NCSA TN3270 2.2

	I've been running the NCSA telnet package with and without the 
packet drivers sucessfully for more than a year now.  Occasionally, I've been
getting the message "Local HOST or gateway not responding" on new
installations.  The station that doesn't work is also not recognized as 
"pingable" from any other host - nobody recognizes it.  Curiously, 
the station on either side may work flawlessly, so apparently there's no 
obvious physical layer problem. I have endlessly tried changing the "address" 
in the config.tel file to every possible combination between c000h and dc00h 
to no avail.  This has happened on old-bus PCs running WD8003s and 3Com 501s 
as well as microchannel PS/2s running with WD8003s and 3Com 523s.  

	One suggestion that I received from someone on this campus was that
I might have too many stations on one length of Thinnet or I may have exceeded
the maximum length for the wire.  In order to test that, I terminated the 
cable at the errant station and tried again without success. (see following
diagram)


     +----------+        +----------+        +----------+
     |          |        |          |        |          |
[7m-----[m|     A    |[7m--------[m|     B    |[7m--------[m|    C     |[7m---||[m
     +----------+        +----------+        +----------+

Fig. 1: Stations A and C work just fine; Station B is new and gets the 
        "Local host ... not responding" message.  Cable is terminated just
        after station C, signal source is just before station A.


     +----------+        +----------+        +----------+
     |          |        |          |        |          |
[7m-----[m|     A    |[7m--------[m|     B    |[7m----||  [m|    C     |[7m-----[m
     +----------+        +----------+        +----------+

Fig. 2: Cable terminated between B and C.  Station A works great; station B
        still has error.  (Assume signal source is before station A and that
        A is first station on this run of cable.)



	Yes, I understand that the cable needs to be terminated at each end - 
it is, otherwise Station A wouldn't work at all, either.


Has anyone ever seen this?  What do I do now?

Stephanie George
--
Stephanie George                         114 Psychology Dept.
george@webb.psych.ufl.edu                University of Florida
(904) 392-3979                           Gainesville, FL  32611
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Sep 90 17:28 EDT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: SNMP comparison

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
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 15:04:57 GMT
From:      dc@uunet.uu.net  (Darren Croke)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ICMP redirects
In article <NARTEN.90Sep24210911@percival.albany.edu>, narten@cs.albany.edu (Thomas Narten) writes:
> 
> Note: To get a redirect, you must be sending the misdirected datagram
> to a router in the first place, so there is still a need for finding a
> viable router.  The IETF Router discovery group is working on that
> problem.
> 
It's currently common for X terminals to have a setup field to allow
a default gateway to be specified.

Darren Croke
dc@graphon.com
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Sep 90 23:03:27 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP info wanted
Robin at Cal State Chico asks:
       .....deleted......
> I do remember reading numerous complaints about the 8232 and praises about
> a product called the ELC from BTI.   We are trying to get rid of the 8232
> and replace it with something else.  Should we get a BTI ELC?  I also
> have literature on the Fibronic's K200 and K2000.  Can anyone compare these
> products to the BTI product in terms of price/performance?
       .... deleted....
> 
I happened to do a market survey earlier this year among commercial users
of IBM TCP/IP solutions.  They included users of IBMs software as well
as third party.  The IBM 8232 came in for a lot of abuse, mainly because
of performance, not because of any serious shortcoming.  Users of the BTI
product were quite happy with it.  Users of other systems, including the IBM
8232, told me on two occasions that they wished they had bought it.

Recently IBM announced a new product to replace the 8232, called the 3172.  It 
seems to be more directly engineered for the purpose of frontending a LAN, 
and appears to offer higher performance at lower cost.

I have used none of these products myself, and have no affiliations
with any of the vendors.
 
-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 18:47:22 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Re: Sys V Unix TCP/IP abilities

In a recent article bill@redford.UUCP (Bill Poitras) writes:

>I have noticed that Xenix/286 has trouble receiving rlogin/rexec calls from 
>a BSD client.  Is this indicitive of all SYSV implementations of TCP/IP 
>software.  What I am trying to do is authorize PC Users on a network,
>and the way I am doing it is by making an rexec call (which uses the BSD 4.2 
>spec) to a Xenix 286 machine.  If the rexec call succeeds, the authorization
>program lets them in.  Can anyone give me help here?  Is this doable with 
>what I have?  Are all SYSV TCP/IP alike?  Any help would greatly be appreciated.

No, not all System V TCP/IP implementations are alike. I'm typing this
on a Visual X terminal, logged in to an Encore Multimax running UMAX V,
a System V Release 3.2 UNIX. I have no problems booting our diskless
Sun's and DG AViiON's from it, nor doing an rlogin/rexec from another host.
In fact, its TCP/IP is even better than many BSD UNIXes we have here.

-- 
Robert Claeson                  |Reasonable mailers: rclaeson@erbe.se
ERBE DATA AB                    |      Dumb mailers: rclaeson%erbe.se@sunet.se
                                |  Perverse mailers: rclaeson%erbe.se@encore.com
These opinions reflect my personal views and not those of my employer.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 19:12:33 GMT
From:      csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM MVS TCP/IP info wanted
We are investigating TCP/IP solutions for our IBM MVS 3090 environment
as well as for our VM 4381 environment.  On the VM side, we have already
procured IBM's TCP/IP offering and an 8232.  I have been following the
discussion here about IBM's TCP/IP for VM.  Right now things are getting
kind of heated in this discussion and I am having trouble distinguishing
fact from fiction.  So I think I'll skip my questions about VM TCP/IP...

I do remember reading numerous complaints about the 8232 and praises about
a product called the ELC from BTI.   We are trying to get rid of the 8232
and replace it with something else.  Should we get a BTI ELC?  I also
have literature on the Fibronic's K200 and K2000.  Can anyone compare these
products to the BTI product in terms of price/performance?

On the MVS side, Fibronics has sent literature on their KNET product.  
How does this compare to IBM's TCP/IP offering for MVS?  Are there any
other players in this market?

Maybe this discussion belongs in an IBM newsgroup... If so, which one?
Thanks for any info you can provide.

Robin Goldstone, Systems Software Specialist
California State University, Chico  Computing Services
robin@csuchico.edu
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 19:58:17 GMT
From:      ingr!b11!wanda!sale@uunet.uu.net  (Ed Sale)
To:        tcp-ip@nic.ddn.mil
Subject:   ARP requests

When our workstations boot, in an effort to ensure that the workstation
is not configured with the same internet address as another station on
the net, we send an ARP request asking for a translation for the internet
address that we are about to use.

RFC826 states that:

298:	"The sender hardware address and sender protocol address are
299:	absolutely necessary."

and also:

227:	"Notice that the <protocol type, sender protocol address, sender
228:	hardware address> triplet is merged into the table before the
229:	opcode is looked at."

Since our intention is to avoid sending out conflicting address
translation information on the net, what we have been doing is to set
the sender protocol address to all-zero, intending that to mean, "this
host on this net" (line 1736, RFC1122).  In this way, an ARP request
which is broadcast to the net does not update everyone's table with a
translation which may be erroneous, and our stations find out about
any address conflict before using the address.

Does this violate the ARP protocol, or is this a valid technique?

Thanks in advance.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Ed Sale      Intergraph Corp.     Huntsville, AL 35894-0001    (205)730-2000
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 21:02:59 GMT
From:      crtchlym@vax1.tcd.ie
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Request for info. on TFTP for Vax VMS

We have a Linotronic Imagesetter printer which we wish to connect to a MicroVax via
ethernet.  The printer supports TCP/IP and we therefore intend to send postscipt files to
the printer using FTP or similar.

However, the printer doesnot support the standard FTP, but only TFTP (trivial FTP).
The CMU-TEK tcp/ip package on our vax only has FTP (not TFTP).

Can anybody point me to a source of TFTP for the vax (under VMS 5.3)?

Thanks in advance.


Martin Critchley,
ERA, Dublin, Ireland

crtchlym@vax1.tcd.ie

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 07:40:40 -0500
From:      ug051@techops.cray.com (Michael Nittman - MERCEDES)
To:        tcp-ip@sri-nic.arpa
Subject:   index
index
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 07:41:25 -0500
From:      ug051@techops.cray.com (Michael Nittman - MERCEDES)
To:        tcp-ip@sri-nic.arpa
Subject:   rfc1122
rfc 1122
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 90 23:27:23 GMT
From:      shlump.nac.dec.com!aussie.enet.dec.com!tong@decuac.dec.com  (Benny Tong)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: choosing ethernet packet type automatically
RFC1122 says:

    Furthermore, it is not useful or even possible for a
    dual-format host to discover automatically which format to
    send, because of the problem of link-layer broadcasts.

I suggest:
    When an IP datagram needs to be sent to an unknown Internet host, ARP
    request packets of both ethernet and 802.3 types are broadcasted to the
    ethernet. The IP datagram is queued for later transmission. When an ARP
    reply comes back, the same packet type and ethernet address as the ARP
    reply is used for sending the IP datagram. If replies with two packet
    types come back, a default packet type can be used.

In article <9009241126.AA00500@asylum.sf.ca.us>, romkey@ASYLUM.SF.CA.US (John
Romkey) writes:
|>The ARP scheme you suggested is what I and other people suggested.
|>When we talked about it in the Host Requirements group, problem after
|>problem surfaced until someone finally said, "Look, why don't we do it
|>the right way? They're different encapsulations; put a router between
|>them." And we were enlightened.
|>

What are the problems with link-layer broadcasts? Can you list some of them
please?
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 14:03:49 -0700
From:      chris@salt.acc.com (Chris VandenBerg)
To:        tcp-ip@NIC.DDN.MIL, ug051@techops.cray.com
Subject:   Re:  index
Michael,
	Please do not send queries to the TCP list. It is NOT an auto-retrieval
system but a distributed maillist with several thousand subscribers, all of whomnow know that you are looking for information and are new to the TCP list. I
guess you believe in grand entrances....
		Regards,
			Chris VandenBerg @acc
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 04:20:27 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson!image.soe.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Please boycott Xircom
Xircom has been distributing a packet driver while violating the copyright
on it.  I wrote the skeleton of the Clarkson packet drivers, which is
copyrighted under the GNU General Public License.  This copyright requires
that code which is linked with mine be available in source form.  I allowed
them to require a signed nondisclosure form, provided that source code be
given to anyone willing to sign.

They have violated that copyright and agreement by refusing to
distribute the source code, have agreed that they are violating it,
and have ceased distribution of the packet driver.  This means that
Xircom Ethernet adapters no longer come with a packet driver.  If your
application requires a packet driver, you will be unable to use a
Xircom adapter.

I am asking anyone who was considering the purchase of a Xircom adapter
to purchase a D-Link adapter instead, and tell Xircom why you did not
buy their product.

No, I don't have D-Link's address.  Perhaps some kind soul who reads
this will supply it to me.  There is also another company (whose name I
do not recall) that makes pocket Ethernet adapters.

--
--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
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 11:14:36 EDT
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        ug051@techops.cray.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   rfc 1122
Hi - I just noticed your messages are being reflected to the TCP-IP mailing
list at the NIC.

If you want to receive RFC's from the NIC by mail,
try sending a message to:
SERVICE@SRI-NIC.ARPA

With a subject line (like you had) of RFC xxx.

Hope this helps!

Bob Stratton		| dsc3rjs@nmdsc{20 | 10}.nmdsc.nnmc.navy.mil [Internet]
Stratton Systems Design	| dsc3rjs@vmnmdsc.BITNET [BITNET only, please!]
			| +1 703 823 MIND [PSTNet]
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 07:52:47 GMT
From:      eru!hagbard!sunic!liuida!isy!tommyp@bloom-beacon.mit.edu  (Tommy Pedersen)
To:        tcp-ip@nic.ddn.mil
Subject:   Racal Interlan NP622A with SLIP. Is this possible?
I'm would like to hear from anyone about combining the SLIP
which follows with Interactive unix ver. 2.2 and the software
Racal/Micom Interlan NP622A with ethernet card NP600. I need
NP622A since the Oracle database I'm using requires this. I
would however also like to use SLIP for distant clients.

Have anyone got this to work? Or do I have to do something else
like having another PC act as a gateway between ethernet and SLIP?

Once again:    I would like to hear from anyone,
               who has some idea about this combination.

Thanks,   Tommy Pedersen

Email: tommyp@isy.liu.se
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 14:52:55 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        cirpka@idca.tds.philips.nl (Jan R. Cirpka)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP info wanted
> 
> Hi Mike,
> 
> > I happened to do a market survey earlier this year among commercial users
> > of IBM TCP/IP solutions.  They included users of IBMs software as well
> > as third party. 
> 
> is this report general available ? If yes, could you please sent me
> an electronic copy ? Thanks very much !
> 
> Jan
Hi Jan,
	The survey was part of a corporate market research effort,
that we undertook in the area of structured wiring systems.  It happened
that some of the sites which we visited were true "blue" sites, and 
during the conversation with them I asked about the LAN front end
systems that they had.  The survey was not specifically about that
topic, but about their LAN plans.  I became interested in the 
topic also because all the IBM sites indicated a strong interest
in both ethernet and TCP/IP.  Needless to say, I was quite surprised
at these two answers, having expected to hear them say Token Ring
and SNA.

	In any case, our study was for internal consumption, and does
not shed any further light on the question raised in the mailing list
about 8232 alternatives.
-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 08:32:34 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 9 interesting & challenging problems for Netman
In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK
(Zheng Wang) writes:
+---------------
| I imagine what we need is a huge screen (as seen at some city
| traffic control centers) with all the nodes and links. Each
| connection is represented by a thin line. When traffic passes,
| it leaves a trace on the line. So the more traffic passes, the darker
| the line is....
+---------------

This is exactly what SGI's new "NetVisualyzer" product does, that is, the
"netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.]

+---------------
|          ... Different traffic can be represented by different
| colors (eg. Yellow Page traffic is yellow :-)
+---------------

Hmmm... Good idea. Except that we already use colors for "the more traffic
passes, the [brighter] the line is". You can do most of the selective
viewing by enabling/disabling filters for different traffic type, but I
suppose there might be times when you'd want to see the ebb and flow of
two different kinds of traffic...  [Have to talk to the implementers...]

+---------------
| We also need some buttons so we can choose to average the traffic
| at different intervals.
+---------------

Got that already ("rescaling interval" and "timeout interval" knobs).

+---------------
| Yes, we need a camera to get a snap shoot from time to time.
+---------------

Or just save the captured/displayed data in a log file? For later replay?
[Got that.]

+---------------
| With the visulization of the complete traffic, a human brain
| can easily answer some of the 9 questions.
+---------------

Yeah, and sometimes it's startling! The first time you see a "timed"
update on your LAN, you say, "Wha' th' hell was thayet thayer?!?"
[At least, I did...  ;-}  ]

+---------------
| For a LAN, to collecting the data at a reasonable interval may
| not be a problem.  But for an Internet, we may have to put all the
| snap shoots together to see the whole picture.
+---------------

"NetVisualizer" lets you select a remote station to do the snooping, while
displaying on the local system. [To be fair, I believe there are other
products out there that support remote monitoring, too, though without
the fancy graphics...]

Still, that doesn't solve the problem completely for a large internet, since
gathering the real-time data can itself become a significant traffic load.


-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
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Sep 90 21:06:03 -0700
From:      Marshall Rose <mrose@cheetah.ca.psi.com>
To:        newbery@comp.vuw.ac.nz (Michael Newbery)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: 9 interesting & challenging problems for Netman
Hmmm... A network management product that does not use SNMP.  Well,
that's certainly an *interesting* direction to take...  (I'm far too
polite to spell-out what I mean by *interesting*).

In any event, discussion on this thread:

	1. Has gotten away from the main topic of Jon's original message.

	2. Is getting dangerously close to product advertisement.

Perhaps we might get back to the original topic?

/mtr
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 12:02:51 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter M. Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP info wanted
In article <1990Sep25.191233.6543@ecst.csuchico.edu>, robin@csuchico.edu (Robin
Goldstone) says:

(stuff deleted)
>Maybe this discussion belongs in an IBM newsgroup... If so, which one?
>Thanks for any info you can provide.

I would like to suggest that you search the IBMTCP-L notebook archives
stored on the listserv@pucc.princeton.edu.
/Pete
--
Peter M. Weiss                   | pmw1@psuvm or @vm.psu.edu
31 Shields Bldg (the AIS people) | not affiliated with PSUVM | VM.PSU.EDU
University Park, PA USA 16802    | Disclaimer -* +* applies herein
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 13:53:04 GMT
From:      ncrlnk!ncrstp!npdiss1!scottr@uunet.uu.net  (Scott Reedstrom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP info wanted
In article <1990Sep25.191233.6543@ecst.csuchico.edu> robin@csuchico.edu (Robin Goldstone) writes:
>How does this compare to IBM's TCP/IP offering for MVS?  Are there any
>other players in this market?
Yes, NCR Comten came out with a TCP/IP offering. It uses the front end to run
the TCP/IP protocol stack.  3270 terminals attached to the front end can run
Telnet out the network connection, and Telnet connections can switch between 
hosts in the front end.  The downside is you need to have a Comten front end. 

-- 
Scott Reedstrom                      |   UUCP: ncrlnk!ncrstp!npdiss1!scottr 
NCR Network Products Division        | Domain: scottr@stpaul.ncr.com
St. Paul, MN  55434                    
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 17:04:26 GMT
From:      ucselx!mccurdy@ucsd.edu  (mccurdy m)
To:        tcp-ip@nic.ddn.mil
Subject:   Hughes server "task stack overflow" prob. identified and fixed

	With the help of people on campus, and Hughes personnel, the
problem that was causing our LAT TCP/IP servers to crash from a 
"task stack overflow" error has been identified and fixed.

	The problem was caused by a bug in the domain name server
resolution function in server resident software.

	Anyone also experiencing this problem should contact Hughes
for a software patch. Thanks ...


-mike mccurdy
San Diego State University

-- 
Mike McCurdy               *  mccurdy@ucselx.sdsu.edu *
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 17:55:35 GMT
From:      cs.utexas.edu!uwm.edu!mixcom!baaa01@CS.YALE.EDU  (Merge Technologies Inc.)
To:        tcp-ip@nic.ddn.mil
Subject:   Which TCP/IP pkg for SCO Xenix & UNIX ?

I am looking for a TCP/IP package for the systems listed below.

	SCO Xenix/386
	SCO UNIX 3.2 

Which vendor and product do you recommend as 
being the most reliable and compatible? 

Please email your response directly to me.  Thank you.

Dean
-- 
Merge Technologies Inc.                   P.O. BOX 27366  Milwaukee, WI  53227
==========(414) 256-5360========================merge@mixcom.UUCP=============
            Diagnostic Medical Image Communications Products
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 22:03:43 GMT
From:      comp.vuw.ac.nz!newbery@uunet.uu.net  (Michael Newbery)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 9 interesting & challenging problems for Netman
In article <70311@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes:
>In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK
>(Zheng Wang) writes:
>+---------------
>| I imagine what we need is a huge screen (as seen at some city
>| traffic control centers) with all the nodes and links. Each
>| connection is represented by a thin line. When traffic passes,
>| it leaves a trace on the line. So the more traffic passes, the darker
>| the line is....
>+---------------
>
>This is exactly what SGI's new "NetVisualyzer" product does, that is, the
>"netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.]

Yes, it's very nice (at least the video I saw was impressive---pity my TV
screen isn't as high res as the Iris :-) but it requires an Iris
workstation on every segment to collect data! Great for SG if they want to
sell lots of Iris's but a little out of our range I'm afraid. Also, in the
case of Point to Point ethernet over fibre links (router-router) it's not
even theoretically possible.
Now, if the product collected data from SNMP agents it would be rather
more generally useful. 
--
Michael Newbery<newbery@rata.vuw.ac.nz>
Levitation: Joseph of Cupertino (1603-1663) was the subject of such frequent
levitation that he was forbidden by his superiors to attend choir.
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 90 22:12:15 GMT
From:      thorin!weiss!smithfd@mcnc.org  (Don Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Reminder - CFP TriComm'91


                          CALL FOR PAPERS

                            TriComm '91
            IEEE Conference on Communications Software:
      Communications for Distributed Applications and Systems

                         April 17-19, 1991
                       Chapel Hill, NC  USA

An international conference sponsored by the IEEE Communications Society, 
the University of North Carolina at Chapel Hill, and MCNC

OVERVIEW
The decade of the 1980's was a period of rapid advances in communications 
technology (both hardware and software) and of pioneering deployment of 
distributed systems and applications.  At the beginning of the 1990's,
new communications technologies and new distributed applications are 
emerging that will have far-reaching impact on communications software. 
Very high-speed networks (e.g., from FDDI to Gigabit technologies), 
multi- and continuous-media communications, interconnection of workstations 
and supercomputers, visualization and image applications, and 
computer-supported cooperative work (CSCW) are just a few examples.  
Participation in the conference by both developers of advanced distributed
applications or systems and researchers interested in communications software 
will provide a mutually beneficial dialogue.  Two major themes will be 
emphasized: (1) examination of requirements and experiences from distributed 
applications and systems, and (2) innovations in underlying communications
software.

Areas of interest include (but are not limited to) the following:
DISTRIBUTED APPLICATIONS AND SYSTEMS          COMMUNICATIONS SOFTWARE   

Production, financial or service industry     Programming environments         
   (e.g., airlines, banking, insurance,          (languages, toolkits)         
    manufacturing, education, medicine)       High-performance protocols       
Computer-supported collaborations	      Continuous-media protocols 
Multimedia mail, conferencing	              Highly available/secure systems  
Visualization; image processing	              Applied theoretical results      
Supercomputer-workstation integration         Operating system kernel support  
Very large-scale file systems	              Performance analysis
                                              Monitoring and debugging             

CALL FOR PAPERS
Original papers are invited and proceedings will be available at the 
conference.  The deadline for submitting papers is October 22, 1990.  
Papers should be no more than 20 double spaced pages in length and should 
have a separate cover page with title, authors, a 250-word abstract, and 
postal address, email address, and telephone number of contact author.  
Send 5 copies to:
    Don Smith, TriComm '91			    
    CB #3175, Sitterson Hall		
    Department of Computer Science	
    University of North Carolina
    Chapel Hill, NC  27599-3175
    919-962-1884; smithfd@cs.unc.edu; Fax-919-962-1799

SCHEDULE
    Submit paper--before October 22, 1990
    Notification of acceptance--December 7, 1990
    Final version due--by January 28, 1991
    Conference dates--April 17-19, 1991
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    PROGRAM COMMITTEE
Don Smith, Chairman                     Yutaka Matsushita                    
    IBM & UNC-Chapel Hill, USA              Keio University, Japan       
Steven Bellovin				Najah Naffah                         
    AT & T Bell Laboratories, USA           Bull, France                 
Rich Chilausky				Erich Neuhold                        
    BNR, USA                                GMD-IPSI, FRG                
Brian Coan				Bernhard Plattner                    
    Bellcore, USA                           ETH, Switzerland             
Flaviu Cristian				Tom Rodeheffer                       
    IBM Research-Almaden, USA               DEC Sys. Res. Center, USA    
Carla Ellis				Beverly Sanders                      
    Duke University, USA                    ETH, Switzerland             
Rong-Chin Fang				M. Satyanarayanan                    
    Northern Telecom, USA                   CMU, USA                     
Domenico Ferrari			H.T. Smith                           
    U. of California-Berkeley, USA          Nottingham University, UK    
James P. Gray				Jorgen Staunstrup                    
    IBM Comm. Systems, USA                  Technical U. of Denmark      
Fukuya Ishino				Liba Svobodova                       
    NTT, Japan                              IBM Res.-Zurich, Switzerland 
Kevin Jeffay				Mladen Vouk                          
    UNC-Chapel Hill, USA                    NC State University, USA     
Rivka Ladin 				Hussein Abdel-Wahab                  
    DEC CRL, USA                            Old Dominion U., USA         
Simon Lam				William E. Weihl                     
    U. of Texas-Austin, USA                 MIT, USA                     
Geovane Magalhaes			Jennifer Welch                       
    CPqD/TELEBRAS, Brazil                   UNC-Chapel Hill, USA 
-----------------------------------------------------------------------        

CONFERENCE COMMITTEE
    Alan Blatecky (MCNC, USA) General Chairman 
    David May (BNR, USA)
    Jurg Nievergelt (ETH, Switzerland) International Chairman		
    Joe Rusnak (IBM, USA)
    Peter Calingaert (UNC-Chapel Hill, USA) 	
    Dan Stephenson (MCNC, USA)
    Andre Fournier (BNR, USA)
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 00:32:41 GMT
From:      usc!elroy.jpl.nasa.gov!hacgate!ladcgw.ladc.bull.com!melb.bull.oz.au!news@ucsd.edu  (Simon J. Gerraty)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP over X.25
In article <128135@pyramid.pyramid.com>, csg@pyramid (Carl S. Gutekunst) writes:
>>The major problem seems to be that B.O.S.'s X3/X29 interface uses one line-
>>discipline, and SLIP uses another. Trying to use both blows my connection.

I have obviously caught the tail end of this chain...
Could some one please explain why anyone is trying to run SLIP
on top of the X3/X29 service ? 

In article <1990Sep19.112128.2154@swbull.bull.se> love@swbull.bull.se (Love Feuer) writes:
>B.O.S. does not support UDP/IP over X.25. The reason for this is
>probably that nobody should get the very, very sick idea of running
>NFS over X.25.

To my knowledge the DPX/2 supports IP over X.25 without fiddling
about with SLIP.  I have not seen any references that indicated
that UDP/IP should not work.  [But of course I haven't tried it
myself :-)]

>[Enter Flame Mode: My big gripe with virtually everyone who is implementing
>CCITT and ISO protocols on UNIX is that they insist on forcing new and unusual
>paradigms on the users, instead of implementing the protocols in such a way
>that they fit well into UNIX paradigms. The present implementations of X.400
>are especially extreme examples, seeming to have been designed in a vacuum.]

Perhaps its because X.400 was designed in a vacuum ? :-)
--
Simon J. Gerraty			<sjg@sun0.melb.bull.oz.au>

#include <disclaimer>             /* imagine something *very* witty here */
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Thu 27 Sep 90 18:37:27-PST
From:      Alan Larson <LARSON@CRVAX.SRI.COM>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Wireless_Connectivity_Problem_&_A_Plea_For_Support
  For the problem of connecting to a building within visible
range, some of the optical point to point links will probably
be the best choice, especially after considering potential
interference problems with RF based systems.


>      One of products I found was a wireless LAN made by a group 
> in Canada;
> 
> Telesystems SLW Inc.
> 85 Scardale Road, Suite 201
> Don Mills, Ontario CANADA  M3B 2R2


  I spoke with them for a while earlier this year, and would recommend
most strongly against them.  I had wanted to establish a point to point
link that would be exceeding the range claims of their system, and was
trying to get some technical details on how the system worked.  Their
answer was "why would you want to know that?"

  They continued to be unhelpful even after I explained my goals, and
it became clear that they were unwilling to give any hard technical
information about their product.

  The directional antennas they had were 3 foot long Yagis, with
a 6 foot coaxial cable.  The price was $600.  The same class of
antenna can be had in the amateur radio marketplace for under $90.
They had no figures on dealing with feedline losses for the antenna
to be mounted away from the radio.

  All in all, I also felt that they were quite rude when dealing
with them on the phone.



> 	               Price:    about $2000, but not yet fixed

  They were $2500 when I talked to them, and they were quite fixed.
The control/router was more, like $4000 I think.  It also wasn't
quite ready back then, either.

	Alan
-------

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Sep 90 09:04:49 TUR
From:      Attila OZGIT <OZGIT%TRMETU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: IBM MVS TCP/IP info wanted
Dear Robin,

I am  currently investigating the same topics. I posted an inquiry to
BIG-LAN discussion list but not received any response as yet.

Could you pls send me a copy from each reply that you receive ?

Regards.

Attila OZGIT
Middle East Technical University
Computer Center

Ankara, TURKEY
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 15:03:49 GMT
From:      OZGIT@TRMETU.BITNET (Attila OZGIT)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP info wanted

Dear Robin,

I am  currently investigating the same topics. I posted an inquiry to
BIG-LAN discussion list but not received any response as yet.

Could you pls send me a copy from each reply that you receive ?

Regards.

Attila OZGIT
Middle East Technical University
Computer Center

Ankara, TURKEY

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 18:06:32 GMT
From:      rti!dg-rtp!dg-rtp.dg.com!harvey@mcnc.org  (Michael Harvey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is a UNIX Domain Socket?
In article <82@unigold.UUCP>, lance@unigold.UUCP (Lance Ellinghouse) writes:
|> Ok, I know this is a dumb question..
|> 
|> What exactly is a Unix Domain Socket?
|> What makes it different from a INET Socket?
|>
A socket is simply a communication endpoint. 
Sockets support two communications domains: the UNIX domain
for process-to-process communication on the same host,
and the Internet domain for process-to-process communication
between hosts that communicate with one another using the
DARPA standard communication protocols, such as IP, TCP, and UDP.

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

I think that covers the basics.  Comments?
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 20:44:21 GMT
From:      dynasys!fedeva!bill@rutgers.edu  (Bill Daniels)
To:        tcp-ip@nic.ddn.mil
Subject:   syslog to remote machine?
I have a few Ultrix machines that are on the same network.  I would like
to be able to send messages via syslog(3) to one of the machines from
all of the other machines.  Syslog(3) as documented in Ultrix doesn't
allow specification of a remote host.  All messages are logged on the
local machine as originating from "localhost".  How might I specify a
remote node to log messages to?  I do not have Ultrix source but if syslog
is public I would be willing to change the sending half of it!
-- 
bill daniels
federal express, memphis, tn
{zardoz!dhw68k,mit-eddie!premise}!fedeva!bill
bill@fedeva.UUCP
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 21:12:47 GMT
From:      amethyst!organpipe!scor_az.resp-sci.arizona.edu@noao.edu  (Royce Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Wireless_Connectivity_Problem_&_A_Plea_For_Support
Net folks,
     I have a connectivity problem.  Last year our 
Telecommunications department rewired the main campus, and a few 
of the buildings that were "close" in a politico-economic sense.  
They have provided fiber links to most buildings and copper to a 
few others.  They did not connect, nor do they intend to connect 
certain "temporary" (been there since 1920) buildings, including 
one to which I  need to be connected.
     It is not econmically feasible (T1? Sure, $750/month + 
$15000 for equipment.  Yeah, right) to lay either copper or fiber 
to this site.  I can stand on my roof and see the other building 
less than 1/2 mile away, I can literally hear them when they yell 
'Connect me! Connect me!'. They are currently connected via a 
9600baud leased line ($35+/month) that has no possibility for 
upgrade.
     My problem is: How do I connect this site at reasonable 
speed (AppleTalk speed minimum) without laying a physical 
connection?  Any ideas?  I know I am not alone in having to do 
this.  A good, inexpensive, reliable method would be met with 
great enthusiasm by a lot of peole, I'm sure.  Options I've heard 
of or looked at: 2-way lasers, microwave relays, (mucho bucks) 
packet radio (mucho slow). Anything else?

(The following is a plea for support AND 
an unpaid promotional announcement)

     One of products I found was a wireless LAN made by a group 
in Canada;

Telesystems SLW Inc.
85 Scardale Road, Suite 201
Don Mills, Ontario CANADA  M3B 2R2
(416) 441-9966
(416) 441-9785 (fax)

     They have several product lines, ranging from a wireless 
RS232 300-19200baud link to the ARLAN 600 line which is their 
"Megabit Wireless LAN".  They all use a spread-spectrum radio 
transmission technology to achieve high security and high levels 
of interference resistance.  Their products are low power 
devices, FCC certified under Part 15 in the US and DOC type 
accepted in Canada for licence-free operation.

	The specs say: Frequency: 915MHz (2.5 GHz also available);
                       Speed: Variable, 1 Mbps nominal
                       Transmit Power: up to 1 watt
                       Typical range: Indoor/Office 300' diameter
                                      Open Factory 1200' diameter
                                      Building - Building 
                                      (line of sight) 1 mile
                                 Directional antennae are available
	               Price:    about $2000, but not yet fixed

Two products are available (but won't be shipping until "4th quarter"):
  ARLAN 610 is a router that "ties into an Ethernet backbone LAN" 
            and according to the Tech I talked to would provide 
            plug'n play compatibility for Internet routing.
  ARLAN 650 is a 8-bit PC/AT compatible card that provides a fully 
            self-contained LAN communications card.  You just have 
            an antenna sticking out the back instead of a wire.

     The 650 sounds like a great product.  Think of the bucks 
you'ld save not having to lay cable (and re-lay it when users 
move!)  It's major drawback is that the only driver available is 
for Novell NetWare.  Utterly useless for a majority of 
applications.  

     Personally I think these sound like fantastic problem 
solvers, especially  for situations like mine and similiar 
situations I know to exist on this campus.  Not to mention home 
use!  I told them having a packet driver written to FTP 
Software's PC/TCP specs would open up a tremendous market.  The 
tech I spoke to said he'ld look into it.  Any other suggestions 
anyone might have would also be welcomed.

PLEA TIME:    CONTACT THIS COMPANY!

If anybody else agrees with me please CONTACT THIS COMPANY!  Let 
them know there is a market out there (I KNOW I'm not alone) AND 
that most of the world wants something other than Novell (like 
TCP/IP).  End of plea.

     Oh yeah, if anyone has any OTHER ideas, let me know.  Thanks!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Royce Robbins                         INTERNET: royce@resp-sci.arizona.edu
Div Resp Sciences                          FAX: (602) 626-4884
UofArizona                               PHONE: (602) 626-5022
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 90 22:36:00 GMT
From:      tiamat!jim@uunet.uu.net  (Jim O'Connor)
To:        tcp-ip@nic.ddn.mil
Subject:   quick check for available host
What is a quick way for a shell script to find out if a networked
host is currently available?

For instance, I'd like to do something like

if host_present hostname
then
	# run network commands
else
	# take other action
fi

Using just about rsh (or rcmd, or remsh, depending on your flavor)
command will work, but it takes rsh (mine anyway) over a minute to
time out, and I'd like to use something that works a little quicker.

I have a socket library, so if you just have programming tips, send them
along and I'll try to write a program that does just what I want.

Thanks,
--jim
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Ahlstrom Filtration, Inc.		615/821-4022 x. 651
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 09:42:59 CDT
From:      willis@cs.tamu.edu (Willis Marti)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Push?
This has to be one of the novice questions, but I haven't been able to dig out
the answer.
Programming under SunOS 4.1, using sockets and send and all that, how can I
tell the TCP to "push" the (possibly buffered) data out *now* and not wait to
piggyback anything.  I don't want to use URGENT (and I'm not sure it has the
same effect).  The only thing I see is to use setsockopt so that TCP *never*
delays... Not really the effect I want either.
What I want is flush for a socket.
Is the PUSH bit implemented? Can I (an application program) set it?
RTFM's accepted, if you'll give me the page.
Thanks,
-------------------------------------------------------------------------------
 Willis F. Marti                Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
        ---Not an official document of Texas A&M---
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 06:44:07 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is a UNIX Domain Socket?
In article <1990Sep27.180632.25841@dg-rtp.dg.com> harvey@dg-rtp.dg.com
(Michael Harvey) writes:
+---------------
| Sockets support two communications domains: the UNIX domain
| for process-to-process communication on the same host,
| and the Internet domain for process-to-process communication
| between hosts that communicate with one another using the
| DARPA standard communication protocols, such as IP, TCP, and UDP.
+---------------

The [Berkeley] socket model supports an arbitrary number of domains.
Let's not forget the XNS domain (Xerox NS), which uses Xerox standard
protocols (ITP, Courier, Clearinghouse), or the XTP domain (Protocol
Engines Inc.'s protocol), or VMTP, or whatever...

...even if AF_INET *is* the most common.


-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
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 11:12 EDT
From:      Twarowski@DOCKMASTER.NCSC.MIL
To:        tcp-ip@NIC.DDN.MIL
Subject:   Uses of PING

   Does the use of  ping -s  through a router to a workstation on
   another ethernet provide a good estimate of packet throughput?

   I have seen where someone will run this command for a couple of
   hours and then kill it to get the number of packets that didn't
   make it. I monitor the Proteon router using SNMP and have been
   getting a 20% packet loss. This other person says that by using
   ping -s he gets only a 2% packet loss.  Can anyone explain????

                                                  Alex
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 14:40:30 -0400
From:      mayer@columbia.sparta.com
To:        tcp-ip@nic.ddn.mil
Cc:        mayer@sparta.com, cfm@sparta.com, hsw@sparta.com
Subject:   sockets, PC-NFS, X, and Clarkson packet drivers
I've been told that the clarkson packet drivers can solve a problem I
have with PC-NFS sockets (namely that there are only 6 of them).  I
ftp'd the drivers and the "pc-nfs driver compatability kit", but must
admit that the resolution of my problem is not apparent
(unfortunately, network protocols are not my forte).  I'm using an X
server on a MS-DOS machine and constantly bump against the 6 socket
limitation.  Although I need to increase this capability, I don't want
to lose PC-NFS's capabilities to mount remote file server directories
as DOS drives and use remote printers.  Is it indeed true that the
Clarkson stuff can allow an increase numer of sockets for PC-NFS?  And
if so, can anyone give me some pointers on how to configuration the
drivers to work with PC-NFS?  Are there any other "public domain"
solutions to my problem (I'd rather advoid a product other than PC-NFS
for compatability reasons)?  Thanks in advance for any assistance.

Frank Mayer
(mayer@sparta.com)

PS- please CC any response directly to me since I do not usually
follow this list.
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 16:57:04 PDT
From:      dsr@NISD.CAM.UNISYS.COM (Dale S. Russell)
To:        tcp-ip@nic.ddn.mil
Subject:   DDN X.25 source desired
I would appreciate any leads to available DDN X.25 software (packet level) written
in C (preferably PD).  Please respond directly to me at dsr@cam.unisys.com.

--Dale
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 18:21:11 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mayer@sparta.com
Cc:        cfm@sparta.com, hsw@sparta.com, tcp-ip@nic.ddn.mil
Subject:   Re: sockets, PC-NFS, X, and Clarkson packet drivers
The Clarkson drivers are a MAC-layer (raw Ethernet frame level) interface,
and have nothing to do with PC-NFS's emulation of 4bsd sockets on DOS.
Yes, you can run one on the other, but if the number of open sockets
isn't documented as being configurable, it is presumably a table size
compiled into PC-NFS.  PC/TCP supports up to 20 sockets (you have to
close your stdio handles to get this many), I believe WIN/PC is also
configurable, I don't know about BWTCP.

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

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 Sep 90 00:09:56 -0700
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        wayne@ultra.com (Wayne Hathaway)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts

Wayne, this is a typical problem in many host AND router implementations.

In your example, Host B should not forward the broadcast under any
circumstances if it is received via a MAC layer broadcast.  True, few BSD's
do this.  Few IP implementations do this.  Some do however (I think of 
Phil Karn's KA9Q code).  It's not that hard after all.  I seem to remember
talking to Mike Karels one day about this, and that he was planning to
add a couple bits that get passed along with the packet from the driver to
IP so that you could tell if it was received via broadcast or multicast.  
I'm not sure that 4.3-Reno does this, but I'm sure someone out there can
answer the question.

Trying to use the destination IP address to determine if the packet was
transmitted via MAC layer broadcast is a heuristic.  The link layer knows
everything IP needs to make the proper decisions.  Then most implementations
throw away this very good information and then attempt to fake it by looking
at the destination IP address.  It works as long as nobody is doing anything
strange, but it's certainly not robust, and one misconfigured host can
trash the network.  It's certainly not a good design.  As a rule, it's 
a bad idea to throw away known good information.  You almost always need
it again soon.

Your case about the directed broadcast brings up a touchy subject. 
My personal opinion is that directed broadcasts are universally bad.  In the
cases where this sort of thing is handy, Internet Multicasting should 
be used.  I know this isn't supported by many routers, but with work on
adding Multicast support to OSPF, we should see some progress in this area
soon.  

Nonetheless, if you are one of the people who believe in directed broadcasts,
I'll say you should still never forward a broadcast received by MAC layer
broadcast, but may forward it if received via unicast.  That is, I believe if
someone is really wanting to do a directed broadcast, he should unicast the 
packet to his router, and not be so crass as to broadcast it.  This still 
prevents broadcast storms, but it depends on the router where the directed
broadcast entered the network to make sure the right thing is done.  It's
not as robust as dropping the packet, but should still prevent most mischief.

In any case, if your router implementation forwards broadcasts under these
conditions, I claim it violates RFC 1009.  And it'll certainly violate 
the son-of-1009 being worked on now!  So all you router vendors, get with
it!  You'll be glad you did, and so will your customers.

We in the Internet community should always remember that we aren't building
research experiments.  We're building the infrastructure that all kinds
of people are using to get their jobs done.  If we build in things that
aren't robust, many people will suffer.

						Thanks,
						   Milo
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 14:15:44 GMT
From:      garof@sixcom.sixcom.it (Joe Giampapa)
To:        comp.protocols.tcp-ip
Subject:   Help! East->West xAtlantic Internet Routers

If there is an Internet newsgroup, my apologies for this mistake.  Please let
me know of it, and cross-post this message.  Thanks.
===============================================================================

I am desperately trying to access my US accounts in the Boston area, from
Milano.  My setup is a bit demented:

1. I have a 19200bps Telebit modem.

2. The only close modem I know of is at CILEA (in Milano), which only
operates at a noisy 1200bps (V21 standard).

3. From there, I can do an X.25 connection to a terminal server at CINECA
in Bologna.  From there I can access Internet (the command is "TCP").

4. I can type the TCP/IP numbers or the logical names of my destinations, and
they will be resolved by the nameserver [DECTCP.???.it], at CINECA.

5. I can make the connection, login, and wait.

Usually after 3 minutes, I can no longer receive any output from my destination
computer.  Possibilities:  
a) either too much noise and error correcting; or
b) connection drops; or 
 c) the bloody 1200 local modem connection generates too much noise.

My net result is that I am able to get work done in sporadic spurts of
less than 5minutes, and <10 commands.

HELP!
1) Does anyone know of a terminal concentrator which connects to an X.25
network or (better) Internet router, which has a modem operating at V22 or
V22 bis?  The call can be anywhere (preferably, and probably in the north)
in Italy.

2) The Italian Internet router is frequently down (90% of the time).  I am
looking for alternate Internet router connections which bypass the CINECA - CNR
Internet network segments (which means:  all routes other than in Italy).  I
have had a successful login by way of Finland, but only by borrowing somebody's
Finnish account.  X.25 connections to routers are preferred and probably most
practical, in the absence of knowing any Internet router to Internet router
connections.

Any help to any of the above will be a tremendous help.  Thank you.
-Joe Giampapa

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 14:39:45 GMT
From:      cica!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!mips!ultra!wayne@tut.cis.ohio-state.edu  (Wayne Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   Question on forwarding broadcasts
I have a little "IP forwarding of broadcasts" question.  The following
example configuration is absurdly contrived, of course, but it is the
simplest that will illustrate the problem.  The problem did surface in
a much more complex (and realistic) situation, but I don't want to
bore everybody with that.

Anyway, consider:

    +------------+    +------------------------+    +------------+
    |   Host A   |    |     Default Router     |    |   Host B   |
    |            |    |                        |    |            |
    | 192.40.1.1 |    | 192.40.1.2  192.40.2.2 |    | 192.40.2.1 |
    +------+-----+    +------+----------+------+    +-----+------+
           |                 |          |                 |
===========#=================#==========#=================#===========
                               Ethernet

where both Host A and Host B are configured to forward things they
cannot handle to the Default Router.  Note that there are TWO
DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and
192.40.2).  (This is of course key to the problem, but it is a
perfectly legal configuration, no?) 

Now assume a user on Host A does a broadcast to network 192.40.1 (its
own network).  No problem, Host A simply puts the message out with the
Ethernet MAC layer broadcast address, and it is picked up by everybody
on network 192.40.1.  But Host B will also pick up this message, and
will find that it is not destined for him.  Host B will then forward
it to the Default Router over network 192.40.2.  The Default Router
will receive this forwarded packet, and will see that it is a
broadcast for a directly-connected network, so he will broadcast it
out on network 192.40.1, by putting it out with the Ethernet MAC layer
broadcast address.  But Host B will also pick up this message, and
will find ...  [repeat as needed].

Clearly what Host B SHOULD do with the "misdelivered broadcast" is say
"This is not for me AND it came in as a MAC layer broadcast; therefore
just discard it (do NOT forward it)."  But unfortunately that requires
IP to know what MAC layer address a datagram came in on, and (at least
in any BSD-derivative implementation I know of) that information is
not available to IP.

Finally, note that saying "Host B should recognize this is a broadcast
from the destination address and not forward it" is NOT a solution,
since it appears to Host B to be a perfectly legal DIRECTED broadcast
to network 192.40.1 from somewhere else, and as far as Host B knows,
he is the only way for that directed broadcast to get through; he HAS
to forward it.

Any comments/suggestions/flames?  Are there non-BSD implementations
out there that handle this?  Mods to BSD?  Future plans from vendors?
Anything else?

[This IS a real problem in any situation where there are multiple
independent networks or subnets active on a single cable, and we in
particular have a lot of those situations. Any real live help will be
most appreciated!]

    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!
-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 16:30:57 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Internet (Open) University


I was so impressed by the number and quality (in breadth&depth) of 
papers inspired by Internet Engineering problems presented at this
(and last) years ACM SIGCOMM Symposium that a strange idea
occurred to me on the way back to the UK (partly fueled by 2 other
experiences):

We run a distance learning University in the UK called the Open
University; I successfully supervised a student through to his PhD
over the UK Academic network last year;

Why not institute a graduate internet school?

(or is it too early?)

jon 

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 17:02:45 GMT
From:      smb@purdue.edu  (Scott Ballew)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
In article <1990Sep28.143945.7440@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
<I have a little "IP forwarding of broadcasts" question. 
<
<Anyway, consider:
<
<    +------------+    +------------------------+    +------------+
<    |   Host A   |    |     Default Router     |    |   Host B   |
<    |            |    |                        |    |            |
<    | 192.40.1.1 |    | 192.40.1.2  192.40.2.2 |    | 192.40.2.1 |
<    +------+-----+    +------+----------+------+    +-----+------+
<           |                 |          |                 |
<===========#=================#==========#=================#===========
<                               Ethernet
<
<where both Host A and Host B are configured to forward things they
<cannot handle to the Default Router.  Note that there are TWO
<DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and
<192.40.2).  (This is of course key to the problem, but it is a
<perfectly legal configuration, no?) 
<
<Now assume a user on Host A does a broadcast to network 192.40.1 (its
<own network).  No problem, Host A simply puts the message out with the
<Ethernet MAC layer broadcast address, and it is picked up by everybody
<on network 192.40.1.  But Host B will also pick up this message, and
<will find that it is not destined for him.  Host B will then forward
<it to the Default Router over network 192.40.2.

Hold it!  In your configuration, Host B should NOT be forwarding ANY
packets at all, unless it is configured as a gateway.  Now, assuming
that Host B IS a gateway and has another network connected behind it,
the answer is found in (I believe) the gateway's requirements RFC (RFC
1009).  Somewhere it says that if a datagram is received via a media
broadcast that is not destined for a local broadcast address (ie, one
of Host B's own broadcast addresses), then it should be quietly
discarded.

Scott Ballew
Cypress Network Operations Center
Purdue University Department of Computer Sciences
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 17:08:12 GMT
From:      dag@fciva.FRANKLIN.COM (Daniel A. Graifer)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: MAC MS-MAIL to SMTP gateway?

In article <26FE4E59.1748@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes:
>In article <34162@cup.portal.com>, Brian_C_McBee@cup.portal.com writes:
>> We have MS mail [...] appletalk network [....] Kinetics Fastpath.  What is
>> our best bet for gatewaying MS-MAIL to SMTP?  
 
>GatorMail - M, they also have one called GatorMail - Q for QuickMail. 
>Kurt Baumann                       InterCon Systems Corporation

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.

What about something utilizing the Columbia Appletalk Protocols?  You might
also check with Compatible Systems (303)444-9532 for software that is
associated with their EtherRoute product (has anyone tried this hardware,
by the way?).  Also try calling Mt Xinu (K-share product) (415)644-0146
and Information Presentation Technologies (IPT uShare) (818)347-7791.

Good luck
Dan
--
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!fciva!dag				7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102
-- 
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!dag@fmccva.franklin.com		7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Sep 90 17:30:57 +0100
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Internet (Open) University

I was so impressed by the number and quality (in breadth&depth) of 
papers inspired by Internet Engineering problems presented at this
(and last) years ACM SIGCOMM Symposium that a strange idea
occurred to me on the way back to the UK (partly fueled by 2 other
experiences):

We run a distance learning University in the UK called the Open
University; I successfully supervised a student through to his PhD
over the UK Academic network last year;

Why not institute a graduate internet school?

(or is it too early?)

jon 
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 19:24:13 GMT
From:      ism.isc.com!clubisc!kirkd@uunet.uu.net  (Kirk Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
I'm posting this for Xircom since they have no net access.
I'd like to comment on my own, but I feel it would be
inappropriate since I'm bias (I'm working with them and
found them to quite reasonable).

So please, no email... (see the number below)

---

We at Xircom regret any confusion and inconvenience we
may have caused regarding our support for the Packet
Driver interface. But, due to the proprietary nature
of the internal operation of our products, we feel it
would not be prudent to freely distribute the source of
our drivers.

Understanding Mr. Nelson's concern, 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. Please note that Xircom is committed to
the TCP/IP community and is supported on over 15
different TCP/IP products, only some of which are based
on the Packet Driver.

In a product comparison review in the August 27th.
issue of PC Week, Xircom was shown to be the fastest
(and received the highest OVERALL rating) of the external
LAN adapters.

Please contact Mr. Steven R. Magidson at Xircom for
additional information. (818) 884-8755 phone; (818)
884-1719.
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 19:34:54 GMT
From:      eru!hagbard!sunic!kth.se!perand@bloom-beacon.mit.edu  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP comparison
In article <9009241517.AA08899@ucbvax.Berkeley.EDU> HANK@TAUNIVM.BITNET (Hank Nussbacher) writes:
>SNMP product comparison time:
>
>Product name            Company Name
>------------            ------------
>Dual Manager            Netlabs
>Netmon III              SNMP Research
>LAN Systems 9100 NMC    Hughes
>OverVIEW                Proteon
>NCC                     Unisys
>NMS                     cisco
>WIN/MGT                 Wollongong
>XNETMON III             SNMP Research

There doesn't seem to be anybody here who is willing to share experiences 
with any of these products, I tried last month. Well, a few, but nothing
that makes me satisfied. (Which means I'll have to try a couple myself, I 
think). Anyway, you are missing a few.

DEC mcc			Digital (VMS and Ultrix)
Sunnet Manager		Sun
Openview		HP (PC-based)
Something?              Vitalink ( I think it's a repackaged HP product )

What I am missing is configuration informations, such as which of these 
products can use imported MIBs. I have been reading the Hughes manual, and 
as far as I can tell that one won't. A scorecard maybe is a good idea.
What should be in it ?

Per
-- 
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
-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 90 23:40:10 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
In article <1990Sep28.143945.7440@ultra.com>, wayne@ultra.com (Wayne Hathaway) writes:
> ... [description of having 2 logical networks on 1 cable deleted]
>...
> Clearly what Host B SHOULD do with the "misdelivered broadcast" is say
> "This is not for me AND it came in as a MAC layer broadcast; therefore
> just discard it (do NOT forward it)."  But unfortunately that requires
> IP to know what MAC layer address a datagram came in on, and (at least
> in any BSD-derivative implementation I know of) that information is
> not available to IP.

I think this is available in 4.3BSD-Reno.  I think it is required
by the Host Requirements RFCs.  It is or will soon be available from
at least one vendor.

>...
> Finally, note that saying "Host B should recognize this is a broadcast
> from the destination address and not forward it" is NOT a solution,
> since it appears to Host B to be a perfectly legal DIRECTED broadcast
> to network 192.40.1 from somewhere else, and as far as Host B knows,
> he is the only way for that directed broadcast to get through; he HAS
> to forward it.
>...
>     Wayne Hathaway               domain: wayne@Ultra.COM
>     Ultra Network Technologies     uucp: ...!ames!ultra!wayne


What about using any of the zillions of routing protocols instead
of static, default routes?  Even RIP should work.

I thought some people say directed broadcasts are or should be illegal.


Vernon Schryver,  Silicon Graphics,   vjs@sgi.com
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 00:14:27 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   Cost of ISDN (was: TCP/IP Over ISDN)
I apologize if this is the wrong place to post this, but I couldn't find
an ISDN newsgroup on COMP.xxx.  I am wondering what are the costs associated
with installing a minimal ISDN configuration in a commercial setting?  
What are the one-time and monthly charges associated with the hardware and
the telecomm service?

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 00:23:24 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   X.25 Versus ISDN
Has anyone done or seen a cost analysis for using T1 lines versus ISDN?  
What is the point at which T1 becomes cheaper, or does it ever become
cheaper?   What are the long-term prospects for leased lines/T1 lines once
ISDN becomes more widely available for anything other than applications
that require use of higher bandwidth than ISDN by a single application?

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)
 
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 06:06:56 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!turing.cs.rpi.edu!faatzd@ucsd.edu  (Don Faatz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom

	As a community that benefits greatly from the efforts of people like
Russ Nelson - we should STRONGLY support his position. If vendors who
collect money for their products are encouraged to behave badly and
basically absorb copyrighted freeware without regards for the copyright
owner - we shall all suffer as the freeware pool goes dry.

	I, for one, shall not buy products from Xircom now or in the future.


<
<Don Faatz, Rensselaer CSLab faatzd@cs.rpi.edu, Troy, NY
<
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 06:31:46 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <1990Sep28.192413.21255@ism.isc.com> kirkd@clubisc.ism.isc.com (Kirk Davis) writes:

   We at Xircom regret any confusion and inconvenience we
   may have caused regarding our support for the Packet
   Driver interface. But, due to the proprietary nature
   of the internal operation of our products, we feel it
   would not be prudent to freely distribute the source of
   our drivers.

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.

   Understanding Mr. Nelson's concern, 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.

"Concern"?  "CONCERN"?  You fardling stole my software, that's what you
did.  For a year you distributed it in violation of my copyright[1].  I've
gone beyond concern -- I'm right pissed!  And being a developer of free
software, I don't have money to pay a lawyer to sue your ass off [2].

You can bet your bippy I'm going to go over your "independently developed"
packet driver with a fine-toothed comb.

There are two morals to this story for other developers of free
software: Register your copyright so you can sue for damages, and
don't compromise free software.

    [1] You don't have to take my word for it.  Look at their Clarkson-
    derived driver and you'll see my copyright, which points you to the
    file called COPYING, which gives the terms for copying.  One of the
    terms is that all the source for an executable that includes my code
    must be available.  As a *concession* to Xircom's concerns, I allowed
    them to require a nondisclosure agreement before providing source
    to anyone requesting it.  They won't do it, even though they said
    they would.

    [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
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 14:03:14 GMT
From:      lib!thesis1.hsch.utexas.edu@tmc.edu  (Jay Maynard)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom

I think Russ is right on the money with this one. While I think the GNU Public
Virus...er...license amounts to software theft and should be boycotted itself,
the proper course for Xircom would have been to not use the code at all if they
were unhappy with the terms of the license. I ceased work on a Clarkson-derived
packet driver because of the GPV, and Xircom should have done the same.

I won't buy anything from them either.
-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu  | adequately be explained by stupidity.
"It's a hardware bug!" "It's a    +---------------------------------------
software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 14:10:02 GMT
From:      news!mentor.cc.purdue.edu!dls@iuvax.cs.indiana.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <5DN%9T*@rpi.edu>, faatzd@turing.cs.rpi.edu (Don Faatz) writes:
> 	As a community that benefits greatly from the efforts of people like
> Russ Nelson - we should STRONGLY support his position.

	Break out the ropes! There's gonna be a lynchin', Festus!

	Your sense of moral outrage is touching, but whether I support his
position or not will have to do with the merits of his position, thank you.

	From what I've seen, and from what I know about people, I doubt that
there was any conspiracy to steal anything. More likely is that they didn't
even read the conditions applied to it and when the knowledge of their mistaken
violation finally made it to the right people, they acted honestly and complied
with the copyright. I don't know the facts, and I doubt that you do either, but
assuming some good faith on both parts, that's what I expect happened.
	What seems to have you so upset is that they comply with the copyright
in the way you wanted. Well, big deal-- if they don't want to make *their*
sources available, they don't have to, and even in the eyes of a Free Software
zealot, that makes them no worse than every other company that does the same
thing. They didn't transfer ownership of Xircom to you, so why are you acting
like you have some right in deciding whether or not they distribute their
sources?
	Boycotting Xircom because Russ Nelson and Don Faatz weren't able to
impose their will on the people running Xircom isn't my idea of a worthy cause.
I can see where Mr. Nelson might be frustrated, and I'm sure he'll make every
effort to clarify the copyright conditions up front in the future, but that's
where it ends for me.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 15:16:35 GMT
From:      netcom!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>In article <5DN%9T*@rpi.edu>, faatzd@turing.cs.rpi.edu (Don Faatz) writes:
>> 	As a community that benefits greatly from the efforts of people like
>> Russ Nelson - we should STRONGLY support his position.
>
>	From what I've seen, and from what I know about people, I doubt that
>there was any conspiracy to steal anything. More likely is that they didn't
>even read the conditions applied to it and when the knowledge of their mistaken
>violation finally made it to the right people, they acted honestly and complied
>with the copyright. 

That's what I told the judge, I did'nt *READ* the 35mph speed limit sign....
He threw the book at me.

Ignorance is not a legal defense. When Xircom shipped their first driver, they
entered into that contract, whether they read it or not.

-- 
 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."
-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 15:25:42 GMT
From:      usc!cs.utexas.edu!smoot@ucsd.edu  (Smoot Carl-Mitchell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
In article <70667@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>What about using any of the zillions of routing protocols instead
>of static, default routes?  Even RIP should work.
>
>I thought some people say directed broadcasts are or should be illegal.
>
>
>Vernon Schryver,  Silicon Graphics,   vjs@sgi.com

Routing has little to do with this problem.  It looks like a variation of
the famous broadcast storm problem inherent in 4.2BSD based TCP/IP
implementations.  The rule is a host which is not configured as a router
should *NEVER* forward an IP packet which has a different destination
address.  4.2BSD has the unfortunate feature of having IP forwarding turned on
for any host.  This has since been fixed in 4.3BSD.

Obviously if more than one host forwards such a misdirected broadcast then
network meltdown can occur very rapidly.  An amusing variation on this
problem is to get a packet sniffer and send an ICMP echo request packet
using the Ethernet and IP broadcast address at about 0.5 sec intervals and
watch the growth in ICMP traffic as all the hosts on the ethernet reply to
this request all at once.  Needless to say on a CSMA/CD network the collison
rate also goes thru the roof.  The corollary rule is never build an application
which sends a broadcast packet which expects more than one host to reply to
the broadcast.
-- 
Smoot Carl-Mitchell, Texas Internet Consulting
smoot@tic.com, smoot@cs.utexas.edu
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 16:45:56 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <14121@netcom.UUCP>, jbreeden@netcom.UUCP (John Breeden) writes:
> Ignorance is not a legal defense. When Xircom shipped their first driver, they
> entered into that contract, whether they read it or not.

	Of course it's not a legal defense. Who said it was? I'm talking
about morality and justice, which have little to do with copyright law. A
boycott has nothing to do with the legal system, either.
	I'd agree that they should pay damages for the interim in which they
used the code, if there were any, and nothing I've seen says they're unwilling
to. But if anyone was damaged, it was the people who bought the stuff and
wanted sources, not Mr. Nelson. And since they knew they weren't getting
sources at the time, I don't think they'd have a case (ethically) either.
	I'm not endorsing Xircom or anyone else-- I know nothing about their
products-- but if you buy an inferior product on "principle" because Xircom
refuses to be intimidated after making a mistake, the joke's on you. If the
only point of a boycott is to force them to abide by GNU's ideas about
software, it's GNU that needs boycotting.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 16:46:33 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: Please boycott Xircom
In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:

   	From what I've seen, and from what I know about people, I
   doubt that there was any conspiracy to steal anything. More likely
   is that they didn't even read the conditions applied to it and when
   the knowledge of their mistaken violation finally made it to the
   right people, they acted honestly and complied with the copyright.

You're right in that it *is* more likely.  In this case, however,
Xircom knew about the GPL, or GPV (General Public Virus) as one wag
put it.  They knew they were obliged to make their source available,
and agreed to do so for those people willing to sign a nondisclosure
agreement.  In spite of agreeing to do so, they will not.

"Honestly" is not the term I would use.

	Boycotting Xircom because Russ Nelson and Don Faatz weren't
   able to impose their will on the people running Xircom isn't my
   idea of a worthy cause.

I'm not trying to impose my will on them.  I'm just trying to make them
live up to their word.  Right now, if someone from Xircom told me it was
sunny, I'd reach for my umbrella.

   I can see where Mr. Nelson might be frustrated, and I'm sure he'll
   make every effort to clarify the copyright conditions up front in
   the future, but that's where it ends for me.

But I *DID* clarify them up front!

--
--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
-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 18:20:47 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
In article <11858@medusa.cs.purdue.edu>, smb@cs.purdue.EDU (Scott Ballew) writes:
> Hold it!  In your configuration, Host B should NOT be forwarding ANY
> packets at all, unless it is configured as a gateway. ...

Right!  I wish I had said that.  (I did think it; trust me.)
Don't the Host Requirements say the same?

For various reasons, I bet the original poster is running workstations with
two interfaces, one ethernet and one other kind.  I bet the workstations
have either 4.2BSD or 4.3BSD TCP/IP, where having two interfaces turns on
IP forwarding.  If so, the easy solution is to set the kernel variable
ipforwarding to 0.  That can be done with adb on some systems and by
editing configuration files on some other systems.



Vernon Schryver,    vjs@sgi.com.
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 90 19:50:51 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question on forwarding broadcasts
>
>I have a little "IP forwarding of broadcasts" question.  The following
>...
>Anyway, consider:
>
>    +------------+    +------------------------+    +------------+
>    |   Host A   |    |     Default Router     |    |   Host B   |
>    |            |    |                        |    |            |
>    | 192.40.1.1 |    | 192.40.1.2  192.40.2.2 |    | 192.40.2.1 |
>    +------+-----+    +------+----------+------+    +-----+------+
>           |                 |          |                 |
>===========#=================#==========#=================#===========
>                               Ethernet
>
>where both Host A and Host B are configured to forward things they
>cannot handle to the Default Router.  Note that there are TWO
>DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and
>192.40.2).  (This is of course key to the problem, but it is a
>perfectly legal configuration, no?) 
>...
>Finally, note that saying "Host B should recognize this is a broadcast
>from the destination address and not forward it" is NOT a solution,
>since it appears to Host B to be a perfectly legal DIRECTED broadcast
>to network 192.40.1 from somewhere else, and as far as Host B knows,
>he is the only way for that directed broadcast to get through; he HAS
>to forward it.
>

Well, you might put it that way, but since it was sent on a LL broadcast
address, it really isn't a directed broadcast, as those are supposed
to stay unicast until they reach the destination (sub)network. At that
point, they become 'plain-old' broadcasts and the usual rules apply.

>Any comments/suggestions/flames?  Are there non-BSD implementations
>out there that handle this?  Mods to BSD?  Future plans from vendors?
>Anything else?
>

First, is it really necessary for the hosts to be doing any forwarding
in the first place - are they routers themselves? If not, by all
means, disable gateway functionality. There are non-BSD
implementations that do handle this situation - I happen to work on
one ;-) (but we fixed it for a different reason ;-) and I'm certain
that by the time this gets out, someone will have pointed at the
apropopriate mods to BSD code. BTW - IP really doesn't need to know
what the LL address was, just a boolean saying whether or not it was
unicast.  However, it might need to become 'smarter' in the face
of IP multicasting ???  

Apart from a) disabling forwarding on the hosts, or b) getting the
mods put in, or c) going to a different box, your only other
alternative might be to split the network onto separate wires - fun,
huh ;-) I'd suggest that you push your vendor(s) to get you code that
is more in line with the RFC's - beg, cajole, threaten, or whatever,
because that is really the solution you appear to need.

>    Wayne Hathaway               domain: wayne@Ultra.COM

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Even MPE can do the right thing!
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 90 08:55:32 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Push?
In article <9009281442.AA26616@cssun.tamu.edu> willis@CSSUN.TAMU.EDU
(Willis Marti) writes:
+---------------
| This has to be one of the novice questions, but I haven't been able to dig
| out the answer. Programming under SunOS 4.1, using sockets and send and all
| that, how can I tell the TCP to "push" the (possibly buffered) data out *now*
| and not wait to piggyback anything....
+---------------

All "BSD 4.x"-derived TCPs (and I believe that includes Sun's) automatically
set the "PUSH" bit on the last packet of any Unix "write()". That is, a write
to a socket *is* a "write-and-push".

There are too many applications that would break if this were not the case.


-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
-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 90 20:59:44 GMT
From:      ddl@husc6.harvard.edu  (Dan Lanciani)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please boycott Xircom
In article <NELSON.90Sep29114633@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
| In article <14568@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
| 
|    	From what I've seen, and from what I know about people, I
|    doubt that there was any conspiracy to steal anything. More likely
|    is that they didn't even read the conditions applied to it and when
|    the knowledge of their mistaken violation finally made it to the
|    right people, they acted honestly and complied with the copyright.
| 
| You're right in that it *is* more likely.  In this case, however,
| Xircom knew about the GPL, or GPV (General Public Virus) as one wag
| put it.  They knew they were obliged to make their source available,
| and agreed to do so for those people willing to sign a nondisclosure
| agreement.  In spite of agreeing to do so, they will not.

	I hope no one takes this as a flame, but I suspect GNU/FSF
proponents could help minimize incidents like this one by using
more conventional terminology rather than inventing or redefining
words that might have potentially misleading connotations.  While
it in no way excuses Xircom from ignoring the terms of the license,
I think the words ``free'' and ``copyleft'' as used by FSF are likely
to confuse people not familiar with the GNU license agreement.
	Before the FSF's usage, the term ``free'', when applied
to software, often implied to many a lack of cost associated with use
and/or distribution.  Giving up control of proprietary code is a very
real cost for many companies and they may not understand that this
could be one of the costs associated with incorporating ``free'' software
covered by the GNU license agreement into their product line.
	The non-word ``copyleft'' is probably even worse in that a
corporate lawyer not aware of FSF policy may assume (foolishly, perhaps)
that this is a cute way of saying that something is not covered by
copyright, i.e., that it is in the public domain.  Until ``copyleft''
finds its way into the legal texts (and dictionary) it might improve
understanding if FSF advocates simply stated that their software is
covered by a real copyright and that its use is governed by a license
agreement whose terms might result in significant actual and perceived
costs to certain users/distributors.

				Dan Lanciani
				ddl@harvard.*

END OF DOCUMENT