Cell Relay Archive

[Marc Delvaux <mdel@globespan.net>]

I cnnot resist jumping on this one.  I'll try to summarize
my view.
If the PMD is such that it results in error patterns that are
different from isolated errors, then HEC error correction is
useless.  This is the case for most coded types e.g. 4B/5B
and corresponding TC indicate that HEC correction is not
allowed.
If for a given PMD isolated errors may be expected, then
HEC correction reduces significantly the cell loss ratio.
Assuming independent isolated errors at low ber, CLR is
~ 40 BER without correction and about ~ 800 BER^2
with error correction.  This is a big difference.
The FSM that alternates between correction and detection
mode is only useful if errors are "correlated" and for times
between 1 and 6-7 cells.  After that, cell delineation is
assumed lost anyway. So its usefulness is relatively limited.
HEC correction helps AAL where cell loss is bad but some
amount of errors in the payload is acceptable, i.e. this is good for
AAL1 but mostly useless for AAL5 (as you mention)  The
only positive effect for AAL5 is to avoid some case where the
lost of the last cell would result in two packets coalescing
compared to only losing one packet in this specific case.

So, because the ATM layer must support different AAL,
HEC error correction makes sense for the correct PMD.
The next question, and i have no definite answer on that one:
"Are there any PMD where isolated bit errors represent
a significant part of all bit errors?"  From what i gathered,
fiber links are relatively close to that, there is some correlation,
but not that bad as to completely wipe the potnetial gain
of HEC correction (again, reduce the cell loss rate).

As a side note, you are right in estimating that error correction
is not used so as to decrease the probability of false synch.  In
fact the HEC cell delineation algorithm treats all errors in the same
way, i.e. it works in the same way with and without HEC
correction.  The linguo is correct HEC in I.432, not corrected e.g.

albert.e.manfredi@boeing.com wrote:

> In article <3801FBE9.172B4118@lucent.com>,
>   "ronald h. davis" <ronaldd@lucent.com> wrote:
>
> > let's put this in context.  the atm layer is concerned only with
> seeing
> > to it that payload content is properly delivered to it's destination.
> > thus, it is focussed only on correction of the header.
> >
> > it is the atm adaptation layer which deals with the payload content.
>
> Yes, as I had also pointed out. The 32-bit CRC in AAL5 has this chore.
>
> However, to put this discussion in context, _if_ an occasional
> corrupted cell header does _not_ in practice result in dropping sync,
> _then_ it seems quite unnecessary to bother with correcting cell
> headers. There just seems no real-world payoff.
>
> > if one wishes to have the ability to recover from corrupted payload,
> > it is detected in the aal, with the corrupted data delivery option
> > allowing the aal to pass corrupted data to the higher layer protocol
> > with an indication of what in the payload is corrupted (e.g. crc
> error).
> > it is then the responsibility of the upper layer protocol to determine
> > what is to be done with the information (i.e. correction, or discard).
>
> Yes. And if the cell header _correction_ features of HEC are used
> effectively, i.e. there are many incoming cells with single-bit errors
> in the header, chances are mighty good that in fact the AAL5 CRC will
> be trashing the entire frame regardless. So why bother with correcting
> these cell headers (when AAL5 is used)?
>
> When AAL1 is used, the fact that sync isn't dropped upon receipt of
> just an occasional bad cell header makes one come to the same
> conclusion.
>
> > i say this to underscore that it is not correct to imply that atm can
> > do nothing in the event of corruption of payload.  how meaningful this
> > action is, however, is a function of what your assumptions are of the
> > distribution of errors in the system.
>
> That's exactly what Paul Koning was pointing out.
>
> > as far as the "clumps of errors" bit goes, atm assumes that the ber of
> > the transmission medium is low.  this allows you to reduce the number
> > of error checks that need to be performed at each node in the network.
> > if ber of the transmission medium is questionable, then you might be
> > better off with a more robust protocol such as x.25.
>
> That's unfair. ATM _is_ also specified for UTP and STP, so clumps of
> errors are perfectly expectable(?). Using X.25 is a little like
> suggesting we use smoke signals.
>
> --
> Bert
> manfredi@arl.bna.boeing.com
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.



begin:          vcard
fn:             Marc Delvaux
n:              Delvaux;Marc
org:            GlobeSpan Semiconductors
adr:            100 Schulz Drive;;;Red Bank;NJ;07701;USA
email;internet: mdel@globespan.net
title:          LSI designer
tel;work:       +1 (732) 345 7502
tel;fax:        +1 (732) 345 7592
tel;home:       +1 (732) 578 9255
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard