HDTenEightyP/NetNews huggingface dataset:
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Future of IP routers
Organization: CERN European Lab for Particle Physics
Date: Fri, 28 Aug 1992 15:57:03 GMT

icarus!mbu@fokus.gmd.de (M. Burak) writes:

>Randall Atkinson writes:

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

>Do you really think that TCP/IP over B-ISDN will be the real challenge? As far
>as I know, TCP/IP allows you a throughput of 28 Mbit/s over a 140 Mbit/s network.
>I don't think that this will be the ultimate protocol performance for high speed networks.
>Isn't it better to use faster and probably new protocols on top of the B-ISDN protocol
>stack?

The discussion is about IP, not TCP. It could equally well be about
CLNP, or IPX. IP will limit you to 70% or so of raw ATM bandwidth
(depending on what assumptions you make about AAL overhead and average
packet size).  Then you have to think about transport overhead, but
that's a completely independent discussion. Now to get religious:
if you use AAL3/4 then you can use a very lightweight transport but
if you use AAL5 you'll need an error-correcting transport such as
Extended TCP, TP4 or XTP. Current TCP is certainly inadequate, as its
designers are the first to admit.

>Another point is that I don't understand the whole discussion about IP Routers. Nobody
>writes that in the B-ISDN there will be Connectionless Servers, taking care of routing
>*and* security and address screening and all other management related stuff. Or are 
>you talking about setting up connections like for video/audio services using AAL type 5?
>If the latter is right than the discussion seems for me ok but if you are talking of an 
>public ATM network as envisaged by CCITT then you have the CLS and AAL type 4. Please
>tell me if that's right or not.

Well, SMDS and CLS already show every sign of being as irrelevant to
the real world as CONS or ISDN :-). Once I get a private or public
ATM connection (a 155 Mbit UNI or NNI plug in my modem room), _I_ will
decide which AAL I use and how I use it.

The argument about routers has been raging also on the IP-over-ATM
working group list (my fault!). My personal conclusion is that in some
cases IP hosts will establish end-to-end VCs to peer hosts, and other
cases they will talk to a router. Some combination of DNS and ARP will
tell them which to do. Routers _must_ exist of course, e.g. as gateways
to the non-ATM world, but should be bypassed for efficiency whenever
possible. There are specific proposals from the IP-over-large-public-
data-networks working group for shortcut routing.

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.

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: 'nclatm' document
Organization: University of Strathclyde
Date: Mon, 31 Aug 1992 14:13:25 GMT

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  
i.e. is this AAL proprietary and hence bears little relation to 
the official AALs. 

Also what are the full titles of the official AAL documents and where 
can they be obtained?

Thanks.

-- 
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. 
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: >>>>Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 31 Aug 1992 01:24:53 GMT

In article <1992Aug30.194536.2545@amd.com>, shah@angelo.amd.com (Amit Shah) writes:
> >
> I have a slight disagreement with your statement that FDDI TTRT by itself
> does not matter.  It depends on the type of traffic you put on the network.
> If you are talking about bursting traffic in excess of 100 Mbps (such as
> high-end imaging), with >2 stations on the ring then the
> TTRT does matter (Lower TTRT will have lower throughput and buffer overflows).
> 
> However, if you are talking about normal traffic (burst rates not exceeding
> 100 Mbps) then you are correct within a few percent points.


I beg to differ, although I have few kind words for those who force
customers to have stupidly tiny TTRT's instead of following .

In no case can an old-fashioned, non-Large-Window TCP/IP sender
transmit more than 64KBytes without allowing the TCP receiver a chance
to transmit at least one ACK.  In other words, the token must be
released by the TCP transmitter at least once every 5.2 milliseconds.
The obvious way to send TCP data in steady state is to arrange for one
ACK per half of the TCP window, or one ACK every 32KB, or one token
rotation every 2.6 milliseconds.

While the token is rotating, no data is being transmitted.  Therefore,
if your ring latency is large, you might choose to transmit 64KB and
then wait for one (burst of) ACK(s) every 5.2 ms, in the hope that your
transmitter's latency in resuming TCP transmissions is less than the
cost of the dead time.  If your systems are fast, this is a reasonable
hope, since ring latencies can be up to 1.67 ms.  If you waste 1 ms on
token rotations every 2.6 ms, you are not going to get close to the
speed of light, which is around 97Mbit/sec.

Please notice that 2.6 ms is far lower than the minimum universally
legal TTRT, and even 5.2 ms is not significantly larger than the silly
and very wrong (in my opinion) TTRT imposed by default by one large
vendor.

I agree that a small TTRT with a large or even modest ring latencies
have bad effects on massive UDP output rates.  However, I do not know
of a realistic application for sending megabytes of UDP data.  That
`ttcp -u` gives such UDP numbers does not by itself make them
interesting.

These assertions are not based on readings of standards.  I haven't
played with 1 ms ring latencies, but I have spent time with the other
circumstances I have implicitly described.


Vernon Schryver,  vjs@sgi.com
From: wbe@bbn.com (Winston Edmond)
Newsgroups: comp.dcom.cell-relay
Subject: Re: high speed protocols
Date: 25 Aug 92 14:29:45
Organization: Bolt Beranek and Newman, Inc., Cambridge, MA
NNTP-Posting-Host: crystal.bbn.com
In-reply-to: jjk@cs.tut.fi's message of Tue, 25 Aug 1992 09:50:03 GMT

jjk@cs.tut.fi (Karttunen Jari Juha) asks:
   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. 

   Jari Karttunen
   Omnitele

The Stream Protocol version 2 (ST-II) specification is available as RFC 1190.
Get "RFC:RFC1190.TXT" via anonymous FTP from NIC.DDN.MIL, or, if you can't
FTP it, send a message to SERVICE@NIC.DDN.MIL with "Subject: RFC 1190".  The
RFC is about 378K characters long, and prints as 152 pages.  Here are the
first few lines:
---------------------------------------------------------------------------
Network Working Group                                  CIP Working Group
Request for Comments: 1190                           C. Topolcic, Editor
Obsoletes: IEN-119                                          October 1990


        Experimental Internet Stream Protocol, Version 2 (ST-II)
---------------------------------------------------------------------------

I've been told that the Packet Video Protocol (PVP) spec. does not exist in
on-line form, but there is a paper version.  We can send you a copy if you
give us a postal address to send it to.  Please send the information and your
request by email either to (kseo@bbn.com and aveitch@bbn.com) or to
(casner@venera.isi.edu).
 -WBE
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Problem to Solve
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 27 Aug 92 16:28:51 GMT

A Real Problem.

System managers are probably not concerned about overuse of video
on the new networks, video is way down on their list of priorities.

However, here is one very big problem which cell relay helps solve:

In our department we work in distributed documents which are integrated
from the work of multiple scientists, using document links.  These scientist 
travel quite often, and they carry their part of the document with them in 
little small inch disks, using whatever local PC they find.

This work is judged in our market place on an hourly basis, that is I
allways want the latest version, even though its an hour old.  The only
real address these smaller units have is their disk name and file name,
I do not know the address of the current PC on which the scientist is 
working.

Now cell relay offers me something called virtual networks, which can be
re-shaped as new nodes are taken off and put on.  So what I need to do is
break with the traditional network addressing scheme, replace it with the
concept of virtual spanning trees.  Then in addition I need an interpretable
protocol which can "ride" this virtual spanning tree locating the appropriate
document components by disk and file name.

Microsoft is butting right up against this problem as we speak.  The solution
is related to a combination of a virtual path network architecture, object
oriented linking, and virus technology.

Novell and IPX can't solve this.
IBM and System Network Architecture can't solve this.
TCP/IP doesn't help.

How does cell relay help with this problem?
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: followup to reordering thread
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 05:08:02 GMT

