HDTenEightyP/NetNews huggingface dataset:
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Comment made at Next Generation Networks conference
Date: 23 Nov 92 18:34:47 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <By6GL7.EB0@usenet.ucs.indiana.edu>, robelr@mythos.ucs.indiana.edu (Allen Robel) writes:
> 
> Hmm, does someone make an FDDI switch?  If so, this certainly changes things.
> I'm a bit uncertain how efficient switching might be performed for FDDI
> in the same way that it is for ethernet.  For instance, to switch an FDDI
> means, I would think, to go through the claim token and ring initialization
> processes each time that a frame is switched, right?  Is there much overhead
> here?  I'm not an FDDI expert so don't know 1) how much time this
> initialization
> process takes, and 2) if there might be a way around it.  Ethernet,
> of course,
> 
> doesn't have this problem so I agree with you about 100Mb/s enet switching...


100Mhz ethernet may or may not be wonderful.  Very few people know any
useful technical facts, and none that I think might know anything about
it have said much.  You might as well talk about 1Gbit/sec packet radio
if you're going to talk about wonderful millenial, cargo-cult stuff.


People now make FDDI switches.  The mostly sell them as token ring and
ethernet switches that happen to also support FDDI ports.

There is no reason to do all of the FDDI switching mentioned above,
which is just as well, since it would not work.

The obvious way to build an FDDI hub is put a MAC on each port of the
switch.  Run a trivial, 2-station "ring" on each link to the hub.
Given that FDDI MAC chips are not the expensive part of the port, and
given that you need a MAC on every port just to switch the packets
through your cross bar, this would not be hard.  It would require
conceptual flexibility for the programmers of the hub, to believe that
SMT would work in such a situation.  (It would, quite easily and
cheaply.  Well, you could run SMT on all of the ports independently as
cheaply as running FDDI on any single port.)

However, I think the current crop of hubs with FDDI ports do not do
that.  They expect their FDDI ports to be connected to "the backbone."
Also, I think at least some such FDDI/TR/ethernet hubs do not use full
cross bar switches.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: mdh@cl.cam.ac.uk (Mark Hayter)
Newsgroups: comp.dcom.cell-relay
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Date: 23 Nov 92 18:07:30 GMT
Organization: U of Cambridge Computer Lab, UK

peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> I'm curious as to why you chose to aggregate all the cell headers at
> the front of the packet, rather than just the first - did this design
> predate AAL5?

Yes, our internetworking protocol and its datalink layers were in use
well before AAL-5. The original version was designed by Derek McAuley
as part of his thesis work in 1988-9, and this is based on an earlier
SAR protocol. In this the SAR information is contained in the header, so
we wish all headers to be carried to the end points (remember we are just
doing cell forwarding at the ethernet-ATM boundary, this does not know
anything about SAR). Clearly the end system on the ethernet is happier if
all the data is contiguous (in the common case of no cell loss all that 
needs to be done is scan the SAR to see it has the expected values and
DMA the data to its IPC buffer). The SAR information contains the
equivalent of the "user indication" bit. In fact we experimented with
two bits (essentially start and end of block) but only one is actually
required.

Mark

-- 
------------------------------------
Mark Hayter
Cambridge University Computer Lab
Mark.Hayter@cl.cam.ac.uk
Tel +44 223 334645
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: Re: Comment made at Next Generation Networks conference
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 23 Nov 1992 15:59:27 GMT

> > Where is the conflict?  Rob wrote "this is slightly lower (6.8%) than
> >FDDI's 97.3 Mb/s", refering to the number of bits a single TCP/IP
> >virtual circuit might get out of either FDDI or ATM.
>
> You just mentioned where the conflict is when you say "a SINGLE
> TCP/IP virtual circuit." [emphasis mine].  What would be the
> throughput for that SINGLE circuit when you've got 20 other
> fast machines using the same bandwidth?  Now compare that figure
> to the same twenty machines connected with an ATM switch...

There doesn't have to be a conflict here.  One can use FDDI as an access
protocol to an FDDI switch (just like switched Ethernet).  So the question is,
how fast can one host drive the MAC protocol (FDDI or ATM equivalent or,
indeed, 100Mbit/s Ethernet)?

