HDTenEightyP/NetNews huggingface dataset:
From: art@acc.com (Art Berggreen)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 27 Jul 92 17:26:41 GMT
Organization: ACC, Advanced Computer Communications

In article <nqqtk74@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Depending on what you mean by FDDI-bridging-hubs, there is the problem
>of bridging FDDI to ethernet.
>Some FDDI-ether bridges are junk, because they do not do the necessary
>IP fragmentation of 4K IP/FDDI datagrams.  Think about NFS which
>likes 4K and 8K UDP/IP datagrams.

I won't take sides in this very controversial topic, but will point out
that there are a large number of people that believe IP-fragmenting bridges
are "junk".  The main argument being, that these devices are doing part
of the routing function without doing the rest.

Art
Newsgroups: comp.dcom.lans.fddi
From: pettengill@cvg.enet.dec.com ()
Subject: Re: ANSI standards
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Sat, 25 Jul 92 08:21:58 GMT

In article <3125@ra.nrl.navy.mil>, caress@cmnext.nrl.navy.mil (Peter N Caress) writes:

|>Is there an archive site where the ANSI standards for FDDI reside? 
|>Thanks in advance.

In general, standards are copyrighted, and distribution is limited to sales
thru either the standards body of thru a vendor licensed to distribute them.
This isn't a matter of making profit, but rather a means of making all
standards generally available at a reasonable cost to anyone who needs them,
including those standards of interest to a very small number of people.

While it is probably true that this method of distributing information is
incredibly dated, one must recognize the standards bodies codify the past,
not the future.

mulp
Newsgroups: comp.dcom.lans.fddi
From: curt@mischief.ecn.purdue.edu (Curt Freeland)
Subject: Optical bypass
Keywords: whats available
Organization: Purdue University Engineering Computer Network
Date: 28 Jul 92 18:57:19 GMT

We just began a search for optical bypass hardware for use on an FDDI ring.
If anyone knows of any good units, and pricing, please drop me a line.
I will summarize if interest warrants.

Thanks
--curt

--
Curt Freeland
Manager, Systems Engineering
Purdue University Engineering Computer Network
(curt@ecn.purdue.edu) (317) 494-3715
Newsgroups: comp.dcom.lans.fddi
From: hyder@niwot.scd.ucar.edu (Paul Hyder)
Subject: Query on overdriving short fiber optic links
Organization: Scientific Computing Divison/NCAR Boulder, CO
Date: Wed, 29 Jul 1992 16:18:17 GMT

After three months tracking down a problem with a fiber based Ethernet
that ended up being overdriven fiber connections I'd like to get some
feedback from anyone out there that has or is planning configurations
similar to ours.

This new network used fiber as the major interconnect in preparation for
full scale FDDI and beyond implementation.  Details on request (were
posted in comp.dcom.lans.ethernet), in short we used short fiber runs
(3 to 300ft) to connect between close buildings, between floors, and to
in-room hardware.  We have been seriously impacted by the lack of
published minimum loss/length requriements.  (Overdriven fiber is truly
a nasty debugging chore.)

QUESTIONS:
	1.  Has anyone seen overdriven FDDI?  Is there a minimum
	    loss/length requirement?

	2.  If you have short fiber optic runs that had overdrive noise
	    how did you solve the problems?  Where did you get
	    attenuators? What did your solution cost?

As always TIA.  Email to me please.
	Paul Hyder
	NCAR
	Boulder, CO
Newsgroups: comp.dcom.lans.fddi
From: shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
Subject: Re: benchmark terminology
Organization: Ultra Network Technologies
Date: Thu, 30 Jul 92 23:55:11 GMT

>Now the raw data rate of FDDI being 100 Mbps or 100,000,000 bps.
>If I report N KB/sec does that mean N*1024 bytes/sec or N*1000 bytes/sec.
>If I report N MB/sec does that mean N*1,000,000 bytes/sec
>   or N*1024*1024 bytes/sec or N*1024*1000 bytes/sec.
>Finally, If I can send N bytes in 1 second and wish to report the result
>as Mbps do I report (N*8)/1,000,000 or (N*8)/(1024*1024) or (N*8)/(1024*1000).

