Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

In the following page: https://kitz.co.uk/adsl/linestats_errors.htm, Kitz wrote the following concerning HEC errors in ATM:

HEC Errors - Header Error Check/Correction

Count of HEC Errors. HEC is a type of CRC error check which has been performed on the header of an ATM cell, but 1 bit errors can be corrected. This count is usually where HECs have been uncorrected and have been discarded.

My question: so we are counting uncorrected HEC cells, understood. But I’d like to know a little more: what exactly does ‘discarded’ mean? Are those corrupt cells dropped or are they passed on as they are?

The upper layer can either cope with the corruption in the cell payload or it can not. If the corrupt cell payload is passed on up as is then if the upper layer has very much more sophisticated error correction of its own then it may still be able to cope despite the corruption. Also if by some minute chance the error is in the ATM 5-byte header itself, not in the cell payload, then the HEC error can be ignored but there’s no way of knowing that apart from the use of some higher level CRC which is unknown in this layer. Anyway, so it’s surely far, far better to pass on the presumed bad cell to the upper layer rather than dropping it as that will certainly ruin any chance of a packet being corrected successfully in an upper layer? Dropping it seems like madness. Is my reasoning here correct?

[burakkucat]

Looking at the Header Error Control (HEC) section, I see --

A CRC type of algorithm used for checking and correcting an error in an ATM cell header. HEC has single bit error correction and multiple bit error detection capabilities. ATM equipment checks for an error and if possible will correct it.

<snip>

Multiple bit errors are discarded and re-requested.

The last sentence is important . . . any ATM cells which have multiple bit errors are discarded and those cells are requested for retransmission. (My understanding.)

[Weaver]

Discarded, understood. Sorry, I don’t understand the retransmission part. Does ATM or AAL5 have retransmissions in the protocol?

If that is not the case, are you referring to L2 ReTx using a different protocol, such as G.INP?

This is merely my own understanding of things and please tell me if I have got things wrong: In G.INP - and presumably PhyR too - a DTU is a certain number of whole suitable protocol-specific fragments and what a fragment is depends on the upper layer in use; if ATM then a fragment is a cell including ATM header, or if PTM with 64/65B framing then a fragment is a 65 byte unit - see G.992.3 Annex N. Either way, a DTU is a string of whole data units according to the layer in use above, it does the right thing™ and makes sure that packet boundaries are aligned with inter-DTU boundaries so for example in the case of ATM never transmits a DTU containing 3.5 cells and the last half in the next DTU.

By definition, G.INP DTUs are the units retransmitted in G.INP and in the case of ATM the DTU will be some number of whole ATM cells. I expect the number will be > 1 so in that case each DTU and therefore each unit retransmitted will contain some n > 1 cells and if so there will be no way of retransmitting a single ATM cell in G.INP.

[burakkucat]

I believe I am correct in saying that ATM cells pre-date both ITU-T G.998.4 (G.Inp) and Broadcom PhyR by many years, so it may be best not to attempt to compare and contrast the former with the two latter techniques.

How an ATM cell is retransmitted seems to be a mystery (at least, to me). I can only assume that either the ATM protocol or the adaption layer (AAL5) takes care of the retransmission.

Perhaps another member may be able to illuminate the technique for us? 

[ejs]

the error is in the ATM 5-byte header itself, not in the cell payload

The HEC only covers the ATM cell header, not the payload.

ATM equipment may well correct single bit errors in the ATM cell header. DSL does not.

There is no retransmission of anything managed at this ATM layer in DSL. Without G.INP or PhyR, the only way data will be re-transmitted will be by a much higher layer, such as TCP or the application.

[Weaver]

Agrees with ejs. I did not think there was any retransmission mechanism.

I understood Burakkucat’s point about the age of ATM, it predating the likes of G.INP. I was just checking for crossed wires between the two  of us. 

[niemand]

Bit of a 'sevenlayermuddle' going on here