Craig
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: How does one compare tansport systems ? was Re: Computers dont like ATM?
Date: 19 Nov 92 13:52:43 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <22909@venera.isi.edu> finn@dalek.isi.edu (Greg Finn) writes:
>
>	ATM is politically very popular.  Arguments that ATM brings
>about end-to-end compatibility do not impress me.  Most LAN traffic
>stays within the LAN.  Forcing LANs to comply with WAN data-link

Traffic goes application to application ie user to user ie end to end.
ATM addresses the building of user applications which are beyond the
traditional data applications now running on LAN's.


It does this while retaining the capability of running the traditional data
applications. Indeed it does this while reducing the compleity of 
a local network making it more manageable and scaleable.

Now questions about the suitability of transport systems must be based on their
suitability for the applications. ATM has been designed for integrated 
applications. In particular ATM has been designed to carry both delay sensitive
and high speed services.

Now what characteristics should be used for the selection of transport systems
to be used in the next decade. These characteristics must of necessity come
from an analysis of the applications.  
-- 
i.sinature
From: myoung@force.ssd.lmsc.lockheed.com
Newsgroups: comp.dcom.cell-relay
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Date: 20 Nov 92 15:03:33 GMT
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California

In article <1992Nov20.122227.6002@infodev.cam.ac.uk>, mdh@cl.cam.ac.uk 
>  (Mark Hayter) writes:
>
>We have been using a system similar to this to allow interworking between 
>our ATM networks and the Ethernet for several years. The ethernet packet
>contains the headers for all of the cells followed by the data - thus the data
>is contiguous at the host. This system works well, and the router forwarding
>code is efficient (since it is basically just doing cell forwarding).
> Data going from ATM->ethernet can be formed quickly into "fat cells",
>being transmitted when a full ethernet packet has been formed or the AAL-5
>"end-of-frame" indication is seen.

  OK, this seems to be the right tack for ethernet-ATM transfer.  I vote
to continue this thread, possibly leading to some standard mapping
between ethernet and cell relay.
Newsgroups: comp.dcom.cell-relay
From: robelr@bronze.ucs.indiana.edu (Allen Robel)
Subject: Re: Comment made at Next Generation Networks conference
Organization: Indiana University
Date: Mon, 23 Nov 1992 02:43:36 GMT

In <smji130@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>> Nope.  On page II-27 of the spiralbound (November 16th) handout, top
>> slide, second bullet item he states:
>>
>> "100 Mbs ATM delivers Less Bandwidth Than 100 Mbs FDDI"
>
> Where is the conflict?  Rob wrote "this is slightly lower (6.8%) than
>FDDI's 97.3 Mb/s", refering to the number of bits a single TCP/IP
>virtual circuit might get out of either FDDI or ATM.
 
You just mentioned where the conflict is when you say "a SINGLE
TCP/IP virtual circuit." [emphasis mine].  What would be the 
throughput for that SINGLE circuit when you've got 20 other
fast machines using the same bandwidth?  Now compare that figure
to the same twenty machines connected with an ATM switch...
 
-allen 
-- 
Allen Robel                         robelr@mythos.ucs.indiana.edu 
University Computing Services       ROBELR@IUJADE.BITNET 
Network Research & Planning         voice: (812)855-7171
Indiana University                  FAX:   (812)855-8299
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Voice Applications
Date: 17 Nov 92 09:18:11 GMT



 >Voice Conferencing:
 >A new service likely to be demanded will be multi-station voice
 >conferencing using the microphone and audio already available on
 >our desktops.  Two required technologies, echo canceling and voice 
 >mixing need some fairly hefty mips.

no they dont - my sparc 1 can mix 8 audio cofnerences at 64kbps PCM
and echo cancel....that is a modest machien nowadays

in fact i thin kthe LBL visual audio tool can do this with 8
LPC or other compressed audio signals on something like a sun ELC ...

dead triv as we say in north london...

 jon
now if you said GSM compressed, i might have to agree that you need
an SS2...:-)
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Transport Level Again
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 18 Nov 92 00:34:49 GMT

