HDTenEightyP/NetNews huggingface dataset:
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Question
Organization: CERN European Lab for Particle Physics
Date: Wed, 22 Jul 1992 13:08:20 GMT

In <1992Jul18.154155.1@research.ptt.nl> walvdrk_r@research.ptt.nl (Kees van der Wal) writes:

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

>>>So the question is "who makes those small 48-56 byte packets? And why is it the 
>>>that size. Is there some kind of "natural" packet size that peaks around those 
>>>values? It's hard for me to believe that.

>> Anyone who histograms data packet sizes finds two peaks, one around
>> 40-50 bytes and one at some higher value - often 512 bytes, sometimes
>> 1500 (i.e. full Ethernet packets). Even when running on FDDI which
>> allows 4Kbyte packets it is very difficult to persuade typical software
>> to use more than 512 bytes.


>I don't argue against the argument that nowadays protocols may produce this
>size of packets. With "one step back" I meant that we have to re-think what
>we're doing with the protocols that eventually are supposed to perform some
>"task". That "task" i.e. the transport of a 1Mbyte digitized picture is then
>what I see as "the driving force". We'll have to design systems and protocols
>that support that "task" rather than restricting ourselves for eternity to
>protocols that don't fit. 

>If system designers are desgning ATM equipment that delivers ATM cells with a 
>cell loss probility in the order of 10E-8, it doesn't make sense to me to use a 
>protocol that expects an ACK for every few bytes that is sends.

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.

 -- Brian
From: craig@sics.se (Craig Partridge)
Newsgroups: comp.dcom.cell-relay
Subject: copper/fiber to the home
Date: 26 Jul 92 23:46:51 GMT
Organization: Swedish Institute of Computer Science, Kista

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

Actually, it is the California smog -- I'm now working out of Palo Alto and
have become reacquainted with what we do to our lungs in the US.  I
just post from Sweden because my netnews keeps blowing my posts and I
haven't had time waste a day fixing ill-documented PD software.

You're right that I was assuming fiber to the local distribution box, and
copper from there.  My understanding is that folks thought they'd learned how to
get 100Mbits/sec over existing unshielded twisted-pair in office  buildings
and figured we could probably use something like that technology to deal
with the last 100 meters.  I heard an AT&T presentation that predicted that
fiber to most local distribution boxes in the US would have been
achieved by 2000.  Voila -- real bandwidth to the home.  Your comments
about what has really been done for FDDI lead me to believe I 
was over-optimistic.

Craig Partridge
craig@bbn.com
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: Thu, 30 Jul 1992 04:10:51 GMT

In article <1992Jul29.164110.1@research.ptt.nl>, walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295) writes:
> In article <22062@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:
>...
> > 	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.


Wasn't the IETF multicast "interactive"?

If you don't have some real time constraints, pictures get objectionably
jerky and voice is hard to understand.

Do you guys not like "etherphone", from many, many years ago?  You can
make a similar thing that works pretty well on modern workstations that
support sound.

50 milliseconds is not at all hard to hit on typical ether-internets,
with workstations acting as routers.  (I know a little of such an
internet with a hundred or so ethernets, some FDDI and TR and a few
thousand workstations, and a little more about the hardware and
software of those workstations.)  Sometimes round trips get worse than
50 msec, but then I've noticed my telephone tends to not work very well
shortly before the building is rattled by thunder.

Do you guys think that all of the "multi-media" people are without a
clue or a hope?  (I think many lack one or the other, but few lack
both.)


I'm trying to politely suggest that you telephony guys should get out
more.  See other parts of the world.  Good data networking people
generally know they don't know about telephony, but it is strange the
obverse does not seem to apply.  (I won't claim in public to be good,
but I will claim to not know too much about telephones.)


Vernon Schryver,  vjs@sgi.com
From: gsa@easyaspi.udev.cdc.com (gary s anderson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Cell SIze
Date: 24 Jul 92 17:04:37 GMT
Reply-To: gsa@easyaspi.udev.cdc.com (gary s anderson)

In article <miw.711957276@cc.uq.oz.au>, miw@cc.uq.oz.au (Mark I. Williams) writes:
|> 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

Pardon my simple-minded question, but I am confused about the 
"multi-service" versus "data-only" statements which keep cropping
up on this "station".

As we evolve into a fully digitized environment, don't all transmission
elements become "just another datagram"?  We may have differing quality of 
service requirements for various datagrams, but the transmitting and
receiving elements are dealing strictly with datagrams.  The parties
at the "end-of-the-line" can view/listen/feel/smell/taste depending
on the possible translations of any incoming message.

My view is that the nominal phone service is just another ATM 
application sending packets with a desired quality of service option
selected.  Am I missing something significant?  Will the phone service
have its own dedicated "out-of-band" paths through the ATM switches?
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Congestion Avoidance
Organization: CERN European Lab for Particle Physics
Date: Mon, 27 Jul 1992 10:13:27 GMT

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

There is nothing new under the sun and M/D/n queuing systems still
behave the same as when Kleinrock wrote the book. The most convincing
story I've heard from an ATM switch fabric designer is "we've ensured
that the fabric can saturate all its outputs simultaneoulsy, and we've
put in enough buffers to guarantee correct re-ordering of cells at every
output." What this means is that if the total traffic at the _inputs_
exceeds the total capacity of the outputs for longer than some delta-T
you are, surprise surprise, in trouble. Of course the designers have done
statistical simulations, but they remain very scared of connectionless
data traffic.

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

Well, as long as your switching fabric is designed to be scalable you
can improve switch performance up to a point just by adding silicon -
and this seems to be more crucial than the bandwidth of trunk lines,
in controlling cell loss rates. (ATM is actually connection-oriented
with guaranteed bandwidth per channel.) But in the end, the queuing theory
will get you.


Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: stan@casc.math.uh.edu (Stan Hanks)
Subject: Re: Question
Followup-To: <1992Jul16.150120.28047@walter.bellcore.com>
Organization: Center for Advanced Scientific Computation, Houston Tx.
Date: Fri, 24 Jul 1992 07:14:25 GMT

In article <1992Jul16.150120.28047@walter.bellcore.com> you write:
>>My understanding is that cell relay, in particular ATM, has really poor
>>efficiency (~40%) when used in a LANish mode, and that under 150 Mb/s
>>or so, it's hardly worthwhile to implement. 
>
>....  The efficiency is then 44/53 =83%.   This
>is result is independent of any particular physical considerations.  


Reference the Berkeley papers from TENET project. I think the actual
title is "Efficienct of TCP/P over ATM" or some such. It used to be
up for FTP somewhere at tenet.berkeley.edu.  There's *ALWAYS* more
to life than simple calculations. Think about what sending say a 50
byte (total length) packet does to your efficiency if you have a fixed
44 byte per cell payload: one cell full, one cell with 6 bytes of data
which makes it only 11% used. A little of that goes a long way to hose
up the overall efficiency of the network.

On the 150 Mbps comment, I can't tell you the source. But it's from someone
who does chip design for ATM and related technologies.

--
Stanley P. Hanks      Principal Scientist,      Technology Transfer Associates
U.S. Snail:        P.O. Box 2087,   Bellaire    TX    77402-2087
FedEx/Shipping:    5303-F Glenmont, Houston     TX    77081
e-mail: stan@karazm.math.uh.edu   voice: (713) 661-2084     fax: (713) 661-0633
Newsgroups: comp.dcom.cell-relay
From: nagle@netcom.com (John Nagle)
Subject: Re: Congestion Avoidance
Date: Sat, 25 Jul 92 18:38:07 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

        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.

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

        					John Nagle
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: Thu, 30 Jul 1992 23:19:15 GMT

In article <12445@ntdd-1>, grayt@Software.Mitel.COM (Tom Gray) writes:
> ...
> :> Now the LAN  industry itself is rapidly accepting ATM. This
> :> industry expects ATM to supplant existing protocols by
> :> 1995....

> I didn't make the prediction of the 1995 date. This prediction was made
> by the representatives of the LAN industry at last years LCN
> conference....

What was this "LCN conference"?

I'm a certified, fur-sure, senior droid working on high speed LAN's and
slow speed WAN's for a major workstation company.  That I don't
recognize even the name of the conference should tell you something
about how representative were those the "representatives of the LAN
industry."  I don't even know what the "LAN industry" might be.

If the "LAN industry" is the people making the stuff connecting the
computers, you should be skeptical.  They have not been very right in
the past, and tend to push whatever they are currently hoping to
deliver in the quarter after next.  (Like everyone else.)

If it's the people making the computers that justify buying networks
stuff, I wouldn't listen too hard.  The computer vendors have fewer
axes to grind, but they also bigger problems than networks, including
Sun and DEC with their "the network is the computer" slogan.  The
product managers for network stuff at computer places are rarely the
most influential or best informed.

Among of the neat things about such conferences is that you can find
some of the most wonderful quotes--to attribute to someone else.  The
really big conferences have speakers who are academic experts (i.e.
people working and teaching at universities) and some industry big
shots (e.g. managers who once or twice 10 or 20 years ago did something
impressive).  Both of those types are often pumping for funding inside
or outside their organizations; I've seen that from close up.  A
distant from me but current example is the conflict between HIPPI
(including serial HIPPI) and Fiber-channel.  Advocates of each predict
theirs will dominate the universe any month now, and both assert quite
confidently that ATM has no chance of every being used for anything
related to a LAN.

The smaller conferences (i.e. all but the top 2 or 3 per year--are
there as many as 3 "top" networking conferences?) tend to have more
"product managers" and fewer academics or big shots.  I won't name the
product managers of the stuff I work on, because they're good guys, and
because I wouldn't cross a hallway, not to mention an exhibit hall, to
listen to their predictions of how networking will evolve.  They are
paid to be enthusiastic about what they're pushing, and only realistic
enough to not look silly to prospects.  In other words, they're
expected to look silly to people on the inside.


Vernon Schryver,  vjs@sgi.com
Organization: University of Maine System
Date: Tuesday, 28 Jul 1992 00:13:11 EDT
From: James <IO92142@MAINE.MAINE.EDU>
Newsgroups: comp.dcom.cell-relay
Subject:    Digital Telephony/FBI?


This is an article that I read in MacWeek. I am wondering if anyone
might have any information about this or is anyone up to speed with
these developments?  Responses via email will be appreciated.


===================================================================
Digital Telephony-MacWeek-7.12.92

Washington

The FBI has sharpened language in proposed legislation that would require
government wiretap access to all U.S. voice and data networks.

The proposal, known as Digital Telephony, is a response to new telephone
technology, which the FBI claims makes eavesdropping more difficult.  The new
draft includes and explicit call for law enforcement monitoring facility with
remote access to every voice and data network in the country.  The FBI also
called for the Federal Communications Commission to relinquish its
standards-setting and device-certification authority to the U.S. Attorney
General, who could force wiretap-secure networks open with fines of up to
$10,000 a day.

The FBI told computer and communications industry leaders that its wiretap
shopping list includes access to all present and future network technologies,
including Ethernet, X.25, cellular networks and Electronic Data Interchange
systems.

"In its current form Digital Telephony would open the entire universe to
wiretaps," said Don Gilbert, information services directory at the Washington,
D.C.- based American Petroleum Institute.  He is among 40 industry leaders
opposing the proposal.

The bill still has not found a sponsor on Capitol Hill.  Nevertheless, the FBI
has not backed down.

Attorney Mike Godwin, counsel to the Cambridge, Mass.-based Electronic Frontier
Foundation, said the FBI remained adamant because Digital Telephony is a
backhanded attempt to prevent the use of encryption on U.S. networks.  The
Department of Justice, the FBI's parent agency, launched anti encryption
legislation in 1991, Senate Bill 266, which did not pass.

"They are asking for an outrageous level of access because they can back down on
the condition that a ban be placed on encryption," Godwin said.
"It leaves us where we would have been if S.B. 266 has passed."

=-=-=-=-=-=--=-=-=-=
James Gray                           Bitnet   :  IO92142@Maine
University of Maine                  Internet :  IO92142@Maine.Maine.Edu

Newsgroups: comp.dcom.cell-relay
From: tonyg@spock.retix.com (Tony "Salty Dog" Goulding)
Subject: Re: Curious attitude ...
Organization: Retix, Santa Monica CA
Date: Fri, 31 Jul 1992 17:20:44 GMT

In article <12467@janice> grayt@Software.Mitel.COM (Tom Gray) writes:
>In article <l7g4nrINNfjd@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>>    
>>    
>>    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? 
>>
>
>FRame relay is a connection oriented layr 1.5 protocol. It is a
>fast packet technology that uses the ideas of ATM. 
>The only essential difference between frame relay and
>cell relay is that one uses variable length packets
>and the other uses constant length. The essence of ATM
>is the lack of sequencing, error correction etc.
>built into these edge to edge protocols.
>
>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. 
>
>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.
>
>The problem here seems to be one of terminology. There is
>confusion because the B-ISDN groups have termed their cell
>relay level the ATM level. ATM was concieved in '70's.
>Cell relay is a refinement which improves on the
>edge to edge ideas of ATM but is not an original
>component.
>-- 
>i.sinature

Tom, you <conveniently> ommitted Tony Li's responses to your previous
assertions - you only addressed his last one. Do I conclude that you 
concur?
I'm not trying to inflame, as an ATM neophyte I'm enjoying these threads
and want to make sure that I'm getting all the right info...
Tony.

-- 

==================================================================
Q:	What is the difference between LA and yoghurt?
A:	One is cultured...
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Question
Organization: CERN European Lab for Particle Physics
Date: Wed, 22 Jul 1992 13:16:16 GMT

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

>This limit of 64K is baloney.
>With Large Windows, you can send as much as you want between ACKs.

>Sorry about that.


Yeah, if only you could get working implementations on all
popular systems, sigh...

  -- Brian
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 30 Jul 92 20:39:48 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <l7g4nrINNfjd@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>    
>    
>    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? 
>

FRame relay is a connection oriented layr 1.5 protocol. It is a
fast packet technology that uses the ideas of ATM. 
The only essential difference between frame relay and
cell relay is that one uses variable length packets
and the other uses constant length. The essence of ATM
is the lack of sequencing, error correction etc.
built into these edge to edge protocols.

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. 

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.

The problem here seems to be one of terminology. There is
confusion because the B-ISDN groups have termed their cell
relay level the ATM level. ATM was concieved in '70's.
Cell relay is a refinement which improves on the
edge to edge ideas of ATM but is not an original
component.
-- 
i.sinature
From: jqj@nntp.uoregon.edu (JQ Johnson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Curious attitude ...
Date: 31 Jul 92 02:15:48 GMT
Organization: University of Oregon Network Services

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

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.
-- 
JQ Johnson
Director of Network Services		Office: 250E Computing Center
Computing Center			Internet: jqj@ns.uoregon.edu
University of Oregon			voice:	(503) 346-1746
Newsgroups: comp.dcom.cell-relay