Subject: Re: Thoughts on CRC usage

From: Juan Cantillo <[email-masked]>
Date: Wed, 2 Nov 2005 09:10:40 +0100

Not yet. We are actively working on a technical document summarizing our
thoughts and observations on this topic, that we intend to submit by the end
of this month.
The maths are ok and the simulations are running!
Juan
 2005/10/31, Gorry Fairhurst <[email-masked]>:
>
>
> Let me pick-up this thread again -
>
> Do you have any published (or technical data) to support your observations
> about the S.2 link error properties?
>
> Can I also make a plea for anyone else with understanding of this
> particular
> physical layer to also come forward and comment on this topic...
>
> Gorry
>
>
> Juan Cantillo wrote:
>
> > (This mail might appear twice in the list, since I sent it from another
> > mail address... it looks like majordomo filters the senders it doesn't
> > know, right?)
> >
> > Dear Gorry and Fausto,
> >
> > Gorry said:
> >> >>BER performance is often hard to quantify. Does that mean that
> WHATEVER
> >> >>distorted waveform is presented at the input to the receiver, the
> > output of
> >> >>the link FEC processing will result in either a BBframe being marked
> as
> >> >>invalid, or one that has up to 10-7 errors in the forwarded frames?"
> >> >>Even this is not exact, a single BBframe could (with small
> probability)
> >> >>contain many errors - and somehow this has to be detected.
> >> >>IMHO, this means we need to consider the worst-case lvele of residual
> >> >>(undetected) errors that can be presented in any single BB frame.
> >
> > 1e-7 is the Packet Error Rate (PER). This is the probability that the
> > FEC used to protect the BBFrame cannot *correct* all the erroneous bits
> > in a BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected.
> > One important strength of the BCH used is that he can also *detect* very
> > accurately that this packet was indeed erroneous after decoding;
> > theoretical estimates show that he will prove wrong only 1e-8 of the
> time.
> > So if you ask your BCH to do error *correction + detection*, at the
> > encapsulation layer, only 1e-15 of your packets will be wrong (this is
> > the "small probability" Gorry refers to)!!! At 15 Mbits/s, for frames of
> > length 384 Byte, this means one uncorrected packet every 6000 years more
> > or less :-) That means that if you If you intend to use a CRC to correct
> > link errors, it will only be activated once every 6000 years.
> >
> > To verify these estimations, we have been running some simulations under
> > various link conditions here in Toulouse since July, full time, and as
> > expected, we still have not detected a single erroneous BBFRAME on our
> > platform after FEC correction + detection :-)
> >
> >> >>The question of retransmissions is irrelevent. The issue here is data
> >> >>integrity - the probability that a corrupted block is (mis)delivered
> > to and
> >> >>accepted by an application.
> >
> > I agree with Gorry. Protecting data is the most important issue, and it
> > should not depend on padding presence/absence. IMHO, the key point is
> > analysing where the threats to data integrity come from: if we suppose
> > that an error event is due *only* to the AWGN link, Maths and
> > simulations clearly prove that CRCs could be removed. If on the other
> > hand you suppose that there might be errors *other* than link ones (say,
> > bit offsets due to bugs in the sofware/hardware), then making a CRC
> > check can be the only way to spot them.
> >
> > Unfortunately, no figures nor precise measurements/litterature are
> > available on that at our knowledge! If anyone has data on this
> > particular issue we would gratefully appreciate it. If those became
> > available you could then scale properly the length of the CRC you need,
> > if that threat proves worth it.
> >
> > Any thoughts on this?
> >
> > Juan
> >
> >
> > -----------------------------------------------------------------------
> > Juan CANTILLO - SatComs PhD. Researcher
> > Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88
> > ENST/TeSA/ENSICA/AAS, Toulouse, FR
>
>

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Wed, 02 Nov 2005 05:38:52 -0500

What is the policy of the IETF as regards "work in progress"? I had the impression that to be standardised an approach had to have been implemented.

/mjm
  ----- Original Message ----- 
  From: Juan Cantillo 
  To: [email-masked] 
  Sent: Wednesday, November 02, 2005 3:10 AM
  Subject: Re: Thoughts on CRC usage

  Not yet. We are actively working on a technical document summarizing our thoughts and observations on this topic, that we intend to submit by the end of this month. 
  The maths are ok and the simulations are running!
  Juan

    Can I also make a plea for anyone else with understanding of this particular
    physical layer to also come forward and comment on this topic...

    Gorry

    Juan Cantillo wrote: 

    >> >>BER performance is often hard to quantify. Does that mean that WHATEVER
    >> >>the link FEC processing will result in either a BBframe being marked as
    >> >>Even this is not exact, a single BBframe could (with small probability) 
    > theoretical estimates show that he will prove wrong only 1e-8 of the time.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 02 Nov 2005 12:59:44 +0100

On 2/11/05 11:38 am, "Marie-Jose Montpetit"
<[email-masked]> wrote:

> What is the policy of the IETF as regards "work in progress"? I had the
> impression that to be standardised an approach had to have been implemented.
> 
> /mjm

A standards-track document (BCP, Standard) has to be supported by
implementations from independent sources. This is a pre-requisite for a
standards-track protocol to progress as an IETF document. RFC 2026 says:
 " In general, an Internet Standard is a specification that is stable
   and well-understood, is technically competent, has multiple,
   independent, and interoperable implementations with substantial
   operational experience, enjoys significant public support, and is
   recognizably useful in some or all parts of the Internet. "

There is no requirement that all work brought to the IETF is implemented, or
even published - although both are useful ways to build consensus and ensure
correctness of an approach :-)

Gorry