Goings on at the Transport Layer:

Since the path building process allow two objects to use a dedicated 
communications path, (not multiplexing a path with multiple process 
ports), then the capability is enabled for application specific transport 
layers.

For a given application, the developer may design a custom transport
layer.  Two examples are:

1)
Phase one: Perform error recovery on a message by message basis, letting 
the state context of each end point determine if a message type is out of 
context.  Then phase two: Switch to a sliding window method of error recovery.

2)
For some compression schemes, the first message may contain system parameters 
requiring error recovery, but subsequent messages may be excitation vectors 
requiring none. 

Each application yields a custom variation on the various transport
level themes.

By avoiding de-multiplexing the objects have tunneled through the
standard OS layers.  The application specific transport layers imply
that the adaption layer must make minimal assumptions about the message.  
Computing the checksum, but letting the upper layer decide its relevance.
Newsgroups: comp.dcom.cell-relay
From: dgr@RODIN (Daniel Robinson)
Subject: Re: Comment made at Next Generation Networks conference
Organization: Vitalink Communications, Fremont, California
Date: Mon, 23 Nov 1992 23:12:21 GMT

In article <By6GL7.EB0@usenet.ucs.indiana.edu> "Allen Robel" <robelr@mythos.ucs.indiana.edu> writes:
+Craig Partridge writes:
+
+Hmm, does someone make an FDDI switch?

Hmm, you use crossbar switches and run one or more rings through
the boards or board sets.  Sounds like Datakit to me...

Daniel Robinson
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Is ATM well suited to LANs?
Date: 20 Nov 92 02:17:41 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

In article <1992Nov19.104113.1@tnclus.tele.nokia.fi> rowland@tnclus.tele.nokia.fi writes:

> "Most LAN traffic stays within the LAN" - The meaning of "most" is 
> shifting.  Why couldn't the inter/intra LAN traffic ratio grow to 
> nearer 50/50 in the future ?  LAN traffic characteristics are 
> evolving as the technology constraints are relaxed or removed.

	You suggest that traffic pattern which has been characteristic
will markedly change in the future.  Perhaps.  But there are good
reasons why heavily used network devices, such as laser printers and
file servers, are located close to their typical user populations.
The need for access and low latency are examples of those reasons.
Neither reason is likely to be affected by the presence of ATM or its
lack.

	Today's multimedia message traffic typically crosses the LAN
at least twice: once to be stored in a nearby server, and once to be
read.  When you FTP a file from far away, where does it typically get
stored today?  Far from believing the 50/50 bound, I think that a
strong argument can be made for 66/33 LAN/WAN as a typical upper
bound.  This ignores how much message traffic is received from
intra-LAN sources, which has no WAN component.  It also ignores the
affect of local mailing lists, where one WAN message that is received
may generate many LAN message transfers.

> Question : When video telephony does take off, will visually attractive
>            people receive more than the average number of calls ?

	Video telephony over long distance will be very costly by
comparison with intra-LAN video traffic.  It is likely that it will be
heavily compressed.  Why restrict users on the LAN to MPEG with its
artifacts if they have the capability to handle uncompressed data?  If
you call your colleague	down the hall or on the next floor, why not
use high resolution video?

	I find no compelling reasons why the typical LAN/WAN traffic
ratio should move toward 50/50.  You may know of some better examples.
If so, sing out.

--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Computers dont like ATM?
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 19 Nov 1992 16:08:38 GMT

rowland@tnclus.tele.nokia.fi writes:

>[Gregory Finn wrote :]

>>	ATM is politically very popular.  Arguments that ATM brings
>>about end-to-end compatibility do not impress me.  Most LAN traffic
>>stays within the LAN.  Forcing LANs to comply with WAN data-link
>>standards is putting the cart before the horse.

> "Most LAN traffic stays within the LAN" - The meaning of "most" is 
> shifting.  Why couldn't the inter/intra LAN traffic ratio grow to 
> nearer 50/50 in the future?

Here's a random list of reasons, in no particular order:

Because most communications systems have a local bias. (e.g. the phone
system, the highway system) Because those that don't have this bias
seem to be broadcast (TV, postal - i.e. junk - mail) systems, and data
networks aren't.

Because work habits tend to favor clusters of people working in physical
proximity, so a work group which shares data is likely to consist of
one or two closely located groups, with little traffic outside. (this is
drawing on my own experience in engineering - in other fields this may
not hold, e.g. if you and your colleagues spend all your time accessing
data from a third, distant party. Radiology comes to mind as an example.)

Because of the existence of NFS - there are good reasons why you want
your main server (or at least the person who fixes it) to be near by.
Any other "remote peripheral" system shares the same property.

Because bandwidth will always be cheaper on a LAN. (or at least on the
right one) 

Because LANs allow people to escape the purview of corporate planners.
Look at the success of Appletalk and of the Apollo ring when they both
came out. Do you think they would have succeeded if every installation
had gone through an IS approval and installation process?

				Peter Desnoyers
--
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Is ATM well suited to LANs?
Date: 21 Nov 92 23:04:09 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

In article <13605@grayt> grayt@Software.Mitel.COM (Tom Gray) writes:

>Indeed if the application on the WAN is to allow the user to edit
>the video stream, why restrict it to MPEG when JPEG is much more
>suitable. Perhaps this will show you why ATM is designed for end to end
>applications and negotiations of protocols.

	ATM is not designed for negotiations of protocols.  ATM is a
data-link layer protocol.  Negotiation of options and encoding
protocols is a much higher layer function that occurs usually in the
session and presentation layers.

	The choice of a coding standard is application driven.  MPEG
is designed for motion picture coding, hence its name.  JPEG was
designed for stills.  You feel the need for JPEG frame by frame to
decrease artifacts - fine.  You pay for greater bandwidth consumption.
This has nothing to do with ATM unless you are arguing that ATM can
send JPEG packets more easily than MPEG packets.  That is a pretty
strange argument to make if it is supposed to favor ATM.
--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: new AAL (SSCOP?)
Organization: Digital Equipment Corp., Littleton MA USA
Date: Tue, 17 Nov 1992 23:00:18 GMT


In article <JH.92Nov12193519@etana.funet.fi>, jh@etana.funet.fi (Juha Heinanen) writes...
>What it doesn't have is multiplexing (addressing) capability.  If you
>would add that, then you and I could use the SAME protocol for Q.93B
>(with null address fields) and for real end-to-end transport purpose
>(with address fields).  So I'm against SSCOP only because of this
>omission.

Juha,

Multiplexing is not included because it is not always required.  But
it is not forbidden, either.  I think the right answer is to converge
a simple transport layer, something like TP0 or maybe UDP, right above
SSCOP.  But for users who don't require multiplexing, it would be a
burden to require it. 
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
Newsgroups: comp.dcom.cell-relay
From: jstone@netcom.com (Jeffrey Stone)
Subject: BISDN NT1 & NT2?
Keywords: BISDN ATM model
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 16 Nov 1992 21:31:47 GMT

I have received several confusing descriptions of the terms NT1 and NT2
in the context of BISDN.  Also S and T interfaces.

Would those of you who understand such things please enlighten me?

Thanks,
Jeff



-- 

Jeffrey Stone		jstone@netcom.com		415.324.0443
From: dm@cl.cam.ac.uk (Derek McAuley)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Computers dont like ATM?
Date: 18 Nov 92 07:31:23 GMT
Organization: U of Cambridge Computer Lab, UK

In article <1992Nov18.025754.14749@trl.oz.au>, lampard@titan.trl.OZ.AU (Greg Lampard) writes:
|> This morning I heard a talk by Dr Paul Green from IBM Research, in
|> which he was explaining his work on high-speed all-optical networking.
|> More or less in passing, he mentioned that 53 byte cells are too small
|> for computers (or words to that effect).  His claim was that small
|> packets are good for delay-sensitive applications, but they make a lot
|> of unnecessary work for the computer that has to receive them, since it
|> has to process a header every 53 bytes, and often just stores the cell
|> to build up a larger packet for the next layer up the protocol stack.

Many computers are well used to dealing in small fixed sized units; lets call
these units cachelines. The trick is to do such handling in hardware. 

