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

Text File | 1992-07-25 | 3.8 KB | 81 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!miw
From: [e-mail] (Mark I. Williams)
Subject: Re: Cell SIze
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Prentice Centre, University of Queensland
References: <[e-mail]> <[e-mail]>
Date: Sat, 25 Jul 1992 04:59:33 GMT
Lines: 69

[e-mail] (gary s anderson) writes:

>In article <[e-mail]>, [e-mail] (Mark I. Williams) writes:
[....]
>|> Yes, but...but.... This analysis considers data traffic only! Remember
[....]

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

You probably have adequate grounds for confusion. We are using the terms
of yesterday to describe the networking of tomorrow. What *I* meant was
"You are considering traffic generated by the devices which currently
use todays packet-switched networks."

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

Your view is correct. It is hoped the future BISDN will be able to
handle all forms of traffic: Data, Voice, Video, etc. In this sense, Data
and Voice, although they are both coded digitally are indeed different,
because the QOS requirements are different. (in fact, there are
different QOS requirements within each of these categories).

The concept of a BISDN is predicated on the fact that you get a
"bundling advantage" by putting all services onto one integrated network
which can achieve any QOS we can reasonably envisage. The moment you
make a decision that precludes the carriage of even one kind of traffic
you have lost your BISDN network. In my view, using fixed-sized sells
with 128-octet payloads would mean telephones could not be included on
the BISDN. Note that I am *not* saying that ATM is the only way you
could solve the problem! ATM  with a fixed 48+5 octet cell size is just
the solution that has been chosen, so we have to live with the choice.

Optimising ATM for IP traffic would be madness. If you wanted to
optimise ATM for any particular service, it would be video or multimedia
publishing. It seems almost certain that these two types of data will
provide a traffic load at least an order of magnitude greater than the
rest of the traffic put together.

It would make much more sense to optimise IP  and IP-based equipment for
ATM and ATM-like (e.g.  IEEE 802.6, etc. etc.) networks. I can think of ways
to do this without even altering IP from its present form. For example,
in current IP networks, most wide-area traffic occurs on point-point
links between routers, and even in the future LAN-interconnect traffic
for most sites will travel between collection points analogous to
today's routers. In this case, why on earth should these collection
points feel restricted to carrying different IP-layer packets in
different cells? These devices will be trying to optimise costs by doing
traffic-shaping anyway, so they could easily aggregate
packets/frames/whatever before splitting them up into cells.

ATM will provide a data pipe you can use in whatever way you see fit,
and clever vendors will design equipment that use it efficiently and in
a manner which costs their customers as little as possible.
Vendors who can't escape the Ethernet mentality will run out of things
to eat.

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