HDTenEightyP/NetNews huggingface dataset:
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.cell-relay
Subject: Re: [packet sizes]
Date: 25 Jul 92 19:15:26 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul24.195100.20475@nntp.uoregon.edu>, jqj@duff.uoregon.edu (JQ Johnson) writes:
> 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?


No, VJ compression works fine for several simultaneous virtual
circuits.  Any real TCP network often has more than one simultaneously
active circuit even over a SLIP line.  That's why anyone sitting down
to invent something like VJ compression without looking at the standard
or his code does just as he did, and includes some kind of circuit or
session or context ID in the compressed header.

You can have as many simultaneous VJ-like-compressed circuits as you
wish to devote resources at the ends and bits in the compressed
header.

"VJ-compression" is not really about "compression."  It is more about
"header prediction", with the near side sending only those bits that
the far side might not be able to predict.

I wonder about doing VJ-compression at full speed over ATM.  Some XTP
ideas included finding the right "context" as the head of the packet is
received, and using that "context" to forward, ACK, etc the packet,
sometimes before you see the trailer.  That does not seem trivial at
gigabit rates on a stream of tiny packets without some special
silicon.  Last I knew, PEI was doing well with continuous streams of
minimal sized UDP and TCP packets at FDDI rates.  I do not know how
they are doing at high speed.


Vernon Schryver,  vjs@sgi.com
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 30 Jul 92 18:36:45 GMT
Organization: Mitel. Kanata (Ontario). Canada.

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

I am not at odds with the AT&T people. AT&T and anyone else in the
business know that there is no sense in using ATM to carry
isochronous data. They are going to use ATM to multiplex
isochronous, synchronous and asynchronous data and control
into channels. Existing digital switches are much more
capable than ATM in carrying isochronous data and
would be cheaper at it as well. 

You (conveniently) edited out the explanation that I presented that
showed that no one would use ATM to carry isochronous traffic
around a building. There is no cost justification in doing so.
However it can make economic sense to use statistical multiplexing
based on ATM techniques to reduce the required network bandwidth
over long haul trunks. ATM is not a technique for carrying
isochronous data (since there are much better ways of doing
this) but it can be used to create services which more
economically carry isochronous data in certain circumstances.

ATM is being designed to create a manageable network that 
can be used to create applications. ATM is being designed
with contention resolution, resource allocation, performance
prediction etc etc in  mind. ATM is being designed as a network
in which there will be practical resolutions to these
problems.

For an introduction to some of these ideas in ATM, you
could consult Multimedia Traffic Management Principles for 
Guaranteed Network Performance by Woodruff et al in
the April 1990 issue of JSAC.

>	As regards your other assertions, you must know more than I.
>	I have no idea what the future will hold.

What? You are not going to tell me that ATM is just another link
layer for LAN services that will have major problems with
bursty traffic!
-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295)
Subject: Re: Curious attitude ...
Organization: PTT Research, The Netherlands
Date: Wed, 29 Jul 1992 15:41:10 GMT

In article <22062@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:

>>> 	The live audio multicast of the IETF meeting last week was
>>> carried to at least 100 if not 200 sites and a few continents. 

>>Broadcasting <whatever> seems an order of magnitude simpler to me than 
>>interactive video or voice. Whatever the variance in delay is, you just need a 
>>sufficiently large buffer at the receiving end to restore timing requirements.
>>And if the network load is sufficiently low, the loss of data can be kept to 
>>an acceptable level.

> 	No.  Multicast is NOT broadcasting.  A routing tree is
> constructed so that the traffic flows according to what is ideally a
> minimum-cost spanning tree.  Hardly broadcast I think.

I agree. The essence is that there's hardly any real time contraints when 
doing none-interactive multicast.


> 	Interactive multi-media conferencing experiments have gone on
> over the Internet for quite a few years.  Multi-site teleconferencing
> goes on between sites that have the hardware every couple of days.

I'm curious about the delays (and the amount of destination buffering) that 
were experienced in those experiments. The present-day target for interactive 
use is 100ms one-way delay and actually coding experts here are complaining.
They'd like to see that down to 50ms.


> 	Leading edge work on this goes on at a number of DARPA
> affiliated labs and has been for years.  Whether it will achieve
> widespread commercial introduction awaits high-speed long-haul network
> costs dropping a lot, which has very little to do with ATM or any
> protocols for that matter.

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.

To keep the queueing delay low, (actually the 1E-x quantile of the delay
destribution) there's (as far as I can see) only two solutions: 

1) a low network load. More precisely: keep the amount of interference low.

2) switch _small_ chunks of data so the result of interfering data streams 
   is proportionally smaller.

ATM is just targeting on the latter to enable several connections to be 
multiplexed on those costly links.

Regards, <kees>
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: (none)
Organization: CERN European Lab for Particle Physics
Date: Mon, 27 Jul 1992 09:56:27 GMT

In <2794@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:

>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

This raises what I consider to be a very major point... can we solve
address management (and name management) such that workstations can
use B-ISDN directly, peer-to-peer, and bypass connectionless routing
altogether? Now we never managed it with X.25, so I am waiting for
somebody to tell me how to do it. Somehow the IETF doesn't seem very
interested by this problem ;-)

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

Now I do have to defend my alma mater ... they have always been
ideas people there, haven't they, not product designers?

  -- Brian
From: schmitt@cmf.nrl.navy.mil (George Schmitt)
Newsgroups: comp.dcom.cell-relay
Subject: connection setup protocols
Summary: any interoperability standards
Keywords: standardization, interoperability
Date: 29 Jul 92 04:28:00 GMT
Followup-To: comp.dcom.cell-relay
Organization: NRL Connection Machine Facility, Washington, DC



Hello.

I'm wondering if any work is being done to standardize the
connection creation/setup protocols for an ATM network.  We
are currently running an ATM network through a switch 
manufactured by Fore Systems which uses its own connection
creation and signalling protocol, but something tells me that
we will have problems when attaching another vendors switch to
it and attempt to create a connection through both.

Anyone out there taking the lead on this or will we all be
forced to use only one manufacturer's switches for all of our
ATM computing needs?


Thanks.


George Schmitt

Connection Machine Facility
Naval Research Laboratory
Washington, DC     20375-5000
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 28 Jul 92 12:16:45 GMT
Organization: Mitel. Kanata (Ontario). Canada.

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

You have described a very small conference system. I have seen descriptions
of voice switches made over Ethernet, FDDI and probably every other 
network system. What these systems cannot provide is the combination
of the required delay and bandwidth (and at a cost competitive with
other technologies). There is no doubt that anyone can switch voice
information through a data network. If you provide enough bandwidth
to lower the delay, if you provide enough buffers to overcome the
delay jitter, you can do anything.

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.

Now can you demonstrate a 2000 line PBX with integrated ACD
operating over TCP/IP?


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

>
>
>
>--
>Gregory Finn	(310) 822-1511
>Information Sciences Institute, Marina Del Rey, CA 90292


-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: tjs@uh.msc.edu (Tim Salo)
Subject: Re: Curious attitude ...
Organization: Minnesota Supercomputer Center, Minneapolis, MN
Date: Tue, 28 Jul 1992 20:11:00 GMT

In article <1992Jul28.104754.1@research.ptt.nl> walvdrk@research.ptt.nl (KEES VAN DER WAL) writes:
>	[...]
> BTW: do you know what coding scheme and what data rates were used [by
> the IETF audio/video multicast]? <k>


My notes indicate the source code used by the IETF audio and video 
multicast can be found on:

Audio: ftp.ee.lbl.gov, ~ftp/vat.tar.Z

Video: diamond.bbn.com, ~ftp/pub/dvcrx.tar.Z

IP multicast: gregorio.standford.edu, ~ftp/vmtp-ip/ipmulti-sunox41x.tar.Z

It looks like additional information on the technology employed can
be found in or referenced in these files.

Tim Salo
tjs@msc.edu
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 28 Jul 92 21:31:37 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

In article <1992Jul28.104754.1@research.ptt.nl> walvdrk@research.ptt.nl (KEES VAN DER WAL) writes:
> finn@isi.edu (Greg Finn) writes:

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

>Broadcasting <whatever> seems an order of magnitude simpler to me than 
>interactive video or voice. Whatever the variance in delay is, you just need a 
>sufficiently large buffer at the receiving end to restore timing requirements.
>And if the network load is sufficiently low, the loss of data can be kept to 
>an acceptable level.

	No.  Multicast is NOT broadcasting.  A routing tree is
constructed so that the traffic flows according to what is ideally a
minimum-cost spanning tree.  Hardly broadcast I think.

	Interactive multi-media conferencing experiments have gone on
over the Internet for quite a few years.  Multi-site teleconferencing
goes on between sites that have the hardware every couple of days.
Much of the early work on discrete cosine transform compression was
done under DARPA support.  Groups were building such hardware for
interactive network use a decade ago.  Now it can be placed onto a
chip or two and boards exist for the PC even, let along big
workstations.

	Leading edge work on this goes on at a number of DARPA
affiliated labs and has been for years.  Whether it will achieve
widespread commercial introduction awaits high-speed long-haul network
costs dropping a lot, which has very little to do with ATM or any
protocols for that matter.

--
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 20:02:56 GMT

In article <miw.712192253@cc.uq.oz.au>, miw@cc.uq.oz.au (Mark I. Williams)
writes: 

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

But it multiplexes! I don't think the term "statistical multiplexing" 
(or even -sm- gain) is saying very much. Present day telephone networks are 
also multiplexed; unscheduled so "statistically". 

If operator X would run an ATM network with plain (and safe) peak rate
allocation and if we could make very fast signalling procedures to renegotiate
the capacity on an already established connection, what would then be the
difference with network Y that would allow "statistical multiplexing" in
the ATM-sense? 

It's like trading in congestion probability (in Y only) against the probability 
that the request for an increase in capacity is turned down (in X). I guess 
that X is to be judged better than Y as during congestion a large number of 
connections are going to suffer, as opposed to maybe a few in case X.

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

Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca

Just guessing: "No bright ideas without a few drops of insanity"?  -- <k>
Newsgroups: comp.dcom.cell-relay
From: crm57d@bnr.ca (Ken Hayward)
Subject: Re: (none)
Organization: Bell-Northern Research
Date: Tue, 28 Jul 1992 21:23:17 GMT

In article <1992Jul27.095627.9605@dxcern.cern.ch> brian@dxcern.cern.ch (Brian
Carpenter   CERN-CN) writes:
>This raises what I consider to be a very major point... can we solve
>address management (and name management) such that workstations can
>use B-ISDN directly, peer-to-peer, and bypass connectionless routing
>altogether? Now we never managed it with X.25, so I am waiting for
>somebody to tell me how to do it. Somehow the IETF doesn't seem very
>interested by this problem ;-)

I believe that the concepts of Directed Arp and/or Shortcut Routing, both being
worked on in IPLPDN, are in the direction of allowing this. They are currently
being considered in the area of SMDS, but potentially apply also to any other
interface that allows multiplexed connectivity to multiple addresses. This
might include X.25, Frame Relay, and/or ATM/B-ISDN, assuming Switched Virtual
Circuits are emulated by the latter two.

(I confess that it may be too late to request that routers/workstations support
either of these for X.25 :-).

Ken Hayward, working for, but not representing, Bell-Northern Research
crm57d@bnr.ca                   +1 613 763 4042
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 31 Jul 92 15:44:14 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <45907@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>Deleted a bunch of stuff.....
>
>
>I didn't realize that the telephony industry was offering a one-time fee 
>for ATM hook-ups, such that all future usage, maintenance and connectivity 
>costs were included in the "PAY MA BELL NOW" figure and you never had to "PAY 
>MA BELL LATER" (substitute your favorite carrier acronym).  We won't even 
>need any networking expertise because we can just use the free, non-biased
>consulting services to support our infra-structure.  Plus, once we have
>ATM we will have the panacea of all known and future technologies and
>will never need an upgrade.  However, if an enhancing technology were
>ever discovered, we could freely upgrade to the new panacea.  Could
>you give us an enticing price to go along with this pledge?????

ATM is an Edge to Edge protocol. I repeat ATM is an EDGE to EDGE protocol.

The  entire idea of ATM is to remove the control and intelligence from the
centre of the network and move it to the periphery. In this way applications
can define their own transport protocols and perfrom their own management
without requiring the involvement of the network.

An application will signal from one side of the network to the other
using only the bandwidth supplied by the network. The user and the
applications are thus freed from the tyranny of the network. The
network itself becomes simply a commodity provider of bandwidth.
It provides only a bandwidth cross connect function with all
value added services (such as switching) being performed
at the periphery.

You know what this means? Bell gets only a commodity fee for
its services. BellCore knows this. The RBOC's know this.
AT&T knows this. Northern Telecom knows this. This is the
reason that these companies are attempting to move out of the
network transport business and into the network services
business. I have heard with my own ears this stated by two
(count them two) senior researchers from BellCore.

Now lets repeat this for the ill of humour.

ATM is and Edge to Edge protocol. ATM is an Edge to Edge protocol.

A user of ATM will need only to buy raw bandwidth from the
telephone company. All switching and other value added services
will be done at the periphery of the network.

This is the entire idea behind ATM. If you do not believe
me, look up "The Integrated Services Packet Network" or
"New Directions in the Communications Age" both by
Jonathan Turner.

ATM frees the user from complying with network standards.
The user tells the network what communication grade of
service he requires and then creates his own services.
-- 
i.sinature
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 31 Jul 92 11:35:35 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <1992Jul31.021548.1674@nntp.uoregon.edu> jqj@nntp.uoregon.edu (JQ Johnson) writes:
>In article <12464@janice> grayt@Software.Mitel.COM (Tom Gray) writes:
>>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
>
>Oh come on.  Data traffic between the workstation on my desk and the file
>server downstairs is seldom text that I'm typing or reading.  Give me
>a Gb/s connection at home to the worldwide information system and I
>guarantee you I can find ways to use saturate it most of the time.

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?






.

-- 
i.sinature
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 31 Jul 92 12:25:29 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <45907@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
>Deleted a bunch of stuff.....
>
>
>2)	Will ATM be a viable "transport" vehicle for the envisioned
>	multi-media world of tomorrow?
>
..
..
>latency requirements (at least this reader would find these topics
>of greater value than biased "PAY ME LATER" comments).....
>
>Just an opinion from the catacombs...........

Just a couple of questions?

1) why do you find the issue of cost of network management and
   reliability to be unimportant? If ther bulk of the cost
   of a data network is not in the equipment but in the
   operation and maintenance of the equipment,  would you
   not regard this as an important consideration in 
   technology selection?

2) what applications do you see in the multi-media 
   world of tomorrow? By this I mean do you see
   ubiquitous multi-media to the desk top  or
   will this be reserved to special applications
   like the public conference system described
   previously.


-- 
i.sinature
Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (KEES VAN DER WAL)
Subject: Re: Curious attitude ...
Organization: PTT Research, The Netherlands
Date: Tue, 28 Jul 1992 09:47:54 GMT

In article <22041@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:

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

Broadcasting <whatever> seems an order of magnitude simpler to me than 
interactive video or voice. Whatever the variance in delay is, you just need a 
sufficiently large buffer at the receiving end to restore timing requirements.
And if the network load is sufficiently low, the loss of data can be kept to 
an acceptable level.

But now in interactive mode ...

Regards, <kees>


BTW: do you know what coding scheme and what data rates were used? <k>