HDTenEightyP/NetNews huggingface dataset:
From: walvdrk_r@research.ptt.nl (Kees van der Wal)
Subject: Re: NT1/NT2 question (2nd time around)
Organization: PTT Research, The Netherlands
Date: Fri, 20 Nov 1992 08:58:02 GMT

In article <1992Nov19.160821.23460@netcom.com>, jstone@netcom.com (Jeffrey
Stone) writes: 

> Can anyone out there please enlighten me as to the meaning of
> NT1 and NT2 in the context of CCITT's BISDN recommendations. 
> Also S & T interfaces.

The meaning of NT1, NT2, S and T are probably not defined in the B-ISDN 
recommendations as these papers focus on the aspect of broadband rather than on 
the definition of network parts and interfaces. I guess you have to refer to 
the ISDN recommendations for that subject (sorry I don't know the numbers) and
then glue a subscript "B" to the interface letter to obtain the "broadband"
version. 

Regards, <kees>


PS. If you're looking for layer 1 specifications of T, see draft recommendation
I.414 and draft revised rec. I.432a. 

> I have asked a number of people this question and have received
> rather confusing answers.

That makes me curious ... <k>
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: How does one compare tansport systems ?
Date: 20 Nov 92 22:44:37 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

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

>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.

	Name one.  ATM is not a transport layer protocol.  It isn't
end-to-end.  With the addition of call set-up protocol, an AAL layer,
and an as yet undefined multicast layer, each residing above it, ATM
may be thought of as a part of a transport layer.

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

	You are labouring under some misunderstandings.  At the very
least ATM requires fragmentation and reassembly in host interfaces.
That is not required for data-link layers that support variable-length
packets.  A four-in/four-out 500 Mb/s per-channel variable-length
router and two DMA drivers already fit onto < 10% of a microprocessor
chip's logic area.  Designed and developed by Caltech, we use them,
the floor below me has them fabricated, proof by silicon.  We don't
need call setup.  We don't need fragmentation or reassembly.  We don't
need AAL.  We support TCP/IP.

	ATM will not succeed in the LAN domain because of technical
superiority.  It may succeed because of marketing superiority or
decrees by government.  That happens a lot.  Marketing and politics
are things that I know nothing about.  I also have no informed opinion
about what is well suited to the all-optical networking domain.
--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: rowland@tnclus.tele.nokia.fi
Subject: Re: Computers dont like ATM?
Organization: Nokia Telecommunications.
Date: Thu, 19 Nov 1992 08:41:13 GMT

[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 ?  LAN traffic characteristics are 
 evolving as the technology constraints are relaxed or removed.

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

            (don't ask me to define "visually attractive" !! )

 Kevin Rowland,

+-----------------------------------------+
Name:     Kevin Rowland.
Address:  Nokia Telecommunications,
          PO Box 33,
          02601 ESPOO, FINLAND.

Telephone:       +358 0 5115703
Telefax:                5116698
Internet: rowland@tnclus.tele.nokia.fi
+-----------------------------------------+
  



Newsgroups: comp.dcom.cell-relay
From: "Allen Robel" <robelr@mythos.ucs.indiana.edu>
Subject: Comment made at Next Generation Networks conference
Organization: Indiana University
Date: Fri, 20 Nov 1992 22:20:00 GMT

At the Next Generation Networks conference John
McQuillan made the comment that 100Mb/s FDDI delivers
more bandwidth than 100Mb/s ATM. Now I know the reasoning
behind this (proportionally, overhead is less  for FDDI
variable-length frames depending on average frame
size) but has anyone done any studies with real-world
networks to determine how much real throughput FDDI
delivers to a given individual station given that its a
shared medium?  How would one calculate the true
throughput for any given station (raw theoretical
throughput, not application layer throughput)?  


I would imagine possible variables that would enter a
station throughput calculation might be the following:
number of stations, token rotation time, token holding
timer but how would one combine these (or others) into a
FDDI station throughput formula?  My motive here is to
compare ATM's inefficiencies (cell overhead, SAR/AAL
overhead???)  with FDDI's inefficiencies (shared
medium and what little frame overhead there is) as
a reality check for McQuillan's statement. 

 

Thanks in advance!

allen
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: Sun, 22 Nov 1992 03:31:05 GMT

Rob,
 
Thanks for your analysis!
 
>Why do you exclude application data throughput? Here are some quick
 
Just thought that it might simplify things not having to worry about
workstation-specific details (adaptor I/O, memory copies, bus speeds
and features etc.).
 
>And that doesn't even address the issue of FDDI being a shared medium and
>ATM being a switching-fabric system...
 
Yes, this is really what I was getting at.  Given a certain set of
conditions any one station might have considerably less throughput than
FDDI's theoretical max throughput (at the extreme, a fully maxed out
FDDI in both circumference and number of stations and all stations 
transmitting at their peak rate for instance).  I was just wondering 
how quickly, because of shared medium considerations, FDDI falls below 
ATM in per-station throughput.
 
