HDTenEightyP/NetNews huggingface dataset:
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: AAL5-CRC32
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 4 Sep 1992 18:30:18 GMT

de@fokus.gmd.de (Dirk Elias) writes:
+---------------
| I've got some questions and comments concerning AAL5-CRC32 calculation.
| 
| 1. Does anybody know something of fast software algorithms to compute CRC32?
| The fastest I know is based on look-up tables and will take 16 instructions
| per 32 bit. This results in about 70 MIPS for a bitrate of 150 Mbps!
+---------------

Well, the fastest byte-at-a-time method I know (with a 1024-byte table) is:

	for (i = 0; i < size; ++i)
		crc = (crc >> 8) ^ table[ (crc & 0xff) ^ data[i] ];

That's about 9 cycles/byte (or more), or 36 cycles/word. I suppose you could
cut that in half if you used a 256 KB table and did it 16 bits at a time.

+---------------
| Definitely to slow. So, if there is no possible software solution, let's 
| take a look on the hardware, exclusively for AAL5-CRC32. You will need a
| CRC-chip and glue-logic, consuming "lots" of board space and wasting power
| for almost nothing!
+---------------

Why do you say "lots" of board space? A similar parallel algorithm can be
done is a small gate array, in less space than the buffers to drive the
host bus.

+---------------
| ...there are two major ways to calculate CRC by hardware. One is "on-the-fly"
| while receiving a cell from the ATM layer... I just want to point out that
| "context-switching" after every cell is lots of work, just to calculate CRC.  
+---------------

BUT YOU HAVE TO DO IT ANYWAY! You have to extract a *lot* more "context" per
cell than just the previous CRC. You need the buffer pointers & counts (or
limits), descriptor-ring pointer (for some architectures), etc. The 32 bits
for the CRC is "just" another pair of "by 16" SRAMs, indexed the same way
as all the rest.

+---------------
| Has anybody knowledge of CRC hardware, performing "context-switching" on
| it's own? (something with integrated memory and some kind of control
| interface)
+---------------

Again, you have to do it anyway. Tacking the CRC task on the side is a fairly
small thing...

+---------------
| the other is "fly-by" upon transmitting a reassembled packet from the AAL
| layer to the next higher layer... If I would like to have about 100 VC's
| using AAL5 and I had to store every packet till it's completed, I would
| have to allocate 64 KBytes for every VC.
+---------------

Memory's cheap.

+---------------
| Since there is still no CPCS-PDU header defined for AAL5, where a packet-size
| information could be transmitted, I have to assume the maximum CPCS-PDU size!
+---------------

Not necessarily. You could allocate "chunks" of buffer as the cells arrive
(a simple linked list).

+---------------
| This would result in several MBytes of interface-board memory. (Sometimes
| I remember that S-BUS card size in my nightmares)
+---------------

It's small, but so is "several MBytes" of RAM.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu>
Subject: Re: >>>>Future of IP routers
Organization: Indiana University
Date: Mon, 31 Aug 1992 20:35:00 GMT
X-Vms-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

Vernon - Why does the TCP sender have to wait for two token circulations
before it can recapture the token if it passes it on due to timer expiration.
I am assuming that the TCP sender is an asynch application rather than a synch
application (in FDDI terms), so there is no "guaranteed" bandwdith.  But
even in that case, if the token arrives "early" during the next rotation,
why can't the TCP sender seize it?

/gary kessler
kumquat@smcvax.bitnet
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: 'nclatm' document
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 06:10:51 GMT

craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
+---------------
| I've been looking at the document 'Network Compatible Local ATM'
| published by Apple/Bellcore/Xerox/Sun, dated 3 April '92.
| 
| Can anybody tell me how the Data Transfer AAL layer described in 
| this document relates to the AAL 5 or other 'official' AALs  
+---------------

It *is* AAL5, you just have to read the spec very carefully to see that.

See the Section 5 introduction [page 57], where it says, "This AAL...builds
on the work presented to Committee T1 in contribution T1S1.5/91-449 [20]".
Then you read the referenced footnote, which says:

   [20] ANSI Committee T1 Contribution T1S1.5/91-449, "AAL5 -- A New High
        Speed Data Transfer AAL", IBM et al, November 1991, Dallas Texas

Of course, one might happen to know that Tom Lyon of Sun wrote the first
draft of AAL5 (then called "SEAL") based on work by Xerox/WashU/MIT/Apple,
and that the 91-449 AAL5 document lists Apple/BBN/DEC/IBM/Motorola/Sun/Xerox
as contributors, and that the NCLATM spec was by Sun/Xerox/Apple/Bellcore,
but that would be cheating... ;-}


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: icarus!mbu@fokus.gmd.de (M. Burak)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 31 Aug 92 09:12:18 GMT
Organization: GMD-Fokus (Berlin)