brian@dxcern.cern.ch (Brian Carpenter   CERN-CN) writes:
+---------------
| Another (very minor) disagreement with Craig. You should compute
| the AAL CRC on the fly as the cells arrive, not after the last cell.
| (I'm assuming you have hardware assist of course.)
+---------------

Basically, I agree with you. One doesn't want to waste either the bandwidth
or the latency of another pass over the data just for the CRC. However, there
exist reasonable potential architectures for an ATM interface for which one
might *not* want to do the CRC "on the fly" at cell-arrival time, since that
involves fetching the old CRC from the per-VCI "context", shifting in the
new stuff (8, 16, or 32 bits at a time), and then saving the new CRC in the
per-VCI "context" -- once per cell.

Depending on the bandwidth and latency to the VCI context memory, and on
the cost of the SAR part of the interface, one might wish to defer the CRC
calculation until the whole packet is being DMA'd to the host and do it
in fly-by mode then (without context changes), for example. Costs nothing
in added bandwidth or latency, and is potentially cheaper. (But also has
the limitation that one must be willing to go ahead and DMA a packet with
a potentially bad CRC. Tanstaafl.)


-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: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: followup to reordering thread
Organization: CERN European Lab for Particle Physics
Date: Mon, 31 Aug 1992 13:55:21 GMT

Another (very minor) disagreement with Craig. You should compute
the AAL CRC on the fly as the cells arrive, not after the last cell.
(I'm assuming you have hardware assist of course.) Otherwise, yes,
switches cannot re-order ("Cell sequence integrity on a virtual channel
connection is preserved by the ATM layer." - CCITT I.150, page 1.)
and AAL5 is simple.

  -- Brian

>> 2) If no re-ordering occurs, does that mean that all I have to do
>> is collect the sequence of cells that have arrived on a VCI/VPI pair,
>> perform some application (TCP,TP4 etc) dependent error control on the
>> assembled packet, then just use the data (if re-transmission not needed).
> 
>Yes.  You receive cells and store them sequentially in a buffer.  When
>you have a complete PDU, you do the AAL CRC, and pass the packet up to
>higher layers.  
> 
>> If the adaption layer is that simple under the no-reordering rule, then
>> why not pay the price in additional switch sophistication and get the
>> huge return in having a much simpler adaption layer?
>>
>> If re-ordering is then not allowed, then doesn't it make sense to have
>> a end-of-message, begin-of-message bit in the cell header?

>Yes.  That's what AAL 5 is all about.

>Craig

Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: >>>>Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 29 Aug 1992 16:43:08 GMT

In article <1992Aug28.164008.4015@sics.se>, craig@sics.se (Craig Partridge) writes:
> ...
> (any FDDI throughput test over a real ring that doesn't mention the TTRT
> that the testers set for the network is worthless) ...

While I agree with the rest of Craig's article, I disagree with this
caveat.  FDDI TTRT by itself does not matter.  What matters is how
often you get to transmit and consequently how much of the time the
ring is idle.  Unless you are using TCP Large Windows (as Cray does and
we all should), legal TTRT's do not crimp your style.  FDDI is less
than 12.5KBytes/millisecond, the maximum standard TCP window is only
64KBytes, and the minimum legal T_Req is on the order of 4 ms.

No interesting maximum-speed FDDI benchmark is going to be run on
anything but a practically idle FDDI ring.  Very few FDDI rings have
physical latencies large enough to matter, so that how frequently you
must release the token mostly affects how frequently you need, expect,
or hope to get TCP ACK's.


Vernon Schryver,  vjs@sgi.com
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: Thu, 3 Sep 92 18:01:46 GMT

OK, solve this one:

A group decides to do window conferencing, basically each one running
the same window based conferencing system sharing graphs, text.  The
third party application establishes a control protocol to determine 
whose turn it is to modify the window, taking turns as requeted by
the users.

Over the cell relay network I presume each member of the group is 
connected in a minimum spanning tree, and over this tree is distributed
circuit bundles, control data and window data, (we will add voice later).
The circuit bundle assigns VCI/VPI pairs to control and data according
to the application software (desktop software).

Suddenly a new member wants to join, and is accepted, so the
spanning tree is restructured to include the new partner.

1) Does the ATM network have a set up protocol to build the spanning
tree?

2) Can the new user perform a call setup to the existing spanning
tree (without reference to a particular host), causing an automatic
tree restructuring?

3) Can the control token sequentially visit each node of the tree
while the data moves in parallel over the tree, each using the same
graph structure? Different tranmission modes over the same graph
structure.

4) Can the desktop control software extract a topology map of the tree, 
then visit portions of this topology uniquely?  (Specify like source 
routing an exact hop by hop set of movements)
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay
From: holm@mprgate.mpr.ca (Terrence W. Holm)
Subject: Interop
Originator: holm@opus
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Distribution: na
Date: Thu, 3 Sep 92 00:08:52 GMT

From October 28 to 30 the Interop Company will hold their
West coast show at the Moscone Convention Center in San Francisco.
There will be various companies at the show displaying ATM
equipment which may be of interest to readers of this newsgroup.

At Interop you will be able to see:

	- Real working ATM switches
	- ATM adapter cards for various workstations
	- Interoperability between ATM switch vendors
	- ATM traffic carried over single and multimode fiber
	- Network management of ATM switches
	- Multicast video over ATM
	- LAN bridging over ATM


Switch vendors previously mentioned in this news group will be at
the show (together offering all the features noted above), including:

	- Fore Systems, booth 3015
	- Adaptive, booth 6164
	- MPR Teltech, booth 5578

Also check out the bridge/router hub vendors, and the carriers.
Expect a few press announcements to be made.


			Terry
			holm@mpr.ca

[Sorry if some people object to this type of posting]
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: Tue, 1 Sep 1992 21:34:00 GMT
X-Vms-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

If a station on an FDDI ring releases the token because its own TRT has
expired, it does NOT necessarily follow that anyone else who follows that
station will also see a "late" token.  Since we all have the same target
token rotation time (many feel that 8 ms. is an ideal value) and independent
TRTs, it really depends upon the amount of synchronous bandwidth that is
allocated and used.  Thus, it is possible that I will see an "early" token,
use up my entire TRT time (i.e., the entire amount of the earlyness), pass
it on to you, where you will also see an "early" token.

Yeah, this is hard to do in just prose...

/gary kessler
kumquat@smcvax.bitnet
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Future of IP routers
Organization: University of Strathclyde
Date: Wed, 26 Aug 1992 09:57:56 GMT