But the cry always goes up "the cost the complexity"; Pah! that's what people
said about caches / snooping / virtual addressing / pipelines / ad nauseum ... 
until one day the hardware designers bit the bullet and it just happened because
that's what it took to go faster.  

So look at it another way; assume some day we have to handle network traffic in
hardware - as someone who dabbles in hardware I know my prefered solution would
be to manipulate fixed rather than variable sized objects. The words paging and
segmentation seem to spring to mind for some reason.

Mac.
Newsgroups: comp.dcom.cell-relay
From: "Allen Robel" <robelr@mythos.ucs.indiana.edu>
Subject: Re: Comment made at Next Generation Networks conference
Organization: Indiana University
Date: Mon, 23 Nov 1992 16:25:40 GMT

Craig Partridge writes:
> There doesn't have to be a conflict here.  One can use FDDI as an access
> protocol to an FDDI switch (just like switched Ethernet).  So the question is,
> how fast can one host drive the MAC protocol (FDDI or ATM equivalent or,
> indeed, 100Mbit/s Ethernet)?
> 


Hmm, does someone make an FDDI switch?  If so, this certainly changes things.
I'm a bit uncertain how efficient switching might be performed for FDDI
in the same way that it is for ethernet.  For instance, to switch an FDDI
means, I would think, to go through the claim token and ring initialization
processes each time that a frame is switched, right?  Is there much overhead
here?  I'm not an FDDI expert so don't know 1) how much time this initialization
process takes, and 2) if there might be a way around it.  Ethernet, of course, 

doesn't have this problem so I agree with you about 100Mb/s enet switching...

allen
Newsgroups: comp.dcom.sys.cisco
From: Gary Kunis <gkunis@cisco.com>
Subject: Re: DS/3 Connectivity
Date: 16 Nov 92 7:54:11 PST
X-Mailer: ELM [version 2.3 PL11]
X-Note1: mail msgid was <199211161557.AA14870@spot.Colorado.EDU>
X-Note2: message-id generated by recnews

Rick,

Here is the answer to your query...

> The local telephone company, C&P of Maryland provides
> a pair of BNC coax connectors for a DS3 line.  If I want
> to connect a cisco router to this interface what must I do?
>
> Thanks
> Rick        

You need to insatll an HSSI interface card into your AGS+
to support the DS/3 speeds.  You also need an external
T3 DSU.  I suggest looking at T3 or kentrox units.

Contact Bob Evans at the Columbia, Md. sales office.  

  -- Gary --

Newsgroups: comp.dcom.sys.cisco
From: morgan@leland.Stanford.EDU (RL "Bob" Morgan)
Subject: FDDI MIB support?
Organization: Networking Systems, Stanford University, CA 94305, USA
Distribution: na
Date: Mon, 16 Nov 92 22:55:04 GMT


Is there support for the SNMP FDDI MIB (currently still in its
experimental location, I believe) in the latest cisco software
release?  My observation is that there is none in 9.0(1), which is the
latest we have.  If it's not there yet, are there plans?  Is cisco
waiting for the MIB to be installed under the official "transmission"
arc of the tree?

Thanks,

 - RL "Bob" Morgan
   Networking Systems
   Stanford

Newsgroups: comp.dcom.sys.cisco
From: merike@alw.nih.gov (Merike Kaeo)
Subject: Re: FDDI MIB support?
Organization: National Inst. of Health, DCRT, CSL
Distribution: na
Date: Tue, 17 Nov 1992 23:00:36 GMT

The FDDI MIB is partially supported.......it is the RFC1285, so it was taken out of the experimental space and put into the transmission 15 (?) space.  If you need more info, e-mail me at merike@alw.nih.gov

-- 

Merike Kaeo			merike@alw.nih.gov
National Institutes of Health	(301) 402-1548 


                          o
                            \
                          \0/
       ||==================|=====||
       ||-+-+-+-+-+-+-+-+-/\+-+-+||
       ||=================\=\====||
       ||                        ||
       ||                        ||
       ||                        ||

    ......kill or be killed.....



Newsgroups: comp.dcom.sys.cisco