HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.dcom.cell-relay
Subject: Question about this newsgroup
From: <PVJQC@CUNYVM.BITNET>
Date: Tuesday, 21 Jul 1992 08:44:17 EDT
Organization: City University of New York/ University Computer Center

Hello,

I would appreciate it if someone could describe this news-group and its
purpose to me.
I am a Ph.D. student in Computer Science trying to write the thesis in
the areas of high-speed integrated networks.  I am gathering material
on ATM/SONET and trying to list various issues which could be persued
at the thesis level.
If any one has any pointers, I would highly appreciate it.
My sources so far have been IEEE Communication magazines, JSACs,
proceedings of SIGCOMM, etc.
Thank you very much in advance.

Prashant
-------

         *********************************************************
         *  PRASHANT V. JOSHI                                    *
         *  COMPUTER SCIENCE DEPARTMENT                          *
         *  CITY UNIVERSITY OF NEW YORK.                         *
         *  INTERNET ADDRESS: PVJQC@CUNYVM.CUNY.EDU,             *
         *  BITNET ADDRESS  : PRASHANT@QCVAX.BITNET              *
         *                                                       *
         *********************************************************
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 29 Jul 92 21:42:31 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

In article <1992Jul29.164110.1@research.ptt.nl> walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295) writes:

>Well, compression helps ... but also takes some time. If there's delay in the 
>transmitting coding, propagation delay and decoding delay, there's not much to 
>spend on queueing delay in the network if the "target" of 50-100ms is to be 
>reached.

	I asked.  The current system's transcontinental round-trip
end-to-end ping packets during teleconferencing return in about 60ms.
One way, the compressed video packets have a delay of about 50ms.
Compression is done by hardware and I would assumed is pipelined.

	This points out what can be done with prototype teleconference
systems already over a 1.34 Mb/s IP based data network.  I wouldn't
claim that it is a commercial system.  We don't build those.  We do
research.  Our concerns are technology development and demonstration.
We use vanilla SPARC IPC routers the size of a Webster's Collegiate
and commercial T1 DSU/CSUs.
--
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: Cell SIze
Organization: Prentice Centre, University of Queensland
Date: Fri, 24 Jul 1992 05:54:36 GMT

craig@sics.se (Craig Partridge) writes:

>>  In this experiment I suppose that the network managers would set the
>>  cell size so that the smaller packets, about 50-80 bytes long, would
>>  rarely fill onto cells.  Am I right?   What would be the actual cell size
>>  selected assuming today's traffic?

>This is a fun question (even if somewhat hypothetical).
[.......]
>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. 

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

My apologies if you *meant* only to consider data traffic.

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
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: > Congestion Avoidance
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 27 Jul 1992 16:55:54 GMT

There's plenty of work going on to try to avoid having ATM use the horribly
wasteful peak bandwidth approach. (Why is it wasteful?  Well, because
the peak bandwidth typically isn't being used, but by having chopped the
full circuit bandwidth into connections, you've made sharing of the unused
bandwidth harder.  It is usually better to completely share the entire
bandwidth of the link, than to break it up into smaller fixed bandwidth
channels).

One key problem is that data communications traffic is typically not
nicely IID and thus M/*/n queueing models are of little help.  (The
Sunshine switch designers reported that when they tried a more realistic
model of data traffic they found the buffering requirements were an
order of magnitude larger than M/*/n models predicted).  One can rapidly
find oneself analyzing queueing theory problems that cause experts to
shudder.

However, there are some nice ideas.  Some of the token bucket schemes
(a variant of leaky bucket) have been shown to give delay and bandwidth
guarantees over cell networks.  See Parekh's MIT dissertation for one.

Craig Partridge
craig@bbn.com
Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (KEES VAN DER WAL)
Subject: Re: > Congestion Avoidance
Organization: PTT Research, The Netherlands
Date: Tue, 28 Jul 1992 09:41:27 GMT

In article <1992Jul27.165554.8612@sics.se>, craig@sics.se (Craig Partridge)
writes: 