>No, I fear the eminent McQuillan may have mis-spoken this time. (Or you may
>have mis-quoted perhaps?)
 
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"
 
To be fair, McQuillan's presentations made a lot of sense taken
as a whole, and the conference was well worth the time and money,
and he was quite cognizant of ATM's inherent benifits, and I DO
have a lot of respect for his ability to synthesize complex issues.
 
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: Craig Partridge <craig@aland.bbn.com>
Subject: Re: Comment made at Next Generation Networks conference
Organization: Indiana University
Date: Mon, 23 Nov 1992 17:05:50 GMT


> Hmm, does someone make an FDDI switch?  If so, this certainly changes things.

Not yet, but my understanding is that there are no serious technical barriers
to doing so.  I'm not an FDDI wizard myself -- this is simply what FDDI
experts tell me.

Craig
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Is ATM well suited to LANs?
Date: 20 Nov 92 17:44:15 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <22926@venera.isi.edu> finn@dalek.isi.edu (Greg Finn) writes:
>
>	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?

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.
.
.
.
.
.
.
.
.

-- 
i.sinature
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Comment made at Next Generation Networks conference
Date: 22 Nov 92 18:48:33 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <By3Lru.BxE@usenet.ucs.indiana.edu>, robelr@bronze.ucs.indiana.edu (Allen Robel) writes:
> ...
> >No, I fear the eminent McQuillan may have mis-spoken this time. (Or you may
> >have mis-quoted perhaps?)
>  
> 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.

I think most applications do not use symmetric flows of data.  That
"100 Mbs ATM delivers" almost two links, each slightly less than one
"100 Mbs FDDI" link is interesting, but not important for current
applications.


By the way, Rob is not quite right about the ratio of TCP ACK's to TCP
data segments in 4.3BSD-reno TCP/IP stacks.  2:1 is what you commonly
see between machines of similar speed on a medium that is not
saturated.  That ratio can be 1:1 if the receiver is very much faster
than the sender and/or the medium.  I have seen the ratio (at steady
state, moving 10's of GB over FDDI) above 8:1 when the receiver is the
bottleneck, not the medium or the transmitter.

For example, when the FDDI ring is at 100% utilization (ie. token
latency at several milliseconds) when an R4000 based Indigo is sending
to an R3000 based machine, the ratio is just under 3:1, at least on one
test ring of around 5 usec latency.


Vernon Schryver, vjs@sgi.com
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Computers dont like ATM?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 20 Nov 1992 09:01:16 GMT

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
| standards is putting the cart before the horse.
+---------------

Especially when end-to-end "ATM compatibility" can be achieved *without*
ATM-sized cells in the LAN! I have been harping on an idea I call "fat cells",
which is basically that you switch AAL_PDU-sized packets in the LAN, with
exactly one ATM header on the front of the AAL PDU. When the packet is to be
routed out of the LAN via "real ATM", as it chops it up into real ATM-sized
53-byte cells, the gateway switch can replicate the prototype header onto the
front of each cell. (For AAL5, it must also set the "end-of-frame" indication
in the header of the last cell in the PDU.) Naturally, it is also the respon-
sibility of the gateway switch to reassemble incoming cells into PDUs (leaving
a prototype ATM header on the front), and switch these "fat cells" (complete
AAL PDUs) into the LAN.

Think of it as transparent bridging between "cell relay" and "ATM-formatted
frame relay".

Since AAL1 & AAL2 traffic don't have natural "PDU" boundaries, you could
set an "aggregation ratio" at call-setup time, that says how many cells
should be included in each "fat cell" on the LAN.

The fun thing about "fat cells" is that a native-mode ATM terminal at the
far end of the circuit cannot tell that you are sending/receiving "fat cells"
instead of 53-byte cells!

Another fun thing is that we could easily "tunnel" or encapsulate fat cells
inside other protocols such as IP [the *inverse* of using ATM to encapsulate
packets], to provide access to "native ATM" for many, many hosts without ATM
interfaces! So much for "end-to-end ATM compatibility" requiring hardware
changes...  ;-}

