HDTenEightyP/NetNews huggingface dataset:
From: craig@sics.se (Craig Partridge)
Subject: > Cell SIze
Organization: Swedish Institute of Computer Science, Kista
Date: Sun, 26 Jul 1992 02:34:47 GMT

|> >Note that if you were trying to compromise on these various tradeoffs,
|> >you'd probably pick a size that balance interrupt costs and bandwidth.
|> >My guess (based on what I've seen of predicted processor performance
|> >and estimated packet sizes) is that you'd choose a size of about 1,000
|> >bits (c. 128 bytes), which was one of the original proposals to CCITT.
|> 
|> Yes, but...but.... This analysis considers data traffic only! Remember
|> that ATM will be expected to provide other services as well. With a cell
|> payload of 128 bytes echo cancellation will be even more difficult than
|> with 64 bytes.

I was not focussing on data traffic.  I was focussing on the future,
and transmission speeds in 100s of Mbits (yes to the home -- we can run
100 Mbit/sec over twisted pair...).  At that point, small cells are
silly and serialization times are not a problem.

Craig Partridge
craig@bbn.com
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Curious attitude ...
Date: 27 Jul 92 17:43:12 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute


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

>Voice and video service will be the bulk of the traffic
>on the networks of the future. They have specific requirements
>which have prevented current data networks from carrying them
>in any practical situation. Has anyone ever made a voice call
>using TCP/IP?. These requirements will not change and so
>the network standards of tomorrow must adapt to them.

	The live audio multicast of the IETF meeting last week was
carried to at least 100 if not 200 sites and a few continents.  Oddly
enough, this was done using TCP/IP.  It was also accompanied by
live compressed video.  I leave it to you, how long ago do you think
researchers were experimenting with live speech over the Internet?




--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Congestion Avoidance
Date: 27 Jul 92 12:32:02 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <k3jm90-.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
|
|        Uh oh.  As the one-time congestion maven of the Internet
|(look at the RFCs that bear my name) I somehow thought the cell relay
|people had developed a new solution to the problem that would make
|huge connectionless nets work.  If they haven't, there's going to be
|trouble a few years downstream.

ATM is connection oriented only. Any connectionless traffic carried
over ATM will be a service using a connection oriented backbone.


|
|        The existing (NSFNET) approach of generously sizing the backbone using
|government subsidies, may not translate well to the commercial world.
|
|        					John Nagle


-- 
i.sinature
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: Re: [packet sizes]
Date: 24 Jul 92 07:43:12 GMT


 >As with VJ-compression?  Or just plain compression.  
 >(The IETF PPP working group is worried about compression between routers
 >at 56K.)
 
 Vernon,

VJ compression has been suggested to get TCP ACK + IP + whatever into
an AAL 5 single cell frame...

i was thinking of a new protocol (...:-) 

 jon
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 30 Jul 92 19:01:13 GMT
Organization: Mitel. Kanata (Ontario). Canada.


In article <1992Jul30.074342.5506@dxcern.cern.ch> brian@dxcern.cern.ch (Brian Carpenter   CERN-CN) writes:
>In <12430@janice> grayt@Software.Mitel.COM (Tom Gray) writes:
>
>
>>Video will not dominate network traffic. Voice traffic is an
>>order of magnitude greater than all other services combined.
>>Therefore voice considerations will dominate the design of
>>networks for the forseeable future. This was reported in
>>IEEE Network for May or June of 1990.
>
>The _total_ voice market is constrained by the total number of people
>in the world rich enough to have a telephone and the amount of time they
>want to talk. This means that the voice market has a future growth
>potential of only about one order of magnitude. The future growth
>potential for image and data transfer is unknowably high. Given that
>carriers invest for 20 or 30 year payback they would be very foolish
>to base plans on the current market share for voice. Indeed,
>nobody would be even _thinking_ about fiber to the home if this
>point was not understood.

This point was understood by the authour of the article in question.
Data traffic will be limited by the ability of the individual user
to type and read. How long will it take to read a file of
two million characters? How much voice traffic will be carried
in the same time at 32kb/s (or 16 or 8 but it is still the
same order of magnitude).

The only service which is capable of matching voice traffic
in terms of bits/second is switched video on demand or
switched entertainment. Fibre to the home is (I agree)
dependant on this service. However fibre to the curb
or fibre in the network is not.








.

-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 29 Jul 92 21:19:34 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute


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

>ATM as I stated later in the same posting is not a technology
>for carrying isochronous data. It is a very poor technology for
>carrying isochronous data.

	You and the AT&T people I meet at conferences are at odds.
	As regards your other assertions, you must know more than I.
	I have no idea what the future will hold.

--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: miw@cc.uq.oz.au (Mark I. Williams)
Subject: Re: Congestion Avoidance
Organization: Prentice Centre, University of Queensland
Date: Sun, 26 Jul 1992 23:10:53 GMT

nagle@netcom.com (John Nagle) writes:

>        Uh oh.  As the one-time congestion maven of the Internet
>(look at the RFCs that bear my name) I somehow thought the cell relay
>people had developed a new solution to the problem that would make
>huge connectionless nets work.  If they haven't, there's going to be
>trouble a few years downstream.

You're right. Congestion avoidance is still the big bugbear for ATM.
There is still (or wasn't 8 months ago) a generally accepted algorithm
for bandwidth allocation that performed better than peak-rate
multiplexing, although everybody is sure that some degree of statistical
multiplexing will be possible.

Of course, that situation is where we are now. With the current
circuit-switched network we are using peak-rate multiplexing by
definition.

cheers,


--
Mark Williams         The University of Queensland       miw@cc.uq.edu.au
+61 7 36 54012   (w)  Prentice Centre
+61 7 36 54477  (fax) Qld 4072  Australia
Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: > Cell SIze
Date: 27 Jul 92 12:39:38 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <1992Jul26.023447.21173@sics.se> craig@sics.se (Craig Partridge) writes:
>|> >Note that if you were trying to compromise on these various tradeoffs,
>|> >you'd probably pick a size that balance interrupt costs and bandwidth.
>|> >My guess (based on what I've seen of predicted processor performance
>|> >and estimated packet sizes) is that you'd choose a size of about 1,000
>|> >bits (c. 128 bytes), which was one of the original proposals to CCITT.
>|> 
>|> Yes, but...but.... This analysis considers data traffic only! Remember
>|> that ATM will be expected to provide other services as well. With a cell
>|> payload of 128 bytes echo cancellation will be even more difficult than
>|> with 64 bytes.
>
>I was not focussing on data traffic.  I was focussing on the future,
>and transmission speeds in 100s of Mbits (yes to the home -- we can run
>100 Mbit/sec over twisted pair...).  At that point, small cells are
>silly and serialization times are not a problem.

The services are indifferent to the speed of the serial link which
is carrying them. It will still take 8ms to fill a 128 byte
packet with speech whether the serial stream is running at
64kb/s or 64Mb/s. The problem of echo canellation (and
its other associated problems such as delay jitter) will 
still remain.

Voice and video service will be the bulk of the traffic
on the networks of the future. They have specific requirements
which have prevented current data networks from carrying them
in any practical situation. Has anyone ever made a voice call
using TCP/IP?. These requirements will not change and so
the network standards of tomorrow must adapt to them.


-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (KEES VAN DER WAL)
Subject: Re: Question
Organization: PTT Research, The Netherlands
Date: Mon, 27 Jul 1992 20:48:17 GMT

In article <1992Jul22.130820.11652@dxcern.cern.ch>, brian@dxcern.cern.ch (Brian
Carpenter   CERN-CN) writes: 

>>>>So the question is "who makes those small 48-56 byte packets? 

> Kees, when typing or moving my mouse (both on an X terminal), I don't
> know about the protocol, but *I* expect an ACK every few bytes, i.e.
> the X client half a kilometre away is supposed to respond to me. So yes,
> as several people have said, small packets are intrinsic to computer-
> generated traffic.

Okay, I give in. I'm convinced now that there are and will be quite a few small 
packets. But I'm still _not_ convinced that the total number of (partly filled)
cells resulting from those small packets is really worth while bothering. 


To do a variation about how many ... does it take to replace a light bulb:

How many typists or mouse-movers does it take to fill a 155Mb/s link?


Regards, <kees>

Kees  van der Wal		       e-mail: J.C.vanderWal@research.ptt.nl
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: > Cell SIze
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 26 Jul 1992 06:16:17 GMT

In article <1992Jul26.023447.21173@sics.se>, craig@sics.se (Craig Partridge) writes:
> I was not focussing on data traffic.  I was focussing on the future,
> and transmission speeds in 100s of Mbits (yes to the home -- we can run
> 100 Mbit/sec over twisted pair...)


100Mb/s over copper to the home?
What kind of lichen are the Lapps giving you to smoke over there?

Today you can't even get 0.128Mb/s unless you are next door to a phone
company building!  (the 18,000 wire-feet-to-the-CO ISDN restriction.)


As I understand the consensus in X3T9.5, 100 meters is a long way for
CDDI.  (Recall that SGI was part of the recent CDDI demo at X3T9.5.)
Most people seem to think that 155Mb/s ATM will work on the same
special copper used for 100Mb/s FDDI-over-copper.  Yes, it is
definitely special, either shielded-twisted-pair or "data-grade"
twisted pair.  It is not at all the standard phone co. voice wire.
Moreover, the bundles of data-grade TP must be separate.  You don't get
to run 12 CDDI connections in a single 25-pair cable.


Perhaps the Bellcore plans for fiber-to-the-curb or fiber-to-the-
(whatever-they-call-the-box-on-the-street-for-12-houses) will get
100Mb/s to the home, with the last few feet over copper.  Maybe that's
what you meant.


Vernon Schryver,  vjs@sgi.com
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: [packet sizes]
Date: 24 Jul 92 19:51:00 GMT
Organization: University of Oregon Network Services

It's not clear to me that VJ compression is really appropriate for ATM
nets.  VJ compression, as I understand it, gets most of its power by
observing that the path over serial circuits is typically used (mostly)
for a single TCP bidirectional stream at a time. Hence you can predict the
next packet, and encode the whole header essentially as a stream
identifier plus a single bit that says "the next packet is in fact the one
you are expecting", with only a small percentage of your packets missing
the cache of current streams and having to be encoded long-form.  VJ
compression doesn't seem to me to do as much good if the physical channel
is muxing lots of independent packet streams.  For example, it's not of
much use, I don't believe, on a high speed path between two routers busy
with lots of low-speed connections.

I'd be interested in the comments of other people more familiar with
TCP/IP compression schemes than I am.  How good IS the match between
VJ compression and ATM?

-- 
JQ Johnson
Director of Network Services		Office: 250E Computing Center
Computing Center			Internet: jqj@ns.uoregon.edu
University of Oregon			voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397
From: Z.Wang@cs.ucl.ac.uk (Zheng Wang)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 30 Jul 92 11:44:51 GMT

Isn't ATM just a compromise between packet switching
and circuit switching?

ATM may transport voice worse than circuit switching (in terms
of quality) and transport data worse than packet switching
(in terms of efficiency). The point is that ATM may do both
sufficiently (or reasonably) well and you get integration,
scaling and value for money.

Zheng
From: ronaldd@cbnewse.cb.att.com (ronald.h.davis)
Newsgroups: comp.dcom.cell-relay
Subject: atm training seminars/courses
Date: 31 Jul 92 15:27:10 GMT
Distribution: usa
Organization: AT&T

could anyone suggest or provide any information on atm seminars and/or
mincourses that are available?  thanks...

-- 
  __  ______  __  / __/ |       at&t bell laboratories, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       ronald@iexist.att.com / att!iexist!ronald
"if you ain't the lead dog, the scenery never changes" -- edmund wilson
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 31 Jul 92 17:17:54 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <12471@ntdd-1>, grayt@Software.Mitel.COM (Tom Gray) writes:
> 
> Not trying to be sarcastic but only asking for your views,
> what services do you see that will fill up gigabit networks 
> to the home?


Examples:
    video
	entertainment, whether TV or HDTV.
	picture phones
	remote monitoring (i.e. burglar alarms)


    data
	remote access to encylopedias, stock market info, etc.

	    This stuff wants as many bits as video, since much of
	    it will be "multimedia" and so include "graphics"

	telecommuting

	    Some of us doing this will eat up as many bits as we can get
	    Anything for which we now use LAN's we will use The Phone
	    Co or the Cable-TV Company, provided the cost is not much
	    more than measured-rate telephone service.

	    Some people keep LAN's saturated.  Usually not those
	    with PC-AT clones, even PC-AT-486 clones.

Much of this will be intermittent: 10MBytes/sec or 100Mbit/sec for
1 to 100 minutes.

This is not Gigabit rates, but then few people are talking about Gb to
the home.  Most of us would settle for 1Mbit/sec or even 100Kbit/sec
for the next several years.  The Phone Co. cannot gives those rates
now, except in special circumstances and/or at high prices.  (Yes, I
know a little about ISDN, SMDS, switched-56, and so on.  Try buying it
for your home.)


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Curious attitude ...
Organization: CERN European Lab for Particle Physics
Date: Fri, 31 Jul 1992 10:23:05 GMT

In <45907@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:

>Deleted a bunch of stuff.....

ditto

>1)	Will ATM become a ubiquitous international service?

>2)	Will ATM be a viable "transport" vehicle for the envisioned
>	multi-media world of tomorrow?

\begin{ :-) } We all know that ISDN means "I Still Don't Need it"
	      Does ATM mean "A Terrible Mistake"?
\end{ :-) }

Seriously
  1) No, it will never be ubiquitous for economic reasons, and it will
     have to interwork with everything down to 2400 bps modems.

  2) I have seen multimedia running over ATM. There is _no_ doubt
     that it is technically viable. The question is economic.
     If interfaces continue to cost $5K, no way.

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: fisk@netcom.com (Benjamin Fisk)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Question
Summary: Its later than you think
Date: 24 Jul 92 17:24:10 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <1992Jul17.144218.29461@walter.bellcore.com>, Shikhar Bajaj <bajaj@thumper.bellcore.com> writes:
> 
> 
> However, I believe that efficiency  is not the major issue  which needs
> to be addressed.  With fiber optic bandwidths in the Terabit range, at
> least in the short to mid-term, we will have bandwidth to burn.  Most
> commercial applications and operating systems implementations cannot
> even "fill the pipe" with data (at least for workstation class machines
> and below) so what is the point about worrying about efficiency.   This
> may seem shortsighted and appear as if I am simply deferring the problem
> to a later date, but I do not believe that IF ATM becomes widespread
> throughout the network, current traffic patterns will persist.  For
> example, multi-media traffic (i.e. real-time video and voice) is so
> unlike data traffic patterns that I do think that major pattern shifts
> would occur.   But, we don't know what these potential patterns may be.  
> 
The infinite pipe argument has always tagged along with fiber.  But for those
who have worked with developing fiber optic networks know that capacity
runs out just as fast on fiber as any other media.  The bottom line is
transmission is expensive to install and it is always in great demand.

However, I do agree that applications are tending twoards longer cell
sizes and that ATM cells will prove out fine in the long run.
-- 
Ben Fisk : fisk@netcom.COM
Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: Packet Sizes
Organization: Digital Equipment Corp., Littleton MA USA
Distribution: na
Date: Wed, 22 Jul 1992 20:18:36 GMT


The 48-byte cell size, of course, stinks.  If we were building an ATM
network for data alone, Craig's 128-byte payload is about right.  It's
even big enough to carry a sort TUBA (briefly IPV7) packet :-) .

Given that PCM voice generates 8 octets/millisecond, cell size sets
voice delay (for one-user full cells).  For a while, ATM was 64 Octets,
but France wanted 32.  Why?  Because if you added the speed-of-light
delay for a call the length of France, and added 4 ms (32-octets) delay,
you'd just barely get away without echo cancellers.  The extra 4 ms.
made echo cancellers seem necessary.  Now a bigger country like the USA
would need echo cancellers anyway, in which case a few extra ms. delay
(even 16 ms.) would be harmless.  So at 48 octets, EVERYBODY LOSES!
That's the way CCITT works; consensus ain't cheap.

I personally suspect that ATM nets (carrying data) will have LOTS 
of cell loss, which will require fairly small retransmission-units 
(R.U.)  If you use AAL5 alone, then the packet is the R.U.  If you
use AAL5 or AAL3 with SSCOP, then SSCOP allows an intermediate
fragment size R.U.  If you use BLINKBLT, or another numbered-cell 
selective retransmit protocol, then the cell is the R.U.

ATM nets are themselves physical layer; AAL is datalink, so internet
protocols and higher will run across them.  We can _optimize_ new
protocols to run over ATM, but will also have to live with the old.
I'm afraid that we're going to have a lot of overhead caused by
traffic that just misses the one-cell cutoff.  Perhaps we should move
towards sligtly modified transport protocols too, just to reduce the
frequency of 40-byte (longer with newer IP, most likely, or CLNP)
packets that, with overhead, just overflow one cell.
---
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: pettengill@cvg.enet.dec.com ()
Subject: Re: Cell SIze
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Sat, 25 Jul 92 08:47:26 GMT

In article <miw.711957276@cc.uq.oz.au>, miw@cc.uq.oz.au (Mark I. Williams) writes:
|>
|>Yes, but...but.... This analysis considers data traffic only! Remember
|>that ATM will be expected to provide other services as well. With a cell
|>payload of 128 bytes echo cancellation will be even more difficult than
|>with 64 bytes. 
|>
|>Consider also a telephone-quality voice channel: the data rate is 16
|>kbps. If you have a cell size of 128 bytes, the "lumpiness" is
|>introducing a delay of 62.5 milliseconds before the bits have travelled
|>an inch. Add a bit of buffering to smooth out delay jitter (which is
|>also somewhat dependent on the cell size) and it quickly becomes
|>apparent that 128 octets is "A Power too Far". Of course you could
|>simply only send 32 octets per cell when you had a long-distance
|>call....:-)

A cell size of 64 or 128 bytes poses no problem for voice.  Echo cancellation
is required for virtually every long distance circuit in the US even for
analog circuits (if any still exist) due to the delay in the wires and the
repeaters.  Even a country as small as France is only barely able to avoid
echo cancellation, and they wanted 32 byte cells so they could continue to
avoid having it within France.  The delays in the intermediate switches can
easily exceed the delay caused by packetizing the data into cells.

The problem with 128 byte cells is that it is larger than needed to carry
the fragments of voice payload with good efficiency.  Since standards always
represent the needs of the past, ATM is well suited to the past, not the
future.

mulp
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Curious attitude ...
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 31 Jul 1992 04:38:12 GMT

In article <12467@janice>, grayt@Software.Mitel.COM (Tom Gray) writes:
> ...
> How does ATM address the internetworking problem? As stated above
> it provides the opportunity to produce a network management model
> which can make valid predictions about performance. 

What kind of predictions do you have in mind?

> How do LAN protocols lack internetworking applications? They
> don't. There are a great many of them. So many that that
> it is impossible to create a network model that can 
> provide valid predictions.
> ...

What sort of predictions would be possible?  

What are some examples of these new performance predictions?


Vernon Schryver,  vjs@sgi.com