> There's plenty of work going on to try to avoid having ATM use the horribly
> wasteful peak bandwidth approach. (Why is it wasteful?  Well, because
> the peak bandwidth typically isn't being used, but by having chopped the
> full circuit bandwidth into connections, you've made sharing of the unused
> bandwidth harder.  It is usually better to completely share the entire
> bandwidth of the link, than to break it up into smaller fixed bandwidth
> channels).

You've got to make a choice: either you stress the "guarantee" for throughput 
and a low loss figure _or_ a high degree of multiplexing gain. A combination of 
both is harder to obtain.

You can have _both_ approaches mixed in a single ATM network.


> One key problem is that data communications traffic is typically not
> nicely IID and thus M/*/n queueing models are of little help.  (The
> Sunshine switch designers reported that when they tried a more realistic
> model of data traffic they found the buffering requirements were an
> order of magnitude larger than M/*/n models predicted).  One can rapidly
> find oneself analyzing queueing theory problems that cause experts to
> shudder.

What "more realistic" model did they use? 


> However, there are some nice ideas.  Some of the token bucket schemes
> (a variant of leaky bucket) have been shown to give delay and bandwidth
> guarantees over cell networks.  See Parekh's MIT dissertation for one.

Looks interesting; is this kind of literature available somewhere?

Regards, <kees>
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: [packet sizes]
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Jul 1992 18:17:32 GMT

In article <2794@ucl-cs.uucp>, J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
> 
>  i agree about the bi-modal distribution, but one minor point:
> 
> if you have all pervasive B-ISDN, it is certainly pretty crazy to run
> TCP/IP, with 40 byte headers, or TP4/CLNP with absolutely enourmous
> headers - you can use very small headers quite reasonably


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


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: reidk@skorpio.usask.ca (Karen Reid)
Newsgroups: comp.dcom.cell-relay
Subject: Acceptable delays
Date: 29 Jul 92 16:44:41 GMT
Organization: University of Saskatchewan, Saskatoon, Canada

Can anyone point me towards references that have a good indication
of the end-to-end delays that various services on an ATM (BISDN) network 
can tolerate (particularly interactive video and voice)?   
What proportion of the delay will beattributed to building packets, 
queueing delay, and propagation delay?

My question stems from wondering how big buffers at internal
switching nodes can be before the delay incurred by cells arriving
at an almost full buffer exceeds some quality of service limit.  I've
seen figures for the delay at a switch ranging from 10's of microseconds
to 100's of milliseconds. 

Thanks,

Karen Reid
reidk@cs.usask.ca
reidk@skorpio.usask.ca
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:35:12 GMT

In article <12464@janice>, grayt@Software.Mitel.COM (Tom Gray) writes:
> 
> 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).


Reasoning about data requirements based on humans reading text is not valid.

I have a private link data link that runs over about 1500 miles of
various phone co. wires.  I move about 5MBytes/day on th quiet days,
and 30MB on the bad days.  I get between 5 and 12 MByte/hour, with the
bottleneck being a pair of v.32bis/v.42/v.42bis modems on 40 miles at
one end of the link.  I continue to fight with latency problems
suffered by my interactive stuff during the automatic file transfers.

Then there is the other, 2000 mile link over which I push only about
2MB/day.

Some of that stuff is netnews.  Some is source code (e.g. UNIX kernel
trees at 30MB each).  Some binaries (e.g. 2MByte UNIX kernels).

You are welcome to imagine that I personally supervise and peruse a
minute fraction of that stuff, but it might be more accurate to assume
otherwise.
Please do not assume that I babble for the equivalent hours per day,
on the telelphone or not.


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

Agreed.  Video is an infinite bandwidth sync.  

Why is fiber to the curb different from fiber to the home?
What's special about the last 100 meters of copper that limits the
bandwidth?  I assume you know of the "emerging standard" for FDDI at
100Mbit/sec over twisted pair.  The ATM guys I know seem to think that
the same twisted pair will go to 155Mbit/sec, although probably never
much higher.


Vernon Schryver,  vjs@sgi.com
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 28 Jul 92 21:53:12 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

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

>However if you are attempting to provide service comparable to the
>existing voice network and extend these services to include
>associated video and data service, you will have to come up with a
>system comparable to ATM.

	I never said that I was.  Nor have others that have commented
here recently.  The issue is whether or not ATM is a good LAN
technology, not whether it is a good technology for carrying
isochronous data.

	The carrying of voice/video traffic over TCP/IP shows that it
can carry isochronous traffic, just as ATM can carry asynchronous
traffic.  If someone makes a statement that isochronous traffic such
as voice/video can't be carried conveniently over long-haul TCP/IP
system, I will point out the error.

	There is a larger looming issue.  Nearly artifact-free
compression algorithms now exist that are used to decrease the
bandwidth loading of both voice and video.  They are often
variable-bit-rate.  This class produces VERY bursty transmission
behavior.  Those of you who are so sure that video data will dominate
MAN and WAN traffic in the future may find yourselves in an
interesting situation.

>As others have pointed out, ATM/B-ISDN has been designed to work in
>a multi-service environment. 

	I don't disagree.  The ISO suite was designed to replace
TCP/IP by the late 80's.  That ATM will work better than other
link-layer protocols in LANs is an issue much up in the air.
--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (KEES VAN DER WAL)
Subject: Re: Congestion Avoidance
Organization: PTT Research, The Netherlands
Date: Mon, 27 Jul 1992 19:49:40 GMT

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.

Well, as ATM (as it has been defined now) is connection-oriented _only_ ...


But ... (taking the chance to be hit) ... 


            is there any future for connectionless operation? 



If a user (or maybe only part of the users) require(s) some kind of "guarantee"
about cell loss or througput, I tend to say "no". 

What's so attractive in present-day connectionless networks? 

- Just the comfort of getting rid of the data and let the network do the hard
  work? 
- Or the potential to spread the load more evenly over the entire network? 
- Or just because the user doesn't want to do signalling (I admit, signalling
  procedures should be made faster). 
- ....?


Regards, <kees>

Kees  van der Wal		       e-mail: J.C.vanderWal@research.ptt.nl
----------------------------------------------------------------------------
PTT Research Neher Laboratories					  Room: E130
Sint Paulusstraat 4					 Fax: +31 70 3326477
2264 XZ  Leidschendam  The Netherlands		       Phone: +31 70 3326295
From: my00@gte.com (Michael Yuen)
Newsgroups: comp.dcom.cell-relay
Subject: Re: connection setup protocols
Date: 29 Jul 92 20:17:38 GMT
Followup-To: comp.dcom.cell-relay
Organization: GTE Labs

In article <3155@ra.nrl.navy.mil>, schmitt@cmf.nrl.navy.mil (George
Schmitt) wrote:
> 
> 
> 
> Hello.
> 
> I'm wondering if any work is being done to standardize the
> connection creation/setup protocols for an ATM network.  We
> Thanks.
> 
> 
> George Schmitt
> 
> Connection Machine Facility
> Naval Research Laboratory

I believe the standard body is looking into using Q.931 for access
signaling, and subset of SS7 for network signaling.

-Mike



-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael Yuen                   Tel - (617)466-2919
GTE Labs                          Internet - my00@gte.com
40 Sylvan Road                 FAX - (617)466-2130
Waltham, MA 02254
Newsgroups: comp.dcom.cell-relay
From: miw@cc.uq.oz.au (Mark I. Williams)
Subject: Re: >>>>Question
Organization: Prentice Centre, University of Queensland
Date: Fri, 24 Jul 1992 06:11:54 GMT

gardner@ux1.cso.uiuc.edu (Mike Gardner) writes:

>What is even worse is that ATM will possibly throw away more packets due to 
>congestion than errors.   Also the 10**8 error rate is for each link.  Cross
>country ATM could cross a dozen or more links, each with possible congestion
>problems.  I wouldn't want to run a ack-less protocol across that!