>It strikes me that since the raw data rate does not have 1024 factored into it
>anywhere the throughput result shouldn't either.  I have three different versions
>of ttcp here, each does this a different way.  Any opinions?

Our opinion is that all data rates should be reported as multiples of
1000, not 1024.  That is, when we say we get X Mbytes/second, we
mean X * 1000000 bytes, not X * 1048576.

All of the rates that my company talks about, and the rates put out
by our "tsock" program (which is just a hacked up version of ttcp),
follow this rule.

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"
                                       ^^^^^^^
                                       10**9, not 2**30
Newsgroups: comp.dcom.lans.fddi
From: jsims@uswest.com (John Sims)
Subject: benchmark terminology
Organization: U S WEST Advanced Technologies
Date: Wed, 29 Jul 1992 22:49:11 GMT

I'm curious what people feel is the correct way to report FDDI
(or for that matter data comm systems in general) throughput.

Now the raw data rate of FDDI being 100 Mbps or 100,000,000 bps.
If I report N KB/sec does that mean N*1024 bytes/sec or N*1000 bytes/sec.
If I report N MB/sec does that mean N*1,000,000 bytes/sec
   or N*1024*1024 bytes/sec or N*1024*1000 bytes/sec.
Finally, If I can send N bytes in 1 second and wish to report the result
as Mbps do I report (N*8)/1,000,000 or (N*8)/(1024*1024) or (N*8)/(1024*1000).

It strikes me that since the raw data rate does not have 1024 factored into it
anywhere the throughput result shouldn't either.  I have three different versions
of ttcp here, each does this a different way.  Any opinions?


John Sims
U S WEST Advanced Technologies
jsims@advtech.uswest.com
From: art@acc.com (Art Berggreen)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 28 Jul 92 17:54:18 GMT
Organization: ACC, Advanced Computer Communications

In article <nrksjfc@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Well, I think bridges in general are nasty, because I'm of the routing
>faith.  More precisely, bridges and routers/gateways are the same kind
>of boxes, except that bridges are particularly stupid (well, limited)
>routers.

I think philosophically, we're in general agreement.  For Routeable protocols
I much prefer routing.  But I do understand customer desires for simple
plug-'n-play devices.  But I think the success of homogeneous local
bridges has set unrealistic expectations for multimedia bridges.

>IP fragmentation is a trivial bit of work, and far less that all of IP
>routing.

You do save the dynamic routing algorithms, but I'm not convinced that
the forwarding is that much simpler (to be done right).

To do IP fragmentation correctly, it should be able to generate ICMP
errors (if DF is set).  It needs to at least know IP option syntax to
properly copy options to fragments.  To insure that it does those
correctly, it needs to at least partially parse the IP header and
verify the header checksum.  It also obviously needs to know about
IP addresses and be careful about IP and/or media broadcasts.  If it
does generate ICMP, what source address does it use?  Of course it needs
to be able to generate the proper headers with new checksums on the
fragments.  Then there is the question of what is should do about IP
Path Discovery. A translating bridge already has to rewrite MAC headers,
which similar to the effort for an IP router just to add a new MAC header.

>DEC is among the vendors of such more-than-bridges-less-than-routers.
>I think they call their boxes "transparent bridges," like others in
>the industry.

That still doesn't make it good technology.

Art
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 28 Jul 92 05:52:38 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul27.172641.22132@acc.com>, art@acc.com (Art Berggreen) writes:
> In article <nqqtk74@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Depending on what you mean by FDDI-bridging-hubs, there is the problem
> >of bridging FDDI to ethernet.
> >Some FDDI-ether bridges are junk, because they do not do the necessary
> >IP fragmentation of 4K IP/FDDI datagrams.  Think about NFS which
> >likes 4K and 8K UDP/IP datagrams.
> 
> I won't take sides in this very controversial topic, but will point out
> that there are a large number of people that believe IP-fragmenting bridges
> are "junk".  The main argument being, that these devices are doing part
> of the routing function without doing the rest.


Well, I think bridges in general are nasty, because I'm of the routing
faith.  More precisely, bridges and routers/gateways are the same kind
of boxes, except that bridges are particularly stupid (well, limited)
routers.

IP fragmentation is a trivial bit of work, and far less that all of IP
routing.


