HDTenEightyP/NetNews huggingface dataset:
From: Mukul Agrawal <mukul@ssdc.honeywell.com>
Subject: ATM Switch Info Request
X-Xxmessage-Id: <A6EDF0C78401523B@mac82-59.ssdc.honeywell.com>
X-Xxdate: Tue, 29 Sep 92 11: 38:47 GMT
Organization: Honeywell Inc.
X-Useragent: Nuntius v1.1.1d11
Date: Tue, 29 Sep 1992 16:34:49 GMT

We are setting up a lab to study high-speed networks for multimedia and 
control. In particular, we would like to get information on ATM switches,
and 
host interfaces that may be available for sale by 1st quarter of 1993.

While we would like to set up an ATM/SONET based testbed, we may 
eventually land up using ATM over some other PHY (such as FDDI). Any 
information on ATM products will be greatly apperciated. Please reply by
mail.

Thanks in advance.

-- Mukul

========================================================================
Mukul Agrawal
Sensor & System Development Center                         (612)782-7469
Honeywell Inc., MN65-2300                             FAX: (612)782-7438
3660 Technology Drive                           mukul@ssdc.honeywell.com
Minneapolis, MN 55418                   Agrawal_Mukul@ssdc.honeywell.com
Newsgroups: comp.dcom.cell-relay
From: tjs@uh.msc.edu (Tim Salo)
Subject: Re: TCP/IP with 700 Mbit/s
Organization: Minnesota Supercomputer Center, Minneapolis, MN
Date: Tue, 29 Sep 1992 14:17:45 GMT

In article <1992Sep23.155705.15270@fokus.gmd.de> icarus!mbu@fokus.gmd.de (M. Burak) writes:
>Could somebody please tell me where to get more information about the 
>700 Mbit/s TCP/IP. [...]

Dave Borman at Cray Research (dab@cray.com) reported on "TCP/IP
Performance at Cray Research" at the March IETF.  His presentation is
contained in the IETF proceedings, pages 492-493, (but is not listed
in the Table of Contents).

To summarize one of his slides, he used the following configuration:

o	HIPPI between two dedicated Y/MPs with Model E IOS and
	Unicos 8.0

o	Memory to memory transfer, (i.e., no mass storage transfers)

o	Results when connecting through a HIPPI switch which 
	disconnects after each packet:

	MTU - 33K  -  416 Mbps
	MTU - 49K  -  525 Mbps
	MTU - 64K  -  605 Mbps

o	With no HIPPI switch (direct channel-to-channel):

	MTU - 64K  -  781 Mbps

Refer to the IETF proceedings or Dave Borman for more information.

Tim Salo
tjs@msc.edu
(612) 626-3047
From: radha@hpindda.cup.hp.com (Radhakrishna Hegde)
Newsgroups: comp.dcom.cell-relay
Subject: MID swapping?
Date: 30 Sep 92 23:35:40 GMT
Organization: HP Information Networks, Cupertino, CA


	Could anyone please tell me how MID swapping works? Thanks in
	advance.

	regards,
	hegde
Newsgroups: comp.dcom.cell-relay
From: brobbins@qualcomm.com (Barry Robbins)
Subject: ATM over T1; use of header address bytes
Organization: QUALCOMM, Inc.
Date: Wed, 7 Oct 1992 00:44:09 GMT

>From what I've read and my conversations with vendors, it would seem that
ATM interface rates officially start at 155Mbps (OC3), with 45Mbps (T3) 
the lowest rate any switch will support. 

My first question:
Is it possible, in a private network using leased T1s and an ATM switch, to 
support ATM cells over T1 interfaces?  Is anybody out there doing this?  Do 
any switch vendors support this?   How would one pack the cells into the
T1 frame, just skip every 193rd framing bit?  How are cells delineated on a
synchronous interface in general.


Second question:
The ATM cell defined for user access has two bytes of VCI (virtual circuit ID),
 and 1 byte of VPI (virtual path ID).  I haven't yet got my hands on any ATM 
specs.  How are these two fields used?  How do they differ?  Are they defined 
for end-to-end addressing?  Or can the switch and/or network stomp on them? 
Any detailed info/pointers appreciated.  Which specs should I get?

Thanks a lot,

Barry Robbins
QUALCOMM Inc.
San Diego
Ph. (619) 597-5693
<brobbins@qualcomm.com>

From: jr@hptnobr.grenoble.hp.com (Jean-Rene Bouvier)
Date: Tue, 29 Sep 1992 11:36:54 GMT
Subject: Re: Gigabit projects outside US and Europe?
Organization: Hewlett-Packard, GND
Newsgroups: comp.dcom.cell-relay

|       Does anyone know of gigabit research projects (especially projects
|   involving more than one organization) outside of the US and Europe?
|   I'm trying to make sure I'm not neglecting any major projects in the
|   summary of gigabit activities I provide in a course I teach.
|
|The UK Academic Community have plans to install a national Gigabit
|network in the next few years. Bob Day <r.a.day@jnt.ac.uk> can supply
|more details or point you at the people who can supply them.
|
|                Jim

I had always thought the UK was part of Europe :-)
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: AAL5
Organization: Finnish University and Research Network
Date: Sat, 3 Oct 1992 14:02:08 GMT

ETSI contribution on AAL5 for the October CCITT meeting is available
for ftp (no email availability) as datanet.tele.fi:atm/i3635.ps.

--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
--
From: dean@pico.qpsx.oz.au (Dean Economou)
Newsgroups: comp.dcom.cell-relay
Subject: Re: TCP/IP with 700 Mbit/s
Date: 29 Sep 92 08:15:41 GMT
Organization: QPSX Communications LTD, Perth, Western Australia.
X-Newsreader: Tin 1.1 PL4

I haven't heard much from them lately, but about a year ago the ULTRANET
people (based in the US) were talking of supporting TCP transfers at
these rates from Cray backplanes.  This wasn't over the "Gigabit
Network", I think it was a backplane to backplane connection.

Cheers,
Dean 
(reply to: dean@qpsx.oz.au)

icarus!mbu@fokus.gmd.de (M. Burak) writes:
: Could somebody please tell me where to get more information about the 700 Mbit/s TCP/IP.
: Some time ago somebody (I forgot the name) mentioned something about a TCP/IP implementation
: allowing 700 Mbit/s of throughput via a Gigabit network. I am very interested where to get
: more information about this implementation.
: 
: Thank you very much.
: 
: Markus Burak
: 
: 
: --
: Markus Burak 				burak@fokus.gmd.dbp.de
: National Research Corporation		voice: +49-30-25499-262
: for					FAX: +49-30-25499-202/168
: Mathematics and Data Processing
: (GMD-FOKUS)
: Berlin, Germany
: 	
: 		Research Center for Open Communication Systems
From: ruh@aquila.sni-usa.com (Bill Ruh)
Newsgroups: comp.dcom.cell-relay
Subject: ATM latencies
Date: 6 Oct 92 15:59:53 GMT
Organization: Siemens Nixdorf Inc.

What is the hardware latency for a short (say 100-byte) message on an
ATM lan?  Has anyone measured this?  On what hardware?

Thanks,
Bill Ruh
-- 


Peace,
Bill Ruh
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: Re: TCP/IP with 700 Mbit/s
Date: 28 Sep 92 07:39:07 GMT



 >> The only one I know about is TCP/IP over HIPPI (800 Mb/s medium) between
 >> a pair of Crays (model number?), which supposedly got 780 MB/s (600 Mb/s
 >> is there was one HIPPI switch in the path). Maybe someone from Cray could
 >> say more...?

 >I think you got your abbrevieations mixed up.  I think you mean 780 megabits, which is still 97 megabytes/sec.  A collegue in Eagan has gotten 75 megabytes/sec,

it is certainly 700 MegaBits per sec, and is not just between crays,
but also between crays and silicon graphics iris workstations, and IS
on HPPI 9i.e on a real net,m not just memory to memory), albeit nly a
few 10s of metres...

note that they use Very Large PDUs (like 64 k BYTES!)
but are running perfectly legal tcp

see Dave Borman at Cray's work with Van Jacobson on go fast tcp
options to make this work long haul too...

cheers
j.
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Prices
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 6 Oct 92 14:27:21 GMT

Cost of Ports:

The current price for a 10Base-T unswitched hub is about $60/Mbps,
(I divided 10 Mbps by the number ports for a typical hub).

And the Fore price for 150 Mbps is about $4,000, or about $30/Mbps,
(I used the Communications Week numbers).  

OK, so lets take the high number, which tells me that 10 Mbps switched
capacity to an existing 10 Base-T adapter card should be around $600.

Ethernet switchers sell for around $100/Mbps, somewhat on the high
side.

The projected cell relay prices seem acceptable, assuming that the 
10Base-T to cell relay hub interface isn't overly complex.
From: bharath@iti.gov.sg (Bharath Narayanan (CCL))
Newsgroups: comp.dcom.cell-relay
Subject: Re: AAL5
Date: 28 Sep 92 01:12:46 GMT
Organization: Indiana University
X-Mailer: ELM [version 2.3 PL11]

