The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for September 1991 (403 messages, 242504 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/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 91 03:51:57 GMT
From:      wilbur!wndrsvr!andyb@ism.isc.com (Andy Brager)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PPP for ISC Unix V.3.2.2.1


Greetings netters. 

Does PPP exist for ISC Unix V.3.2.2.1  ?
Does anyone know where I could get a copy?

Thanks!!


Andy
-- 
If I bounce, please send a copy of the *whole* message including 
the headers, to andyb@stb.info.com.  Thank you.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 19:46:53 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In comp.protocols.tcp-ip, article <2424@crackers.clearpoint.com>,
  martillo@crackers.clearpoint.com (Martillo) writes:
< and should a developer implement this interface for his
< bridge, router or end host, that network device will be able to
< communicate with the Little Dipper/Auriga products over point-to-point
< serial links as well as any other device which implements this
< specification.  Comments on this draft are welcome. 
< 
One question: I couldn't find anything in these proposals that isn't covered
by RFCs 1171 and 1220..?

Sure, PPP is a tad more work to implement (especially link setup), but we're
talking WANs here and I suggest that the features (identification, link
quality monitoring, et al) are worth the investment.

Substituting sync for async lines in RFC1171 is left as an exercise for the
reader.

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 19:50:29 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:

> We are trying to configure an SCO Unix system running some type of
> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
> is to get up to _6_ Megabits/Sec.

Well, nearly any modern Ethernet card will deliver 6 Megabits per second.
After all it's only around 600KB/s. SCO's TCP protocol stack will most
probably not be able to keep up with the card though.

> We realize that we need EISA bus machines with 32-bit Ethernet cards to do
> this.

Why ever? The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across.
Taking account of all hw protocol overheads it can sustain between 5-6 MB per
second. Here you are proposing to load it with just 600KB/s, which is one
tenth of its top capacity. Think of this: my VGA card will, during continuous
graphics operation, sustain 2MB/s over the ISA bus, and my SCSI controller
will get 1.4MB/s sustained from a SCSI disk.

32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface
between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet).

    Same goes for EISA SCSI disk controllers (the most expensive SCSI disks
    top out at 4MB/s, and most cannot do more more than 1.5MB/s off the
    platter). In practice EISA is only needed for very high speed graphics
    (good luck with that) and for disk arrays, or, theoretically, for very
    high bandwidth tapes.

    The real benefits of EISA, for most people, are not in bandwidth, but
    in configurability and interrupt sharing and multiple mastering, where
    the ISA bus is badly misdesigned.

> Another important detail is that each computer will be talking over a
> Cisco router with one ethernet card per computer.

Note that you need an Ethernet card per computer anyhow :-).

Probably what you mean is that you will have a separate Ethernet cable per
computer. This of course means that each machine would have its own 0.8MB/s
Ethernet dedicated to itself. The problem is that I doubt very much that
this would buy you anything at all, as I would expect the CISCO router not
to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
normally not designed to sustain the maximum combined bandwidth of all the
Ethernets they link. Does anybody know for sure what is the maximum thruput
of a CISCO router?

I expect that in practice having a star configuration with a router in the
middle and an Ethernet to each machine will probably buy you nothing at all,
except having a single active failure point.

> This way we completely eliminate packet collisions.

This is probably completely unnecessary. Collisions are very rarely a
problem, the Ethernet will in practice share out its capacity between
machines in only slightly less than linear fashion, if packet sizes are not
too small.

If you really want for some funny reason a star configuration, with an
active hub, and no collisions and guaranteed point-to-point capacity,
consider seriously getting a Token Ring.  At least Token Ring active hubs
are designed for this task, and not as routers, and tend to be fairly fail
safe too.

> They also told us about their ES3210 card, which they claim can
> operate at _13_ Megabits/Sec. I thought that the cable can't operate
> faster than 10 Megabits/Sec. Am I missing something?

Well, they are telling you nice numbers out of thin air.

> How do I get real numbers that will tell me what to expect in the field?

Toss a coin... :-)

> I don't know how obvious my lack of network expertise is,

Very obvious. :-). But at least you know. Some other poster who also replied
to your article is not in a much better position than yourself, but does not
know. :-)

> but if you see any questions that I'm not asking, I need to know that
> also. I'm sure I'm not asking everything I need to know.

Well, now that I have answered your questions, let's tell you something more
useful.

First of all, the good news: as I have said almost any modern Ethernet card
will deliver substantially all of the Ethernet bandwidth, and this bandwidth
is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA
machine.  Collisions will be in practice not a problem. You probably don't
need a CISCO router at all, you can put all the machines on the same
Ethernet, if you don't need 6Mb/s sustained bandwidth between each machine,
but only aggregate.

The bad news are that the TCP/UDP/IP sw on the host, and in particular
SCO's, will have such huge overheads and misdesigns that in practice you
will not be able to use more than a fraction of the nominal speed of the
hardware. Somebody (Van Jacobson and others) have spent some serious effort
in tuning up certain implementations of TCP/UDP/IP and can boast of being
able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the
hardware capacity, but figures like 30-50% are far more common. I don't
remember exactly, but I seem to remember that you'd be lucky to get more than
300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet
protocol stack.


Finally, what you should tell us is what is your problem, e.g. how many
machines you have got to link, how far apart they are, what is the average
packet length, and what is the maximum packet rate that you expect from each
machine, and other characteristics. Once you have told this to us, we can
tell you whether Ethernet makes any sense at all. Possible alternatives are
running TCP/UDP/IP over SCSI or over several point-to-point links, e.g.
synch, or RS-422, for example.
-- 
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 20:00:28 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

bill@connection.prospect.com (Bill Poitras) writes:

> In article <1991Aug29.041708.29784@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:
> >I think you are asking too much of a timesharing O/S even with an EISA
> >PC to get sustained 6Mbytes/s. If you only want it for bursts, you
> >may have better luck.
> 
> Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
> running AIX with a ESDI controller and 16 bit ethernet controller.  I can
> consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
> running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
> see your problem.

Alleluiah! Alleluiah! He got a dispensation from Shannon himself! He can
shove thru an 800KB/s Ethernet and a 1MB/s ESDI device ten, twenty, one
hundred times their maximum rated capacity! He is one of the Anointed! The
last time we saw anything similar it involved bread and fish!

    Amazing facts: the maximum bandwidth of the MCA bus when running at full
    tilt in 32 bit mode is under 40MB/s; to have 100MB/s of transfer rate
    *to memory* would require dozens of megabytes of requires hundreds of MB
    of 4-way interleaved 20-30ns RAM; to be able to consistently get 20MB/s
    on a TCP/IP link would require, assuming an overhead of 4 instructions
    per byte passed thru (wildly optimistic, just consider checksumming), a
    80Mhz CPU.

:-) :-) :-) :-) :-) :-) :-) :-)
-- 
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 20:17:17 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <BOB.91Aug31121320@remora.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> In article <2424@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
>    ... [S]hould a developer implement this interface ... that network
>    device will be able to communicate with the Little Dipper/Auriga
>    products ...
 
> Would I still be able to communicate with members of the Little
> Dipper/Auriga product line if I don't manage to SLITHER, but instead
> only implement something like SLIP or PPP?
 
> Which is to say, will Clearpoint's boxes talk to the rest of the
> world?

We may not have the same view of network system architecture. 
Clearpoint makes high-performance WAN/Ether bridging products (routing
will soon be available).  In the normal course of events bridges (unlike
routers) do not really talk to end hosts.  Bridges are so to speak out
of band and talk to other bridges.  Logically, all the bridges (assumed
to be running STP) and ethersegments can be replaced by a single ether
cable and no network host would notice. 

To summarize: bridges are communications subnet devices and not network
hosts.  Historically, communications subnet devices have not had network
addresses and have not been reachable from network hosts.  Recently it
has become more common to implement network host functionality in
communications subnet devices, and in fact some protocols have been
developed which make the implementation of such network host
functionality useful in certain situations.  For this reason, the Little
Dipper/Auriga products support SNMP, server telnet and client telnet. 

But in general, especially in more common networking environments where
TCP/IP is not used, communications subnet devices only communicate with
other communications subnet devices (except perhaps at boot time), i.e. 
bridges generally talk to other bridges while forwarding or filtering
all network host traffic without actually operating on the data within
the packets which compose the traffic.  The Little Dipper/Auriga
products do communicate with all other bridges which implement 802.1d
STP. 

The Little Dipper/Auriga has the capability to do SLIP and PPP.  Remote
transparent bridging using PPP (as well as remote transparent bridging
using Frame Relay and X.25) will appear shortly.  I read RFC1055 and it
looks like SLIP is targeted for slow asynchronous character-oriented
serial links.  This is not really a high-performance medium and the
protocol does not lend itself to transparent bridging and without
customer demand you would have to make an awfully persuasive case to
encourage us to provide it. 

In most networking environments which I have analyzed the largest part
of the traffic is local with infrequent resort to the use of wide-area
links (of course there are some notable exceptions like airline
reservation systems and there are special features in the Little
Dipper/Auriga to handle such systems).  In the usual environments it
makes sense to add 1 to several (currently the LD supports a maximum of
3) WAN interfaces to the bridge to provide all the hosts within the
bridged network with indirect access to the wide-links to other similar
bridged environments or to a router with a WAN interface.  Providing
wide-area connectivity in this manner is cheaper than giving many
individual hosts their own wide area links especially when they would
probably use these interfaces much less than they would use their LAN
interfaces. 

Reasonable possible architectures to provide WAN connectivity are:

1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet

2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet

3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet

4) Ethernet - Router - WAN Link - Router - Ethernet

5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet

In IP terms, architecture:

	(1) corresponds to 1 IP network
	    and can employ the transparent bridging version of PPP or
	    SLITHERNET.

	(2) corresponds to 2 IP networks 
	    and can employ the transparent bridging version of PPP or
	    SLITHERNET.

	(3) corresponds to 3 IP networks
	    and can employ only SLITHERNET.

	(4) corresponds to 3 IP networks
	    and can employ the transparent bridging version of PPP, SLITHERNET
	    or PPP for IP.

	(5) corresponds to 2 IP networks
	    and can employ the transparent bridging version of PPP, SLITHERNET
	    or PPP for IP.

Once we concentrate on high-performance networking on moderate to
high-speed synchronous serial links, only SLITHERNET is completely
flexible.  But I will gladly sell you the means to implement
architecture (5) because I can then lock you into my proprietary
implementation of half-routers. 

(4) is an inefficient use of IP networks, and is an architecture which
should be discouraged.  But we will support you, if you truly want to
do it.

(3) is in most cases the most reasonable architecture when a mesh of
serial links interconnects connect several major bridged LAN sites and
only SLITHERNET supports this.  Unless a bridging device supports 
SLITHERNET, there is no growth path to this architecture, and a customer
who choses bridges and routers which don't support SLITHERNET will
probably in the end have to duplicate his investment.

Now in all cases it is possible a customer truly wants to replace the
right hand half of the network with a single IP host.  If the Little
Dipper/Auriga bridging device is run in bridging mode, the single IP
host will either use PPP in transparent bridging mode or SLITHERNET.  If
the Little Dipper/Auriga bridging device is run in routing mode, the
single IP host will either use PPP for IP or SLITHERNET.  I will make
available a SLITHERNET implementation for the IBM PC in the next couple
of weeks for those people who truly wish to do this. 

I should note that PPP is basically misdesigned because the latest crop
of Ethernet chips tend to support HDLC modes while the latest crop of
Serial HDLC chips tend to support Ethernet modes.  As a consequence if
SLITHERNET is used for wide area networking while ethernet is used for
local area networking, respinning ethernet software for wan uses and
respinning ethernet interfaces for wan interfaces is relatively
straightforward as well as vice versa.  PPP makes such respinning much
harder and more costly.  Basically, a customer who demands PPP is
demanding that his hardware and software cost more.  In a period of
economic retrenchment, demanding SLITHERNET makes a lot more sense
especially when SLITHERNET is a flexible architecture which provides
growth paths.

In short, there are no plans to provide SLIP because it is inappropriate
for the class of devices typified by the Little Dipper/Auriga products. 
PPP for transparent bridging will be available shortly.  PPP for IP will
only become available with routing (available shortly) unless customers
start clamoring for the ability to communicate over a wide area link
solely with the network host functionality built into the bridge. 

Joachim Carlo Santos Martillo Ajami



-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 21:12:37 GMT
From:      karl@MorningStar.Com (Karl Fox)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

Joachim Carlo Santos Martillo Ajami writes:

   Reasonable possible architectures are:

   1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet
   2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet
   3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet
   4) Ethernet - Router - WAN Link - Router - Ethernet
   5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet

   In IP terms, architecture:

	   (1) corresponds to 1 IP network and can employ the transparent
	       bridging version of PPP or SLITHERNET.
	   (2) corresponds to 2 IP networks and can employ the transparent
	       bridging version of PPP or SLITHERNET.
	   (3) corresponds to 3 IP networks and can employ only SLITHERNET.
	   (4) corresponds to 3 IP networks and can employ the transparent
	       bridging version of PPP, SLITHERNET or PPP for IP.
	   (5) corresponds to 2 IP networks and can employ the transparent
	       bridging version of PPP, SLITHERNET or PPP for IP.

You should really have said "Reasonable possible *bridging* architectures",
because I suspect that the most common way of interconnecting TCP/IP
networks looks like your number (4) but where the routers have their
interfaces configured with the BSD IFF_POINTOPOINT semantics, associating
their interface with the primary (Ethernet) address of the machine at the
other end of the WAN link and providing a host route to it.  This doesn't
work with X.25, which usually requires a subnet (unless you are running it
over a point-to-point connection), but it's exactly what is intended to be
used with PPP.  It corresponds to only two IP networks; the point-to-point
link doesn't use up a subaddress.  This is what we recommend to our PPP
customers, and I believe is also what Sun recommends to their Internetwork
Router customers.

Best of all, the two ends of the circuit don't have to come from the same
vendor.  There are dozens of products you can buy *today* that work this
way.  It would certainly rub *me* the wrong way if I were Wellfleet or 3COM
and PSI or Alternet told me I had to buy a cisco router if I wanted a
connection.  It also means that PSI or Alternet can pick a router vendor
and stick with it, since their connections run a non-proprietary protocol.

I believe Bob was referring to something like this.  Coming from the TCP/IP
point of view (and not being constrained by protocol architectures that
don't scale past a LAN), he didn't see the value in bridging over routing.
Of course, if you *do* use TCP/IP, there isn't any (at least until the
Internet gets more than 20 hops wide).

If I've missed something important here, flame away, as I'm somewhat of a
novice at this stuff and probably deserve it.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 21:51:24 GMT
From:      jik@athena.mit.edu (Jonathan I. Kamens)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: how to keep /etc/hosts up to date

Why don't you just update the software on the machines that are running the
BSD networking software so that they're doing bind name resolution instead?

There's no good reason for any machines to still be using hosts files instead
of bind, at least not for machines that are running BSD networking software. 
If your vendor distributes software that does networking without bind support,
then complain to your vendor.  And if you compiled the software yourself, then
get the bind distribution and recompile so that bind is used.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 91 23:35:57 GMT
From:      dave@pmafire.inel.gov (Dave Remien)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:
>> Another important detail is that each computer will be talking over a
>> Cisco router with one ethernet card per computer.
>
>Note that you need an Ethernet card per computer anyhow :-).
>
>Probably what you mean is that you will have a separate Ethernet cable per
>computer. This of course means that each machine would have its own 0.8MB/s
>Ethernet dedicated to itself. The problem is that I doubt very much that
>this would buy you anything at all, as I would expect the CISCO router not
>to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
>normally not designed to sustain the maximum combined bandwidth of all the
>Ethernets they link. Does anybody know for sure what is the maximum thruput
>of a CISCO router?

Ours forwards at about 15000 packets per second, and routes at about
2000 packet/sec. The newer ones are supposed to about double that.

Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
will go.  Even routing implies (assuming max size legitimate packets)
3MBytes/sec.  I suspect that the quoted Cisco rates are for minimum (50
byte) or fairly small packets, netting somewhere in the neighborhood of
100KBytes/sec. 

[ Stuff bites dust ]

>
>The bad news are that the TCP/UDP/IP sw on the host, and in particular
>SCO's, will have such huge overheads and misdesigns that in practice you
>will not be able to use more than a fraction of the nominal speed of the
>hardware. Somebody (Van Jacobson and others) have spent some serious effort
>in tuning up certain implementations of TCP/UDP/IP and can boast of being
>able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the
>hardware capacity, but figures like 30-50% are far more common. I don't
>remember exactly, but I seem to remember that you'd be lucky to get more than
>300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet
>protocol stack.

Our SCO box, with WD8003e, 33MHz 80386 and caching ESDI controller
simply is incapable of EVER exceeding 100KB/sec over the network, even
using a simple send the same packet over and over again through a UDP
connection. Average rcp/ftp stuff is about 70KB/sec.

My Dell V.4 box, admittedly running on a '486-25 with SCSI and WD8013,
averages 285KB/sec talking to our HP9000/720, sending 20MB at a whack.


>Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

Dave
-- 
Dave Remien +*+*+*+*+*+*+*+*+*+*+*+*+*+*+ WINCO Computer Engineering Group 
  dave@pmafire.inel.gov or rzd@inel.gov      "Dave Barry for President" 

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 03:47:25 GMT
From:      MITRE-TAEGU@TAEGU-EMH1.ARMY.MIL
To:        comp.protocols.tcp-ip
Subject:   Routing using RIP

RE:  RIP routing algorithm - "routed" implementation 

The RIP algorithm is based on selecting the route with the least number of
hops.  However, how does it select between routes with an equal number of hops?

Suppose a system that looks something like the following:

                  ______________
                  |  Distant   |
                  |  Network   |
                  --------------
                   /         \
                 /             \       <----Diverse comms paths
                /               \
            ________         ________
            |  A   |         |  B   |        <---Local gateways 
            --------         --------
               ||               ||
         ================================     <----Local ethernet
           ||       ||      ||        ||
           C        D  ..............  Z     <---Local workstations

The local workstations (C..Z) would all have paths to the distant network
through both A and B.  Both would have equal hop counts.  How then do they
select the gateway to use?  

A non-scientific observation of our path use would seem to indicate that one
route is preferred over the other in routing packets.  Is it possible that this
selection is based on the order of their appearance in the /etc/hosts file? 
(Note that our system does not use NIS, for reasons that are beyond the scope
of this discussion.)  

We would appreciate any insight into the routing under these conditions.  Also,
is there any reason to believe that "gated" may handle this situation better
than "routed" does?  

Thanks for any information.

                                             Dan Jones
                                             mitre-taegu

P.S.:    The local gateways are currently Sun 3/160s running SunOS 3.5. with
         the SunLink version 5.0 internet routing package.   (This will
         eventually be upgraded to SunOS 4.1.1 and the version 6.x of the
         internet routing package.)  The local workstations can be either Sun
         3/160s or Sun 386is running SunOS 4.0.2.   

P.P.S:   Are there alternative routing algorithms available that would use
         another metric, such as delay time, instead of hop count?

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 09:52:09 GMT
From:      jacob@chaos.cs.brandeis.edu (Jacob Baltuch)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   info on getting onto internet requested

I'm trying to get the company I work for onto the Internet.

I'd need info on:

1. administrativia (where to apply... procedure...)
   essentially a pointer

2. approximate cost of hardware (also: is it up to me and a willing
   gateway to use SLIP...)

thanks for any info. please email: jacob@chaos.cs.brandeis.edu/
                                   baltuch@binah.cc.brandeis.edu

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 10:24:21 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   double msgs

I get two coipies of every msg on this list. As well as the "straight"
msg, i also get a copy which has Sender:
tcp-ip-request@uk.ac.nsfnet-relay as well. Can the moderators fix this
or could the problem be at my end?
_______________________________________________________________________________
Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786  67266  Fax: +78651335
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 10:52:38 GMT
From:      werner@inesc.pt (Werner Vogels)
To:        comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   problems using MACH-NFS


We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and
experience on all these machines the same problem with using NFS. When
we mount a disk from one of our sparcstations, everything runs fine until
a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes
imeditaly with sending these 8k (fragmented at IP level). We can see data
traveling the network but the i386 will not kick the packet up to user
level. Not having the kernel code or objects we can not do any further
debugging. Does any body has any clues?

-- 
Werner Vogels

INESC - Distributed Systems and Industrial Automation Group
        Tel: +351 1 3155150 ext 280, Fax: +351 1 525843
        e-mail: werner@inesc.pt / C=pt;A= ;P=inesc;s=werner

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 12:39:28 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

dave@pmafire.inel.gov (Dave Remien) writes:

>Our SCO box, with WD8003e, 33MHz 80386 and caching ESDI controller
>simply is incapable of EVER exceeding 100KB/sec over the network, even
>using a simple send the same packet over and over again through a UDP
>connection. Average rcp/ftp stuff is about 70KB/sec.
 
>My Dell V.4 box, admittedly running on a '486-25 with SCSI and WD8013,
>averages 285KB/sec talking to our HP9000/720, sending 20MB at a whack.

why do you suppose the SCO box is so slow while the Dell Box screams
(is the 8013 vs the 8003 the issue - or surely not because of the 486
vs the 386)

-- 
            Larry Snyder, NSTAR Public Access Unix 219-289-0287
              {larry@news.rn.com, ..!uunet!news.rn.com!larry}

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 13:32:01 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   hostname & domainname

In a Unix system (IBM aix), I am not sure what to specify for hostname
and domainname an I've found no documentation clear about that.
My first guess would have been:
hostname="machine1"  domainname="department.university.be"
Then I read that, for mail, the hostname may be stripped of its labels.
Could it be:
hostname="machine1.department"  domainname="university.be"
Finally, everything also seems ok (almost) if:
hostname="machine1.department.university.be"  domainname=""
What is the definition of and relation between hostname and domainname?
I guess that mail as distributed should work if mail-address=host-name
without any related modification to sendmail.cf, but aix appends my
"department.university.be" to any destination address.
Given the various mail configuration errors I saw, it's unclear to many.

Please cc: me in an answer. Despite on Internet, I get this group
8 days after you send your mail.

Thanks in advance.

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 13:51:20 GMT
From:      cpcahil@virtech.uucp (Conor P. Cahill)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

pcg@aber.ac.uk (Piercarlo Antonio Grandi) writes:

>    Same goes for EISA SCSI disk controllers (the most expensive SCSI disks
>    top out at 4MB/s, and most cannot do more more than 1.5MB/s off the
>    platter). In practice EISA is only needed for very high speed graphics
>    (good luck with that) and for disk arrays, or, theoretically, for very
>    high bandwidth tapes.

Throughput is not the only evaluation factor for a disk controller.  Another
factor, which is where a good EISA controller will shine, is the amount of
time the bus is tied up transferring that 4MB/s.  You yourself said that
the theoretical max for the ISA bus was between 5 and 6 MB/s.  4MB/s is
appox 80% of the theoretical max.  With a good EISA controller that same
4MB/s can take up only 12% of the theoretical max, thereby freeing the
bus up for other operations.

>    The real benefits of EISA, for most people, are not in bandwidth, but
>    in configurability and interrupt sharing and multiple mastering, where
>    the ISA bus is badly misdesigned.

I want the EISA for the bandwidth.  I like the fact that a controller can
get me my data blocks that much faster while taking up less of the system
bus.

>First of all, the good news: as I have said almost any modern Ethernet card
>will deliver substantially all of the Ethernet bandwidth, and this bandwidth
>is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA

Giving up 20% of the bus bandwidth just to handle ethernet i/o sounds like
a good reason to go with EISA.   20% is alot of the system.

-- 
I guess these are the views of VTI - since it is my consulting company.

Conor P. Cahill              (703)430-9247              uunet!virtech!cpcahil 
Virtual Technologies, Inc.  46030 Manekin Plaza            Sterling, VA 22170 

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 15:23:44 GMT
From:      pcg@aber.ac.uk (Piercarlo Antonio Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

dave@pmafire.inel.gov (Dave Remien) writes:

> In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
> >Probably what you mean is that you will have a separate Ethernet cable per
> >computer. This of course means that each machine would have its own 0.8MB/s
> >Ethernet dedicated to itself. The problem is that I doubt very much that
> >this would buy you anything at all, as I would expect the CISCO router not
> >to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
> >normally not designed to sustain the maximum combined bandwidth of all the
> >Ethernets they link. Does anybody know for sure what is the maximum thruput
> >of a CISCO router?
 
> Ours forwards at about 15000 packets per second, and routes at about
> 2000 packet/sec. The newer ones are supposed to about double that.

Amazing facts #2! Shannon is in a jolly good mood if he gives so many
dispensations these days:

> Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
> will go.

25 times the bandwidth of a single Ethernet. Impressive! CISCO must be very
generous to give customers so much extra capacity, as their routers rarely
connect more than 2-3 Ethernet segments, and they overdesign their products
to handle ten times the maximum load on their average configuration.

> Even routing implies (assuming max size legitimate packets) 3MBytes/sec.

Here I detect the possibly improbable assumption that it can forward or
route maximal size packets at the maximum rate, which seems incredibly
optimistic, because 22MB/s aggregate bandwidth is a really stunning figure,
being able to forward packets between 25 Ethernets at full tilt.

If it really can route 22MB/s then whatever processor card is inside a CISCO
router must have a bus that is at least four times as fast as an ISA bus,
nearly as fast as an EISA bus, and it must have a diabolically fast memory
subsystem.

22MB/s cannot be achieved by most :-) 386 memory subsystems for pure string
copies.  Try copying a 1KB string from one buffer to another for a few
thousand times and then calculate the memory bandwidth.

Just to give people an idea of the numbers involved, here is a transcript of
a quick test done on the local DECsystem 5830, which has got a screamingly
fast (20-25MIPS) 25Mhz R3000 CPU:

    Script started on Mon Sep  2 16:04:31 1991
    $ cat copy.c
    #define N (1024/sizeof (int))
    
    int from[N],to[N];
    
    main()
    {
	register long	k = 64*1024;
    
	while (k--)
	    bcopy(from,to,sizeof to);
    }
	
    $ cc -o ./copy -O copy.c
    $ time ./copy
	    8.3 real         7.0 user         0.1 sys  

I read 7 seconds for copying 64MB, or almost 10MB/s. This is reading and
writing, with no processing. Maybe this 25Mhz R3000 CPU can beat a CISCO
router bandwidth only if one does simply reads from its own cache, so let's
have a look at just reading:

    $ cat read.c
    #define N (1024/sizeof (int))
    
    int frame[N];
    
    main()
    {
	register int	i;
	register volatile	v;
	register long	k = 64*1024;
    
	while (k--)
	    for (i = 0; i < N; i++)
		v = frame[i];
    
	return v;
    }
	
    $ cc -o ./read -O read.c
    $ time ./read
	    4.8 real         4.1 user         0.0 sys  
    $ ^]  
    script done on Mon Sep  2 16:05:55 1991

That's a tad over 4 seconds for 64MB, or 16MB/s.

I'd be truly amazed if the CISCO router could handle 22.5MB aggregate
bandwidth, even if just for forwarding, unless it has inside a processor
memory combination substantially faster than a 5830, or it has a wormhole
chip. Somehow I think both hypothesises are somewhat improbable.

> I suspect that the quoted Cisco rates are for minimum (50
> byte) or fairly small packets, netting somewhere in the neighborhood of
> 100KBytes/sec. 

I suspect that too, so that at 15k packets/s we'd get about 0.8MB/s for
forwarding. Looks more like it. CISCO may not have gotten a Shannon
dispensation after all.

The original poster should tell us, as I said, what kind of packet size and
frequency distribution he expects and so on.
-- 
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 17:13:15 GMT
From:      mike@tredysvr.Tredydev.Unisys.COM (Mike Marciniszyn)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Lachman TCP/IP T_CONN_RES Bug?

THE PROBLEM:

We've seen crash dumps from systems in which TCP listening circuits
no longer seem to correctly connect.  After some investigation,  I've
determined that the inp_tstate has been incorrectly set to BADSTATE, after
which the listening circuit/socket no longer can connect properly.  The
connection actually takes place underneath the API but because of the
BADSTATE, the T_CONN_IND is never forwarded up from the tcp driver to the API.

THE CULPRIT:

The only place that I can find for this to occur is in the handling of
the T_CONN_RES primitive in tcp_state.c.  The code correctly checks to
see if accepting the T_CONN_RES would cause the transport to enter
a BADSTATE.  However, when that is the case inp_tstate is unconditionally
updated as follows:

	inp->inp_tstate = NEXTSTATE(TE_ERROR_ACK, inp->inp_tstate);

The normal state for a listening endpoint is TS_IDLE and in fact, a T_CONN_RES
handled in that state would cause the inp_tstate to get assigned BADSTATE.
I believe this sequence of events can occur if a connection is aborted
in the TCP streams driver after several T_CONN_IND's have been forwarded to the
API layer but before the API layer has generated the T_CONN_RES for all of
them.  In that case,  the count of cloned pcb/tcb's linked to the listening pcb
would be less than the number of T_CONN_IND's forwared to the API. The
T_CONN_RES for the aborted connection could encounter a TS_IDLE endpoint
and cause the above problem.

THE SOLUTION (?):

Only do the above assignment when it would not result in setting
inp_tstate or better yet JUST NOT DO THE ASSIGNMENT AT ALL.  I can't think of
any rationale for the ERROR_ACK due to an out of state primitive changing
the state of a transport endpoint!  (In fact,  the T_CONN_RES primitive
is the only one with such an assignment!)

OTHER SIDE ISSUES (uncovered as a result of the investigation):

Aborted connections do not generate T_DISCON_IND's with the sequence
number that matches the T_CONN_IND sequence number.  They just silent
discard the pcb/tcb.  Such an indication would allow the API to discard
T_CONN_IND's when a T_DISCON_IND with a matching sequence number exists.

The sequence number in the T_CONN_IND is actually a pointer to the tcb
structure.  It is possible that a connection could be aborted and its
space re-assigned to the SAME listening endpoint resulting in multiple
T_CONN_IND's with the same sequence number!  The code really should use
a cycling sequnce number.

A queue reference in the T_CONN_RES could result in kernel panics when the
kernel uses it as a queue pointer to test for queue validity!  A better way
of testing queue reference validity would be to thread the list of TCP
pcb's and seeing if a tcb with the queue exists on the list!

1). Has anyone seen the above problem?

2). Does anyone have any comments on the solution?

3). Does anyone know why the state change to BADSTATE exists?

Mike Marciniszyn
Maintenance Subsystem Development
Unisys Tredyffrin
DOMAIN: mike@tredysvr.tredydev.unisys.com  UUCP: tredysvr!mike

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 21:06:00 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing using RIP

In article <9108271304.aa07864@36sig.taegu-emh1.army.mil> MITRE-TAEGU@TAEGU-EMH1.ARMY.MIL writes:
>RE:  RIP routing algorithm - "routed" implementation 
>
>The RIP algorithm is based on selecting the route with the least number of
>hops.  However, how does it select between routes with an equal number of hops?

This points out one of the weaknesses of RIP's course metrics.

In most of the implementations I've seen, it is somewhat random.  From the
basic algorithm of only accepting new routes which have a SMALLER metric
than one already in the routing table, I'd guess that most implementations
would take the first seen equal cost route.  If the router supports multi-
path forwarding, then multiple equal cost routes can be kept and used for
forwarding.

Art

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 91 22:04:25 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: problems using MACH-NFS

In <1991Sep2.105238.15359@inesc.pt> werner@inesc.pt (Werner Vogels) writes:

>We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and
>experience on all these machines the same problem with using NFS. When
>we mount a disk from one of our sparcstations, everything runs fine until
>a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes
>imeditaly with sending these 8k (fragmented at IP level). We can see data
>traveling the network but the i386 will not kick the packet up to user
>level. Not having the kernel code or objects we can not do any further
>debugging. Does any body has any clues?

Sounds like the Ethernet card and/or the Ethernet driver in the i386
machines is choking on the sudden influx of data from the network.
This is common if you have a fair-to-poor Ethernet card, and about
the only thing to be done is to cut back on the "rsize" parameter in
the mount request to a more conservative value, like 2048 or 1024
bytes.  You might have some kind of statistic to verify this; if
Mach has 'netstat', 'netstat -i' should show you input errors if it's
a driver problem.  I expect it won't show up there, and that it's
the card.

Rob T
--
Rob Thurlow, thurlow@convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 04:56:41 GMT
From:      torek@elf.ee.lbl.gov (Chris Torek)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
>... The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across.  Taking
>account of all hw protocol overheads it can sustain between 5-6 MB per
>second.

(I know nothing of the ISA bus and little of PC architecture in
general, and will just take the above for granted.)  Given this bus
speed, you can get 1.25 MB/s out of your Ethernet, although you may
have to be careful: if you use the bus twice for each 16-bit word
sent---and it is easy to do this in some architectures---you will take
2.5 MB/s out of your 5 or 6.  This leaves the other half of the bus
bandwidth for whatever else goes on.  (If you touch it more than twice
you will get into trouble---anything like that implies that there are
other devices doing the same.)  Ideally, you will touch it only once.

>32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface
>between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet).

Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 08:18:21 GMT
From:      dr754312%cs.nthu.edu.tw@CUNYVM.CUNY.EDU (Ching-ho Huang)
To:        comp.protocols.tcp-ip
Subject:   Re:  Finger server as a requirement for all Internet hosts

You may change the access right of the FINGER file.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 14:10:19 GMT
From:      sfancher@spdcc.COM (Steven Fancher)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   AIX 3.1 ARP Question


     A question about AIX 3.1 ARP implementation:

      According to RFC826  a node should update its ARP cache if it sees a
      request or a reply who's IP address matches an entry in its cache.
      i.e. A, B, and C are nodes on a network. A and B have ARP cache entrys
      for C. C's hardware address changes. A broadcasts a request for C's
      new hardware address and C sends a reply. A updates his cache.
      B also gets both the broadcast request and the reply. B should update
      its cache entry for both A and C (B saw the request containing A's
      hardware address and the reply containing C's hardware address).

      On our network, tests show that A and C do everything right, but B's
      cache does not get updated. I have looked at the ARP code and it seems
      that it should work. 

      Does AIX 3.1 IP code implement RFC 826 completely. Should this be
      working for us or did they punt on this part of the protocol?

      Does anyone know the answer to this? I would greatly appreciate any
      replies. Please mail any info to 'sfancher@clam.com'. I will post a 
      summary if there is interest.

      Thanks,

      Steven Fancher | CLaM Associates | 25 First Street | Cambridge, MA
      +1 617 621 2542| sfancher@clam.com | No Disclaimer Applies

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 15:39:23 GMT
From:      bill@bilver.uucp (Bill Vermillion)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Sep1.200028.16596@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:

>    Amazing facts: the maximum bandwidth of the MCA bus when running at full
>    tilt in 32 bit mode is under 40MB/s; to have 100MB/s of transfer rate
>    *to memory* would require dozens of megabytes of requires hundreds of MB
>    of 4-way interleaved 20-30ns RAM; to be able to consistently get 20MB/s
>    on a TCP/IP link would require, assuming an overhead of 4 instructions
>    per byte passed thru (wildly optimistic, just consider checksumming), a
>    80Mhz CPU.

That contradicts what I have read about the MCA bus.  The 40MB/s is for
streaming data mode (burst mode is at 20MB/s).

However the MCA bus support data-multiplexing, that uses the address lines
as data to give a 64 bit wide transfer.   It's not limited to using just
the data lines.

My information is from a book called "The Micro Channel Architecture
Handbook" written  by Chet Heath (one of the MCA designers, so there is a
vested interest there).

This books shows that when multiplexing using the streaming data mode the
transfer rate is 80MB/sec.  (NCR is claiming that speed on their new MCA
bus-based multi-processor '486 boxes).

One paragraph (paraphrased to conserve space) notes that the bus cycle time
is 100ns in these specifications, but the bus specs would allow a 50ns
cycle time.   At that time the throughput could approach 160MB/sec.
There is nothing to note that this has been done, though they did note that
the "model 70 E80 systems implement at 62.5 ns cycle".




-- 
Bill Vermillion - UUCP: ...!tarpit!bilver!bill
                      : bill@bilver.UUCP

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 16:34:30 GMT
From:      se@IKP.Uni-Koeln.DE (Stefan Esser)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

FTPing large files between institutes (each of them connected to the 
universities backbone net through a IGS) I get up to 1MB/s depending on 
the sending and receiving machines.

While the receive buffers of 386s and Sun SLCs are easily overrun when 
receiving more than a few packets, resulting in transfer speeds 
of 10KB/s to 200KB/s, modern workstations (eg. DEC 5000/200, Sparc 2) 
are well capable of sending and receiving Megabytes at 1MB/s.

My measurements were done between Suns and DECs local and over 
two IGS routers. The test file was about 4MB long.
It was 'preloaded' into the buffer cache and then sent into '/dev/null'.
Speeds between machines on the same cable or connected through 
2 CISCOs always came out at about 1MB/s without much difference.
Seems, the CISCO boxes are *really* fast.

A way to 'benchmark' the TCP overhead is to ftp a long file from the 
buffer cache into '/dev/null' through the 'local loopback' (127.0.0.1).
Then the local system has to send and receive the data at the same time,
doubling the overhead. Values seen on fast 386s are in the range 
of 200KB/s, while the Sun2 or DEC 5000/200 go well beyond 1MB/s.

You probably can't get more than *twice* the performance measured 
this way with any network controller on your system.

Stefan
-- 
 Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
 se@IKP.Uni-Koeln.DE                                           [134.95.192.50]

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 16:44:42 GMT
From:      ejackson%sedofis%sed@CUNYVM.CUNY.EDU
To:        comp.protocols.tcp-ip
Subject:   NONE


SEND INFO.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 17:13:10 GMT
From:      rbrickey@BBN.COM (Ron Brickey)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please unsubscribe me.

---
ron

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 17:25:24 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   high-level network analysis tools needed

I have a need for a high-level network (TCP) analyzer.
That is, I want to measure transactions instead of packets.
A transaction might be several packets which establish the connection,
transfer the data, and acknowledgement of the data.

The goal is to characterize an existing network, and gain a better
understanding of the dynamics of a network. 

If I can purchase a product that does this, fine. If not, I may have
to build such a tool.

I have two questions:

Does anyone know of any commercial product that has this ability? 

If not, do you think such a monitor can be implemented in software on
a fast Unix box (perhaps using nnstat as a starting point)?


Please reply by E-Mail.
--
Bruce G. Barnett	barnett@crdgw1.ge.com	uunet!crdgw1!barnett

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 19:35:26 GMT
From:      dcarr@hobbit.gandalf.ca (Dave Carr)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In <2431@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:

>I should note that PPP is basically misdesigned because the latest crop
>of Ethernet chips tend to support HDLC modes while the latest crop of
>Serial HDLC chips tend to support Ethernet modes.  As a consequence if
>SLITHERNET is used for wide area networking while ethernet is used for
>local area networking, respinning ethernet software for wan uses and
>respinning ethernet interfaces for wan interfaces is relatively
>straightforward as well as vice versa.  

Yes, and anyone who has an WAN driver for an 82596, I would like to hear from
(and so would Intel I imagine).  Given the errata, I doubt it would SLITHER !

And also I will quote a Zilog engineer "You're not going to use the USC in Ethernet
mode ?  (long pause)  Are you?"...  Given the FIFO bugs, (albeit corrected with the
latest step of the week), I would stick to HDLC on the USC, and Ethernet on the 
82596.
-- 
Dave Carr               | dcarr@donut.gandalf.ca | If you don't know where  
Gandalf Data Limited    | TEL (613) 723-6500     | you are going, you will
Nepean, Ontario, Canada | FAX (613) 226-1717     | never get there.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 91 20:49:37 GMT
From:      jonson@NISC.SRI.COM (1Lt Matthew W. Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip"

<Lars Poulsen writes>
> Subject: TCP-IP@NIC.DDN.MIL vs USENET's "comp.protocols.tcp-ip"
> 
> I originally submitted the message just before this one to
> TCP-IP@NIC.DDN.MIL, and it has not been returned as undeliverable, but
> after 24 hours, it has not shown up on comp.protocols.tcp-ip yet.

The new host of the mailing list is NISC.SRI.COM.  I haven't noticed
any real improvement, I routinely have expected my contributions to
the list to take a day to show up on it.
 
> It appears that the mailing list has become separated from the newsgroup,
> perhaps intentionally. If so, when did that happen ?
> 
> Or is NIC in bad shape ?

yes :-)


/matt

-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 01:10:14 GMT
From:      nwnetman@U.WASHINGTON.EDU (Jonathan Kochmer)
To:        comp.protocols.tcp-ip
Subject:   Q: Master List of TELNET / FTP programs?


Has anyone compiled a list of *all* TELNET/FTP programs for *all* 
operating systems?  In the best of all possible worlds, I would like 
a list including the following information:

     - name of the package;
     - operating system under which it runs;
     - in the case of freeware / shareware, definitive FTP
       source(s), directory, and filename, or user group(s)
       from which it can be obtained;
     - in the case of commercial packages, company's name,
       postal and e-mail address, and package's cost;
     - nature of user interface (e.g., completely command
       driven, partially or completely menu driven, etc.);
     - quality of online and written documentation;
     - if there are multiple packages available for a given 
       OS, qualitiative comparisons on ease of use and
       installation.

If such a list does not yet exist, it would probably be "A Good 
Thing" to create and distribute, especially as more sites with 
minimal technical support and a wide diversity of OS's start hooking 
up to the Internet (e.g., k-12 schools, sites in Eastern European 
and less-industrialized nations, etc.).

If, within a week, it appears that there is no such list, I will 
post a second request for information in which I will list all the 
packages of which I am aware, and will solicit information for other 
packages not listed, with an eye towards creating such a document.

Many thanks in advance!

Jonathan Kochmer
University Computing Services
University of Washington

nwnetman@milton.u.washington.edu

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 03:15:08 GMT
From:      ed@weir.pa.dec.com (Ed Gould)
To:        comp.os.mach,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: problems using MACH-NFS

> We installed MACH 2.6(Mt Xinu) on a few i386 boxes (compaq, intel) and
> experience on all these machines the same problem with using NFS. When
> we mount a disk from one of our sparcstations, everything runs fine until
> a nfs.read request is done. The i386 asks for 8192 bytes and the ss respondes
> imeditaly with sending these 8k (fragmented at IP level). We can see data
> traveling the network but the i386 will not kick the packet up to user
> level. Not having the kernel code or objects we can not do any further
> debugging. Does any body has any clues?

This sounds like you're using an Ethernet interface in the 386 box that
can't receive enough back-to-back packets without dropping at least one
to reassemble the 8KB datagram.  Some interfaces - notably the older
3Com (3c501) - don't have enough buffering to receive more than two
consecutive packets.  8KB datagrams typically get split into seven
packets for transmission.

The solution to this problem is to specify smaller read and write sizes
(read sizes for remote filesystems, write sizes for exported
filesystems) in fstab (or on the mount command line).  Try adding

	rsize=2048,wsize=2048

to the options field of the appropriate fstab entries.  (I believe that
only rsize needs to be specified on the 386 end; wsize should be set on
any machines that mount filesystems *from* the machine with an
inadequate Ethernet card.)

---
Ed Gould			Digital Equipment Corporation
ed@pa.dec.com			Network Systems Laboratory
+1 415 688 1309			505 Hamilton Ave, Palo Alto, CA  94301

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 04:26:25 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards
Subject:   Ethernet packets/second (was Re: Need help selecting ...)

In article <1991Sep2.152344.14037@aber.ac.uk>
pcg@aber.ac.uk (Piercarlo Grandi) writes:
 > dave@pmafire.inel.gov (Dave Remien) writes:
 > 
 > > In article <1991Sep1.195029.16374@aber.ac.uk>
 > > pcg@aber.ac.uk (Piercarlo Grandi) writes:
 > > >Probably what you mean is that you will have a separate Ethernet cable
 > > >per computer. This of course means that each machine would have its own
 > > >0.8MB/s Ethernet dedicated to itself. The problem is that I doubt very
 > > >much that this would buy you anything at all, as I would expect the
 > > >CISCO router not to be able to sustain more than 0.8MB/s aggregate
 > > >anyhow, as routers are normally not designed to sustain the maximum
 > > >combined bandwidth of all the Ethernets they link. Does anybody know for
 > > >sure what is the maximum thruput of a CISCO router?
 
 > > Ours forwards at about 15000 packets per second, and routes at about
 > > 2000 packet/sec. The newer ones are supposed to about double that.
 > 
 > Amazing facts #2! Shannon is in a jolly good mood if he gives so many
 > dispensations these days:
 > 
 > > Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
 > > will go.
 > 

Stop right there!  15000 packets/second is (approx) the Ethernet maximum.  For
those who want the math:

	Minimum frame length = 64 bits of preamble		64 bits
				6 octet destination address	48 bits
				6 octet source address		48 bits
				2 octet type			16 bits
			       46 octet data		       368 bits
				4 octet FCS			32 bits
							-----------------
							       576 bits

The time to transmit this frame at 10 Mbit/s is 57.6 usec.  Add to that the
minimal interframe spacing of 9.6 usec and you can spit a frame out every
67.2 usec or 14880 (almost 14881) frames per second -- assuming one
station is doing all the transmitting.

cisco playes the specsmanship game of being able to handle this theoretical
maximum.  They are not the only ones who try to play this game.  (Note that
when playing this game the payload maximum is 14880 pps * 46 bytes/p = 684480
bytes/second.  That's a lot of work for a bit more that 1/2 Mbyte/s.)

Using the maximum ethernet frame length the numbers look like 1220.8 usec per
frame.  When adding the 9.6 usec interframe spacing requirement the maximum
frames/second (large frames) is 812 frames/second.  The payload in this case
increases to 1.218 Mbytes/s.  Typical networking -- the best throughput occurs
when the processor is doing the least amount of work :-)

// marc
-- 
marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 04:44:03 GMT
From:      megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Need documentation or references for AFS and RFS

Is there any available documentation on the AFS (Andrew File System)
and RFS (??? Remote File System) remote file system protocols?
Any pointers, either online or paper documentation, would be appreciated.
I would like to add these references to my masters essay.  In particular,
I'd like to know if it would be possible to get a complete specification
that would allow one to implement these protocols in a new (non-Unix)
environment.

Also, if there are any other remote file system protocols that look like
contenders for a standard, I'd like to know about them.
I'm particularly interested in protocols that work over the Internet.
(Of course, I know about NFS, FTP, TFTP; and a simple `grep' through the
RFC index didn't bring up anything about AFS or RFS)

Any info is most welcomed.

-Marc
-- 
Marc E. Gauthier   megauthier@watcgl.waterloo.edu   University of Waterloo
		   129.97.140.64		    885-1211 x3469 or x4548

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 14:27:19 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        news.groups,bit.listserv.biglan,comp.dcom.lans,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,rec.radio.amateur.packet
Subject:   CFD: comp.protocols.tcp-ip.ka9q

[ Follow-ups directed to news.groups and comp.protocols.misc (for those not
  willing to wade through news.groups) ]

This is an official Request For Discussion for the creation of the
new newsgroup "comp.protocols.tcp-ip.ka9q"

Proposed Charter:

Comp.protocols.tcp-ip.ka9q would be for discussion of the configuration,
modification, extention and administration of the KA9Q NOS IP routing
software.  This group is intended to cover both the "old NET" version and
the newer "NOS" version, as well as the various platforms it has been
ported to.

While there are existing groups which cover various elements of the KA9Q
package, it is the intention of this group, to gather together the vast
net-wide knowledge base into one area.  Currently discussions about ka9q
are carried out in rec.radio.amateur.packet, comp.protocols.tcp-ip[.ibmpc],
comp.protocols.ppp as well as several mailing lists.

I would hope that this concentration of readers would aid in adding some
structure and coordination to the development of the package, as there are
currently many flavours of the system derived from varying previous versions.

Why "comp.protocols.tcp-ip.ka9q"?

ka9q's strength (IMHO) is its IP routing capabilities and secondly, its
built in TCP server support (SMTP, POP, finger, etc).  These strengths
are applicable to many tcp-ip environments.  While the software's roots
are based in amateur packet radio, its use is spreading rapidly into the
IP routing/briding/serving arena.  rumor has it that this software is the
base of the Telebit Netblazer's OS.

ka9q supports the following protocols:

SLIP
PPP
SMTP
POP
bootp
RIP
ARP
FTP
telnet
ICMP

plus others

Discussion will end at 11:59 P.M. on 27 September 1991.

i will running the vote unless anyone has any objections.

-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 16:01:36 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip
Subject:   gethostbyaddr() in ISC TCP/IP 1.1.2

The TCP/IP Guide fro ISC has a man page for this call that lists its syntax as:
	struct hostent *gethostbyaddr(addr, len, type)
	char *addr
	int   len, type

If you use gethostbyname() it returns the same hostent structure.  This
structure has two fields in it that I thought related to what
gethostbyaddr() is asking for: h_addrtype and h_length.  Are the "len"
and "type" parameters required in gethostbyaddr() the same as h_lenght
and h_addrtype in the hostent structure?  IE, for IP internet addresses
should length be 4 and type be AF_INET?  I'm pretty sure of the latter,
but when I use either 4 or the length of the *addr in the length
parameter I still don't get a valid reply from the nameserver.

Michael J. Hammel        | mjhammel@{Kepler|socrates|feynman}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet 
"Jesus Saves!  But Gretzky gets the rebound!  He shoots!  HE SCORES!"

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 17:18:40 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

martillo@crackers.clearpoint.com (Martillo) writes:


>                              SLITHERNET:  A Proposal
>                          for Using Moderate-To-High-Speed
>                        Synchronous Serial Connections as a
>                             LAN-like Networking Medium

Ah yes, Yet Another Serial Protocol (YASP).  Pretty soon its going to
be like IBM in the 60's and early 70's when they had about 100
different variations of bisync, all mutually incompatible.

-- 
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 17:38:20 GMT
From:      sean@fiamass.ie (Sean Mc Grath)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please unsubscribe sean@fiamass.ie

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 18:21:49 GMT
From:      garath@ais.org (Belgarath)
To:        comp.protocols.tcp-ip
Subject:   Re: gethostbyaddr() in ISC TCP/IP 1.1.2

mjhammel@Kepler.dell.com (Michael J. Hammel) writes:

>and h_addrtype in the hostent structure?  IE, for IP internet addresses
>should length be 4 and type be AF_INET?  I'm pretty sure of the latter,
>but when I use either 4 or the length of the *addr in the length
>parameter I still don't get a valid reply from the nameserver.

char *query_ip_number(socket)
int socket;
{
	struct sockaddr_in PeerInfo;
	int len = sizeof PeerInfo;
	if(getpeername(socket, (struct sockaddr *)&PeerInfo, &len) == -1)
			stop("getpeername()");
	return inet_ntoa(PeerInfo.sin_addr);
}

char *query_ip_name(socket)
int socket;
{
	long test = inet_addr(query_ip_number(socket));
	struct hostent *HostInfo = gethostbyaddr(&test, 4, AF_INET);
	return HostInfo->h_name;
}

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 18:22:22 GMT
From:      nwnetman@U.WASHINGTON.EDU (Jonathan Kochmer)
To:        comp.protocols.tcp-ip
Subject:   RE: Q: Master List of All TELNET/FTP Packages?


In an eralier posting, I asked:

>> Has anyone compiled a list of *all* TELNET/FTP programs for *all*
>> operating systems?

Billy Barron replied:

> Yes, see NETINFO:VENDORS-GUIDE.DOC on NIC.DDN.MIL via anonymous FTP.

It's quite an impressive document; some 150 pages long, and chock full
of exactly the kind of information I was looking for.

Jonathan Kochmer
University Computing Services
University of Washington
Seattle, WA

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 18:27:04 GMT
From:      garath@ais.org (Belgarath)
To:        comp.protocols.tcp-ip
Subject:   Problems with multiple connections


I have a structure defined to hold the people who connect with the
following format:

struct caller_info {
	int socket;             /* Will hold the socket id */
	char *nick;             /* Will hold the nickname of the person */
	char *host;             /* Will hold the string name of the host */
	char *ip;		/* Will hold the numeric id of the host */
} User[MAX_USERS];

	As it currently stands, I can only accept one connection at a time.
If one is sitting at a read() call, the other one stops right after the
connected message until the first connection closes, then the second moves
on.  That is problem number 1.  I want multiple people obviously.
	My next problem is reading info.  I don't know what to put for the
length it should read.  If I put 10 for instance, and they only put 4
characters, then it'll screw up for the next time they put something as
it'll still have the other 6.  Is that why you use the loop thing that was
in the nroff you sent me?  If they only type 4 chars though, then hit
return, where will those next 6 bytes come from?  I think I need to use
select() calls or an fcntl() with FIONREAD or something, but am unsure of
how to use it.
	After that's fixed, I need to be able to tell *when* someone just
typed something so that I can send it to the other people.
	Right now I basically have:

	while(1) {
		char buff[10];
		NewFD = accept();
		write() some stuff.
		read(NewFD, &buff, sizeof(buff));
		write() another.
		close(NewFD);
	}

	Any help would be greatly appreciated.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 19:38:35 GMT
From:      katz@celtics.ma30.bull.com (katz)
To:        comp.protocols.tcp-ip
Subject:   ORACLE SQL*NET tcp port numbers.


I would like to have some information about the underlying communications
 of two ORACLE packages communicating with the SQL*NET protocol over tcp/ip. 

1). Is the communication interface of ORACLE use sockets ?
2). How is established the tcp port number between the two packages?

Thank you for a quick reply. 
--
== Eddie Katz                          BULL HN Information Systems  ==
== (508) 294 2586 (FAX 294 2583)       300, Concord Rd              ==
== MS - MA30 836A                      Billerica, MA 01821          ==
== Edouard.Katz@mips2.ma30.bull.com                                 ==

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 91 19:42:58 GMT
From:      ddrg@hobbit.gandalf.ca (Duncan Glendinning)
To:        comp.protocols.tcp-ip
Subject:   Re: Decnet IV Implementation

In <9108271757.AA13434@achilles.coral.com> ken@achilles.coral.com (Ken Benstead) writes:

>Hello World,
> 
>   I known this is probably not the "right place" to ask this question 
>but I'm not sure where "right place" would be, so here goes anyway.  Does
>anyone know of a Decnet IV router implementation suitable for porting 
>(ie includes source code)?  A public domain implementation would be
>nice but any information (including commercial packages) would be much
>appreciated.  Please E-Mail reponses directly to me.
 
>Thanks in anticipation,
>Ken Benstead
>kbenstead@coral.com

I'd also appreciate hearing about public domain implementations of
Decnet Phase IV.
-- 
Duncan Glendinning         CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 03:31:22 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IRC client for MSDOS?

I found one, but it used a local dialup to reach an irc server.  Does
a package exist that uses, say, packet drivers?  Looking for a decent
irc client.

Eric
-- 
Eric Sheppard      Georgia Tech    |   "Of course the US Constitution isn't
Atlanta, GA                        | perfect; but it's a lot better than what
ARPA: ce1zzes@prism.gatech.edu     |             we have now." -Unknown
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ce1zzes

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 12:57:10 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   truly silly route, UC london to UC dublin


given the distance from london to dublin, and the fact that there is 2
Mbps IP to belfast, this is a truly silly route:

traceroute to 137.43.1.4 (137.43.1.4), 30 hops max, 40 byte packets
 1  cisco (128.16.6.150)  0 ms  10 ms  10 ms
 2  gateway (128.16.3.3)  20 ms  30 ms  30 ms
 3  192.80.7.1 (192.80.7.1)  30 ms  30 ms  30 ms
 4  192.80.6.2 (192.80.6.2)  200 ms  210 ms  220 ms
 5  nss.sura.net (192.80.214.254)  200 ms  230 ms  200 ms
 6  College_Park.MD.NSS.NSF.NET (129.140.9.77)  220 ms 320 ms  210 ms
 7  Ithaca.NY.NSS.NSF.NET (129.140.74.9)  280 ms  290 ms  250 ms
 8  Ithaca.NY.NSS.NSF.NET (129.140.10.79)  270 ms  340 ms  280 ms
 9  Ithaca.NY.NSS.NSF.NET (129.140.10.130)  460 ms  370 ms  530 ms
10  gate-cern.easi.net (192.70.246.2)  660 ms  690 ms  1120 ms
11  ext-gw-01-e.cern.ch (192.65.185.129)  340 ms  360 ms
12  ibr-router.surfnet.nl (192.87.4.9)  520 ms  560 ms  440 ms
13  hef-router.nikhef.nl (192.87.4.21)  400 ms  380 ms  460 ms
14  192.16.192.233 (192.16.192.233)  750 ms  750 ms  980 ms
15  * * *

i mean really, are we trying to cover as many continents as
poss...ayvbe we should route it via kaist & CSIRO for good measure:-)

j.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 14:16:55 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Changing passwd on remote system.

I've got a problem with networking that someone may be interested in.
I've got a sun server and server 386 systems running unix (System V R4).
Unfortunately, AT+T didn't include the passwd functionality in NIS in
SVR4 so I'm having to come up with a different way of managing
passwords.  I'd like everyone to be able to log into any computer on the
network with the same loginid and same password.  So, what I'd like to
do is write a little program that will allow the user to go through the
network and change their passwd that is located on the server.  Then the
server will propagate the passwd file via NIS.  Does anyone have ideas
on how I can do this?  I'd really like to avoid writing a passwd program
and would just like to call passwd on the remote system.  But there are
authentication problems and I would prefer that users didn't log onto
the server at all.  Any ideas on how to best tackle this problem?

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 14:55:33 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        news.announce.newgroups,news.groups,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   RFD:  comp.protocols.tcp-ip.ka9q

This is an official Request For Discussion for the creation of the
new newsgroup "comp.protocols.tcp-ip.ka9q"

Proposed Charter:

Comp.protocols.tcp-ip.ka9q would be for discussion of the configuration,
modification, extention and administration of the KA9Q NOS IP routing
software.  This group is intended to cover both the "old NET" version and
the newer "NOS" version, as well as the various platforms it has been
ported to.

While there are existing groups which cover various elements of the KA9Q
package, it is the intention of this group, to gather together the vast
net-wide knowledge base into one area.  Currently discussions about ka9q
are carried out in rec.radio.amateur.packet, comp.protocols.tcp-ip[.ibmpc],
comp.protocols.ppp as well as several mailing lists.

I would hope that this concentration of readers would aid in adding some
structure and coordination to the development of the package, as there are
currently many flavours of the system derived from varying previous versions.

Why "comp.protocols.tcp-ip.ka9q"?

ka9q's strength (IMHO) is its IP routing capabilities and secondly, its
built in TCP server support (SMTP, POP, finger, etc).  These strengths
are applicable to many tcp-ip environments.  While the software's roots
are based in amateur packet radio, its use is spreading rapidly into the
IP routing/briding/serving arena.  rumor has it that this software is the
base of the Telebit Netblazer's OS.

ka9q supports the following protocols:

SLIP
PPP
SMTP
POP
bootp
RIP
ARP
FTP
telnet
ICMP

plus others

Discussion will end at 11:59 P.M. on 27 September 1991.

i will running the vote unless anyone has any objections.
-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 16:54:59 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: Changing passwd on remote system.

In article <1991Sep5.141655.15426@homecare.COM> jessea@homecare.COM () writes:
>network with the same loginid and same password.  So, what I'd like to
>do is write a little program that will allow the user to go through the
>network and change their passwd that is located on the server.  Then the
>server will propagate the passwd file via NIS.  Does anyone have ideas
>on how I can do this?  I'd really like to avoid writing a passwd program
>and would just like to call passwd on the remote system.  But there are
>authentication problems and I would prefer that users didn't log onto
>the server at all.  Any ideas on how to best tackle this problem?

There is an expect script that will do this that comes with the expect
distribution.

It's designed for a single user who wants to keep multiple accounts in
sync, where some computers have separate NIS, or don't even use NIS.
Your case would just be a very simple use of it.  Your users can call
it directly as:

	passmass server

where 'server' is the name of your server.  They will then be prompted
for the old and new passwords.

Or you can bury that in a script (called 'yppassword', for example).
Or edit passmass so that it has a default server, and then change it's
name to yppassword.

Don

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 17:09:14 GMT
From:      TANNERC@CU18.CRL.AECL.CA
To:        comp.protocols.tcp-ip
Subject:   udp on Internet Connection

Hi All

We are just about to get our connection to the Internet. We are planning
to install a router of our own (CISCO) which we will use to keep
unwanted traffic from our own network (and vica versa). I am wondering
what functions we will loose (or what problems we will cause ourselves)
if we prevent any UDP traffic between our local network and the
Internet.

Thanks in advance for your advice.

Chris
--
Chris Tanner                          Tannerc@CU18.CRL.AECL.CA
AECL Research
Chalk River Ont.
Canada K0J 1J0

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 18:07:58 GMT
From:      MRC@Panda.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Nippon Telephone & Telegraph change of address

Maximum distribution requested.

I have been asked to get the word out on this to any/all e-mail correspondents
with personnel at Nippon Telephone and Telegraph in Japan.

--- Begin forwarded message --

NTT is now providing domain name service directly to the full Internet and is
retiring the CSnet connection.

Please send your messages to NTT users using the syntax
	user@ntt-20.ntt.jp
and not to
	user%ntt-20.ntt.jp@relay.cs.net

Any messages addressed to addresses of the form
	user%host.ntt.jp@relay.cs.net
will be rejected after 9/15.

Please check any mailing lists under your control and correct as necessary.

If you have any questions on this, please contact:
	nic@nttta.ntt.jp

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 18:08:30 GMT
From:      sma@rocksanne.wrc.xerox.com (Susie Armstrong)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP FIN and window

Fred Bohle mentions that the TCP on Xerox boxes will not send
a FIN into a zero window.  If the Xerox boxes you refer to
are the 8000 or 6085 series of machines, then the TCP
implementation was written by me, and perhaps I can explain
the rationale behind not sending a FIN into a zero window.

FINs, like SYNs, are client control information, and must be
sent reliably; that is, they consume sequence numbers.  As
such, even though they occupy no "physical space" in the
segment data space, I subjected them to the same rules as
"physical data".  If a window is closed, I concluded that the
remote end really meant it - it wants no more client data,
including FINs.  Of course, per protocol, I will send URGs and
RSTs into a closed window.

Note that though I will not send a FIN into a closed window,
I will process a FIN that I receive into my closed window (my
window reflects buffering for "physical data", and FINs don't
consume buffers, so processing that FIN is easy to do).  This
reflects my belief in that old transport implementation rule
"be conservative about what you send, be liberal about what
you accept".

Having different windowing rules for FINs than for other
client data (i.e. SYNs and physical data) seems conceptually
wrong.  However, I do agree that the specification is not
explicit on this point, and sending the FIN into a closed
window (and having it accepted) does not harm the integrity
of the data or of the closing handshake.

This implementation was done pre-host-requirements-rfc -
perhaps that document has some more clues on the commonly
accepted treatment of FINs in general, if not on this case
specifically.

Cheers,
    Susie Armstrong
    Xerox Webster Research Center
    armstrong.wbst128@xerox.com

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 91 22:47:31 GMT
From:      martin@unislc.uucp (Martin Cryer)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:
>
>> We are trying to configure an SCO Unix system running some type of
>> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
>> is to get up to _6_ Megabits/Sec.
>
>Well, nearly any modern Ethernet card will deliver 6 Megabits per second.
>After all it's only around 600KB/s. SCO's TCP protocol stack will most
>probably not be able to keep up with the card though.
>
>> We realize that we need EISA bus machines with 32-bit Ethernet cards to do
>> this.
>
>Why ever? The 16 bit ISA bus runs at 8Mhz and transfers 16 bit across.

Some run at 10 as will some controllers, you may be able to match
a pair that give that xtra bit....

>Taking account of all hw protocol overheads it can sustain between 5-6 MB per
>second. Here you are proposing to load it with just 600KB/s, which is one
>tenth of its top capacity. Think of this: my VGA card will, during continuous
>graphics operation, sustain 2MB/s over the ISA bus, and my SCSI controller
>will get 1.4MB/s sustained from a SCSI disk.
>

But while you are using the bus...

EISA offers 32bit DMA so you can DMA into user space directly, whatever
its address. EISA Bus Master DMA also holds the bus for a shorter time
(upto 33MHz) and being Bus Master reduces the cpu involvement...
(I know PCAT Bus Master boards exist, but they are finicky on memory
timings).

>32 bit EISA Ethernet cards are an expensive joke, as is any "turbo" interface
>between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit one (Ethernet).

Cuts response time to the controller requests though and gives
better burst speed to the controller. Expense is probably releated to
current sales volumes. Advent of Intel BMIC usage will bring
costs down...

>
>    Same goes for EISA SCSI disk controllers (the most expensive SCSI disks
>    top out at 4MB/s, and most cannot do more more than 1.5MB/s off the
>    platter). In practice EISA is only needed for very high speed graphics
>    (good luck with that) and for disk arrays, or, theoretically, for very
>    high bandwidth tapes.

Mmm, well with the new Seagate 1.25GB disks that spin at 5400+ rpm, ~3.0MBytes/s
is possible, and with more than one device 5.0 MBytes/s is not
impossible.

Even if the sustained xfer rate is not this, it allows quicker reponse to
simultaneous 2 device requests and reduces bus contention. This all adds
upto better system throughput.

Also, modern drives have caches which allow better than 1.5MByte/s xfers
for < cache size xfers.

>
>    The real benefits of EISA, for most people, are not in bandwidth, but
>    in configurability and interrupt sharing and multiple mastering, where
>    the ISA bus is badly misdesigned.

This is indeed true, but for power users everything helps. EISA also means
up to 16 slots on some boards...

EISA Bus also allows more upmarket systems to be designed which still
allow those systems to use standard ISA boards for less performance
critical uses - providing a more expanded product offering.

EISA gives actual bus timings as a standard, as opposed to "if-it-works-
with-an-IBM-PCAT-then-it-must-be-ok" standards.

>
>> Another important detail is that each computer will be talking over a
>> Cisco router with one ethernet card per computer.
>
>Note that you need an Ethernet card per computer anyhow :-).
>
>Probably what you mean is that you will have a separate Ethernet cable per
>computer. This of course means that each machine would have its own 0.8MB/s
>Ethernet dedicated to itself. The problem is that I doubt very much that
>this would buy you anything at all, as I would expect the CISCO router not
>to be able to sustain more than 0.8MB/s aggregate anyhow, as routers are
>normally not designed to sustain the maximum combined bandwidth of all the
>Ethernets they link. Does anybody know for sure what is the maximum thruput
>of a CISCO router?
>
>I expect that in practice having a star configuration with a router in the
>middle and an Ethernet to each machine will probably buy you nothing at all,
>except having a single active failure point.
>
>> This way we completely eliminate packet collisions.
>
>This is probably completely unnecessary. Collisions are very rarely a
>problem, the Ethernet will in practice share out its capacity between
>machines in only slightly less than linear fashion, if packet sizes are not
>too small.
>
>If you really want for some funny reason a star configuration, with an
>active hub, and no collisions and guaranteed point-to-point capacity,
>consider seriously getting a Token Ring.  At least Token Ring active hubs
>are designed for this task, and not as routers, and tend to be fairly fail
>safe too.
>
>> They also told us about their ES3210 card, which they claim can
>> operate at _13_ Megabits/Sec. I thought that the cable can't operate
>> faster than 10 Megabits/Sec. Am I missing something?
>
>Well, they are telling you nice numbers out of thin air.
>
>> How do I get real numbers that will tell me what to expect in the field?
>
>Toss a coin... :-)
>
>> I don't know how obvious my lack of network expertise is,
>
>Very obvious. :-). But at least you know. Some other poster who also replied
>to your article is not in a much better position than yourself, but does not
>know. :-)
>
>> but if you see any questions that I'm not asking, I need to know that
>> also. I'm sure I'm not asking everything I need to know.
>
>Well, now that I have answered your questions, let's tell you something more
>useful.
>
>First of all, the good news: as I have said almost any modern Ethernet card
>will deliver substantially all of the Ethernet bandwidth, and this bandwidth
>is at worst one fifth of the ISA bus bandwidth, so you don't need any EISA
>machine.  Collisions will be in practice not a problem. You probably don't

Collisions may be a problem. You have to get the DATA from somewhere and
put it somewhere too, unless all data is RAM to RAM only. The longer you
have the Bus the less time there is for disk i/o and handling other ISA
xfers you need. EISA will help reduce this risk. An Ethernet card
that handles the kind of bandwidth you want is probably dumb in the
sense that no protocol handling at link or IP layers and above is
handled out on the board, but in the kernel drivers. You are correct below
that the protocol stacks will probably get you...

EISA will give you 32bit DMA address space, so your drivers can (if
nicely written), give you DMA from user space to controller (or controller
to user space) without copying, whatever your memory size. This is
especially important for high volume disk i/o on SVR4 where the
buffer cache is through the normal VM page fault / free page pool
mechanism and can therefore come potentially from any real memory
address (and not just below 16MB where the SVR4 buffer cache is likely to be).

>need a CISCO router at all, you can put all the machines on the same
>Ethernet, if you don't need 6Mb/s sustained bandwidth between each machine,
>but only aggregate.
>
>The bad news are that the TCP/UDP/IP sw on the host, and in particular
>SCO's, will have such huge overheads and misdesigns that in practice you
>will not be able to use more than a fraction of the nominal speed of the
>hardware. Somebody (Van Jacobson and others) have spent some serious effort
>in tuning up certain implementations of TCP/UDP/IP and can boast of being
>able of getting TCP/UDP/IP end-to-end connections that exploit 90-95% of the
>hardware capacity, but figures like 30-50% are far more common. I don't
>remember exactly, but I seem to remember that you'd be lucky to get more than
>300-400KB/s end-to-end on a TCP/UDP/IP connection from SCO's Internet
>protocol stack.

And even slower for file system to net to file system xfers.
Ftp in BINARY/IMAGE mode for big files probably will even give
only 100kbytes/s of so on a 386/486 type of PC running a fairly standard
Un*x and TCP/IP stack. Tftp won't give much better either.

>
>
>Finally, what you should tell us is what is your problem, e.g. how many
>machines you have got to link, how far apart they are, what is the average
>packet length, and what is the maximum packet rate that you expect from each
>machine, and other characteristics. Once you have told this to us, we can
>tell you whether Ethernet makes any sense at all. Possible alternatives are
>running TCP/UDP/IP over SCSI or over several point-to-point links, e.g.
>synch, or RS-422, for example.

If you are going to do SCSI, ie using host controllers both as
target and initiator, the reliability will be higher than Ethernet
and a simpler protocol layering than TCP/IP may be in order for
efficiency. (ALso bigger block sizes could be used than normal
datagrams).

>-- 
>Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

Martin Cryer
Unisys Europe Africa
Unix SVR4 Development
Unisys Salt Lake City

All opinions are my own and not those of my employer.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 01:28:05 GMT
From:      erik@srava.sra.co.jp (Erik M. van der Poel)
To:        comp.protocols.tcp-ip
Subject:   Re: EBCDIC ASCII and *much* more

Andr'e PIRARD writes:
> So, because we restrict ourselves to single-octet codes for now

What do you suggest for the Japanese, Chinese, Korean, and Taiwanese
users?
-
-- 
EvdP

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 02:02:21 GMT
From:      martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <KARL.91Sep1171232@remora.MorningStar.Com> Karl Fox <karl@MorningStar.Com> writes:
>Joachim Carlo Santos Martillo Ajami writes:
 
>   Reasonable possible architectures are:
 
>   1) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - BIWU - Ethernet
>   2) Ethernet - Bridge InterWorking Unit (BIWU) - WAN Link - Router - Ethernet
>   3) Ethernet - Hybrid Bridge/Router (HBR) - Wan Link Network - HBR - Ethernet
>   4) Ethernet - Router - WAN Link - Router - Ethernet
>   5) Ethernet - Half-Router - WAN Link - Half-Router - Ethernet
 
>   In IP terms, architecture:
 
>	   (1) corresponds to 1 IP network and can employ the transparent
>	       bridging version of PPP or SLITHERNET.
>	   (2) corresponds to 2 IP networks and can employ the transparent
>	       bridging version of PPP or SLITHERNET.
>	   (3) corresponds to 3 IP networks and can employ only SLITHERNET.
>	   (4) corresponds to 3 IP networks and can employ the transparent
>	       bridging version of PPP, SLITHERNET or PPP for IP.
>	   (5) corresponds to 2 IP networks and can employ the transparent
>	       bridging version of PPP, SLITHERNET or PPP for IP.
 
>You should really have said "Reasonable possible *bridging* architectures",

except that bridges were not used in all the architectures which I
described. 

>because I suspect that the most common way of interconnecting TCP/IP
>networks looks like your number (4) but where the routers have their
>interfaces configured with the BSD IFF_POINTOPOINT semantics, associating
>their interface with the primary (Ethernet) address of the machine at the
>other end of the WAN link and providing a host route to it. 

This method sounds more like the half-router method (5). 

>                                                            This doesn't
>work with X.25, which usually requires a subnet (unless you are running it
>over a point-to-point connection), but it's exactly what is intended to be
>used with PPP.  It corresponds to only two IP networks; the point-to-point
>link doesn't use up a subaddress.  

Avoiding the waste of subnets is good, but this method of interconnect
appears rather inflexible.  Non-IP traffic does not have an obvious way
to get across the link.  And the point-to-point link probably cannot
easily be replaced by a mesh of point-to-point links as might be
desirable to provide a high degree of availability, alternate routing
and fault tolerance.  Since this method is a half-router formalism, I
have to wonder how synchronized the software must be on both end hosts. 
If one machine can support the latest and greatest routing software,
does the semantics of BSD IFF_POINTTOPOINT prevent the best use from
being made of this new software. 

>                                   This is what we recommend to our PPP
>customers, and I believe is also what Sun recommends to their Internetwork
>Router customers.

The Suns use an 8530 type device on their serial interface, which
requires fairly expensive interrupt service routines.  A lot of serial
traffic could easily make necessary an upgrade to a more powerful
router.  I can see where recommending this solution might desirable from
Sun's standpoint. 

>Best of all, the two ends of the circuit don't have to come from the same
>vendor. 

Of course, for this reason I am making the slithernet specification
available.  Now personally I would rather that customers had to buy all
their equipment from us, but I also know customers are not stupid and
don't like to play this sort of game.  As a consequence, I am explicitly
telling our competitors as well as makers of non-competing networking
products how to communicate with our devices over a serial link.  I have
confidence that even if we aid our competitors, Clearpoint will still be
able to provide the biggest bang for the buck, and as a consequence,
customers will choose Clearpoint products over those of our competitors. 

>        There are dozens of products you can buy *today* that work this
>way.  

To me dozens, hardly seems like a resounding vote of confidence.

>      It would certainly rub *me* the wrong way if I were Wellfleet or 3COM
>and PSI or Alternet told me I had to buy a cisco router if I wanted a
>connection. 

Actually, NEARnet makes us buy cisco router for our internet connection.

>            It also means that PSI or Alternet can pick a router vendor
>and stick with it, since their connections run a non-proprietary protocol.

I would actually prefer that the interconnect connection be made with
remote transparent bridges because it is cheaper and NEARnet currently
limits our access to our router.  The situation would be analogous in
New England Telephone limited our access to our PBX.  The router like
the PBX should be under our control, and a remote transparent bridge
could function analogously to the CSU/DSU between our PBX and the central
office.

>I believe Bob was referring to something like this.  Coming from the TCP/IP
>point of view (and not being constrained by protocol architectures that
>don't scale past a LAN), he didn't see the value in bridging over routing.

1) You have to turn on UDP checksumming if you connect two ethernets
by a bridge rather than a router.  

2) Bridges are a fairly efficient way to reduce contention on a LAN. 
Suppose you have eight hosts on a LAN.  There is a fairly high
probability of collision.  But take each of these hosts and connect them
to a Little Dipper ether port.  Now at any instant 4 separate pairs of
hosts can communicate with each other without colliding.

Of course, you could do this with a router, but there are not too many
eight interface routers on the market, and such a box would probably
not do the routing at wire speed.  The Little Dipper does do wire speed
bridging (and will do wire speed routing shortly) at a very low cost.

In general, putting a bridge in front of a boot server or an NFS server
might be a good idea to increase performance, reliability and
availability while reducing contention while putting a router in front
of such a device is probably not a good idea because of extra overhead
and most advice which I have read recommends against so doing. 

>Of course, if you *do* use TCP/IP, there isn't any (at least until the
>Internet gets more than 20 hops wide).

I think we may be at different incarnations on the wheel of reincarnation
of computer and communications hardware.  A few years ago, a lot of
companies did intelligent ethernet controllers and put TCP/IP on the
controller.  This did not work so well because the cards cost too much
for cheap low power machines and became a bottle neck on the expensive
powerful machines.

So in many respects, dumb network interfaces with the implementation of
communications protocols within the end host was a good idea.  Once the
communications protocols are implemented in end hosts, the older OSI/PTT
(actually DARPA NCP) model of networking in which end hosts take little
part in the routing of packets but rather are served by intelligent
packet switches becomes pointless. 

But now the Little Dipper/Auriga product line provide a better solution
than involving end hosts intimately in the routing of packets and better
performance can be achieved by reincarnating the older model in new more
powerful garb.  In fact, since the Auriga and Karina devices actually
plug into endhosts, it may still appear as if the newer DARPA TCP/IP
model is being followed. 

>If I've missed something important here, flame away, as I'm somewhat of a
>novice at this stuff and probably deserve it.

I see no obvious reason for flames at this point in the discussion.

Joachim Carlo Santos Martillo Ajami

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 02:16:34 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.protocols.tcp-ip,comp.protocols.ibm,comp.unix.aix
Subject:   tn3270 on SNA emulators

The tn3270 protocol allows a 3270 datastream to be carried over a telnet
session to support full-screen block-mode access to IBM and compatible
mainframe systems. To make use of it, you need a tn3270 client (I know
of versions of UNIX, DOS, Macs, and VMS at least) and a tn3270 server
which runs on the IBM mainframe system itself, ie.

    +--------+               +--------+
    | PC/Mac |               | IBM    |
    |        |               |        |
    | tn3270 |               | tn3270 |
    | client |               | server |
    +--------+               +--------+
        |                         |
      --+----- tn3270 protocol ---+----

As an alternative to using tn3270, many vendors (most?) support the
connection of their systems to IBM systems via SNA (or BSC) links.  The
system in question then emulates an IBM 3274 terminal cluster
controller and users can gain access to the IBM mainframe itself by
telnetting to the "SNA-gateway" system and then running some program
that does the 327x terminal emulation, ie.

    +--------+               +------------------+        +--------+
    | PC/Mac |               |     Gateway      |        | IBM    |
    |        |               |                  |        |        |
    | telnet |               | telnet <   327x  |        |        |
    | client |               | server > emulator|        |        |
    +--------+               +--------+---------+        +--------+
        |                         |        |                 |
      --+--- telnet protocol -----+-       +--- SNA/BSC -----+


The problem with this second solution is that you end up with character
by character echo between the telnet client and the gateway. This, for
users users used to block mode terminals with instanteous, consistent
response for local editting of the screen, can be something of a culture
shock, ie. they complain.

Why don't vendors offer SNA gateways that support tn3270 servers ?, ie.

    +--------+               +------------------+        +--------+
    | PC/Mac |               |     Gateway      |        | IBM    |
    |        |               |                  |        |        |
    | tn3270 |               | tn3270 |   327x  |        |        |
    | client |               | server | emulator|        |        |
    +--------+               +--------+---------+        +--------+
        |                         |        |                 |
      --+--- tn3270 protocol -----+-       +--- SNA/BSC -----+

This would provide much better, more IBM-like access to the mainframe
system, and would avoid the cost and overheads of installing a LAN
interface and IP software on the IBM mainframe (which is not cheap :-).

It may be that somone out there has already done this using the runtime
libraries that are freqently provided with the SNA emulation packages;
if so I'd really like to hear from you (particularly if it is on the
Sun or IBM RS/6000 platforms),

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,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 02:19:24 GMT
From:      martin@unislc.uucp (Martin Cryer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

>bill@connection.prospect.com (Bill Poitras) writes:
>
>> Are you kidding?  I have seen 100Mbytes/s when ftping a file to a PS/2
>> running AIX with a ESDI controller and 16 bit ethernet controller.  I can
>> consitently get 20Mbytes/s.  Hell, I can get 11Mbytes/s sometimes to a PC
>> running DOS.  This is a ISA machine with a 16bit RLL controller.  I don't
>> see your problem.
>

Where do you buy one of these high throughput PS/2s, I want one NOW!
As for the EXTENDED ESDI and the HyperEthernet...

This is even worse than an IBM salesman in a bar at closing time....

Or is this a case of "my-PC-is-bigger-then-your-PC", naa - naa - nana - naa!

Martin Cryer
Unisys Europe Africa
Unix SVR4 Development
Unisys Salt Lake City

All opinions are my own and not those of my employer.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 04:24:31 GMT
From:      martin@unislc.uucp (Martin Cryer)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.


TYPO CORRECTION TIME....

In article <1991Sep5.224731.1555@unislc.uucp> martin@unislc.UUCP (Martin Cryer,D1Z01,5754) writes:

>In article <1991Sep1.195029.16374@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>scogen@xenitec.on.ca (scogen@xenitec.on.ca) writes:
>>
>>> We are trying to configure an SCO Unix system running some type of
>>> IP, (maybe TCP, maybe UPD) to operate at maximum throughput. Our goal
>>> is to get up to _6_ Megabits/Sec.

sorry I read this as megabyte / s originally!
		         ^^^^
I blame my bad eyesight and this darned X windows font!

>>
>>Well, nearly any modern Ethernet card will deliver 6 Megabits per second.
>>After all it's only around 600KB/s. SCO's TCP protocol stack will most
>>probably not be able to keep up with the card though.
>>
>EISA will give you 32bit DMA address space, so your drivers can (if
>nicely written), give you DMA from user space to controller (or controller
>to user space) without copying, whatever your memory size. This is
>especially important for high volume disk i/o on SVR4 where the
>buffer cache is through the normal VM page fault / free page pool
>mechanism and can therefore come potentially from any real memory
>address (and not just below 16MB where the SVR4 buffer cache is likely to be).

Sorry this should say SVR3 here             ^^^^

Martin Cryer
Unisys Europe Africa
Unix SVR4 Development
Unisys Salt Lake City

All opinions are my own and not those of my employer.

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 06:12:16 GMT
From:      pnr@ngs.fi (Pekka Nikander)
To:        comp.protocols.tcp-ip,comp.protocols.ibm,comp.unix.aix
Subject:   Re: tn3270 on SNA emulators

In article <1991Sep6.021634.20465@newshost.anu.edu.au> pte900@jatz.aarnet.edu.au (Peter Elford) writes:
>   Why don't vendors offer SNA gateways that support tn3270 servers ?, ie.
>
>       +--------+               +------------------+        +--------+
>       | PC/Mac |               |     Gateway      |        | IBM    |
>       |        |               |                  |        |        |
>       | tn3270 |               | tn3270 |   327x  |        |        |
>       | client |               | server | emulator|        |        |
>       +--------+               +--------+---------+        +--------+
>	    |                         |        |                 |
>	  --+--- tn3270 protocol -----+-       +--- SNA/BSC -----+


The Mitec OpenConnect provides the functionality you want to.  Their
solution is a "black box" that acts as the gateway,  Contact

	Mitek
	2033 Chennault Drive
	Carrollton, TX 75006
	(214) 490 4090
	(214) 490-5052 FAX

Furthermore, I have written such a program on the top of Sun Sunlink
SNA.  It should not be too hard to provide support for BSC as well,
but I don't have access to BSC lines.  The program is still under
testing, and I don't know weather it eventually will be freely
distributable, supported commercial product, or both.  However, if
anybody is interested, please contact me.

Pekka Nikander                                Internet: pnr@ngs.fi -or-
Nixu Oy Inc, independent consultation company           Pekka.Nikander@ngs.fi

--
Pekka Nikander

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 06:13:56 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: AIX 3.1 ARP Question

In article <9189@spdcc.SPDCC.COM> sfancher@spdcc.COM (Steven Fancher) writes:
+---------------
|       According to RFC826  a node should update its ARP cache if it sees a
|       request or a reply who's IP address matches an entry in its cache.
|       i.e. A, B, and C are nodes on a network. A and B have ARP cache entrys
|       for C. C's hardware address changes. A broadcasts a request for C's
|       new hardware address and C sends a reply. A updates his cache.
|       B also gets both the broadcast request and the reply. B should update
|       its cache entry for both A and C (B saw the request containing A's
|       hardware address and the reply containing C's hardware address).
+---------------

B does *not* (and should not) see the reply from C! From RFC 826, page 5 (or
so, they're not numbered), "Packet Reception", near the end of the algorithm:

        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

The "(new) target hardware address" is in this case C's unicast address,
*not* the MAC-layer broadcast address.


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 10:02:24 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problem from hell

Since no-one has followed up on this, I will offer my opinions - if I'm
wrong, please flame - I'll learn from it *B^) I'm still feeling my way with
this stuff.

mcneill@eplrx7.uucp (Keith McNeill) writes:

>The site on which I work has a large bridged ethernet with many hosts on it.
>A class B address has been assigned to the site (call it XXX.YYY.0.0).  The
>network owners have assigned each building a subnet number.  Hosts that sit
>on the large bridged ethernet do no use subnetting (i.e. subnet mask
>255.255.0.0).  
>My network is a separate ethernet.  My network was assigned subnet 252 within
>the XXX.YYY.0.0 network.  All hosts on my ethernet, including both interfaces
>on the router, use a subnet mask of 255.255.255.0.  My router is a Sun
>Workstation running proxy arp.  Proxy arp is used to enable communication
>between the subnetted (my network) and non-subnetted (everybody else)
>portion of the XXX.YYY.0.0 network.

I have seen this subnetted & non-subnetted hosts situation referred to as
having a highway with cars driving on the left & trucks on the right!
Do I have these definitions right?
- Routing: Having two (or more) interfaces in different nets, and passing 
packets between those nets
- Proxy arp: One (or more) interfaces in the *same* net, responding to 
recognised host addresses and forwarding packets on their behalf
From the netstat table below, it seems to me that your host is routing, not
proxy arping.
I'm not too familiar with proxy arp, but don't you just have a table of
host addresses on the 252 side that the 78 interface will respond for?
I can anticipate that you will say you're not running routing code, ie
routed or gated, but I have seen Sun clones running SunOS which function as
routers by default, despite RFC1122 saying that this should not happen.

>On my router I have added a default route pointing to the 78 subnet interface.
>netstat -r on my router:
>Routing tables
>Destination          Gateway              Flags    Refcnt Use        Interface
>127.0.0.1            127.0.0.1            UH       3      19989      lo0
>default              XXX.YYY.78.1         U        5      2295226    ie3
>XXX.YYY.252.0        XXX.YYY.252.10       U        78     1681671    ie0
>XXX.YYY.78.0         XXX.YYY.78.1         U        0      4851       ie3

This is correct for a subnetted router. It would be better to have a proper
router (eg cisco) as the default host if you have multiple logical subnets
on the same physical cable.

>The root of the problem is that my router sits on subnet 78 and the router
>to the AAA.BBB.CCC.0 network sits on subnet 10.  When I try to add a route
>sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net
>AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable

This is correct. XXX.YYY.10 is not in your subnet.

>Non subnetted machines sitting on the bridged ethernet have no problem
>communicating with the AAA.BBB.CCC.0 network.

It is, after all, a *different* network, and XXX.YYY.10.1 is a true router.

>This leads to 2 questions:
>1)	Is my router (i.e. the Sun IP code) acting correctly.
Yes

>2)	One way to solve this would be to change the subnet mask on the 78
>	side of my router to 255.255.0.0.  Can the Sun IP code deal with a
>	machine with 2 different subnet masks for the same class B network.

If it can, it's broken! If the 78 side is now net XXX.YYY.0.0, then
XXX.YYY.252.0 is a host address in the same network, not a net address.

As I've said, I don't believe you are proxy arping. Changing *both* your
masks, and using proxy arp, will, I think, work.

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 12:33:25 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: Changing passwd on remote system.


 Well you could do 2 things :

 a) Get a copy of npasswd (emx.utexas.edu) it is a great password checking
    package and also suppoerts Yellow Pages (NIS)

 b) Do a rsh (remote shell) to the Server machine, and change the local password
	in the server.

 That easy !!


 _____________________________________________________________________________

 Jose Angel Vela Avila. 
  
  Instituto Tecnologico y de Estudios Superiores de Monterrey
    I.T.E.S.M

  Mexico.
  ___               _    ___  _         __
 (   >             ' )  /    //        /  )  josevela@mtecv2.mty.itesm.mx
  __/________    _  (  / _  // __.    /--/   josevela@tecmtyvm.mty.itesm.mx
 / /  (_)  \_)__</_  \/ </_</_(_/|_  /  ( o  josevela@tecmtyvm.BITNET
<_/

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 14:08:45 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Backups using rsh.

I'd like to do backups over our network using rsh, but I'm wondering if
the data will be transferred reliably.  Does rsh use tcp or udp and
should I be using it for backups?

-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 16:31:49 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Any results from Gbits testbeds ?


    Date:    28 Aug 91 13:52:56 GMT
    From:    Marten Terpstra <mcsun!hp4nl!nikhefh!a20@uunet.uu.net>
    Subject: Any results from Gbits testbeds ?

    Hi all,

    Couls anyone tell me if there are any (preliminary) test results or other
    conclusions available somewhere on the NSF net sponsored Gigabit testbeds ?

    And now that I'm more or less on the subject, can anyone suggest some readi
    ng
    material on ATM and other of these goodies that are to come ?

    Thanks,

    -Marten

The August 26 Issue of NW did a feature article ( page 44 ) on the 
5 ( Auroura, Blanca, Casa, Nectar, Vistanet ) NREN prototype testbeds.


As the article points out there are varying degrees of new switching 
and transmission technologies involved with each deployment; ATM, Sonnet,
SMDS, etc.

I found it to be a good overview for non-participants ( with an interest ),
such as myself. Recommend ( but who am I ) reading.

 [ Standard disclaimer applies. My views only ]

  George Williams

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 16:56:45 GMT
From:      cgonzale@mtecv2.mty.itesm.mx
To:        comp.protocols.tcp-ip
Subject:   Western Digital's cards


Does anybody know the difference between Western Digital's Ethercard Elite 16 Combo and WD8013EW cards ?

We need an Ethernet card with 10BaseT & BNC media support in the same board but we are not shure about the correct model that we have to order.

Thanks,
Cesar

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 17:00:24 GMT
From:      kent@tfd.COM (Kent Hauser)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   need help usings streams modules with sockets


I'm using SunOS 4.1.1 and I need line-at-a-time reading on a tcp
stream. I also need to spin in a select loop so I can do non-blocking
i/o on multiple desriptors.

A perfect solution would be to push a "ldterm" streams module
on the socket descriptor & use cannonical processing.  Unfortunately,
the ioctl returns "not supported on a socket".

My question is (before I write a custom streams filter to do
this & other filtering) does this mean that *no* streams modules are
supported on sockets, or just that ldterm doesn't work on sockets.

Also, if someone has a simple sample streams module with all of the
OS hooks in it, i'd appreciate it.

Thanks.

kent

-- 
Kent Hauser			UUCP: {uunet,sundc,uupsi}!tfd!kent
Twenty-First Designs		INET: kent@tfd.com
(202) 408-0841	

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 17:51:22 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

From RFC792:

2.10.  Robustness Principle

  TCP implementations will follow a general principle of robustness:  be
  conservative in what you do, be liberal in what you accept from
  others.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 18:42:53 GMT
From:      bumed@nmrdc1.nmrdc.nnmc.navy.mil (BUMED GUEST ACCT)
To:        comp.os.vms,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   POP daemon on an Amdahl

We are currently trying to use POPmail.  We have successfully ported a 
version to run off FTP's TCP layer and now either have to transfer 
a couple hundred vms accounts to 3b2s (gag!) or need to find a POP
daemon to run on a vm system.

Does anyone know where I can find such a daemon?

Sorry for the wide distribution, but I need a quick response......

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 18:49:32 GMT
From:      bumed@nmrdc1.nmrdc.nnmc.navy.mil (BUMED GUEST ACCT)
To:        comp.os.vms,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: POP daemon on an Amdahl

We are currently trying to use POPmail.  We have successfully ported a 
version to run off FTP's TCP layer and now either have to transfer 
a couple hundred vms accounts to 3b2s (gag!) or need to find a POP
daemon to run on a vm system.

Does anyone know where I can find such a daemon?

Sorry for the wide distribution, but I need a quick response......

sorry for posting twice but the news server forgot to add my account name
  Please reply to nmctr6@bumed10.bumed.nnmc.navy.mil

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 20:37:19 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

Frank writes:

>From: kasten@europa.clearpoint.com (Frank Kastenholz)
>Message-Id: <9109061751.AA20593@europa.clearpoint.com>
>To: fab@md.interlink.com, mentor.cc.purdue.edu!dls@purdue.edu,
     tcp-ip@nic.ddn.mil
>Subject: Re: TCP FIN and window
 
>>From RFC792:
 
>2.10.  Robustness Principle
 
> TCP implementations will follow a general principle of robustness:  be
> conservative in what you do, be liberal in what you accept from
> others.

So what is your conclusion from this statement.  I want to be liberal
and accept the FIN, in fact I already do that.  What is not determined
is does the statement about being conservative mean the other end should
NOT send the FIN?  I argued against this in previous messages.

Let's hear your opinion, Frank.

Let's hear everyone's opinions.

Fred


------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 91 21:56:00 GMT
From:      dls@MENTOR.CC.PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


	I don't think sending the FIN violates being conservative, because
any conforming implementation knows how to strip off and discard data beyond
its window. As I have argued, sending it, at least when you're sending other
data, is absolutely free.
	My $0.02:

	"Be liberal in what you receive and conservative in what you
send" practically qualifies as a political sound bite. All the substance is
subject to interpretation. Everyone will agree it's a good idea to do that,
which is undoubtedly why it is quoted so often, but it doesn't mean any
agreement at all on the issue.
	Anyone for being tough on crime, too?!? :-)

							+-DLS

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 91 03:18:19 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   Re: How to connect to the Internet?


Marc,

I wish my easy_to_use 3-R system can be of help for you to gain your internet 
access.  It is:

	Rope  (a lease line from your telephone company)
	Router (an IP router, or a gateway if your local net is big enough)
	Registered net membership (registering your name resolver)

As of the details of those hardware connections, I seldom use the Installation
Guide, because we can figure them out by their physical sizes, for example, we
never try to put a 9-pin conector to a 25-pin slot.

On the costs issue, As far as I am aware of, the telephone companies charge 
the lease line by the distance between your net and your service provider,
usually a nearest backbone outlet from your office.  The membership fee 
has two categories: direct member of some regional network, or an
associate member of some members of those regional networks.  You should
be able to get a quote from your local service providers.  You may try
to contact your local universities first.

shannon
-------

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 91 16:33:50 GMT
From:      selene@osystem.pdx.com
To:        comp.protocols.tcp-ip
Subject:   (none)

delete tcp-ip jander@osystem.pdx.com

Please turn OFF the mailinglist!   It gets routed through a no-no spot.

--Jon

__________________________________/----\______________________________________
| selene@osystem.pdx.com (Jonathan Anderson)   Voice: +1 503 682 3731        |
| Jonathan Anderson @ 1:105/291.2.fidonet.org                                |
| "On the bleeding edge of technology!"                                      |
\----------------------------------=||=--------------------------------------/

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 10:43:46 GMT
From:      ykluger@fibronics.UUCP (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   SLIP Sources

Hi,

Does anyone know of publicly available sources for SLIP ?

-- Yoav Kluger
   Fibronics Ltd.
   MTM Industrial Park
   Haifa 31905, Israel

   Email: imp!uunet!fibronics!ykluger
   Voice: Int'l.972.4.313313 x669
   Fax:	  Int'l.972.4.516266
   

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 18:43:49 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Changing from ASYNC to TCP/IP while still keeping security?
To: tcp-ip@nic.ddn.mil
Date: Sun, 8 Sep 91 14:43:49 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Reply-To: scoggin@delmarva.com
In-Reply-To: <6118@inews.intel.com>; from "John Reece" at Aug 29, 91 10:04 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> In article <1991Aug29.191937.10748@milton.u.washington.edu>, erikm@hardy.u.washington.edu (Erik Madsen) writes:
> 
> |> What I want to do is propose to the MIS people that we can still keep 
> |> the same security we have now (or maybe do smarter security) and get 
> |> faster connections between
> |> our corporate net (our desktop computers) to our internet server (and
> |> still convincing them that if we do that, we are not opening our corporate
 |> net to the outside internet world.  

You might check with the folks at Advanced Networks & Systems - Linda Boykin
(boykin@nic.ans.net) might be a good start.  ANS has a Secure Internet
Gateway product for your type of situation.


----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 19:10:08 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   FDDI throughput

Good morning,
I was hoping that someone out there might have some good information regarding
Network SYstems FDDI router throughput and Network Peripherals VME adapter 
FDDI throughput? It's so tough to find out how fast things really run once
you get them installed into your environment, and I was hoping that someone
had done some testing to obtain rough estimates.
Please respond directly and I'll summarize to the net if appropriate.
Thank you,
Chris VandenBerg
CMC -  A Rockwell Intl Co.   125 Cremona Dr.   Goleta, CA. 93117
Internet - chrisv@cmc.com          ma-bell - 805-562-3127 

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 19:23:36 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.mail.misc,comp.protocols.tcp-ip
Subject:   Top-level domains; anyone have a list?

Does anyone have a list of valid top-level domains?  I have found myself in
need of one for mailer configuration here (it's a strange beast, yes).  We
need to forward all mail for domain addresses to one site, and route UUCP
mail separately.  However, I want to pre-select knowing that the top level
domain (ie: ".us") is valid first.

Any help appreciated!

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 20:36:03 GMT
From:      bill@connection (Bill Poitras)
To:        comp.protocols.tcp-ip
Subject:   This is a test of mailing to an NNTP server

This message is to test using mail to post to the Usenet news.  I chose
this newsgroup because it had a dash in its name and is a group which I
read often.  All flames to /dev/null.  Thank you.

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton bu}!polygen!bill |
|     (bill)      | Waltham, MA USA           | - This space for rent -     |
|                 | FAX (617)890-8694         | bill@polygen.com            |
 +-----------------+---------------------------+-----------------------------+

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 91 23:54:28 GMT
From:      ykluger@fibronics.UUCP (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   Limited Broadcast Problem on Unix?

Hi,

I am trying to implement BootP. I have a server running on a UNIX
machine (SUN SparcStation) bound to the BootP server port, and a
client (on a custom box) which comes up and sends an initial BootP
request.  Since the client does not know even its IP address, it uses
the "This Host" address (all 0's) as the source address, and the
Limited Broadcast address (all 1's) as the destination. Very
surprisingly and in a most disappointing fashion, the server does not
get the request datagram - it is stopped somewhere, either in IP or
UDP or the socket (my guess is in the latter). Attemtps to send the
very same datagram from the very same client to the very same server
using either the specific address of the host hosting the server or
the corresponding network broadcast address as destination resulted in
ultimate success.

Could anybody help me with this? Is it possible that SUN's unix does
not support limited broadcast? Or do I have to activate some hidden
socket option?

Thanks in advance for any tips

-- Yoav Kluger
   Fibronics Ltd.
   MTM Industrial Park
   Haifa 31905, Israel

   Email: imp!uunet!fibronics!ykluger
   Voice: Int'l.972.4.313313 x669
   Fax:	  Int'l.972.4.516266
   

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 01:38:58 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.sources.wanted,comp.archives.admin,comp.org.eff.talk,bionet.general,comp.protocols.tcp-ip
Subject:   Re: knowbots: searches on inet sections

In article <36002@hydra.gatech.EDU> ccoprmm@prism.gatech.EDU (Michael Mealling) writes:

   Has anyone been doing anything with a species of program called a "knowbot"?
   Essentially they scout the net (news, archives, mail lists, etc) for articles
   that would be of interest to the user. If you've read David Brin's _Earth_,
   they are referred to as "ferrets". (I kind of like the name "meme-hound").  

There's a pile of discussion going on all over in assorted places
about these things, here's some pointers to where the traffic is and
who's talking.  This is by its very nature a sketchy report, since
the whole premise of this is that there are people of every field and
persuasion looking for tools and techniques to look for interesting
articles, and so you'd bound to find traffic and experts just about
anywhere.

"Knowbot" is trademarked, not a generic term, take care how you use
it.  There's a service which calls itself the "Knowbot Information
Service (V1.0) Copyright CNRI 1990 All Rights Reserved." which you can
use by telnet to sol.bucknell.edu, port 185; it's a system that looks
up user email addresses by name.   More information about it can be
found at 
	nri.reston.va.us:/rdroms/*
including the text of an internet draft on the subject.  (I'll have to
check if and when this was published as an RFC.)

KIS is reviewed in the June 1991 issue of _Boardwatch_ Magazine.
There's a short account by Vincent Mazzarella of a presentation by Mr
David Ely of CNRI (the Corporation for National Research Initiatives)
to the ACR Workshop on Computer Networks in Radiology Research in
bionet.general (March 1991) where he refers to systems like "Grateful
Med" as a Knowbot:

	One can build a KNOWBOT locally and then send this to a larger
	machine, have the program run on that larger machine, returning
	processed data to the local system.  GRATEFUL MED is a good
	example of this concept in which a search routine is built at the
	local PC and is then sent to a large database for a search.

The first thing I turned to to start to prepare this was WAIS, the
Wide Area Information Service. A search for "knowbot" in the
"matrix_news" database on quake.think.com yielded a good article that
references a meeting of the Coalition for Networked Information (CNI)
working group on "Developing a Framework for Network Directories and
Related Services", held June 3-4 at Stanford.  This meeting brought
together some of the interested parties; you can find an account of it
via anonymous in the file 
	quake.think.com:/pub/mids/matrix_news/cni.3
or by using the WAIS source in
	quake.think.com:/pub/mids/matrix_news.src
Rather than quote bits of the article it would be most useful to fetch
the whole thing and read it.  WAIS itself falls into this category
generally, since there's a division of labor between the search
engines running on remote machines like Connection Machine
supercomputers, and the local display and user interface systems
running in point-and-click (Mac) or part of your editor (GNU Emacs)
environments.

comp.archives is an example of a real-life system which uses some of
these tools.  A set of programs systematically filters through days
worth of usenet news postings looking for key words and phrases that
refer to materials available for anonymous FTP from remote systems.  A
human editor pares these hits down somewhat to wipe out some noise and
to perhaps add additional information to each posting.  Though the
scheme to date has employed a single moderator at a time in this role,
it's lacking but for volunteers to have multiple people each tracking
a more specialized subset of the net and sharing their sense for
important new additions to archives with others.  (Further discussion
to comp.archives.admin.)  I don't know that the scanning code has yet
been released (Adam?)

For the limited problem space of "ftp'able files" the searching
necessary is really quite minimal; for searches on fuzzier topics
you'd probably want to go with a system that had a priori full text
indexing of probably relevant groups combined with regular scanning of
usenet news + mailing lists for key words and phrases which would have
a lower hit rate but might lead you farther afield.  One interesting
project that also focuses on searching through usenet is the
"Pasadena" system; there will be a presentation on it by Mitch Wyle at
SIGIR in Chicago in October.

The "archie" service (see quiche.cs.mcgill.ca:/archie/doc/) is also
worth noting, both in the context of providing before-the-fact
searching for FTP retrieval and also as a general tool for locating
things around the net in a knowbot-style fashion.  

There's a great deal to be gained if what you're dealing with can be
treated not just as great amorphous gobs of information; the more that
you can deduce explicit or implicit structure in the information the
more focused and precise your searches can be.  As an extreme example
the work of Malone at MIT ("Information Lens") to provide users with
tools to create structured e-mail messages and then also tools to
filter through their mail based on the added structred information
have proven to be very powerful.  Unfortunately, netnews tends to be
anything but a nice small homogenous cooperating community, so those
tools would have less success when unleashed on the daily torrent of
netnews.  

One reaction to this flood of news is to try to locate sources which
have an ear open to the wide world of what's out there and which can
condense and edit it down to a reasonable stream of especially
interesting materials.  Sometimes you'll find volunteers up to the
task, and you'll often see people forwarding off particularly
interesting mailing list or newsgroup materials to their friends who
don't have the time or energy (or tools) to plow through netnews.

Paper- (or email-) based electronic information sources have started
to pop up; no doubt more are coming.  For $xx-$xxx/year (the price of
a good magazine, let's say, but less than an academic journal
subscription) you get the services of an editorial staff, some on-line
archives managed for the task, and a steady stream of interesting
materials.  I doubt that anyone gets rich from producing one of them
any time soon, but a well-edited and properly produced periodical
should be able to support itself from readers of the net.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
 for information on MSEN products and services contact info@msen.com


Notes.

There was a review of comp.archives in an earlier issue of Boardwatch.

	The masthead says that Boardwatch comes out 12 times a year.
	It gives these electronic mail addresses:

	Internet:	jack.rickard@csn.org
	GEnie:		JACK.RICKARD
	CompuServe:	71177,2310
	Fidonet:	104/555
	MCI Mail:	418-7112

WAIS can be had from quake.think.com:/pub/wais/.  A (beta test) ascii
terminal interface is running at hub.nnsc.nsf.net, log in as "wais".

The "Matrix News" materials are on quake.think.com:/pub/mids/matrix_news/ 
A subscription form is in the file "0subscribe".
	Matrix News
	Matrix Information & Directory Services
	701 Brazos, Suite 500
	Austin, TX 78701-3243
	U.S.A.
Thanks to John Quarterman for this excellent periodical.

bionet.general quotations were found in the WAIS server "biosci"
running at genbank.bio.net.

I don't have a good citation for Information Lens.

comp.archives has not been written up extensively in any periodical
(and that's probably my fault).

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 06:53:37 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Backups using rsh.

In article <1991Sep6.140845.25125@homecare.COM>, jessea@homecare.COM () wrote:
>I'd like to do backups over our network using rsh, but I'm wondering if
>the data will be transferred reliably.  Does rsh use tcp or udp and
>should I be using it for backups?

rsh(1) uses TCP, so it's as reliable as TCP is (whatever that
means these days :-)).

...Sam
-- 
<skl@cs.sfu.ca>

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 06:58:26 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


    ...the probe time should be the same as the retransmission time, with
    exponential backoff, and not 2 minutes (!). Berkeley uses a minimum of
    5 seconds (as much as a 1000 times too large on an Ethernet), which makes
    for pretty poor performance if you do drop a probe.

I'm sorry, but this is pretty much all wrong.

1) In a modern TCP, the receiver window will never be o unless the destination
   device is slower than the network link (eg terminal servers).

2) The sender's view of the window can of course be 0 (causing it it go into
   probe mode) whenever the receiver's window is smaller than the effective
   delay*bandwidth product of the network (more common).

3) In case two, the receiver will be sending one ACK for each two packets or
   so, each opening the window appropriately.  In order for there to be a
   significant performance hit, youhave to drop ALL of those ACKs, AND the
   first probe or so.  This is notvery likely.

4) Probes are a failsafe technique for recovering from am ACK that would
   open the window being lost.  Lost packets are rare.

5) In case one, the correct interval for probing the window should be
   based on the time you expect the remote host to dispose of it's data.
   This isn't based on the network characteristics at all, so basing the
   initial probe interval on the calculated RTT is completely bogus.
   (If you can use the calculated RTT and slow-start/etc to measure the
    effective network bandwidth, you ought to be able to get a good idea
    of the effective end-device bandwidth by doing similar calculations
    on the window updates (slightly more difficult because the window
    updates aren't nicely sequenced for you)).
   (No one does this, and it isn't important.  As long as you exponentially
    back off your probes, you hit a non-obnoxious interval relatively soon
    anyway.  And the probes are hardly ever useful anyway.)
   (oh, while rfc793 implies that maybe the data shouldn't be acked until
    it is actually disposed of by the 'end-device', I don't think that
    there are many TCPs thatactually operate this way.  I hope not, since
    it seems much more useful to use the RTT values to characterize the
    nework, rather than the application).

6) Given all of the above, I think the 5 second minimum of the berkeley
   code is quite appropriate.  I can also claim actual data in that area.
   I recently "fixed" cisco's terminal server TCP code to do better
   zero-window probing (in particular, to avoid affecting the RTT numbers
   while probing).  Part of this included changing the debugging support
   to differentiate between probes and other retransmissions.  It is quite
   clear that doing the first probe after the calculated RTTO results in
   way to many probes being sent.

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

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 07:04:52 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

in fact that fusion in a jar were two researchers and they stirred up
massive confusion in the media some time ago. maybe this is a second try .. 

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:35:29 GMT
From:      dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To:        comp.protocols.tcp-ip
Subject:   Re:   a minconfigured host

> Suppose that an IP host is miconfigured with a forwarding capability,
> i.e. the host would try to forward a packet received which was not
> destined to this host, would it decrease the TTL of the packet?

If a host that is not a router is forwarding packets, then it is
broken, but you already know that.  The misconfigured host would be
considered a router, and should obey all the rules of a router,
including decreasing the TTL of a packet.  If it is not decreasing the
TTL, then it is broken.

Daniel

=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====

Daniel M. Barton                 Internet:  dmbarton@ralvmm.vnet.ibm.com
TCP/IP Development                          dmbarton%ralvmm@vnet.ibm.com
IBM Research Triangle Park, NC  USA

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:50:55 GMT
From:      Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721)
To:        comp.protocols.tcp-ip
Subject:   Re: a minconfigured host


Thank you for your answer.

 >If a host that is not a router is forwarding packets, then it is
 >broken, but you already know that.  The misconfigured host would be
 >considered a router, and should obey all the rules of a router,
 >including decreasing the TTL of a packet.  If it is not decreasing the
 >TTL, then it is broken.

I understand that the misconfigured (i.e. ip.forwarding) host *should* 
decrease the TTL.  But my question is if it is quite so in the current 
popular implementation, such as the IP on a UNIX system.

Yuko

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 13:56:47 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

Johnny writes:

>From: micro-heart-of-gold.mit.edu!wupost!m.cs.uiuc.edu!zweig@bloom-beacon.mit.edu  (Johnny Zweig)
>Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
>Subject: Re: TCP FIN and window
>Message-Id: <1991Aug28.215504.7608@m.cs.uiuc.edu>
>References: <1991Aug19.220019.4082@novell.com>, <1991Aug27.205232.7303@ultra.com>, <1991Aug27.192634.16859@jarvis.csri.toronto.edu>
>To: tcp-ip@nic.ddn.mil
 
>How about advertizing a one-octet window?  There's no law that says that you
>have to actually _accept_ data -- so advertize a teensy window...
 
>-Johnny Singleton


The problem with this approach is when there really is data and the window
really should be closed.  If you advertize one byte, the other end will send
it.  Now what?  If you advertize zero bytes, you have not changed the problem.
If you do not ack the byte you got, the other end will retransmit, eventually
breaking the connection.  If you advertize one byte again, what will you do
with the byte you just got, and what will you do with the next one you get,
etc., etc., eventually you have too much data.  This negates flow control.
It just changes a full-bandwidth flow into a slow leak (1 byte per round trip).

Again, I say just allow the FIN to flow into a zero window.

More comments, please

Fred

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:33:32 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

On 3 Sep 91 04:56:41 GMT, torek@elf.ee.lbl.gov (Chris Torek) said:

pcg> 32 bit EISA Ethernet cards are an expensive joke, as is any "turbo"
pcg> interface between a 40MB/s 32 bit bus (EISA) and a 0.8MB/s 1 bit
pcg> one (Ethernet).

torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

That's impossible to achieve, it ignores inband formatting information
(headers, CRC, pauses between packets) and other practical constraints.

The theoretical maximum is a bit less than 1MB/s, and even that cannot
in practice be achieved because the Ethernet is a simplex channel, and
most protocols require ACKs every now and then, and thus in practice you
cannot just pump data continuously from source to target with maximal
size packets.

The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
occasional bursts at 0.9MB/s.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:52:29 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

On 2 Sep 91 13:51:20 GMT, cpcahil@virtech.uucp (Conor P. Cahill) said:

cpcahil> pcg@aber.ac.uk (Piercarlo Antonio Grandi) writes:

pcg> Same goes for EISA SCSI disk controllers (the most expensive SCSI
pcg> disks top out at 4MB/s, and most cannot do more more than 1.5MB/s
pcg> off the platter). In practice EISA is only needed for very high
pcg> speed graphics (good luck with that) and for disk arrays, or,
pcg> theoretically, for very high bandwidth tapes.

cpcahil> Throughput is not the only evaluation factor for a disk
cpcahil> controller.  Another factor, which is where a good EISA
cpcahil> controller will shine, is the amount of time the bus is tied up
cpcahil> transferring that 4MB/s.

Latency then perhaps matters. But in practice not a lot...

cpcahil> You yourself said that the theoretical max for the ISA bus was
cpcahil> between 5 and 6 MB/s.  4MB/s is appox 80% of the theoretical
cpcahil> max.

Of course, but this is nearly irrelevant. Almost nobody keeps their SCSI
bus running at its top rated bandwidth continuously (not even Adaptec,
which stay off the bus for some programmable fraction of the time).

In particular disk access tends, in normal operation, to be bursty (the
effect of caching and paging, and then of intervening seeks).

Also, most disks currently available don't do much more than 1.3MB
sustained, so having two such disks gives you, if both are active
together, an instantaneous bandwidth of 2.6MB/s, but on average they
will not be both active together, and theat will not in acase last long.

In practice 5-6MB/s is many times than the *average* bandwidth
required, and it is twice the highest instantaneous load you can expect
to see in a small to medium general purpose timesharing system.

cpcahil> With a good EISA controller that same 4MB/s can take up only
cpcahil> 12% of the theoretical max, thereby freeing the bus up for
cpcahil> other operations.

The problem is that, except for very large systems running very large
loads, or particular cases, there are no other operations.

All CPU memory access, the real pig, is via a private bus, and only
tapes, disks, communications and framebuffers use the ISA bus, and their
combined *average* utilization is nowhere its saturation point, and
their *peak* is also accomodated more or less easily.

pcg> First of all, the good news: as I have said almost any modern
pcg> Ethernet card will deliver substantially all of the Ethernet
pcg> bandwidth, and this bandwidth is at worst one fifth of the ISA bus
pcg> bandwidth, so you don't need any EISA

cpcahil> Giving up 20% of the bus bandwidth just to handle ethernet i/o
cpcahil> sounds like a good reason to go with EISA.  20% is alot of the
cpcahil> system.

Yes, but you are not transferring 1MB/s constantly thru your Ethernet
adapter, I hope. And if you are, then most people have pretty low
average Ethernet adapter utilizations.


Quite surprisingly :-) the highest bandwidth user is likely to be the
frame buffer: SVGA cards, which are pretty slow as frame buffers go, can
require 2MB/s, and, if you are doing image processing, sustainedly. But
a 2MB/s video card will almost surely need a 2MB/s disk/tape subsystem,
and this is not the sort of application that I would do with ISA, I
would definitely do it with EISA. I would also use EISA for largish
(more than (perhaps half) a dozen users) timesharing.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 18:56:24 GMT
From:      voliva@hpcc01.corp.hp.com (Val Oliva)
To:        comp.protocols.tcp-ip
Subject:   Re: a minconfigured host


(Yuko Murayama) asks:
---------
/ hpcc01:comp.protocols.tcp-ip / Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721) /  6:07 am  Aug 29, 1991 /

Suppose that an IP host is miconfigured with a forwarding capability, 
i.e. the host would try to forward a packet received which was not destined
to this host,  would it decrease the TTL of the packet?

Yuko Murayama
Dept of Computer Science 
University College London
----------

	Assuming that this host is configured as an IP router, then it
	should decrement the TTL of the packet. 

	NOTE : Hosts with 'Embedded Gateway Code' and are configured as
	       IP router must follow RFC 1009 (Requirements for Ineternet
	       Gateways).


	Regards,


	Val Oliva

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 19:06:32 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: how to keep /etc/hosts up to date

>We've got a few systems running BSD networking without support for
>BIND in the network library routines.  Their /etc/hosts, /etc/networks,
>/etc/gateways, etc., files are out of date, and I'm looking for
>ideas on updating them.
>
>There are three sources of information that I'd like to include in
>the updated files.  First, I need our own departmental information.
>Since we maintain the local BIND server ourselves, it is easy to
>derive the appropriate information from the BIND database source
>files by writing a translator.  No problem there.
>
>Second, I need University-wide information.  I'd like to get this
>data by querying BIND itself, but I don't know how to get started.
>This part of /etc/hosts has been maintained by hand in the past.
>Is there a better (i.e., automated, BIND-based) approach?

I do this with a little input file to nslookup, plus a two-bit awk
script to reformat the results.  This works fine if you know all the
domains from which you want data; if there are many subdomains that
are delegated to other servers, you would need to add some logic to
spot them and do a recursive set of nslookup/awk calls.

If you're interested in these files, let me know.

>Third, I need well-known Internet sites and networks.  I can get
>the DoD Internet Host Table from the NIC (using gettable), and this
>may be enough.

That's exactly what I do.  It's generally enough, although I have a
little filler file in which I can stuff miscellaneous entries that are
not determined by one of the three sections you listed.

Someday, I'll be out of the business of maintaining a huge hosts file.....

Doug Nelson
Network Manager
Michigan State University

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 19:48:10 GMT
From:      johnscj@NSCO.NETWORK.COM (Curt Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re:  CISCO phone number?

Cisco number is 415-326-1941  FAX number is 415-326-1989

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:09:50 GMT
From:      exudnw@exu.ericsson.se (Dave Williams)
To:        comp.protocols.nfs,comp.protocols.tcp
Subject:   NFS bibliography?

Is there any interest in publishing an NFS bibliography similar to the one
frequently published in comp.windows.x?  If so, (or even not) please send
me the title(s) of your favorite NFS reference and I'll post a summary.
If there exists an NFS bibliography, then post it or send me a copy.

Thanks


--
= exudnw@exu.ericsson.se                                  (214)907-7928 =
= David Williams                                                        =
= Ericsson Network Systems                                              =
= Richardson, TX 75081                        These opinions are my own.=

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:19:18 GMT
From:      abt@NSD.3COM.COM (Abtin Assadi)
To:        comp.protocols.tcp-ip
Subject:   Support of Multiple Logical Subnetwork by Routers

> C.H. Cheng, The Chinese Univ. of Hong Kong writes:
>Is anyone out there using 3Com Brouter (BR/2000)? I think we have the latest
>version (V3.0.2.3).  Unfortunately, although the manual mentions that it
>supports Multiple Logical Network (Subnetwork?!) for IP, we are not able to
>implement subnet routing through a single port when we set up two addresses
>(with different subnet no. of course) to this port.  It seems that the
>secondary address is of no use with this brouter.

This problem has already been fixed, please contact your local 3Com customer support organization for the latest rev of BR/2000 software.

Abtin Assadi,
3Com Corp.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 20:42:38 GMT
From:      APRIL@NIC.DDN.MIL (April Marine)
To:        comp.protocols.tcp-ip
Subject:   Transition of NIC services

FYI--for widest distribution.

This transition of NIC services also applies to the assignment of
IP network addresses, top-level domains, and second-level domains
under COM, EDU, MIL, NET, ORG, and GOV.

********************************************************************** 
DDN MGT Bulletin 84              DCA DDN Defense Communications System   
4 Sept 91                        Published by: DDN Network Info Center
                                     (NIC@NIC.DDN.MIL)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the NIC.DDN.MIL host [192.67.67.20]
using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************
    
                       TRANSITION OF NIC SERVICES


The transition of the Network Information Center from SRI
International in Menlo Park, CA, to Government Systems Inc. in
Chantilly, VA, is officially scheduled for 1 October 1991.  This
includes the transition of services currently offered to DDN and
Internet users by SRI, such as network/user registration, on-line
information services, and Help Desk operations.  SRI will continue to
provide all NIC services, to include responding to all user calls and
requests, until 30 September 1991.


DISA and GSI will make every effort to ensure a smooth and timely
transition of NIC services from SRI.  Network users should be
minimally impacted.  With a few minor exceptions, all on-line services
currently offered by SRI will appear the same to the user when a
connection is established to the new (GSI) NIC host.  These exceptions
are due to the change from the TOPS20 operating system to the SunOS
operating system.  The new NIC host is a Sun 470 SPARCserver running
SunOS 4.1.  All users on the DDN and the Internet should carefully
note the following changes:

U.S. Postal Address:      Government Systems, Inc.
                          Attn: Network Information Center
                          14200 Park Meadow Drive
                          Suite 200
                          Chantilly, VA  22021

Help Desk Telephone Numbers:

                          1-800-365-3642 (1-800-365-DNIC)
                          1-703-802-4535

Help Desk Hours of Operation:

                          7:00 am to 7:00 pm Eastern Standard Time


Fax Number:               1-703-802-8376

Network Address:          192.112.36.5 (NIC.DDN.MIL)

Root Domain Server:       192.112.36.4 (NS.NIC.DDN.MIL)

During the period of 26 to 30 September 1991 the ID (WHOIS) database
will not be changed.  All registration actions for this five day
period will be suspended.  This action is necessary in order to
transfer the master database to GSI.  Starting 26 September 1991, all
U.S. mail and fax requests should be addressed to the GSI address and
fax number shown above.  All electronic mail requests should continue
to be directed to the "HOSTMASTER" and "REGISTRAR" mailboxes at
NIC.DDN.MIL.  As appropriate, SRI will redirect electronic mail to
GSI.  On 1 October 1991 all registration activities will resume to
include the normal generation of DDN TAC access cards.
Currently-valid TAC access cards will remain valid until the normal
expiration date.

IMPORTANT!  Hosts not using the domain naming system should edit their
host tables prior to 1 October 1991 to reflect the change in GSI's
domain name DIIS.DDN.MIL (192.112.36.5) to NIC.DDN.MIL and delete the
current NIC.DDN.MIL (192.67.67.20) from their tables.  The GSI IP
address, 192.112.36.5, will not change and may be used in lieu of the
domain name.  GSI will re-generate all informational and network
tables (i.e., host tables) no later than 8 October 1991.  All tables
will be available using the same access method currently used to
download from the SRI NIC.

We hope that the transition and its accompanying changes will not
greatly inconvenience network users, and we thank you in advance for
your patience and understanding.  For general questions regarding the
transition, users may call the new NIC Help Desk after September 1,
1991 at 1-800-365-3642.  Questions regarding NIC operations policy
should be referred to Mr. Wil Pitre of DISA/DODS at (703) 692-2771
(DSN) 222-2771.  Questions regarding NIC contractual matters should be
referred to Mr. Tyrone Smallwood of DISA/DISCA.
-------

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:05:13 GMT
From:      flamer@endeavor.intel.com (Jim Trethewey)
To:        comp.protocols.tcp-ip
Subject:   Trouble w/ Clarkson SLIP packet driver + PC/TCP

Is anyone else using the PC/TCP generic SLIP kernel with the
Clarkson SLIP8250 packet driver with success?  I am not.

What I have:
   PC/TCP (PC-210) Version 2.05 from FTP Software, Inc.,
   The Clarkson packet driver SLIP8250.COM (included on Unsupported Disk A:),
   HCL (Hummingbird Communications Ltd.) eXceed/W (X server for MS-Win3.0),
   Microsoft Windows 3.00,
   MS-DOS 3.3,
   and a 386 pc.

My ultimate goal is to run the PC as an X terminal over SLIP to the UNIX 
client, and so far it works up to a point (the point at which the PC locks
up).
I am trying to SLIP on COM2: (IRQ3, IO_base 0x2f8, 9600 baud, 8-1-NONE) to
a UNIX PC (Intel 386 UNIX V.3.2 R2.2 + Lachman TCP/IP + X11R3).
On the PC, I do:

   slip8250 -w 0x60 -h 6 3 0x2f8 9600
   slpdrv -t 32 -p 16

It works as long as I don't stress it.  Under stress (ftp a >=30K file), it 
hangs.  Reducing the baud rate makes no difference (other than it's slower).  
Increasing the PC's buffers, e.g., with:

   slip8250 -w 0x60 -h 6 3 0x2f8 9600 20480 20480

only makes it take longer to hang.
I do have h/w (RTS/CTS) flow control on both ends.  The Clarkson SLIP8250.ASM
code that was provided appears only to WATCH CTS, I guess so it won't overdrive
the other guy (UNIX), but it never seems to drop RTS if its own buffers get
too full, so UNIX never throttles itself.

Is there a newer version of the Clarkson driver that implements RTS/CTS flow
control BOTH directions?  Or is there something else magical I was supposed
to do?

When the lock-up occurs, I get a message (from MS-Windows, I assume) like:

   I/O card parity interrupt at 24E3:04DC.
     Type (S)hut off NMI, (R)eboot, other keys to continue

I can also get it to fail in "plain" DOS doing an FTP, without MS-Windows
or the X server in the picture.

Anyone with experience to share?  I'd be most grateful.

--Jim Trethewey, $WORK = flamer@mithril.intel.com, $HOME = flamer@alfirin
 5200 NE Elam Young Parkway HF3-73, Hillsboro OR 97124-6497 (503)696-5444

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:19:47 GMT
From:      woodcock@mentor.cc.purdue.edu (Bruce Sterling Woodcock)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: Backups using rsh.

In article <1991Sep9.065337.6596@cs.sfu.ca> skl@cs.sfu.ca (Samuel Lam) writes:
>rsh(1) uses TCP, so it's as reliable as TCP is (whatever that
>means these days :-)).

It means it's more reliable than NFS, and an order of magnitude faster, at
least.  :)

Why don't all distributed filesystems simply use TCP/IP for data communication?

Bruce

-- 
------------------------ woodcock@mentor.cc.purdue.edu ------------------------
Yes.  We fuck.  Often, and with great enjoyment of the act.  We aren't married,
we use birth control, we use interesting little toys on occasion.  We moan like
beasts in heat.  Life is *great*.  -- Bryant, ref. to Erin, on alt.brother-jed.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 22:51:56 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Throughput

>That's impossible to achieve, it ignores inband formatting information
>(headers, CRC, pauses between packets) and other practical constraints.
>
>The theoretical maximum is a bit less than 1MB/s, and even that cannot
>in practice be achieved because the Ethernet is a simplex channel, and
>most protocols require ACKs every now and then, and thus in practice you
>cannot just pump data continuously from source to target with maximal
>size packets.
>
>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
>occasional bursts at 0.9MB/s.
>--
>Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
>Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
>

The overhead of Ethernet is effectively 38 bytes (8 bytes preamble, 14
bytes MAC header, 4 bytes FCS and 12 bytes interpacket time).

Then absolute theoretical maximum throughput follows.

For minimum sized packets (46 bytes of information) this gives:

    5.476Mb/s or 0.685 MB/s

for maximum sized packets (1500 bytes):

    9.752Mb/s or 1.219MB/s

Allowing 40 bytes for TCP/IP overhead for maximum sized gives:

    9.492Mb/s or 1.186MB/s

Art

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 91 23:00:24 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   (none)

Fellow netters:

I am writing asking for any information/opinions on TFTP....
I've heard lots of rumors and stories about the possible security
risks to be considered before enabling this option.  I'd like to
hear any good/bad stories, as well as any implementation concerns
that anyone has...

Thanks for your help,

Bryan Miller
Network Manager
Virginia Commonwealth University
bmiller@cabell.vcu.edu

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 01:44:43 GMT
From:      warb@faatcrl (Dan Warburton)
To:        comp.protocols.tcp-ip
Subject:   Re: Support of Multiple Logical Subnetwork by Routers

A563700@CUCSC.BITNET ("C.H. Cheng, The Chinese Univ. of Hong Kong") writes:

>Hi all,
 
>  Is there anyone running Multiple Logical (Sub)network successfully with
>other brand of bridging router?
 
>C.H. Cheng
>Computer Services Center
>The Chinese Univ of Hong Kong

We are using cisco AGS router with 6 ethernets and Multiple Logical Subnets
We have partitioned our Class C address with a four bit subnet. We avoid
subnet 0 and subnet F, Giving 14 subnets with 14 hosts (we aviod host 0 and hostF) . We assign multiple subnets to the same ethernet address when the number of
hosts exceeds fourteen or for logical (to us) reasons. Works Well. As does the
router.

-- 
+  Dan Warburton   Nas Simulation Support Facility (NSSF)                  
+                  Federal Aviation Administration Technical Center  
+                  Atlantic City International Airport, NJ 08405    //
+  609-484-4480    Mail Stop: ACN-313        Aikido        Amiga  \X/ Sun
+  warb@faatcrl.uucp  ...rutgers!faatcrl!warb   -- An Open Systems Group --

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 02:02:38 GMT
From:      lindner@cs.umn.edu (Paul Lindner)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Internet Gopher v0.2 Curses Client and Server is available


			 The Internet Gopher
		  A Distributed Information Service

	 Unix-Server, Curses-Client Release 0.2, 9 Sep. 1991

		       University of Minnesota
		  Computer and Information Services

The Internet Gopher is a distributed docuemnt delivery service.   It
allows a neophyte user to access various types of data residing on
multiple hosts in a seamless fashion.  This is accomplished by
presenting the user a hierarchical arrangement of documents and by
using a client-server communications model.  The Internet Gopher
Curses Client allows a user on a terminal to access the vast array of
information available on various gopher servers.  The Internet Gopher
Server accepts simple queries, and responds by sending the client a
document. 

Also included in the release are experimental clients and servers for
real-time radio, utilities for using gopher in shell scripts (written
in perl), and some sound utilities for NeXT machines.

Other Internet Gopher Software available includes:

Macintosh Gopher client written in HyperCard.
Macintosh Gopher Server software.
PC Gopher Client with a Borland Turbo Vision Interface.
Full Text Indexing servers for NeXT machines.
NeXT Gopher client (provided by Max Tardiveau of the University of St.
                    Thomas.) 

All of this software is available for anonymous ftp to
boombox.micro.umn.edu (128.101.95.95) in the /pub/gopher directory. 

The Internet Gopher Development Team can be reached via e-mail as
gopher@boombox.micro.umn.edu.  If you prefer paper we can be reached
at: 

Internet Gopher Team
132 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
-- 
 | Paul Lindner | lindner@boombox.micro.umn.edu   |"You have to spit
 |              | Computer & Information Services | to see the shine..."
 |             	| University of Minnesota         | -- Babes in Toyland
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 04:49:44 GMT
From:      wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
] The theoretical maximum is a bit less than 1MB/s, and even that cannot
] in practice be achieved because the Ethernet is a simplex channel, and
] most protocols require ACKs every now and then, and thus in practice you
Actually, if you're Van Jacobson, and have really high-tech equipment
(a pair of Sun 3/60s!) it's possible to achieve 8 Mbits/sec for
large-block file transfers by careful tuning.  The 3/60 had AMD LANCE
Ethernet chips - the 3/280 used Intel chips, and he could only get
about 5-6 Mbits/sec.

My first reaction to the request, however, was "Wow!  What is this
guy trying to accomplish?  Are PCs and Ethernets the right approach?
If he's got money to burn, why isn't he using FDDI?  Is this broadcast
data, or really point-to-point, or does he have one blazing-fast data
source that he's trying to store?  Is this data being stored to disk,
or just displayed on screens?  If it's being stored, how much is there?
Maybe you want one big machine with 100 MB RAM to store it and shove
it out gradually?"

Especially if the real application is broadcast, there's been a lot
of work on broadcast protocols.  Alternatively, as some people have
suggested, there are other networks such as SCSI that are cheap,
fast, and efficient.  How many machines are you trying to connect?

(NASA has some large data-shuffler that's basically a big multi-ported
memory box with a bunch of DMA connections to a bunch of buffers,
which they've used for some high-speed data applications;
I don't remember any details, since it's been about 3 years since I
read about the beast, but it was very hard to emulate with
non-custom approaches.)

Oh - cisco routers DO have a lot of bandwidth, at least in the large models -
I think it's the AGS-PLUS (we paint a Death Star on the front and 
sell it as the AT&T StarWAN 450).  The C-Bus backplane has a 533
Mbits/sec bandwidth, and the high-speed multiport Ethernet cards can
do essentially full bandwidth for (all? 4-6?) each port.
Most routers have traditionally been limited by their
packet-processing rate, but the newer products from cisco, Proteon,
and a few other people have fast enough processors to get beyond that.
The 450's packet-processing rate was something around 50-60kpps for
short packets, and being increased as they tuned the software,
but for this job you'd presumably use large packets so the problem
is bus bandwidth and memory buffers anyway - should be ok.

		Good luck!
-- 
				Pray for peace;      Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# "After all, the 'good of society' is based upon the 'rights of the individual.'
# Not the other way around, IMHO." -- Chris Preston

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 06:30:49 GMT
From:      torek@elf.ee.lbl.gov (Chris Torek)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

>torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
>That's impossible to achieve, it ignores inband formatting information
>(headers, CRC, pauses between packets) and other practical constraints.

This is true...

>The theoretical maximum is a bit less than 1MB/s, and even that cannot
>in practice be achieved because the Ethernet is a simplex channel ...

but this is not, quite.  (See below.)

>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
>occasional bursts at 0.9MB/s.

I beg to differ.  Here is a rerun of old tcp-ip mail.  I have quoted it
in its entirety because Van tends to get quoted out of context.  If you
reproduce this, you must either include the whole thing or get permission
from Van for your excerpting.

To: tcp-ip@nic.ddn.mil
Subject: saturating an ethernet from 1000 miles away
Date: Wed, 05 Jun 91 07:47:44 PDT
From: Van Jacobson <van@ee.lbl.gov>

A minor milestone in high-speed, long-haul networking happened
at the recent Educom National Net '91 conference in Washington,
DC:  TCP transfers from a Cray YMP at Pittsburgh Supercomputer
Center to a Sun Sparcstation-2 on the show floor ran at a
sustained rate of 10Mb/s (by `sustained' I mean sustained over
hundreds of megabytes of data transferred -- In one of the first
tests, we shipped 256MB from the PSC to DC in 3.9 minutes).  The
rough topology was:

	   FDDI            T3 backbone        Ethernet
	  100Mb/s            45Mb/s            10Mb/s
  PSC YMP -------> PSC ENSS --....--> DC ENSS ---------> SS-2

The limiting bandwidth was the show ethernet & we ran at that
bandwidth.  If we could have gotten in & out of the ENSS at >=
45Mb/s, we would have run at the 45Mb/s NSFNet backbone
bandwidth.  (Dave Borman's Cray TCP has been measured at over
300Mb/s.  My TCP on the SS-2 runs 48Mb/s through the loopback
interface (i.e., copying all the data twice, doing both sides of
the protocol & context switching on every packet) and should
easily sink or source >100Mb/s as soon as Sun comes up with a
decent high-speed network interface.)

The real milestone is that two completely independent
implementations of the RFC1072/RFC1185 "fat pipe" extensions,
one by Dave Borman of Cray Research for Unicos on the YMP & one
by me for an experimental TCP/IP running on the SS-2,
interoperated with no problems.  [This gave me no small measure
of joy:  Sun demonstrated their normal inability to supply system
source to academic sites & I didn't get a copy of 4.1.1 (the
only version of Sun OS that would run on a SS-2) until Friday of
the week before the show.  I spent a very long weekend
throwing out Sun's network & IPC code & replacing it with my
experimental 4.4BSD stuff and got a working kernel 45 minutes
before the movers came to crate up our lone Sparcstation-2 &
ship it from California to DC.  So the very first chance to
test my RFC1072 implementation against Dave Borman's was when we
got the machine uncrated & connected the SS-2 to the show net in
DC.  I was all resigned to another 36 hours of sleepless
debugging when, to my utter astonishment, the Cray &
Sparcstation flawlessly negotiated a 512KB window & timestamps,
then happily started exchanging data at a very high rate.
(Several other groups were busy setting up their demos.  I
started up my usual throughput test programs on the Cray & Sun
then looked down at the `recv' indicator light on the Cabletron
transceiver & noticed it was on solid -- I stared at it for at
least 30 seconds & it didn't even blink.  Right after that I
heard one of the Cornell people say ``What happened to the
network?  Our connection seems to have stopped.'' and I did my
best to look innocent while the test finished.)]

The big disappointment was that I was worried about what would
happen when the TCP congestion avoidance / recovery algorithms
started interacting with half a megabyte of stored energy
(in-transit data) in the pipe.  So I'd spend a bunch of time
tuning the Fast Retransmit and Fast Recovery algorithms & had a
bunch of instrumentation set up to watch how they'd perform.
But the damn T3 NSFNet refused to drop packets -- we shipped
slightly more than 30GB (roughly 22 million data packets) during
the three days of the show & the kernel network stats said that
6 were dropped.  Naturally, I wasn't watching for any of
these 6 & a 0.00003% loss rate wasn't enough test any of the
spiffy new algorithms.  Oh well, maybe next time I'll bring my
wire cutters and chop halfway through the cable to make things a
bit more interesting.

[The one interesting piece of behavior had to do with the
ethernet controller on the Sun:  The LANCE is a half-duplex
device so if it's receiving back-to-back ethernet packets it will
never attempt to transmit, even if it has data available to
send.  TCP will attempt to ack every other packet but, since new
data packets were arriving back-to-back from the ENSS, the ack
packets just got queued in the LANCE on the SS-2.  Since the
acks can't get out, eventually (after half a megabyte is sent)
the window on the Cray should close, it should stop sending
packets & the SS-2 should get to dump 180 back-to-back ack
packets, re-opening the window & restarting the data flow.  This
would have resulted in essentially the stop-and-wait performance
of a BLAST protocol but, fortunately, there seems to be a 128KB
buffer somewhere in the T3 NSFNet so after 90 data packets there
was a 30us pause, allowing the SS-2 LANCE to grab the ethernet,
dump 45 back-to-back acks, then start collecting the next 90
data packets.  So the window on the Cray never shut & the pipe
stayed full -- due to essentially an engineering mistake in the
network (a transcontinental T3 run at T3 needs at least half a
meg of buffer everywhere a queue can form).  This, incidentally,
is one reason why we used a half megabyte window instead of the
80KB window required to fill a 36ms RTT into 10Mb bandwidth-delay
product.]

Anyway, I'm writing this mostly to document that it happened &
to thank all the people at LBL, PSC, Merit, Cray & Sun that made
it happen.  I'm particularly grateful to Dave Borman for some
great Cray TCP software and to Geoff Baehr at Sun for battling
with the lawyers and getting us the system pieces we needed
(it's nice to know that at least part of Sun still ranks
engineering over bean counting).  And I am eternally grateful to
Wendy Huntoon of PSC & Elise Gerich of Merit who put in long,
long hours to get the new and almost untested PSC & NSF T3
connections up & running, then kept everything running smoothly
and essentially trouble free for the entire show.

 - Van Jacobson
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 07:38:58 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In <17380@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:

>>torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
 
>In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
>(Piercarlo Grandi) writes:
>>That's impossible to achieve, it ignores inband formatting information
>>(headers, CRC, pauses between packets) and other practical constraints.

Just following up Chris' reposting of Van's note.  If Van's note fails
to convince, one should read the paper by Boggs, Mogul and Kent in the
Proceedings of SIGCOMM '88.  They walk through the various models of
Ethernet and show that simplifying assumptions in some models cause
the models to understate the maximum bandwidth.  Also, they did some
real tests of bandwidth with various configurations of senders and
receivers that show the throughput rates.  My recollection is that
they showed a maximum practical rate (after headers et. al.) of a little
over 1 MByte/s.

Craig Partridge

PS: Yes, Boggs is Dave Boggs, of Metcalfe and Boggs, the Ethernet designers.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 09:08:27 GMT
From:      tjc@ecs.soton.ac.uk (Tim Chown)
To:        comp.protocols.tcp-ip
Subject:   Re: Western Digital's cards

In <4089@mtecv2.mty.itesm.mx> cgonzale@mtecv2.mty.itesm.mx writes:

>Does anybody know the difference between Western Digital's Ethercard Elite 16 Combo and WD8013EW cards ?
 
>We need an Ethernet card with 10BaseT & BNC media support in the same board but we are not shure about the correct model that we have to order.

Are they not one and the same thing?   The Combo cards we ordered all
had WD8013EW on a sticker on the back.  We're very happy with their
performance and compatibility with the free NCSA software.

	Tim
-- 

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 11:04:57 GMT
From:      and@kaija.spb.su (Victor A. Andreenko)
To:        comp.protocols.tcp-ip
Subject:   Locus TCP/IP for DOS and NE1000

Hi netters,

We have  Locus TCP-IP package for DOS, V1.0. Unfortunately
driver for Ethernet card Novell NE1000 is absent in
this distribution.  All drivers in this package have
named _*.drv_ and they are installed from _config.sys_
at boot time.

We have some questions:
    1) what type of driver used by this package ?
       Is some description of LOCUS TCP/IP drivers type ?
    2) Can we use PDS, NDIS or other drivers NE1000 by
       some other ways ?
    3) May we get LOCUS driver for NE1000 from anywhere ?

Any information appreciable.

Please send answers not only via USENET, but direct e-mail too.
-----------------------------------------------------------------------------
Victor A. Andreenko    e-mail internet: and@kaija.spb.su
Leningrad(St. Petersburg)        phone: office: +7 (812) 2941103,2983700
	USSR                              home: +7 (812) 2954347

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 14:04:53 GMT
From:      martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes:

>1) You have to turn on UDP checksumming if you connect two ethernets
>by a bridge rather than a router.  

This should say:

You don't have to turn on UDP checksumming if you connect two ethernets
by a bridge rather than a router. 

Joachim Carlo Santos Martillo Ajami

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 14:33:01 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   SLIP and PPP compared

> From: ...!visual!ssanbeg@ucbvax.Berkeley.EDU  (Scott Sanbeg)
> Subject: Building a LAN around OS/2 -- Newbie asks advice
> 
> Basically, I don't know if PPP is more efficient than SLIP, 

Here's something I have been wanting to post for a while and finally
found an excuse.  This really is a FAQ waiting to happen.

Efficient in which respect ?  effective throughput ? administration ?

In terms of data throughput, efficiency of a serial link is determined
more by the underlying hardware than the framing protocol.  A pair
of 9600 baud modems can only pass so many bytes.  Framing protocol 
overhead is a fairly minor factor (IMO).  SLIP has a (defacto) MTU 
of 1006 and two bytes of framing per frame.  Async PPP has a (defacto) MTU
of 1500 with 5-8 bytes of framing per frame.  Depending on how it 
is configured on site, PPP's special character escaping scheme may
increase its overhead.  

If you discount the byte stuffing, the two protocols are not far apart
in terms of maximal effective throughput (MTU size packets).  PPP will 
deliver *marginally* less throughput due to its slightly higher number 
of framing bytes (any extra byte stuffing a particular link is configured 
to perform will reduce PPP's effective throughput further).

As packet size decreases, effective throughput would tilt in favor of SLIP 
because the framing bytes become a larger proportion of the overall frame
size.  For highly interactive traffic (telnet) where packets are no larger
than say, 64 bytes, this becomes more pronounced, but even then, a best
case configuration put a PPP frame at only 3 bytes larger than an equivalent
SLIP frame.  (best case means: PPP header compression options on, Async Ctrl
Char Map is all zeroes).

Why PPP ?  more features:
  - Two of the framing bytes present in PPP but absent in SLIP are a type
	field used to demultiplex different network layer protocols.  This
	is a key feature for routers because SLIP links only pass IP
	traffic, no IPX, no DECNet, no ISO, etc.
  - Two other bytes are a frame check sequence which allows the frame 
  	integrity to be checked at the data link layer.
  - PPP can be configured to escape certain ctrl characters (0x00-0x1f)
  	which your data comm hardware may be sensitive to.
  - PPP provides an authentication capability (currently unencrypted, 
  	but encryption is being worked on in IETF).
  - PPP's IP configuration allows for IP addresses to be negotiated 
  	automatically.

Judge for yourself whether these features are necessary and worth 
the tradeoff's in performance and complexity.  Any answer to this 
is highly dependent on the context.  Your mileage will vary.

There are many other considerations:
    - There are more SLIP implementations in the field (plus more mature)
    - The performance differences described are fairly thin (IMO)
    - Not all PPP implementations offer all of the features I describe above
    - Not all PPP implementations are async, many are sync (faster because
    	invariably much of the framing is processed by hardware)

    my $0.02 (don't spend it all in one place),

        - GL

}} Gordon Lee                 FTP Software Inc
}} voice: (617) 246-0900      26 Princess St
}} fax:   (617) 245-7943      Wakefield, MA  01880

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 14:52:48 GMT
From:      utterbac@husc9.harvard.edu (Margot Utterback)
To:        comp.protocols.tcp-ip
Subject:   Need the LPD protocol

Murphy strikes again!  Just because the last time someone posted the location
of a document describing the lpd protocol I decided not to get it, now I 
desperately need it.  Such is life! (heavy sigh) Anyway, can some kind
soul point me to such a document?  Thanks very much in advance.
Please e-mail because I need it ASAP.  

utterbac@husc.harvard.edu

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 15:49:12 GMT
From:      bg18215@hawaii.sbi.com (Beth Gilbrech)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP Accounting Software

Am interested in any tcp/ip accounting utilities that might
be available:  commercial, public domain or otherwise.  We 
need to keep track of #/packets sent to particular ip addresses
and other obscure details over here.

Any and all info would be appreciated.
--

Beth Gilbrech                           net:    bg18215@hawaii.sbi.com
Salomon Technology Services             phone:  1-201/896-7340
Systems Engineering - Network Software  fax:    1-201/460-0674

**An employee and not a spokesperson for Salomon Brothers, Inc.**

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 17:48:58 GMT
From:      aninda@bach.ecse.rpi.edu (Aninda Dasgupta)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on OS/2

IBM has an excellent TCP/IP offering, including source code and many
example programs.  There are a number of other vendors offering this
package .

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 17:59:11 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.


I just love a good opening... ;-)

torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).

Piercarlo>That's impossible to achieve, it ignores inband formatting
Piercarlo>...
Piercarlo>practical constraints. 
Piercarlo>...
Piercarlo>The theoretical maximum is a bit less than 1MB/s, and even
Piercarlo>...
Piercarlo>packets. 

Well, I decided to do some back-o-lope calculations a little while
back, and came-up with something on the order of 1128-1130 KB/s for
TCP over Ethernet. This was based on min gaps and pre-ambles and such.
BTW, that is user-level thruput... 

Piercarlo>The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
Piercarlo>occasional bursts at 0.9MB/s.

Well, then folks like HP and Sun (I have to be egalitarian ;-) must have
the very very best Ethernet sw ;-) as I have seen HP 700's do 1100KB/s
sustained and SS2's do 1063KB/s sustained. And that's released product...

rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | "It's so fast, that _______" ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 18:13:39 GMT
From:      jal@acc.flint.umich.edu (John Lauro)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9185229@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>cpcahil> Throughput is not the only evaluation factor for a disk
>cpcahil> controller.  Another factor, which is where a good EISA
>cpcahil> controller will shine, is the amount of time the bus is tied up
>cpcahil> transferring that 4MB/s.
>
>Latency then perhaps matters. But in practice not a lot...
>
>cpcahil> You yourself said that the theoretical max for the ISA bus was
>cpcahil> between 5 and 6 MB/s.  4MB/s is appox 80% of the theoretical
>cpcahil> max.
>
>Of course, but this is nearly irrelevant. Almost nobody keeps their SCSI
>bus running at its top rated bandwidth continuously (not even Adaptec,
>which stay off the bus for some programmable fraction of the time).
>
>In particular disk access tends, in normal operation, to be bursty (the
>effect of caching and paging, and then of intervening seeks).
>

That's because the CPU is too busy waiting for the controllers (disk and
ethernet) to accept the data so it can work on getting something else
ready to send.  Even if no single piece is any faster, it frees the
processor that much quicker.  Granted, under dos you will not notice
any significat difference.  A Novell 386 server, or Unix, etc... will
take advantage of it.

I don't think anyone listed all the specs for Cisco routers.  Here are some
more for the AGS+.  They demonstrated protype software in October 1990 that
could forward more than 74,000 pps total in multiple streams.  The reason
for these speeds, is it's possible to put over 24 ethernet ports on
these boxes, or FDDI.  There is a 16 MIPS Bit Slice processor per interface
card, the main CPU is a 30 Mhz 60020, and the C-BUS controller also has a
16 MIPS processor.

Back to the original topic...  If a dedicated 10Mbs per computer is
wanted, he would save much money with high speed bridges.  There are some
that can take upto 7 ports and handle full ethernet speed on all ports.
By using multiple bridges you could have any number of available ports.
These devices cost considerably less than an equally equiped router.
Routers are best to keep the broadcasts down, but if you have only a small
number of machines per segment, than that isn't needed.

Also if he was considering anything less than an AGS+ (even an AGS) then
it would probabbly be better not to use any router at all if the number
of machines is sufficiently small.  (Was the number ever stated?)

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 19:12:46 GMT
From:      deb.kocsis@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Merit/NSFNET Seminar Announcement

Dear Moderator:
 
Please forward this seminar announcement to the mailing list you
moderate if appropriate and of interest to your readers.  If you
no longer moderate this list, please reply with the new moderator
if you have contact information for that person.
 
Thank you.
 
Merit/NSFNET Information Services
 
 ------------------------------------------------------------ 
 Please pass on the announcement below to interested parties 
 where appropriate.  Hard-copy brochures are available for your 
 colleagues not-yet attached by sending us their postal address or 
 calling 1-800-66-MERIT or (313) 936-3000. 
 
 Thank you. 
 
 ----------------------------------------------------------- 
 
 
 The Merit Networking Seminars: 
 
 Making Your NSFNET Connection Count 
 ------------------------------------------------------------ 
 
 Merit/NSFNET Information Services is committed to providing 
 current information on national networking to all users of the 
 NSFNET and the Internet. Toward this end we will sponsor a one-and- 
 a-half day seminar in College Park, Maryland on November 11-12, 
 hosted by SURANet. "Making Your NSFNET Connection Count" will be 
 an informative seminar focusing on Internet tools, resources, and 
 applications. Campus computing leaders, information systems and 
 networking administrators, educational liaisons, librarians, and 
 educators who want to learn more about national networking are 
 encouraged to attend. 
 
 Day 1, Real People Doing Real Things With Networking, will feature a 
 number of presentations concerning network applications in 
 education from the elementary grades through the college level. The 
 Day 1 activities will begin with a keynote address by Stephen Wolff, 
 Director of the Division of Networking, Communications, and 
 Research Infrastructure of the National Science Foundation. 
 
 Day 2, Network Tools and Futures, will provide attendees with 
 information on the tools and resources available on the Internet. Day 
 2 will also include information on directory services for people and 
 applications on the Internet, as well as parallel sessions for special 
 interests in internetworking, gigabit technology, and K-12 
 networking. The seminar will conclude with a presentation on the 
 National Research and Education Network (NREN)  and its pending 
 legislation by Mike Nelson, Professional Staff Member, United States 
 Senate Committee on Commerce, Science, and Transportation. 
 
 The seminar will be held at the University College of the University 
 of Maryland.  Microcomputers connected through SURAnet to NSFNET 
 and the Internet will be available on-site so that attendees may 
 access network resources discussed in the presentations. The 
 registration fee is $295 until November 1. Registrations received 
 after that date should include $345. This fee includes the seminar, 
 receptions on Sunday and Monday evenings, lunch on Monday and 
 Tuesday, the demonstration room, and all seminar materials. 
 
 For further information and a complete agenda send an electronic 
 message to seminar@merit.edu or telephone 1-800-66-MERIT, or 
 (313) 936-3000. 
 

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 20:12:00 GMT
From:      JOHNGALT@CCIT.ARIZONA.EDU (John Galt)
To:        comp.protocols.tcp-ip
Subject:   Need help choosing PCROUTE/KA9Q/SLIP/PPP/V.32bis/V.42bis...

Hello,

I am trying to connect two physically separate ethernet segments together.
One segment is located in a project office which is located about eight
miles as the phone flies from the district office which has the other segment.

Originally, before I started work in this office, a bridge and DSU/CSU
combination was purchased.  We recently received the equipment, two NAT
bridges and two Astrocom DSU/CSU combinations.  I called our local phone
company, US West, and requested that the line be put in.  WELL, they told
me that the price had gone up on July 15.  Originally, the line was to cost
~$740.00 to install and then $180.00 per month (this is for a 56K line).  As
of the price increase, however, the installation cost is $1000.00 and the
monthly charge is $720.00!!!!!!!

Flame on.
This is a 400% increase!  I thought deregulation was supposed to stop this
kind of thing!  I may have to blame it on our local "Arizona Corporation
Commission" which seems to be a rubber stamp regulatory organization.
Flame off.

We can't afford the monthly charge on this line, so I decided to connect
us in a different way.

KUDOS:
The people at NAT were very helpful.  They gave us a couple alternative ideas
and, when that didn't work for us, they allowed us to return the bridges.
If I ever get a chance to do business with NAT again, I will gladly give
them first shot at anything.  If you ever need ethernet bridges or monitoring
tools, look into them.  I dealt with Jim Huang at (800) 543-8887.

On the other hand, I am still waiting for a call back from Astrocomm, and I
have left messages...

Back to the problem:

After reading as much material as I can get my hands on, I think the best
solution for us is to use a PPP or SLIP line with V.32bis and V.42bis modems.
I want to connect one of these modems to each ethernet segment, either
directly on the back of one of our UNIX boxes (we have Data General AViiON
300's), or to a dedicated PC running PCRoute or KA9Q.  To tell the truth, I
don't care for the DG's, so I would rather stick with the PC's.  Any opinions
on this idea?

Now the questions:

Has anyone used either PCRoute or KA9Q for this purpose?  I think PCRoute
only supports SLIP, where KA9Q supports PPP.  Theoretically this would be
an advantage, but is there a practical difference?  I only need to talk
TCP/IP, so I won't need the multiple protocol capabilities of PPP.  If there
is no real advantage to PPP over SLIP, then should I stick with PCRoute?

What about hardware?  That is, what ethernet board should I use?  PCRoute
only seems to support certain boards.  What about the speed of a packet
driver interface?  I have read that it is much slower than direct access.
Is this going to be a practical limitation?

Should I stick with an 8088 or get a 80286 based computer?  If I was routing
two ethernet segments directly, it would seem to be an advantage to get the
286.  Since I will be connecting to a serial line, do I need the extra power
of the 286?

And what type serial port board should I use?  I want to be able to use the
port at 38.4 or 57.6K.  The documentation recommends a board with the 16550
chip.  Is this something that just plugs into the 8250 slot?  What about
something like the Digiboard intelligent port boards?

Anybody have experience with the V.32bis/V.42bis modems?  The Digicomm seems
pretty good, and is cheaper than either the CODEX or AT&T.  The Hayes doesn't
even seem to meet the V.32 spec (the specs say "ping-pong to simulate V.32").
What about other V.32bis modems?
  
Thanks very much in advance for any information you can send to me.  Please
reply directly to me and I will summarize if there is interest.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  "Dr. John Galt"                Internet : johngalt@ccit.arizona.edu   %
%  U.S. Geological Survey         BITNET   : johngalt@arizrvax           %
%  P.O. Box 3328                  Voice    : (602) 623-5444              %
%  Tucson, AZ 85722                                                      %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 21:25:33 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes:
>
>Ah yes, Yet Another Serial Protocol (YASP).  Pretty soon its going to
>be like IBM in the 60's and early 70's when they had about 100
>different variations of bisync, all mutually incompatible.
>
   Think of it as job security Brian.  And remember what
   happened to IBM when their "future site" model resulted in
   SNA with 7 incompatible LU types....all they did was move the
   incompatibility above the link layer...

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 91 23:01:35 GMT
From:      coolidge@speaker.wpd.sgi.com (Don Coolidge)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Throughput

In article <1991Sep9.225156.22053@salt.acc.com>, art@opal.acc.com (Art Berggreen) writes:
|> >That's impossible to achieve, it ignores inband formatting information
|> >(headers, CRC, pauses between packets) and other practical constraints.
|> >
|> >The theoretical maximum is a bit less than 1MB/s, and even that cannot
|> >in practice be achieved because the Ethernet is a simplex channel, and
|> >most protocols require ACKs every now and then, and thus in practice you
|> >cannot just pump data continuously from source to target with maximal
|> >size packets.
|> >
|> >The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
|> >occasional bursts at 0.9MB/s.

Ummm...I've been measuring the TCP throughput of several of our (SGI)
Ethernet interfaces lately, and all of them come in higher than that.
Using ttcp -s, I get from 0.905MB/s (VME expander interface) to 
1.079 MB/s . Perhaps you'd consider reviewing your figures?  :^)
 
|> The overhead of Ethernet is effectively 38 bytes (8 bytes preamble, 14
|> bytes MAC header, 4 bytes FCS and 12 bytes interpacket time).
|> 
|> Then absolute theoretical maximum throughput follows.
|> 
|> For minimum sized packets (46 bytes of information) this gives:
|> 
|>     5.476Mb/s or 0.685 MB/s
|> 
|> for maximum sized packets (1500 bytes):
|> 
|>     9.752Mb/s or 1.219MB/s
|> 
|> Allowing 40 bytes for TCP/IP overhead for maximum sized gives:
|> 
|>     9.492Mb/s or 1.186MB/s

That's a good UDP number.

TCP/IP overhead is actually a bit higher - you have to account for
ACKs. That would be 3*(38+40) per 3000 bytes (two MTU packets, one
ACK), or 0.86505*10Mb/s theoretical TCP throughput. That's 1.081 MB/s.
I'd say that at 1.079, SGI is doing pretty well...

- Don Coolidge
coolidge@sgi.com

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 03:51:18 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
 > torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
 > 
 > That's impossible to achieve, it ignores inband formatting information
 > (headers, CRC, pauses between packets) and other practical constraints.
 > 
 > The theoretical maximum is a bit less than 1MB/s, ...

You weren't listing earlier.  The theoretical maximum is 1.218 Mbytes/sec of
payload (user data) using maximum frame sizes and minimum delays.  See article
<1175@dumbcat.sf.ca.us> if you need to see how the bits up.  (This rate is
provided at only 812 packets/second.  That's plenty of time to handle headers,
CRCs, etc.

 > and even that cannot
 > in practice be achieved because the Ethernet is a simplex channel, and
 > most protocols require ACKs every now and then, and thus in practice you
 > cannot just pump data continuously from source to target with maximal
 > size packets.

True, but we're playing the specsmanship game here, aren't we?

// marc
-- 
marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 13:05:58 GMT
From:      et@ajk.tele.fi (Eero Torri)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   "Open Systems Security" document available



This is a forwarded message from Arto Karila:

--------------------------------------------------------------------------
In June I posted a note about my study "Open Systems Security - 
an Architectural Framework" which I made available through the Internet
on our host "ajk.tele.fi". The paper deals with security architectures
for open systems and is applicable to both OSI and DoD Internet.

The paper aroused lots of interest. Unfortunately the quality of service
provided by our host was rather bad last summer because we were changing
machines. Also, many people complained that they had difficulties printing
the document which was in post script format.

A slightly updated version of the document is now available in (hopefully)
more standard post script format which should print on printers other than
the Apple LaserWriter too. Our host is now running a lot better and the
paper is also available on one of best managed ftp servers "nic.funet.fi".
I hope this has solved most of the problems.

So, the paper is now available with anonymous FTP at two locations:

host: ajk.tele.fi, file: PublicDocuments/OpenSystemsSecurity.tar.Z

host: nic.funet.fi, file: pub/doc/security/karila/OpenSystemsSecurity.ps.Z

The format is compressed post script, page size A4, length over 100 pages.


--
Arto Karila              + INTERNET: atk@ajk.tele.fi
Telecom Finland          + TEL     : +358 0 704 2000
Business Systems R&D     + FAX     : +358 0 704 2712
P.O. Box 140
00511 HELSINKI

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

-- 
Eero Torri               + INTERNET: et@ajk.tele.fi
TELE/Palvelukehitys      + TELEBOX : spp482
Elim{enkatu 8            + TEL     : +358 0 704 2973
00511 HELSINKI           + FAX     : +358 0 704 2712

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 16:21:16 GMT
From:      booloo@lll-crg.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.arch
Subject:   Speed of memory and fast networks (was: Need help selecting Enet cards)

In article <1991Sep2.152344.14037@aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>
>Just to give people an idea of the numbers involved, here is a transcript of
>a quick test done on the local DECsystem 5830, which has got a screamingly
>fast (20-25MIPS) 25Mhz R3000 CPU:
>
>    Script started on Mon Sep  2 16:04:31 1991
 [ code deleted ]
>    $ time ./copy
>	    8.3 real         7.0 user         0.1 sys  
>
>I read 7 seconds for copying 64MB, or almost 10MB/s. This is reading and
>writing, with no processing. Maybe this 25Mhz R3000 CPU can beat a CISCO
>router bandwidth only if one does simply reads from its own cache, so let's
>have a look at just reading:
>
 [ code deleted ]
>    $ time ./read
>	    4.8 real         4.1 user         0.0 sys  
>
>That's a tad over 4 seconds for 64MB, or 16MB/s.
>

There is currently some work going on here attempting to design a gigabit
switch based on the (developing) FiberChannel standard.  One of my colleagues
is involved in this work and we have been having discussions regarding who
can make use of gigabit data rates.  The argument put forth by my colleague
is that memory speed on most computers is so slow that, when using a protocol
like TCP which typically (most common implementations) touches memory at least
three times (DMA into memory and copy from kernel to user space - I didn't count
the checksum), high data rates to the application just aren't possible.

For example, we measured the memory speed of a Vax 6310 at around 8 MBytes/sec.
If memory is touched three times for a TCP connection, that means a maximum
possible data rate of less than 3 MBytes/sec.  So even if we have a HiPPI
connection on this machine, we aren't going to do any better than 3 MB/sec.

Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec.  And that
means a maximum achievable TCP rate of less than 6 MB/sec.  That isn't fast
enough to justify hanging a 5830 on a gigabit network.  And that's a long way
from saturating an FDDI ring.

It seems that supercomputers (e.g. Cray Y/MP) use very fast memory and can
achieve very high throughput rates.  Are these the only machines that can take
(direct) advantage of gigabit/FDDI data rates?  Using a gigabit net for a 
backbone is one aspect but being able to deliver a gigabit rate to an 
application seems a pipe dream for most of the current (less than super)
computer architectures.  I don't claim to be an expert (ex - one who has been;
spurt - a small drip :-) when it comes to architecture and I don't know what
all is out there, but my impression is that memory speeds need to come way up
in order to make use (at the application level) of fast networks.  

Additionally, a protocol such as TCP needs to be better "integrated" within
a given architecture.  For example, reducing the number of copies by eliminating
the kernel/user space copy, and performing the checksum in parallel with a 
copy rather than requiring a memory access just to calculate the checksum are
sorely needed.  

I guess what I'd like to know and hear comments on is whether there are any
architectures out there (other than Cray/Fujitsu/NEC) that can actually take
advantage of high-speed networks (FDDI and up)?

Thanks in advance,
mb
---
Mark Boolootian		booloo@lll-crg.llnl.gov		+1 415-423-1948

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 17:10:02 GMT
From:      pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE)
To:        comp.protocols.tcp-ip
Subject:   SLIP (or PPP) over switched network

I would like to establish dynamically a link between two IP network
using a public switched network (ISDN or Phone). A call should be made
when there is a packet to forward, and also the circuit should be released
after some idle time (for obvious financial reasons).

Is it possible to do this with curent implementations of SLIP or PPP?
I know that there are similar products for IP over X25.
I would prefer free software...

Thanks  for any help

jean-jacques pansiot
Universite Louis Pasteur Strasbourg, France
pansiot@isis.u-strasbg.fr

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 19:29:00 GMT
From:      rml0@harvey.gte.com (Robert Long)
To:        bit.listserv.ibm-nets,comp.protocols.tcp-ip,comp.sys.hp,comp.protocols.ibm,comp.dcom.lans
Subject:   Searching for interconnect between 3270 terminals and UNIX host

I am in search of a hardware or software solution to the
following problem...

I have an HP 9000 platform with HP-UX hosting a character based
(VT100) application. This platform has Async, Ethernet and X.25
connections which accomodate incoming terminal sessions via
Dial-in, Telnet-TCP/IP and X.3/X.25.
                            My Platform

+-------+       +--------+        ~~~~~~~           +-----+    *--*
| HP    |-------| X.25   |      {  X.25  }       +--|Modem|-----/\
| 9000  |---+   | Switch |-----{   PSDN   }      |  +-----+
+-------+   |   +--------+      {~~~~~~~~}    +--+-----------+
            |                               +-|TerminalServer|
            |                               | +--------------+
            |                               |
     |------+------------Ethernet-----------+-------------------|

This satsifies the needs of all of my prospective users except
for one. This user is sitting in front of a real 3270 terminal,
attached to a 3274, attached to a 3745, attached to a 3090 IBM
host.

                  My external Customer/User
+------+      +------+       +------+       +------+
| 3270 |------| 3274 |-------| 3745 |-------| 3090 |
| Term |      | Clus |       |  FEP |       | Host |
+------+      +------+       +------+       +------+

I want to give access to the VT100-based application running on
the HP9000 from the 3270 bound user. I want to avoid asking them
to install an application on their 3090. Therefore I am focusing
on the downstream pieces (i.e. FEP and Cluster Controller). I am
aware of options for 3274-like controllers from AT&T/Memorex that
connect to an Ethernet and provide VT100 emulation over Telnet to
TCP/IP hosts, but this can't be considered because their current
controllers don't support the option and they won't trade them
out.

I could consider DEC's DECserver 510 or 550, but these come out
LAT instead of Telnet - and then I would need a router or such to
get the traffic back to my HP9000.

I have 3090 hosts and an SNA network of my own and would consider
making additions to it to accomplish these connections. I want to
avoid requiring my external user to run their 3090's MIPs to
accomplish this (like running STX under MVS - going out to NPSI
in the 3745). But, I would consider running these on my own
machines to accomodate them.

Well, any insights - hints - or products? I will definitely post
any solutions offered!

My Thanks,

Bob Long
GTE Telephone Operations   P.O. Box 290152
IM Technology              Mail Code S5-A
                           Temple Terrace, FL 33687
---------------------------------------------------
813/979-3219 -Voice               FAX- 813/979-3259
R.LONG/GTE -SprintMail       Internet- rml0@gte.com
---------------------------------------------------
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bob Long                              rml0@gte.com
GTE Telephone Operations              Tampa, FLorida

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 20:22:49 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

I have been reading this thread (and others elsewhere regarding
"SLITHERNET") with some interest.  What I have yet to understand is
how SLITHERNET is better than PPP (especially since there are so many
PPP implementations now and I have never seen a SLITHERNET
implementation).

As for regionals forcing people to buy a particular vendor's router to
connect to the regional network; that is falling by the wayside.
There are many people who are buying Telebit NetBlazers and running
dedicated sync PPP links to Alternet's cisco routers (that is how we
talk to Alternet here).  Also most of the other IP router vendors are
offering PPP so they can interoperate on point-to-point links too.
The requirement for PPP is becoming part of the router requirements
doc as well.  Why muddy the water with another nonstandard?

-- 
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 22:59:39 GMT
From:      martillo@jjmhome.UUCP (Joachim Martillo)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <169385@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes:
> In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes:
 
> >Ah yes, Yet Another Serial Protocol (YASP).  Pretty soon its going to
> >be like IBM in the 60's and early 70's when they had about 100
> >different variations of bisync, all mutually incompatible.
 
>    Think of it as job security Brian.  And remember what
>    happened to IBM when their "future site" model resulted in
>    SNA with 7 incompatible LU types....all they did was move the
>    incompatibility above the link layer...

Of course, a better way to view the issue is to note that 
the promulgation of PPP is based on a fundamentally silly idea that a single
protocol can solve all problems for all times on very diverse media over
a very wide range of speeds.  Further, even if we accept this ridiculous
premise, PPP is fundamentatlly misdesigned with all sorts of goop built
into the protocol which simply doesn't belong there, ridiculous FSA's and
one of the most moronic methods of tunneling which I have ever perused.

Somehow promulgating attrocities like PPP looks more motivated by a hidden
agenda to guarantee job security than suggesting a reasonable alternative.

Joachim Carlo Santos Martillo Ajami

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 23:16:50 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Need the LPD protocol

In article <1991Sep10.105250.3239@husc3.harvard.edu>,
 utterbac@husc9.harvard.edu (Margot Utterback) wrote:
>... the last time someone posted the location of a document describing
>the lpd protocol I decided not to get it, now I desperately need it.

It's RFC 1179, and is available at all the usual RFC outlets..

1179  McLaughlin, L.  Line printer daemon protocol.  1990 August; 14 p.
      (Format: TXT=24324 bytes)

...Sam
-- 
<skl@cs.sfu.ca>

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 91 23:28:09 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" document available

Arto Karila (atk@ajk.tele.fi) writes:

>In June I posted a note about my study "Open Systems Security - 
>an Architectural Framework" which I made available through the Internet
>on our host "ajk.tele.fi". The paper deals with security architectures
>for open systems and is applicable to both OSI and DoD Internet.
>
>The paper aroused lots of interest. Unfortunately the quality of service
>provided by our host was rather bad last summer because we were changing
>machines. Also, many people complained that they had difficulties printing
>the document which was in post script format.
>
>A slightly updated version of the document is now available in (hopefully)
>more standard post script format which should print on printers other than
>the Apple LaserWriter too. Our host is now running a lot better and the
>paper is also available on one of best managed ftp servers "nic.funet.fi".
>I hope this has solved most of the problems.
>
>So, the paper is now available with anonymous FTP at two locations:
>...
>The format is compressed post script, page size A4, length over 100 pages.

It is available in the USA;
anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.ps.Z
(The link between Finland and the USA was in fact quite slow, 920 bytes/sec.)
- Dan Kegel (dank@blacks.jpl.nasa.gov)

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 03:39:38 GMT
From:      paulb@mlacus.oz.au (Paul Bandler)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,acus.general,comp.protocols.ibm
Subject:   TELNET & 3270 (tnv3270?) - Request For Information

I need some information about 3270 terminal emulation over a TCP/IP network,
including product availability.

I've seen discussion on these groups about products which do 3270 emulation
over TCP/IP networks, however I'm unclear exactly how they work.  

I assume that they somehow map a 3270 data stream over a Telnet data stream?  

That being the case, if I have a PC with such a Telnet/3270 product, what 
requirement, if any, does this place on the 3270 host to have a peer entity?

Does, say IBM, supply a 3270/Telnet server which receives this data stream
and directs it into the normal 3270 data path?  

If so, where does this server run, in the host or in a Front End Processor?

Can anyone offer comment on the performance of such a terminal network?  Is it
a feasible solution for a large terminal network?  How does is compare say with
say a solution which uses a communications server to convert into a real 3270/
bisynch stream before reaching the host?

Thanks in advance for any information.  Please reply by email rather than
posting as postings take a long time to trickle down this way.

Regards,

Paul Bandler
ACUS - Australian Centre for Unisys Software

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 05:24:05 GMT
From:      shaw@pegasus.com (Sandy Shaw)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   ftp text conversion

I recently wrecked some non-text files by ftp'ing from a system where
the fact that I had forgot to use the binary command caused some type of
text conversion to take place. Unfortunately, the original files are no
longer available. The conversion performed did not affect the length of the
files. Does anyone out there know what type of conversion has been done
and if it is reversible? Help!

shaw@pegasus.com

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 05:44:52 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
+---------------
| On 3 Sep 91 04:56:41 GMT, torek@elf.ee.lbl.gov (Chris Torek) said:
| torek> Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
| 
| That's impossible to achieve, it ignores inband formatting information
| (headers, CRC, pauses between packets) and other practical constraints.
+---------------

True, but you can get a lot closer than you seem to think. See below...

+---------------
| The theoretical maximum is a bit less than 1MB/s, and even that cannot
| in practice be achieved because the Ethernet is a simplex channel, and
| most protocols require ACKs every now and then, and thus in practice you
| cannot just pump data continuously from source to target with maximal
| size packets.
+---------------

The data rate within a packet is 1.25 MB/s. I fear you are overstating
the amount of overhead.

+---------------
| The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
| occasional bursts at 0.9MB/s.
+---------------

Hah! Our slowest systems (SGI Irix 4D/25's) can *sustain* over 0.95 MB/s
of *user* data bytes from one Unix process to another via standard TCP/IP,
and faster systems (e.g., a pair of 4D/340's) can *sustain* 1.075 MB/s.
I know, because I measured it again just a moment ago, to be sure. The
systems involved were normal equipment, the same as customers would get,
*not* in single-user mode, *were* running the X server, *were* running
the usual assortment of daemon processes [routed, mrouted, timed, inetd,
&c.], but had no heavy users except my "ttcp" job. [Oh, yes, and they
were running the just-released Irix version 4.0 software.]

I am told by our TCP developers that using the optional "IO3" I/O board
(I only had "IO2"s on my 340's), running "single-user" with no graphics or
daemons running, and with an idle net (there were 20+ other stations on
my local net doing routed and timed, &c.), they have sustained 1.100 MB/s.
O.k., so I only got 1.075 MB/s; it was under non-ideal conditions... ;-}

Let's look at what you should be able to sustain theoretically, given fast
enough hardware and software. Most Berkeley-based TCPs will transmit one
ACK per two data packets, with default window settings. The 64-bit Ethernet
preamble is 8 bytes, and the 9.6us inter-packet gap is equivalent to 96/8 =
12 bytes.  So:

     pre dst src type IP/TCP  data  CRC IPG
Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538
Data: 8 + 6 + 6 + 2 + 20+20 + 1460 + 4 + 12 = 1518 + 20 = 1538
Ack:  8 + 6 + 6 + 2 + 20+20 + 0+(20)+4 + 12 =   64 + 20 =   84
                              ====                        ====
                              2920                        3160

There are 2920 user data bytes (not including the "pad" to bring the ACK up
to the minimum Ethernet packet size) moved per 3160 byte-times on the wire,
which is (2920/3160)*1.25 = 1.155 MB/s of *user* data, process-to-process.

If you open your TCP window size all the way to 64 KB, you'd need one ACK
per 44 packets, but to keep things moving smoothly you'd need two ACKs per
window, or one ACK per 22 data packets = 1460/(1538 + (84/22)) = 1.18 MB/s.
Now *that's* the maximum sustainable!


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 05:46:12 GMT
From:      wbe@bbn.com (Winston Edmond)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" document available


   Even after playing with the PostScript directly to try to get things to
work, I'm still unable to get this paper to print properly.  I had at least
some success with the 'tar' file version from ajk.tele.fi, but I had no
success at all getting the version from blacks.jpl.nasa.gov (which matched
the version from nic.funet.fi) to print.  I've sent details to Arto.
 -WBE

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 06:12:30 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

1.094 MB/s
In <17380@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) says:
+---------------
| Actually, Ethernet is 1.25 MB/s (10 over 8 = 1.25, not 0.8).
|
| (Piercarlo Grandi) writes:
| >The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
| >occasional bursts at 0.9MB/s.
| 
| I beg to differ.  Here is a rerun of old tcp-ip mail.  I have quoted it
| in its entirety because Van tends to get quoted out of context...
+---------------

If you look carefully at Van's fine article quoted by Chris, you will see
that the size/time he reports for a large file transfer equates to 1.094 MB/s.
Gee, awfully close to the 1.1 MB/s I claimed for SGI boxes. Multiple people
getting the same result with various hardwares. Must be real. ;-}

-Rob

p.s. This fall's Interop is going to be fun. Who's got the best "ttcp"
number over FDDI, I wonder...?

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 07:45:59 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.sysv386,comp.unix.wizards
Subject:   Fastest FDDI at Interop?

In <lbiue4o@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:

>p.s. This fall's Interop is going to be fun. Who's got the best "ttcp"
>number over FDDI, I wonder...?

My bet is that the winner won't be the folks with the fastest software but
the folks with the fastest FDDI interface -- most of the folks who have
FDDI boards in the works or in production only seem to get about 40 to
50 Mbits/second out of the board.

As a back of the envelope calculation, I took Clark et. al.'s performance
paper from IEEE Communications Magazine in 1989 and figured that a conservative
estimate is that a packet costs about 1,000 instructions + the number of
instructions to do the checksum.  So figure you can do the TCP checksum in
a one instruction per 2 bytes (also conservative) and use 8Kbyte FDDI maximum
packet sizes and you get a bit over 5,000 instructions per packet for
processing.  Take a machine of between 10 and 20 MIPS and your software
ought to crack 100Mbit/sec.  (Note this calculation isn't perfect --
there's some operating system overhead like timers and schedulers that
can eat into the amount of cycles available for protocols).

Craig

PS: You can do similar calculations and figure TP4/CLNP ought to be doing
around 50Mbits or so, even though its checksum is somewhat more intensive
than TCP's to compute.  So while at Interop, you can also reasonably
ask the OSI software houses to show how fast *their* stuff runs over FDDI.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 09:44:04 GMT
From:      glaser@custine.crin.fr (Norbert Glaser)
To:        comp.protocols.tcp-ip
Subject:   Server sources

Hi,

I'm looking for public available tcp-ip server sources for unix V.

Thank's !

Norbert

-------------------------------------------------------------------------------
CCCC  RRR   I  N   N  Campus Scientifique         Norbert Glaser, Office 705
C     R  R  I  NN  N  B.P. 239                    Tel.: (+33) 83.91.20.00
C     RRR   I  N N N  F-54506 Vandoeuvre-Cedex                Ext. 26.67
CCCC  R  R  I  N  NN  France                      FAX : (+33) 83.41.30.79
-------------------------------------------------------------------------------
>       "Toutes les grandes personnes ont d'abord e'te' des enfants.          <
>        Mais peu d'entre elles s'en souviennent."  (Saint-Exupe'ry)          <
-------------------------------------------------------------------------------

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 12:24:06 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>There is currently some work going on here attempting to design a gigabit
>switch based on the (developing) FiberChannel standard.  One of my colleagues
>is involved in this work and we have been having discussions regarding who
>can make use of gigabit data rates.  The argument put forth by my colleague
>is that memory speed on most computers is so slow that, when using a protocol
>like TCP which typically (most common implementations) touches memory at least
>three times (DMA into memory and copy from kernel to user space - I didn't count
>the checksum), high data rates to the application just aren't possible.
I disagree. Read on.

>For example, we measured the memory speed of a Vax 6310 at around 8 MBytes/sec.
>If memory is touched three times for a TCP connection, that means a maximum
>possible data rate of less than 3 MBytes/sec.  So even if we have a HiPPI
>connection on this machine, we aren't going to do any better than 3 MB/sec.
I disagree about some points. I've measured memory speed (buswidth) of
certain machines and found numbers such as 20 MB/sec for suns and 
about 35 MB/sec for IBM RS6000 (520 one of the slowests).
So this will deliver about 11-12 MBytes/sec transfer rate!

>Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec.  And that
>means a maximum achievable TCP rate of less than 6 MB/sec.  That isn't fast
>enough to justify hanging a 5830 on a gigabit network.  And that's a long way
>from saturating an FDDI ring.
Put 10 IBM RS6000's on a HiPPI ring and it is full with data.
Other measurements have shown that 10 suns can fill FDDI with a transferrate
of 6MBytes/sec each. Totalling 60Mbytes/sec!!

>It seems that supercomputers (e.g. Cray Y/MP) use very fast memory and can
>achieve very high throughput rates.  Are these the only machines that can take
>(direct) advantage of gigabit/FDDI data rates?  Using a gigabit net for a 
>backbone is one aspect but being able to deliver a gigabit rate to an 
>application seems a pipe dream for most of the current (less than super)
>computer architectures.  I don't claim to be an expert (ex - one who has been;
>spurt - a small drip :-) when it comes to architecture and I don't know what
>all is out there, but my impression is that memory speeds need to come way up
>in order to make use (at the application level) of fast networks.  
Indeed why do we have a pipe across networks for application to application
connection which is many times faster than memory and the machine itself?
answer: because networks are shared amongst users, machines, applications,
you named it.

>Additionally, a protocol such as TCP needs to be better "integrated" within
>a given architecture.  For example, reducing the number of copies by eliminating
>the kernel/user space copy, and performing the checksum in parallel with a 
>copy rather than requiring a memory access just to calculate the checksum are
>sorely needed.  
These tricks are being done. But measurements have shown that TCP isn't
that much trouble.

>I guess what I'd like to know and hear comments on is whether there are any
>architectures out there (other than Cray/Fujitsu/NEC) that can actually take
>advantage of high-speed networks (FDDI and up)?
It is usefull for situations where a small number of hosts can
fill the network easily. Take some RS6000's and use them as image
viewing stations, connect them to a distributed image data base and
see how ethernet is completely stuffed.
(Ethernet just to connect two stations is fast enough for the images.)

Conclusion, keep up the good works of designing, implementing,
testing, measuring and standardizing of very fast networks.
Especially for non-backbone situations.

>Thanks in advance,
>mb
>---
>Mark Boolootian		booloo@lll-crg.llnl.gov		+1 415-423-1948
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 13:40:12 GMT
From:      jra@lawday.DaytonOH.NCR.COM (John R. Ackermann)
To:        comp.protocols.tcp-ip
Subject:   configuring ftp site

I'm trying to set up a minor ftp site and don't know what the standard
directory structure is that most anonymous users would expect.

Also, our implementation of ftp doesn't (at least not yet) support a
user name of "anonymous".  What alternative names are common for
anonymous ftp?

Thanks.
-- 
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		      John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv      tcp/ip: ag9v@ag9v.ampr [44.70.12.34]

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 13:48:49 GMT
From:      fingerhu@ircam.fr (Michel Fingerhut)
To:        comp.protocols.tcp-ip,eunet.misc
Subject:   The shortest way from Paris to the UK is...

traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40 byte packets
 1  ircam-gw (129.102.0.1)  10 ms  10 ms  0 ms
 2  fnet-gw.inria.fr (192.44.64.26)  4290 ms  3910 ms  1130 ms
 3  sophia-gw.inria.fr (192.93.1.1)  590 ms  680 ms  1240 ms
 4  icm-sophia.atlantic.fr (192.33.170.10)  1710 ms  1190 ms  1730 ms
 5  148.52.2.1 (148.52.2.1)  2820 ms  340 ms *
 6  NSS.TN.CORNELL.EDU (192.35.82.100)  4790 ms  1120 ms  590 ms
 7  Ithaca.NY.NSS.NSF.NET (129.140.10.13)  700 ms  800 ms  830 ms
 8  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.10)  660 ms  1390 ms  2220 ms
 9  Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13)  2740 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.77)  1840 ms Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13)  2340 ms
10  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.17)  2770 ms  3940 ms  4450 ms
11  * Salt_Lake_City.UT.NSS.NSF.NET (129.140.15.12)  4810 ms  700 ms
12  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  690 ms  1760 ms  2220 ms
13  Palo_Alto.CA.NSS.NSF.NET (129.140.13.16)  2730 ms Palo_Alto.CA.NSS.NSF.NET (129.140.13.80)  3400 ms Palo_Alto.CA.NSS.NSF.NET (129.140.13.16)  3930 ms
14  Palo_Alto.CA.NSS.NSF.NET (129.140.13.130)  2790 ms  1210 ms  710 ms
15  AMES.TWB.NET (192.52.195.28)  540 ms  580 ms  2470 ms
16  * * *
17  * 192.80.6.1 (192.80.6.1)  3000 ms  2040 ms
18  cisco.ulcc.ac.uk (128.86.1.2)  2750 ms  3470 ms  3930 ms
19  * *

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 17:16:51 GMT
From:      jeffs@novell.com (Jeff Seideman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   poll on Pop usage

I am trying to find out if POP servers really are installed on
networks.  I would appreciate if you would take the time and
email your answers to the following questions:


Does your network mail host include a POP server?  Was it pur-
chased with the host, or obtained separately?

If obtained separately, was it public domain or a purchased pro-
duct?  In either case, how can I obtain it?

If so, does it use the POP-2 or POP-3 protocol?

If POP-3, how  does it deviate from the POP-3 standard?  ie.
Does its command list differ from the following:

*    USER name:  login              return:  +OK, -ERR
*    PASS pwd:  password            return:  +OK, -ERR
*    STAT:  summary                 return:  +OK #msgs #bytes
*    LIST [#]:  summary             return:  +OK (summary), -ERR
*    RETR #:  read msg              return:  +OK (msg), -ERR
*    DELE #:  delete msg            return:  +OK, -ERR
*    NOOP:  handshake               return:  +OK
*    LAST:  hightes access          return:  +OK #
*    RSET:  undo marks              return:  +OK
*    TOP # #:  retrieve msg lines   return:  +OK (msg), -ERR
*    RPOP name:  remote login       return:  +OK, -ERR
*    QUIT:  end session             return:  +OK

If POP-2, how  does it deviate from the POP-2 standard?
ie.  Does its command list differ from the following:

*    HELO name password:  login             return:  +OK, -ERR
*    FOLD folder:  specify folder/mailbox   return:  #msgs, -ERR
*    READ [#]:  begin reading msg           return:  =size
*    RETR:  retrieve msg                    return:  msg
*    ACKS:  ack & save                      return:  =size next
*    ACKD:  ack & delete                    return:  =size next
*    NACK:  not received                    return:  =size
*    QUIT:  end session                     return: +OK

thanks:
 +-----------------------------------------------------------------------+
 |                    Jeff Seideman:  jeffs@novell.com                   |
 +-----------------------------------------------------------------------+

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 17:19:07 GMT
From:      jeffs@novell.com (Jeff Seideman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   poll on BSD Unix mailers

I am trying to find out if there is any kind of standard Unix
mailer that is being used, or at least if there is one whose
use is widespread enough to approach being a standard.  I would
appreciate if you would take the time and email your answers to
the following questions:


Do your Unix hosts use the BSD mailer, or any other command line
mailer?  If so, does its command list include the following:

*      d [message list]:  delete msgs
*      m [user list]:  mail to list
*      n:  read next message
*      q:  end session
*      s:  [message list] file:  append messages to file
*      u:  [message list]:  undelete messages
*      w:  [message list] file:  same as s, w/o the "from" line
*      x:  quit and forget marks
*      z [-]:  read next [previous] page of headers

thanks:
 +-----------------------------------------------------------------------+
 |                    Jeff Seideman:  jeffs@novell.com                   |
 +-----------------------------------------------------------------------+

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 17:36:35 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

martillo@jjmhome.UUCP (Joachim Martillo) writes:


>Of course, a better way to view the issue is to note that 
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.
 
>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.
 
>Joachim Carlo Santos Martillo Ajami

You are right, PPP is a bit more complex than it needs to be (FSM,
etc.).  On the other hand, it works and works very well for most
point-to-point circuits over which people transmit the datagrams of
unreliable networks.  There are methods for transferring IP,
Appletalk, CLNP, IPX, and DECnet.  It supports communications between
MAC layer bridges.  It has the support of many people, users and
vendors alike.  There exist many interoperable implementations.  It is
going to be a router requirement.  You are swimming against the tide.

Hey, c'mon now.  There are things that I would like to see done
differently in various protocols in the Internet Protocol Suite.  That
doesn't mean that I reject and spurn IP just because I think that I
can do it better.  Perhaps PPP would have been more to your liking had
you participated in the design, specification, and implementation
process.  I guarantee you that everyone who has done an implementation
has generated input that has helped extend PPP and make it more
useful.

One last point: I have used PPP on everything from a 1200 bps async
dial-up link to a dedicated T1 link and it works very well in all the
cases that I have encountered (real-world that is with real modems,
DSU/CSUs, and telco-supplied links).  The proof of the pudding is in
the tasting, don't you think?

-- 
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 17:45:51 GMT
From:      sandee@Think.COM (Daan Sandee)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: ftp text conversion

In article <1991Sep12.052405.27189@pegasus.com>, shaw@pegasus.com (Sandy Shaw) writes:
|> I recently wrecked some non-text files by ftp'ing from a system where
|> the fact that I had forgot to use the binary command caused some type of
|> text conversion to take place. Unfortunately, the original files are no
|> longer available. The conversion performed did not affect the length of the
|> files. Does anyone out there know what type of conversion has been done
|> and if it is reversible? Help!
|> 
|> shaw@pegasus.com

Anything might have happened, depending on what system you were ftp'ing from,
and which system you are ftp'ing to, neither of which you name.
Without that information, nobody can help you.
One tip : ftp the files back to the same system.
Okay, so you don't have write privileges there.
So ftp the files back to *another* similar system.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 18:43:04 GMT
From:      6500elli@ucsbuxa.ucsb.edu (James A Elespuru)
To:        comp.protocols.tcp-ip
Subject:   Which protocol is used with rp?

The subject says it.  Which protocol is used for
data transmitions with a remote printer (ie FTP?
telnet? UDP?).

Thanks

Don. C.Itoh Technology, Irvine,CA.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 18:43:49 GMT
From:      dadams@awawa.Ebay.Sun.COM (Don Adams  Secure Products Syst Eng Sun Federal)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" document available

I had similar luck with the same version.

Don Adams

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 18:51:47 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: ftp text conversion

In article <1991Sep12.052405.27189@pegasus.com> shaw@pegasus.com (Sandy Shaw) writes:
>I recently wrecked some non-text files by ftp'ing from a system where
>the fact that I had forgot to use the binary command caused some type of
>text conversion to take place. Unfortunately, the original files are no
>longer available. The conversion performed did not affect the length of the
>files. Does anyone out there know what type of conversion has been done
>and if it is reversible? Help!

The conversions depend on the OSes running on the two systems.  The general
idea is that the sending system converts the text into a standard format,
and the receiving system converts from that into its own format.  The most
common conversions have to do with newlines.  The standard format uses CR
followed LF as the newline indication, and CR followed by NUL in place of a
bare CR (so that a CR followed by LF in the original file can be
distinguished).  If the sending system uses LF as its newline indication,
it will insert a CR before every LF in the file when transmitting it, and
add a NUL after any CR in the file.  If the receiving system uses CR as its
newline indication, it will replace every CR/LF pair with CR; what it
should do with CR/NUL is unclear.

Sometimes the conversions are reversible, other times they aren't.  For
instance, in the above example, if the receiving system translates CR/NUL
to LF, the conversion is invertible -- replace all CRs with LF and vice
versa.  But if CR/NUL is translated to anything else, then this character
becomes ambiguous in the resulting file; you can't tell whether it was
originally a CR or that character.

-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 19:39:42 GMT
From:      mikes@cascade.ens.tek.com (Mike Skrydlak)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:

>Of course, a better way to view the issue is to note that 
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.
>
>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.
>
>Joachim Carlo Santos Martillo Ajami

I, as a customer, want to have routers/whatevers from different vendors be
able to talk to each other & route/whatever various protocol-type packets.
To achieve this 'multiple vendor choice' scenario, I want a 'standard'
protocol to do this, and perform 'adequately'. It doesn't have to be perfect.
Few things are, especially when designed by committee. I believe many other
customers feel this way.

If PPP does this, most customers will forgive it's flaws.
And I believe they will view most criticisms at this point as 
  'Too little, too late'.  That's life.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 91 20:14:18 GMT
From:      plcochet@nysnet.nys.GOV (Peter L. Cochetti)
To:        comp.protocols.tcp-ip
Subject:   SLIP DRIVER for ATT 3B2/Wollongong TCP/IP

Is there a SLIP drive which will work on an ATT 3B2-1000/80 using the
Win/3b tcpip?  No one at either ATT or Wollongong seems to know! I guess
the answer is no....does anyone else have it?         

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 02:28:35 GMT
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" document available

In article <WBE.91Sep11224612@crystal.bbn.com>, wbe@bbn (Winston Edmond) writes:
>   Even after playing with the PostScript directly to try to get things to
>work, I'm still unable to get this paper to print properly.  I had at least
>some success with the 'tar' file version from ajk.tele.fi, but I had no
>success at all getting the version from blacks.jpl.nasa.gov (which matched
>the version from nic.funet.fi) to print.  I've sent details to Arto.

The version on funic was dated Aug 27; that's probably the original
unfixed version (the tar on ajk.tele.fi was dated 29 Aug).

After Arto's second announcement, I had troubles connecting to
ajk.tele.fi from nic.funet.fi (and still do, looks like an
over-paranoid router somewhere) so I wasn't able to update the
document on nic.funet.fi.  When I tried from a .hut machine just now,
it worked, so now the documents is

pub/doc/security/karila/OpenSystemsSecurity.tar.Z

at host nic.funet.fi.

I haven't printed the document but the stuff in the tar.Z distribution
seems to work with Ghostscript 2.2, so I suppose it's correct.  The
file OpenSystemsSecurity.ps doesn't work at all with Ghostscript 2.2.

The old (non-working) version of the document is in
pub/doc/security/karila/old.

//Jyrki

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 04:57:17 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Forwarding of broadcast packets

I have been using Netwatch to observe ethernet packets to learn what exactly
is happening. I have observed the following behaviour which seems rather
unsociable to me, and would appreciate comments from others. We have a class
B network with 8 bits of subnet, multiple logical subnets on the one
backbone. The vast majority of hosts think they are on a non-subnetted net,
3 unix hosts with another interface connected to a physical subnet & two
cisco routers know better. Also some AEG's route to localtalk Macs & 2 PC's
route to Banyan Vines networks. The backbone is wholly bridged.
What concerns me is this: whenever a host broadcasts at the ethernet level,
(RIP update, rwho, packets to a particular IP address where host only knows
a default net to send to...),(but *not* ARP), four other hosts repeat that
packet, sending it to a destination of '00ffbad1dead', and also sending an
ICMP redirect to the original source. Two hosts are non-gateway RS6000's,
one is a gatewaying Sun clone running 4.1.1, the other is one of the Banyan
PC's. What is common to these?
In the case of the RS6000's, I know how to stop this - there are network
options of 'ipsendredirects' & 'ipforwarding' which are *on by default*,
which is totally contrary to RFC1122, and there's no way a nongateway host
should *ever* send a redirect! But what about the others?
As well, my gatewayed RS6000 responds to some packets by sending ICMP
unreachables (not just one, but between 3 & 8 at a time!!) back to the
source. I'm not certain, but I think it's reacting to the IP address of
x.y.255.255 which the other (dumb, nonsubnetted) hosts use. (And all the
rebroadcasts mentioned above compound the fault!  But anyway, even
though my host *is* subnetted, it should recognise that as an 'all subnets
broadcast', shouldn't it? I would appreciate comments before I report this
to IBM. 
Also, how can I accurately match a machine's response to the packet that
caused it, using only Netwatch & perhaps PCAnalyse?  Am I asking too much?
Thanks in advance for any advice

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 05:50:59 GMT
From:      Andy.Linton@comp.vuw.ac.nz (Andy Linton)
To:        comp.protocols.tcp-ip,eunet.misc
Subject:   Re: The shortest way from Paris to the UK is...


In article <1991Sep12.134849.1337@ircam.fr>, fingerhu@ircam.fr (Michel
Fingerhut) writes:
|> traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40
|> byte packets
|>  1  ircam-gw (129.102.0.1)  10 ms  10 ms  0 ms
|>  2  fnet-gw.inria.fr (192.44.64.26)  4290 ms  3910 ms  1130 ms
|>  3  sophia-gw.inria.fr (192.93.1.1)  590 ms  680 ms  1240 ms
|>  4  icm-sophia.atlantic.fr (192.33.170.10)  1710 ms  1190 ms  1730
|> ms
|>  5  148.52.2.1 (148.52.2.1)  2820 ms  340 ms *
|>  6  NSS.TN.CORNELL.EDU (192.35.82.100)  4790 ms  1120 ms  590 ms
|>  7  Ithaca.NY.NSS.NSF.NET (129.140.10.13)  700 ms  800 ms  830 ms
|>  8  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.10)  660 ms  1390 ms  2220
|> ms
|>  9  Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13)  2740 ms
|> Ann_Arbor.MI.NSS.NSF.NET (129.140.17.77)  1840 ms
|> Ann_Arbor.MI.NSS.NSF.NET (129.140.17.13)  2340 ms
|> 10  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.17)  2770 ms  3940 ms 
|> 4450 ms
|> 11  * Salt_Lake_City.UT.NSS.NSF.NET (129.140.15.12)  4810 ms  700 ms
|> 12  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  690 ms  1760 ms  2220
|> ms
|> 13  Palo_Alto.CA.NSS.NSF.NET (129.140.13.16)  2730 ms
|> Palo_Alto.CA.NSS.NSF.NET (129.140.13.80)  3400 ms
|> Palo_Alto.CA.NSS.NSF.NET (129.140.13.16)  3930 ms
|> 14  Palo_Alto.CA.NSS.NSF.NET (129.140.13.130)  2790 ms  1210 ms  710
|> ms
|> 15  AMES.TWB.NET (192.52.195.28)  540 ms  580 ms  2470 ms
|> 16  * * *
|> 17  * 192.80.6.1 (192.80.6.1)  3000 ms  2040 ms
|> 18  cisco.ulcc.ac.uk (128.86.1.2)  2750 ms  3470 ms  3930 ms
|> 19  * *


Compare this with our path!

traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 38
byte packets
 1  ngauranga (130.195.6.1)  6 ms  5 ms
 2  csc.net.vuw.ac.nz (130.195.1.1)  12 ms  7 ms
 3  gw-vuw.waikato.kawaihiko.net.nz (140.200.216.1)  58 ms  35 ms
 4  feba-aotearoa.waikato.paccom.net.nz (130.217.64.1)  63 ms  85 ms
 5  arc2.nsn.nasa.gov (132.160.254.1)  736 ms  694 ms
 6  ARC1.NSN.NASA.GOV (192.52.195.2)  699 ms  700 ms
 7  GSFC1.NSN.NASA.GOV (128.161.2.3)  779 ms  780 ms
 8  ULCC.NSN.NASA.GOV (128.161.65.59)  869 ms  871 ms
 9  cisco.ulcc.ac.uk (128.86.1.2)  905 ms (ttl=239!)  893 ms (ttl=239!)
10  * *

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 11:40:43 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
To: samsung!crackers!martillo@zaphod.mps.ohio-state.edu (Martillo)
Date: Fri, 13 Sep 91 7:40:42 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
Reply-To: scoggin@delmarva.com
In-Reply-To: <2424@crackers.clearpoint.com>; from "Martillo" at Aug 31, 91 2:31 am
X-Mailer: ELM [version 2.3 PL11]

> 
> The following memorandum is a first draft of one of a pair of potential
> RFCs which specify a methodology for using wide-area serial synchronous
> DCE/DTE-type point-to-point links as a computer networking medium.  The
> Clearpoint Little Dipper/Auriga product line offer as one of several
> configurable options a wide-area interface which implements this
> specification, and should a developer implement this interface for his
> bridge, router or end host, that network device will be able to
> communicate with the Little Dipper/Auriga products over point-to-point

If this is a "potential RFC", why isn't it being handled as an Internet
Draft?  Also, maybe you should change the name (to be consistent with the
networking community's love of acronyms) to YAPPP - Yet Another Point-to-
Point Protocol.  

Seriously, if PPP is deficient, shouldn't we create a Working Group to
revisit point-to-point protocols in general?  I don't really think the
RFC process was created for the purpose of "legitimizing" proprietary
protocols.  A lot of companies are starting to point to RFC xyz and saying
that their product meets an RFC; nevermind that the IETF lists the protocol
and that RFC as Experimental or Not Recommended...


----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 11:54:51 GMT
From:      srwmcln@windy.dsir.govt.nz
To:        comp.protocols.tcp-ip
Subject:   Wanted:PD IBM PC Telnet/Ethernet terminal server s/w.

I have a friend who is interested in PD software to turn a IBM PC into a
Telnet/Ethernet terminal server for (say) 20 terminals. Whats out there?.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 15:11:16 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   Cabletron Prod. Support Stinks

Does anyone else have comments about Cabletron's product support.  We have
had incredibly bad luck with returns for repair (the need for repair is
another story!).  On two occasions, units have been returned for repair
with proper RMA/RA numbers and on two occasions the receiving department
claims that they have never received the devices.  (ATTENTION:  Upcoming
Plug For My Own Company!)  Thank goodness that Federal Express has 
deliver records with someone's name on it.  However, even after this,
the support people will not call back.  We call and leave messages and
it is like the message goes the way of the RMA numbers - into a black hole.

Is this uniquely our problem or have others experienced this sort of 
behavior from their product support?  We bought Cabletron products based
upon their reputation (which due to failures in the H/W we have yet
to experience just how good their products are!).  I have egg on my face
because of my recommendations that we try their stuff.  This is absolutely
the only TCP/IP - ethernet equipment that we have used that didn't just
go plug and play.

The first problem encountered was with the NB25E bridge.  Right out of the
box, it generated massive collisions and gunk on the net.  We finally 
were able to make the MAGIC cable needed to connect the console port of
the bridge to a terminal (why are VTx00 and ADDS the only ones supported?)
and set up the characteristics that we wanted to play with.  When I say
MAGIC cable, I mean MAGIC cable;  No "standard" RS-232 sort of config will
work.  It has to have some semi-bizarre combo of H/W signaling.  Even after
this the bridge still generated massive (*&^ on the net.  OK, infant 
mortality, get an RMA and back to the factory it goes.  After being lost
and not worked on for a week or two, it is finally returned and "fixed".
Something was indeed broken in the unit.  Now it comes back and our MAGIC
console cable won't work.  Back to the factory where "Mr. Fixit" tells
us that our cable is built wrong.  We need to have a couple of pins 
moved around into positions that don't match anything in print or match
anything ever built by anyone around here where there are decades of 
experience making serial devices talk.  "OK, send it back to us please with
the cable corrected."  Guess what?  Still no talkie on the console.
With no console, the bridge configuration cannot be set up.  We can't
ping the bridge or talk SNMP to it.  It leaves us totally blind which is
not acceptable in our environment.

In the meantime, port 7 on the MT-800 (a DELNI clone) has given up the 
ghost.  Get the RMA.  Send it to Cabletron.  Receiving claims they have
never seen it.  Deja vu all over again?  They will not return our
calls.

This is the most frustrating experience that we have ever gone through
with a H/W vendor.  We aren't even being kissed on the cheek and told
everything will be o.k. while we wait much longer than necessary.


Are we just being picked on?

bill daniels
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 17:26:11 GMT
From:      wlb@memstvx1.memst.edu
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP software needed for SUN

Hello,

     I need some help either locating or modifying software for Proxy
ARP.  We have a class B network, 141.225.0.0, for our campus.  We are
connected to SURAnet via a Proteon router.  We have assigned subnet
numbers for different building/departments but have not enabled
subnetting campuswide.  Our Engineering department has now acquired
second ethernet cards for 2 of their SUNs and wants to subnet.  I
need to find software (Proxy ARP) to allow the SUN to answer ARP
requests for the workstations on the subnet that the non-subnetted
hosts do not know about.

     I perfer to find something at no cost, but would be willing to 
purchase a commercial package if nothing free is available.  I can
FTP to sites on the Internet, so that would be the best source if
the software is out there.

Thanks in advance,

Bill Brown
Systems Programmer/Postmaster/Network flunky
Memphis State University

wlb@memstvx1.memst.edu
wlb@memstvx1.bitnet

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 17:53:03 GMT
From:      Sam.Wilson@ed.ac.uk
To:        comp.protocols.tcp-ip,eunet.misc
Subject:   Re: The shortest way from Paris to the UK is...

Well, we can't help it if France's routing is messed up! :-)

[ from cancer.ucs.ed.ac.uk - 129.215.200.7 ]

cancer: 54) traceroute 129.102.0.1
traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 40 byte packets
 1  129.215.200.253 (129.215.200.253)  4 ms  4 ms  3 ms
 2  gw.ulcc.ja.net (146.97.112.4)  125 ms  107 ms  97 ms
 3  cisco.ulcc.ac.uk (128.86.1.2)  102 ms  108 ms  122 ms
 4  hef-router.nikhef.nl (192.16.192.176)  691 ms  789 ms  2494 ms
 5  Amsterdam.Nl.EU.net (192.87.4.20)  713 ms  773 ms  1044 ms
 6  134.222.2.2 (134.222.2.2)  796 ms  502 ms  504 ms
 7  fnet-gw.inria.fr (192.93.1.108)  582 ms  401 ms  763 ms
 8  * * *
     :
     :
     :
30  * * *

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 20:28:04 GMT
From:      steve+@andrew.cmu.edu (Stephen Webster)
To:        comp.protocols.tcp-ip
Subject:   tn6530 anybody?

Hey all, have you heard of (or do you have) a Telnet that emulates one of
those old Tandem 6530 terminals?  Doesn't matter what it runs on, I'll buy
the box; just got to have it.

Please burble by email.  I can't be trusted to read any newsgroup regularly.

thanks,
-steve webster

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 20:46:02 GMT
From:      solomon@becks.comm.mot.com (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   What are the sources of UDP packet errors?


Greetings:

Take the hypothetical situation of three hosts connected via Ethernet.  
No bridges, routers, gateways ... no nothin', except these three hosts:  
A, B, and C.  Let's say A sends B a UDP packet.

Now, if we assume that the Ethernet tranceivers and the IP code in all hosts
are working properly, can we *ever* get an error at the UDP layer (that is, an
error detected solely by the UDP checksum)?  If the answer to this is, *yes*,
please enumerate the reasons why such an error could occur.  [I'm after reasons 
that help shed some light on the process of computer communications, not things
like ``the UDP code is hosed'' ;-)]

What if we release the restrictions above, namely, place these hosts on
separate networks, connected via routers (whose Ethernet drivers are also
functioning properly).  Are the sources of error now simply those inherent in
connection-less network layer service, i.e., lossed packets, duplicated
packets, etc?

Any insight into this matter is greatly appreciated.  Thanks,
--
Jim Solomon (solomon@becks.comm.mot.com)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 21:08:53 GMT
From:      petri@digiw.fi (Petri Alhola)
To:        comp.protocols.tcp-ip
Subject:   Public TCP/IP networks info Wanted

We are here in Finland building with our local unix users group (fuug)
public accessible TCP/IP based network based in dial up lines.
It used async modem lines eith 9600..19200 with SLIP and 64K
ISDN lines with ppp. I am personaly involved to project by developping
the software used in 64K bit links.

I like to get more information about similar projects in other countiries
where is build this kind of publisly accessible internet like networks
that are not limited only to large companies and univerities. As i know
there is alternet in usa that is one similar.

The information that i like to get is, how they are organized, what
is policy to joining them, what it costs, how they are implemented,
how they uses dialup and fixged lines.

I am also intrested to get pointers where i can ftp more information.

Petri Alhola
petri@digiw.fi

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 21:24:39 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Router security features

At a user group meeting yesterday, the topic of discussion was network
security and "firewall" routers.  We had an engineer from a local
TCP/IP vendor come in and discuss the details of their router software
with us.

In order to encourage more commercial enterprises (like my company) to
connect with Internet, network security issues have to be addressed in
a more cost-effective and less labor-intensive way than in the past.  At
this meeting, a couple of people wanted to be able to tie into the network
using an inexpensive piece of DOS-based router software which had
some fairly simple security features in place.  The engineer for this
vendor claimed that "no" router has these features as of this date.

Routers currently operate strictly at Level 3 (IP, beneath TCP).  IP
datagram headers do not contain the information necessary to screen
network traffic for security purposes, unless all you want to do is allow
and disallow traffic between particular IP addresses (a fairly useless
idea).

Current Internet thinking is that network security should be host-based
rather than network-based.  A number of companies therefore put one host
on Internet and run a local network on the other side of this "firewall".
Employees must either walk over to that host system or remote login to
it in order to access Internet.  I really don't like that approach.

But in order to provide host-based security features in a modern
environment of distributed workstations, one per desktop (especially given
the freely-available TCP/IP software one can use under DOS), the security
administrator has to worry about a far greater number of hosts than in
the past.  When I worked for DEC/Marlboro ten years ago, there was exactly
one computer on ARPAnet.  Today, given the same number of employees and
similar (but new) equipment, there would be perhaps 500 desktop systems
which could run TCP/IP and theoretically be connected to Internet.

Is it possible to implement a port-number-based TCP/IP security filter
within a router?  (This could be configured to only allow certain types
of connects to go through, etc.)  If it's possible, can it be done without
unduly slowing performance down or adding cost?  Is it reasonable to
expect router vendors to provide this, in the absence of an RFC standard
to do it?  Is there an RFC working committee already addressing this
issue (generally, network-based rather than host-based security)?

If this can't be done in a router, I would assert that any other approach
would add latency to packet-forwarding time, because the router (or
equivalent functionality in a Unix-based host) is usually a given when
connecting to Internet, and a separate box would add a second hop to
network connections.

By the way, I'm talking about low-cost software-based routers in the
$1,000-5,000 range, not whiz-bang models beyond the price-range of small
companies.

-rich

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 91 22:21:47 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: [alt.security] Re: "Open Systems Security" document available

I wrote:
>Arto Karila (atk@ajk.tele.fi) writes:
>>In June I posted a note about my study "Open Systems Security - 
>>an Architectural Framework" which I made available through the Internet
>>on our host "ajk.tele.fi". The paper deals with security architectures
>>for open systems and is applicable to both OSI and DoD Internet.
>It is available in the USA;
>anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.ps.Z
>(The link between Finland and the USA was in fact quite slow, 920 bytes/sec.)
>- Dan Kegel (dank@blacks.jpl.nasa.gov)

This file, downloaded from nic.funet.fi in binary mode, did not print 
properly, so I have downloaded the files from ajk.tele.fi.  Get them with
anon FTP to blacks.jpl.nasa.gov, dir pub/karila, file OpenSystemsSecurity.tar.Z
and/or OpenSystemsSecurity.txt.Z.
- Dan K.

-r--r--r--  1 dank       246271 Sep 11 16:32 OpenSystemsSecurity.ps.Z
-r--r--r--  1 dank       346316 Sep 13 15:16 OpenSystemsSecurity.tar.Z
-r--r--r--  1 dank       115683 Sep 13 15:17 OpenSystemsSecurity.txt.Z
-r--r--r--  1 dank         3432 Sep 13 15:21 README

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 05:28:34 GMT
From:      ron@npd.Novell.COM (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the sources of UDP packet errors?

In article <1991Sep13.204602.18573@ecs.comm.mot.com> solomon@becks.comm.mot.com (James Solomon) writes:

>Now, if we assume that the Ethernet tranceivers and the IP code in all hosts
>are working properly, can we *ever* get an error at the UDP layer (that is, an
>error detected solely by the UDP checksum)?  If the answer to this is, *yes*,
>please enumerate the reasons why such an error could occur. [I'm after reasons 
>that help shed some light on the process of computer communications, not things
>like ``the UDP code is hosed'' ;-)]

The UDP checksum is there to detect errors not detected elsewhere such
as at the Ethernet data link level.  If you make the hypothetical
assumption that there will never be any failures anywhere in your
hardware or software, I would say no, you could never get a UDP
checksum error.  But if you assume only the Ethernet tranceivers and
the IP code in your hosts can be trusted, there still are other
areas that could fail and generate UDP checksum errors.  Examples:
intermittent software bugs in the Ethernet driver, flakey memory in
your Ethernet controller or host memory, bugs in your OS that
occasionally corrupt packet buffers, etc.

>What if we release the restrictions above, namely, place these hosts on
>separate networks, connected via routers (whose Ethernet drivers are also
>functioning properly).  Are the sources of error now simply those inherent in
>connection-less network layer service, i.e., lossed packets, duplicated
>packets, etc?

All of the problems I mention above can occur (and have occurred at
times) in routers that would simply result in corrupted packets being
delivered to users if there were no checksum.  Your questions are
touching upon the subject of the importance of an end-to-end checksum.
Basically, you have to decide if you want to pay a small (if implemented
properly) performance hit in computing the UDP checksum for the benefit
of detecting otherwise undetected bad packets.  Alternatively, you can
assume your hardware and software are generally reliable and disable UDP
checksums.  You get what you pay for.
--
Ron Holt   ron_holt@npd.novell.com   +1 801-568-8674

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 17:41:53 GMT
From:      lhl@CS.WISC.EDU (L.H. Landweber)
To:        comp.protocols.tcp-ip
Subject:   (none)

CALL FOR PARTICIPATION

INET'92
International Networking Conference
Internet Society
Kobe Japan - June 15-18, 1992

	The first international conference organized by the 
Internet Society (just being formed) focusing on 
worldwide issues of research and academic networking - 
INET '92 - will be held on June 15-18, 1992 in Kobe, 
Japan. The goal of this conference is to bring together 
individuals from university, industry and government who 
are involved with planning, developing, implementing, managing 
and funding national, regional and international research 
and academic networks.  

	The conference agenda will include plans and status 
reports on research and academic networks throughout the 
world. In addition, possible topics for conference 
sessions include but are not limited to the following:

Technology and Services
-- Progress toward international open network protocols
-- Interoperability among existing national and international networks
-- Collaboration technologies
-- Security, management and authentication in managing networks
-- Technologies of the '90s
-- Mail and directory services
-- Very high speed networks
-- Data storage: terabytes and beyond
-- Networks and network services of the 21st century

Applications
-- Network support of international scientific collaboration
-- Network access to scientific papers and data across national boundaries
-- Supercomputing
-- High energy physics
-- Workstation teleconferencing
-- Computer supported collaborated works
-- Education 
-- Libraries

Regional Issues
-- Asia-Pacific Rim		-- Latin America
-- Eastern Europe		-- North America
-- Europe			-- Africa
-- Special Issues for the Third World

Policy Issues
-- Globalization of services
-- Commercialization/privatization
-- Coordination of international links
-- Appropriate use
-- Security
-- Privacy
-- Telecommunications policy

Information for Paper Submission
For Technology & Services and Applications sessions, 
please submit 6 copies (in English) of double-space 
typed manuscript (maximum of 20 pages) with an abstract 
to 

	Prof. Haruhisa Ishida
	Computer Centre, University of Tokyo
	Bunkyo-ku, Tokyo
	Japan 113
	(Phone) +81-3-3818-0287
	(FAX) +81-3-3814-7279

You may also submit a PostScript version of your paper 
by e-mail to ishida@u-tokyo.ac.jp.

Tutorials
In addition to papers, proposals for one day tutorials 
are solicited in any of the conference area.  Such 
proposals should be submitted to the program chair or 
Deborah Estrin (estrin@usc.com) by January 6, 1992.

Important dates
-- January  6, 1992		Manuscript due and proposal due for a tutorial 
-- March 1, 1992		Notification of acceptance to authors
-- April 15, 1992		Camera-ready papers due

Workshop for Developing Countries

A one day workshop for representatives of developing and 
third world  countries, "How to Plan for and Implement 
Research and Academic Networks", will be held in 
conjunction with INET'92.

Conference, Program, and Advisory Committees
Conference Committee
-- General Conference Chair		Hideo Aiso, Japan
-- Regional Conference co-chairs
	North America:			Richard Mandelbaum, USA
	Europe: 			Frode Greisen, Denmark
	Asia-Pacific Rim: 		Jun Murai, Japan
	Developing Countries:	 	Stefano Trumpy, Italy

Program Committee
-- Program Chair			Haruhisa Ishida, Japan
-- Program Regional co-chairs
	-- North America: 		John Demco, Canada
	-- Europe:			Dennis Jennings, Ireland
	-- Asia-Pacific Rim:		Hide Tokuda, Japan/USA
	-- Developing Countries:	Enzo Puliatti, UNDP/Italy

Advisory Committee
-- Chair					David Farber, USA

Tutorial Committee
-- Chair					Deborah Estrin, USA

Internet Society Liaison			Larry Landweber, USA

General Inquiries
	To be added to the conference mailing list, send 
mail, fax or E-mail to one of these addresses.

Japan & Pacific Rim:
	WIDE project,
	INET '92 secretariat 	Phone: +81 466 48 9433
	5322 Endo, Fujisawa		FAX:   +81 354 90 7002
	Kanagawa 252, Japan		EMail: inet92@wide.ad.jp

North America:
	EDUCOM, 
	INET '92 secretariate	Phone: +1 202 872 4200
	1112 16th Street, NW	FAX:   +1 202 872 4318
	Washington DC 20036, USA	EMail: inet92@educom.edu

Europe:
	UNI-C, 
	INET '92 secretariate	Phone: +45 45 93 83 55
	DTH, bygning 305		FAX:   +45 45 93 02 20
	DK-2800 Lyngby, Denmark	EMail: inet92@vm.uni-c.dk


Sponsor
Internet Society 
in cooperation with
ACM SIGCOMM
IPSJ(Information Processing Society of Japan)
CREN, EDUCOM, FARNet, IAB and NetNorth in North America
JAIN, JCRN, TISN, and WIDE in Japan
EARN, EUUG (EUnet), NORDUNET and RARE in Europe

Corporate sponsors (preliminary list)
  Advanced Network & Services
  Digital Equipment Corporation
  IBM
  Novell

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 91 20:47:32 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the sources of UDP packet errors?

In article <1991Sep13.204602.18573@ecs.comm.mot.com> solomon@becks.comm.mot.com (James Solomon) writes:
>
>Greetings:
>
>Take the hypothetical situation of three hosts connected via Ethernet.  
>No bridges, routers, gateways ... no nothin', except these three hosts:  
>A, B, and C.  Let's say A sends B a UDP packet.
>
>Now, if we assume that the Ethernet tranceivers and the IP code in all hosts
>are working properly, can we *ever* get an error at the UDP layer (that is, an
>error detected solely by the UDP checksum)?  If the answer to this is, *yes*,
>please enumerate the reasons why such an error could occur.  [I'm after reasons 
>that help shed some light on the process of computer communications, not things
>like ``the UDP code is hosed'' ;-)]

Yes.  The interface between the transceiver and the host could be faulty.
Most machines will have parity checking on memory buses so this isn't
too much of a problem.  However if you have several layers of hardware which
discard and then regenerate the parity you can have a problem.  The UDP
checksum doesn't catch all errors, but it is an additional backup.

If you say that UDP checksumming is useless unless you have a problem you're
quite right.  However you need the checksum to tell you you have a problem.

>What if we release the restrictions above, namely, place these hosts on
>separate networks, connected via routers (whose Ethernet drivers are also
>functioning properly).  Are the sources of error now simply those inherent in
>connection-less network layer service, i.e., lossed packets, duplicated
>packets, etc?

Now is when you really need UDP checksumming.  Each of these devices
will discard and regenerate the Ethernet CRC's.  If any errors are 
inserted into the data inside the routers this will go unnoticed.  The
probability of this is low, but non-zero.  If you're running your
NFS across a SLIP link you're dead meat as there is no checksumming
performed at the link-level there.  Of course, very few people run
SLIP much faster than 19200 so you usually don't want to run NFS across
it, but other UDP based protocols can have problems.

Basically, a restriction like "the Ethernet drivers are functioning properly
so why should I need UDP checksums" is bogus.  You can never assume that
a portion of you system is functioning.  That's the whole point behind
checksums.  You can say "I believe the probability of this event is very low
so I choose not to have end-to-end checksums of the data."

BTW, lost packets, duplicated packets, etc. should not cause corrupted
UDP data so checksumming doesn't help there, unless of course, your IP
re-assembly code is broken.
-- 
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 19:42:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

In article <1991Sep13.212439.10000@kronos.com>, richb@kronos.com (Rich Braun) writes:
>                                   ...           The engineer for this
> vendor claimed that "no" router has these features as of this date.
> ..


Talk to other vendors.

I know of at least one important computer vendor (not my employer) whose
connection to the Internet appears to involve just such filters.  I suspect
it involves some vendor's dedicated routers.

There are also such facilities for workstations acting as routers,
including my employer's.


Vernon Schryver,   vjs@sgi.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 20:31:44 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   NIT-based traceroute

Could someone please tell me where the NIT-based version of
traceroute is archived.

Thanks very much in advance.

...Sam
-- 
<skl@cs.sfu.ca>

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 20:39:49 GMT
From:      kph@cisco.com (Kevin Paul Herbert)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

cisco routers support access lists using TCP port numbers and IP addresses. You can
send mail to customer-service@cisco.com to find out more.

Our low-end router costs just a little bit more than the price range you quoted.

Kevin

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 91 21:34:46 GMT
From:      sob@isr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   non-ip info request

Yes, I know this is comp.protocols.tcp-ip but, who knows... someone
might have the info handy.

for the in-progress round of router (& bridge tests) I'd like to
verify what I'm doing with 2 protocols: DECnet & OSI

can anyone send me an anotated packet dump of a OSI and a DECnet
packet? Some sort of protocol that would 1/ route & 2/ be a good one
to test performance with. (I'm using Echo Request packets for IP-UDP,
AppleTalk etc)  But if there is not a dump of an OSI & DECnet ping
(actually I don't know that there is such a thing as a DECnet ping), 
then anything would do.

What I need most is the anotation, i.e. what bits do what
something like

offset	data
#DATAGRAM HEADER
00 	AA 00 04 00 02 04        # dest MAC address of router
06 	AA 00 04 00 01 04        # source hardware address
12 	08                       # type high byte
13 	00                       # type low byte
#
# IP HEADER
14 	45                       # IP version - 4,
                                    # header length (4
                                    # byte units) - 5
15 	00                       # service field
16 	00 2E                    # total length
18 	00 00                    # ID
20 	40 00                    # flags (3 bits)-4 (do not
                                    # fragment),
                                    # fragment offset-0
22 	0A                       # TTL
23 	11                       # protocol - 17 (UDP)
24 	C4 8D                    # header checksum
10 	00 4 26                  # source IP address
10 	00 4 30                  # destination IP address


can anyone help (soon! :-( )

thanks

			Scott

			sob@harvard.edu

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 02:53:34 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   SND.WL1/SND.WL2 confusion

I am tracking down a bug in my implementation of TCP, which I wrote with RFC
793 open on my lap.  There is some garbled nonsense (at least it looks like
nonsense to me; I don't know if I'm being stupid or Postel was smoking
something on page 72) about only updating the send window when SND.WL1 !=
SEG.SEQ or SND.WL2 != SEG.ACK which is designed to keep you from updating your
send window on the basis of out of date (retransmitted) ACKs.

Problem:  when a receive window opens up, if no data have been sent, my TCP
module will see totally identical ACK segments, except that the later ones
have bigger windows.  The bug is that an application sending 1K chunks hangs
when the remote TCP's receive window gets below 1K and my send window doesn't
get updated by the later ACKs with those succulent 4096 octet windows because
of my (mis)implementation of the (mis)statements on page 72 of RFC 793.

So could someone please explain/give a pointer to an explanation of the Right
Thing (tm) to do with updating the TCP send window?  It seems like the
SND.WL1/SND.WL2 hack cannot prevent me from using a newer advertisement of a
gratuitously smaller window (i.e. two identical ACKs, the latter of which has
a smaller window) without preventing me from (correctly) using a gratuitously
bigger window size.  I understand the need to not decrease the send window
when you see a retransmission (I think; it's getting late, and I'm tired) but
I think my reading of RFC 793 p.72 is the Wrong Thing.

-Johnny Window

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 07:53:04 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip,eunet.misc
Subject:   Re: The shortest way from Paris to the UK is...

Sam.Wilson@ed.ac.uk writes:

>Well, we can't help it if France's routing is messed up! :-)
 
>[ from cancer.ucs.ed.ac.uk - 129.215.200.7 ]
>cancer: 54) traceroute 129.102.0.1
>traceroute to 129.102.0.1 (129.102.0.1), 30 hops max, 40 byte packets
> 1  129.215.200.253 (129.215.200.253)  4 ms  4 ms  3 ms
> 2  gw.ulcc.ja.net (146.97.112.4)  125 ms  107 ms  97 ms
> 3  cisco.ulcc.ac.uk (128.86.1.2)  102 ms  108 ms  122 ms
> 4  hef-router.nikhef.nl (192.16.192.176)  691 ms  789 ms  2494 ms
> 5  Amsterdam.Nl.EU.net (192.87.4.20)  713 ms  773 ms  1044 ms
> 6  134.222.2.2 (134.222.2.2)  796 ms  502 ms  504 ms
> 7  fnet-gw.inria.fr (192.93.1.108)  582 ms  401 ms  763 ms
> 8  * * *
>     :
>     :
>     :
>30  * * *
It seems that from holland we get the shortest connection (in hops).
Even from cancer.ucs.ed.ac.uk it is longer.
From dutepp0.et.tudelft.nl:
traceroute to sun2.nsfnet-relay.ac.uk (128.86.8.45), 30 hops max, 40 byte packets
 1  dutrci1.tudelft.nl (130.161.180.25)  20 ms  8 ms  5 ms
 2  snet-router.surfnet.nl (192.87.8.17)  11 ms  8 ms  8 ms
 3  hef-router.nikhef.nl (192.16.183.80)  9 ms  9 ms  10 ms
 4  cisco.ulcc.ac.uk (192.16.192.185)  103 ms  87 ms  85 ms
 5  * *

Also note very fast responce times.
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:46:12 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   RPC on SYSVR4

Hi everybody,

We have some RPC application that we have ported to SYSVR4 recently. Looking
at what rpcgen emits this looks pretty different from what I have seen under
BSD-ish UNIXes (like SunOS). It seems like the RPC library runs directly on
top of TLI. I wonder wether the source for such a library is publicly
available (like the socket-based RPC libraries). Any hints ?

			cheers
				-Torsten
--
Torsten Beyer                      	mail	     : tb@Materna.DE
Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
     UNIX is a registered trademark of AT&T. AT&T is a modem test command

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:54:46 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   (none)


Please remove me from this list.

Thank you.

      || * * * * * =========       Tom Varga
      ||  * * * *  =========       Kendall Square Research
      || * * * * * =========       617-895-9415
      || ===================       tom@ksr.com
      || ===================       uunet!ksr!tom
      || ===================       N2UA @ KA1PEP
      ||

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 11:55:09 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
To: dcarr@hobbit.gandalf.ca (Dave Carr)
Date: Mon, 16 Sep 91 7:55:09 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
In-Reply-To: <1991Sep3.193526.21423@hobbit.gandalf.ca>; from "Dave Carr" at Sep 3, 91 7:35 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> In <2431@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
> 
> >I should note that PPP is basically misdesigned because the latest crop
> >of Ethernet chips tend to support HDLC modes while the latest crop of
> >Serial HDLC chips tend to support Ethernet modes.  As a consequence if
> >SLITHERNET is used for wide area networking while ethernet is used for
> >local area networking, respinning ethernet software for wan uses and
> >respinning ethernet interfaces for wan interfaces is relatively
> >straightforward as well as vice versa.  
> 
> Yes, and anyone who has an WAN driver for an 82596, I would like to hear from
> (and so would Intel I imagine).  Given the errata, I doubt it would SLITHER !
> 
> And also I will quote a Zilog engineer "You're not going to use the USC in Ethernet
> mode ?  (long pause)  Are you?"...  Given the FIFO bugs, (albeit corrected with the
> latest step of the week), I would stick to HDLC on the USC, and Ethernet on the 
> 82596.
> -- 
> Dave Carr               | dcarr@donut.gandalf.ca | If you don't know where  
> Gandalf Data Limited    | TEL (613) 723-6500     | you are going, you will
> Nepean, Ontario, Canada | FAX (613) 226-1717     | never get there.
>
[Begin Soapbox]

I agree with Mr. Carr.

It is interesting to note the reactions of people to this new proposal for
a serial protocol.  I think the folks at Clearpoint might want to reconsider
the resources being spend on a product such as this, as opposed to developing
a PPP-based product line, if this reaction is representative of the market.

The comment regarding the overhead of using the async adapters on a work-
station at high-speed is probably justified.  There is at least one vendor
marketing a SCSI-attached serial adapter with PPP software to address this
issue.  IMHO, this is a decent approach since it will interoperate with any
other PPP-based product at the other end.  And after all, isn't interoperabilitywhat we are all about?

[End of Soapbox] 

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:11:09 GMT
From:      martinea@HAWK.NSTN.NS.CA (Michael P. Martineau)
To:        comp.protocols.tcp-ip
Subject:   Re: ka9q bootp and POP (was: Re: KA9Q or PcRoute)


    while i have some ka9q enthusiasts attention, has anyone got the ka9q POP
    server to work with POPmail (PC version)?
    
From what I remember from looking at this issue several months ago, some
POP servers return comments as part of their response fields.  If I remember
correctly, POPmail does not like these comments (it expects numerics in 
the return field and gets confused when it see additional text).  The
POP server can be hacked to remove the comments.

*************************************************************************
* Michael P. Martineau			martinea@hawk.nstn.ns.ca	*
* General Manager			Phone: 468-NSTN			*
* NSTN Inc.				FAXL   468-3679			*
*************************************************************************

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:22:18 GMT
From:      ANGLEY@raleng.mtc.com (Kevin Angley)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please remove me from the tcp-ip mailing list.

If this is not the appropriate means of getting off the list, a private message
with the correct procedure to angley@raleng.mtc.com would be appreciated.

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 12:58:17 GMT
From:      marikar@digrev.UUCP (Mo)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please take me off the mailing list.
Mo Marikar.
Digital Review.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 13:24:14 GMT
From:      matthew@ooc.uva.nl (Matthew Lewis)
To:        comp.protocols.tcp-ip
Subject:   Wanted: rarpd with dynamic allocation of IP addresses

Hello!  As the subject says... We have a class-c net and are moving over to
NFS for our PC's.  Since all of the PC's are never used at once, we would
love to be able to allocate a pool of IP addresses to use for them via
rarp.  Has anyone done this yet?  Is there a compelling reason NOT to?


Thanks,

Matthew Lewis
Sys Admin, CICT/OOC
University of Amsterdam


P.S.  If you reply by mail, I'll summarize
-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 13:57:45 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: Q: Master List of TELNET / FTP programs?
To: nwnetman@u.washington.edu (Jonathan Kochmer)
Date: Mon, 16 Sep 91 9:57:44 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
Reply-To: scoggin@delmarva.com
In-Reply-To: <9109040110.AA24341@milton.u.washington.edu>; from "Jonathan Kochmer" at Sep 4, 91 1:10 am
X-Mailer: ELM [version 2.3 PL11]

> 
> 
> Has anyone compiled a list of *all* TELNET/FTP programs for *all* 
> operating systems?  In the best of all possible worlds, I would like 
> a list including the following information:
> 
> Jonathan Kochmer
> University Computing Services
> University of Washington
> 
> nwnetman@milton.u.washington.edu

There is a TCP/IP Vendor's Guide, which is kept REASONABLY up-to-date.  It
is available via anonymous FTP from nic.ddn.mil as NETINFO:VENDORS-GUIDE.DOC
.211 - they also have it available in paper form for a small fee.
----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:33:10 GMT
From:      ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   lpr command for SCO wanted

Hi, netlanders,

I think I once read that someone has ported the lpr command (the lpd
client) to the SCO base? I have a customer who wants to use the Novell
NFS server lpd functionality from his SCO UNIX systems...

Thanks a lot in advance. I'm sorry that I didn't get the source from 
the net when it appeared at the first time.

Regards
Ralf.
-- 
| Ralf U. Holighaus          |                                     PEM GmbH |
| Technical Support Manager  |          Vaihinger Strasse 49, PO-Box 810165 |
|                            |                 W-7000 Stuttgart 80, Germany |
| holighaus@pem-stuttgart.de |    VOICE: x49-711-713045 FAX: x49-711-713047 |

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:58:59 GMT
From:      subra@thor.cc.nd.edu (Kumaraswamy Subramanian)
To:        comp.protocols.tcp-ip
Subject:   Info. wanted on POP2 server implementation

Hello,
  I am trying to implement a POP2 server and I have a question on the POP2 
protocol. I am following the RFC 918 and the RFC says that whenever a POP2
client requests for the message using "RETR" command the server should send
multiline response(each line terminated with CRLF pair) and should change its
state to wait for an ACKS/ACKD/NACK from the client. The problem I am facing
is when I tested the server with a POP2 client the client hangs up at the
"RETR" state and my logfile for the POP2 server says the message has been
transferred to the client and also has changed its state to receive one of the
acknowledgement(ACKS/ACKD/NACK). The client is not able to recognize the end
of message from the server. It just keeps on waiting thinking that the more
message is yet to come from server.
Is there any way to tell the client the "End of Message" like the POP3 server
which terminates the message with ".CRLF"? or am I missing something here?
(currently I haven't implemented timeouts for client wait time )

Thanks in advance.


------------------------------------------------------------------------------- 
email: subra@thor.cc.nd.edu

Kumaraswamy Subramanian
Network Analyst,
Univ. of Notre Dame
Notre Dame IN 

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 14:59:46 GMT
From:      rich@progress.COM (Rich Lenihan)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   standard services?

I have a question about the contents of the /etc/services file.  We have
a very heterogenous UNIX tcp/ip-based network.  We'd like to be able
to assign local services in the /etc/services file without fear of stomping
on some vendor's implementation of their networking product.

Is there a range of port numbers that are considered to be user-defined?  I 
assume that numbers in the lower range would be reserved, but I've come across 
numbers in the 6000 range as well.  Also, is there any place (like the NIC) 
where these numbers are registered?

Thanks (and apologies if this is a FAQ-type question)

   Rich

------------------------------------------------------------------------------
Rich Lenihan                 UUCP: mit-eddie!progress!rich
Progress Software Corp.      Internet: rich@progress.com
5 Oak Park                   >-   Insert funny stuff here  -<
Bedford, MA  01730           >-Draw amusing symbols, logo's-<
USA                          >-     or characters here     -<

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:05:31 GMT
From:      hjones@csi.compuserve.com (Benny Jones)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for TOPS-10?

I'm trying to find a TOPS-10 implementation of TCP/IP.  Can anyone
help me?  Thanks much.

Benny Jones
CompuServe	70003,1153
Internet	hjones@magnus.acs.ohio-state.edu
-- 
Benny Jones
CompuServe 		70003,1153
Internet		hjones@magnus.acs.ohio-state.edu

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:14:43 GMT
From:      mbt@ESD.3Com.COM (Brad Turner)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Router security features

3Com's NETBuilder bridge/router software (ver 3.0 and greater) includes IP
packet level filtering capabilities. For more information you can send email
to info@3com.com or call 1-800-NET-3Com (408-764-5000 outside the USA)

-brad-

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 16:23:22 GMT
From:      mmm@well.UUCP (Michael Hidalgo)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe


Please remove me from the mailing list.
Michael Hidalgo

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 19:25:53 GMT
From:      osmana@well.sf.ca.us (Osman Arslaner)
To:        comp.protocols.tcp-ip
Subject:   SQL Server and TCP/IP


We would like to run our SQL Server (from Microsoft) over TCP/IP
protocols. We have installed TCP/IP from FTP Software on our OS/2
Server and tried to interface to the SQL Server program through
NetBios. We were not able to make it work.

We are told that SQL Server is using Named Pipes and will not interface
to NetBios, but we can interface it directly to TCP/IP using a file
called "sockets.dll".

Has anybody installed SQL Server over TCP/IP yet ? Also where can we get
a copy of this file "sockets.dll" ?

Any help will be appreciated.
Thanks.

Osman Arslaner.
Montreal, QUEBEC.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 20:01:24 GMT
From:      warb@faatcrl (Dan Warburton)
To:        comp.protocols.tcp-ip
Subject:   Help with SOW for Internet wanted


I need to write a Statement of Work suitable for use in Government
(FAA) procurement for a 56kbs connection to the Internet. If you have
specifications of this type connection please forward them to me at:

		warb@faatcrl.uucp

As you can see we are a UUCP site trying to upgrade to direct connection. 
Some Questions I have:

1. How can I charactize the Internet? List the major regional networks I 
   want to be able to exchange packets with? Indicate which machines I want 
   to be able to ping?

2. How can I keep from getting a dial up connection? Specify some type of 
   minimum latency time for connection.

3. What type of Engineering Support Services are available? I am thinking of help with 
   routing, E-mail, netnews and bridging with-in our networks is what I am thinking.

Thanks in advance!!!
-- 
+  Dan Warburton   Nas Simulation Support Facility (NSSF)                  
+                  Federal Aviation Administration Technical Center  
+                  Atlantic City International Airport, NJ 08405    //
+  609-484-4480    Mail Stop: ACN-313        Aikido        Amiga  \X/ Sun
+  warb@faatcrl.uucp  ...rutgers!faatcrl!warb   -- An Open Systems Group --

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 23:27:13 GMT
From:      cs@Eng.Sun.COM (Carl Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC on SYSVR4


> We have some RPC application that we have ported to SYSVR4 recently. Looking
> at what rpcgen emits this looks pretty different from what I have seen under
> BSD-ish UNIXes (like SunOS). It seems like the RPC library runs directly on
> top of TLI. I wonder wether the source for such a library is publicly
> available (like the socket-based RPC libraries). Any hints ?

	We don't make an SVr4 version available (likely we will when Sun ships
an SVr4 system), but the one that we do make available as TIRPCSRC is very,
very close to what we actually use (basically, things have been added to the
SVr4 version in order to get it to run on SunOS 4.1, and that version is made
available as TIRPCSRC).  Appended is the blurb on where to get it.

			Carl

Sun's freely licensed implementation of Transport Independent RPC
(TIRPC), is now available as source code via anonymous ftp from
uunet.uu.net in the directory "networking" as the file named
tirpcsrc.tar.Z.  This is a compressed tar file.  This implementation of
TIRPC is compatible with SunOS 4.1 *only*, and requires root
priviledges for installation.

TIRPC is the version of Sun RPC that is part of System V Release 4 (SVR4).
See the "README" file in the distribution, as well as the files in
the doc and man directories, for further information.

To use anonymous FTP, use the ftp program to connect to uunet.uu.net.
When prompted for a user name, enter "anonymous".  When prompted for
a password, enter your user ID (such as "joeuser@sun.com").  Then
change directories (cd) to the "networking" directory, where you will find
tirpcsrc.tar.Z.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 91 23:46:09 GMT
From:      peterr@syacus.acus.oz.au (Peter Russell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,acus.general,comp.protocols.ibm
Subject:   Re: TELNET & 3270 (tnv3270?) - Request For Information


I think you use the telnet/3270 type thing in a PC when you have a 3274
type controller that has the ethernet support installed.  I think 3274's
of the right model and upgrade will do all of straight coax, token ring or
ethernet.

Peterr

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 00:35:41 GMT
From:      pmanglik@tanj.intel.com (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe


Please take me off the maiiling list.

Pankaj

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 06:35:20 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   cisco router performance (was selecting a fast ethernet card).

A rather curious set of circumstances has caused a message requesting info
on high performance ethernet controllers of PCs to lead to some speculation
on how a cisco might operate,a ndhow fast it really is.  I thought I should
step in with real (inside) data in that area.  So....

Piercarlo Grandi says:

    dave@pmafire.inel.gov (Dave Remien) writes: [I think]

    > Ours forwards at about 15000 packets per second, and routes at about
    > 2000 packet/sec. The newer ones are supposed to about double that.

First comment:  The cisco forwards (used to) 15k routed IP packets per second
under some set of moderately ideal conditions ("fast switching" within the
same interface complex.)  15K is an old number - the ideal case is several
times that now.  The "2000 packets/sec" number is for pessimal cases (eg
output interface is less intelligent").  What the number actually means is
that the cisco can make 15k routing decisions in a second, and that the
best case end-of-input packet to start of output packet time is 66.7 uS.


    > Lessee ---- 15000 * 1500 = 22.5MBytes/sec, a tad faster than Ethernet
    > will go.

    25 times the bandwidth of a single Ethernet. Impressive! CISCO must be
    very generous to give customers so much extra capacity, as their
    routers rarely connect more than 2-3 Ethernet segments, and they
    overdesign their products to handle ten times the maximum load on
    their average configuration.

We're not so generous - we charge a lot of money.  And I suspect that
the "average" cisco router is larger that 2-3 ethernets (maximum
capacity is something like 28 ethernets.  Many protocols are sensitive
to delay, so shipping a packet out as quickly as possible is a good idea.
Finally, ciscos support interfaces like FDDI and T3 that go much faster
than ethernet, and the architecture has to support those too.

    > Even routing implies (assuming max size legitimate packets) 3MBytes/sec.

    Here I detect the possibly improbable assumption that it can forward
    or route maximal size packets at the maximum rate, which seems
    incredibly optimistic, because 22MB/s aggregate bandwidth is a really
    stunning figure, being able to forward packets between 25 Ethernets at
    full tilt.

    If it really can route 22MB/s then whatever processor card is inside a
    CISCO router must have a bus that is at least four times as fast as an
    ISA bus, nearly as fast as an EISA bus, and it must have a
    diabolically fast memory subsystem.

    22MB/s cannot be achieved by most :-) 386 memory subsystems for pure
    string copies.  Try copying a 1KB string from one buffer to another
    for a few thousand times and then calculate the memory bandwidth.
	    :
	    : code to time bcopy deleted
	    :

    I'd be truly amazed if the CISCO router could handle 22.5MB aggregate
    bandwidth, even if just for forwarding, unless it has inside a processor
    memory combination substantially faster than a 5830, or it has a
    wormhole chip. Somehow I think both hypothesises are somewhat improbable.

Well, no wormhole chip.  But under optimal conditions, the aggregate
throughput of a cisco is much faster than 22.5MB.  The memory system consists
of a bunch of very fast static RAM shared between the interfaces of each
interface complex.  The "processor" consists of one or more custom micro
coded bit-slice processors and a 30Mhz 68020 which may or may not be involved.
The packets are not copied at all, which helps a lot - a packet comes in,
we check it, route it, and get it sent out some other interface.  This takes
about 67 uS (to get 15kpps).

    > I suspect that the quoted Cisco rates are for minimum (50
    > byte) or fairly small packets, netting somewhere in the neighborhood of
    > 100KBytes/sec. 

    I suspect that too, so that at 15k packets/s we'd get about 0.8MB/s for
    forwarding. Looks more like it. CISCO may not have gotten a Shannon
    dispensation after all.

Nope.  Since the data isn't copied, the forwarding rate is independent
of the packet size.  Obviously, we can't ship out packets faster than
they can be sent on the destination interface.  But other packets might
have to go to other interfaces.  Now, I've mentioned "interface complex"
a couple of times.  In somewhat older ciscos, an interface complex is
one to four network interfaces on a single card.  Copying data to a
different card is (of course) somewhat slower.  In current ciscos, the
interface complex is one two four boards (each with up to six interfaces)
on the 'cBus', a 533 Mbit/s bus, which expands the scope of high speed.

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

Sender: <tcp-ip-relay@nisc.sri.com>
From: aria!dumbcat!marc@uunet.uu.net  (Marco S Hyman)

    Stop right there!  15000 packets/second is (approx) the Ethernet
    maximum.  For those who want the math:

	    Minimum frame length = 64 bits of preamble		64 bits
				    6 octet destination address	48 bits
				    6 octet source address		48 bits
				    2 octet type			16 bits
				   46 octet data		       368 bits
				    4 octet FCS			32 bits
							    -----------------
								   576 bits

    The time to transmit this frame at 10 Mbit/s is 57.6 usec.  Add to that
    the minimal interframe spacing of 9.6 usec and you can spit a frame out
    every 67.2 usec or 14880 (almost 14881) frames per second -- assuming
    one station is doing all the transmitting.

Exactly correct.  The theorectical max doesn't change with multiple stations,
but you are more likely to have collisions which will interfere somewhat.
Still, studies (Boggs @ DEC) have shown that even with 20 stations trying
to transmit simultaneously, the usable badnwidth ofan ethernet is still
close to 10 Mbit/s.


    cisco playes the specsmanship game of being able to handle this
    theoretical maximum.  They are not the only ones who try to play this
    game.  (Note that when playing this game the payload maximum is 14880
    pps * 46 bytes/p = 684480 bytes/second.  That's a lot of work for a bit
    more that 1/2 Mbyte/s.)

It's a game if you have a two port ethernet only box.  As described above, the
actual numbers get more interesting when you have more or faster interfaces.


    Using the maximum ethernet frame length the numbers look like 1220.8
    usec per frame.  When adding the 9.6 usec interframe spacing requirement
    the maximum frames/second (large frames) is 812 frames/second.  The
    payload in this case increases to 1.218 Mbytes/s.  Typical networking --
    the best throughput occurs when the processor is doing the least amount
    of work :-)

This can't be argued with either.  If you're trying to get the maximum
performance out of your tcp, and it isn't sending full sized network
datagrams, that is certainly the first thing to fix.

To get back to the original question, on high throughput for PC Unix:
Van Jacobson has done a convincing proof that TCP can go over 6Mbit/sec.
(He tuned the TCP on a SUN 3/60, and got repeatable TCP data transfer
rates consistantly close to 9Mbit/sec.  A sun 3/60 is not a blazingly fast
machine, though it does have a shared memory ethernet controller.)
There were some interesting results:

    1) checksumming does NOT matter.  The limiting factor is usually the
	memory cycle time of the processor memory.  Given a modern CPU
	with some form of instruction cache, the checksum can be folded
	into a data copy at zero cost.

    2) The ethernet controller CHIP DOES matter.  Going this fast means
	that the wire will be full of data almost all of the time, and
	collisions WILL occur between the systems sending data and the
	ACKs the receiver has to send back.  If the chip cannot reset
	its packet pointers and whatnot quickly in the event of a collision,
	it won't go as fast (This was the suspected reason that Intel's
	82586 ethernet controller had a lower peak performance than the
	AMD Lance chip used in the 3/60).

    3) The hardware matters.  The 68k in the 3/60 was idle about 30% of
	the time in 3/60.  Why wasn't it less idle and going faster?
	Well, because the Lance couldn't make use of the full bandwidth
	of the memory - It takes an eternity (600 nS) to do a single
	16 bit memory transfer, and during that time, the 68k couldn't
	access the memory either, so it sat idle.  This goes to show that
	a bus is only as fast at the device driving it.  So EISA bus has
	a bandwitdh of XXX Mbyte/sec - can your I/O device, DMA controller,
	or CPU actually deliver or eat data that fast?

Can a PC do 6Mbit/sec?  I doubt it.  Pre-Jacobson TCPs tend to go about
1Mbit/sec, and I don't think that anyone has made significant efforts to
incorporate the new theory into PC implementation.

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

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 07:30:50 GMT
From:      bersee@nikhef.nl (Josefien Bersee)
To:        comp.protocols.tcp-ip
Subject:   announcement 3rd JENC



                ANNOUNCEMENT AND CALL FOR PAPERS
                --------------------------------

             3rd Joint European Networking Conference

             ****************************************
             Building Research Networking for Europe
             ****************************************

Innsbruck, Austria, May 12-15, 1992

Organized by RARE (Reseaux Associes pour la Recherche Europeenne)
in cooperation with:

o ACM SIGCOMM     o ACOnet        o EARN
o EurOpen         o Internet Society


GOALS

This conference aims at informing the participants about the state of
the art in networking and about building new and better network
services. It will provide a forum for the presentation and discussion
of technical and strategic topics related to the provision of
networking services for research and higher education, as well as
corresponding research and development activities. As a result parti-
cipants will get understanding of the issues in European Networking.

The conference addresses technical, managerial and end-user support
staff from local, national and international service providers as well
as application developers, policy makers and representatives of
funding bodies, advanced user groups and standards organizations.

Much emphasis will be placed on cooperation between networking
services. The conference will continue and enhance the discussion
between members of different networking communities, building on the
positive experiences of the earlier Killarney and Blois Conferences.
This conference is THE forum on networking in Europe and presents a
unique opportunity to meet key people active in networking today.

CONFERENCE VENUE

The city of Innsbruck is situated in the middle of Tirol, one of the
most famous holiday areas in Austria.  Innsbruck offers history and
traditions as well as an up-to-date infrastructure.  The conference
will take place in the Innsbruck Convention Centre - Kongresshaus
Innsbruck - a spacious centre of high international standard.

FIRST INVITATION AND PRELIMINARY PROGRAMME

A first invitation and preliminary programme, including information on
how to register will be distributed in January 1992.  Please contact
the RARE Secretariat if you want to make sure you receive the
invitation.

CALL FOR PAPERS

As for the past Joint Networking Conferences, the programme will
include a combination of solicited and submitted papers.
Presentations taking 20, 30 or 45 minutes are invited.  One-page
summaries of proposed papers should arrive at the programme chair not
later than November 17, mentioning the topic against which the author
would like his paper assessed and the expected length of the
conference presentation.  It is again intended to publish proceedings
of the conference in "Computer Networks and ISDN Systems".  Full
papers must be provided by the start of the conference at the latest.

Topics for submitted papers should be related to the major headings
of the general outline of the conference given below:

1 Users, User Support & Group Communications

         User Support
         User View of European Networked Resources - User Requirement
         Impact of Networking
         Teleconferencing
         Videoconferencing

2 Infrastructure: Coordination & Management

         Multiprotocol Backbone Infrastructure
         Network Management
         Operational & Interworking
         Quality of Service - Concepts, Performance, Measurement
         Security Implementation and Operation
         Services Management
         Gateways

3 Coordination of Applications & Services/Projects

         Access Control and Authentication
         Directory Services
         Distributed Computing
         Distributed Services Management
         Documentation Format, eg. ODA
         File Servers
         Information Services (Library etc.)
         Message Handling Systems (MHS)
         Naming and Address Management
 	 High Performance Computing
	 Visualisation
		
4 Technology

         New Technology (ATM, Frame Relay)
         Products
         Security Techniques

5 Policy, Funding & Futures

         Economic Impact of Networking
         Electronic Publishing & Intellectual Property Rights
         International Export - Legal Restrictions
         Is there life after COSINE?
         Security Policy

6 International Success Stories - Advanced Uses/Users

         Collaborative Research
         Distance Learning

7 Status reports of national initiatives and European projects

         COSINE
         Country Reports
         RARE Working Groups
         Standards
	 EARN / EurOpen / RIPE 

CALL FOR POSTERS AND DEMONSTRATIONS

As in previous years, a poster wall will be available for the display
of posters.  Participants are invited to submit a poster presentation
of the project they work on or a topic of common interest to the
conference participants. The programme committee will select the two
best posters during the conference for inclusion in the conference
proceedings.

During the conference there will be the opportunity for participants
to present their project or activities in the form of a demonstration,
either as part of their presentation or separately.  Requests for
demonstrations should be made through the RARE Secretariat, specifying
technical requirements.  X.25 and IP connectivity will be provided.

FURTHER INFORMATION

For further information contact :

RARE Secretariat                        Programme chair :
P.O. Box 41882                          Christian Michau
NL-1009 DB AMSTERDAM

tel +31 20 592 5078                     tel +33 1 44274260
fax +31 20 592 5043                     fax +33 1 44274261
email raresec@nikhef.nl                 email michau@frors12.bitnet
X.400 C=nl; ADMD=400net; PRMD=surf;     
      O=nikhef; S=raresec              

Progamme committee :
Christian Michau, Vint Cerf, Howard Davies, Marieke Dekker, Jill
Foster, Frode Greisen, Krzysztof Heller, Dennis Jennings, Barry
Leiner, Manfred Paul, Paul-Andre Pays, Paul Van Binst

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 14:50:51 GMT
From:      plcochet@nysnet.nys.GOV (Peter L. Cochetti)
To:        comp.protocols.tcp-ip
Subject:   Wollongong/ATT 3B2 TCP/IP SLIP Packet Driver


I am trying to connect my ATT 3B2-1000 to internet using SLIP, but the ATT/
Wollongong tcp-ip doesn't have the driver. Does anyone know where I can get it?

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 14:52:41 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: SND.WL1/SND.WL2 confusion

In article <1991Sep16.025334.1409@m.cs.uiuc.edu> zweig@cs.uiuc.edu writes:
>I am tracking down a bug in my implementation of TCP, which I wrote with RFC
>793 open on my lap.  There is some garbled nonsense (at least it looks like
>nonsense to me; I don't know if I'm being stupid or Postel was smoking
>something on page 72) about only updating the send window when SND.WL1 !=
>SEG.SEQ or SND.WL2 != SEG.ACK which is designed to keep you from updating your
>send window on the basis of out of date (retransmitted) ACKs.

That isn't what it says, it says (SND.WL1 < SEG.SEQ  .OR.
(SND.WL1 = SEG.SEQ .AND. SND.WL2 =< SEG.ACK)), which is not what you say
above.  In particular,  SND.WL1 = SND.SEQ .AND. SND.WL2 = SEG.ACK
is permitted.  Assuming that you actually implemented the test
the RFC describes, and just muffed it when describing it in your posting,
this should not be causing your difficulties.

On the other hand, just before the WL1/WL2 stuff on page 72 is the text:

	If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
	updated.

This is a typo that was corrected in RFC1122, page 94, where it
says:
    ...	the window should be updated if: SND.UNA =< SEG.ACK =< SND.NXT


If you implemented this test according to the original text, it will
cause the problem you describe.  1122 corrects a number of typos in
the original documents; you should have a copy of it open on your
desk beside the copy of 793 that you're working from!
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 15:54:52 GMT
From:      ort@frenulum.eng.ufl.edu (Randy Thomas)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.unix.xenix.misc,comp.unix.xenix.sco
Subject:   HLS 6130 Support under SCO UNIX

I am trying to find out how easily I can use a Hughes LAN Systems 6130
broadband NIC under SCO's UNIX.  Neither HLS nor SCO have been very helpful
about this matter.  Each claims that the other has the appropriate drivers
and documentation.  HLS told me that the 6130 card was supported under 
XENIX ONLY!  However, SCO claims no support for the card under XENIX nor
UNIX.  Am I missing the boat here.  Is it possible that SCO's support for
another card might work for the HLS 6130.  Any help would be greatly 
appreciated.

Thank you,

--
Randy Thomas
ort@wasp.eng.ufl.edu
Computer & Information Engineering Sciences
University of Florida

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 16:07:17 GMT
From:      black@beno.CSS.GOV (Mike Black)
To:        comp.protocols.tcp-ip
Subject:   Why can't my clients talk to another subnet?

I have read as much material as is on the net and have succeeded
(somewhat) in implementing subnetting on our buildings Sun workstations.
Here's an example of our setup:

22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
  |                                   |
 Host1                               Host2
  |
 192.9.201.1 (255.255.255.0)
  |
192.9.201.2 Client1
192.9.201.3 Client2

The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
cannot ping,ftp, or telnet to the clients.  Note that a route has
been added thusly:
On Host1: route add net 22.19.6.0 Host1 0
On Host2: route add net 22.19.4.0 Host2 0

The two hosts can talk to each other fine, but not the clients.  Can
someone enlighten me?
Thanx...Mike...

--
-------------------------------------------------------------------------------
: usenet: black@beno.CSS.GOV   :  land line: 407-494-5853  : I want a computer:
: real home: Melbourne, FL     :  home line: 407-242-8619  : that does it all!:
 -------------------------------------------------------------------------------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 19:26:23 GMT
From:      edhall@rand.org (Ed Hall)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>Of course, a better way to view the issue is to note that 
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.

Of course, the exact same charge has been leveled at TCP/IP itself.  I
regard both charges as having the same merit....

		-Ed Hall
		edhall@rand.org

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 21:29:40 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   SLITHERNET versus PPP discussion

I received a recommendation that this discussion be moved from usenet
to the mailing lists.  Articles are separated by ='s.  Newly added
comments are indicated by *'s.

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: brian@telebit.com (Brian Lloyd)
Newsgroups: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <1991Sep11.202249.24555@telebit.com>
Date: 11 Sep 91 20:22:49 GMT

I have been reading this thread (and others elsewhere regarding
"SLITHERNET") with some interest.  What I have yet to understand is
how SLITHERNET is better than PPP (especially since there are so many
PPP implementations now and I have never seen a SLITHERNET
implementation).

*I showed SLITHERNET in Washington in January.  SLITHERNET may not be
*the best way to handle serial links, but PPP is truly backwards.  And
*you are right, if you only compare a single point to point link there
*is no real difference.  But suppose 10 sites are to be interconnected
*by wide-area links.  Running serial links to a packet switch is
*probably a better idea than interconnecting Suns or other routers even
*if serial point-to-point semantics are used between routers.  If the
*number of sites to be connected by wide-area links grows, a complex mesh
*of interconnected packet switches (a communications subnet) might be
*required.  In such a case another level of addressing is required
*because it is undesireable to route packets through the communications
*subnet on the basis of IP address.  Now you can get the necessary
*second level of addressing by using the PPP bridging encapsulation.
*Of course, since bridging PPP includes the whole MAC packet which
*include a type or LSAP/DSAP pair, there is no reason to use
*network level PPP at all. Unfortunately the bridging PPP
*specification is totally brain-dead in that there is a 
*variable number of bytes in front of the MAC addresses.  Because of
*this goop, implementing PPP in a WAN-LAN remote transparent bridge
*is quite painful.

*The question remains how to route packets within
*the communications subnet.  SLITHERNET allows the direct application
*of 802.1d MAC bridging. Again the bridging PPP specification can be
*used but the specification has added yet another level of brain-death
*by not including the MAC addresses with the 802.1d BPDUs.

*In fact, STP may not be the best way to route packets in a wide-area
*communications subnet, but with the extra level of addressing, another
*logical MAC address could be used in the implementation of another
*routing scheme which could be retrofitted later.

As for regionals forcing people to buy a particular vendor's router to
connect to the regional network; that is falling by the wayside.
There are many people who are buying Telebit NetBlazers and running
dedicated sync PPP links to Alternet's cisco routers (that is how we
talk to Alternet here).  Also most of the other IP router vendors are
offering PPP so they can interoperate on point-to-point links too.
The requirement for PPP is becoming part of the router requirements
doc as well.  Why muddy the water with another nonstandard?

*The mere definition of a protocol in an RFC hardly means that it
*is either useful, reasonable or much of a standard.  Who
*uses RDP for anything?

*PPP evinces no evidence of the application of any modern ideas of
*protocol design and in fact violates most principles of good protocol
*design.  PPP is misdesigned for any sort of sophisticated use of a mesh
*of wide-area links.  PPP contains ridiculous cruft in the terms of
*silly FSA's.  PPP is misdesigned relative to trends in capabilities
*provided by the latest crop of LAN or DTE/DCE serial interface chips.
*This silly piece of garbage should be given a swift burial.

-- 
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: brian@telebit.com (Brian Lloyd)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <1991Sep12.173635.5447@telebit.com>
Date: 12 Sep 91 17:36:35 GMT

martillo@jjmhome.UUCP (Joachim Martillo) writes:

>Of course, a better way to view the issue is to note that 
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.
 
>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.
 
>Joachim Carlo Santos Martillo Ajami

You are right, PPP is a bit more complex than it needs to be (FSM,
etc.).  On the other hand, it works and works very well for most
point-to-point circuits over which people transmit the datagrams of
unreliable networks.  There are methods for transferring IP,
Appletalk, CLNP, IPX, and DECnet.  It supports communications between
MAC layer bridges.  It has the support of many people, users and
vendors alike.  There exist many interoperable implementations.  It is
going to be a router requirement.  You are swimming against the tide.

Hey, c'mon now.  There are things that I would like to see done
differently in various protocols in the Internet Protocol Suite.  That
doesn't mean that I reject and spurn IP just because I think that I
can do it better.  Perhaps PPP would have been more to your liking had
you participated in the design, specification, and implementation
process.  I guarantee you that everyone who has done an implementation
has generated input that has helped extend PPP and make it more
useful.

One last point: I have used PPP on everything from a 1200 bps async
dial-up link to a dedicated T1 link and it works very well in all the
cases that I have encountered (real-world that is with real modems,
DSU/CSUs, and telco-supplied links).  The proof of the pudding is in
the tasting, don't you think?

*I would have to do some analysis of link utilization and cpu
*overhead.  The Sun uses an 8530 which has lots of associated
*overhead.  The trend in ethernet chip design seems to be to give
*them an HDLC mode.  Thus to a Sun a WAN card and an ethernet card
*which represents much less cpu overhead than an 8530
*could look identical.  And to the hardware designer converting an
*ethercard to a WAN card might be minor quickly made changes.
*There are lots of economies which could be obtained and which
*might be passed on to the customer if SLITHERNET is used.
*PPP, being totally brain-dead, of course makes such economies
*impossible.

-- 
Brian Lloyd, WB6RQN         Telebit Corporation        The views expressed
Network Systems Architect   1315 Chesapeake Terrace    herein are my own and
brian@telebit.com           Sunnyvale, CA 94089-1100   are not necessarily
voice (408) 745-3103        FAX (408) 734-3333         my employer's.

===============================================================================

Path: cpoint!crackers!jjmhome!martillo
Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@jjmhome.UUCP (Joachim Martillo)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <10930@jjmhome.UUCP>
Date: 11 Sep 91 22:59:39 GMT
References: <169385@pyramid.pyramid.com>

In article <169385@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes:
> In article <1991Sep4.171840.29088@telebit.com> brian@telebit.com (Brian Lloyd) writes:
 
> >Ah yes, Yet Another Serial Protocol (YASP).  Pretty soon its going to
> >be like IBM in the 60's and early 70's when they had about 100
> >different variations of bisync, all mutually incompatible.
 
>    Think of it as job security Brian.  And remember what
>    happened to IBM when their "future site" model resulted in
>    SNA with 7 incompatible LU types....all they did was move the
>    incompatibility above the link layer...

Of course, a better way to view the issue is to note that the
promulgation of PPP is based on a fundamentally silly idea that a
single protocol can solve all problems for all times on very diverse
media over a very wide range of speeds.  Further, even if we accept
this ridiculous premise, PPP is fundamentatlly misdesigned with all
sorts of goop built into the protocol which simply doesn't belong
there, ridiculous FSA's and one of the most moronic methods of
tunneling which I have ever perused.

Somehow promulgating attrocities like PPP looks more motivated by a
hidden agenda to guarantee job security than suggesting a reasonable
alternative.

Joachim Carlo Santos Martillo Ajami

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo)
Newsgroups: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-ID: <14496@cpoint.clearpoint.com>
Date: 10 Sep 91 14:04:53 GMT
References: <2429@crackers.clearpoint.com> <KARL.91Sep1171232@remora.MorningStar.Com> <14455@cpoint.clearpoint.com>
Organization: Clearpoint Research Corp., Hopkinton MA

In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes:

>1) You have to turn on UDP checksumming if you connect two ethernets
>by a bridge rather than a router.  

This should say:

You don't have to turn on UDP checksumming if you connect two ethernets
by a bridge rather than a router. 

Joachim Carlo Santos Martillo Ajami

===============================================================================

Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
To: samsung!crackers!martillo@zaphod.mps.ohio-state.edu (Martillo)
Date: Fri, 13 Sep 91 7:40:42 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nic.ddn.mil
Reply-To: scoggin@delmarva.com
In-Reply-To: <2424@crackers.clearpoint.com>; from "Martillo" at Aug 31, 91 2:31 am

> The following memorandum is a first draft of one of a pair of potential
> RFCs which specify a methodology for using wide-area serial synchronous
> DCE/DTE-type point-to-point links as a computer networking medium.  The
> Clearpoint Little Dipper/Auriga product line offer as one of several
> configurable options a wide-area interface which implements this
> specification, and should a developer implement this interface for his
> bridge, router or end host, that network device will be able to
> communicate with the Little Dipper/Auriga products over point-to-point

If this is a "potential RFC", why isn't it being handled as an Internet
Draft?  

*Because I wanted to get some input from the internet community.

	Also, maybe you should change the name (to be consistent with the
networking community's love of acronyms) to YAPPP - Yet Another Point-to-
Point Protocol.  

*Because I don't like acronyms.

Seriously, if PPP is deficient, shouldn't we create a Working Group to
revisit point-to-point protocols in general?  

*Because that seems like a great way to get nothing done or produce
*an attrocity like PPP.  I doubt ethernet or IP for that matter
*would have be produced or would have been so useful and easy to
*apply if they had been designed by committee.

					      I don't really think the
RFC process was created for the purpose of "legitimizing" proprietary
protocols.  

*This question is orthogonal to the issue.  I proposed SLITHERNET because 
*PPP is deficient in major ways.  Most of my company's business is not
*among the internet community.  And I could make a good argument
*that perhaps the ability to provide an almost shrink-wrap packet
*data network is a competitive advantage for our products, but we
*decided to be good network citizens.

	    A lot of companies are starting to point to RFC xyz and saying
that their product meets an RFC; nevermind that the IETF lists the protocol
and that RFC as Experimental or Not Recommended...

*Sounds like the description which should be applied to PPP.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

===============================================================================

Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Message-Id: <16876@zephyr.ens.tek.com>
Date: 12 Sep 91 19:39:42 GMT
References: <169385@pyramid.pyramid.com> <10930@jjmhome.UUCP>
Followup-To: comp.protocols.ppp
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 25
Status: RO

In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:

>Of course, a better way to view the issue is to note that 
>the promulgation of PPP is based on a fundamentally silly idea that a single
>protocol can solve all problems for all times on very diverse media over
>a very wide range of speeds.  Further, even if we accept this ridiculous
>premise, PPP is fundamentatlly misdesigned with all sorts of goop built
>into the protocol which simply doesn't belong there, ridiculous FSA's and
>one of the most moronic methods of tunneling which I have ever perused.
 
>Somehow promulgating attrocities like PPP looks more motivated by a hidden
>agenda to guarantee job security than suggesting a reasonable alternative.
>
>Joachim Carlo Santos Martillo Ajami

I, as a customer, want to have routers/whatevers from different
vendors be able to talk to each other & route/whatever various
protocol-type packets.  To achieve this 'multiple vendor choice'
scenario, I want a 'standard' protocol to do this, and perform
'adequately'. It doesn't have to be perfect.  Few things are,
especially when designed by committee. I believe many other customers
feel this way.

*Unfortunately, PPP is very brain-dead and hinders any sort of
*sophisticated wide-area networking techniques.  Now maybe Tecktronix
*will never do any sort of sophisticated wide-area networking, but
*I would not count on such a possibility.

If PPP does this, most customers will forgive it's flaws.
And I believe they will view most criticisms at this point as 

  'Too little, too late'.  That's life.

*If you like PPP, go ahead and stick to it.  We do support it
*even though it hinders sophisticated wide-area networking and
*is basically a low-performance protocol.  You will pay for it later.

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: Joachim Carlo Santos Martillo <martillo@azea.clearpoint.com>
Message-Id: <9109092005.AA03696@azea.clearpoint.com>
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking
To: Art Berggreen <iplpdn-request@nri.reston.va.us>
Date: Mon, 9 Sep 91 16:05:55 EDT
Cc: iplpdn@nri.reston.va.us
In-Reply-To: <9109031614.AA29828@opal.acc.com>; from "Art Berggreen" at Sep 3, 91 9:14 am
X-Mailer: ELM [version 2.2 PL14]
Status: RO

>  Just a quick question about the Serial Line Ethernet proposals.
 
>  What mechanisms are being pursued to guarantee WAN like loss rates?
                                                  ^^^
I assume you mean LAN.

The Little Dipper/Auriga products keep track of error rates in terms
of proportion of bad packets detected over unit intervals and can put
an interface in the disconnected state if the error rate becomes too
large.  These products also detect anomalous line conditions and will
turn the interface off entirely in some cases.

The Little Dipper/Aurigas can run a short packet protocol where the
hdlc drivers at both ends of the interface communicate with each
other, set parameter and do tests and develop some statistices.

This short packet protocol is logically out-of-band, and should it be
standardized for interoperability.  But it should probably be put into
a separate specification since this short packet protocol really
addresses a separate problem than data transport which is addressed by
Slithernet and Slide.

There is an even more important reason to keep this sort of link
statistics and testing protocol separate from the main transport
protocol.  While the actual transport specification is unlikely to
change from one serial point-to-point medium to the next, the method
of determining link reliability is likely to change from one type of
serial point-to-point medium to next or may even change with time on a
specific serial point-to-point medium as equipment changes or
improves.

In the past, some of T1 ESF hype suggested that reliability
information might be available on a separate 16 kbps management
channel.  If such information were available on a separate channel,
there would be little reason to require testing and diagnostics to be
built right into the specification of Slithernet or Slide, and in fact
there would be no need for an "out of band" short packet reliability
protocol.  By leaving this protocol to be defined later, I am
purposefully making clear that this protocol should be optional and
may in fact in some cases be irrelevant.

The incorporation of link diagnostics and statistics into PPP is an
example of bad protocol design.  The addition of this functionality
implies an assumption that the designer at the instant of design knew
what is appropriate for all serial point-to-point technologies for all
time and therefore the designer believed it was reasonable for him to
simultaneously solve the transport, diagnostics, statistics and
reliability problem in a big mish-mash rather than reasonably
partitioning the problem.

A reasonable way to handle link diagnostics and testing with
Slithernet would be to allocate a logical mac address for this purpose
and have a diagnostic and test application listening at this address
or connecting to its peer at the other end of the point-to-point link.
Such an application could perform a full suite of tests to obtain much
more useful information than the short packet protocol could provide
or the built-in PPP functionality could provide.  Of course, since PPP
does not have a reasonable addressing mechanism, PPP could not host
such applications.

Even such diagnostic and testing peers might not be sufficient to
choose an appropriate communications path.  Slithernet provides an
architecture for a communication subnet consisting of a mesh of serial
point-to-point links connected by mac bridges (PSNs).  In travelling
from source host to destination host, a packet might transverse
several links and bridges.  Even though the link from the source host
to the first mac bridge might have a sufficiently good error rate (and
maybe all the links in the path as well), the cumulative error over
all links in the path might not be acceptable.

For situations like this, mechanisms like higher level management
protocols might be helpful in determing the best paths, but as of now
providing good transport with reasonable reliability is still an area
of on-going research and development.  Because these are still areas
of on-going research and development, the field of computer networking
is reasonably interesting.  But because a lot of research and
development is still required, the built-in features of a protocol
like PPP for link diagnostics and statistics only provide the warm and
fuzzies for the customer and a sinecure for an engineer, but on the
whole, the approach to protocol design used in PPP is fairly miserable
and the diagnostic and statistics features of the protocol have the
perfect analogy in the snake oil which one might have purchased from a
patent medicine salesman at the turn of the century.

>  1) Don't bother, and live with serial channel error rates.
>  2) Run an error rate monitoring protocol and stop using bad links.
>  3) Run a full error detecting/correcting protocol like LAPB.
>  4) Something else.
 
>  Art

Joachim Carlo Santos Martillo Ajami

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: Mon, 9 Sep 91 13:52:54 EDT
Cc: martillo (Joachim Carlo Santos Martillo)

> > point-to-point links to provide a communications subnet for a
> > subnetwork to which many hosts can be attached.  To these hosts
> > slithernet looks like an ethernet, and therefore all the standard
> > software can be run in the standard configuration.
 
> But using something like a Telebit Trailblazer you get the same
> advantage.  I'm still at a loss for where Slithernet gives the
> user capability he doesn't already have with PPP and a router.

A trail-blazer, a link running PPP and a router gives you simply a
point to point link.  Slithernet allows you to take a set of
serial-point-point links, a set of bridges (to act as PSNs) and build
yourself a shrink-wrap communications subnet for a wide area network.
This communications subnet can provide high availability and fault
tolerance and alternate routing in a way which is transparent to the
devices which are connected.

Now in a sense IP routers are second order PSNs in that they route
between networks which might correspond to wide area communications
subnets, but designing a wide-area network which has more than a
trivial number of point-to-point links is sort of a cludge and rather
costly.  Also, there are a lot better things for which SUN cpu cycles
might be used than for taking lots of character interrupts and
building data packets from the received characters.

The slithernet wide-area network can transport anything which can be
put in an ethernet packet and can support broadcast functionality like
ARP.  Rather than treating the serial interface as some special
non-broadcast medium as must be done with PPP, the slithernet
interface appears to IP more or less as a standard ethernet interface
albeit a slow one (but not much different than some of the versions of
cheapernet which AT&T has marketed in the past).

> > Many ethernet chips have an hdlc mode which expects etherformat
> > packet.  Slithernet takes advantage of this technology.  And in fact
> > for many hardware companies (like Clearpoint) respinning and ether
> > card as a WAN card would be trivial except that the newer
> > sophisticated ether chips are incompatible with PPP.  Actually, the
> > newer serial chips are gaining ethernet modes which cannot be
> > efficiently used with PPP.
 
> What are the implications of this for the user?  Are you saying that
> this eliminates the need for a full-blown router and that something
> that is more bridge-like could take its place?

Just as you can use bridges or routers with ethernet depending on your
needs, you can use bridges or routers with slithernet.

But if the serial chip has an interface to the host processor which
looks like the interface to a common ethernet chip, or if in fact
common ethernet chips can be programmed to do hdlc bit stuffing,
software development is a lot cheaper if the changing one or two lines
of the initialization code of the ethernet driver is sufficient to
turn the ethernet driver into a serial hdlc driver.  If software
development become cheaper, eventually the lower costs might be passed
along to the customer especially because the bridge/router market is
rather competitive.  Unfortunately, because PPP packets do not look
like slithernet packets, PPP prevents such software development
savings and in fact if PPP is the serial communications standard
rather than replacing a couple of line interface chips on an ethernet
board to respin it as a wide-area point-to-point board in a couple of
weeks, the board might have to be completely redesigned over a period
of several months.  The redesign represents major added costs.  Such
costs are passed onto the customer.

Joachim Carlo Santos Martillo Ajami

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Message-Id: <9108302112.AA06328@azea.clearpoint.com>
Subject: Re: your mail

> > You comment that slide can do everything PPP can do.
> > Aside from the obvious fact that it can carry protocols as an
> > extension of ethernet, how does SLIDE cope the the parameter
> > negotiation problem.  That is, depending on performance
> > situations, one (who believes in PPP) wants to negotiate various
> > forms of compression and authentication, etc.  It looks like SLIDE
> > simply says "that function should not be done at this layer".  Is
> > that your intent?
 
> I actually believe this.  After all the bundespost is working on a
> switched or permanent point-to-point ether service and nobody seems to
> worry about the question.  But because of the ethernet min packet
> size, you can use all packets shorter than 62 bytes as out of band
> signals to do all the parameter negotiation one wants.  To tell the
> truth I have forgetten the details of PPP parameter negotiation, but
> you might be able to use the PPP procedures.

This position that parameter negotiation should be somehow out of band
and only ancillary to the protocol is not merely aesthetic.  Suppose a
circuit switched public telephone network is providing transport and a
means of parameter negotiation on the signaling channel.  It might be
preferable to use this mechanism rather than the PPP parameter
negotiation even though PPP might mandate in-band procedure especially
because concerns about parameter negotiations are much larger in
demand circuit switched environments than in leased or nailed-down
line environments.

> After agreeing on basic parameters, you could use an ethernet logical
> address to communicate with an authentication server.  I believe the
> IEEE 802.10 committee is busily working on this.
 
> In any case authentication should be part of a separate specification.
> The argument that one has to use PPP because it provides
> authentication is rather bogus.  I suppose nobody should have used
> TCP/IP, rlogin, telnet or NFS until kerberos was worked out.

If anything the problem of authentication is even more orthogonal to
the question of transport.  Also authentication is an area of ongoing
development.  What is needed can change with circumstances and what is
available can change with time.  Transport and authentication should
be implemented as completely separate but communicating modules which
can be mixed and matched.  There is no obvious reason to include the
authentication procedure as part of the transport specification, and I
would argue that doing so might indicate a less than optimal
partitioning of the various problems associated with computer
networking.

Of course host requirements might specify a set of transport
procedures and a set of authentication procedures.

> Joachim Carlo Santos Martillo Ajami

Joachim Carlo Santos Martillo Ajami

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo (Joachim Carlo Santos Martillo)
Message-Id: <9108301225.AA05846@azea.clearpoint.com>
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

> Briefly, can you explain why
> what you are proposing is different or better than PPP?

PPP is simply an encapsulation for the transmission of packets along a
point-to-point serial DCE/DTE link.  In some sense PPP can handle the
trivial or degenerate case of the problem which Slithernet addresses.

Slithernet provides an architecture for interconnecting such
point-to-point links to provide a communications subnet for a
subnetwork to which many hosts can be attached.  To these hosts
slithernet looks like an ethernet, and therefore all the standard
software can be run in the standard configuration.

Many ethernet chips have an hdlc mode which expects etherformat
packet.  Slithernet takes advantage of this technology.  And in fact
for many hardware companies (like Clearpoint) respinning and ether
card as a WAN card would be trivial except that the newer
sophisticated ether chips are incompatible with PPP.  Actually, the
newer serial chips are gaining ethernet modes which cannot be
efficiently used with PPP.

In general PPP is a backwards-directed concept.

Joachim Carlo Santos Martillo Ajami

===============================================================================

Sender: <tcp-ip-relay@nisc.sri.com>
From: Joachim Carlo Santos Martillo <martillo@azea.clearpoint.com>
Subject: Re:  Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: Fri, 30 Aug 91 4:33:54 EDT

> Did you know that SLIDE was used in the way you describe by the Bridge
> Communications IB/3 in 1986?  It runs DC to 10 MBPS, you believe the
> data sheet.

So what? A SLIDE encapsulation is rather obvious.  They were probably
not the first either.

> Great, if you are doing Ethernet (not 802.5 or mixed media) remote
> bridging over a point to point line.  No so hot if you're routing - the
> header on the line just became a minimum of 14 octets, maybe as much as
> 20.  Frame Relay? SMDS?

20 bytes! Quel horreur!  I don't understand the point.  Routers
between token ring and Ethernet have been built and work fine.  There
should be no reason routing between token ring and slithernet won't
work as well except for the larger rate differential.

> The 82586, by the way, doesn't generate or not generate FCS on a frame
> by frame basis.  That is a feature of the 82596.

I have never programmed an 82586, but when Intel was trying to sell me
on this chip, the technical rep claimed that if CRC needed to be
generated on a per packet basis, the procedure was to chain a
configure command which turned on CRC generation before the transmit
command and then chain a configure command which turned off CRC
generation after the transmit command.

> You should talk to 3COM.  They've got a lot of experience with SlitherNET.
> And they don't use it anymore.

I have built a SLITHERNET.  It works fine and has run for a year.  And
I have beat on it with all sorts of protocols including NFS.

Joachim Carlo Santos Martillo Ajami

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 22:08:00 GMT
From:      tal@WIMSEY.BC.CA (Tal Elyashiv)
To:        comp.protocols.tcp-ip
Subject:   BSD tcp source code?

Can anybody tell me where BSD tcp, tftp, and telnet source code
can be found?

Thanks,

Tal Elyashiv
R&D Dept.
Delta Controls Inc.
(604) 590-8184

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 23:41:30 GMT
From:      ASASG@ASUACAD.BITNET
To:        comp.protocols.tcp-ip
Subject:   looking for a thesis topic

Dear Friends,

I am a student at Arizona State University doing my Masters in Computer

Science. I am presently looking for a good topic for my thesis and hence

have been referring to various journals but have not come up with a good

topic. I intend to work in the area of TCP/IP. If any of you have a good

topic in mind or have any suggestions to make, please let me know.


I look forward to hearing from you.


Sincerely yours,

Aniruddha Gokhale


e-mail address : gokhale@enuxhb.eas.asu.edu
     or        : asasg@asuvm.inre.asu.edu

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 91 23:48:48 GMT
From:      scd@math.ufl.edu (Steve C Donahue)
To:        comp.protocols.tcp-ip
Subject:   Dialup IP


I have the CREN/CSNET release of Dialup IP (version 2.0).  The docs for
this claim that the code has been installed on Sun OS 3.5.  We are running
Sun 4.1.1 rev A.  I am having a problem with the installation and I think
(actually, I am sure) that it has to do with the difference in OS
revisions.  In the installation docs, they say to modify the file
/sys/sys/tty_conf.c.  I assume that this was a pre-4.1.1 file because it
does not exist now.

I would really like to use this version of SLIP because it negotiates phone
connections on demand.  If there is another package that does this, I would
gladly take it.  However, I have not been able to dig one up.  Any help
would be appreciated.

--
----------------------------------------------------------------
It is a miracle that curiosity survives formal education.
       -- Albert Einstein

 Steve Donahue                 Internet: scd@cis.ufl.edu
 CIS Engineering               NeXTmail: uflorida!thecube!steve
 University of Florida

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 00:20:01 GMT
From:      netnews@leadsv.UUCP (Leads Network News)
To:        comp.protocols.tcp-ip
Subject:   API for FTP?

Is there an application program interface to FTP, with examples (software)
of how to use it?  Ideally, this would be a set of C routines that we
could FTP.  

We're writing some software that will use FTP, and we're looking for the
interface and examples of how to use it.  Thank you.

Charley Pow

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 01:02:57 GMT
From:      hayes@ultra.com (John Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

In <49983@seismo.CSS.GOV> black@beno.CSS.GOV (Mike Black) writes:

>I have read as much material as is on the net and have succeeded
>(somewhat) in implementing subnetting on our buildings Sun workstations.
>Here's an example of our setup:
 
>22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>  |                                   |
 Host1                               Host2
>  |
 192.9.201.1 (255.255.255.0)
>  |
>192.9.201.2 Client1
>192.9.201.3 Client2
 
>The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
>cannot ping,ftp, or telnet to the clients.  Note that a route has
>been added thusly:
>On Host1: route add net 22.19.6.0 Host1 0
>On Host2: route add net 22.19.4.0 Host2 0
 
>The two hosts can talk to each other fine, but not the clients.  Can
>someone enlighten me?

From your network number of 22 it would seem that you have one portion of 
your network configured as a subnetted class A net, while a separate section
of the net (192.9.201) is a subnetted class C net.  You are trying to use 
both sections with the same netmasks.  

For the sake of this discussion I am going to assume that host 1 and
host 2 are running routed, and that the clients are not.  The following 
answers may change slightly if this is not the case.  For clarity, I will 
refer to the 22 net as NET1 and the 192.9.201 net as NET2.

The netmasks that should be used in the ifconfig for the interfaces in NET1
should be something on the order of 255.255.0.0.  I specify interfaces rather
than machine, because Host1 has 2 interfaces, one for each net.

The netmasks for those interfaces on NET2 should be something like
255.255.255.0.  

The 'Host' machines should have no need for any route add's, as they are
running routed, and each of the client machines should have a route as
such: route add net 22.19.0.0 Host1 1 

John.

-- 
John Wm. Hayes 						hayes@ultra.com  
UltraNetwork Technologies				(408)922-0100 x202

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 01:28:56 GMT
From:      dalton@pine.circa.ufl.edu (DALTON)
To:        comp.protocols.tcp-ip
Subject:   Reply on CMUIP Mail on a Vax

We are having trouble getting the CMU-IP e-mail to work on our Vax.
We are able to get IP mail to e.g. Dalton@Robot.nuceng.ufl.edu. just fine
but we can only reply while reading the Vax mail received if the sender
is on the Robot machine or on the DecNet cluster.  Can anyone help on this.

We are able to rount mail through another mathine using the command:

mail  anyfile.txt  ""Other_vax::Wins%""<user@machine.dept.site.network>"""

But we would like to be just use the Reply option within Vax Mail.  I can 
use to Reply on the Other_vax that is running the Wollongong WINS software, 
but not on Robot, using CMU-IP.

Any help will be appreciated.

Ron Dalton, Prof. Nuc. Eng. Sci., U. of FL, Gainesville.
Dalton@Robot.NucEng.UFL.edu.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 06:51:13 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I) (fwd)

This further discussion of the merits of PPP may be of interest.

Sender: <tcp-ip-relay@nisc.sri.com>
From: martillo@crackers.clearpoint.com (Martillo)
Newsgroups: comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
Date: 18 Sep 91 12:27:54 GMT
References: <169385@pyramid.pyramid.com> <10930@jjmhome.UUCP> <1991Sep17.192623.5717@rand.org>
Organization: Clearpoint Research Inc, Hopkinton, MA

In article <1991Sep17.192623.5717@rand.org> edhall@rand.org (Ed Hall) writes:
>In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>>Of course, a better way to view the issue is to note that 
>>the promulgation of PPP is based on a fundamentally silly idea that a single
>>protocol can solve all problems for all times on very diverse media over
>>a very wide range of speeds.
 
>Of course, the exact same charge has been leveled at TCP/IP itself.  I
>regard both charges as having the same merit....
 
>		-Ed Hall
>		edhall@rand.org

Just go ahead and compare apples and oranges.  It shows good analytical
skills.  I probably should have said "a single link level protocol" but
I assumed most people would understand.  The logic of PPP is rather more
like claiming that 802.5 algorithms can be used on all ring media even
though there are ring media which don't use tokens. 

TCP does one job well.  It provides sequenced reliable transport on
top of a virtualized network layer.  PPP by way of contrast tries
to do all sorts of random crap.  The TCP designers understood how to
do good protocol design.  The PPP designers did not understand.

Joachim Carlo Santos Martillo Ajami

-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 11:51:12 GMT
From:      se@IKP.Uni-Koeln.DE (Stefan Esser)
To:        list.sco,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,biz.sco.general,comp.unix.sysv386,comp.unix.wizards
Subject:   Re: Need help selecting Ethernet cards for very high throughput rates.

In article <PCG.91Sep9183332@aberdb.aber.ac.uk> you write:
|>That's impossible to achieve, it ignores inband formatting information
|>(headers, CRC, pauses between packets) and other practical constraints.
 
|> The very best Ethernet sw can drive it at 0.8MB/s, sustained, with
|> occasional bursts at 0.9MB/s.

What makes you that sure ? 
Would you believe someone who, has seen more than 900KB/s, sustained ?

May be that you can't *imagine* TCP transfers faster than 800KB/s.
But there are people who *know* that it is possible, because they've done it.

If you have INTERNET access to this site, I invite you to test the ethernet 
performance of our DEC 5000/200 and Sparc 2 systems.
Then you'll also know that it is possible ...

Stefan
-- 
 Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
 se@IKP.Uni-Koeln.DE                                           [134.95.192.50]

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 12:27:54 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <1991Sep17.192623.5717@rand.org> edhall@rand.org (Ed Hall) writes:
>In article <10930@jjmhome.UUCP> martillo@jjmhome.UUCP (Joachim Martillo) writes:
>>Of course, a better way to view the issue is to note that 
>>the promulgation of PPP is based on a fundamentally silly idea that a single
>>protocol can solve all problems for all times on very diverse media over
>>a very wide range of speeds.
 
>Of course, the exact same charge has been leveled at TCP/IP itself.  I
>regard both charges as having the same merit....
 
>		-Ed Hall
>		edhall@rand.org

Just go ahead and compare apples and oranges.  It shows good analytical
skills.  I probably should have said "a single link level protocol" but
I assumed most people would understand.  The logic of PPP is rather more
like claiming that 802.5 algorithms can be used on all ring media even
though there are ring media which don't use tokens. 

TCP does one job well.  It provides sequenced reliable transport on
top of a virtualized network layer.  PPP by way of contrast tries
to do all sorts of random crap.  The TCP designers understood how to
do good protocol design.  The PPP designers did not understand.

Joachim Carlo Santos Martillo Ajami

-- 
The statements contained in this article solely represent the views of
the author and in no way do they reflect the official opinion or policy
of Clearpoint Research Corporation.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 12:35:48 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan E. Miller)
To:        comp.protocols.tcp-ip
Subject:   Sendmail


Any sendmail guru's out there???

I have a question concerning "Apparently-to".  When exactly should you
see this line in a mail header, as opposed to the normal "To:"???

Thanks,

Bryan Miller
bmiller@cabell.vcu.edu

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 13:59:42 GMT
From:      chi@SPARTA.COM (Chi Chu)
To:        comp.protocols.tcp-ip
Subject:   let me out!

Please unsubscribe chi@sparta.com.  I can't take it anymore!

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 14:58:55 GMT
From:      albright@LAGER.CISCO.COM (Bob Albrightson)
To:        comp.protocols.tcp-ip
Subject:   Re: udp on Internet Connection

> Hi All
> 
> We are just about to get our connection to the Internet. We are planning
> to install a router of our own (CISCO) which we will use to keep
> unwanted traffic from our own network (and vica versa). I am wondering
> what functions we will loose (or what problems we will cause ourselves)
> if we prevent any UDP traffic between our local network and the
> Internet.

You will loose domain name service.  Some routing protocols use UDP.  Just to
name a few.  Don't filter all UDP.

 -bob

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 15:45:56 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP FIN and window

>Date: 5 Sep 91 18:08:30 GMT
>From: rochester!rocksanne!sma@cu-arpa.cs.cornell.edu  (Susie Armstrong)
>Organization: WRC, XEROX
>Subject: Re:  TCP FIN and window
>Message-Id: <897@rocksanne.WRC.XEROX.COM>
>References: <9108261807.AA27462@leo.md.interlink.com>
>To: tcp-ip@nic.ddn.mil
>Status: R
 
>Fred Bohle mentions that the TCP on Xerox boxes will not send
>a FIN into a zero window. ...
 
>Note that though I will not send a FIN into a closed window,
>I will process a FIN that I receive into my closed window (my
>window reflects buffering for "physical data", and FINs don't
>consume buffers, so processing that FIN is easy to do).  This
>reflects my belief in that old transport implementation rule
>"be conservative about what you send, be liberal about what
>you accept".

Exactly.  This is why I think a clarification is in order here.
Following this rule leads us into this problem.  I believe that
you SHOULD send the FIN into a zero window, and you believe that
you should NOT.

I wrote several points trying to justify my position, and would
like others to comment on them.  Briefly they are:

1. FIN, like SYN is a session control function, and as such
   deserves special treatment.

2. FIN takes sequence space but not data space, so buffering
   considerations do not apply.

3. This strategy of sending FIN into a zero window is practiced
   by a great number of implementations, so interoperability is
   NOT impaired by following it.  On the contrary, interoperability
   IS impaired by NOT following it.

4. If it makes you feel better about it, consider sending FIN in this
   situation to be more like a zero window probe.  You MUST support
   zero window probes, and FIN is one byte beyond the current sequence
   number in the situation which gave rise to the problem is the first
   place.

   (The original problem was trying to close the FTP data connection.
    The data port had a zero window in the reverse direction.  Xerox
    would not send the FIN into this zero window.)


>However, I do agree that the specification is not
>explicit on this point, and sending the FIN into a closed
>window (and having it accepted) does not harm the integrity
>of the data or of the closing handshake.
 
>This implementation was done pre-host-requirements-rfc -
>perhaps that document has some more clues on the commonly
>accepted treatment of FINs in general, if not on this case
>specifically.

No such luck.  My scan of host-req. did not show up anything useful on
this issue.

>Cheers,
>    Susie Armstrong
>    Xerox Webster Research Center
>    armstrong.wbst128@xerox.com


Glad to meet you Susie.  Let's pursue this further, offline if you wish.

Others, please respond with opinions and suggestions for how to proceed
(RFC perhaps?)
Fred
------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 16:03:25 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re:  tn3270 on SNA emulators


	Date: 6 Sep 91 02:16:34 GMT
	Sender: <tcp-ip-relay@NISC.SRI.COM>
	From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!manuel!jatz.aarnet.edu.au!pte900@ucbvax.Berkeley.EDU  (Peter Elford)
	Organization: AARNet
	Subject: tn3270 on SNA emulators
	Message-Id: <1991Sep6.021634.20465@newshost.anu.edu.au>
	To: tcp-ip@nic.ddn.mil


	Why don't vendors offer SNA gateways that support tn3270 servers ?, ie.

	    +--------+               +------------------+        +--------+
	    | PC/Mac |               |     Gateway      |        | IBM    |
	    |        |               |                  |        |        |
	    | tn3270 |               | tn3270 |   327x  |        |        |
	    | client |               | server | emulator|        |        |
	    +--------+               +--------+---------+        +--------+
	        |                         |        |                 |
	      --+--- tn3270 protocol -----+-       +--- SNA/BSC -----+

	This would provide much better, more IBM-like access to the mainframe
	system, and would avoid the cost and overheads of installing a LAN
	interface and IP software on the IBM mainframe (which is not cheap :-).


Then you lose the ability to use other functions to/from the IBM mainframe!
You cannot FTP to/from the IBM mainframe, you cannot Telnet FROM the IBM,
you cannot MAIL to/from the IBM,  you cannot use an API to write TCP appl.
code, you cannot use NFS there, ...

It is not cheap, but it is not all that expensive either.


------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 16:05:05 GMT
From:      hendrick@ctron.com (Jim Hendrick)
To:        comp.protocols.tcp-ip
Subject:   Looking for an old Posting by Jacobson

I am looking for postings regarding performance of TCP/IP, specifically the

interim notes on BSD Network Speedup posting by Jacobson posted here in
comp.protocols.tcp-ip July 1988

and the

Cong. Avoid. and Control "Comp. COmm. Review" vol 18 no 4 pp 314-329
procc ACM SIGCOMM Aug 1988

and supposedly posted here in this newsgroupp Nov. 1988.

Any info would be appreciated Thanks.

--
###############################################################################
### My opinions, etc are exclusively the property of nobody in particular.  ###
### "If you think this is a mess, you should see what its like in here..."  ###
### tapping his forehead. . .                                               ###
###############################################################################

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 18:49:42 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   Please remove me from this list.


Please remove me from this list.


      || * * * * * =========       Tom Varga
      ||  * * * *  =========       Kendall Square Research
      || * * * * * =========       617-895-9415
      || ===================       tom@ksr.com
      || ===================       uunet!ksr!tom
      || ===================       N2UA @ KA1PEP
      ||

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 19:50:18 GMT
From:      TGAMS@CUNYVM.BITNET (Tom Abernathy)
To:        comp.protocols.tcp-ip
Subject:   SLIP for IBM-PC, SUN3, SUN386i, VAX/VMS

I am looking for information / sources for Serial Line IP implementations
for IBM Personal Computers (running DOS), SUN3 and/or SUN386i, and
VAX running VMS and WIN/TCP.
If there are public domain versions of this where are they.
Thank you.

Tom Abernathy
Mount Sinai School of Medicine
tom@msrcvax
or
tgams@cunyvm.cuny.edu

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 20:52:54 GMT
From:      allebrandi@inland.com (Tom Allebrandi)
To:        comp.protocols.tcp-ip
Subject:   "Reverse Subnetting"

I have a question about subnetting and netmasks. None of the documents
I have read, including the RFC (whose number I forget), deal with what
we are trying to do.

The NIC has assigned our company 32 Class C network numbers. The
numbers were carefully chosen so that

	1) The "C" byte for the first one is a multiple of 32;
	2) The "C" byte for the rest of the numbers follow in sequence.

Specifically, we have 192.111.128 through 192.111.159.

What we would like to do is this: Pretend to be a Class B subnetwork by
using a netmask of 255.255.224.0 The way that I understand subnets is
that you do the following:

	1) AND the source IP address with the netmask;
	2) AND the destination IP address with the netmask;
	3) If the answers are the same, the two hosts are on the same
	   local network.

For example:

	A) 192.111.128.1 AND 255.255.224.0 = 192.111.128.0
	B) 192.111.132.1 AND 255.255.224.0 = 192.111.128.0
	C) 192.111.167.1 AND 255.255.224.0 = 192.111.160.0

Hosts A and B would be treated as being on the same local network; C
would not be on the same local network.

I've tried this idea on a number of different TCP/IP implementations.
My results are:

1) CMU/TEK TCP/IP on VAX/VMS - Works

2) Multinet TCP/IP on VAX/VMS - I have been told that this works

3) DEC Ultrix-32 (version 4.1) - Will not let you set the netmask for a
   Class C network number to anything but 255.255.255.0

4) Sun O/S (version 4.something) - You can set the netmask but once you
   do the local host can no longer communicate with the network.

5) Silicon Graphics Unix (version unknown) - Same as for Sun O/S.

For those that don't work, should it? Am I possibly just doing
something wrong? On the Ultrix machine, for example, I use

	/etc/ifconfig ln0 192.111.132.78 netmask 255.255.224.0

to start TCP/IP. I use a similar command on the Sun and Silicon Graphics.

Please respond by Email, I'll summarize if necessary.

Thanks!

--- Tom Allebrandi		Inland Steel Research Labs
    Allebrandi@Inland.Com	East Chicago, IN

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:30:01 GMT
From:      jon@mxmsd.UUCP (Jon Fields)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Dialup IP and Telebit NetBlazer

Hello,

We require some low volume, low cost, TCP/IP connections to  remote
hosts for purposes of ftp, telnet, and running X clients.  The XRemote
product from NCD satisfies the last requirement, but not the first
two.  SLIP will satisfy the first two, but I have heard that it 
performs very poorly for the last.

I have heard about the Telebit NetBlazer, and have sent away for
info on it.  I would greatly appreciate comments from people who have
similar requirements to ours, and how they have been satisfied.  Also,
any comments by current NetBlazer products would be received
with great interest.  And finally, if you know of other dialup IP
products, please let me know.

E-mail is fine; I will post a summary if there is enough interest.

Thanks!!

Jon Fields
--
 UUCP: ...uunet!mxmsd!jon         Jon Fields
Voice: (513)-825-3931 x-314       Measurex--Management Systems Division
  Fax: (513)-825-5393             1280 Kemper Meadow Drive
                                  Cincinnati, Ohio 45240

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:41:16 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Wireless network connections?

The October _Unix World_ contains an article about radio-based wireless
LAN communications.  The article is slanted toward the company which is
contemplating building a complete LAN based on radio transceivers.

In my case, I'm wondering if a single point-to-point radio connection
might be more cost-effective than infra-red for a 100-meter haul across
a roadway and parking lot.  At last check, a pair of IR transceivers
for Ethernet cost on the order of US$12,000.  This article mentions the
existence of radio transceivers costing as little as $2,800 a pair.

Ideally, the cost of this could be brought down to a level comparable
with or below that of a 56K leased line plus modems, and deliver better
performance (perhaps even 10M, which IR can deliver).

The vendors mentioned in the article are Motorola, NCR, and
Telesystems.  The NCR product plugs into an AT bus, which could theore-
tically be configured as a low-cost TCP/IP router if outfitted with an
Ethernet LAN card and appropriate software.

Has anyone set something up like this?  In our case, this would be a
temporary solution, as our company is contemplating a move and even if
it doesn't move there will eventually (12-24 months) be fiber optic
conduit available at our doorstep.

I don't have purchasing authority on this, but I'd love to be able to
go to management and say, "We can join Internet for under $10,000 and
thereby save $30,000 a year".  At this point, direct Internet access is
a pipe dream, given presently-high startup and monthly access costs.

-rich

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 21:51:45 GMT
From:      bcanning@REED.EDU
To:        comp.protocols.tcp-ip
Subject:   unsubscirbe bcanning@reed.edu

please unsubscribe bcanning@reed.edu

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 91 22:33:56 GMT
From:      pnm@SATURN.ACC.COM (Patrick N. Medved)
To:        comp.protocols.tcp-ip
Subject:   SCO Drivers


I am working on porting a driver from a Sun Machine
to a SCO Unix machine.  I need the driver to interface
to IP.  I called SCO and they said their documentation
doesn't go into that.  Possibly if I got involved with
their developer relations, then they could get me
some information on how to do it, or maybe some sample
drivers.  

It seems to me I have seen some messages on this list
about drivers for SCO.  I would appreciate some
information on how to connect a driver on SCO to IP.

Specifically, could someone point me to some SCO IP drivers that are
available via FTP and any documentation for doing this.

Thanks, Pat

pnm@saturn.acc.com

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 10:11:32 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

hayes@ultra.com (John Hayes) writes:

>In <49983@seismo.CSS.GOV> black@beno.CSS.GOV (Mike Black) writes:
 
>>I have read as much material as is on the net and have succeeded
>>(somewhat) in implementing subnetting on our buildings Sun workstations.
>>Here's an example of our setup:
 
>>22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>>  |                                   |
 Host1                               Host2
>>  |
 192.9.201.1 (255.255.255.0)
>>  |
>>192.9.201.2 Client1
>>192.9.201.3 Client2
 
>>The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
>>cannot ping,ftp, or telnet to the clients.  Note that a route has
>>been added thusly:
>>On Host1: route add net 22.19.6.0 Host1 0
>>On Host2: route add net 22.19.4.0 Host2 0
 
>>The two hosts can talk to each other fine, but not the clients.  Can
>>someone enlighten me?

Clients:  'route add default Host1 1'
(assuming that 192.9.201 is the only net here, and Host1 can forward ie is
running routed or gated) will give the clients access to 22.19.x or whatever
Host1 knows about. But remember that IP is two way, and Host2 still does not
know how to send (back) to the clients.

>From your network number of 22 it would seem that you have one portion of 
>your network configured as a subnetted class A net, while a separate section
>of the net (192.9.201) is a subnetted class C net.  You are trying to use 
>both sections with the same netmasks.  

The class C net is not subnetted!  That is the normal mask. It doesn't
matter that the two nets have the same mask.

>For the sake of this discussion I am going to assume that host 1 and
>host 2 are running routed, and that the clients are not.  The following 

Neither host2 nor the clients *need* run routed, but host1 does

>The netmasks that should be used in the ifconfig for the interfaces in NET1
>should be something on the order of 255.255.0.0.  I specify interfaces rather

This makes things much easier, because now both hosts are in the same subnet.
Either running routed/gated on Host2, or 'route add net 192.9.201 Host1 1' 
will do. I would favour the dynamic (routed) approach.
But what if they *want* 24 bits of subnet?  Then they would like to have
'route add net 192.9.201 Host1 1' but Host2 can't do that because it's not
in the same (logical) net as Host1, even though they're on the same cable.
Now, they need a host which can have multiple interfaces on the same
physical cable, and can 'pass' packets from one subnet to the other (in
reality, forward them out on the same cable).  Routers (can you say $$$) do
this using logical addresses for one physical interface.  The hosts would
then have a judicious mixture of static routes (one, in this case) and a
default. For host2: 'route add net 22.19.4 Host2 0' & 'route add default
22.19.6.254 1' where the router has 22.19.x.254 as its secondary addresses
on every subnet. (I guess that could be 22.x.y.254, but I assume there's
more to this network that's not been presented, why else have a class C net
at all?, there seems plenty of spare class A)
The static routes are not strictly necessary but improve efficiency since
packets sent to the default will be doubled on the network.

>The netmasks for those interfaces on NET2 should be something like
>255.255.255.0.  

I assumed that they were already

>The 'Host' machines should have no need for any route add's, as they are
>running routed, and each of the client machines should have a route as
>such: route add net 22.19.0.0 Host1 1 

Or the more general default one

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 12:30:31 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


 > From tcp-ip-relay@nisc.sri.com Thu Sep 19 03:30:44 1991
 > Sender: <tcp-ip-relay@nisc.sri.com>
 > From: fab@md.interlink.com (Fred Bohle)
 > To: fab@md.interlink.com, kasten@europa.clearpoint.com,
 >         mentor.cc.purdue.edu!dls@purdue.edu, tcp-ip@nic.ddn.mil
 > Subject: Re: TCP FIN and window
 > 
 > Frank writes:
 > 
 > >From: kasten@europa.clearpoint.com (Frank Kastenholz)
 > >Message-Id: <9109061751.AA20593@europa.clearpoint.com>
 > >To: fab@md.interlink.com, mentor.cc.purdue.edu!dls@purdue.edu,
      tcp-ip@nic.ddn.mil
 > >Subject: Re: TCP FIN and window
 
 > >>From RFC792:
 
 > >2.10.  Robustness Principle
 
 > > TCP implementations will follow a general principle of robustness:  be
 > > conservative in what you do, be liberal in what you accept from
 > > others.
 > 
 > So what is your conclusion from this statement.  I want to be liberal
 > and accept the FIN, in fact I already do that.  What is not determined
 > is does the statement about being conservative mean the other end should
 > NOT send the FIN?  I argued against this in previous messages.
 > 
 > Let's hear your opinion, Frank.

when there is a particular form of behavior which is of dubious "legality"
per the spec, then do not do it. 

if you can make sense out of a packet when you receive it and you can correctly
process it, then you should.

if you are advertising a window of size n and a packet comes in that is bigger
than size n, if you can process it (have the buffers/computrons/whatevers) then
you should do so. you should not gratuitously drop the packet.

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 14:21:30 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: EBCDIC ASCII and *much* more

u
 t!wnoc-tyo-news!sranha!sranhd!srava!erik@ucbvax.Berkeley.EDU>

On 6 Sep 91 01:28:05 GMT you said:
>Andr'e PIRARD writes:
>> So, because we restrict ourselves to single-octet codes for now
>
>What do you suggest for the Japanese, Chinese, Korean, and Taiwanese
>users?

A decent solution of the war between ISO and Unicode.
So they can start using computers. I know what's waiting.
But most of all a single code.
I know that redundant character codes mean big troubles.
So, no rush towards immediate solutions for profit.
But I don't think America will abandon ASCII right away.
There is still some CP/M around!
The same holds for 8-bit codes.

Andr'e.

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 15:36:34 GMT
From:      pnm@SATURN.ACC.COM (Patrick N. Medved)
To:        comp.protocols.tcp-ip
Subject:   SCO DRIVERS


I am working on porting a driver from a Sun Machine to SCO UNIX.
I need the driver to interface to IP.  I called SCO and they said
their documentation doesn't go into that.  If I was to become
involved with developer relations, I could get info on 
interfacing a driver to IP.  

I think the interface is called the LI interface.  I thought
I had seen some drivers mentioned in this group that were
written for SCO Unix as available via FTP.

I would appreciate any information on how to get any drivers
or documentation via FTP if possible.

Thanks, Pat 		pnm@saturn.acc.com

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 15:42:14 GMT
From:      rogers@ux1.cso.uiuc.edu (Bill Rogers)
To:        comp.protocols.tcp-ip
Subject:   I need a PD bootp server for DOS?

Is there a pd dos implemetation of bootp server to assisn IP address?
We are using a mix of NCSA, Clarkson, and Ka9q and would like to dynamically
assign ip's.
Thanks,
Bill

-- 
..............................................................................
Bill Rogers                             . Internet - rogers@ux1.cso.uiuc.edu
Asst. Director for Academic Computing   . Bitnet - ROGERS@UIUCVMD
Sangamon State University               . Voice - 217-786-6549

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 16:46:01 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <9109062037.AA18038@leo.md.interlink.com> fab@MD.INTERLINK.COM (Fred Bohle) writes:
>So what is your conclusion from this statement.  I want to be liberal
>and accept the FIN, in fact I already do that.  What is not determined
>is does the statement about being conservative mean the other end should
>NOT send the FIN?  I argued against this in previous messages.

Sending the FIN is fine.  It's just another probe into a zero window.
The fact that you probe as soon as the FIN is available is just an
implementation detail.  What isn't conservative is announcing a zero
window yet expecting the remote node to send the FIN to you briskly.

						don provan
						donp@novell.com

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 18:31:53 GMT
From:      phil@brahms.amd.com (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

dls@MENTOR.CC.PURDUE.EDU writes:
>	Anyone for being tough on crime, too?!? :-)

Let's end government waste, fraud and abuse.

Also, let's be tougher about collecting on student loans.

--
This posting is purely a personal opinion.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 18:38:25 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problem from hell

Well, I'll take a stab at it, too.

>>The root of the problem is that my router sits on subnet 78 and the router
>>to the AAA.BBB.CCC.0 network sits on subnet 10.  When I try to add a route
>>sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net
>>AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable
>
>This is correct. XXX.YYY.10 is not in your subnet.

What you really need to do is designate a single subnet on the bridged
Ethernet in which all the routers live.  Or, if your default router
handles multiple subnets (e.g. cisco), you can define a secondary address
on it that is in your subnet (78 in your case).

>>This leads to 2 questions:
 ...
>>2)     One way to solve this would be to change the subnet mask on the 78
>>       side of my router to 255.255.0.0.  Can the Sun IP code deal with a
>>       machine with 2 different subnet masks for the same class B network.
>
>If it can, it's broken! If the 78 side is now net XXX.YYY.0.0, then
>XXX.YYY.252.0 is a host address in the same network, not a net address.

I wouldn't go so far as to call it broken.  It is generally the case that
you have to use the same subnet mask on each side, but it doesn't have to
be, if the router will accept subnet masks per route, and sort the routes
properly (smaller subnets to the top).  The Sun IP code doesn't do this.

Doug Nelson
Michigan State University













 !
 graeme@ucbvax.Berkeley.EDU>

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 18:51:13 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Duplicate/old mailings

Is NISC.SRI.COM having trouble getting mail out to the TCPIP list?  I am
receiving frequent multiple copies of letters, and letters that are up
to two weeks old.

I don't have any reason to suspect that it's a problem with the SMTP on
my end; is it that I'm just too far down (up) the list, and it can't tell
exactly where it left off when it encounters a non-responding address?

Doug Nelson
Michigan State University

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 19:26:13 GMT
From:      oleg@watson.ibm.com (Oleg Vishnepolsky)
To:        comp.protocols.tcp-ip
Subject:   Re: API for FTP?

In  <17879@leadsv.UUCP>  netnews@leadsv.UUCP (Leads Network News) writes:
> Is there an application program interface to FTP, with examples (software)
> of how to use it?  Ideally, this would be a set of C routines that we
> could FTP.
>
> We're writing some software that will use FTP, and we're looking for the
> interface and examples of how to use it.  Thank you.
>
> Charley Pow

IBM OS/2 and DOS TCP/IP products come with client FTP API. They do come
with examples of how to use it.
Other vendors may have it as well but I personally am not aware of any.

Oleg Vishnepolsky

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 20:37:44 GMT
From:      robert@nysnet.nys.GOV (Robert J. Vitello)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   SLIP driver for AT&T 3B2


We are operating a 3B2/1000 using AT&T's remarketing of Wollongong's
TCP/IP.  While Wollangong supports the SLIP driver, AT&T even denies
that there is such a thing.  And because of the relationship between
Wollongong and AT&T, it appears that we can't get the SLIP driver from
the original supplier either.

Has anyone a way around this?  Are there any alternative sources?

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 21:04:53 GMT
From:      aej@manyjars.WPI.EDU (Allan E Johannesen)
To:        comp.protocols.tcp-ip
Subject:   Protocol Test Suite

Is something similar to the "DCA Upper Level Protocol Test System
Software" filed away in some FTP archive?

I have seen an old reference to a 1600 BPI tape of binaries which
would run on ULTRIX 1.1 available from NTIS, but was hoping a more
contemporary software source was available somewhere on the Internet.

This package tested interoperability of TCP, IP, SMTP, FTP and TELNET.

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 91 23:27:04 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window

In article <9109062156.AA16523@mentor.cc.purdue.edu> dls@MENTOR.CC.PURDUE.EDU writes:
>	"Be liberal in what you receive and conservative in what you
>send" practically qualifies as a political sound bite. All the substance is
>subject to interpretation. Everyone will agree it's a good idea to do that,
>which is undoubtedly why it is quoted so often, but it doesn't mean any
>agreement at all on the issue.

On the contrary, i dare say this rule has been applied zillions of
times with utter certainty to make implementation decisions and settle
arguments.  If you consider it a vacuous motherhood, perhaps you do
not understand it very well.

Its application is, perhaps, blurred in this particular case because
the suggested handling of FIN is "only a little liberal", being only
slightly at odds with the specs.  In addition, this behavior is a
reasonable candidate for canonization in future specs.  (The presence
of this behavior in the specs would, of course, instantly make it
conservative.)

Finally, notice that this FIN handling only causes problems in rare
cases.  This is a classic proof of The Rule: sending something too
liberal is only a problem when communicating with a second
implementation that's too conservative about what it receives.  The
beauty of applying The Rule to a real world problem is that it often
shows that *both* implementations are at fault. :-)
							don provan
							donp@novell.com

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 01:15:40 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        comp.protocols.tcp-ip
Subject:   Increasing transfer size of SOSS - Can it be done ?



Hi,
   We have successfully been using SOSS to access our MOD drive from DOS.
However write access is exceedingly slow. Due in part to the MOD itself
but I also believe in part to the 1024 packet limit that SOSS imposes. NFS
uses 8192 bytes per packet (or burst?). Is there a way of recompiling SOSS
with a bigger packet size? Or is the problem deeper than that?

I have the sources to pcip, pcipdrv and soss.

Any help appreciated.
--
Dr. Roberto Togneri                         Phone: +61-9-380-2535
Digital Signal Processing Research Group
Dept. of Electrical & Electronic Engineering
The University of Western Australia         Fax:   +61-9-380-1065
NEDLANDS WA 6009 Australia                  Email: robert@swanee.ee.uwa.oz.au

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 01:43:56 GMT
From:      dinesha@bass.bu.edu (Dinesh V.)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Looking for Network Management Standards

Hi,

	I am looking for the ISO/IEC Network Management Standards Documents.
	Our Library here doesn't have them and though I tried some other local
	facilities, I couldn't lay my hands on them. I was wondering if there
	were some anonymous ftp sites where I could get them from or whether 
	they are available in the electronic format. If not, is there some
	organisation I could write to and obtain them?


	Could you mail your responses to dinesha@bu-pub.bu.edu?
Thanks,

Dinesh.

PS:	I am particularly interested in the Configuration Management Standard.
	

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 05:58:00 GMT
From:      ACM_CSA@SWTEXAS.BITNET (ACM_CSA@SWTEXAS.BITNET)
To:        comp.protocols.tcp-ip
Subject:   HP Apollo Ethernet Revisited


       Ok guys... sorry that I have so negligent in replying, but there
    has been this little catch called school that I must attend to.  I
    have compiled as many facts about our system that I could find.

       It seems that our Apollos use a token ring network to
    communicate between each other, and the ethernet card is only
    attached to machine //plum.  It also seems that our school
    administrators have delayed (again humph!) the installation of
    TCP/IP (and thus an Internet connection) on our VAXen.  That
    changes our outlook on life so that we will just be connecting the
    Apollos to a TI UNIX machine, and to a Novell PC network.  There
    has been a small breakthrough of sorts since my last message.
    There is a command in one of the books that shows how to activate
    the ethernet card for an operation of some type.  Using a varation
    of the command, we got the card online just for sending and not
    for receiving.  We are still clueless as to how to make the thing
    work properly.  If there are any further inquires as to the
    specific setup of a machine, we can deal with it through e-mail.
    Thank you.

Brian Collins
Chairman of USERDIR for ACM/CSA

Bitnet:   ACM_CSA@SWTEXAS
THEnet:   SWT::ACM_CSA
Internet: ACM_CSA%SWTEXAS.BITNET@RICEVM1.RICE.EDU

 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

     -------            -------            -------
 --> |  1  | ---------> |  2  | ---------> |  3  | ----------
 |   -------            -------            -------          |
 |                                         | 9Tr |          |
 |                                         -------          |
 |                                                          |
 |                      -------            -------          |
 |                  --- |  5  | <--------- |  4  | <---------
 |                  |   -------            -------
 |                  |
 |                  |
 |                  |   -------            -------
 |                  --> |  6  | ---------> |  7  | ---
 |                      -------            -------   |
 |                                                   |
 |                                                   |
 |                      -------            -------   |
 ---------------------- |  9  | <--------- |  8  | <--
                        -------            -------

 Num //Node       ID    Other
 ---------------------------------------------------------------------------
  1  //Banyan   - F066  DN3000, Diskless (//Plum), 4M RAM
  2  //Fig      - F6B3  DN3000, Diskless (//Plum), 4M RAM
  3  //Redwood  - FE3A  DSP90, Diskless (//Plum), 3M RAM, 9 Track Tape Drive
  4  //Banana   - 12C99 DN4000, 140M HD, 4M RAM, SIO, 5.25" Floppy, Color
  5  //Palm     - 10450 DN4000, 320M HD, 12M RAM, 8mm Tape
  6  //Peach    - FEC3  DN3000, 320M HD, 4M RAM, 8mm Tape
  7  //Plum     - 104AA DN3000, 320M HD, 4M RAM, SIO, 5.25" Floppy,
                                                 802.3 Ethernet Card
  8  //Pear     - E925  DN3000, Diskless (//Plum), 4M RAM
  9  //Mulberry - 10033 DN3000, Diskless (//Plum), 4M RAM

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 06:36:00 GMT
From:      v130jarn@ubvmsb.cc.buffalo.edu (THE SHOTGUNNER)
To:        comp.protocols.tcp-ip
Subject:   FTP sites in the US


     I was wondering where a person could get FTP numbers for Pennsylvania or 
the surrounding area?  Does it matter what type of connection one is on,
say VAX cluster or UNIX?  I'd appreciate a list, but don't know where to get it.
Much appreciated....

                                          Alex
                                    (V130JARN@ubvmsb.cc.buffalo.edu)

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 08:53:38 GMT
From:      wetzels@amc.uva.nl
To:        comp.protocols.tcp-ip
Subject:   subscribe

please subscribe wetzels@amc.uva.nl

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 09:02:16 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Forwarding of broadcast packets

In article <1991Sep13.045717.13473@ccu1.aukuni.ac.nz>, graeme@ccu1.aukuni.ac.nz ( Graeme Moffat) writes:
> I have been using Netwatch to observe ethernet packets to learn what exactly
> is happening.
 
> (RIP update, rwho, packets to a particular IP address where host only knows
> a default net to send to...),(but *not* ARP), four other hosts repeat that
> packet, sending it to a destination of '00ffbad1dead', and also sending an
> ICMP redirect to the original source. 

That ethernet address is "Off, Bad One Dead". This is an
"ARP-Storm-killer-address", given in response to an ARP request for
what is understood to be a broadcast IP address. It serves to stop the
confused host from continuously asking for an address that it should
never get an ARP resolution for. I have forwarded more complete
details to Graeme.

========================
Tom Evans  tom@wcc.oz.au 
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179  A.C.N. 004 818 455

wcc@cup.portal.com, AppleLink: "WEBSTER.USA"
2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA
1-408-954-8054  FAX 1-408-954-1832

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 09:41:05 GMT
From:      koelman@issun3.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   IP reassembly in Comer Volume II

Hello,

I just went through the section on reassembly (7.4) in Comer's
Internetworking with TCP/IP Volume II (love it...) and noticed
that there is no mentioning whatsoever of the arrival of
duplicates and fragments of duplicates. Has anyone checked the
code to see what happens when this occurs?

I wonder whether it was a deliberate decision not to mention
duplicates... I would ask the authors directly if I had their
e-mail addresses, I missed them in the book...

Ton Koelman
koelman@issun3.stc.nl

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 11:47:05 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


 >> 1) In a modern TCP, the receiver window will never be o unless the destination
 >>    device is slower than the network link (eg terminal servers).

Or the host above the device is tied up doing something else.
We have this nice Mach machine which doesn't believe in the
ENOSPACE error code; instead it prints the message "file system
full, pausing" on the console.  Guess what happens to any 
receive windows of active TCP connections in this instance!

I'll refrain from the myriad cases a PCTCP window can go to 0..

 >> 5) In case one, the correct interval for probing the window should be
 >>    based on the time you expect the remote host to dispose of it's data.
 >>    This isn't based on the network characteristics at all, so basing the
 >>    initial probe interval on the calculated RTT is completely bogus.

Which in the case I mentioned above is non-deterministic.

 >>    (No one does this, and it isn't important.  As long as you exponentially
 >>     back off your probes, you hit a non-obnoxious interval relatively soon
 >>     anyway.  And the probes are hardly ever useful anyway.)

But in my extreme situation above (which happened to me not so long
ago) my active mail connection would back off to our maximum backoff
1,2,4...32,etc. and timeout before I had a chance to clean up the filesystem,
thus freeing space so the Mach system could drain the TCP window allowing
me to continue.

Of course the problem was exaggerated by the fact that I was coming in
over a 2400 baud line...


					Larry Backman
					backman@ftp.com

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 14:37:33 GMT
From:      sgaras@brnwil.uucp (Sam Garas)
To:        comp.protocols.tcp-ip
Subject:   Using LAN manager 1.1 tcp-ip with FTP PC/TCP

I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction
with FTP's PC/TCP.  I run into a conflict because of the two TCP 
protocols loaded at the same time.  I can not run both of them at the
same time.  I was wondering if anyone has any suggestions on how to 
run PC/TCP and LAN manager 1.1 at the same time without running into any
conflicts.  Can this be done?  

Thanks

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

######    ##    #     #     Sam Garas     R&D Software Specialist
#     #  #  #   #  #  #     Brown & Williamson Tobacco Corporation
#     #   ##    #  #  #     1600 West Hill St.
######   ###    #  #  #     Louisville, KY 40210
#     # #   # # #  #  #     (502) 568-7903
#     # #    #  #  #  #     sgaras@brnwil.uucp
######   ###  #  ## ##      coplex.com!brnwil!sgaras

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

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 15:48:21 GMT
From:      fjr@sgfb.ssd.ray.com (Fred J. Roeber)
To:        comp.protocols.tcp-ip
Subject:   LANCE chip bug

I am not sure this is the correct news group but figured I would give it
a try.  We are using certain hardware cards for our ethernet network.  These
cards use the AMD LANCE chips for packet generation.  What we are finding
is that periodically the LANCE seems to hang and stops sending and receiving
packets.  In some cases, a software chip reset clears things up but in others
only a HW reset will fix things.  I have heard from others of rumors
of similar problems.  Indeed, I have noticed in the SGI ethernet driver that
they have support for software access to the chip reset line and take a lot
of care to work around "LANCE problems".  What I am wondering is whether
there is some known LANCE bug that causes these problems.  I find it hard
to believe that this would be the case since typical workstations don't
seem to hang for this reason and I can't imagine that all the vendors drivers
have the special error recovery stuff that SGI put in.  Does anybody have
any pointers on this subject.  If people send to me I'll post a summary.
Thanks in advance.   Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 15:50:16 GMT
From:      lyman@anduril.network.com (John R. Lyman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP FIN and window


   It seems that the important thing to ask is how many times and how often
 will this out-of-window FIN be retransmitted.  We certainly don't want to
 waste bandwidth retransmitting out-of-window data.  IMHO it is better if 
 no data is sent (including the FIN) into a closed window.  Rather the 
 probe mechanism should be used to prompt the receiver to open the window.

   As for processing an out of window FIN, its probably not worth the 
 trouble unless all of the preceeding data has already been accepted.  In
 which case an execption to the spec can be made for robustness. 

					John Lyman

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 16:06:58 GMT
From:      lr@cs.brown.edu (Luigi Rizzo)
To:        comp.protocols.tcp-ip
Subject:   Where can I find CSLIP code ?

The title says almost all... I'm working on some code that transfers IP
packets on a (slow) serial line and would like to compress them before
transmission. I think I some parts of CSLIP should work, does anyone
know where can I find it ?

	Thanks
	Luigi
==================================================================
Luigi Rizzo                Brown University & Univ. di Pisa
e-mail: lr@cs.brown.edu, luigi@iet.unipi.it
==================================================================

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 16:47:38 GMT
From:      fc297303@seas.gwu.edu (jogle)
To:        comp.protocols.tcp-ip
Subject:   looking for references about the Internet


Hello...

   Can anyone point me to any references on the Internet, it's history,
it's current configuration, etc?   Is a map of the net available via
ftp anywhere?

   Any help would be greatly appreciated.  Please E-mail

                                    Thanks in advance,

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 17:09:49 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: high-level network analysis tools needed


    That is, I want to measure transactions instead of packets.
    A transaction might be several packets which establish the connection,
    transfer the data, and acknowledgement of the data.

Our LANWatch product comes with a program called TANA, which separates out
all the TCP connections it can find in a dump file, and tells you the
initial state, final state, number of packets, etc.  We also provide
source code, so you can modify it (using MSC 5.1 under DOS).

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

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 17:09:50 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Backups using rsh.


    Why don't all distributed filesystems simply use TCP/IP for data
    communication?

With any luck, we and Interstream (at least) will be demonstrating NFS over
TCP at Interop.

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

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 17:12:26 GMT
From:      anthony@IRENE.JPL.NASA.GOV (Anthony Martin)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Vax VMS

To Whom It May Concern,
      I am looking for a TCP/IP
product which will run on a 
MocroVaxII.    Due to old historical
software, we are unable to upgrade to
current version of VMS and are at 4.6.
DEC can't support us and we are looking
for some TCP/IP software elsewhere.
We have heard rumors that Carnegie-Mellon
University has TCP/IP shareware which
may work but have had no success in
getting a point of contact.    Any help
or suggestions would be greatly
appreciated.
    Anthony Martin (818)354-1580
     anthony@irene.jpl.nasa.gov

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 17:40:57 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: Dialup IP and Telebit NetBlazer

FYI there is a mailing list, netblazer-users@telebit.com, where users
of the NetBlazer discuss implementation and usage of the NetBlazer.
Telebit and/or other users answer questions.  Send mail to
netblazer-users-request@telebit.com to subscribe.

-- 
Brian Lloyd, WB6RQN                                     Lloyd and Associates
Network Architect                                       3420 Sudbury Road
brian@telebit.com                                       Cameron Park, CA 95682
voice (916) 676-1147

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 18:44:00 GMT
From:      v130jarn@ubvmsb.cc.buffalo.edu (THE SHOTGUNNER)
To:        comp.protocols.tcp-ip
Subject:   tcp locations


     Sorry to bug you all, but how do I get a comprehensive list of FTP
sites?????

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 19:19:23 GMT
From:      ragarwal@acsu.buffalo.edu (Rajesh S. Agarwalla)
To:        comp.protocols.nfs,comp.protocols.tcp
Subject:   Need information of documentation to NFS

Hi,

I need to understand NFS to the very finest level of detail. Could
anyone please give me information on good papers, books or any other
material to understand NFS?

If possible, please reply by email and I can then post a summary of
all the responses I receive.

Thank you very much.

Rajesh
-- 
Rajesh S. Agarwalla		        | (O): (716) 636-3772
Department of Computer Science          | (R): (716) 833-8009 
State University of New York at Buffalo |
Buffalo, NY 14260                       | Email: ragarwal@cs.buffalo.edu 

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 20:56:55 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: a minconfigured host

In article <9109091352.AA03752@NISC.SRI.COM> Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721) writes:
> >If a host that is not a router is forwarding packets, then it is
> >broken, but you already know that.  The misconfigured host would be
> >considered a router, and should obey all the rules of a router,
> >including decreasing the TTL of a packet.  If it is not decreasing the
> >TTL, then it is broken.
>
>I understand that the misconfigured (i.e. ip.forwarding) host *should* 
>decrease the TTL.  But my question is if it is quite so in the current 
>popular implementation, such as the IP on a UNIX system.

The definition of a router is "a host that forwards packets between
subnets", so your original question was poorly worded, since there's no
such thing "a host that is not a router that is forwarding packets."

But to answer your revised question, most IP implementations that include
forwarding capability decrement the TTL when they do so.  Presumably the
intent of including the capability is to allow the host to be a router.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 23:17:31 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: "Reverse Subnetting"

allebrandi@inland.com (Tom Allebrandi) writes:

> The NIC has assigned our company 32 Class C network numbers. The
> numbers were carefully chosen so that
 
> What we would like to do is this: Pretend to be a Class B subnetwork by
> using a netmask of 255.255.224.0

We tried this experiment here also, using a single Sun and a number of SCO
UNIX machines (SysV).  It also failed - the machines refused to accept a
netmask with fewer bits than 255.255.255.0.  Reading through the source for
different TCP/IP packages, I decided it was doomed to failure - there is
too much code that assumes that a different network can't possibly be part
of the same subnet.

Are there changes to the TCP/IP conventions in the works to make this
possible?  It'd certainly cut down on the demand for class B addresses.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 91 23:49:54 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and PPP compared


    > Basically, I don't know if PPP is more efficient than SLIP, 

    Efficient in which respect ?  effective throughput ? administration ?

One thing left out in this discussion is that many users assume that PPP
comes with "tcp header compression", and slip doesn't.

In reality, a random slip implementation and a random PPP implementation
are about equally likely to have header compression.

BillW
-------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 05:12:40 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Using Wide-Area Point-to-Point Links for Computer Networking (I)


   Date: 10 Sep 91 14:04:53 GMT
   Sender: <tcp-ip-relay@nisc.sri.com>
   From: decwrl!ucbvax.Berkeley.EDU!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!transfer!lectroid!jjmhome!crackers!cpoint!martillo  (Joachim Carlo Santos Martillo)
   Organization: Clearpoint Research Corp., Hopkinton MA
   References: <2429@crackers.clearpoint.com>, <KARL.91Sep1171232@remora.MorningStar.Com>, <14455@cpoint.clearpoint.com>

   In article <14455@cpoint.clearpoint.com> martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes:

   >1) You have to turn on UDP checksumming if you connect two ethernets
   >by a bridge rather than a router.  

   This should say:

   You don't have to turn on UDP checksumming if you connect two ethernets
   by a bridge rather than a router. 

   Joachim Carlo Santos Martillo Ajami


UDP provides an End-To-End checksum; you should *always* use it,
especially when you cross physical network boundaries via
computational devices. The UDP checksum will protect against
corruption in places that the bridge or routing device may not. A
packet in a bridge may be corrupted as it is transferred from ethernet
chip to memory, or during other bus transfers, or by software failure
after the ethernet CRC has been verified. Because the UDP checksum is
end-to-end it can guard against such problems.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 07:42:33 GMT
From:      jamin@caldera.usc.edu (Sugih Jamin)
To:        news.groups,comp.protocols.tcp-ip
Subject:   comp.protocols.research?

Hello,

Is there a comp.protocols.research that is akin to comp.os.research
but concerns itself with (inter)networking research?
-- 
sugih                                             Use e-mail, save a tree.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 13:00:23 GMT
From:      tom@rs1.tcs.tulane.edu (Tom Gerace)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IBM AADU and Clarkson packet drivers

We have an ethernet network of pc's, using a PS/2 running AIX as
a file server.  The workstations use file and print services
by running IBM's AIX Access for DOS Users product (AADU).

We also have the requirement to run TN3270 with Clarkson packet
drivers concurrently.  The problem that we've run up against is
that the AADU package uses drivers of its own (PCINIT and NTY),
and the Clarkson packet drivers cause conflicts.

I know that a Novell solution was created with the -n switch 
in the Clarkson packet drivers, allowing both the Novell drivers
and the Clarkson drivers to be in memory at once.

Has anyone out there done the same thing with AADU and tn3270
that we are doing here?  Can the two drivers use the one
ethernet board concurrently?

Thanks in advance for the help.

Tom Gerace                         tom@rs1.tcs.tulane.edu
Manager, Consultants Bureau        (504) 865-5631
Tulane Computing Services
Tulane University
New Orleans, LA  70118  USA

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 13:03:21 GMT
From:      and@kaija.spb.su (Victor A. Andreenko)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   LOCUS PC/TCP for DOS and NE1000

Hi,

We have  Locus TCP-IP package for DOS, V1.0. Unfortunately
driver for Ethernet card Novell NE1000 is absent in
this distribution.  All drivers in this package have
named _*.drv_ and they are installed from _config.sys_
at boot time.

We have some questions:
    1) what type of driver used by this package ?
       Is some description of LOCUS TCP/IP drivers type ?
    2) Can we use PDS, NDIS or other drivers NE1000 by
       some other ways ?
    3) May we get LOCUS driver for NE1000 from anywhere ?

Any information appreciable.

Please send answers not only via USENET, but direct e-mail too.
-----------------------------------------------------------------------------
Victor A. Andreenko                      e-mail internet: and@kaija.spb.su
Independent affiliate "KAIJA"              phone: office: +7 (812) 2941103
St. Petersburg (Leningrad)                                +7 (812) 2983700
Chernyshevskogo sq. 9,                              home: +7 (812) 2954347
SU-196128 , USSR

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 16:18:47 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Using Wide-Area Point-to-Point Links for Computer Networking (I)


   Date: 12 Sep 91 19:39:42 GMT
   Sender: <tcp-ip-relay@nisc.sri.com>
   From: decwrl!uunet.uu.net!zephyr.ens.tek.com!cascade.ens.tek.com!mikes  (Mike Skrydlak)

   If PPP does this, most customers will forgive it's flaws.
   And I believe they will view most criticisms at this point as 
     'Too little, too late'.  That's life.

Further: most customers care about functionality more than technical
elegance. The Internet and TCP/IP community have changed over the
years, and it's important to understand this. They are no longer just
the hard code cadre of network hackers that got the whole thing going.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 16:41:37 GMT
From:      rusek@pilot.njin.net (Robert John Rusek)
To:        comp.protocols.tcp-ip
Subject:   Novell 386 3.11 to Internet / Telnet / FTP

I have a Netware 3.11 server which I wish to connect to the internet.
I require my workstations to be able to TELNET, FTP, and Mail to the 
internet.  Does anyone know of a way to accomplish this.

Thanks

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 17:18:44 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Cc:        mjhammel@kepler.dell.com, and@kaija.spb.su
Subject:   Re: LOCUS PC/TCP for DOS and NE1000

In article <9109211303.AA25796@kaija.spb.su>, and@kaija.spb.su (Victor
A. Andreenko) writes:
> Hi,
> 
> We have  Locus TCP-IP package for DOS, V1.0. Unfortunately
> driver for Ethernet card Novell NE1000 is absent in
> this distribution.  All drivers in this package have
> named _*.drv_ and they are installed from _config.sys_
> at boot time.
> 
> We have some questions:
>     1) what type of driver used by this package ?
>        Is some description of LOCUS TCP/IP drivers type ?
>     2) Can we use PDS, NDIS or other drivers NE1000 by
>        some other ways ?
>     3) May we get LOCUS driver for NE1000 from anywhere ?
> 
> Any information appreciable.
> 
> Please send answers not only via USENET, but direct e-mail too.

I don't think the version 1.0 package contains a driver for that card. 
I have the version 2.0 package and it only supports the following cards:
3Com 3C503
3Com 3C501
3Com 3C523
MICOM NI5251
Western Digital WD8003

I know the version 2.0 and earlier packages do not support the NDIS or
PDS specs.

You might contact the following addresses to see if they can let you
know if a driver for that card exists:

support@locus.com
uunet!locus.com!support

Gee, I didn't know we could send mail to the USSR.  I guess
"Distribution: world" really means exactly that now.  :-)


Michael J. Hammel        | mjhammel@{Kepler|socrates|feynman}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet 
===Silly Saying Under Construction===

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 91 23:45:27 GMT
From:      martillo@crackers.clearpoint.com (Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

In article <=lfcl#h@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:

>Granted that PPP has some protocol overhead which some people may regard as
>random crap. The same may still be said about TCP/IP (have you ever read
>RFC 1144?).
 
>But the point is that lots of the stuff PPP does is actually necessary in a
>heterogenous environment with possibly unreliable lower-level links.

This statement is true only in the sense that some sorts of links require
extra management, but it does not mean that such management is reasonably
defined into the link level transport protocol.

>To do reliable link setup and teardown, you need something like a state
>machine, and if you don't want to impose unnecessary restrictions on what
>equipment people are going to connect to your link and how they can configure
>it, you better have option negotiation.

The option negotiation should be part of a separate protocol.

>Surprise: PPP's state machine is sufficiently general that its code
>can be shared between protocols. The option negotiation may not be perfect,
>but it works.

But it is an example of PPP's misdesign that this stuff is even
included in the main transport protocol.   The option negotiation
may actually be reasonable as long as it is properly treated
as a separate protocol whose use depends on whether it is applicable.

Option negotiation and authentication in some networks can reasonably
take place out of band.

>Plus, I still haven't found if you can do anything with Slithernet that
>would be impossible, or even prohibitively more difficult, with PPP.

1) There is good evidence to believe that PPP is going to be incompatible
   with the latest generation of serial chips which support ether modes
   and with the latest generation of ether chips which support serial modes.

2) Only  the bridging version of PPP contains sufficient information
   that sophisticated mesh topologies of serial links can be supported.
   Such mesh topologies are often desirable when seeking high reliability
   and availability in a network.

3) Unfortunately, the bridging version of PPP contains variable length
   goop in front of the MAC packet.  Many microprocessors, like the AM29k
   or IBM ROMP (used in the RT/PC) have no real capabilities for dealing
   with multiple allignments of data.  The Intel 80x86 microprocessors
   can handle multiple allignments of data, but will produce much
   lower performance when doing so.

4) PPP is rather inflexible in the following case:

              Serial P-to-P
   Router A ------------------ Router B describes the initial set up

   But it becomes desirable to replace one router with the following
   set up
      
             Serial P-to-P            Ethernetwork
   Router A ------------------ Bridge --------------- Router B1
                               |   |
                      Ether    |   |    Ethernetwork
            Router B2----------|   |------------------Router B3

   With PPP, it is necessary to reconfigure router A to generate
   PPP bridging packets or in fact get new software or a new router
   if router A does not happen to support PPP bridging formats.

   If SLITHERNET were used, no changes to router A would be necessary.

>Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\

Joachim Carlo Santos Martillo Ajami

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 00:00:01 GMT
From:      pmanglik@tanj.intel.com (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove me from this list. Thanks.

Pankaj

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 00:45:17 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   Internet Commercialization BOF scheduled for INTEROP.

Thursday 9:15-11:15PM (Oct 10)
(See INTEROP Program for location)

Internet Commercialization
Geoff Goodfellow
President
Anterior Technology/RadioMail

In the last year increasing attention has been given to the commercial IP
services market.  The purpose of this BOF is examine the emerging market of
"commercial" IP services.  Representatives from the various commercial IP
service providers will be present to answer your questions and to help 
clear the air in this emerging area.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 01:12:58 GMT
From:      sfrazier@mcinix.vlink.COM (Steven E. Frazier)
To:        comp.protocols.tcp-ip
Subject:   SLIP 9.6 Sync vs Async

Is it possible to run SLIP on Sync modems?  I have a chance to buy a couple
of 9.6 Sync modems.  I would like to run SLIP between two boxes and I was
wondering if I could use the Sync modems or not, if so, how would I handle
the connection from the Sync modem to the Async com port?

Thanks in advance.

Please email me your answers.

Steve

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 08:21:09 GMT
From:      anthony@cco.caltech.edu (Lawrence Anthony)
To:        comp.protocols.tcp-ip
Subject:   Where to obtain CMU tcpip suite?

could someone please let me know where to obtain the CMU tcpip package?
we are running a version of CMU tcpip that dates from 1988 on our
vaxstations.  if a more recent version exists, i would like to update our
machines accordingly.

please reply via e-mail unless you think this topic is of general interest.

thanks in advance.

lawrence anthony
lza@ulysses.caltech.edu

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 12:46:00 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)


    You don't have to turn on UDP checksumming if you connect two ethernets
    by a bridge rather than a router. 

Our Tech Support people have seen many cases of corrupted files due to
not using UDP checksums, even between hosts on the local Ethernet.  Packets
can get damaged on the I/O bus, or by defective Ethernet cards (or in the
bridge, if it re-calculates the CRC), not just on the cable itself.

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

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 17:45:10 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: SQL Server and TCP/IP


 >> 
 >> We would like to run our SQL Server (from Microsoft) over TCP/IP
 >> protocols. We have installed TCP/IP from FTP Software on our OS/2
 >> Server and tried to interface to the SQL Server program through
 >> NetBios. We were not able to make it work.
 >>

Exactly what problems did you have?
Did you contact us?

 >> We are told that SQL Server is using Named Pipes and will not interface
 >> to NetBios, but we can interface it directly to TCP/IP using a file
 >> called "sockets.dll".
 >>

SQL server runs on top of Named Pipes which runs on top of Netbios which
runs on top of TCP.  Sockets.DLL is the API from an application to
FTP Software's TCP protocol stack in OS/2.

To confuse things even more; SQL Server uses Name Pipes but also uses 2 or 3
LANMAN API calls to enumerate & find things.  Novell provided a Named Pipes's
& Netbios DLL so SQL server would run over the Netware OS/2 Requestor.
It did, but as I recall it was inadaquate due to inability to do resource
location without the aforementioned LanMan API's.  This could have been
corrected by NOvell since I last looked (6/90).


 >> Has anybody installed SQL Server over TCP/IP yet ? Also where can we get
 >> a copy of this file "sockets.dll" ?
 >>

Socket.dll is part of our standard PCTCP for OS/2 distribution.  If I had
to guess you are running over our 1.0 product which is almost a year out
of rev.


Here's what I suggest you do;


	* contact support@ftp.com (1-617-246-0920) with your problems
	* upgrade to our latest rev (PCTCP for OS/2 1.1PL1)
	* Get SQL Server running on either Lanman or Netware 1st.
	* Drop PCTCP for OS/2 into the equation

While we have never tested SQL Server over TCP: we have extensively tested
LANMAN over our Netbios.  In theory (ha, ha, ha) since SQL server is a Lanman
application, it should work.





					Larry Backman
					backman@ftp.com

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 20:40:11 GMT
From:      gmc@PREMISES1.QUOTRON.COM (Greg Christy)
To:        comp.protocols.tcp-ip
Subject:   NIT-based traceroute

Version 2.0 of traceroute can be found on ftp.ee.lbl.gov as
tcpdump-2.0.tar.Z.  Be sure to get and apply the patch found in
tcpdump-2.0.patch-1 as well.

Greg

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 91 21:32:37 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

> >Mr. Grandi has measured memory speed of the Vax 5830 at 16 MB/sec.  And that
> >means a maximum achievable TCP rate of less than 6 MB/sec.  That isn't fast
> >enough to justify hanging a 5830 on a gigabit network.  And that's a long way
> >from saturating an FDDI ring.
> Put 10 IBM RS6000's on a HiPPI ring and it is full with data.
> Other measurements have shown that 10 suns can fill FDDI with a transferrate
> of 6MBytes/sec each. Totalling 60Mbytes/sec!!

HiPPI is not a ring technology.  HiPPI networks are made with crossbar
switches.  You set up and tear down individual connections through the
switch.  Seperate connections do not interfere with each other.  (e.g.,
if you have a connection between machines A and B, and another connection
between machines C and D, each connection can pump data through at the full
800 mbits/sec if it is able to...)  So, a HiPPI network is not used as a
backbone in the same sense that FDDI is used as a backbone...

			-David Borman, dab@cray.com

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 01:01:30 GMT
From:      explorer@iastate.edu (Michael L Graff)
To:        comp.protocols.tcp-ip
Subject:   KA9Q PPP problems

I'm trying to connect with the campus network using a communications line which
will eat ^s and ^q.  I'd like to use KA9Q's PPP, but I'm having problems.

Rather than run ~1.5 miles every five minutes or so, I thought I'd try it on
two directly connected machines first, then modify the config files later to
protect the special characters and write the dialer scripts.

However, I've only established ONE connection in this manner.  I mean, come on,
direct connection?  Must be in the config files...

If anyone has gotten this type of thing to work, PLEASE mail me the config
files used on both ends of the connection and dial scripts if handy.

Thanks in advance,
--Michael

-- 

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 02:46:49 GMT
From:      sandeep@schutz.ee.uts.EDU.AU (Sandeep Chandra)
To:        comp.protocols.tcp-ip
Subject:   Add to Mailing List

Hi,

Will appreciate greatly if my name could be added to the
mailing- list. My email address is :

         sandeep@ee.uts.edu.au

Ta,

Sandeep Chandra, Multimedia Group, Uni of Tech, Sydney, AUS
+61 2 330 2353

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 04:05:17 GMT
From:      erik@eab.retix.com (Erik Forsberg)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

In article <12718250271.13.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>
>To get back to the original question, on high throughput for PC Unix:
>Van Jacobson has done a convincing proof that TCP can go over 6Mbit/sec.
>(He tuned the TCP on a SUN 3/60, and got repeatable TCP data transfer
>rates consistantly close to 9Mbit/sec.  A sun 3/60 is not a blazingly fast
>machine, though it does have a shared memory ethernet controller.)
>There were some interesting results:
>
>    1) checksumming does NOT matter.  The limiting factor is usually the
>	memory cycle time of the processor memory.  Given a modern CPU
>	with some form of instruction cache, the checksum can be folded
>	into a data copy at zero cost.
>
>    2) The ethernet controller CHIP DOES matter.  Going this fast means
>	that the wire will be full of data almost all of the time, and
>	collisions WILL occur between the systems sending data and the
>	ACKs the receiver has to send back.  If the chip cannot reset
>	its packet pointers and whatnot quickly in the event of a collision,
>	it won't go as fast (This was the suspected reason that Intel's
>	82586 ethernet controller had a lower peak performance than the
>	AMD Lance chip used in the 3/60).
>
>    3) The hardware matters.  The 68k in the 3/60 was idle about 30% of
>	the time in 3/60.  Why wasn't it less idle and going faster?
>	Well, because the Lance couldn't make use of the full bandwidth
>	of the memory - It takes an eternity (600 nS) to do a single
>	16 bit memory transfer, and during that time, the 68k couldn't
>	access the memory either, so it sat idle.  This goes to show that
>	a bus is only as fast at the device driving it.  So EISA bus has
>	a bandwitdh of XXX Mbyte/sec - can your I/O device, DMA controller,
>	or CPU actually deliver or eat data that fast?
>
>Can a PC do 6Mbit/sec?  I doubt it.  Pre-Jacobson TCPs tend to go about
>1Mbit/sec, and I don't think that anyone has made significant efforts to
>incorporate the new theory into PC implementation.
>

Question was, can a PC do 6 Mbit/sec ? A 25 Mhz 386 AT class machine
should be able to. A 25 Mhz Microchannel (PS2 model 80) using same software
could easily do 9 Mbit/sec. What was the software ? It was an OSI protocol stack
running OSI NETBIOS (old TOP NETBIOS) over class 4 transport, over CLNS over
LLC on Ethernet (using Western Digital 16 bit cards and their NDIS drivers).

A similar TCP/IP implementation should be able to go marginally faster
due to less complex software required. But hardware performance is far
more important.

So I think we can expect to see those numbers in the future.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 09:44:41 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   SO_KEEPALIVE

Hi Everybody,

Just a short question: When switching on SO_KEEPALIVE on a tcp socket, how
often does that connection get tested for beeing established ?


			cheers
				-Torsten
--
Torsten Beyer                      	mail	     : tb@Materna.DE
Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
     UNIX is a registered trademark of AT&T. AT&T is a modem test command

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 11:58:19 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   (none)



Please, can someone help me get off this d*mn list!!!!


      || * * * * * =========       Tom Varga
      ||  * * * *  =========       Kendall Square Research
      || * * * * * =========       617-895-9415
      || ===================       tom@ksr.com
      || ===================       uunet!ksr!tom
      || ===================       N2UA @ KA1PEP
      ||

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 13:10:30 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)


    The requirement for PPP is becoming part of the router requirements
    doc as well.  Why muddy the water with another nonstandard?

Clearpoint wants SLIDE et al. Because PPP doesn't do what bridges need;
they want MAC addresses and 802.1 spanning tree connectivity.  I don't
know if their hope that hosts will implement it will ever come true, but
the prospect of multi-vendor interoperability among half-bridges sounds
like a good idea to me.

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

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 13:54:00 GMT
From:      asnjiw01@ASNCEN.ASN.NET ("Janice Wolf")
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please remove me from the tcp-ip mailing list.

If this is not the appropriate means of getting off the list, please send
instructions to me at asnjiw01@asncen.asn.net.  Thank you.

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 14:01:20 GMT
From:      ginny@AIX.NIH.GOV (Ginny Vinton/1000000)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please unsubscribe ginny@aix.nih.gov

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 14:18:41 GMT
From:      evan@IS.RICE.EDU (Evan R. Wetstone)
To:        comp.protocols.tcp-ip
Subject:   Re: udp on Internet Connection

> 
> > Hi All
> > 
> > We are just about to get our connection to the Internet. We are planning
> > to install a router of our own (CISCO) which we will use to keep
> > unwanted traffic from our own network (and vica versa). I am wondering
> > what functions we will loose (or what problems we will cause ourselves)
> > if we prevent any UDP traffic between our local network and the
> > Internet.
> 
> You will loose domain name service.  Some routing protocols use UDP.  Just to
> name a few.  Don't filter all UDP.

Yes, *PLEASE* do not filter all UDP.  You can cause serious problems for your
regional network if you do.  We had a site that decided to filter out all 
incoming DNS requests from the outside.  Unfortunately, there were (and 
possibly still are) a lot of semi brain-damaged implementations of name 
resolvers out there.  Sun's implementation of DNS in NIS (nee YP) under 4.0
was one of them.  It could handle a hard error (i.e. Non-existent domain),
but it couldn't handle a soft error (i.e. no response at all).  Like the
Eveready rabbit, they keep going and going, trying to contact the
nameservers as fast as they can.  As time goes on, more and more hosts need
to get information about that domain.  More and more traffic flows across
the T1.  The routers start to bog down.  Eventually, one of the links fails.
The routes to that site start to flap.  More sites try to contact the
nameservers.  The network begins to melt.  It's not a pretty picture.

Moral:  If you shut off all UDP service into your net, your regional may shut
your connection down to save the rest of the network....


-- 
Evan Wetstone
Sesquinet Network Support

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 14:19:04 GMT
From:      rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius)
To:        comp.protocols.tcp-ip
Subject:   (none)

Please unsubscribe rwskubow@grand.{uwaterloo.ca, waterloo.edu} from this
mailing list.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 14:42:19 GMT
From:      mark@telesys.ncsc.navy.mil (Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  configuring ftp site

John Ackerman writes...

>	I'm trying to set up a minor ftp site and don't know what the standard
>	directory structure is that most anonymous users would expect.
>
>	Also, our implementation of ftp doesn't (at least not yet) support a
>	user name of "anonymous".  What alternative names are common for
>	anonymous ftp?
>
>	Thanks.

John, this is just an amateur's opinion, but if your TCP/IP documentation
doesn't tell you how to set up an FTP server and the package doesn't support
"normal" anonymous ftp, I think you should look at another TCP/IP.  Setting
up an FTP server is kind of risky and although my vendor's package (Sun)
suggests not enabling anonymous ftp, it supports it by establishing the kind
of restricted access space that people usually want to provide.  An
uncontrolled anonymous ftp capability allows people to read and write
nearly any file on your system; this is surely not your objective.  If you
had a package that was supported the anonymous FTP server, it should tell
you how to set it up.  I really recommend going that direction.

Anybody else got any comments?

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(904)235-5153
(mark@telesys.ncsc.navy.mil)

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 14:43:30 GMT
From:      jra@lawday.DaytonOH.NCR.COM (John R. Ackermann)
To:        comp.protocols.tcp-ip
Subject:   POP2 - POP3 interoperability?

Will the Berkely POP3 server (as modified for SysV and WIN-TCP) work
with POP2 pc clients?  In particular, with the ka9q NOS pop client?

-- 
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		      John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv      tcp/ip: ag9v@ag9v.ampr [44.70.12.34]

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 15:05:12 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: API for FTP?


    Is there an application program interface to FTP...

You don't say what operating system you're using.  We developed such an
API for DOS, and later ported it to OS/2.  IBM implies they will offer
something similar in their next release of their OS/2 product in November.
I don't know of any others.

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

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 15:05:13 GMT
From:      jbvb@ftp.com (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET & 3270 (tnv3270?) - Request For Information


    I assume that they somehow map a 3270 data stream over a Telnet data
    stream?  

Yes.  The data is in EBCDIC, with 3270 buffer orders, and the IAC EOR
sequence is used to delimit blocks.
    
    Does, say IBM, supply a 3270/Telnet server which receives this data stream
    and directs it into the normal 3270 data path?  

All the mainframe TCP/IP packages include TN3270 clients and servers.  Where
the code winds up depends on the package.  OpenConnect Systems (formerly
Mitek) also has a gateway box that takes TCP/IP on one side and maps it to
SNA on the other.  The big advantage of TN3270 is that it is block mode; the
alternative approach of converting the 3270 DS into VT100 escape sequences is
compute-intensive whereever the conversion takes place (sometimes in the
mainframe, otherwise in an outboard box), and creates much more traffic on
the net as it simulates block-mode to a remote client.

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

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 15:05:14 GMT
From:      jbvb@ftp.com (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Trouble w/ Clarkson SLIP packet driver + PC/TCP

Unless you have a 16550 serial controller chip on your 386, Windows will
make your PC drop far too many characters for decent SLIP performance.  I
don't think flow control will help.  We've had good luck with current
versions of the Clarkson SLIP8250 driver, which contains 16550 support
in addition to the basic 8250.

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

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 16:15:00 GMT
From:      OLSON@MV2.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Unscribe

Please remove me from the tcp-ip mailing list.

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 16:17:39 GMT
From:      gallager@bbn.com (Douglas Gallager)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

Marco Hyman writes:

    Stop right there!  15000 packets/second is (approx) the Ethernet
    maximum.  For those who want the math:

            Minimum frame length = 64 bits of preamble          64 bits
                                    6 octet destination address 48 bits
                                    6 octet source address              48 bits
                                    2 octet type                        16 bits
                                   46 octet data                       368 bits
                                    4 octet FCS                 32 bits
                                                            -----------------
                                                                   576 bits

    The time to transmit this frame at 10 Mbit/s is 57.6 usec.  Add to that
    the minimal interframe spacing of 9.6 usec and you can spit a frame out
    every 67.2 usec or 14880 (almost 14881) frames per second -- assuming
    one station is doing all the transmitting.


Bill Westfield writes in response:

> Exactly correct.  The theorectical max doesn't change with multiple stations,
> but you are more likely to have collisions which will interfere somewhat.
> Still, studies (Boggs @ DEC) have shown that even with 20 stations trying
> to transmit simultaneously, the usable badnwidth ofan ethernet is still
> close to 10 Mbit/s.

Certainly throughput changes when you change from 1 workstation to 2
or more workstations; with one you can't have any collisions, but with
2 or more you can. And as you say, the theoretical max doesn't change
much as the number of workstations changes.  But the maximum possible
throughput you get from an ethernet (CSMA/CD) depends on a lot of
things, including the propagation time between any two stations
divided by the time it takes for a packet to be transmitted. (Since
there are actually N*(N-1)/2 different distances between N
workstations, this is actually a little bit more complicated than
this, but you get the picture.)  In other words, if all the
workstations are connected by a very short cable, and they are sending
each other maximum size packets, the throughput will be much higher
than if they are connected by a very long cable, and they send each
other minimum size packets.

I also think you use the word "simultaneously" a little loosely.  If
all workstations are literally transmitting "simultaneously", then the
throughput will 0. You mean that all are transmitting at random times,
such that their aggregate rate is something less than 10Mbits/second.

Doug Gallager

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 16:20:36 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re:  Router security features


kronos!richb  (Rich Braun) wrote:
Is it possible to implement a port-number-based TCP/IP security filter
within a router?  (This could be configured to only allow certain types
of connects to go through, etc.

Both cisco & 3COM provide such a capability. {We have cisco's, the campus
likes IB-2000s}.  I can't comment on the performance, but the functionality
is there to do a great deal of filtering.  It is *not* a total solution,
but can contribute greatly to your 'firewall'.
Cheers,
-------------------------------------------------------------------------------
 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---

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 16:54:25 GMT
From:      hsw@COLUMBIA.SPARTA.COM (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: [alt.security] Re: "Open Systems Security" document available

I pulled over the tar file and sucessfully printed each of the document
sections on a postscript printer (NEC 960) with no trouble.  It looks like
the A4 formatting causes you to lose the line numbers which were probably
in a page header that did not get printed on 8.5x11 paper.  Otherwise,
the pages look fine.

Howard Weiss

SPARTA, Inc.
9861 Broken Land Parkway, suite 355
Columbia, MD 21046
phone: (301) 381-9400 x201
email: hsw@columbia.sparta.com

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 17:38:27 GMT
From:      billh@hpcndpc.CND.HP.COM (Bill Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Using LAN manager 1.1 tcp-ip with FTP PC/TCP

>I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction
>with FTP's PC/TCP.  I run into a conflict because of the two TCP 
>protocols loaded at the same time.  I can not run both of them at the
>same time.  I was wondering if anyone has any suggestions on how to 
>run PC/TCP and LAN manager 1.1 at the same time without running into any
>conflicts.  Can this be done?  
>
>Thanks

The two simple alternatives to solve this problem are:

(1) Run LAN Manager over the RFC NETBIOS module provided by FTP, Inc
    and don't use HP TCP/IP.

(2) Look at services that you need from PC/TCP and see if HP has a 
    way to provide this capability with HP's LAN Manager client.

Bill Hayes
HP

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 17:56:02 GMT
From:      shiao@ans.net (Dennis Shiao)
To:        comp.protocols.tcp-ip
Subject:   Introductory Material on FTP


I am looking for some pointers to introductory material on FTP
(besides the man pages on a given system). The material should 
be geared towards relatively new users on the internet, who are
not quite as aware of the many services available. Thus, the 
material would cover the basic commands of ftp, how to connect
to a host, using anonymous ftp, etc. 

I tried looking for archives of this newsgroup in the following
places,

cs.dal.ca:	    /pub/comp.archives/comp.protocols.tcp-ip
srawgw.sra.co.jp:   /.a/sranha/arch/arch/comp.archives/..
	            ..auto/comp.protocols.tcp-ip
src.doc.ic.ac.uk:   /Usenet/comp.archives/auto/comp.protocols.tcp-ip

but could not find anything subtantial. This leads to my second 
question: Is there an archive for this group ? And if so, where is
it ? I tried looking for a FAQ as well, and turned up empty.

Thanks in advance. Reply via e-mail is preferred.

-Dennis.
--
Advanced Network & Services, Inc.    E-Mail: shiao@nis.ans.net
100 Clearbrook Road                  (914) 789-5340
Elmsford, NY 10523

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 18:10:49 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

Just caught the tail end of this thread, from someone at Cisco.  I'd say
the Cisco router is by far and away the most popular (the only?) TCP/IP
router product available, given the response to my query for info on
low-cost routers.  Well over half of my responses suggested the Cisco
router, despite my request for bottom-line cost under US$5,000.

This latest thread, though, points out something that I've always felt
about Cisco:  they're a Rolls-Royce type of company, and I want a Volks-
wagen.  My desire is to go to management and say "I can get real-time,
secure access to Internet for little money", not "I can route 22 megabytes
of data per second on our corporate backbone".

Is my impression inaccurate?  Does this Acura Legend company also market
a Honda Civic?

-rich

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 18:20:24 GMT
From:      alanlb@thorcs.vt.edu (Alan L. Batongbacal)
To:        comp.protocols.tcp-ip
Subject:   Can a node pick up stuff not its own?

I am involved in building a system that (hopefully) will listen in
on arbitrary transmissions on an Ethernet.  For the sake of simplicity,
say that the machines on the network are all Unix machines running
TCP/IP.  Is there a way for a particular machine to listen in on
transmissions meant for its brethren?

-alan l. batongbacal
-alanlb@vtopus.cs.vt.edu

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 18:56:25 GMT
From:      marleyd@sumax.seattleu.edu (David Marley)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove me from this lisst

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 19:02:53 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Increasing transfer size of SOSS - Can it be done ?

robert@swanee.ee.uwa.oz.au (Roberto Togneri) writes:
>   We have successfully been using SOSS to access our MOD drive from DOS.
>However write access is exceedingly slow. Due in part to the MOD itself
>but I also believe in part to the 1024 packet limit that SOSS imposes. NFS
>uses 8192 bytes per packet (or burst?). Is there a way of recompiling SOSS
>with a bigger packet size? Or is the problem deeper than that?

If someone has a new publicly-available RPC library which can handle
multi-packet requests and which compiles under DOS, I'd be happy to
integrate it with SOSS.  Single-packet RPC is a limitation of the
existing one (it's pretty _old_).

-rich

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 19:56:29 GMT
From:      murky@hssi.dnet.hac.com (Gary A. Murakami)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Looking for Stanford ethernet filter for HP

Need source for the Stanford Ethernet Filter.  If it exists,
I would like versions compatible with HP-UX but will settle
for any version right now.  I would like to find anonymous
ftp site(s).  Thanks.

Gary A. Murakami      murky@hssi.dnet.hac.com
Hughes Training Inc.  West Covina, CA
"In life the only constant is change."

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 20:03:23 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted:PD IBM PC Telnet/Ethernet terminal server s/w.


    I have a friend who is interested in PD software to turn a IBM PC into a
    Telnet/Ethernet terminal server for (say) 20 terminals. Whats out there?.

Do you have the hardware needed to connect 20 terminals to a PC?

My guess is that in order to do that, you step well outside of the "mass
produced" PC peripherals, lose the cost advantages of the PC platform, and
would be just as well off buying a commercial terminal server from one of
the many vendors that provide them.

That said, you would probably want to start with the PD version of NCSA
telnet for the IBMPC...

BillW
-------

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 21:00:17 GMT
From:      debbie@pooh.sdd.trw.com (Debbie Salierno)
To:        comp.protocols.tcp-ip
Subject:   Help wanted on IP Datagram Reassembly

To whomever can help,
	I've been hunting around for an algorithm to handle IP datagram
reassembly.  Since I'm new to the TCP/IP world, I'm not sure how to 
handle the reassembly. I have been reading the Comer text books on how
to handle fragmentation and they have been helpful but I need the source
code or psuedo code so I can implement it on my machine. 
	I have RFC 815 on "IP Datagram Reassembly Algorithm" but there is no
pseudo code or enought detail for me to implement it with some confidence
that it will work.  What I'm looking for is a detailed algorithm for
reassembly or the source code itself.  If anyone can help, I would really
appreciate a response.

				Thanks

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 21:03:20 GMT
From:      jhc@iris.uucp (James H. Coombs)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_KEEPALIVE

In article <tb.685619081@elwood> tb@Materna.DE (Torsten Beyer) writes:

>Just a short question: When switching on SO_KEEPALIVE on a tcp socket, how
>often does that connection get tested for beeing established ?

The timing is implementation dependent.  I had to patch the kernel in
Apple's A/UX 1.1.1 to get the timings that I had when I started using
keepalives with 1.1.  I STRONGLY recommend that you implement your own
connection testing.  I have done so since, and the implementation is
trivial.

FYI.  The original timings were something like 1 test a minute, with a
timeout after 10 minutes of no response.  I don't remember exactly what
A/UX 1.1.1 gave me, but it was something like 2 days.

--Jim

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 21:20:22 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   (none)


since the majority net users do not have control over the mailing lists--
to those who like to unsubscribe, the only thing I can do is to say "bye-bye";
to those who like to subscribe, the only thing I can do is to say "welcome".

So, it is not absolutely important to copy the subscription/unsubscription
requests to everyone.  

shannon
-------
------- Forwarded Message

Return-Path: owner-ietf-smtp@dimacs.rutgers.edu
Return-Path: <owner-ietf-smtp@dimacs.rutgers.edu>
Received: from dimacs.rutgers.edu by netix.com (4.1/LLNL-1.18)
	id AA03207; Fri, 6 Sep 91 16:18:06 PDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA11326; Fri, 6 Sep 91 18:49:40 EDT
Received: from NETIX.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA11314; Fri, 6 Sep 91 18:49:30 EDT
Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18)
	id AA03102; Fri, 6 Sep 91 15:47:56 PDT
Message-Id: <9109062247.AA03102@netix.com>
To: ietf-smtp@dimacs.rutgers.edu, ietf-tcp@nisc.sri.com
In-Reply-To: Your message of "Fri, 06 Sep 91 17:13:31 EDT."
             <9109062113.AA05742@batman.sbi.com> 
Date: Fri, 06 Sep 91 15:47:50 PDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: Shannon Yeh <yeh@netix.com>


 >    Please unsuscribe me from the SMTP list group.

  If people like to subscribe or unsubscribe to/from a mailing list, I
  guess they could always tell mailing_list_name-request@domainname; if this
  doesn't work, I would recommend them to send a msg to the postmaster
  of the distribution host.  Just a piece of suggestion.

  shannon
  -------

------- End of Forwarded Message

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 21:47:47 GMT
From:      debbie@pooh.sdd.trw.com (Debbie Salierno)
To:        comp.protocols.tcp-ip
Subject:   Need Help on IP header

To whomever can help,

	I've been trying to fiqure out whether IBM's AIX implementation of IP
is wrong or me not understanding how it should work.  Hopefully someone can
enlighten me.  

	The scenario is as follows:

I'm sending a 2k buffer from one host to multiple host hooked up to an NSC 
intelligent bridge router.  The router has a copy_to function which allows
copies of the datagram to be made and sent out to certain hosts.  Since I
sent a 2k buffer, I assumed that IBM's implementation of IP would fragment
the buffer so it would fit on a network frame.  Since I'm sending thru
ethernet the MTU is 1.5k therefore AIX would have to break up the buffer
before sending it out to the destination host (correct I hope). Once the
NSC router receives this datagram it envelopes it with a copy_to header
and an IP header so it can be routed to the hosts which need this datagram.
Since the router is routing thru ethernet, it doesn't need to break the
datagram down any further.  The application receiving this datagram receives
the copy_to header, original IP header and the data in its buffer.  The
IP header above the copy_to header has been strip off by the IP protocol.  
Since the original IP header was modified due to the copy_to, IP won't handle
the reassembly.  My problem is with the data in the IP header possibly being
incorrect.  I received two datagrams with the following headers:

datagram 1. 45 00 05 dc 3d 40 20 00 1c 11 00 00 64 9c 08 05 64 9d 08 04
	    04 0b 04 c4 07 d8 84 91   <    data    >

datagram 2. 45 00 02 24 3d 40 00 b9 1c 11 00 00 64 9c 08 05 64 9d 08 04
	    <    data   >

datagram 1. has a header length of HLEN=5 but it has 2 words worth of options
	    should it be HLEN=7 and not HLEN=5?  And if the header length
	    should be 7 words is IBM implemenation of IP incorrect?  According
	    to what I have read, Header length has to be a minimum of 5 but
	    can be larger depending on the option fields used.  Is this 
	    correct?  If the header length is correct, how can one tell where
	    the data should start?

datagram 2. has the correct header length of 5 and the data follows after
	    the fifth word of header.


If someone can help explain this problem, I greatly appreciate the help.

					Thanks

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 21:51:07 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)


    The argument put forth by my colleague is that memory speed on
    most computers is so slow that, when using a protocol like TCP
    which typically (most common implementations) touches memory at
    least three times (DMA into memory and copy from kernel to user
    space - I didn't count the checksum), high data rates to the
    application just aren't possible.

This assumes that the DMA into memory and the kernel to user copy
take their bytes from the same chunk of memory bandwidth.  One would
hope that any architecture designed for high I/O bandwidth would be
able to do a lot of I/O into memory without having any effect on the
processor's access to memory.

    For example, we measured the memory speed of a Vax 6310 at
    around 8 MBytes/sec.  If memory is touched three times for a
    TCP connection, that means a maximum possible data rate of less
    than 3 MBytes/sec.  So even if we have a HiPPI connection on
    this machine, we aren't going to do any better than 3 MB/sec.

The number is suspicious (it works out to 1 (32 bit) memory transfer
every 500 nS.  While this might be typical for transfering data over a
bus (an old bus, anyway), but sounds way wrong for "integrated" memory.
Maybe the bcopy that you are using needs improving...

I would also claim that if the bandwidth one gets from their network is
the same as the bandwidth that one gets from their memory, then this IS
a "high data rate to the application").  One might as well claim that
gigabit networks are useless because they are faster than any existing
disk drives, so what would be the point during FTPs.

In fact, I'd go so far as to say that the entire point of very high speed
networking is to remove the distintion between remote and local data.


    That isn't fast enough to justify hanging a 5830 on a gigabit network.

Supporting a single 1G data stream is only one excuse for having a 1G
network.  Also inherent in such a network is the concept of multiplexing
multiple streams.  And there will always be computers too slow to take
advantage of the full bandwidth of the network (or generic I/O devic
they are connected to.  That doesn't make that computer useless, nor
does it mean that it should not be connected.  I doubt whether anyone
expected single hosts to use the full bandwidth of an ethernet during
that development effort, and there are certainly hardware controllers
that still do not permit this.  So what?

A good design for a network permits hosts to access them to the limit of
their own abilities, perhaps based on other design criteria (There have
certainly been more ethernet interfaces sold that will never do anywhere
close to 10 Mbit/sec.  At <$300 each, this is not a problem...)

BillW
-------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 22:18:21 GMT
From:      lms@SSDS.SSDS.COM (L. Michael Sabo)
To:        comp.protocols.tcp-ip
Subject:   Re: Cabletron Support

Not to get a long chain going regarding whose customer support is good and 
whose is not - but I feel I must respond to the posting regarding Cabletron.  
We have had *excellent* support from Cabletron over the years.  Their technical 
support has been both prompt and accurate.  Also they listened to our needs for 
network management, for example,  and we saw our requirements fulfilled in 
their SPECTRUM product.  That's my two cents.

P.S.  BIG-LAN is a more appropriate forum for LAN "talk" and customer support 
issues are better left between customers and vendors.

L. Michael Sabo
SSDS, Inc 

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 91 23:27:09 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
To:        comp.protocols.tcp-ip
Subject:   Re: Sendmail

bmiller@CABELL.VCU.EDU (Bryan E. Miller) writes:

>I have a question concerning "Apparently-to".  When exactly should you
>see this line in a mail header, as opposed to the normal "To:"???

If the message header block is missing the To: line, sendmail will add
the Apparently-to: header.

/pbp
--
Paul Pomes, Computing Services Office  |  Good gun control is a two-handed
University of Illinois - Urbana        |  grip, trigger control, and sight
Email to Paul-Pomes@uiuc.edu           |  management.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 00:16:32 GMT
From:      jude@discovery.nas.nasa.gov (Jude A. George)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   table of Internet site locations?


Is there available a table of Internet networks and their respective locations
(latitude & longitude, or city name, or zip code, or whatever)?  I know that
such location information is available for UUCP sites, since each UUCP site
must have a phone number.

For wide area networks, (e.g. 35.0.0.0), a location for each router would
be needed.

This information will be used by a network management system we are developing
in-house.

Jude George
Computer Sciences Corporation
NASA Ames Research Center

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 00:38:31 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate/old mailings

In article <9109191855.AA02165@NISC.SRI.COM>, 08071TCP@MSU.EDU (Doug Nelson) writes:
> Is NISC.SRI.COM having trouble getting mail out to the TCPIP list?  I am
> receiving frequent multiple copies of letters, and letters that are up
> to two weeks old.
> 

I seem to be getting lots of duplicate messages, in many newsgroups, not
just comp.protocols.tcp-ip, and through Internet News, not the
mailing lists. I thought maybe our newsreaders were broken after a
recent OS upgrade! - anybody know where they are coming from?


Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 01:21:25 GMT
From:      jra@lawday.DaytonOH.NCR.COM (John R. Ackermann)
To:        comp.protocols.tcp-ip
Subject:   POP2 Server for SVR3/WIN-TCP needed

Well, I've found out that POP3 <isn't> a superset of POP2, and the nice
POP3 server I just got running isn't going to do me any good.

Can someone point me to a POP2 server that'll work on SVR3 with WIN-TCP,
or can reasonably be made to do so...

Thanks,

John
-- 
John R. Ackermann, Jr.        Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		      John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv      tcp/ip: ag9v@ag9v.ampr [44.70.12.34]

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 01:24:35 GMT
From:      Christopher-Vance@adfa.oz.au (Christopher JS Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problem from hell

| >>The root of the problem is that my router sits on subnet 78 and the router
| >>to the AAA.BBB.CCC.0 network sits on subnet 10.  When I try to add a route
| >>sun-router>> route add net AAA.BBB.CCC.0 XXX.YYY.10.1 1 add net
| >>AAA.BBB.CCC.0: gateway XXX.YYY.10.1: Network is unreachable
| >
| >This is correct. XXX.YYY.10 is not in your subnet.

I don't seem to have the original article, to follow it up directly,
so I'm trusting somebody else's quote.  But I think we have a solution
to a related problem:

What we have is a campus-wide class B network with a number of bridges
to make things look unified without subnets.  But we also have a
couple of real class C size subnets.


outside world -- router ------------\
			D.E.1.16    |
				    |
				    |--------- apollo ---- ring D.E.51.0
				    | D.E.1.12	      D.E.51.3
				    |
				    |
				    |
				    |---------- sun ---- ethernet D.E.31.0
				    | D.E.30.20	    D.E.31.1
				    |
				    |
	    other hosts ------------/
			D.E.F.G (F != 31, F != 51)


Most hosts on campus are totally unaware of the use of subnets. All
hosts on the two subnets use a network mask of 255.255.255.0 on both
sides of their gateways.  All hosts use static routing, mostly:

	localhost	localhost
	D.E		my ethernet address
	default 	D.E.1.16

The non-gateway hosts on the two subnets use

	localhost	localhost
	D.E.F		my external address
	default		my D.E.F gateway

The point now, is that the two gateways are different, the apollo uses:

	localhost	localhost
	D.E.51		D.E.51.3	ring
	D.E.1		D.E.1.12	backbone ethernet
	default		D.E.1.16

	which works, because the campus router is on the same [sub]net
	as the ethernet interface of the host.

The other sun gateway must use

	localhost	localhost
	D.E.31		D.E.31.1	ether subnet
	D.E.30		D.E.30.20	backbone ethernet
	default		D.E.30.21

But there is no host D.E.30.21.  This works because we have a friendly
host export an ARP entry for this IP address which has the ethernet
address for the router D.E.1.16.  Perhaps we could tell the router to
recognise this as an alternative IP address for itself on the save
interface as D.E.1.16, but I don't drive that machine, so I can't tell
you.

Why this kludge?  There are multiple hosts on D.E.30.* which all think
the campus has no subnets.  Why is the other network different?  They
have no hosts except those on their subnet.

The other part of the solution is a proxy ARP server which ensures
that requests from non-subnetted hosts for ethernet addresses of hosts
on D.E.31 and D.E.51 get given the ethernet addresses of their
respective gateways instead.

-- Christopher

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 03:23:41 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: POP2 - POP3 interoperability?

In article <1991Sep23.144330.25972@lawday.DaytonOH.NCR.COM> jra@lawday.DaytonOH.NCR.COM (John R. Ackermann) writes:
>Will the Berkely POP3 server (as modified for SysV and WIN-TCP) work
>with POP2 pc clients?  In particular, with the ka9q NOS pop client?

POP2 and POP3 are quite different protocols.  In particular, POP3 is
*not* an extended version of POP2.

The IMAP2 distribution (FTPHOST.CAC.WASHINGTON.EDU, imap/imap.tar.Z or
imap/new-imap.tar.Z for the latest) includes both a POP2 and a POP3
server.  The code is for BSD, but it shouldn't be too hard to port to
SysV as long as you have inetd.

 -+-+-   | -++-  --|--    /__ Mark ("Gaijin") Crispin "Gaijin!  Gaijin!"
+-|-|-+ -+-++++  +-|-+   /  / R90/6 pilot; DoD #0105  "Chigau. Omae ha gaijin."
+-+-+-+  |\||||  |===|  /  /  Atheist & Proud         "Iie, boku ha nihonjin."
 --|--  /| |/\| -+===+-   /\  (206) 842-2385/543-5762 "Souka. Yappari gaijin!"
  /|\    | |__|  /   \   /  \ FAX: (206) 543-3909
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanakute mo shiranai yo.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 05:16:00 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   re: API for FTP?

There exists no general API for the FTP protocol. While I was at FTP
Software, I created one for an FTP library that's a part of PC/TCP.
It's documented in their Dev Kit, for which I believe you can even buy
the documentation separately (but which is not available online). Of
course, the only FTP implementation I know of that conforms to it is
the one in the devkit, as well, so that's probably not very helpful to
you.

You can probably figure out ways to drive most UNIX and some DOS FTP's
from scripts, if you need to, or (under UNIX) fork an FTP client and
set up pipes for its stdin and stdout and read and write commands and
responses to it.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice: 617 942-0915

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 09:25:19 GMT
From:      martillo@AZEA.CLEARPOINT.COM (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

>    From: martillo@azea.clearpoint.com (Joachim Carlo Santos Martillo)
>    Date: Sun, 22 Sep 91 11:26:07 EDT
>    X-Mailer: ELM [version 2.2 PL14]
 
>    >    4) PPP is rather inflexible in the following case:
 
>    > 		 Serial P-to-P
>    >       Router A ------------------ Router B describes the initial set up
 
>    >       But it becomes desirable to replace one router with the following
>    >       set up
 
>    > 		Serial P-to-P            Ethernetwork
>    >       Router A ------------------ Bridge --------------- Router B1
>    > 				  |   |
>    > 			 Ether    |   |    Ethernetwork
>    > 	       Router B2----------|   |------------------Router B3
 
>    >       With PPP, it is necessary to reconfigure router A to generate
>    >       PPP bridging packets or in fact get new software or a new router
>    >       if router A does not happen to support PPP bridging formats.
 
>    >       If SLITHERNET were used, no changes to router A would be necessary.
 
>    >    >Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
 
>    >    Joachim Carlo Santos Martillo Ajami
 
>    > You seem bent on sticking bridges in the middle of things.  Sobeit.
>    > That is not how I build networks but I tend to have a rather narrow
>    > view of things :-).
 
>    Often there is no choice, our building is wired for for TWIP and
>    thin-wire ethernet with cables beginning in the telecommunications
>    closet and terminating in offices.  This arrangement is quite common
>    in large corporate networks.
 
> How does this preclude the use of routers?

Because cabling and the wiring closet might be the responsibility of
Telecommunications, and they might not want Engineering or R&D
equipment in areas which they control.

And their position is not unreasonable.  Suppose MIS does not run IP
based software.  Therefore, their offices must be connected by bridges
or repeaters in the wiring closet.  If Engineering and R&D offices are
connected by IP routers, when offices are changed, there is a rewiring
nightmare.

But suppose everyone used IP based software.  Suppose Engineering and
R&D had about 120 machines on three subnetworks with about 40 machines
on a given subnetwork which corresponded to a single thinwire coax
cable.  Now rather than being connected to a single coax cable, each
of these machine is connected to a wire which terminates in the wiring
closet.  Now I suppose, you could use several IP routers to route
among 40 networks, but having a single machine per network is fairly
silly (and low performance given that IP is actually designed to be
efficient when a relatively large number of machines are connected to
a relatively smaller number of machines).  You could use a several
multiport repeater to connect 40 ethernets, but there is no real
growth possibilities here because repeaters quickly increase the
effective length of an ethernet to the maximum.

You could even use a combination of multiport repeaters and IP
routers, But that would mean subdividing our subnetworks into smaller
subnetworks and they might work well right now.  Also the larger the
number of subnetworks the more work routers have to do, and
performance will go down.

There really is a use for bridges in such environments as described
which are quite common in large corporate networks.

And anyway this claim "I don't build networks with bridges" is simply
prejudice.  IP routers do one thing very well.  They route between IP
subnetworks very well.  They do not route frames very well within an
IP subnetwork (and in fact can't).  Now the issue of routing within an
IP subnetwork is not important with LANs because LANs have very simple
broadcast communications subnets and use packet filtering at the
individual hosts which receive all packets.  However, such
communications subnets are inherently low performance because
communication between one pair of hosts preclude communications
between any other pair of hosts (not precisely true on some ring
networks where communication between just a subset of the ring hosts
would be precluded).  Such communications subnets are also security
nightmares because all hosts hear all packets. High performance and
secure communications subnets use meshes of packet switches.  It
happens that we call these packet switches MAC bridges when the
interconnection technology is ethernet but the terminology does not
change the function which is being performed.

>    Muliport Bridges are used as hups to create single logical ethernets
>    from multiple separate physical ethernets.  This set up is
>    topologically convenient, and eases management and increases
>    availability (if someone kicks or unterminates his connection, only
>    his segment becomes unusable).
 
> A router will do the same thing.

No this is incorrect, an IP router is very good at routing traffic
among IP subnetworks.  A properly designed PSN (Packet Switch Node)
(aka MAC bridge) can give high performance frame routing between end
hosts with added security as a bonus.

>    Repeaters could have been used but our traffic load is simply too high
>    for repeaters to be a reasonable way of achieving connectivity.
>    Routers are not really a reasonable solution unless each office
>    ethernet is to be a separate subnetwork.
 
> I agree but you can still use a router.

Only for a few special case architectures.

>    Joachim Carlo Santos Martillo Ajami

Joachim Carlo Santos Martillo Ajami

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 09:46:57 GMT
From:      jcross@ec.uwa.oz.au (Jennifer Cross - pgmr)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>I guess what I'd like to know and hear comments on is whether there are any
>architectures out there (other than Cray/Fujitsu/NEC) that can actually take
>advantage of high-speed networks (FDDI and up)?
>Mark Boolootian		booloo@lll-crg.llnl.gov		+1 415-423-1948

  Just a thought...
  Many of the specialised (read non unix) systems out-there use more direct
  memory systems.  For a (possibly trivial) example the Amiga OS uses
  systems messaging by passing pointers to memory (inherently dangerous I
  admit, but Very fast).  The current (latest) Amigas are running a 68040
  with 0-16Mb Static ram and 8-64Mb dram (direct to processor - not on
  an external bus).  The memory speeds on these systems are very
  impressive - not that you could _effectivly_ use
  this type of bandwidth out to a "normal" amiga i/o device but ideal for
  memory mapped (anywhere in any process's address space) i/o.
  when required, the OS simply passes pointers to memory structures between
  processes (no copying - ever).  On the amiga this only work because their
  is NO address space protection.  I think protected memory which allows
  this type of multiple allowed readers/writers are being implimented for
  the new(er) distributed data boxes - where all storage appears as memory
  (100% virtual).
I own an Amiga for fun, use SUN, SGI, PC, MAC for work.
--        ___
	 (   >                  /)                        (voice) +61 9 362 6680
          __/_/> ____  ____  o //  _  __            (home)  cjcross@DIALix.oz.au
	 / / (__/ / <_/ / <_<_//__</_/ (_ @ Beautiful Perth, Western Australia
	<_/                  />                     (work) jcross@ecel.uwa.oz.au
			    </                            (voice) +61 9 380 3879

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 09:47:55 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   Duplicate/old mailings

Hi Doug. I haven't removed the direct address to you so you should get
this addressed to yourself and again as a member of the list. I assume
you will therefore recieve 3 mailings of this.
I'm getting duplicate mailings. Somebody emailed yesterday saying the
same thing was happening to them. One of the dupolicate examples
always has Sender:tcp-ip-request@uk.ac.nsfnet-relay...I suspect the
problem may be there. The first of the two mailings always had, as one
would expect, Sender: tcp-ip-relay@com.sri.nisc. I mentioned this via
email to somebody(sorry, forgot name) concerned with administering the
list. I believe it may take some days to rectify.
_______________________________________________________________________________
Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786  67266  Fax: +78651335
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 11:27:56 GMT
From:      koelman@issun3.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Re: Help wanted on IP Datagram Reassembly

In <28DE55E1.1457@deneva.sdd.trw.com> debbie@pooh.sdd.trw.com (Debbie Salierno) writes:


>	I've been hunting around for an algorithm to handle IP datagram
>reassembly.  Since I'm new to the TCP/IP world, I'm not sure how to 
>handle the reassembly. I have been reading the Comer text books on how
>to handle fragmentation and they have been helpful but I need the source
>code or psuedo code so I can implement it on my machine. 
>	I have RFC 815 on "IP Datagram Reassembly Algorithm" but there is no
>pseudo code or enought detail for me to implement it with some confidence
>that it will work.  What I'm looking for is a detailed algorithm for
>reassembly or the source code itself.  If anyone can help, I would really
>appreciate a response.


Comer Volume 2 contains enough detail, I would think. Phil Karn's
ka9q also has the reassembly code. You can also look at the BSD
code (on uunet.uu.net)

Ton K.
koelman@stc.nl

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 12:34:07 GMT
From:      marikar@digrev.UUCP (Mo)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please take me off them mailing list.
Mo Marikar
Digital Review

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 13:02:23 GMT
From:      bersee@nikhef.nl (Josefien Bersee)
To:        comp.protocols.tcp-ip
Subject:   rectification dates 3rd JENC


                         *************
                         RECTIFICATION
                         *************


We regret that a mistake has crept into the announcement of the

"Third RARE Joint European Networking Conference"

Please note that it will be held from Monday 11 - Thursday 14 May 1992
in Innsbruck, Austria (instead of 12-15).

Please accept our apologies for any inconvenience this may have caused.


Josefien Bersee
RARE Secretariat
 

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 15:13:53 GMT
From:      dxe@cassidy (Dan Ellsweig - Network planning)
To:        comp.protocols.tcp-ip
Subject:   MVS-TCP/IP


Greetings fellow netters.....


We here at Salomon Brothers have begun to investigate the offerings
by IBM which place IBM at the fringe of the distributed processing 
environment as we know it. Specifically, the offering which opens
the entire IBM product line by allowing TCP/IP interconnect.

I am wondering if there are network users out there who may have
specific experience ( good and bad ) in using the IBM TCP/IP
products - MVS-TCP/IP in particular. 

We are interested in using the FTP, NFS, SNMP, Mail and MVS socket
libraries. All input is welcome!!!!!!

In addition, any information regarding future products such as 
the CICS-TCP/IP interface or information on IMS access via TCP/IP
would be welcome.


Thanks



-- 
*****************************************************************************
Dan Ellsweig    **   Salomon Technology Services      **  dxe@cassidy.sbi.com
                **   Route 3   East Rutherford, N.J.  **
*****************************************************************************

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 15:46:56 GMT
From:      rpcfod@nimbus@UUNET.UU.NET (Robert Patt-Corner)
To:        comp.protocols.tcp-ip
Subject:   SLIP Addressing Issues

I'd like to check an assumption out ...

We're trying to set up SLIP access to a mostly ethernet network.

I'm under the impression that IP addresses belong to interfaces,
not to hosts.  Thus to set up the addresses we'd use, for instance our
class B address for the ether:

138,219.x.x

And perhaps a class C for the SLIP.  To do the routing we'd need
to find an IP implementation that permits assigning (on a single host)
an address from the ether netrange to the ethernet card and from the
SLIP range to the async port.

Is this correct?

If so, then does this rule out (for the router) 
packages like KA9Q and its derivatives,
which firmly believe in one host, one address?  Anybody do it with WIN/TCP
for VMS?

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 16:12:20 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Need Help on IP header

In article <28DE6104.15DD@deneva.sdd.trw.com> debbie@pooh.sdd.trw.com (Debbie Salierno) writes:
>
>	I've been trying to fiqure out whether IBM's AIX implementation of IP
>is wrong or me not understanding how it should work.  Hopefully someone can
>enlighten me.  
>
>	The scenario is as follows:
>
>I'm sending a 2k buffer from one host to multiple host hooked up to an NSC 
>intelligent bridge router.  The router has a copy_to function which allows
>copies of the datagram to be made and sent out to certain hosts.  Since I
>sent a 2k buffer, I assumed that IBM's implementation of IP would fragment
>the buffer so it would fit on a network frame.  Since I'm sending thru
>ethernet the MTU is 1.5k therefore AIX would have to break up the buffer
>before sending it out to the destination host (correct I hope). Once the
>NSC router receives this datagram it envelopes it with a copy_to header
>and an IP header so it can be routed to the hosts which need this datagram.
>Since the router is routing thru ethernet, it doesn't need to break the
>datagram down any further.

Actually, it might have to since it may be adding extra headers to an
already maximally-sized Ethernet packet.  However, this second-level
fragmenting should be invisible to you, because it will be occuring
in the router-to-destination datagram, not in the envelopped datagram.

>The application receiving this datagram receives
>the copy_to header, original IP header and the data in its buffer.  The
>IP header above the copy_to header has been strip off by the IP protocol.  
>Since the original IP header was modified due to the copy_to, IP won't handle
>the reassembly.  My problem is with the data in the IP header possibly being
>incorrect.  I received two datagrams with the following headers:
>
>datagram 1. 45 00 05 dc 3d 40 20 00 1c 11 00 00 64 9c 08 05 64 9d 08 04
>	    04 0b 04 c4 07 d8 84 91   <    data    >
>
>datagram 2. 45 00 02 24 3d 40 00 b9 1c 11 00 00 64 9c 08 05 64 9d 08 04
>	    <    data   >
>
>datagram 1. has a header length of HLEN=5 but it has 2 words worth of options
>	    should it be HLEN=7 and not HLEN=5?  And if the header length
>	    should be 7 words is IBM implemenation of IP incorrect?  According
>	    to what I have read, Header length has to be a minimum of 5 but
>	    can be larger depending on the option fields used.  Is this 
>	    correct?  If the header length is correct, how can one tell where
>	    the data should start?
>
>datagram 2. has the correct header length of 5 and the data follows after
>	    the fifth word of header.
>

I don't understand why you believe those 8 octets are options.  They
don't look like any kind of IP options I am familiar with.  On top of this,
the IP offset and length numbers make sense only if they are data rather than
options.  Eg.,

fragment 1:   offset 0  more fragments  length 5DC = 1500 decimal
fragment 2:   offset B9 = 185 chunks    length 224 = 548 decimal

Now if frag 1 really has a 5 word header, its data length is 1480 octets.
Meanwhile, frag 2's offset is 185 * 8 = 1480 octets.  It adds up.

There is something funny about the total data length, though, if you
really are sending 2K = 2048 octets of data in the datagram, because the way
it looks now total data length is 1500-20 + 548-20 = 2008.
It would be useful to know which 40 are missing.

If something is being trashed here, it isn't clear whether it is AIX or the
router that is at fault.  The router does seem to be zeroing the IP
checksum (which is not good!) of the copied fragments, so it might
be messing around with other things too.
You should try to eliminate one possible source of errors, by checking
what the fragments look like before the router munges them.
A lan analyser is the best tool for this.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 17:02:45 GMT
From:      lms@SSDS.COM (Michael Sabo, Denver)
To:        comp.protocols.tcp-ip
Subject:   Cabletron Customer Support

> Does anyone else have comments about Cabletron's product support.

Not to start a long chain regarding whose customer support is good and
whose isn't - yet I feel I must respond regarding customer support I have
received from Cabletron over the years.  Simply put I have received
superior service.  Their responses to my questions have been immediate
and accurate.  Cabletron has been one of the few companies who listened
to our needs and incorporated these into subsequent product offerings.
This was especially true during the development of their network management
platform SPECTRUM.

L. Michael Sabo
SSDS, Inc.

P.S.  Perhaps the BIG-LAN news group would have been a more appropriate
forum regarding LAN questions.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 17:53:26 GMT
From:      fxs@stowe.UUCP (Fran Sullivan)
To:        comp.protocols.tcp-ip
Subject:   Please change distribution.


Could you change my distribution address from 

fmrco!fxs@uunet.uu.net

to

fmrco!stowe!tcpip@uunet.uu.net


I would like to distribute this to a
larger following within my company.



Thanks,

                                               |\/\/\/|
* Fran Sullivan                                |      |
* fmrco!fxs@uunet.uu.net                       |      |
* Sun Tech Support                             | (o) (o)
* Fidelity Information Systems                 C      _)   ...Hey Dude!
* Boston, MA    02109                           |  `__|     
* ( 617 ) 570-2762                              |   /   
                                               /    \
                                              / ---- \ 

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 18:10:48 GMT
From:      markb@giga.slc.unisys.com (Mark Baranowski)
To:        comp.protocols.tcp-ip
Subject:   Is MX-ing the domain-name legal?


Hello;

Suppose I have a domain named:        sub.domain.edu

And suppose I have the following   
hosts inside of this domain:          host1.sub.domain.edu
                                      host2.sub.domain.edu
                                      host3.sub.domain.edu

Is it legal to have an MX record so that mail can be sent to the
domain name rather than to a specific host?  For example:

    sub.domain.edu.     IN      MX     20   host2.sub.domain.edu.

The intent here would be for host2 to act as the domain's mailhost
and for the from-line on outgoing mail to read "user@sub.domain.edu"
so that the outside world would not be aware of hosts 1, 2, or 3.

The reason for my question is that I have been told that the above
configuration violates the RFC for DNS.  Yet I have seen many domains
on the Internet configured in a similar manner!


Thanks.

-- 
markb@slc.unisys.com,  markb@signus.elen.utah.edu,  ...!giga!markb

	"WERE THERE ALIENS ON THE MOON WHEN THE ASTRONAUTS LANDED?"
						-- National Enquirer headline

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 19:39:11 GMT
From:      krishna@cs.albany.edu (Krishnakumar K.)
To:        comp.protocols.tcp-ip
Subject:   Distributed file systems and TCP

In article <9109201709.AA24932@ftp.com> jbvb@ftp.com writes:
>
>    Why don't all distributed filesystems simply use TCP/IP for data
>    communication?
>

Overhead!!
It is quite clear that distributed file systems can live very well
without TCP. In most cases (if not all) the reply to the file system
call acts as the acknowledgement also and this renders the specific ack
to the call as required by TCP unnecessary. In most distributed file 
systems completion of the call is the responsibility of the client and
so the client can always make an extra call in case of a lost reply.
Things being so, I feel that distributed systems are well off without TCP
and the extra traffic.

>With any luck, we and Interstream (at least) will be demonstrating NFS over
>TCP at Interop.
>
Isn't NFS good enough with just UDP?

Krishnakumar K.	
dept. of CS
SUNY Albany

email: krishna@cs.albany.edu

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 20:17:24 GMT
From:      jca@crash.cts.com (John C. Archambeau)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.ibm.pc.hardware
Subject:   3-Com boards

I have access to a pair of 3-Com boards that I plan on using.  Problem
is that I have no documentation on the boards for jumper setting the
port address and memory address of the board.  Nor do I have a disk with
MS-DOS drivers.  The boards are either 3C501's, 3C502's or 3C503's.  The
boards are identical, but one has a boot prom that says on it, "3C502
EtherStart V. 1.1."

I plan on using one board in a Compaq 286 with an Intel Inboard/AT and
one (for now) in a 386SX/20 (Orchid Motherboard).  Both systems will be
running ISC 2.0.2.  The Unix may be upgrade to ESIX R4 later down the
line.

I would appreciate any information one may have on configuring the
jumpers for the boards.  Later down the line, one of the 3-Com boards
will be replaced with a WD8003E or WD8013E and the 3-Com board will be
put into an XT clone running PC/IP or Karn's KA9Q.

Also, any documented problems with using these boards and how to get
around them would be most appreciated.

 Thanks,

  JCA

--

 /*
 ** ARPA    : crash!jca@nosc.mil
 ** INTERNET: jca@crash.cts.com
 ** UUCP    : {nosc ucsd hplabs!hp-sdd}!crash!jca
 */

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 20:36:23 GMT
From:      yongwang@eng.auburn.edu (Yong Wang)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe


Please unsubscribe me from the list.

---yongwang@eng.auburn.edu

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 21:15:06 GMT
From:      goldstein@delni.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help choosing PCROUTE/KA9Q/SLIP/PPP/V.32bis/V.42bis...


In article <F8758C8B3AC0E582@Arizona.edu>, JOHNGALT@CCIT.ARIZONA.EDU (John Galt) writes...
>...  I called our local phone
>company, US West, and requested that the line be put in.  WELL, they told
>me that the price had gone up on July 15.  Originally, the line was to cost
>~$740.00 to install and then $180.00 per month (this is for a 56K line).  As
>of the price increase, however, the installation cost is $1000.00 and the
>monthly charge is $720.00!!!!!!!
> 
>Flame on.
>This is a 400% increase!  I thought deregulation was supposed to stop this
>kind of thing!  I may have to blame it on our local "Arizona Corporation
>Commission" which seems to be a rubber stamp regulatory organization.
>Flame off.

Just as a hunch, did you order "DDS 56K" service?  In many cases, the 
telephone companies are "transitioning" the old DDS services.  These 
were hubbed, so every circuit went through some central test board,
at great cost, in order to guarantee low BER.  You need that as much as  
your bicycle needs armor plate!

Nowadays you should NEVER order DDS; instead, order "dirty digital" or 
"DDS2" or "Accunet Spectrum" (AT&T's name) or some other service.
In general these ONLY come in 56/64 kbps speeds (typically 64 kbps with
restrictions that make them effectively 56k after the DSU).  But they're
also usually cheap, about the same as a voice grade line or little more.

The phone company is getting people to move to the new service by
raising the price of DDS (hubbed) to the sky.  That's the usual way.

BTW, PPP buys you one thing SLIP can't: A checksum!  The TCP checksum is 
a bad joke; PPP has a true CRC.  If you don't like undetected errors,
don't use SLIP.  Anywhere on your network.  Period.
---
Fred R. Goldstein              Digital Equipment Corp., Littleton MA
goldstein@delni.enet.dec.com   voice: +1 508 952 3274
 Do you think anyone else on the planet would share my opinions, let
 alone a multi-billion dollar corporation?

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 21:30:31 GMT
From:      REDREC@UNAMVM1.BITNET (Cristina Casimiro)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on OS/2


   Hi :
   Do you if UNISYS offers the same package (TCP/IP,etc)
   Cristina Casimiro
   Universidad Nacional Autonoma de Mexico

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 91 23:27:53 GMT
From:      gaddam@remus.rutgers.edu (Surekha Reddy Gaddam)
To:        comp.protocols.tcp-ip
Subject:   Interested in TLI interface VS Berkely Sockets


Can some one post the trade-offs between the TLI interface and
the Berkely sockets.  


Thanks,

Surekha Reddy

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 00:45:57 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

In article <1991Sep23.181049.17056@kronos.com> richb@kronos.com (Rich Braun) writes:
>router, despite my request for bottom-line cost under US$5,000.
>
>This latest thread, though, points out something that I've always felt
>about Cisco:  they're a Rolls-Royce type of company, and I want a Volks-
>wagen.  My desire is to go to management and say "I can get real-time,
>secure access to Internet for little money", not "I can route 22 megabytes
>of data per second on our corporate backbone".

Try Telebit for the NetBlazer.  If you need a couple of ethernets, and no
more than one 56K leased line link (synchronous) then the Netblazer is much
less expensive and quite capable.

It's a Volkswagon, and priced like it.  Seems to work like it too (nice and
reliable).

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 01:26:55 GMT
From:      glenn@score.aic.co.jp (Glenn Mansfield)
To:        comp.protocols.tcp-ip
Subject:   Queries on CMOT


We are currently investigating the CMOT management protocol suite.
We intend doing some experimentation on this subject. In this context:

	are there any CMOT implementations available as pds or otherwise.
	are there any other sites carrying out similar experiments?
	is there a working group / news group where discussions on this
           subject is being carried out.

Please reply to me by mail. I will summarise the replies in this newsgroup.

					thanks
							glenn
						glenn@aic.co.jp

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 07:09:39 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

In article <1991Sep24.094657.1202@uniwa.uwa.oz.au>, jcross@ec.uwa.oz.au (Jennifer Cross - pgmr) writes:
>   ...
>   Many of the specialised (read non unix) systems out-there use more direct
>   memory systems.  ...
> I own an Amiga for fun, use SUN, SGI, PC, MAC for work.
                                   ^^^

SGI IRIS's have done something similar for network output for years, and
that with IRIX 4.0, do something similar on input when convenient.  It is
convenient surprisingly and significantly often with TCP/IP/FDDI and with
certain "C compiler and linker technology".


Vernon Schryver,   vjs@sgi.com

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 09:47:25 GMT
From:      johnm@vaxc.cc.monash.edu.au
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBM AADU and Clarkson packet drivers

In article <9236@cs.tulane.edu>, tom@rs1.tcs.tulane.edu (Tom Gerace) writes:
> ...
> I know that a Novell solution was created with the -n switch 
> in the Clarkson packet drivers, allowing both the Novell drivers
> and the Clarkson drivers to be in memory at once.

By default, a Packet Driver supports multiple applications that want to
use different protocols simultaneously; without having them fight for
control of the I/O board.

The -n option was created to change to format of packets of one of these
protocols.  From INSTALL.DOC:

          The -n option is used to convert IPX packets between the
          Ethernet II type 8137 encapsulation used by BYU's PDSHELL IPX
          interface code and the 802.3-style encapsulation normally used
          on Ethernet by Netware servers, shells and boot PROMs. ...

> Has anyone out there done the same thing with AADU and tn3270
> that we are doing here?  Can the two drivers use the one
> ethernet board concurrently?

What you require is a AADU driver (or AADU kernel) that makes calls to a
Packet Driver, and then AADU and tn3270 will both be able to communicate
concurrently.

	John
--
John Mann, Leader - Networking Section  Internet: johnm@vaxc.cc.monash.edu.au
Computer Centre, Monash University      Phone: +61 3 565 4774
Clayton, Victoria 3168, Australia       Fax:   +61 3 565 4746

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 12:54:39 GMT
From:      garyo@apricot.co.uk (Gary Osborne)
To:        comp.protocols.tcp-ip
Subject:   Re: Using LAN manager 1.1 tcp-ip with FTP PC/TCP

sgaras@brnwil.uucp (Sam Garas) writes:

>I am trying to use HP's LAN manager 1.1 tcp protocol in conjuction
>with FTP's PC/TCP.  I run into a conflict because of the two TCP 
>protocols loaded at the same time.  I can not run both of them at the
>same time.  I was wondering if anyone has any suggestions on how to 
>run PC/TCP and LAN manager 1.1 at the same time without running into any
>conflicts.  Can this be done?  

Why not junk the HP stack, run the FTP stack with FTP's Netbios, and their
DISPKT (Packet Driver -> NDIS converter) software. From what you say this should
work. FTP's Netbios is very compliant and the DISPKT driver is now old and 
safe software.

Cheers.


==============================================================================
Gary Osborne						garyo@apricot.co.uk

Apricot Computers Limited
Birmingham, UK
==============================================================================

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 13:41:32 GMT
From:      pv0618@hertz.njit.edu (Paranjothi Varadarajan)
To:        comp.protocols.tcp-ip
Subject:   Question on tn3270


Hi !

I am using tn3270 software ( I have the source code) to log into an MVSR
machine. I would like to  build something which lets the end user (using
my application) to directly go to the login prompt (ie pass the domain
stage). 


The User Interface currently runs tn3270 domain_name and the user  sees
the following in an xterm "
SNS/TCP Version 1.0.0 Server Telnet    (domain_name)
Wed, 25 Sep 91 9:35:07 EDT
Enter "NEWS" for current news.

Enter Command Or 'HELP':  "

The user then enters a (probably) system name, to which the system
responds by giving a logon promt.

I would like to remove this need of having the user to enter the system
name at the domain prompt every time and take him directly to the logon
prompt eg I would like to be able to  run 

 tn3270 domain_name sys_name.


I have been looking into the tn3270 code . 

Does any body out there any ideas of how can I do this.

I certainly do not want to write another program to run on top of tn3270
which probably opens up pipes and reads and writes thru the pipe to
communicate the system name.

Is it possible to use a socket for this ?

Please respond by posting in the news group in addition to sending the
mail , since I may loose the account I am using currently.

Really appreciate any clues...

thanks !

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 13:54:00 GMT
From:      Alessandro.Forin@SPICE.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: LANCE chip bug

The first thing you should fix is your mail setup :-))
sandro-
-----------------------------------------------------------------------------
Date: Wed, 25 Sep 91 09:28:54 -0400
Sender: <tcp-ip-relay@nisc.sri.com>
From: "Mail Delivery Subsystem" <postmaster@ray.com>
Subject: Returned mail: Unable to deliver mail
Precedence: junk
To: Alessandro.Forin@SPICE.CS.CMU.EDU

   ----- Transcript of session follows -----
554 fjr... Cannot open /ub1/fjr/.forward: Permission denied
setgroups: Not owner

   ----- Unsent message follows -----
Received: from uunet.UU.NET by rayssd.ssd.ray.com (5.65/8.26) with UUCP ; Wed, 25 Sep 91 09:28:55 -0400
Received: from SPICE.CS.CMU.EDU by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA16944; Wed, 25 Sep 91 08:54:46 -0400
Date: Wed, 25 Sep 1991 08:48-EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: Alessandro.Forin@SPICE.CS.CMU.EDU
To: "Fred J. Roeber" <rayssd!fjr@uunet.uu.net>
Subject: Re: LANCE chip bug
Message-Id: <685802936/af@SPICE.CS.CMU.EDU>
In-Reply-To: "Fred J. Roeber"'s mail message of 20 Sep 91 15:48:21 GMT

The Lance is a chip and all chips have bugs :-)
The ones I found are documented in a driver, which is free just like
all other Mach 3.0 code.
Let me know if you want to look at it.

sandro-

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 13:59:04 GMT
From:      jjohnson@HNS.COM (Jayne Johnson)
To:        comp.protocols.tcp-ip
Subject:   Connection failure detection with Berkeley sockets

I have a BSD4.3 Tahoe release of the TCP/IP suite of protocols and have noticed
strange behaviour from the socket api. Given the following scenario:
     1. card A creates a non-blocking socket for listening
     2. card B creates a non-blocking socket and initiates a connection 
        request to card A.
     3. card A receives a connection indication from the select() from card B
     4. card A accepts the connection request from card B.
     5. card B receives a connection confirmation from the select() from 
        card A.
     6. card A and card B exchange messsages 
     7. an operator resets card A ( on purpose , to simulate card failures )
     8. card B gets an indication from the select() 

My question is as follows , how can an application determine when a connection
has been broken ? Should select() get an indication? Should I set a socket 
option (like out-of-band data ? ). Should I read the socket control block 
structure state field? Is there a message passed between the TCP and socket api
which can be forwarded up to the application interface when connections are
closing?
I need to find out when a connection has failed as soon as possible since my
system has redundant cards ( which already have connections established ) and I
can easily switch over to the redundant card when a connection indication
is received. I prefer to treat the socket api like a black box and not read
the socket control block structure. I have been reading the RFCs ,
Steven's book on UNIX network programming, Lefler's book on BSD ,
Comer's book on TCP/IP and there doesn't seem to have any literature on
this subject. 
I also have instituted a failure management scheme which uses 'ping'
and periodic echo messages to determine who is alive and well in the
network. However the failure management system is much slower than
connection indications. Any thoughts? Any literature? 
Thanks in advance for your help and insight. 

Jayne F. Johnson
Hughes Network Systems
11717 Exploration Lane
Germantown, Md 20874

email : jjohnson@hns.com
phone : 301/428-2714

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 14:09:35 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is MX-ing the domain-name legal?

In article <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes:
>Is it legal to have an MX record so that mail can be sent to the
>domain name rather than to a specific host?  For example:
>
>    sub.domain.edu.     IN      MX     20   host2.sub.domain.edu.
>
 ...
>
>The reason for my question is that I have been told that the above
>configuration violates the RFC for DNS.

Not likely.  Check out the example zone on page 16 of rfc1033.
Note the MX record for domain SRI.COM directed at host KL.SRI.COM.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 16:22:13 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   All these "unsubscribe" requests

If someone is retransmitting this newsgroup via an e-mail list and
retransmitting responses via reply e-mail,

	PLEASE DISABLE THE REPLY POSTINGS.

At least until you provide a better method for people to get themselves
off the e-mail list.

Thank you.

-rich

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 16:49:29 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP sites in the US

Alex writes:

> I was wondering where a person could get FTP numbers for Pennsylvania or 
> the surrounding area?  Does it matter what type of connection one is on,
> say VAX cluster or UNIX?  I'd appreciate a list, but don't know where to get
> it.

and, paraphrased, what are available ftp sites.

FTP is available in almost all tcp-ip implementations.  I assume that you
really want to know what sites have ftp servers running that support
anonymous logins.  If that's what you're looking for, the archie system
at McGill University is one source.  You can get information on using
archie by telnetting to quiche.cs.mcgill.ca and logging in as archie.  In
addition, you can get a list of probable ftp servers by doing an anonymous
ftp to quiche.cs.mcgill.ca, cd archie/listings, and capturing the info you
get from an ls there.  If you do an ls -l, you can see when the information
on the listed host was last captured and how much space it takes to hold
a compressed version of the ftp-able file list.  I'm not sure why you're
interested in just the Pennsylvania area... as the domains indicate, 
anonymous ftp is supported on machines all over the world.

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(904)235-5153
(mark@telesys.ncsc.navy.mil)

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 18:14:29 GMT
From:      saba@tellab1.TELLABS.COM (Bruce Sabalaskey)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe

Please unsubscribe me from this list.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 18:30:26 GMT
From:      slf@well.sf.ca.us (Sharon Lynne Fisher)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Looking for SNMP users


I'm doing a story for Communications Week, and I'm looking for users who
have switched from some other network management method, or no network
management method, to some Unix-based management method, such as Accumaster
or SNMP.  If you'd be willing to be interviewed for this story, please reply
here, send me email at slf@well.sf.ca.us, or call me at (415) 864-5987.
Thanks!

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 19:15:08 GMT
From:      shj@ultra.com (Steve Jay)
To:        comp.protocols.tcp-ip
Subject:   zero windows & probes (was - Re: TCP FIN and window)

In <12716157325.11.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:

>1) In a modern TCP, the receiver window will never be o unless the destination
>   device is slower than the network link (eg terminal servers).

Destination devices slower than networks are quite common.  I just
tried an experiment on a Sun 4/370 with fddi & a SCSI disk.  I sent
800 KB from a faster machine to the 4/370, which was writing the data to
its SCSI disk.  A 0 window occurred 4 times during the transfer.

Please don't consider a 0 window an "unusual" event, or one that only
happens with very slow devices.

> 4) Probes are a failsafe technique for recovering from am ACK that would
>    open the window being lost.  Lost packets are rare.

Maybe not that uncommon in wide-area networks.  I think starting with
a fairly fast "zero-window" probe is a good idea.  Perhaps RFC 1122's
suggestion of 1 RTT is a bit quick, but the 5 seconds in Berkeley is
definitely too long.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 20:45:26 GMT
From:      kxb@math.ksu.edu (Karl R. Buck)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.ibm.pc.misc
Subject:   Using "mount" and SOSS

How can I allow a certain user (or failing that anyone from a certain client) 
to be able to mount a file system on SOSS? The documentation states that the 
export.us file is similar to exports(5), but there seem to bee some major 
differences in SunOS export format. At any rate I am trying to mount using 
mount(1) on a Sun client (using setuid root and executing as another user) 
but SOSS keeps complaining about "invalid client credentials". I am able to 
mount file systems just fine using "net use" with Sun's PC-NFS. Any ideas?

Thanks.
--
Karl Buck 				email: kxb@hilbert.math.ksu.edu
Department of Mathematics		Phone: 913.532.6750
Kansas State University		
Manhattan, KS 66506		

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 91 22:37:37 GMT
From:      NIC@NIC.DDN.MIL (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   DDN NIC changes!

This message is a notification of DDN NIC services transitioning from SRI
to a new contractor, GSI, and other related changes that will be occurring.

These changes should occur between 27-Sep-91 and 1-Oct-91.

HOST NIC.DDN.MIL
  Address will change from 192.67.67.20 to 192.112.36.5


MAILING LISTS
  TCP-IP, NAMEDROPPERS, and ISODE will move from NISC.SRI.COM
  back to NIC.DDN.MIL.


PRIMARY ROOT SERVER NS.NIC.DDN.MIL
  Address will change from 192.67.67.53 to 192.112.36.4

ROOT SERVER A.ISI.EDU
  A root server will no longer run on this host. 

ROOT SERVER KAVA.NISC.SRI.COM
  A new root server will be run at SRI at address 192.33.33.24, to take
  the place of A.ISI.EDU.

New ROOT.CACHE file that can be used with NAMED:
----------
;
;	@(#)root.cache	1.1	(Berkeley)	86/01/21
;
; Initial cache data for root domain servers.
;

.			999999	IN	NS	NS.NIC.DDN.MIL.
			999999	IN      NS	KAVA.NISC.SRI.COM.
			999999	IN	NS	AOS.BRL.MIL.
                        999999  IN      NS      C.NYSER.NET.
			999999	IN	NS	TERP.UMD.EDU.
			999999	IN	NS	NS.NASA.GOV.
			999999	IN	NS	NIC.NORDU.NET.

;
;  Prep the cache (hotwire the addresses).  Order does not matter
;

NS.NIC.DDN.MIL.         999999  IN      A           192.112.36.4
KAVA.NISC.SRI.COM.      999999  IN      A           192.33.33.24
AOS.BRL.MIL.            999999  IN      A           192.5.25.82
C.NYSER.NET.            999999  IN      A           192.33.4.12
TERP.UMD.EDU.           999999  IN      A           128.8.10.90
NS.NASA.GOV.            999999  IN      A           128.102.16.10
NS.NASA.GOV.            999999  IN      A           192.52.195.10
NIC.NORDU.NET.          999999  IN      A           192.36.148.17


-------

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 00:25:32 GMT
From:      Liquid.Len@SOL.USC.EDU
To:        comp.protocols.tcp-ip
Subject:   [PMDF Mail Server <Postmaster@gamera.usc.edu>: Undeliverable mail]

Please deal with this problem/mail loop. It's been a week and we're getting
millions of these. We don't have a user YONTA at node Gamera.bitnet or
Gamera.usc.edu, and if whoever it is is sending thinking he exists, please
remove him, from your list.

Thanks in advance.

USC
                ---------------

Return-Path: <postmaster@gamera.usc.edu>
Received: from gamera.usc.edu by sol.usc.edu (4.1/SMI-3.0DEV3) id AA13290; 
                Wed, 25 Sep 91 16:35:33 PDT
Date: Wed, 25 Sep 91 16:32 PDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: PMDF Mail Server <Postmaster@gamera.usc.edu>
Subject: Undeliverable mail
To: tcp-ip-relay%NISC.SRI.COM@usc.edu
Message-Id: <0D220746293FE07A2C@gamera.usc.edu>
X-Envelope-To: asbed@SOL.USC.EDU

The message could not be delivered to:

Addressee: YONTA
Reason: 
  %MAIL-E-NOSUCHUSR, no such user YONTA at node GAMERA

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

Received: from JNET-DAEMON by gamera.usc.edu; Wed, 25 Sep 91 16:32 PDT
Received: From SNYBUFVA(MAILER) by GAMERA with Jnet id 7683 for YONTA@SC; Wed,
 25 Sep 1991 16:32 PST
Received: from JNET-DAEMON by SNYBUFVA with PMDF#10360; Wed, 25 Sep 1991 19:35
 EST
Received: From CUNYVMV2(MAILER) by SNYBUFVA with Jnet id 8321 for
 YONTA%SC@SNYBUFVA; Wed, 25 Sep 1991 19:35 EDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 8710; Wed,
 25 Sep 91 19:31:44 EDT
Received: from NISC.SRI.COM by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP;
 Tue, 24 Sep 91 23:05:49 EDT
Received: by NISC.SRI.COM (5.65/SRI-NISC1.2) id AA13064; Fri, 20 Sep 91
 14:34:56 -0700
Received: from NIC.DDN.MIL by NISC.SRI.COM (5.65/SRI-NISC1.2) id AA13060; Fri,
 20 Sep 91 14:34:53 -0700
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 19 Sep 91
 09:23:02 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05372; Thu, 19 Sep 91
 09:19:49 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
 tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if
 you have questions)
Date: 19 Sep 91 15:42:14 GMT
Sender: <tcp-ip-relay@nisc.sri.com>
From:
 agate!spool.mu.edu!samsung!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!rogers%ucbvax.Berkeley.EDU@usc.edu
Subject: I need a PD bootp server for DOS?
To: tcp-ip%nic.ddn.MIL@usc.edu
Message-id: <1991Sep19.154214.23302@ux1.cso.uiuc.edu>
Organization: University of Illinois at Urbana
X-Envelope-to: YONTA

Is there a pd dos implemetation of bootp server to assisn IP address?
We are using a mix of NCSA, Clarkson, and Ka9q and would like to dynamically
assign ip's.
Thanks,
Bill
 
--
..............................................................................
Bill Rogers                             . Internet - rogers@ux1.cso.uiuc.edu
Asst. Director for Academic Computing   . Bitnet - ROGERS@UIUCVMD
Sangamon State University               . Voice - 217-786-6549
 

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 00:50:31 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   HELP - netstat, connect(ions)

We have a program that serves another set of programs.  It accepts
connections from the clients on a one-connection-per-message basis.
The client then closes the connection at which time the server (I hope)
closes his socket.

netstat(1) continues to show many sockets to the server, even after the
client has gone away.  The states show as LAST_ACK and TIME_WAIT and
such as that.

My question revolves around the number of sockets still showing under
netstat(1).  Is there a maximum number of these sockets in the
TIME_WAIT, etc, state that can exist before the server will stop
accepting new connections?  If there are clients attempting to connect
in a fairly rapid basis, will the clients eventually have to block
waiting around on an available socket?  This seems to be happening with
the clients.  I believe that they are sitting around waiting on a
connection which blocks the client for a number of seconds (< 10 secs).

The configuration is a DECsystem 5500, Ultrix 4.2.  The server socket id
is 2003, if that matters.

-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 02:06:06 GMT
From:      wong_a@summer.chem.su.oz.au
To:        comp.protocols.tcp-ip
Subject:   Sendmail.cf!


	I'm setting up sendmail and since we don't have a 
	particularly exotic setup, I just used the default 
	sendmail.cf suppiled by Apollo. I've looked at the 
	.cf file and all the "rules" look O.K. But here's 
	the transcript from a
	'sendmail -bm -v wong_a@summer.chem.su.oz.au' session,


wong_a@summer.chem... Connecting to summer.chem.tcp...
220 SUMMER.CHEM.SU.OZ.AU TGV/MultiNet SMTP service ready.
>>> HELO lester.ARPA
 250 SUMMER.CHEM.SU.OZ.AU ; Hello lester.ARPA, pleased to meet you.
>>> MAIL From:<root@lester.ARPA>
 250 OK
>>> RCPT To:<wong_a@lester.ARPA>
 250 <wong_a@lester.ARPA>... ok - delivered as <wong_a@lester.ARPA>
>>> DATA
 354 Start mail input; end with <CRLF>.<CRLF>
>>> .
 250 OK ; Job SMTP-NETMAIL (queue SMTP_SUMMER, entry 155) started on SMTP_SUMMER
>>> QUIT
221 SUMMER.CHEM.SU.OZ.AU TGV/MultiNet SMTP service complete.
wong_a@summer.chem... Sent


	Why is the 'RCPT To:' field set to '<wong_a@lester.ARPA>' 
	rather than '<wong_a@summer.chem.su.oz.au> ??

	How did sendmail modify the address I gave it, 
	summer.chem.su.oz.au -> lester.ARPA

	What rule am I supposed to modify?

Thanks
Adrian.

-----------------------------------------------------------------------------
Adrian Wong, Dept.of Theoretical Chemistry     wong_a@summer.chem.su.oz.au
University of Sydney NSW 2006 Australia        061-2-692 4137
-----------------------------------------------------------------------------

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 02:37:17 GMT
From:      lars@spectrum.cmc.com (Lars Poulsen)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available

Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about
security in Open Systems; Dan Kegel subsequently made it available
on a file server at JPL. I retrieved it, and it was a disaster ...

The document apparently has been posted earlier, and users had
grief with printing it, because it required (but did not include)
the Apple LaserPrep file. This version was supposed to alleviate
that problem.

(1) I retrieved the file and queued it for printing on my Imagen printer.
    I received 300 pages of PostScript Source, beginning with the Apple
    LaserPrep file. The only reason I'm still alive, is because nobody knows
    I was the one who submitted the job ....

    Problem no 1: The concatenated file does not begin with the
                  magic cookie that tells the print spooler that
                  this job is PostScript and doesn't need to be run
                  through the text-to-PostScript converter before
                  printing. That cookie is "%!" in the first two
                  bytes.
    Problem no 2: The VI editor won't read the file because there are
                  lines somewhere in the file longer than 256 ??
                  512 ??? bytes.
    Solution:     Use the ADB debugger to zap the second byte from
                  a "%" to a "!" sign.

(2) I printed the file again. No output. Just a cover page that said
    "Input file 768364 bytes: 0 pages printed".

    Problem no 3: Those long lines turn out to be the famous patented
                  Apple bit-smoothing code for the laserwriter.
                  About 12000 hex digits in a looooooooooong hex
                  string; wrapped in code that essentially says
                  "If the product name is not "LaserWriter", skip
                  to end of file".
                  That's just dandy, if the file is LaserPrep; not so
                  great, if the file is the concatenated LaserPrep
                  plus Arto's book.
    Solution:     Use ADB debugger to locate the offending section
                  and insert a "0A" (new line) character into the hex
                  string every 128 bytes or so; then use VI to delete
                  the whole binary program and wrapper.
                  About 3 hours.

(3) I printed the file again.
    The cover page is great.
    The next two pages are printed upside-down-reversed; i.e. to read
    them I have to hold the paper against the light and read THROUGH
    the paper.
    The next 80 pages look OK.
    Appendices again are mirror-reversed.
    The bibliography is not reversed, but is truncated about a half to a
    whole inch, so every line is missing a word or so.

    Problem no 4: The file is really a concatenation of 5 output files
                  from a wordprocessor. Not sure which one. Each file
                  starts out by invoking a "psu" (page setup) macro,
                  and ends with a "Trailer". The psu macro contains
                  some code that essentially says "fiddle with something
                  called /invertflag is this is not a LaserWriter and
                  the PostScript interpreter's revision number is less
                  than 47.0".
                  Well, our Imagen printer runs a PostScript CLONE
                  called UltraScript revision 2.0.
    Solution:     Try to delete the /invertflag portion of the /psu
                  macro.

(4) Print again: No output. Job failed with an error message:
                  [ Error: typecheck; OffendingCommand: get ]
    Obviously, I deleted something wrong.

Well, I'm out of time and patience. I really would have liked to read
this paper, but I don't have time to reverse-engineer it from the
broken postscript file. Will somebody wake me up when it's fixed ?

-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 02:40:36 GMT
From:      jprice@intel7.intel.com (Great GooglyMoogly!)
To:        comp.protocols.tcp-ip
Subject:   (none)


	Please remove me from your distribution list, please.

	Thanx in advance.

        o-------------------------------------------------------------o
        :   John Price, FB7-53, Intel, Rio Rancho, New Mexico 87124   :
        :               eMail:  JPrice@Intel7.Intel.Com               :
        :                 standard disclaimer applies                 :
        o-------------------------------------------------------------o
                "...it'll cure your asthma, too." - Grand Wazoo       

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 12:41:43 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,ba.internet,dnet.inet
Subject:   RFD:  comp.internet.{policy,routing,research}

I'd like to open the floor for discussion a new "comp.internet" set of
newsgroups, including some suggestions charters for a few of them, and
ideas for others.

It's a curious artifact of how Usenet and the Internet have developed
that there isn't a single mainstream usenet group with the name "internet"
in it.  Several regional news hierarchies have created such groups
(ba.internet, dnet.inet) and they carry reasonable traffic.  But there's
nothing in the mainstream netnews to discuss how the internet works, who
is involved in running it, what it costs, what it should be doing.  Those
discussions happen in one of several dozen mailing lists.

Here's a few suggested newsgroups (with charters handy) to take up the slack.

comp.internet.policy
	Rules, regulations, and policy decisions regarding internetworking.
	Appropriate use guidelines, commercial use restrictions, export
	regulations as they apply to internets.  What the rules are, who
	makes them, what it costs to make your own rules.

comp.internet.routing
	Routing protocols on the Internet -- RIP, EGP, BGP, OSPF, IS-IS, RSPF.
	Sensible routing architectures for regional, campus, and world
	networks.  Policy-based routing.  Traceroute.  Observations of what
	does and doesn't work on the internet today.  Traceroute contests
	(worked all states; worked all continents; maximum hop count :-)

comp.internet.research (moderated)
	Also suggested as "comp.protocols.research".  Matters of internetworking
	interest relevant to future networks and which expand the knowlege
	and state of the art.  Moderated (need to find a moderator for this
	one).  Target audience doesn't read a lot of netnews, but does care
	about the Internet, and doesn't have time to read tcp-ip.

Several other groups could potentially fall under the general "comp.internet"
rubric; certainly any of the IETF mailing lists might have a parallel
public newsgroup with a name somewhere near these (or in comp.protocols or
in comp.dcom).  Quite possibly there's room for a comp.internet.com-priv
gateway to the existing "commercialization and privatization of the
internet" mailing list (com-priv-request@uu.psi.com).  These groups which
I have describe are new lists, not gateways of older mailing lists; they
supplement the existing discussions, and don't replace them.

The net has grown substantially since TCP-IP@NIC.DDN.MIL first was gatewayed
into comp.protocols.tcp-ip.  Internetworking is a booming industry, and
it has generated a number of high-traffic mailing lists.  The proposed groups
have already seen substantial discussion on the net; the names are reasonable
(though I'm up for suggestions); and I think they'd be a good addition.
-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
 for information on MSEN products and services contact info@msen.com
"Technically trained people are not troglodytes" -- Mitch Kapor, RFC 1259

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 15:19:56 GMT
From:      tom@ksr.com
To:        comp.protocols.tcp-ip
Subject:   Please remove me from this list.


I tried sending to the list manager and I've tried sending to the list
itself but it seems like I just can't get off this list.  Somebody,
please help me get off, otherwise I'll just continue annoying
everybody with these silly messages.

Thanks,

tom@ksr.com

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 15:36:45 GMT
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available

In article <1991Sep26.023717.15435@spectrum.CMC.COM>, lars@spectrum (Lars Poulsen) writes:
>Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about
>security in Open Systems; Dan Kegel subsequently made it available
>on a file server at JPL. I retrieved it, and it was a disaster ...

Try with nic.funet.fi
pub/doc/security/karila/OpenSystemsSecurity.tar.Z which has the files
separately.

I haven't printed all of the files, but they do have the magic cookie
and do seem to work with Ghostscript - there seems to mantras
something like 'Copyright Lawsuits Inc, all rights reversed' in the
documents and also some eexec hex gibberish, but Ghostscript doesn't
seem bothered by those, and neither did a HP laserjet something with
which I tested Abstract.ps.

//Jyrki

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 15:50:11 GMT
From:      yongwang@eng.auburn.edu (Yong Wang)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

Please remove me from this list. Thanks.

yongwang@eng.auburn.edu

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 18:12:05 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP and PPP compared

The difference in efficiency between SLIP and PPP when transporting IP
datagrams is minimal.  Many PPP implementations include VJ header
compression while few SLIP implementations support VJ header
compression (I am not aware of any commercial SLIP offering that has
VJ header compression).

There is another issue here: PPP will support other protocol stacks
and SLIP will not.  If you are considering the possibility of running
more than one protocol stack over your link you will want to consider
PPP.  Also having the ability to negotiate anuthentication and IP
addresses is a win.

-- 
Brian Lloyd, WB6RQN                                     Lloyd and Associates
Network Architect                                       3420 Sudbury Road
brian@ray.lloyd.com                                     Cameron Park, CA 95682
voice (916) 676-1147

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 22:15:16 GMT
From:      Ewan.Tempero@comp.vuw.ac.nz (Ewan Tempero)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available


Here is what I did.

First the disclaimers
1. I know nothing about postscript except that it's some kind of
   stack-based language for printing things
2. This has worked for me "twice". "twice" is in quotes because the
   first time I did this was a long time ago and I only vaguely
   remember the details but the second time I did it (a couple of
   minutes ago) it took about 5 minutes to figure out how to
   print the first 3 pages (4 minutes were taken up in finding 
   where I put the damn file and then uncompressing it)
3. I make no claims that this will work for anyone else on any other
   system with any other printer (not "any other _brand_ of printer",
   any other printer than the physical one I used, which was the
   department Apple Laserwriter II)

So, I tried to print the document as received and got some error
(I forget what it was). So I looked at the postscript to see what
I could see. Knowing nothing about postscript I couldn't see much.
I then created another postscript file that I knew would print 
(using dvips this time, I forget what I used last time) and looked at 
it again to see what I could see as being different. My "weirdness 
detection heuristic" identified the line:

%%IncludeProcSet: "(AppleDict md)" 68 0

as being weird so I deleted it and tried printing the file again.
It worked.
<shrug>
good luck
--ewan
-- 
e-mail:	ewan@comp.vuw.ac.nz	Post: Department of Computer Science
Phone:	+64 4 715 328 x8069	      Victoria University of Wellington
Fax:	+64 4 715 375		      P.O. Box 600, Wellington, New Zealand
Conjecture: 1+1=1 (plus a small constant)

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 91 23:25:52 GMT
From:      jeff@markets.UUCP (Jeff Crilly N6ZFX)
To:        comp.protocols.tcp-ip
Subject:   delete jeff@markets.com

delete jeff@markets.com
unsubscribe jeff@markets.amix.com

- I tried various ways to get off the list.  Maybe this will do it.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 00:45:47 GMT
From:      dee@nimbus.worldbank.org (W. McDonald Buck)
To:        comp.os.vms,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   Re: Is TCP/IP and NFS viable in corporate network.

I didn't see the original post, nor many of the responses to this thread, but 
the question is very important to me as some of us are tasked to create a 
corporate network. We want to do just this (TCP/IP, NFS, etc). 

I need some info on who has done this on a large scale, and what success they 
have had. I am particularly interested in sites where users predominantly use 
PCs. We have thousands of PCs and eight hundred MACs. Maybe 2500 pcs are on 
token rings, and some run Banyan vines. Maybe 500 run Pathworks over ethernet. 
Most pcs are isolated, and just connect to terminal servers, or have token ring 
cards for SNA access to a 3090. We propose to try to build a campus wide TCP/IP 
net, and offer services to all. 

Thanks for any input.   

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 04:05:15 GMT
From:      jgd@convex.csd.uwm.edu (John G Dobnick)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available

From article <1991Sep26.023717.15435@spectrum.CMC.COM>, by lars@spectrum.cmc.com (Lars Poulsen):
> Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about
> security in Open Systems; Dan Kegel subsequently made it available
> on a file server at JPL. I retrieved it, and it was a disaster ...

I, too, had difficulties with this.  What I wound up doing was
(using the JPL files as a base):

	Acquired the tar file with the individual sections.
	Ignored the mass "all-in-one" file.
	Printed the individual sections, individually.  

It seems that the combined file has this Apple header cruft in it
that triggers our PostScript printer's "this is text" filter (the
file lacks the "%!" magic-cookie.)  Our (non-Apple) printer also
seemed to choke on the Apple-specific data.

The individual sections each start with "%!" magic-bits; the document
prints without incident, although some assembly is required.  :-)
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: jgd@uwm.edu                      ATTnet: (414) 229-5727
UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 04:06:00 GMT
From:      CURT.ELLMANN@MAIL.ADMIN.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

to: tcp-ip@nic.ddn.mil

please remove me from the tcp-ip list

thanks

curt.ellmann@mail.admin.wisc.edu





                                                                               

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 07:09:25 GMT
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

In article <Sep.24.19.27.53.1991.1179@remus.rutgers.edu> gaddam@remus.rutgers.edu (Surekha Reddy Gaddam) writes:
 > 
 > Can some one post the trade-offs between the TLI interface and
 > the Berkely sockets.  

Just a few...

In BSD UNIX Sockets are kernel based.  In System V TLI is an interface
library implemented upon a STREAMS based network.

The same TLI interface can be used with any STREAMS based network
implementation.   Address sizes might be a concern with sockets. (What do you
do if the network address requires more bytes than will fit into a struct
sockaddr?)

TLI buffer management is more complex, even with the t_alloc call.  It's all
too easy (IMHO) to have a memory leak using TLI.

A TLI server has to do more work that a socket server to accept a connection.
Using sockets an accept call returns a new socket -- TLI has to create the new
endpoint before calling accept.

You can not read and write to a TLI endpoint unless the network stream has
been modified (by popping and pushing the appropriate module).   t_snd and
t_rcv would have to be used.

// marc
-- 
marc@dumbcat.sf.ca.us -- pacbell!dumbcat!marc

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 10:41:07 GMT
From:      daveg@prowler.clearpoint.com (Dave Goldblatt)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Help Requested in Defeating Ring Buffer Software Patent


[ I apologize for the wide distribution (especially if you've seen it before),
   but as this could conceivably affect a wide number of people, I figure
   it's worth it.  Flames to email, please. ]

	I am looking for information which could be used to invalidate
a patent which covers one of the most basic techniques in software:
the ring buffer.  Specifically, the patent is on the idea of using two
circular buffers in commonly addressable memory to queue pointers to
messages (also in shared memory) between two processors.  One buffer
contains messages going in one direction, and the other buffer
contains messages going in the other.

	The allegedly inventive feature is having one of the
processors tell the other processor the size of the ring buffers.

	I'm looking for code or references to this technique written
before October 5, 1981.  An example of dual processor communication
would be ideal, however, inter-process communication via this method
could also prove useful.  I know of at least one network adapter which
violates this patent, and also of an Ethernet controller which does as
well, but neither are before the required date.  I've also heard that
the CDC 6x00 line used this method -- details would be appreciated.

	Any information will be GREATLY appreciated!  For better
results, email will be appreciated even more so.

	Thanks!

-dg-
--
"We go out in the world and take our   |  Dave Goldblatt [daveg@clearpoint.com]
  chances / Fate is just the weight of |  Subsystems Software Engineering
  circumstances / That's the way that  |  Clearpoint Research Corporation
  lady luck dances / Roll the bones.." - Rush

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 12:18:29 GMT
From:      graeme@ccu1.aukuni.ac.nz ( Graeme Moffat)
To:        comp.protocols.tcp-ip
Subject:   Re: routing problem from hell

Christopher-Vance@adfa.oz.au (Christopher JS Vance) writes:

> Detailed description of network deleted
 
>But there is no host D.E.30.21.  This works because we have a friendly
>host export an ARP entry for this IP address which has the ethernet
>address for the router D.E.1.16.  Perhaps we could tell the router to
>recognise this as an alternative IP address for itself on the save
>interface as D.E.1.16, but I don't drive that machine, so I can't tell
>you.

Ask the people who do!
Sounds like your campus network administration is as bad as ours. They
should have this set up, and assist you to configure correctly.

>Why this kludge?  There are multiple hosts on D.E.30.* which all think
>the campus has no subnets.  Why is the other network different?  They
>have no hosts except those on their subnet.

But wouldn't it be better to do it properly?  If part of your net is
subnetted, than *all* of it should be.  And how do the hosts D.E.30.* talk
to the subnetted ones?

>The other part of the solution is a proxy ARP server which ensures
>that requests from non-subnetted hosts for ethernet addresses of hosts
>on D.E.31 and D.E.51 get given the ethernet addresses of their
>respective gateways instead.

Ah. Thinking about it, I suppose this actually reduces network packets,
since a properly subnetted host would have to send packets for all different
subnets to the router for forwarding back on the same cable, while here the
hosts believe that they're all on the same physical interface and hence only
one packet appears.
Who keeps the proxy ARP tables uptodate when hosts are changed? What if
there were many more subnets all over the place?

-- 
Graeme Moffat                g.moffat@aukuni.ac.nz \ Time wastes us all, 
Computer Aided Design Centre,  Fax: +64-9-366-0702 /  our bodies & our wits
School of Engineering,    Ph: +64-9-737-999 x8384 /  But we waste time,
University of Auckland, Private Bag, Auckland, NZ \   so time & we are quits

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 13:45:12 GMT
From:      mike@sojurn.uucp (Mike Sangrey)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available

In article <1991Sep26.023717.15435@spectrum.CMC.COM> lars@spectrum.cmc.com (Lars Poulsen) writes:

>Well, I'm out of time and patience. I really would have liked to read
>this paper, but I don't have time to reverse-engineer it from the
>broken postscript file. Will somebody wake me up when it's fixed ?
>
>-- 
>/ Lars Poulsen, SMTS Software Engineer
>  CMC Rockwell  lars@CMC.COM

Me too, Me too, ....  If this has already been fixed, I would really like
to know where to get a copy.  I'm mainly uucp, but with some work I can
ftp it.

Thanks !!


-- 
   |  UUCP-stuff:  rutgers!devon!sojurn!mike   |  "It muddles me rather"     |
   |  Slow-stuff:  2129 Old Phila. Pike        |             Winnie the Pooh |
   |               Lancaster, Pa.  17602       |    with apologies to        |
   |  Fast-stuff:  (717) 396-9897              |             A. A. Milne     |

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 13:58:38 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

James, Brian, et, al,

Clearpoint is not "pushing" SLIDE "over" PPP. For various historical reasons,
SLIDE development preceeded PPP development. PPP is being developed right now
and we hope to have it released by the end of the year.

We ARE committed to A) developing standards based bridges and routers and B)
publishing any proprietary protocols that we develop so as to continue the
thought, development, and evolution of networking. As a corporate 
philosophy, we believe very strongly in contributing to the area from 
which we have gained so much and SLITHER/SLIDE is one such contribution.


PPP provides the same capabilities that SLIDE does. It also provides
more capabilities than SLIDE does. It is also a standard -- SLIDE is
not. It is also more costly to implement than SLIDE is -- it has a
finite state machine, link control protocols, several supporting
protocols and services and so on.
 
There are techno-religous arguments as to whether PPP is a "good"
protocol or not. Reasonable people may and do hold differing opinions
on the subject, and they do. Those arguments are best carried out on the
mailing lists and in the market place. If, at some point, SLIDE "wins"
(whatever that means) then perhaps it too could become a standard
protocol.

Cheers
Frank Kastenholz
Clearpoint Research Corp.



 > From tcp-ip-relay@nisc.sri.com Fri Sep 27 02:13:23 1991
 > To: brian@telebit.com  (Brian Lloyd)
 > Subject: Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)
 > Sender: <tcp-ip-relay@nisc.sri.com>
 > From: jbvb@ftp.com  (James B. Van Bokkelen)
 > Reply-To: jbvb@ftp.com
 > Cc: tcp-ip@nic.ddn.mil
 > Repository: babyoil.ftp.com
 > Originating-Client: plug.ftp.com
 > 
 >     The requirement for PPP is becoming part of the router requirements
 >     doc as well.  Why muddy the water with another nonstandard?
 > 
 > Clearpoint wants SLIDE et al. Because PPP doesn't do what bridges need;
 > they want MAC addresses and 802.1 spanning tree connectivity.  I don't
 > know if their hope that hosts will implement it will ever come true, but
 > the prospect of multi-vendor interoperability among half-bridges sounds
 > like a good idea to me.
 > 
 > James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
 > FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
 > 
 > 
 > 


slipslide

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 14:20:34 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Williams)
To:        comp.protocols.tcp-ip
Subject:   UNSUBSCRIBING

Well, since there have been a bunch of "let me off the list" requests on the
air lately, let me remind people that, in general, you should direct your
unsubscribe requests to [interest-group]-request@[host].  If that's not
working for tcp-ip, there's a problem that probably requires contacting
a live person by telephone or specific email address.  To recheck before
posting, I picked up the latest interest-group info from NIC.  Here's the
entire tcp-ip entry, in case anyone's forgotten what the purpose of this
group actually is...

TCP-IP@NIC.DDN.MIL

   The NIC has taken over the responsibility for the periodic update of the 
   TCP-IP implementations (the latest update can be obtained via FTP by 
   ANONYMOUS login from SRI-NIC file NETINFO:VENDORS-GUIDE.DOC).  We are 
   particularly interested in the addition and expansion of TCP services. In 
   addition to this function, it is hoped that this distribution list can aid 
   in the following areas:

      To act as an on-line exchange among TCP developers and maintainers.

      To announce new and expanded services in a timely manner.

   Archives are kept on SRI-NIC in files:
      TS:<TCP-IP>TCP-IP.*
      where the "*" is a wild-card character.

   All requests to be added to or deleted from this list, problems, questions,
   etc., should be sent to TCP-IP-REQUEST@NIC.DDN.MIL.  Please do \not/ send 
   such requests to TCP-IP@NIC.DDN.MIL, as this address is self forwarding to 
   the entire list membership.

   Coordinator: Vivian Neou <Vivian@NIC.DDN.MIL>
                            (415) 859-4781

I hope this eliminates the confusion...

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(904)235-5153
(mark@telesys.ncsc.navy.mil)

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 14:38:03 GMT
From:      dave@mmagnet2.mmc.com (David A. Rageth)
To:        comp.protocols.tcp-ip
Subject:   BIND and MX records

I have a generic question about the use of MX records in the domain name server.
Currently, to insure the delivery of mail we have the following MX
definitions for hosts:

    hosta    IN   MX   10 hosta
             IN   MX   20 servera
             IN   MX   50 serverb
    hostb    IN   MX   10 hostb
             IN   MX   20 servera
             IN   MX   50 serverb


Instead of repeating the same set for each host, is it possible to do
the following:

    *        IN   MX   20 servera
             IN   MX   50 serverb


    hosta    IN   MX   10 hosta
    hostb    IN   MX   10 hostb


x++++++++++++++++++++++++++++++++++++++++x
 x            David Rageth                x
  x   Internet : dave@mmc.com              x
   x   voice    : (303)977-4584             x
    x   fax      : (303) 877-2765            x
     x   USMail   : Martin Marietta           x
      x              P.O. Box 179 m/s 1084     x
       x              Denver, Colorado          x
        x                               80201    x
         x++++++++++++++++++++++++++++++++++++++++x

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 15:10:36 GMT
From:      poorman@convex.com (Peter W. Poorman)
To:        comp.protocols.tcp-ip
Subject:   Correct response to FTP "NLST"?

Hi folks;

I've just run across an interesting issue in the implementation of the 
FTP protocol.

RFC 959 says that the correct response to a "NLST" (Name LiST) command
is "... a stream of names of files and no other information."  Many
servers (for example, SunOS) return a list that INCLUDES the names of
sub-directories, while other servers do not.

This difference makes life difficult for programs that attempt to make
sense out of the this information.  (Exactly what this command is intended
for, according to the RFC.)

Does anyone out there have any information that would clarify the "correct"
behavior in this case?

Thanks!

--Pete Poorman
  poorman@convex.com

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 15:41:55 GMT
From:      wayne@ultra.com (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

David Borman says:

 >> HiPPI is not a ring technology.  HiPPI networks are made with
 >> crossbar switches.  You set up and tear down individual
 >> connections through the switch.  Seperate connections do not
 >> interfere with each other.  (e.g., if you have a connection
 >> between machines A and B, and another connection between machines
 >> C and D, each connection can pump data through at the full 800
 >> mbits/sec if it is able to...)  So, a HiPPI network is not used as
 >> a backbone in the same sense that FDDI is used as a backbone...

He is of course correct that HIPPI is not a ring technology.  It is in
fact a *channel* technology, quite similar to the earlier Cray High
Speed External (HSX) channel.  He is also correct that *one* way of
building "HIPPI networks" is with crossbar switches.  This is
reminiscent of the old days of interconnecting IBM mainframes with
channel-to-channel adapters.

This is by no means the *only* way of networking with HIPPI, however.
It is equally possible to use the HIPPI as a traditional channel,
connecting to a "control unit" (network adapter) that provides access
to a traditional network, with traditional networking facilities like
a wide variety of host connections, routers, network hierarchies
("backbones"), and so forth.  The trick, of course, is to find a
network fast enough to make a HIPPI connection worthwhile; clearly
Ethernet and FDDI to *not* fit the bill.

    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!

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 15:59:49 GMT
From:      dank@blacks.jpl.nasa.gov (Dan Kegel)
To:        alt.security,sci.crypt,comp.protocols.tcp-ip
Subject:   Re: "Open Systems Security" documnet available

jgd@convex.csd.uwm.edu (John G Dobnick) writes:
>From article <...>, by lars@spectrum.cmc.com (Lars Poulsen):
>> Arto Karila (atk@ajk.tele.fi) posted a pointer to a document about
>> security in Open Systems; Dan Kegel subsequently made it available
>> on a file server at JPL. I retrieved it, and it was a disaster ...
>I, too, had difficulties with this.  What I wound up doing was
>(using the JPL files as a base):
>	Acquired the tar file with the individual sections.
>	Ignored the mass "all-in-one" file.
>	Printed the individual sections, individually.  
>It seems that the combined file has this Apple header cruft in it
>that triggers our PostScript printer's "this is text" filter (the
>file lacks the "%!" magic-cookie.)  Our (non-Apple) printer also
>seemed to choke on the Apple-specific data.
 
>The individual sections each start with "%!" magic-bits; the document
>prints without incident, although some assembly is required.  :-)

Ok, I am deleting the all-in-one file from blacks.jpl.nasa.gov.
The tar file is still available as
blacks.jpl.nasa.gov:pub/security/karila/OpenSystemsSecurity.tar.Z
- Dan Kegel

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:02:23 GMT
From:      schmidt@orion.oac.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

++ In article <Sep.24.19.27.53.1991.1179@remus.rutgers.edu> gaddam@remus.rutgers.edu (Surekha Reddy Gaddam) writes:
++  > 
++  > Can some one post the trade-offs between the TLI interface and
++  > the Berkely sockets.  

If you have a chance, check out chapters 6 and 7 from W. Richard
Stevens excellent book on UNIX Network Programming.  It covers both
BSD sockets and TLI there.

        Doug

p.s. another trade-off between the two is that in certain Sun OS releases
     the TLI/Streams support appears to be broken, e.g., you can't perform
     an orderly release!  I understand this is fixed in later versions.

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:06:59 GMT
From:      prakash@beast.sme.siemens.com (Veera Prakash)
To:        comp.protocols.tcp-ip
Subject:   Unsubscribe me please!!!

Please, Please remove me from the mailing list.
I have sent several messages to tcp-ip-request@nic.ddn.mil and
tcp-ip-request@nisc.sri.com. But, nobody has cared so far.

Thanks very much,
Veera Prakash <prakash@sme.siemens.com>

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:11:48 GMT
From:      elogan@hp835.mitek.com (Ernie Logan)
To:        comp.protocols.tcp-ip
Subject:   Re: Correct response to FTP "NLST"?

In article <poorman.685984236@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes:
>Hi folks;
>
>I've just run across an interesting issue in the implementation of the 
>FTP protocol.
>
>RFC 959 says that the correct response to a "NLST" (Name LiST) command
>is "... a stream of names of files and no other information."  Many
>servers (for example, SunOS) return a list that INCLUDES the names of
>sub-directories, while other servers do not.
>
>This difference makes life difficult for programs that attempt to make
>sense out of the this information.  (Exactly what this command is intended
>for, according to the RFC.)
>
>Does anyone out there have any information that would clarify the "correct"
>behavior in this case?
>
>Thanks!
>
>--Pete Poorman
>  poorman@convex.com

RFC 1123 (Host Requirements RFC) says:
(I quote from "4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3")

"The data returned by an NLST command MUST contain only a simple list of legal
pathnames, such that the server can use them directly as the arguments of
subsequent data transfer commands for the individual files."

RFC 1123 expands on most application related RFC's, amd is the latest
information for FTP.

This means to me that the SunOS you refer to is NOT RFC compliant if it does
what you say it does. 
---
Ernie Logan
AS/400 TCP/IP Development
elogan@oc.com

OpenConnect Systems
2033 Chennault Drive
Carrollton, Texas USA 75006
Phone: (214) 490-4090
*-------------------------------*
* "My opinions are mine alone.  *
* No one else would want them." *
*-------------------------------*

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:21:25 GMT
From:      dzoey@terminus.umd.edu (Joe Herman)
To:        comp.protocols.tcp-ip
Subject:   Re: Correct response to FTP "NLST"?

poorman@convex.com (Peter W. Poorman) writes:


>RFC 959 says that the correct response to a "NLST" (Name LiST) command
>is "... a stream of names of files and no other information."  Many
>servers (for example, SunOS) return a list that INCLUDES the names of
>sub-directories, while other servers do not.
 
>Does anyone out there have any information that would clarify the "correct"
>behavior in this case?

From the Host Requirements RFC (RFC 1123) Section 4.1.2.7
"The data returned by and NLST command MUST contain only a simple list
 of legal pathnames, such that the server can use them directly as the
 arguments of subsequent data transfer command for the individual files."

I interpret this to mean that you should only return file names and not
sub directories in response to an NLST command.

				Joe Herman
				U. of Maryland DOSIP project.

dzoey@terminus.umd.edu
-- 
"Everything is wonderful until you know something about it."

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:44:54 GMT
From:      pmanglik@tanj.intel.com (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   Please unsubscribe NOW

tom@ksr.com writes:
 > 
 > Please, can someone help me get off this d*mn list!!!!
 > 
        Tom Varga
 
Tom,

Looks like 'you can check out anytime you want, but you can never leave'.
I have been trying unsuccessfully to get off the list for the last 3 weeks. 

Pankaj

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 16:44:56 GMT
From:      dsoulele@uccs.jpl.nasa.gov (Dean Souleles)
To:        comp.protocols.tcp-ip
Subject:   SLIP and/or PPP for Ultrix 4.1

I'm interested in establishing a an internet connection between a machine in
Europe and a machine in the U.S.  For various reasons I need to use a 
serial connection. I am thinking of using SLIP and/or PPP to run a TCP/IP 
connection with high-speed data compressing modems. inter-continental US
to Europe. I plan to have some X windows clients running on the remote
machine with the X server running locally.

A couple of questions:

	1. Is SLIP the appropriate protocol to use for this? Is there
	   another way to do this?

	2. Are SLIP and PPP independent of each other? (I.E. Do
	   I need both of them?)

	3. What is the current version of SLIP and PPP?

	4. It there an Ultrix 4.x port of SLIP and PPP available via 
	   ftp (and where)?


Thanks much.
-- 
Dean Souleles			dsoulele@uccs.jpl.nasa.gov
				dsoulele@dsfvax.jpl.nasa.gov

Jet Propulsion Laboratory

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 17:07:32 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Correct response to FTP "NLST"?

In article <poorman.685984236@convex.convex.com> poorman@convex.com (Peter W. Poorman) writes:
>RFC 959 says that the correct response to a "NLST" (Name LiST) command
>is "... a stream of names of files and no other information."  Many
>servers (for example, SunOS) return a list that INCLUDES the names of
>sub-directories, while other servers do not.

From RFC1123, "Requirements for Internet Hosts -- Application and
Support", page 31:

            The data returned by an NLST command MUST contain only a
            simple list of legal pathnames, such that the server can use
            them directly as the arguments of subsequent data transfer
            commands for the individual files.

You are confusing the OS concept of "filename" with the FTP concept of
"name".  This quote seems to try to clear up such confusion by
refering to "pathnames", which, to me at least, clearly indicates that
the directory information should, in fact, be included. 

The distinction between "filename" and "directory" is entirely OS
specific.  From an external host, the OS's filename cannot be
distinguished from the OS's directory information.  This leads me to
think that the FTP "name" of the file should be a unique name that
isn't dependent on the current context of the FTP session.
Consequently, it would include the directory information.

Since the 4.2BSD FTP server reacted in exactly the way you prefer,
there are many implementations which are at odds with this practice.

>This difference makes life difficult for programs that attempt to make
>sense out of the this information.

Actually, back when i was doing FTP client hacking (a *long* time ago,
mind you), i found just the opposite to be the case.  The problem is
that as long as the user provides the NLST argument, she can use her
OS specific knowledge to aim the NLST at a particular directory
without the client program's knowledge.  Now when the NLST response
comes back, the client program doesn't have a clue how to combine what
the user asked for with what came back from the server to identify a
particular file.  If NLST returns a pathname for the file that is
unique across the entire file system, the client program can operate
on each file without having to understand the user's original
directory request.  The Host Requirements passage i quoted above seems
to be aimed at solving this problem by requiring that the returned
string can be used "directly" as an argument to a file operation.

In my experience, only UNIX specific FTP clients can do anything with
the filename-only NLST response.  (And many UNIX specific FTP client
implementators seem to have difficulty understanding what makes
their client UNIX specific....)
						don provan
						donp@novell.com

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 17:51:04 GMT
From:      brian@RAY.LLOYD.COM (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Using Wide-Area Point-to-Point Links for Computer Networking (I)


Truce.  Sr. Martillo and I have let the PPP and SLIDE discussion
slither off into personal mail.  I appologize profusely for cluttering
up the tcp-ip mailing list.  It came from responding to mail and not
paying attention to who all the recipients were.  Mea culpa.

Brian Lloyd, WB6RQN                                     Lloyd and Associates
Network Architect and all-around nice guy               3420 Sudbury Road
brian@ray.lloyd.com                                     Cameron Park, CA 95682
voice (916) 676-1147

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 18:34:46 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Is MX-ing the domain-name legal?

In <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes:
>Is it legal to have an MX record so that mail can be sent to the
>domain name rather than to a specific host?  For example:
 
>    sub.domain.edu.     IN      MX     20   host2.sub.domain.edu.
 
>The intent here would be for host2 to act as the domain's mailhost
>and for the from-line on outgoing mail to read "user@sub.domain.edu"
>so that the outside world would not be aware of hosts 1, 2, or 3.

This is perfectly legal -- your informant is mis-informed.  I think RFC 974
even has an example like this.

Craig Partridge

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 19:17:00 GMT
From:      NEWKIRK@hsdwl.utc.com
To:        comp.protocols.tcp-ip
Subject:   How to convert to legitimate network address


    First, some "claimers":  (1) this is the right list, (2) I do read
it, and (3) I'm not the only one interested.
 
    Well, it's finally happened.  We now have a bone fide class B network
number and are now facing the task of converting a bogus, class A,
wholly bridged network into something legitimate.  Problem is, where
to grab a hold?
 
    The existing network has about 500 hosts and workstations of various
varieties, e.g. Sun's, HP's, Dec's (VMS & Ultrix), PC's, Mac's, etc.  We
also use IBM's tcp/ip code on VM and MVS, UCX on a VAX 9xxx, and so on.
Our network covers about a dozen buildings, mostly "local", but some 30
miles or so away.  Novell is also sprouting and there's LAT to contend
with.
 
    Our current thoughts are to use a simple 255.255.255.0 subnet mask
and perhaps start with Domain Name services.  But that's about where the
ideas stop and speculation begins.  A wholesale replacement of bridges
with routers isn't reasonable ($$), and a "midnight address-changing
party" is sadistic.  In a nutshell, the overall need is for an orderly
transisition from the old to the new.
 
    So, where should we start?  Suggestions, thoughts, rules-of-thumb,
war stories, references to published documentation (RFC's?), and so on,
will all be gratefully received (and read).  Perhaps a compilation of
replies would make a useful addition to the FAQ list.
 
    Thanks in advance,
    Bill Newkirk
 
PS: If you just can't resist, go ahead and say, "I told you so."  :-)

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 20:54:17 GMT
From:      hobbit@FTP.COM (*Hobbit*)
To:        comp.protocols.tcp-ip
Subject:   gethostby* routines

Is it really the case that most gethostbyaddr() implementations return only
the canonical name in the hostent [hostinfo? whatever] struct, without filling
in the aliases as well?  This is sort of biting us on the suns on which we
dinked the libraries to use the domain resolver instead of the YP kludge --
now we're having to do things like put the FQDN in the exports file because
when "mountd" does its inverse lookup, all it gets back is the cname and no
aliases [I checked this with a small example program].  If gethostent()
winds up using the host table, all the aliases seem to get filled in, but not if
we're strictly using the resolver.

We further noticed that one can "work around" this by taking the one name you
get back, and doing a forward gethostbyname() on *that*.  You then get
back all the aliases.  Sure, we can mung all our various Sun libraries to
do this and hope all the executables call this same library, but it doesn't
help us for all cases and I was wondering if there was a better way to make
gethostbyaddr() work right for us.

_H*

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 21:11:45 GMT
From:      megauthi@watcgl.waterloo.edu (Marc E. Gauthier)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Summary of replies -- AFS, RFS & other remote file systems

Here is a summary of the replies I have gotten concerning my inquiry
about remote/distributed file systems over IP.  I had not announced I
would do a summary, but it has been suggested, and the material seems
of general interest.  I have edited down most replies, for brevity.

------------------  AFS  ------------------

I got very good references on AFS (mostly from Transarc, who are
maintaining/improving/commercializing it).
Perhaps the most interesting was a reference on where to get documentation
for AFS ... in AFS files!  (i.e., you'd need to be running AFS to get
them -- not useful if you're looking for docs on how to _implement_ AFS :-)
But they are available via anonymous FTP also, as described below.


> From Brian.Pawlowski@Eng.Sun.COM Wed Sep  4 03:58:28 1991
> From: Brian.Pawlowski@Eng.Sun.COM (Brian Pawlowski)
> Subject: AFS Specs
> 
> I have attached two notes on AFS docs (where to get them) to get
> you started.
 [I included part of the first -MEG]
> 
> After reading the docs (which describe AFS 3! not AFS 4 (aka OSF DCE DFS))
> I'd be intrerested in hearing if you think it is feasible to implement
> these protocols from scratch.
> 
> Keep in mind that many feel that AFS 4 (which is the most likely
> pretender, er I mean contender, to the throne currently occupied
> by NFS:-) is by some measure two to four times more complex
> than AFS 3.
 
> Here goes, first mail from Ed_Zayas@transarc.com.
> 
> [Access is through AFS]
> 
> The set of AFS-3 programmer's specification documents have now been
> released, and are publicly available in the GCO cell.  For those who
> forgot, you may access the .dvi and PostScript files for these papers in
> the following directories:
> 
>       /afs/grand.central.org/darpa/doc/afs/specs/progint/
>               archov - Architectural Overview
>               bsrv - BOS Server
>               fscm - File Server/Cache Manager
>               psrv - Protection Server
>               rx - Rx, LWP
>               vvl - Volume/Volume Location Server


> From erz+@transarc.com Wed Sep  4 11:19:53 1991
> From: Ed._Zayas@transarc.com
> Subject: Re: AFS 3 documentation?
> 
> Marc...
> 
> Yes, you're right, AFS is not free (cheap, but not free).  Anyway, we
> did indeed think ahead to the fact that people not running AFS might
> like to look at these documents.  We've set up an anonymous FTP service
> here, and the specs are available in this fashion.
> 
> The host you want to FTP from is grand.central.org (IP address
> 192.54.226.100, just in case name mapping is a problem for you).  You'll
> find yourself sitting in the equivalent of the /afs/grand.central.org
> AFS directory.  The AFS-3 programmer specs are, as you might imagine,
> visible in the following directory:
> 
> 	darpa/doc/afs/specs/progint
> 
>[...]  I'll post a followup on info-afs, telling people about this option.
> 
> Please make sure to forward any comments, suggestions, etc. to me having
> to do with the AFS prog spec suite.  Also, please tell your friends who
> don't normally read this bboard that they are there for the sharing.
> 
> As far as the AFS-4 stuff, I don't believe the specs are publicly
> releasible yet.  However, there was a paper presented at the Summer 1990
> Usenix that might interest you.  It is entitled ``DEcorum File System
> Architectural Overview'', and gives a flavor of what's going on in
> ``AFS-4''.  If you don't already have it or can't easily get a hold of
> it, I'm moving the on-line version of it to GCO.  You'll be able to find
> it, again via anonymous FTP, in the following directory [...]:
> 
> 	darpa/doc/afs/dce/usenix90
 
> From erz+@transarc.com Tue Sep 10 10:20:55 1991
>[...]
> You can use the following reference for the Usenix DFS paper:
> 
> 	Michael L. Kazar, Bruce W. Leverett, et. al.,
> 	``Decorum File System Architectural Overview'',
> 	USENIX Conference Proceedings,
> 	Anaheim, TX, Summer 1990

[ The USENIX paper is also available in PostScript.  I've put the paper,
as well as the .dvi version of AFS specs, available via anonymous FTP
from watcgl.waterloo.edu in /pub/afs , since access to grand.central.org
from our site is often quite slow. -MEG ]


> Elaine Wolfe
> Marketing Services
> Transarc Corporation
> The Gulf Tower, 707 Grant St.
> Pittsburgh, PA 15219
> (412) 338-4448
> elaine@transarc.com

[ I thought I might as well include this, for people actually interested
  in getting AFS.  -MEG ]


------------------  RFS  ------------------

> From doug@access.digex.com Thu Sep  5 06:28:13 1991
> From: "Douglas E. Humphrey" <doug@access.digex.com>
> 
> [...] I know that RFS is an AT&Tism, 
> found in System V UNIX, so AT&T via some channel would be the 
> place for that.
> [...]


------------------  Misc  ------------------

> From watstar@sail.uwaterloo.ca Wed Sep  4 17:15:53 1991
> From: WATSTAR at UW <watstar@sail>
> Reply-To: erick@development.watstar.uwaterloo
> 
>[...]
> There are two more:
>    UNIX's remote tape protocol (RMT?) which is a very limited random access
>    system.  Only one file at a time, but its random access makes it more
>    useful than ftp at times.
> 
>    Andy Taunenbaum & Co. at the Free (Vrie) University in Holland have designed
>    the bullet server which runs on their amoeba protocols.  Typical network
>    disk throughputs of about 600Kbytes/s was their claim about two years ago.
>    That is roughly four times typical NFS, eh?
>    The amoeba system is very popular in Europe.
> 
> Erick 


> From forsyth@minster.york.ac.uk Thu Sep  5 06:39:18 1991
> Subject: file system protocols
> 
> the 10th edition's file system protocol is described in volume 2
> of the UNIX Programmer's Manual (10th Edition),
> which has been published as a book by Saunders College Publishing.
> it is interesting because it is relatively straightforward.
> it is worth looking up the articles by L Marshall about the
> Newcastle Connection.
> a decent one should take less than 1000 lines of C at each end!
> the Newcastle Connection takes more because it does more
> (it distributes all unix system calls, not just file system operations).
> NFS takes more because .... [your entry here, 30 words or less].


> From droms@sol.bucknell.edu Mon Sep  9 09:36:10 1991
> From: droms@sol.bucknell.edu (Ralph E. Droms)
> Reply-To: droms@bucknell.edu
> 
>    Is there any available documentation on the AFS (Andrew File System)
>    and RFS (??? Remote File System) remote file system protocols?
> 
> I know of a couple - the attached list is extracted from an NFS
> bibliography I've compiled as part of a two-day NFS tutorial.  (Sorry
> for the LaTeX format.)  BTW, RFS == "Remote File Sharing".
> 
> - Ralph Droms                 Computer Science Department
>   droms@bucknell.edu          323 Dana Engineering
>                               Bucknell University
>   (717) 524-1145              Lewisburg, PA 17837
> 
> -----
> \section{AFS (Vice--Virtue)}
> 
> \begin{itemize}
> 
> \item Morris, J. H., M. Satyanarayanan, M. H. Conner, J. H. Howard, D.
> S. H. Rosenthal and F. D. Smith, Andrew: a distributed personal
> computing environment, {\em Comm. of the ACM 29} 3, (March 1986), 184--201.
> 
> Describes the Andrew computing environment, including the VICE--VIRTUE
> file system, the Andrew window system and Andrew support for
> distributed applications.
> 
> \item Satyanarayanan, M., J. H. Howard, D. A. Nichols, R. N.
> Sidebotham, A. Z. Spector, M. J. West, The ITC distributed file
> system: prinicples and design, {\em Proc. of the 10th ACM Symp. on Op.
> Sys. Prin.} (Dec. 1--4 1982), 35--30.
> 
> Details the architecture and implementation of the VICE--VIRTUE file
> system.
> 
> \item Howard, J. H., M. Kazar, S. G. Menees, D. A. Nichols, M.
> Satyanarayanan, R. N. Sidebotham, M. J. West, Scale and performance in
> a distributed file system, {\em ACM Trans. on Comp. Sys.  6} 1 (Feb.
> 1988), 51--81. 
> 
> Compares the performance of VICE--VIRTUE and NFS.
> 
> \item Satyanarayanan, M., Integrating security in a large distributed
> system, {\em ACM Trans. on Comp. Sys. 7} 3 (August 1989), 247--280.
> 
> Describes the integration of identification, verification and
> encryption in the VICE--VIRTUE file system.
> 
> \end{itemize}
> 
> \section{RFS}
> 
> \begin{itemize}
> 
> \item Rifkin, A. P., M. P. Forbes, R. L. Hamilton, M. Sabrio, S. Shah
> and K. Yueh, RFS architectural overview, {\em Proc. of the Summer 1986
> USENIX Conf.}, 248--259.
> 
> Describes AT\&T's RFS, with details of the implementation and the
> mechanisms with which RFS preserves \unix\ semantics.
> 
> \item Bach, M. J., M. W. Luppi, A. S. Melamed and K. Yueh, A
> remote--file cache for RFS, {\em Proc. of the Summer 1987 USENIX
> Conf.}, 273--279.
> 
> Illustrates the use of caching to improve the performance of RFS.
> 
> \item Harris, D., Remote File System, in {\em \unix\ Networking}, S. G.
> Kochan and P. H. Wood, eds., Hayden Books, Indianapolis, IN, 1989,
> 203--236.
> 
> An overview of RFS.
> 
> \end{itemize}

[ A much more complete and readable version of this bibliography has been
  made available by its author via anonymous FTP from nri.reston.va.us
  in rdroms/{nfs-biblio.txt , nfs-biblio.PS} (latter file is in PostScript
  format).  It covers many areas of distributed file systems, and includes
  comments on the references too.  -MEG ]


> From gdmr@dcs.edinburgh.ac.uk Fri Sep  6 04:45:38 1991
> 
> FTAM?  (The ISODE version, for example.)


[ The following was useful when looking for references in USENIX
  proceedings (just grep through the bibliography file)...  -MEG ]

> From andrea@usenix.org Fri Sep  6 16:51:48 1991
> From: andrea@usenix.org (Andrea Galleni)
> Subject: Re:  Online Usenix proceedings?
> 
>                 USENIX Online Library/Index
> What Is It:
>      The USENIX online index is an electronically  available
>      list  of papers published by the USENIX Association and
>      related groups.  The index is kept as  a  simple  ASCII
>      file,  in  refer/bib format, sorted by author, and con-
>      tains information  about  papers  published  in  USENIX
>      conference and workshop proceedings, newsletters, jour-
>      nal, and the like.
> 
> How to Get the Index [200k long!]:
> 
>              echo send bibliography | mail uunet!library
> 
>      Or, via anonymous ftp to uunet.uu.net:
> 
>              ftp> get library/bibliography


-Marc
-- 
Marc E. Gauthier   megauthier@watcgl.waterloo.edu
Computer Graphics Lab, University of Waterloo  [129.97.140.64]  +1 519 888 4548

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 21:49:29 GMT
From:      schmidt@net4.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   obtaining the maximum UDP packet size


Hi,

	I'm curious to know if there is any portable way to determine
the largest packet size devliverable via UDP (other than just
experimenting until it fails ;-)).  I notice that in rfc 1122, in
section 4.1.4 it says:

----------------------------------------
4.1.4  UDP/APPLICATION LAYER INTERFACE

The application interface to UDP MUST provide the full services of the
IP/transport interface described in Section 3.4 of this document.
Thus, an application using UDP needs the functions of the
GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and RECV_ICMP()
calls described in Section 3.4.  For example, GET_MAXSIZES() can be
used to learn the effective maximum UDP maximum datagram size for a
particular {interface,remote host,TOS} triplet.
----------------------------------------

	It doesn't seem that any of the socket options available via
getsockopt return this informtion.  Can someone tell me how to obtain
this info?  For example, it appears that Sun OS 4.x has a limit of
around 8k bytes, but that number doesn't seem to appear in any header
files.

	thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | (schmidt@ics.uci.edu)
And say to all the world: "This was a man."         | (714) 856-4101
   -- In loving memory of Terry Williams (1971-1991)|

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 22:12:45 GMT
From:      olinger@halley.est.3m.com (Randy M. Olinger)
To:        comp.protocols.tcp-ip
Subject:   DecNet Version of RCPGEN

Is there an easy to port client-server programs built using RPCGEN
to a VAX that has TCP/IP??  I have a simple pserver rogram that accesses a
database on unix and returns the result to a client program.  I would
like to have the client running on several hardware platforms, and so
far all the UNIX platforms have been no problem (HP, Sun, Ultrix).  I
do not want to make the VAX's in our department (or company)
outcasts...

I also don't want to go and learn all the low-level pipe type stuff,
but may have to.

Any help would be appreciated

--
Randy M Olinger

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 91 23:07:10 GMT
From:      schoff@uu.psi.com (Martin Schoffstall)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Wireless network connections?

There are a few purveyors of WideArea Wireless networking also, which
are appropriate to the laptop mobile environment; however, the bandwidth
is less than 56kbps and user software is nearly non-existant, this is
about to change.

Marty

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 13:17:37 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Is MX-ing the domain-name legal?

From article <1991Sep27.183446.27144@sics.se>, by craig@sics.se (Craig Partridge):
 In <1081@giga.slc.unisys.com> markb@giga.slc.unisys.com (Mark Baranowski) writes:
>Is it legal to have an MX record so that mail can be sent to the
>domain name rather than to a specific host?  For example:
 
>    sub.domain.edu.     IN      MX     20   host2.sub.domain.edu.

I hope so, because that's what I do here.  The intent is to allow our
users to advertised email addresses which contain only the domain name,
a logical entity which remains stable over time, rather than email addresses
containing the names of particular machines (short term entities which
change over time).

When the machine to which the domain is mx-ed is retired, you just change
the mx record in your dns info.

(Of course, it might require a bit of messing around to make sure that
mail gets routed to the correct machines for particular users...)

--
Paul DuBois
dubois@primate.wisc.edu

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 13:51:59 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

The big difference (IMHO) is that 95% of the applications today are
written to the socket interface, and 5% use TLI.  I keep looking for
people using TLI outside of AT&T and there don't seem to be many.
Sun/AT&T helped solidify this with their abysmal implementation of
TLI in SunOS 4.1 (and their statement that all new applications
were supposed to written to TLI).  Berkeley also helped solidify
this with their implementation of the OSI protocols in 4.3BSD Reno
with few changes required to the socket interface.  (As I recall,
circa 1986 AT&T's reason for developing TLI was that sockets
wouldn't be usable with OSI.)

Regardless, it appears both will be around as the POSIX 1003.12
working group is recommending both as part of their DNI.

As a matter of interest, is anyone aware of any Unix or non-Unix
systems other than System V derivatives and SunOS that provide TLI?

	Rich Stevens  (rstevens@noao.edu)

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 22:27:55 GMT
From:      revco@REVCO.MED.YALE.EDU (Jim Revkin)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

please unsubscribe me from the tcp-ip mailing list.
i never realized how much correspondence would be involved.

thanks,


jim revkin aka

revco@revco.med.yale.edu

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 91 22:38:34 GMT
From:      mshiels@TMSoftware.ca (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   socket interface to X.25 or NetBIOS?

Are there any unix machines out there which implement a socket interface
to X.25 and/or NetBIOS.  With the advent of LAN Manager and better access
to the lower layers of Ethernet it seems possible for Unix manufacturers
to implement NetBIOS protocols for unix.  Just thought I'd check what's
-- 
---

Michael A. Shiels                           | mshiels@masnet.uucp
MaS Network Software and Consulting         | mshiels@tmsoftware.ca

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 07:00:55 GMT
From:      jt@mentat.com (Jerry Toporek)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

In article <1991Sep28.135159.720@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>
>As a matter of interest, is anyone aware of any Unix or non-Unix
>systems other than System V derivatives and SunOS that provide TLI?
>

Yes.  OSF/1 and Netware 386 include TLI libraries based on the Mentat version.

Digital supplies an XTI (over sockets) library with Ultrix. (XTI is a superset
of TLI defined by X/Open.)

OSF/1 also includes an XTI Streams interface to sockets-based protocols (known
as XTISO).

There are several others that may not be publicly announced yet that will be
available real soon now.

-- 
Jerry Toporek ========================  `` ''  ===============================
jt@mentat.com                          < @ @ >      Mentat Inc.
uunet!mentat.com!jt                     ( > )       1145 Gayley Ave, Suite 315
(213)208-2650 Ext-24                     \~/        Los Angeles, CA 90024

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 15:15:59 GMT
From:      geoff@vindaloo.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Interested in TLI interface VS Berkely Sockets

Quoth rstevens@noao.edu (W. Richard Stevens) (in <1991Sep28.135159.720@noao.edu>):
#As a matter of interest, is anyone aware of any Unix or non-Unix
#systems other than System V derivatives and SunOS that provide TLI?

The PC-NFS Programmer's Toolkit 2.0 (which is shipping but has not
yet been formally announced - >sigh<) includes XTI (X/Open cleaned
up version of TLI) and sockets for DOS.

Geoff

--Geoff Arnold, PC-NFS architect(geoff@East.Sun.COM or geoff.arnold@Sun.COM)--
------------------------------------------------------------------------------
--       Sun Technology Enterprises : PC Networking group                   --
--                (a Sun Microsystems Inc. company)                         --

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 17:48:36 GMT
From:      howard@thumper.bellcore.com (Howard Bussey)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

The SCOPE (and later KRONOS and NOS) operating systems on the CDC 6000
and 7000 series used a circular buffer for I/O.  The control structure
was like:

struct CBUFFER {
 int *first, *in, *out, *limit;
};

first and limit pointed to the first, and 1 past the last "words" in the
buffer (so the size of the buffer is (limit - first)).

in and out pointed to the next available word for writing and reading,
respectively.

in==out implied the buffer was empty. in+1 == out (in the equivalence
class implied by CBUFFER) meant the buffer was full.

The constraints were first <= {in|out} < limit.

This was used to allow a program to read or write data (even
continuously!).  Most of the operating system ran in peripheral
processors (PPs).  When an I/O operation was started, with the CIO
(Combined I/O) service, a PP was allocated to the request.  It would
poll (yes, poll!) the CBUFFER structure.  When (in != out), the PP would
transfer data.  So the CBUFFERs were used for inter-processor
communication.  Actually, the PPs were only 1 processor, which
time-multiplexed itself each microsecond among 10 or 20 different
contexts, resulting in what looked like 10 or 20 individual PPs (each
with 1 microsecond instruction cycle times).

The SCOPE/KRONOS/NOS operating system may have allowed several
simultaneous and independent transfers.  I do know that tape-tape copies
could keep the tapes spinning continuously.

[N.B. IMHO, the 6600 was the first RISC machine! please, discussion
directly to me]

--------------------------------------------------------------
Howard Bussey <howard@thumper.bellcore.com>
Bellcore Room 2P-288/445 South Street/Morristown NJ 07962-1910
voice: +201 829 44 79; fax: +201 829 58 88

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 19:05:11 GMT
From:      wilker@gauss.math.purdue.edu (Clarence Wilkerson)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent


Most interrupt drive io systems for Z80 's in the late 70's used ring bufferes of some kind. I'm
pretty sure the console io on the Heath-Zenith H89 used this, and the Mostek io modules did
also.
Clarence Wilkerson
 

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 91 19:51:03 GMT
From:      sandee@Think.COM (Daan Sandee)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

This in response to Dave Goldblatt's request on the history of circular buffers,
and as comment on Howard Bussey's response.
Note I have set the followup to comp.sys.cdc, so we old CDC hands can go and
wallow in nostalgia without annoying the rest of the universe further.
There's still stuff that I don't know either that Dave would want to know, 
i.e. the real first date, so this is a hint to Dave to keep reading this
newsgroup, as more details may turn up. -- Daan.

In article <882@salt.bellcore.com>, howard@thumper.bellcore.com (Howard Bussey) writes:
|> The SCOPE (and later KRONOS and NOS) operating systems on the CDC 6000
|> and 7000 series used a circular buffer for I/O.  The control structure
|> was like:
|> 
|> struct CBUFFER {
|>  int *first, *in, *out, *limit;
|> };
 [ excellent description deleted ]

|>  ..............  Actually, the PPs were only 1 processor, which
|> time-multiplexed itself each microsecond among 10 or 20 different
|> contexts, resulting in what looked like 10 or 20 individual PPs (each
|> with 1 microsecond instruction cycle times).

 (not quite relevant, and not quite correct either. With 20 PPs, there were
*two* PP chassis each acting as 10 logical PPs in a slot-and-barrel
arrangement. Only the 6000 series ; don't know about 7000 series ; Cyber 70's
were the same but optionally had 7 PPs per chassis ; Cyber 170s from Model D
onwards had real hardware individual PPs).

|> The SCOPE/KRONOS/NOS operating system ....
  Well, there's SCOPE, later known as NOS/BE ; and KRONOS, later known as
  NOS. That's two operating systems.
  The fact that both Scope and Kronos had circular buffers means that the
  feature must be *very* old. After 1970, they weren't talking to each other.
  In fact, lots of the Scope and Kronos development consisted of the two sides
  (re)inventing the same wheels, though in a different order.

|>   ..... may have allowed several
|> simultaneous and independent transfers.  I do know that tape-tape copies
|> could keep the tapes spinning continuously.

At least in SCOPE, the CPU-resident program could set up TWO of these structs
(called File Environment Tables, or FETs), one for reading, one for writing,
using the same buffer, then fire up one PP for reading and one for writing.
The read PP would move the IN pointer, and the write PP would move the OUT
pointer, and the CPU program could sit back and watch. This mechanism was known
as pointer chasing. In this manner a tape-to-tape copy would proceed at full
tape speed. If there was a hitch (say, error recovery on read) the write PP
would find the buffer empty and give up. The CPU program would regain control,
wait for data to be available, and fire up the write PP again.

|> --------------------------------------------------------------
|> Howard Bussey <howard@thumper.bellcore.com>

Dave's original request was for any code before Oct 81. Well, I can find code
which I *think* I wrote around 1976. But the basic principle was in CDC
operating systems *at least* in the very early 1970's. Before my time, anyway.
I first heard of this method in late 1973. (I wonder, do I still have the
SCOPE 3.4 Handbook, dated 1972 or 1973, which describes this?)
Is Greg Mansfield out there ? or Dave Cahlander ? Or Seymour Cray, for that
matter : I don't think he invented it, but I'm sure he knows who did.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 00:25:08 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: zero windows & probes (was - Re: TCP FIN and window)


    >1) In a modern TCP, the receiver window will never be o unless the
    >   destination device is slower than the network link.

    Destination devices slower than networks are quite common.  I just
    tried an experiment on a Sun 4/370 with fddi & a SCSI disk.  I sent
    800 KB from a faster machine to the 4/370, which was writing the data to
    its SCSI disk.  A 0 window occurred 4 times during the transfer.

    Please don't consider a 0 window an "unusual" event, or one that only
    happens with very slow devices.

I'm not (I work on terminal servers all the time, and network interfaces are
certainly getting to the point that they can be faster than disks.)  In a
sense, this is EXACTLY the point I'm trying to make.  Doing 0 window probes
based on network RTTs does not really make any sense at all.  What you
really need to know is how long before the window SHOULD open again (which
is dependent on the IO device), and NOT on how long it should take to get
a repsonse back (which is only dependent on the network (in theory, anyway.))

    > 4) Probes are a failsafe technique for recovering from am ACK that would
    >    open the window being lost.  Lost packets are rare.

    Maybe not that uncommon in wide-area networks.  I think starting with
    a fairly fast "zero-window" probe is a good idea.  Perhaps RFC 1122's
    suggestion of 1 RTT is a bit quick, but the 5 seconds in Berkeley is
    definitely too long.

Even in WANs, dropped packets are relatively rare.  5 seconds is probaly
too long (there are applications that would take 5 seconds to get rid of
a (1500 byte) packet, but they are pretty rare, and even a small system
can probably put up with a probe more often than every 5 seconds).  Before
it gets changed, I'd like to see statistics on how often that time has to
go off to illicit a window update that was lost...

BillW
-------

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 02:04:39 GMT
From:      rvp@surf.sics.bu.oz.au (Rey V. Paulo)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco router performance (was selecting a fast ethernet card).

We are installing a new MAC running A/UX.  It is connected to one subnet
in our class B network.  After the installation, it appears that the new
host doesn't understand subnetworking.  For instance, I can run telnet,ping,
etc. to any other host in the same subnet but all hosts outside the subnet
are unreachable.  Has anyone encountered similar problems?  I would 
appreciate any help or suggestion.

Many thanks.
-- 
Rey V. Paulo                  | Internet:  rvp@surf.sics.bu.oz.au
Bond University               | I am not bound to please thee with my answer. 
AUSTRALIA                     |         -Shylock, in "The Merchant of Venice" 
------------------------------+----------------------------------------------

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 04:56:22 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: socket interface to X.25 or NetBIOS?

In article <mf-13g5xj@tmsoft>, mshiels@TMSoftware.ca (Michael A. Shiels) wrote:
>Are there any unix machines out there which implement a socket interface
>to X.25 and/or NetBIOS.

The UBC X.25 support for BSD/SunOS had a socket interface, and
since the 4.4 BSD X.25 support is based on that, it should have
it as well.

...Sam
-- 
<skl@cs.sfu.ca>

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 10:38:41 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Speed of memory and fast networks (was: Need help selecting Enet cards)

BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>    The argument put forth by my colleague is that memory speed on
>    most computers is so slow that, when using a protocol like TCP
>    which typically (most common implementations) touches memory at
>    least three times (DMA into memory and copy from kernel to user
>    space - I didn't count the checksum), high data rates to the
>    application just aren't possible.
 
>This assumes that the DMA into memory and the kernel to user copy
>take their bytes from the same chunk of memory bandwidth.  One would
>hope that any architecture designed for high I/O bandwidth would be
>able to do a lot of I/O into memory without having any effect on the
>processor's access to memory.
 
>    For example, we measured the memory speed of a Vax 6310 at
>    around 8 MBytes/sec.  If memory is touched three times for a
>    TCP connection, that means a maximum possible data rate of less
>    than 3 MBytes/sec.  So even if we have a HiPPI connection on
>    this machine, we aren't going to do any better than 3 MB/sec.
 
>The number is suspicious (it works out to 1 (32 bit) memory transfer
>every 500 nS.  While this might be typical for transfering data over a
>bus (an old bus, anyway), but sounds way wrong for "integrated" memory.
>Maybe the bcopy that you are using needs improving...

It sure looks like it. Look at this sheet posted at comp.benchmarks:
}Newsgroups: comp.benchmarks,comp.arch
}Subject: Attainable memory bandwidth
}Message-ID: <MCCALPIN.91Sep27212326@pereland.cms.udel.edu>
}Date: 28 Sep 91 01:23:26 GMT
}Sender: usenet@ee.udel.edu
}Organization: College of Marine Studies, U. Del.
}
}==========================================================
}Memory Transfer Rates in MB/s for Standard Fortran Kernels
}==========================================================
}John D. McCalpin			September 24, 1991
}mccalpin@perelandra.cms.udel.edu	DELOCN::MCCALPIN
}
}The following table presents the results of a simple test of the
}memory bandwidth of a computer running some simple vector kernels
}coded in Fortran.  In each case, only the memory transfer rate in
}Millions of Bytes per second (MB/s) is shown.
}
}Machine		Copy	Scale	Sum	SAXPY
}------------------------------------------------------
}IBM RS/6000-950	190.5	163.3	184.6	187.5
}IBM RS/6000-530	145.5    88.9   109.1   120.0
}IBM RS/6000-320	 58.2	 55.7	 60.0	 60.0
}SGI 4D/240		 35.6	 22.1	 34.9	 25.6
}DEC 5000		 25.9	 25.6	 23.1	 21.8
}Sun 4/490		 25.0	 16.7	 24.0	 19.4
}Sun SS1+		 28.6	 12.3	 25.5	 13.3
}SGI 4D/25		 23.7	 11.6	 17.8	 13.7
}Sun SS1		 24.6	  9.3	 24.0	  9.6
}------------------------------------------------------
}
}The test shows how well the memory system can move large (uncacheable)
}contiguous arrays around and how much the work of FP operations can be
}overlapped with the waits on cache misses.  The results on the latter
}range from superb (IBM 320) to awful (Sun SS1).
}
}Fortran code ommitted.
}--
}John D. McCalpin			mccalpin@perelandra.cms.udel.edu
}Assistant Professor			mccalpin@brahms.udel.edu
}College of Marine Studies, U. Del.	DELOCN::MCCALPIN (SPAN)

This shows that advanced machines can easily produce a data stream 
of 50Mbytes/sec or more. The other reason for research on high speed
networks is that there is also research on high speed memory.

>I would also claim that if the bandwidth one gets from their network is
>the same as the bandwidth that one gets from their memory, then this IS
>a "high data rate to the application").  One might as well claim that
>gigabit networks are useless because they are faster than any existing
>disk drives, so what would be the point during FTPs.
 
>In fact, I'd go so far as to say that the entire point of very high speed
>networking is to remove the distintion between remote and local data.
This is exactly the ultimate goal. (IMHO)
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 14:53:58 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Using Wide-Area Point-to-Point Links for Computer Networking (I)

Having looked over the slide and slither "rfcs", and the
assoicated mail, I have cleverly decided to stay out of the
philosophical discussion. However, there are a few mis-statements
of "facts" that I feel compelled to respond to....

Firstly, the idea of using (essentially) the ethernet encapsulation on
serial line is tempting.  No need to write a new RFC for each new protocol,
potentially better error checking, shared device driver code.  So you
waste a few header bytes - it's a high speed line, it doesn't matter much.
Ethernet has been areound for a while now, and everyone is familiar with it.


    1) There is good evidence to believe that PPP is going to be
       incompatible with the latest generation of serial chips which support
       ether modes and with the latest generation of ether chips which
       support serial modes.

       ...if the serial chip has an interface to the host processor which
       looks like the interface to a common ethernet chip, or if in fact
       common ethernet chips can be programmed to do hdlc bit stuffing,
       software development is a lot cheaper if the changing one or two lines
       of the initialization code of the ethernet driver is sufficient to
       turn the ethernet driver into a serial hdlc driver.

A) The fact that some ether/serial chips are capable of supporting both
   formats does not make PPP "incompatible" with these chips.
B) Defining "standards" based on available chips is backwards, sort of.
C) I count only 1 (one) more chip familly supporting both (The Zilog).
   The last generation of Intel chips (in fact, the 82586 was the first
   second generation ethernet chip available) also supported many modes.
   The AMD ILLAC does NOT support serial modes according to the latest
   documentation I've seen.
D) The interface device driver is such a small portion of the software
   that makes up a modern multi-protocol multi-media bridge/router that
   the cost savings of having a "single driver" are pretty small.
E) Those savings are offset by the overhead and difficulty of providing
   unnecessary protocols for the serial line (eg ARP).
F) And it still doesn't help all those interfaces that are neither
   HDLC nor EtherNet (TR, FDDI, T3, ULtraNet, ISDN, ATM, etc...)
G) No matter how hard one tries to pretend otherwise, a serial PtoP
   link is NOT an ethernet.  Trying to treat it like one is probably
   not a very good idea.


    2) Only the bridging version of PPP contains sufficient information
       that sophisticated mesh topologies of serial links can be supported.
       Such mesh topologies are often desirable when seeking high reliability
       and availability in a network.

I'm sure the router vendors who have been offering boxes that support
"sophisticated mesh topologies" for the last 5 years will be surprised
to hear this.  Or did you mean "only the bridging version of PPP contains
sufficient information to to bridging"?


    3) Unfortunately, the bridging version of PPP contains variable length
       goop in front of the MAC packet.  Many microprocessors, like the AM29k
       or IBM ROMP (used in the RT/PC) have no real capabilities for dealing
       with multiple allignments of data.  The Intel 80x86 microprocessors
       can handle multiple allignments of data, but will produce much lower
       performance when doing so.

I re-read the RFC, because I didn't believe that Fred Baker (with the IETF
looking over his shoulder) would do anything this stupid, and I was right.
It looks to me like for an equivilent configuration, the PPP bridging spec
"factors" out to a fixed packet format:

A) There is an optional "LAN ID" word.  I'd assume that this is either
   there on essentially all packets, or never, in a particular network.
   In any case, it's 32 bits long, so it doesn't affect alignment.
B) If you are bridging either 802.4 or 802.5, you can get packets with
   another 16 bits of "stuff" in them.  I don't think that you can both
   types of packets on the same link (otherwise SRT or 8209 style symantics
   would come into play, converting the packets to one form or ther other).
   Even if you could, I don't see how this would affect overall speed.  Since
   you have to do table lookups of both source and destination "ethernet"
   addresses, one of them is never aligned on 32 bit boundries...


    4) PPP is too complex in other ways (primarilly the link control protocol)

This is probably true, although it is not too difficult to implement the
"minimal subset" of PPP.  All during the period that PPP was being defined
(two years!), there were occasional talks amoung router vendors about
bypassing "all that async-oriented" stuff and coming out with a de-facto
industry standard based on someone's (anyone's!) existing sync spec.  But
we didn't...  You can always get stuck like the rest of us - run PPP when
you need to talk to another vendor, and your own protocol when that won't
work for some reason.

BillW
-------

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:16:52 GMT
From:      I.Wakeman@cs.ucl.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: Distributed file systems and TCP

O
 Krishnakumar K. writes in response to the question without attribution:
 >>
 >>    Why don't all distributed filesystems simply use TCP/IP for data
 >>    communication?
 >>
 >
 >Overhead"!
 >It is quite clear that distributed file systems can live very well
 >without TCP. In most cases (if not all) the reply to the file system
 >call acts as the acknowledgement also and this renders the specific ack
 >to the call as required by TCP unnecessary. In most distributed file 
 >systems completion of the call is the responsibility of the client and
 >so the client can always make an extra call in case of a lost reply.
 >Things being so, I feel that distributed systems are well off without TCP
 >and the extra traffic.

I  agree with you (up to a point) when you're running a filesystem over an
archetypal, high speed, low error rate, local area network; but if
you're running a file system distributed over a wide area network, all
the assumptions about the operating environment change, and a whole new
set of network algorithms have to be used, especially to look after
congestion problems. Whilst it is possible to build the mechanisms to
cope with WANs into your transaction mechanism over UDP, you only end up
reproducing the functionality of a reliable transport protocol such as
TCP. So, since if you're putting a file system over a high latency
network one ought to be doing some form of file caching (a reason for
ditching NFS and moving to something more sensible like AFS), which
requires bulk transport anyway, go for a reliable tranport protocol in
the first place - its a win in the long run.

 >
 >>With any luck, we and Interstream (at least) will be demonstrating NFS over
 >>TCP at Interop.
 >>
 >Isn't NFS good enough with just UDP?

Over a congested WAN - No. 
 >
 >Krishnakumar K.	
 >dept. of CS
 >SUNY Albany
 >
 >email: krishna@cs.albany.edu
 >

ian

Ian Wakeman                                       +44 71 387 7050 ext 3706
Internet: I.Wakeman@cs.ucl.ac.uk    UUCP: ...!{uunet,ukc}!ucl-cs!I.Wakeman
Computer Science, University College London, Gower Street, LONDON WC1E 6BT

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:45:14 GMT
From:      tar@math.ksu.edu (Tim Ramsey)
To:        alt.sys.sun,comp.protocols.tcp-ip
Subject:   whois and SunOS 4.1.1

hilbert% uname -a
SunOS hilbert 4.1.1 3 sun4

hilbert% whois \!tar13

When we understand knowledge-based systems, it will be as before --
except our fingertips will have been singed.
		-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
----------------------------------------------------------------------
Hi!  You have attempted to contact a whois server at SRI-NIC.ARPA.
Your WHOIS client program is either extremely old or your software
vendor is really out of it.  Please complain to them.
To contact the current DDN NIC WHOIS server, it will be
necessary to either: 	

	a) Use a command-line option to tell your WHOIS client 
           to connect to a different host (NIC.DDN.MIL),

	b) Or, recompile WHOIS with the CORRECT name for the DDN NIC,
           NIC.DDN.MIL, in place of the ancient SRI-NIC.ARPA.

For further information about the DDN NIC, please contact the new
contractor, GSI, at 1-800-365-3642.  Thank You.
--------------------------------------------------------[caw 91/09/24]

I guess it's official.  Sun is really out of it.  :-)

(time to recompile whois)

--
Tim Ramsey/system administrator/tar@math.ksu.edu/(913) 532-6750/2-7004 (FAX)
Department of Mathematics, Kansas State University, Manhattan KS  66506-2602

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 15:54:32 GMT
From:      solomon@becks.comm.mot.com (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   PD Implementation of TCP/IP



Greetings:

Does anyone know of any source code for TCP/IP available via anonymous FTP?  I
am aware of the BSD4.3 code on uunet.uu.net but I'm looking for something that
has more comments (yes, I ask the world ;-) and is not meant to be part of
the kernel.  Please send Email and I'll summarize if there is significant
interest.

Gracias,
--
Jim Solomon (solomon@becks.comm.mot.com)

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 16:12:06 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re: MVS-TCP/IP



>From: sbi!pivot-sts!cassidy!dxe@uunet.uu.net  (Dan Ellsweig - Network planning)
>Subject: MVS-TCP/IP
>Message-Id: <540@pivot-sts.sbi.com>
>To: tcp-ip@nic.ddn.mil
>Status: R


>Greetings fellow netters.....


>We here at Salomon Brothers have begun to investigate the offerings
>by IBM which place IBM at the fringe of the distributed processing 
>environment as we know it. Specifically, the offering which opens
>the entire IBM product line by allowing TCP/IP interconnect.
>
>I am wondering if there are network users out there who may have
>specific experience ( good and bad ) in using the IBM TCP/IP
>products - MVS-TCP/IP in particular. 
>
>We are interested in using the FTP, NFS, SNMP, Mail and MVS socket
>libraries. All input is welcome!!!!!!
>
>In addition, any information regarding future products such as 
>the CICS-TCP/IP interface or information on IMS access via TCP/IP
>would be welcome.


Interlink Computer Sciences markets SNS/TCPaccess for MVS.  It
contains FTP, SMTP, Sockets, etc.  SNS/NFS is also available
for NFS support.

Please contact me directly for information on CICS and IMS interfaces.

Please contact headquarters in Fremont, CA. at 510-657-9800 and
ask for sales.
------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 19:05:15 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.sys.ibm.pc.misc
Subject:   Re: Using "mount" and SOSS

kxb@math.ksu.edu (Karl R. Buck) writes:
>How can I allow a certain user (or failing that anyone from a certain client) 
>to be able to mount a file system on SOSS?

If you're running a name server (named) somewhere on your LAN, you can
specify a list of up to 50 client names separated by spaces after the
names of filesystems.  Make sure NETDEV is configured with the IP
address of at least one name server.

SOSS doesn't directly support this for sites which don't run a name
server.  It relies on PC/IP, which might support some form of host
file but I'm not sure what it would be.  So: run a name server if you
want to use this.  Always a good idea in any event; I hate updating
hostname files.

I didn't know the NFS protocol allows for specifying a list of allowed or
disallowed user-names for mount requests.  Does it?

-rich

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 20:01:28 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Sanity check on network configuration

I'd like to bounce this idea I have off the net.community before I go in
and recommend something that I'll wind up having to undo later.  We're about
to renumber our internal TCP/IP LAN so it'll conform to the "real"
Internet if and when it gets connected.

First, a simplified diagram of our in-house net:

	+----+-----+-----+------+-----+   ---X~~~~~~(The Great Beyond)
	A    B     C     D      E     F
	|    |           |      |
	+G   +H          +I     +J
	+K               +L     +M
			 +N

Boxes A through F are on the backbone.  C and F only have one Ethernet
interface; A, B, D, and E each have two Ethernet interfaces and run IP
routing.  This second interface is hooked up to a subnet (mostly of
DOS PC's running CUTCP).  Eventually box X (a router of some sort)
will connect the backbone with the Internet At Large.

Right now, every system in the whole LAN is set up with a 24-bit subnet
mask (24 bits of address, 8 bits of host number).  Because I can guarantee
that each subnet won't ever have more than 62 nodes, I'm thinking of
switching to a 26-bit subnet mask (6 bits for the host number) for the
subnets while keeping a 24-bit (Class C) subnet mask for the backbone.

Is this the most sensible way of setting things up, so as to avoid
having to go out and get another Class C network number every time we
add a router to the network?  (We'd have plenty of expansion space if
we could put 4 routers into each Class C network.)  Am I right to assume
that I need to have a unique "network number" for each router interface
card?

My thinking on this is a wee bit foggy and there's no one else here to ask.

-rich

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 20:08:24 GMT
From:      gooey@helix.nih.gov (Sean Graham)
To:        comp.protocols.tcp-ip
Subject:   WD8013EP Packet Driver Question...


	I was wondering if someone can tell me if the current packet
	driver "WD8003E.COM   6535  03-28-91" supports the WD8013EP
	card.  It's the Ethercard PLUS Elite16.  If not, could someone
	point me in the direction of a driver that would support it?

	Email if you can.

	Thanks in advance..

	Sean

--
|| Sean N. Graham                 NIH               DoD# 601  AMA# 601894  ||
|| '91 GSX600FM | '85 RX-7    Bethesda, Md          gooey@helix.nih.gov    ||
|| "This is a test of the Emergency Broadcasting System.  This is just a   ||
|| test.  In the event of a real emergency you would most likely be dead." ||  

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 21:01:14 GMT
From:      phil@brahms.amd.com (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   all these unsubscribe requests

Looks like they're all coming via UCBVAX. Anyone
wanna beat on their postmaster?

--
This posting is purely a personal opinion.

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 21:02:49 GMT
From:      shj@ultra.com (Steve Jay)
To:        comp.dcom.lans,comp.dcom.modems,comp.lang.c,comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.unix.wizards,comp.sys.cdc,comp.sys.prime,comp.sys.ibm.pc.hardware
Subject:   Re: Help Requested in Defeating Ring Buffer Software Patent

In <1991Sep29.195103.18362@Think.COM> sandee@Think.COM (Daan Sandee) writes:

>Dave's original request was for any code before Oct 81. Well, I can find code
>which I *think* I wrote around 1976. But the basic principle was in CDC
>operating systems *at least* in the very early 1970's. Before my time, anyway.
>I first heard of this method in late 1973. (I wonder, do I still have the
>SCOPE 3.4 Handbook, dated 1972 or 1973, which describes this?)
>Is Greg Mansfield out there ? or Dave Cahlander ? Or Seymour Cray, for that
>matter : I don't think he invented it, but I'm sure he knows who did.

The "Circular I/O" technique being discussed here was in the original COS
(Chippewa Operating System) for the 6600 in 1964.   It is described in
the COS Reference Manual.  If someone's life depends on it, I know where
I can get a copy of that manual.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 22:08:48 GMT
From:      hwajin@omni.com (Hwa-Jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: obtaining the maximum UDP packet size

In article <28E3A769.20571@ics.uci.edu> schmidt@ics.uci.edu (Douglas C. Schmidt) writes:
>	It doesn't seem that any of the socket options available via
>getsockopt return this informtion.  Can someone tell me how to obtain
>this info?  For example, it appears that Sun OS 4.x has a limit of
>around 8k bytes, but that number doesn't seem to appear in any header
>files.

SunOS uses default udp_sendsize of 9K which is used to allocate socket
level buffers for each socket opened by users.  BTW, 9K for sending
side -- for NFS traffic (8K + some extra stuff).  Applications are
restricted by this "send" size because UDP is datagram service.  If you
want to send larger packets you'll need to use setsockopt SO_SNDBUF.
To get the currently available maximum UDP packet size you can use in
your application, use getsockopt SO_SNDBUF.

*hwajin

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 91 22:46:24 GMT
From:      jonson@SERVER.AF.MIL (1Lt Matthew W. Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Why can't my clients talk to another subnet?

<Mike Black writes>
> Subject: Why can't my clients talk to another subnet?
> Message-Id: <49983@seismo.CSS.GOV>
> 
> I have read as much material as is on the net and have succeeded
> (somewhat) in implementing subnetting on our buildings Sun workstations.
> Here's an example of our setup:
> 
> 22.19.4.1 (255.255.255.0) --------  22.19.6.1 (255.255.255.0)
>   |                                   |
 Host1                               Host2
>   |
 192.9.201.1 (255.255.255.0)
>   |
> 192.9.201.2 Client1
> 192.9.201.3 Client2
> 
> The Clients here cannot ping,ftp, or telnet to Host2.  Host2 also
> cannot ping,ftp, or telnet to the clients.  Note that a route has
> been added thusly:
> On Host1: route add net 22.19.6.0 Host1 0
> On Host2: route add net 22.19.4.0 Host2 0
>
If the clients have a 
route add default 192.9.201.1 1
statement they will try to send all their non-local packets to host1 for
forwarding.  You could also run your net 22 as a Class B sized net and then
you wouldn't need the two route commands you mentioned above (use a netmask
of 255.255.0.0).

One other thing worth pointing out is that net 22 is in actuality owned by
Defense Information Systems Agency and is used on what is known as DSNET1 which
is our lowest (classification level) classified network.  Although net 22 may
never be connected to the Internet, it is allocated.  If you have any plans to
connect this network you are working on to the Internet, you need to make sure
you have requested and received valid unused net numbers from the NIC...

 
/matt
-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

Any opinions expressed herein are my own and NOT the property of the USAF.

END OF DOCUMENT