It is nice to reserve the word "junk" for something that does not
perform its advertised function.  An FDDI-ethernet bridge that does not
fragment 4352 byte IP datagrams is "junk" because your network will not
work.  A box that does only spanning tree "routing" based on MAC
addresses and does IP fragmentation may not be a bridge by some
definitions, and it may be unclean, but it is not "junk."


DEC is among the vendors of such more-than-bridges-less-than-routers.
I think they call their boxes "transparent bridges," like others in
the industry.


Vernon Schryver,  vjs@sgi.com
From: caress@cmnext.nrl.navy.mil (Peter N Caress)
Newsgroups: comp.dcom.lans.fddi
Subject: ANSI standards
Date: 24 Jul 92 15:28:09 GMT
Reply-To: caress@cmnext.nrl.navy.mil

I'm sure this is an FAQ, but I haven't seen anything about it in earlier
postings...

Is there an archive site where the ANSI standards for FDDI reside? 
Thanks in advance.

-- Peter
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 27 Jul 92 15:06:15 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul27.083245.3122@doug.cae.wisc.edu>, wittmann@engr.wisc.edu (art wittmann) writes:
> 
> I'm working on an article that is going to talk about use of hubs on 
> networks that one might design for a relatively heavy duty environment.
> 
> Hub manufacturers are building bridging FDDI interfaces for their hubs,
> however, I'd prefer to recommend routing when possible.  Anyone have 
> any insight into the *right* way to integrate hubs and routers?
> 
> Anyone want to agree or disagree one routing being the preferred method
> for connecting hubs?  The environment that I'm describing would use FDDI
> as a backbone and hubs to distribute token ring and ethernet to end stations.


Depending on what you mean by FDDI-bridging-hubs, there is the problem
of bridging FDDI to ethernet.
Some FDDI-ether bridges are junk, because they do not do the necessary
IP fragmentation of 4K IP/FDDI datagrams.  Think about NFS which
likes 4K and 8K UDP/IP datagrams.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: benchmark terminology
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 31 Jul 1992 04:49:38 GMT

In article <1992Jul30.235511.10694@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> >Now the raw data rate of FDDI being 100 Mbps or 100,000,000 bps.
> >If I report N KB/sec does that mean N*1024 bytes/sec or N*1000 bytes/sec.
> >If I report N MB/sec does that mean N*1,000,000 bytes/sec
> >   or N*1024*1024 bytes/sec or N*1024*1000 bytes/sec.
> >Finally, If I can send N bytes in 1 second and wish to report the result
> >as Mbps do I report (N*8)/1,000,000 or (N*8)/(1024*1024) or (N*8)/(1024*1000).
> 
> >It strikes me that since the raw data rate does not have 1024 factored into it
> >anywhere the throughput result shouldn't either.  I have three different versions
> >of ttcp here, each does this a different way.  Any opinions?
> 
> Our opinion is that all data rates should be reported as multiples of
> 1000, not 1024.  That is, when we say we get X Mbytes/second, we
> mean X * 1000000 bytes, not X * 1048576.
> ...


I prefer 1KB=1024 Bytes, and 1MB = 1K*1KBytes = 2**20 Bytes.

That makes 1M about 4% larger than 1,000,000.  

When I say I have measured 500MByte/sec over ethernet with my stuff, I
can be more confident that other people will also measure 500MB.


Vernon Schryver,  vjs@sgi.com
From: haneyg@cs.utk.edu (Gary W Haney)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT question
Keywords: Fddi
Date: 23 Jul 92 15:38:48 GMT
Article-I.D.: utkcs2.l6tkk8INNfeh
Distribution: comp
Organization: University of Tennessee, Knoxville - CS Department

Can anyone provide me with a list of the FDDI chip vendors that
support promiscuous mode on their products.

Please reply directly to me and I'll summarize. (haneyg@utkcs2.utk.edu)

Thanks in advance,

Gary
From: wittmann@engr.wisc.edu (art wittmann)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 28 Jul 92 19:56:57 GMT
Organization: College of Engineering, Univ. of Wisconsin-Madison
Originator: wittmann@muskie.engr.wisc.edu