gja writes:

>ATM, meaning AAL1 through AAL5 (and not including I.364, CCITTs
>connectionless service), is layered underneath protocols such as IP.
>It is not positioned to replace them.

I agree with this statement but would like to add that CLNAP can also be used
underneath protocols such as IP. CLNAP can be used as a MAC like service
(comparable to the MAC service defined by 802.6) with the exception, that 
E.164 addresses have to be used instead of 48 bit addresses. 
In my opinion this does not exclude to use IP over AAL type 5 directly.
Which is better, I can not deceide.

Brian Carpenter writes:

>Sorry, as usual CCITT and their friends are too far behind reality.
>IETF and the ATM Forum will have resolved all these questions before
>CCITT even formally votes on AAL5.

Sounds very good. But please tell me how will IP work over an ATM network with
AAL type 5? What is the concept of this approach? 
Is connection setup required prior to sending CL-data or do you assume a fully
meshed network? What function in the ATM network will perform routing of IP packets if you 
only have ATM switches providing an ATM layer? 
I have no idea. Is there anybody who can help me to answer these questions?

Craig Partridge writes:

> But there's no need to make poorly documented comments about the performance 
> of IP to justify ATM.

I never wanted to justify ATM by making poorly documented comments about the performance
of IP. My question was, does it make sense to limit the discussion to IP only and is IP
the right choice to use over ATM, is the performance good enough (I dont't have alternatives
except for XTP which is in the software version without tuning not much better in the performance than IP). 
This question was  answered by several people writing that IP is faster than I personally ever imagined and our results showed. I think that IP will live a long time as a protocol on top of the AALs (whatever AAL you want) and I think that B-ISDN will provide a multi-protocol environment. But as aforementioned I don't know how IP will work on top of ATM especially by using AAL type 5 because this AAL offers 'only' a connection oriented mode.


--
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
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Paths Revisited
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 1 Sep 92 16:43:41 GMT


|> 
|> For a user connected to an arbitrary local ATM switch it is unlikely
|> the DNS will be able to return a VCI/VPI pair having any meaningful
|> value. The VCI/VPI which finally carries IP packets into foo@bar.sna.fu
|> will be different to the the VCI (and/or VPI) that any given user
|> needs to send packets to their local ATM switch on.
|> 
> As you've indicated, a VCI/VPI pair is only meaningful between host and
> first switch. At the switch it's translated into a different VCI/VPI. 

Examine this basic assumption.  In private networks, it is likely that
a few vci/vpi pair values will be reserved for global usage.  Also it
is likely that departmental enterprises will be granted some permanent
VCI pair for use over their geographic domain. Thus some VCI will have
global functions though not necessarily associated with a particular 
host.

We agree that the VCI is a local pointer only, generally only valid on
a temporary scale, but the use of virtual paths does solve a host of 
customer problems directly.  Super computers have been based upon virtual 
paths (look at some transputer architectures).  However, these 
supercomputers allowed self-routing and track building by the application 
themselves, the applications actually becoming migratory.
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Bare Bones Adaptation
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 2 Sep 1992 08:15:34 GMT

young@bantha.decnet.lockheed.com writes:
+---------------
| I have a question on the "lean mean" AAL5 adaption layer:
| 
| Does this definition cover only the begin and end of message 
| indication, leaving the byte count and checksum to be handled
| by the application specific upper layer?  
+---------------

Not quite. AAL5 includes a 16-bit byte count and CRC-32 in the
last (marked) cell of each frame, plus enough pad bytes so that
the count & checksum are always at the end of that last cell
(so you can find them easily).

+---------------
| For instance, let's say I am collecting arbitrary uncompressed audio 
| from a continous source. With this application, I really have no checksum 
| requirement, no message boundaries, just collect bytes.
| Is this the bare bones adaption layer? 
+---------------

You might prefer to use AAL1, I think...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: dm@cl.cam.ac.uk (Derek McAuley)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Bare Bones Adaptation
Date: 2 Sep 92 22:28:15 GMT
Reply-To: dm@cl.cam.ac.uk (Derek McAuley)
Organization: U of Cambridge Comp Lab, UK

In article <1992Sep2.043325.2784@adaptive.com> george@hal (George Marshall) writes:
>>Is this the bare bones adaption layer? 
>
>For a continuous bit stream source as you described, there are other
>(simpler?) adaptation layers defined/contemplated:
>
>AAL1 (Class A) is a "Constant Bit Rate" AAL; this AAL is intended for 
>use in emulating a real (as opposed to virtual) circuit service; 

A *real* circuit; what you mean I can get 5 volts down it |-)

Seriously, is AAL5 *the* bare bones adapt(at)ion layer, or did it
simply force the CCITT to realise they hadn't solved all the worlds
future networking problems with AAL1/2/3/4, and hence couldn't get
away with defining the BISDN UNI and signalling in these overly
simplistic terms? (Rhetorical.)

