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

Text File | 1992-07-22 | 4.2 KB | 91 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!gatech!europa.asd.contel.com!darwin.sura.net!jvnc.net!nj.nec.com!rsd
From: [e-mail] (Rajiv Dighe)
Subject: Re: Packet Sizes
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: C&C Research Labs, NEC USA, Princeton, N.J.
References: <[e-mail]>
Distribution: na
Date: Wed, 22 Jul 92 20:58:09 GMT
Lines: 78

In article <[e-mail]> [e-mail] (Fred R. Goldstein) writes:
>
>The 48-byte cell size, of course, stinks.  If we were building an ATM
>network for data alone, Craig's 128-byte payload is about right.  It's
>even big enough to carry a sort TUBA (briefly IPV7) packet :-) .
>
>Given that PCM voice generates 8 octets/millisecond, cell size sets
>voice delay (for one-user full cells).  For a while, ATM was 64 Octets,
>but France wanted 32.  Why?  Because if you added the speed-of-light
>delay for a call the length of France, and added 4 ms (32-octets) delay,
>you'd just barely get away without echo cancellers.  The extra 4 ms.
>made echo cancellers seem necessary.  Now a bigger country like the USA
>would need echo cancellers anyway, in which case a few extra ms. delay
>(even 16 ms.) would be harmless.  So at 48 octets, EVERYBODY LOSES!
>That's the way CCITT works; consensus ain't cheap.
>
>I personally suspect that ATM nets (carrying data) will have LOTS
>of cell loss, which will require fairly small retransmission-units
>(R.U.)  If you use AAL5 alone, then the packet is the R.U.  If you
>use AAL5 or AAL3 with SSCOP, then SSCOP allows an intermediate
>fragment size R.U.  If you use BLINKBLT, or another numbered-cell
>selective retransmit protocol, then the cell is the R.U.
>
>ATM nets are themselves physical layer; AAL is datalink, so internet
>protocols and higher will run across them.  We can _optimize_ new
>protocols to run over ATM, but will also have to live with the old.
>I'm afraid that we're going to have a lot of overhead caused by
>traffic that just misses the one-cell cutoff.  Perhaps we should move
>towards sligtly modified transport protocols too, just to reduce the
>frequency of 40-byte (longer with newer IP, most likely, or CLNP)
>packets that, with overhead, just overflow one cell.

Historical Overview :-)

Way back in the early 80's when we first started looking at the
format for B-ISDN, the first battle was ATM vs STM- simply packet
switching vs circuit switching.
It was decided to go with ATM because it had more networking features in
it.
Then was the big fixed vs variable battle.
We had proposed a multiple-length format where the size varied
from a minimum of 8 bytes to a maximum of 2048 bytes (determined
by the length of the SIZE field in the header).
Why a minimum of 8 - a nice number (power of 2) that we felt would adequately
represent the size of a header without sacrificing functionality
(remember we chose ATM for the networking features and the
power lay in the header).
Our arguement was simple.
The minimum sized packet and the maximum sized packet was a function
of the line speed, the available technology and the minimum delay
required by the most stringent service assuming a non-preemptive service
policy.
All these were going to change with time.
So at any given time, the minimum and maximum sized packet (packet is
being used here to denote cell for purely historical reasons) would
be chosen by the network manager depending on his needs,
however the protocol didnt have to change with the technology or the
need!!!!!
Unfortunately, it was widely believed that fixed length cells
were easier to switch than multiple length and so a standard was
decided based on the design of a fabric.
That the cost of the network was not in the fabric but in the OA&M
was not considered.

Our arguement then that this fixed-length decision would only add to
the complexity at the end-points due to the segmentation and reassembly
is being validated if you look at the number of different adaptation
layers we already have.

Rajiv-looking-back


>---
>Fred R. Goldstein   [e-mail]
>k1io             or [e-mail]   voice:[phone]
>Standard Disclaimer:  Opinions are mine alone; sharing requires permission.