+---------------
| I have great reservations about what ATM costs us in LANs.
+---------------

Likewise, but more for the dampening effect it's already having on alternative
technologies (such as PTM, or gigabit "frame relay", or "fat cells", etc).

+---------------
| When ATM-based LAN performance exceeds PTM-based LAN performance/cost,
| ATM proponents will have a much better argument than they now have. 
| Frankly, I don't forsee that happening in the electrical domain.
+---------------

Well, I do, actually. Sliding down the price/volume curve, and all that...
Two-chip solutions that go from AAL PDUs to ATM cells to SONET line coding
(and back) are not that far away, at least at 155 Mb/s.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: lampard@titan.trl.OZ.AU (Greg Lampard)
Subject: Computers dont like ATM?
Organization: Telecom Research Labs, Melbourne, Australia
Date: Wed, 18 Nov 1992 02:57:54 GMT

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.
He also seemed to be suggesting that this storage and retrieval process
could become a bottleneck (at 100s of Mbit/s?) because of the limitations 
of memory bandwidth.  He was advocating variable length packets (an idea
called PTM - packet transfer mode - that IBM has proposed), because it
puts the complexity in the switch rather than in the receiving
terminal. 

From this, his conclusion was (I think) that ATM is good for switching
voice traffic, but not so good for computer networks.  This seems to go 
against what's actually happening, with people building ATM LANs while 
telcos hang back, not sure if ATM is the right way to go.