In article <1992Aug26.092945.4663@ccsun.strath.ac.uk>, craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
|> In article <BtKDH9.7M7@usenet.ucs.indiana.edu>, robelr@ucs.indiana.edu (Allen Robel) writes:
|> |> In article <1992Aug25.123428.26295@ccsun.strath.ac.uk>  
|> |> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
|> 
|> |> but routers currently don't handle video/voice traffic that well...
|> 
|> 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.
|>  
|> 
As a follow up to this, the ATM network in the future presumably will have
dedicated multi-media terminals that don't in fact transfer multimedia over IP,
but instead have built in AAL support for video/audio and data using different 
AAL types for each type of traffic e.g. one AAL type for video, one AAL type for 
audio, and a third AAL type to carry data, perhaps running IP over this third AAL 
type. This will remove the requirement to send video/audio traffic via a router,
because the video/audio AAL entities will connect directly with the video/audio
AAL entities at the other end.
-- 
Dave Stevenson 				d.w.stevenson@uk.ac.strath
Computer Centre				Tel : 041-552 4400 x3461
University of Strathclyde
Glasgow, U.K.
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Today's Problem
Date: 4 Sep 1992 10:42:54 -0400
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: nigel.msen.com
X-Newsreader: Tin 1.1 PL3

bantha.decnet.lockheed.com!young writes:
: 
: Far into the future (mid 1993) server nomenclature is fading from
: our language, being replaced by server "waves" which migrate about
: the virtual path networks (enabled by wave interpreters at each node).

Not.

Mid 1993 is near future, just about "now", as far as building
administrative tools goes.  Can you imagine trying to manage a network
that was full of random processes that swoop down and wreak havoc on your
disks?  And worse yet "interpreters" that could download and possibly
execute unfriendly codes?  No way.

--Ed

Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Future of IP routers
Organization: Basket Weavers, Inc.
Date: Thu, 3 Sep 1992 02:26:11 GMT


While noting that I agree with Mark that we're comparing apples and oranges
I thought I'd vaguely wave my arms again and comment on his comment...

In article <miw.715482801@cc.uq.oz.au> miw@cc.uq.oz.au (Mark I. Williams) writes:
>jtw@lcs.mit.edu (John Wroclawski) writes:
	[..]
>>In both cases the actual route calculation is done out-of-band.
>
>While the rest of your comments were correct, this isn't quite true. In
>an ATM switch, routing decisions are made on a per-connection basis.
>There is no lookup of next-hop information, since the VCI usually *is*
>the route.

I would expect that "out of band" and "on a per-connection basis" were
both intended to convey the same meaning, i.e. the choosing of the
route or path taken by an ATM cell from end to end is fixed at connection
establishment time. However John is right in his (deleted) description
of incoming VCI/VPIs being used to 'look-up' a next-hop. This look-up
establishes the desired output port of the switch, and new VCI/VPI
value for the cell when it leaves the switch. Strictly the VCI/VPI
is only "the route" on a switch-to-switch basis.

I think the term 'look-up' has been used imprecisely in both the ATM
switch and IP router description. For the switch it is literal, for
the IP router there is implicit coversion from addresses to routes
to output ports occuring in each look-up.

gja
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Something New
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 28 Aug 92 15:46:23 GMT


Excerpts from netnews.comp.dcom.cell-relay: 26-Aug-92 Re: Future of IP
routers by Allen Robel@ucs.indiana. 

>> Which means that the filtering functionality currently available
>> in routers gets pushed out to end nodes and is carried out
>> at call setup?  I'm not sure that I'm comfortable with this
>> sort of arrangement. 

Using ATM to support customer premises routers, and value added network
routers seems just fine.  What's the debate here?  Who cares if Ma
Bell doesn't install routers in the ATM network, as long as we have
value added networks to do it for us?

>Remember that ATM is going to replace the voice network as well as the
>data network.  Take a look at call screening and call control in today's
>voice networks; it is actually quite sophisticated.  In an ATM world,
>the local ATM switch--acting much like today's PBX--will no doubt be
>able to do all kinds of policy restrictions.

Nobody is going to rip out their PBX and replace them with ATM based 
PBXs. If the local exchange offers ATM based voice utilities, most users 
will default to standard POTS (Plain Old Telephone) option.

>
Show me something new, something enabled by ATM besides desktop television.
Show me how ATM allows intelligent, global, public, distributed data bases. 
Show me how ATM eliminates the entire concept of host addressing, moving 
us closer to the concept of distributed memory access.
From: ajw@otter.hpl.hp.com (Anthony Wiley)
Date: Fri, 4 Sep 1992 10:17:45 GMT
Subject: Re: AAL 5 query
Organization: Hewlett-Packard Laboratories, Bristol, UK.