Dear Sir:
I am new to this field. I have some details upto AAL4 but nothing about AAL5.
Could you please cite some references ?
Thanks in advance.
Regards
Bharath

bharath@iti.gov.sg
Information Technology Institute
Singapore 0511.
Newsgroups: comp.dcom.cell-relay
From: KUMQUAT@SMCVAX.BITNET
Subject: (none)
Organization: Indiana University
Date: Sat, 26 Sep 1992 19:15:07 GMT

Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
 with BSMTP id 5732; Sat, 26 Sep 92 15:12:03 EDT
Date: Sat, 26 Sep 92 08:29 EDT
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT@SMCVAX.BITNET>
Subject: Re: ATM-SAP for AAL3/4
To: comp.dcom.cell-relay@ucs.indiana.edu
X-VMS-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

Brian Carpenter askes why we even worry about AAL3/4 since AAL5 is so
much simpler.  He is correct...

however, SMDS is available today and compatible (more or less) with AAL3/4
but not with AAL5.  So, at least for while, we probably do have to worry
about AAL3/4.

Gary Kessler
+1 802-879-3375
kumquat@smcvax.bitnet
From: gpkatch@alcor.concordia.ca (Gary Katch)
Newsgroups: comp.dcom.sys.cisco
Subject: Abnormal bridge tables?
Date: 30 Sep 92 18:13:25 GMT
Organization: Concordia University
  Computing Services C-1012
  1455 De Maisonneuve West
  Montreal (Quebec) H3G 1M8
X-Tel: (514) 848-7632
  Fax: (514) 848-7622
Originator: gpkatch@alcor.concordia.ca

I get the following report from 'show bridge':
--------
Total of 10200 station blocks, 6531 free

BG Hash   Address        Action  Interface Age  RX count  TX count
 	[...]
 1 11/0   AA00.0400.C9D8 forward Serial0     0         1         0
 1 11/1   AA00.0400.C9D8 forward Serial0     1         1         0
 1 11/2   AA00.0400.C9D8 forward Serial0     1         1         0
	[92 similar entries]
 1 11/94  AA00.0400.C9D8 forward Serial0    42         1         0
 1 11/95  AA00.0400.C9D8 forward Serial0    42         1         0
 1 11/96  AA00.0400.C9D8 forward Serial0    44         1         0
	[...]
 1 B9/0   AA00.0400.61D8 forward Serial0     0         1         0
 1 B9/1   AA00.0400.61D8 forward Serial0     0         1         0
 1 B9/2   AA00.0400.61D8 forward Serial0     0         1         0
 1 B9/3   AA00.0400.61D8 forward Serial0     0         1         0
	[144 similar entries]
 1 B9/147 AA00.0400.61D8 forward Serial0    45         1         0
 1 B9/148 AA00.0400.61D8 forward Serial0    45         1         0
 1 B9/149 AA00.0400.61D8 forward Serial0    45         1         0
	[...]
--------
The bridging is table is huge compared to my other routers in
the same network.  This one is filled with multiple entries for
the same ethernet addresses, differing by hash and age.  You can
see that subsequent entries for the same address cause the hashed
addresses to increment.

What is happening??

Version:

IGS-BR Software, Version 8.2(1)
Compiled Mon 10-Dec-90 14:08 by mlb
System Bootstrap, Version 4.3(1)
cisco IGS (68020) processor (revision 1) with 1024K bytes of memory.
Serial Number 00125380
Bridging software.
1 Ethernet/IEEE 802.3 interface.
1 Serial network interface.
16K bytes of non-volatile configuration memory.
Configuration register is 0x1

Config info:

decnet routing 54.227
decnet node-type area
decnet max-address 1023
!
interface Ethernet 0
ip address 132.205.40.1 255.255.255.0
ip broadcast-address 132.205.40.255
decnet cost 5
decnet router-priority 60
bridge-group 1
!
interface Serial 0
ip address 132.205.56.2 255.255.255.0
ip broadcast-address 132.205.56.255
decnet cost 5
decnet router-priority 60
bridge-group 1
!
bridge 1 protocol dec
bridge 1 address FFFF.FFFF.FFFF discard

-- gk
Date: Friday, 25 Sep 1992 12:49:36 +02
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Any clues on AGS+ 'clear'?
From: Andre' Pirard <pirard@vm1.ulg.ac.be>
X-UserAgent: Nuntius v1.1.1d9
X-XXMessage-ID: <A6E8BC149901180A@ampa.segi.ulg.ac.be>
X-XXDate: Fri, 25 Sep 92 10:52:36 GMT
Distribution: world
Organization: University of Liege (Belgium)

In article <1992Sep24.155113.6767@bristol.ac.uk> Paul Smee,
smee@bristol.ac.uk writes:
>Second, I can't find any way to clear the various interface-associated
>counters which are shown by 'show interface ethernet <n>' -- is there a

clear counters [type unit]
You need 8.3(?).

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET
Newsgroups: comp.dcom.sys.cisco
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: Weird Ethernet Behavior
Organization: Indiana University
Date: Mon, 5 Oct 1992 14:09:09 GMT

In <Oct.4.23.11.23.1992.6277@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>>On all of our busy routers, 0 checksum errors are
>>recorded for Appletalk and IPX, but IP has some recorded.  We do have
>>services that actually use the checksum mechanisms for IPX (not sure
>>about Appletalk).

>I think you're find that IP is the only protocol with checksum
>failures because it's the only protocol that uses checksums.

>The IPX packet format is based on XNS, which has checksums.  So there
>is a checksum field.  But last time I looked IPX always set the
>checksum field to -1, and Novell software would not accept packets
>with real checksums.  We'd love to enable checksums for IPX, and we've
>asked Novell about this.  I'd love to hear that they had fixed it, but
>I really doubt it.  Since Cisco's implementation of Novell is based on
>XNS, they could easily support checksums for Novell, if Novell
>themselves would implement it.  This explains why you never see a
>checksum failure for Novell: none of the packets have Novell
>checksums.  (More precisely, the checksum field always has -1, which
>means "ignore checksum".)

>Appletalk allows checksums, but I have a feeling it isn't normally
>used.  We got a printer that supports Appletalk.  We couldn't talk to
>it through a Cisco router, because all of our routers have Appletalk
>checksumming enabled, and the printer had a bug in their checksum
>code.  It worked fine locally.  This implies to me that at least some
>Mac's don't generate checksums.  I just looked at our net for a minute
>with Sun's etherfind, and if I understand the packet format correctly,
>only packets generated by the Cisco have non-zero checksums.  This
>would explain why you're seeing no checksum failures for Appletalk.

Yea, yea, yea,  I assumed that SPX was checksumed and it isn't.
But, I just ran a little experiment that still suggests that the
show ip/ipx/appletalk traffic is relevant.  We captured a good IPX
frame heading towards a cisco with the sniffer, changed it checksum
from FFFF to 67FF, and resent it to the cisco.  The cisco counted
it as a IPX checksum failure.  If none of our ciscos are recording
any other IPX checksum failures, it suggests that corrupted packets
caught by the ethernet CRC are not making it into the router.  All
our ciscos are recording IP checksum failures, suggesting that the
ethernet CRC is begin ignored.

-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)
Newsgroups: comp.dcom.sys.cisco
From: Mike Skrydlak -- Tektronix Network Services <mikes@cascade.ens.tek.com>
Subject: Re: ip accounting 
             <9210021746.AA18701@wolf.cisco.com> 
Date: 02 Oct 92 14:09:41 PDT


> Everything after the CSC/4 will have field-upgradable memory.

My God !! How did you get the sales-types to agree to that ??

Was it a compromise for letting them institute all the recent 
product pricing announcements designed to make cisco sales-types
even more commissions ?

'Oh - you want to have it still be supported ?? - That'll be another
 $4000 for each of your routers' he said as he smiled ...

Newsgroups: comp.dcom.sys.cisco
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: Weird Ethernet Behavior
Organization: Indiana University
Date: Thu, 1 Oct 1992 21:02:50 GMT

In <1aflcqINNi8n@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

>In article <BvG405.Jp0@usenet.ucs.indiana.edu> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>>  Of course the router doesn't
>>need to validate the ethernet address to correctly route an IP
>>packet.

>Sure it does, because ethernet is a broadcast medium.  An ethernet node
>should ignore any packets that weren't addressed to its ethernet address
>(or the broadcast address or the address of a multicast group it's a member
>of), unless it's in promiscuous mode.  If the CRC doesn't check, the node
>shouldn't believe that the destination ethernet address is correct, so
>shouldn't accept it even if it appears to have its address.
>-- 
>Barry Margolin
>System Manager, Thinking Machines Corp.