In article <nrksjfc@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In article <1992Jul27.172641.22132@acc.com>, art@acc.com (Art Berggreen) writes:
|> > In article <nqqtk74@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> > >Depending on what you mean by FDDI-bridging-hubs, there is the problem
|> > >of bridging FDDI to ethernet.
|> > >Some FDDI-ether bridges are junk, because they do not do the necessary
|> > >IP fragmentation of 4K IP/FDDI datagrams.  Think about NFS which
|> > >likes 4K and 8K UDP/IP datagrams.
|> > 
|> > I won't take sides in this very controversial topic, but will point out
|> > that there are a large number of people that believe IP-fragmenting bridges
|> > are "junk".  The main argument being, that these devices are doing part
|> > of the routing function without doing the rest.
|> 
|> 
|> Well, I think bridges in general are nasty, because I'm of the routing
|> faith.  More precisely, bridges and routers/gateways are the same kind
|> of boxes, except that bridges are particularly stupid (well, limited)
|> routers.
|> 
|> IP fragmentation is a trivial bit of work, and far less that all of IP
|> routing.
|> 
|> 
|> It is nice to reserve the word "junk" for something that does not
|> perform its advertised function.  An FDDI-ethernet bridge that does not
|> fragment 4352 byte IP datagrams is "junk" because your network will not
|> work.  A box that does only spanning tree "routing" based on MAC
|> addresses and does IP fragmentation may not be a bridge by some
|> definitions, and it may be unclean, but it is not "junk."

Now lets be reasonable, I don't know of too many IP end station 
implementations that don't let you set the maximum transmission unit.  
This is an issue, but necessarily one that defines junk vs. workable 
product.

The point of my original question was:

If you have a routed FDDI network, how would you use hubs that can house
say: FDDI, enet and token ring interfaces?  Must the interface back to
the main ring also be routed?  Could you live with a bridge, lets even
say it's a half-breed and does fragmentation?  

Do hubs belong on FDDI based backbones, or are they misfits?  On one hand
you can use routers to form the backbone.  These routers can have multiple
interfaces that can then be attached to, say, multiport repeaters that
are considerably smaller and cheaper than hubs.

On the other hand, you could use hubs and build a big bridged network.  If
you found a hub manufacturer that built an FDDI router card for the hub,
would you trust them?  Synoptics and Ungerman-Bass are two that do.

Thanks,
Art
Organization: University of Maine System
Date: Tuesday, 28 Jul 1992 00:41:17 EDT
From: James <IO92142@MAINE.MAINE.EDU>
Newsgroups: comp.dcom.lans.fddi
Subject:    Digital Telephony/FBI?

I read this article in MacWeek and I would like to know if there
is anyone who might have more information about these
current subjects.
Any responses via email will be greatly appreciated.
Digital Telephony-MacWeek-7.12.92

Washington

The FBI has sharpened language in proposed legislation that would require
government wiretap access to all U.S. voice and data networks.

The proposal, known as Digital Telephony, is a response to new telephone
technology, which the FBI claims makes eavesdropping more difficult.  The new
draft includes and explicit call for law enforcement monitoring facility with
remote access to every voice and data network in the country.  The FBI also
called for the Federal Communications Commission to relinquish its
standards-setting and device-certification authority to the U.S. Attorney
General, who could force wiretap-secure networks open with fines of up to
$10,000 a day.

The FBI told computer and communications industry leaders that its wiretap
shopping list includes access to all present and future network technologies,
including Ethernet, X.25, cellular networks and Electronic Data Interchange
systems.

"In its current form Digital Telephony would open the entire universe to
wiretaps," said Don Gilbert, information services directory at the Washington,
D.C.- based American Petroleum Institute.  He is among 40 industry leaders
opposing the proposal.

The bill still has not found a sponsor on Capitol Hill.  Nevertheless, the FBI
has not backed down.

Attorney Mike Godwin, counsel to the Cambridge, Mass.-based Electronic Frontier
Foundation, said the FBI remained adamant because Digital Telephony is a
backhanded attempt to prevent the use of encryption on U.S. networks.  The
Department of Justice, the FBI's parent agency, launched anti encryption
legislation in 1991, Senate Bill 266, which did not pass.

"They are asking for an outrageous level of access because they can back down on
the condition that a ban be placed on encryption," Godwin said.
"It leaves us where we would have been if S.B. 266 has passed."

=-=-=-=-=-=--=-=-=-=
James Gray                           Bitnet   :  IO92142@Maine
University of Maine                  Internet :  IO92142@Maine.Maine.Edu
From: TOSDRST@GE1VM.SCHDY.GE.COM
Newsgroups: comp.dcom.lans.hyperchannel
Subject: subscription
Date: 27 Jul 92 15:59:23 GMT
Distribution: inet
Organization: The Internet

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From:
Subject: subscription
Please sign me up
.ge nymap data

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From The Desk of Don Smith.
From: bryand@cascade.ens.tek.com (Bryan Duff)
Newsgroups: comp.dcom.lans.hyperchannel
Subject: Re: EN642-2 PCF limitations
Summary: File system limitations
Date: 29 Jul 92 21:19:27 GMT
Distribution: inet
Organization: Network Systems Corp.

In article <9207292005.AA07608@orville.nas.nasa.gov> PMW1@PSUVM.PSU.EDU ("Peter M. Weiss +1 814 863 1843") writes:
>(One of the) We at Penn State have run across a limitation of the
>PCF so that filtering on full IP addresses causes us to also add
>a static route for that address.  Because of our extensive filtering
>(and its concomitant ROUTE), we have approached the limit of the
>file system (30036 bytes of EEPROM) to store configuration statements.
>
>Has anyone run across this limitation, and if so, how did you bypass/
>resolve it?
>
>/Pete
>--
>Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
>31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection"
>University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92


This problem can be resolved fairly simply by adding another EEPROM to
the IP coprocessor board effectivly doubling the capacity.  You should 
contact your local NSC Customer Service Representative or NSC Sales
office to find out the details.  While I don't know exactly who your
Sales Rep. would be, the Customer Service District Manager for your
area is Mr. Stubbs in Media, PA.  The Phone number is  215/565-1935.  
He should be able to direct you in the proper direction.

I sure hope this is of benefit to you.
____________________
Bryan L. Duff
Network Engineer
Network Systems Corp.
email - bryand@cascade.ens.tek.com

--
Bryan Duff
Network Engineer
Network Systems Corp.
From: TOSDRST@GE1VM.SCHDY.GE.COM
Newsgroups: comp.dcom.lans.hyperchannel
Subject: subscription request please
Date: 27 Jul 92 15:16:16 GMT
Distribution: inet
Organization: The Internet

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From:
Subject: subscription request please
Please sign us up..
 Ray K. Smith tosrksc@ge1vm.schdy.ge.com
  and
 Don R. Smith tosdrst@ge1vm.schdy.ge.com

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

Don Smith
Senior Software Engineer--Network Services
General Electric Company
Corporate Information Technology-Schenectady Megacenter
*
              ______
             /      |   INTERNET:  TOSDRST@GE1VM.SCHDY.GE.COM
            |       |   IBMMAIL:   IBMMAIL(USGESTVS)
  _________/        |   PROFS:     GE1VM(TOSDRST)
  >              0  |   DIALCOMM   8-235-1946
 /                  |   AT&TNET:   1-(518)-385-1946
| ______________    |   SNEAKERNET:General Electric Company
               `_   |              Corporate Information Technology
                 `__|              2500 Cambridge Road
                                   2nd Floor East Wing
                                   Schenectady New York, 12345
                          FAX:      1-518-385-0654
                                       8-235-0654


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From The Desk of Don Smith.
From: PMW1@PSUVM.PSU.EDU ("Peter M. Weiss +1 814 863 1843")
Newsgroups: comp.dcom.lans.hyperchannel
Subject: EN642-2 PCF limitations
Date: 29 Jul 92 20:05:00 GMT
Distribution: inet
Organization: The Internet

(One of the) We at Penn State have run across a limitation of the
PCF so that filtering on full IP addresses causes us to also add
a static route for that address.  Because of our extensive filtering
(and its concomitant ROUTE), we have approached the limit of the
file system (30036 bytes of EEPROM) to store configuration statements.

Has anyone run across this limitation, and if so, how did you bypass/
resolve it?

/Pete
--
Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection"
University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92

Newsgroups: alt.heraldry.sca