In UK political terms I think AAL5 would be referred to as a Stalking
Horse.

Mac.
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Another Problem
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Sun, 30 Aug 92 16:42:26 GMT

This newsgroup continues to debate the interface between TCP/IP routers
and ATM. Must be an important application.

Now here is another problem which ATM might solve.

As I look around this company I see hundreds of little cubic foot computers
on each desktop, exactly alike, distributed geographically.  Some companies
literally have thousands of these things.

Imagine that an account executive wants to read into his spread sheet the
entire daily summary of mail orders spread over a number of distributed
offices.  Thus, he wants to extract a particular file located in each of
a large set of desktop machines.  

Here are some restrictions to the solution:

1) This problem applies to about 80% of the USA's largest companies, who
spend some 1 trillion dollars on solutions each year.

2) The only host address this account executive wants to deal with is 
"computers on the desktops of account clerks".

3) This company swears by twisted pair wiring, as do 80% of all users.

4) This applications requires low latency.

5) This customer would prefer to have his entire computer system composed
of the distributed coordination of these small machines, he hates 
mini/maxi/mainframe computers.

6) This customer hates the hassle of maintaining servers, although he is 
willing to tolerate some file backup facilities.
From: pagels@cs.arizona.edu (Michael A. Pagels)
Newsgroups: comp.dcom.cell-relay
Subject: Out of order messages
Date: 27 Aug 92 15:56:49 GMT
Organization: U of Arizona, CS Dept, Tucson

This is a simple question, but I can't seem to track down
a definitive answer:  Is it possible for ATM cells when
providing a connection based service to become out of order
after traversing multiple switches?  Some specifications
start from either answer in their development of protocols.
I suspect the answer revolves around the ability of the
switches to maintain order, or if they can reroute connections
after setup time.

Thanks in advance.

Michael
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 1 Sep 92 12:58:38 GMT
Organization: Naval Research Laboratory, DC

In article <1992Aug31.151529.26275@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:

>The public ATM network will presumably have the same level of 
>switch and route redundancy as current telco networks
>and so an alternate route should be available if a switch fails. The overhead 
>in re-establishing a connection will be small and I presume the rate
>of switch failure will be small also. These are the sort of things that
>only experience will show.

Call-setup overhead will likely be expensive.  Just consider the speed
of light (i.e.  minimum) delays in call setup for a long-haul (e.g.
Virginia to California transcontinental link) and figure one
round-trip for the call setup.  That isn't a trivial amount of time
relative to data transmission rate.  Experimental evidence in existing
telephone switches and ATM switches is that the call setup delay is in
fact not small.  Similarly, telephone switches fail surprisingly often
-- though with fast recovery times.

Don't get me wrong.  ATM might be a wonderful technology.  However, it
is important that we look at it realistically and design to account for
the potential technical hurdles of ATM.  I'm sure ATM can be done right
-- I'm not sure that the world will do ATM right.

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: >>>>Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 05:17:27 GMT

In article <p9jiflk@sgi.sgi.com> I wrote:
+---------------
| vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
| +---------------
| | If the token was released because the timer had expired, the token will
| | have to go around the ring twice before the TCP sender can recapture it
| | and resume sending. During all of that time, the TCP sender is unable to
| | send any data.
| +---------------
| 
| Good point, Vernon. This is often forgotten. However, it only applies if
| there are other people on the ring also trying to send at full speed. If
| there is no-one else on the ring sending, or if the others only send a small
| amount, you may well be able to send *some* data on the next rotation --
| though not a full T_Opr's worth.
+---------------

(*blush*) Open mouth, insert foot. Vernon was completely right in the first
place. The token *does* have to go around twice before we can send again if
the TRT expired while we were sending. I forgot that the "late_cnt" is set
even in state T2 in transition T(23) [Transmitter state diagram Footnote #10].

Sorry 'bout that...


-Rob

p.s. But I was still correct (and Vernon would agree) that in the "many-
senders" case, the token may have to go around "number_of_active_stations"
times (plus 1?) before we can send again.

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: AAL 5 query
Organization: University of Strathclyde
Date: Wed, 2 Sep 1992 12:11:22 GMT

Can somebody perhaps clarify my understanding of certain parts of AAL5:

I'm looking at the situation where a host requires to have more than one 
VC open at one time. In this case, one AAL entity is required for each
connection. ATM-SDUs from each AAL are multiplexed/demux'd by a single
ATM layer entity in the interface. This gives the following structure for 
the interface:

			 ATM physical connection
				    |
				    |  
				ATM entity 
				|   |   |
			       AAL AAL  AAL
				
				   CPU



In order to transfer information across a virtual connection, the user layer
passes a MAAL-CREATE.request primitive (with the far end ATM_CEI and
AAL_CEI as parameters) to initialise new AAL state machines for a new AAL 
entity. 

There is no primitive that is passed from the MAAL (or AAL) entity to the ATM
layer which says "a new connection is being created, please assign a new
VCI/VPI pair for use with this AAL and associate cells to/from this 
VCI/VPI pair with this newly created AAL entity.". 

As far as I can see, this means that the ATM layer is unable to demultiplex
cells to the correct AAL entity, since firstly, the ATM layer doesn't know
which VCI/VPI corresponds to which AAL and secondly, there is no parameter
in the ATM-DATA.indicate primitive to identify a unique AAL entity to 
which each ATM-SDU should be passed.

A similar problem occurs when multiplexing outgoing cells at the ATM layer,
because multiple AAL entities will pass cells to the ATM layer, but without
any parameter to say which AAL they are from.

This seems to mean that	without some
method of identifying which AAL entity a VCI/VPI pair's incoming cells should 
be sent to, only one connection i.e. one VCI/VPI pair can be supported on any
interface using this scheme. 

Was this deliberate in order to simplify the document, and such an association 
is left for the reader to infer, or am I missing something very basic?

Help would be appreciated.

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K.
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 26 Aug 92 21:28:18 GMT
Followup-To: comp.dcom.cell-relay
Distribution: na
Organization: Naval Research Laboratory, DC

In article <1992Aug26.092945.4663@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:

>In the telco scheme of things, security is a problem which handled by the 
>network, when a call connection is set up.

  Actually, the telcos don't have ANY security in their call setup
protocols.  Go read the CCITT documents and be disappointed -- I was.
Signalling System 7, widely used by telcos and specified by CCITT,
could really stand some minimal authentication at call setup time.

>IP is designed to be processed in software, not in silicon, and 
>this may mean there is no easy way of carrying out the filtering you suggest.

  I'm sure that Protocol Engines, Inc. would be very pleased to sell
you custom silicon for TCP/IP off the shelf today.  They would much
rather have you use that silicon for XTP, but they would still be
happy for you to use it for TCP/IP (followups to this paragraph belong
in comp.protocols.misc).

>Because routers are store and forward, I would have thought that time critical
>traffic such as video/audio traffic would be very difficult to pass across a
>router at high speed. Since the telcos are billing ATM as ideal to carry
>multimedia traffic, this implies that the idea of using ATM routing at the
>network level is more suitable for high speed multi media traffic than IP.

	Curiously enough, off the shelf IP routers (e.g. CISCO AGS+)
coped remarkably well with the IETF videocast from Boston in July.  
I was in Boston, but the simulcast had a local terminus (thanks Allison !)
and the folks who saw it found it quite useful and thought quality was OK 
if not great.

	Claims that one cannot do multimedia over IP look kind of
silly when you have seen real-time voice/video over today's Internet.
Given some tweaking of things, I'm quite sure that better quality and
performance is possible while still using a connectionless network
protocol and doing routing at the network layer.

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: >>>>Future of IP routers
Organization: CERN European Lab for Particle Physics
Date: Mon, 31 Aug 1992 13:44:24 GMT

In <1992Aug28.164008.4015@sics.se> craig@sics.se (Craig Partridge) writes:

>I'm seeing a recurrent thread of silly comments about what IP can and
>cannot do, often based on dubious benchmarks.
> 
...
> 
>Based on the trends (of which these results are simply the leading edge),
>there's every reason to believe that TCP can operate happily at gigabit
>speeds and that IP routers will happily forward IP datagrams at gigabit
>speeds sometime in the future.  That's probably true of CLNP and TP4
>too.
> 
Always dangerous to question what Craig writes, since he usually
turns out to be right. But surely you agree that TCP (original version)
will slow down when the delay-bandwidth product exceeds the maximum
window - otherwise Van Jacobson would not be writing all these RFCs...
But this is nothing to do with Gbits of course, a 2400 baud line to
Andromeda would have the same problem. (Hence my obsession that Craig
already knows about with the transit delay of ATM switches.)

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: high speed protocols
Date: 25 Aug 92 16:35:41 GMT
Organization: Naval Research Laboratory, DC

In article <1992Aug25.095003.10307@funet.fi> jjk@cs.tut.fi (Karttunen Jari Juha) writes:
>
>I am looking for specifications and papers of high speed
>transport and network layer protocols such as XTP, VMTP,
>Hippi, Stream Protocol and Packet Video Protocol. 

  You've at least mixed apples and oranges above.  HiPPI is a link
protocol not a transport or network layer protocol.

  Many of the above are documented in RFCs online at an archive site
near you and obtainable via anonymous ftp.  The current XTP spec is
available in Postscript from sgi.com via anonymous ftp.


Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.dcom.cell-relay