>barmar@think.com          {uunet,harvard}!think!barmar
That's certainly one valid way to look at it.  On the other hand,
there's nothing wrong with an IP router ignoring the ethernet CRC.
If the ethernet address is wrong and their router accepts the frame
as though it were the correct recipient, nothing terribly wrong is
likely to happen.  IP networks can damage, duplicate, and lose
packets with out ill effect (yes, I know this isn't true for things
like NFS).  I think the changes of the destination ethernet address
being wrong, but the IP header checksum correct, are pretty remote.
We have seen a slightly broken network where cisco's feature of
accepting IP packets with bad ethernet CRCs allowed it to continue
to work.


-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)
From: bav@hobbes.ksu.ksu.edu (Brick Verser)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 6 Oct 1992 21:45:20 GMT
Organization: Kansas State University
NNTP-Posting-Host: hobbes.ksu.ksu.edu

ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>You are correct. After talking to cisco, it doesn't look like our
>problem is the cisco accepting corrupted ethernet packeta, but a heavily
>loaded cisco doing the corruption.

I don't think internal corruption can explain the problem KSU was having.
A quick recap:

  About 4 weeks ago our Solbourne suddenly started hanging frequently...the
  nfsd's went into disk wait and eventually 100+ processes hung before the
  system became completely unresponsive.

  It was determined that the nfsd's were doing HUGE reads which the
  kernel was trying to fill and hanging in doing so.  The reads were often
  for 0xaaaaaaaa or 0x55555555 bytes.  Turns out each core dump showed the
  NFS reads were coming from one of 6 IPCs in a single building.  None of
  the 35 or so other machines on campus which use the Solbourne caused it.
  These machines all use a single Cisco router with 24 Ethernet ports.

  A test program showed that indeed, UDP packets with bad checksums were
  being passed by the Cisco.  About one in 10K to 20K packets were bad
  but were transmitted by the router, with the tail-end of the bad packets
  being 0xaa's or 0x55's.  

  Only packets arriving from one building did this, and it was fixed by 
  reseating the fiber-optic transceiver on that Cisco Ethernet port.

Internal corruption could do this, but should do it for multiple buildings.
The building this was coming from is not an especially busy one.  And it 
wouldn't be fixed by reseating the FOT on the Cisco's Ethernet card.  
So how can one explain these symptoms?  The Cisco accepting bad Ethernet
packets caused by a flakey FOT is one way.  Any others?

--Brick
Newsgroups: comp.dcom.sys.cisco
From: Jim Forster <forster@cisco.com>
Subject: Re: ip accounting 
             <CMM.0.90.2.718046951.vaf@Valinor.Stanford.EDU> 
Date: 02 Oct 92 10:46:00 PDT

>> Any chance that future cisco CPUs will have a field-upgradeable memory
>> design?

Everything after the CSC/4 will have field-upgradable memory.

  -- Jim
Newsgroups: comp.dcom.sys.cisco
From: Sam Wilson <ercm20@festival.ed.ac.uk>
Subject: Multicast storms
Reply-To: Sam.Wilson@edinburgh.ac.uk
Date: 29 Sep 92 17:01:28 BST
Via: uk.ac.edinburgh.festival; Tue, 29 Sep 1992 17:01:32 +0100

Three times recently we have experienced a kind of multicast storm,
apparently because of a breakdown in the bridge spanning tree.  We have
Cisco AGS+/3s running 8.2(7) and routing IP, DECnet, Novell and
AppleTalk and bridging other stuff (LAVC, LAT, ISO CONS/UK Pink
Book/LLC2).  We have a meshed network of ethernets and FDDI and a leased
line (which was installed after the first storm).  During the storms we
saw large amounts of multicast traffic (LAVC and LAT mostly) apparently
being looped within the network.  Traffic peaked at between 1000 and
2000 pps, never falling below 1000pps, presumably the peak rate that the
routers could forward the traffic on the the attached ethernets.

At the time of the storms we were using the DEC spanning tree, and had
been for the best part of two years with no trouble.  There were no
obvious changes of configuration that we know about, in either hard- or
software, that might have triggered the problem and we've been unable to
track down any external events that might have caused it.  (The first
and second occurrences were both at about 11.20 on consecutive Tuesday
mornings.  Nothing has happened on following Tuesdays.  Third occurence
started on a Thursday evening and continued off and on through most of
Friday.  (I wasn't here and don't have exact details of what happened
but I have no reason to suppose that the outcome would have been
different if I had been.)

I'm preparing a note for our suppliers and Cisco, but I was just
wondering if anyone else had come across anything similar. 


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK