NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/cellrel/241

Internet Message Format | 1992-07-24 | 3.2 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!umeecs!umn.edu!noc.msc.net!uc.msc.edu!shamash!easyaspi.udev.cdc.com!gsa
From: [e-mail] (gary s anderson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Cell SIze
Message-ID: <[e-mail]>
Date: 24 Jul 92 17:04:37 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (gary s anderson)
Lines: 55

In article <[e-mail]>, [e-mail] (Mark I. Williams) writes:
|> [e-mail] (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       [e-mail]
|> [phone]   (w)  Prentice Centre
|> [phone]  (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?