I guess I should also say (in case it isn't obvious) that I don't know
much about protocols, LANs etc., but I am interested in the direction
that LANs are going.  Any knowledgeable people out there care to comment
on the above?

Greg.
---
Greg Lampard                    | Showing you how you can turn your old
Telecom Research Laboratories   | nuclear physicist into a brand new
g.lampard@trl.oz.au             | communications engineer.
From: wainner@Pt.hq.af.mil (Scott Wainner)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Computers dont like ATM?
Date: 22 Nov 92 05:00:11 GMT
Organization: Headquarters Air Force, The Pentagon Washington, DC

lampard@titan.trl.OZ.AU (Greg Lampard) writes:

> Paul Green statements: 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.

It is true that 53 bytes is a nuisance to the computer.  The computer
industry proposed a 69 byte cell (ie 64 byte payload) but a compromise
was made with Europe which wanted a 32 byte cell.  So, we get a 44 or
48 byte payload depending on the AAL used.  I think 48 seems logical
since it's a multiple of 8 bytes.  The reason for the fixed cell size is
to minimize buffer requirements in the switch.  Since all the cells are
the same length, the switch can process the cells in "parallel".  The
other benefit of fixed size cells is that it may be implemented in 
hardware that will perform frame reconstruction must faster than
software processes.

>He also seemed to be suggesting that this storage and retrieval process
>could become a bottleneck (at 100s of Mbit/s?) because of the limitations 
>of memory bandwidth.  He was advocating variable length packets (an idea
>called PTM - packet transfer mode - that IBM has proposed), because it
>puts the complexity in the switch rather than in the receiving
>terminal. 

Exactly, we're trying to make the switch faster by eliminating the
protocol processing and implementing the switching in hardware.

>From this, his conclusion was (I think) that ATM is good for switching
>voice traffic, but not so good for computer networks.  This seems to go 
>against what's actually happening, with people building ATM LANs while 
>telcos hang back, not sure if ATM is the right way to go.

I think ATM has great merits but I'm not quite sure how fault tolerance
will be introduced in the network since we're using VCIs and VPIs to 
perform the routing. Is this static once the call setup is complete?
How does the switch know to reroute a failed connection without forcing
the application to "reopen" the path.


>Greg.
>g.lampard@trl.oz.au             | communications engineer.

Scott Wainner
swainner@tasc.com.
Communications Systems Engineer
From: jstone@netcom.com (Jeffrey Stone)
Newsgroups: comp.dcom.cell-relay
Subject: NT1/NT2 question (2nd time around)
Date: 19 Nov 92 16:08:21 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

A few days ago I posted a question about NT1/NT2 and have received
no responses so far.

Here it is again.  Any help will be appreciated.

Can anyone out there please enlighten me as to the meaning of
NT1 and NT2 in the context of CCITT's BISDN recommendations. 
Also S & T interfaces.

I have asked a number of people this question and have received
rather confusing answers.

Cheers,
Jeff

-- 

Jeffrey Stone		jstone@netcom.com		415.324.0443
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Chips
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 18 Nov 92 19:18:54 GMT


>
>A comment on the PHY layer interface:  We are developing a very 
>low cost STS-3 PHY interface for the LOCAL interface, with
>sponsorship 
>...
>a host 
>of other companies (16 in total).
>....
>
>The SUNI chip, as we call it will sell for less than $50.00 in
>volume.
>It integrates complete SONET framing, ATM cell processing, FIFO
>buffering,
>complete diagnostic and performance monitoring functions, and high
>speed
>serial interface (155 Mbit/s) in a single chip.
>
>A complete port card using a twisted pair interface will cost about
>$70.00
>for the components.

Will this be available on an equal basis to all hub vendors?  Is there
an independent VLSI company associated with this chip whose sole motivation
is an ever widening market?  Is special information going to the supporting
vendors, before the smaller hub vendors have access to the specifications?
Can we all receive e mail on any design material which is also being
shared by the supporting vendors?
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Solving a Problem
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 16 Nov 92 20:32:47 GMT

Coping with Embedded Processors:

The problem we have is that many of the newer applications, and
the backward support of the older PC applications involve placing
some auxiliary processors in the switch; IE routing, distributed disk 
controllers, audio processing and protocol conversion.

Some of the new applications require only access to a switch resident 
path control system; IE transaction routing, distributed data base,
address discovery, process discovery.

The auxiliary processors allow the building of distributed protocols,
using a dynamic network architecture.  The binding utilizes the
virtual path; and the discovery and collection of objects utilizes 
a wavefront discovery process.   The science of dynamic networks
has developed in the operating system world, (see ACM Trans
on Comp Sys, May 1992 for a distributed protocol concept based upon
the x kernel).


For switch vendors the third party supported embedded processor
does not fit well with distribution channels to which they are
accustomed.  Perhaps the better approach would be to extend the
virtual path concept into the new unix multiprocessors, essentially
solving the same problem from the other direction.


If the path definition was extended into the multi-processor, then
discovery and arbitrary connection of operating system "objects"
would be seemless across the cell-relay to multi-process boundary.
The cells, reassembled at the interface, continue their movement
in the multi-processor guided by object linking ID's which are
mapped to the virtual path.  The construction of distributed protocol
contexts utilizes the wave method; operating as the meta language over
both the network and the multi-processor, with its interpreters placed
both in the switch and in the processors.  In both instances the wave has
capability to create binding paths.

Advantages:

  The workstation vendors could activate an already existing channel
of developers.  The desktop obtains direct control of distributed
object linking, supported across the hub with switched paths.  The
problem of host based addressing standards is returned to the computer 
vendors, who have dealt with it more successfully than the communications
vendors.  The switch vendors do not have to expose their architecture
to third party add on developers.

Disadvantages:

  Much of the work on object oriented linking would have to be re-cast
to support the new virtual path networks resulting in a new standards
conflict.  The meta language control system chosen needs to be supported
on both sides of the network interface.
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: Tue, 24 Nov 1992 04:35:19 GMT

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

>hmmph!  Let's not chop nits.  I was only trying to point out that there
>exists an interpretation of the quote that is entirely true, and that
 
Vernon, if I came across sounding like I was chopping nits I didn't
mean to.  If you knew me you'd know that's not my nature.
 
>    -I understand that all current ATM-LAN's use fixed and permanent
>        curcuits among all hosts.  That seems unlikely to work in a
>       real LAN of hundreds of TCP/IP hosts, all coming and going.
 
[other stuff on other "more interesting" ways to compare FDDI and ATM
 deleted]
  
In my original post, I wasn't trying to deride FDDI (we've got a 
3 ring FDDI campus backbone that's served us quite well up to now).  
I was only trying to clarify something over which I was genuinely
confused.  Which is, is there an easy way that a network manager
can determine a point at which FDDI (current implementations
like ours) starts to become less efficient at delivering
bandwidth than ATM?  Or, if not an easy way, at least some
general parameters to consider.  I really didn't intend to
start an extended ATM/FDDI benefits/drawbacks kind of discussion
(but now that this thread has turned out that way that's
OK too...)
 
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
Newsgroups: comp.dcom.cell-relay