(1) The 10**-8 error ratio *includes* losses due to congestion. This is
why there is so much effort being put into ATM resource
management/control. 

(2) The 10**-8 error ratio is defined to be end-end. An ATM link should
have an error ratio more like 10**-12, and a switch should have losses
something like 10**-10.

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: tli@skat.usc.edu (Tony Li)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 30 Jul 1992 09:04:11 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

In article <12445@ntdd-1> grayt@Software.Mitel.COM (Tom Gray) writes:
    
    You know something, I agree with you. Ethernet is simple and common.
    However an Ethernet can be fully loaded by 6 to 10 workstations.
    Thus the problem for systems larger than just a few workstations
    is not LAN connection but LAN interconnection. With the power of
    work stations increasing this number can be expected to decrease.
    
    Now ATM is seen as the answer to the interconnection problem
    since it offers a chance to create a workable network modelk  that
    can be used to effectively manage a data network. In this view
    ATM will be used intially as a cloud network to eliminate
    the complexity of the routing protocols.
    
I'm sorry, but it won't do this unless ATM is used as the sole media
for small isolated LANs.  If it is used as a LAN interconnect, you
still have a router sitting between the switch and the LAN.  And you
still have to run a routing protocol to make correct level 3 routing
decisions.  If you use big ATM clouds, then you actually _aggravate_
the routing problem since a large non-broadcast cloud breaks existing
level 3 assumptions about the nature of the media.  I refer you to the
Directed ARP and Shortcut Routing proposals currently in front of the
IETF for proposed solutions to this problem.

    :> As I have pointed out, it is now the protocol of choice for
    :> the LAN industry which expects ATM to supplant existing
    :> protocls by 1995.

As a member of the "LAN industry", I can assure you that we expect ATM
to _supplement_ existing networks.  Ethernet, like Fortran, will
continue to be the lowest common denominator for years to come.
    
    The problem with these LAN protocols
    is not in the access but in the internetworking applications.
    It is here that ATM is now replacing the existing networks.
    Frame Relay has seen widespread acceptance and Frame Relay
    is the first example of ATM protocols.

How do LAN protocols lack internetworking applications?  And how does
ATM address this issue?  Answer: it doesn't.  It provides another link
layer for data and adds other services.  Frame Relay is an ATM
protocol?  What is SMDS?  X.25? 

The opinions expressed are mine and not those of my employer...

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: (none)
Date: 23 Jul 92 08:11:56 GMT



 >>>>So the question is "who makes those small 48-56 byte packets? And why is it the 
 
 >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.

 Briaa,

 i agree about the bi-modal distribution, but one minor point:

if you have all pervasive B-ISDN, it is certainly pretty crazy to run
TCP/IP, with 40 byte headers, or TP4/CLNP with absolutely enourmous
headers - you can use very small headers quite reasonably

someone should be working on this (apart from the usual cambridge
university computer lab types who will be out there in 2002 world:-)

 jon
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: Thu, 30 Jul 1992 07:43:42 GMT

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.

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: habs@panix.com (Harry Shapiro)
Newsgroups: comp.dcom.cell-relay
Subject: Re: > Cell SIze
Date: 27 Jul 92 02:24:46 GMT
Organization: PANIX Public Access Unix, NYC


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

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

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

>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

I have seen plans from Time-Warner where they replace their existing
plants (trunk and branch) with a optically feed trunk serving a cluster
of 500 homes. This involves them rebuidling only 20% of their "plant."

They will use such a new plant to deliver video on demand. I can imagine
them using ATM to get to and from the "cluster." Of course since they
are wokring a deal with IBM they will probally use PARIS.

ATM to the block or to the neighborhood and coax to the home seems
like a good concept for the short term (0-16/20 years).
-- 
Harry Shapiro  				      habs@panix.com
List Administrator of the Extropy Institute Mailing List
Private Communication for the Extropian Community since 1991
Newsgroups: comp.dcom.cell-relay