RE: CRC check indication of bad fiber

[Mick Seaman <mick@xxxxxxxxxxx>]

Let me be a little more careful in my choice of words, and also plead for a
little tolerance while I get educated.

One physical bit error might get changed into a number (>1) of data bit
errors? I should have said terms in the scrambling polynomial (?)

Assuming a self synchronizing scrambler as per other technologies are there
any new consequences for Ethernet?

What are the consequence of these with regard to assumptions of CRC
protection level against envisaged noise characteristics?. None at all?

I'm not suggesting that an avalanche occurs. I'm very happy with a
conclusion that says the CRC is all we need. Simplifies life enormously.

Mick

> -----Original Message-----
> From:	Jaime Kardontchik [SMTP:kardontchik.jaime@xxxxxxxxxxx]
> Sent:	Thursday, May 20, 1999 4:45 PM
> To:	Mick Seaman; stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> Subject:	Re: CRC check indication of bad fiber
> 
> I do not think so.
> 
> Once the descrambler at the receiver has been synchronized, single bit
> errors
> in a frame during transmission will usually generate single bit errors in
> the
> receiver (or a few errors, depending on the additional coding using in the
> transmitter). These single-bit errors (or few bit errors) will be detected
> by
> the CRC. And the descrambler will remain usually synchronized even in the
> presence of isolated transmission errors. So, no avalance of errors will
> be
> produced as long as the descrambler remains synchronized.
> 
> In order for the descrambler to loose synchronization something
> catastrophic
> has to occur, for instance the closening of the eye at the equalizer in
> the
> receiver (if there is an equalizer there) and the failure of the timing
> recovery circuit of the receiver.
> 
> Jaime E. Kardontchik
> Microlinear
> San Jose, CA 95131
> email: kardontchik.jaime@xxxxxxxxxxx
> 
> 
> Mick Seaman wrote:
> 
> > My understanding is, that if the data is scrambled, one physical bit
> error
> > can be turned into a large number (order of the scrambling polynomial?)
> > data bit errors.
> >
> > This could much reduce the degree of error checking/protection provided
> by
> > the CRC, presuming that to be calculated over the data bits rather than
> the
> > physically transmitted bits and to remain the same 'end to end' where in
> > this case I mean that much interpreted term to mean over a number of
> number
> > of .1D bridges or a number of repeaters (are full-duplex repeaters
> capable
> > of all potential media type conversions with the different transmission
> > arrrangements under discussion?).
> >
> > So it may be necessary to add extra information to the frame (or to a
> set of
> > frames) to guard against bad fibers (?).
> >
> > Mick
> >
> > > -----Original Message-----
> > > From: Chang, Edward S [SMTP:Edward.Chang@xxxxxxxxxx]
> > > Sent: Thursday, May 20, 1999 1:58 PM
> > > To:   Drew Perkins; 'msalzman@xxxxxxxxxx';
> > > 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
> > > Subject:      RE: IEEE 802.3 Requirements
> > >
> > >
> > > Drew:
> > >
> > > Yes, at MAC level, the CRC of the whole packet is checked; therefore,
> it
> > > can
> > > be used for indication of bad fibers.  However, we have to
> differentiate
> > > the
> > > normal read errors from the persistent errors generated by a bad
> fibers.
> > > Any way, it can be done.
> > >
> > > Ed Chang
> > > Unisys Corporation
> > >
> > > -----Original Message-----
> > > From: Drew Perkins [mailto:drew.perkins@xxxxxxxxxxxx]
> > > Sent: Thursday, May 20, 1999 2:32 PM
> > > To: 'msalzman@xxxxxxxxxx'; 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
> > > Subject: RE: IEEE 802.3 Requirements
> > >
> > >
> > >
> > > Is there any reason that the Ethernet CRC wouldn't make a pretty darn
> good
> > > error detection mechanism?
> > >
> > > Drew
> > > ---------------------------------------------------------
> > > Ciena Corporation                 Email: ddp@xxxxxxxxxxxx
> > > Core Switching Division                 Tel: 408-865-6202
> > > 10201 Bubb Road                         Fax: 408-865-6291
> > > Cupertino, CA 95014              Cell/Pager: 408-829-8298
> > >
> > >
> > > -----Original Message-----
> > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Michael
> M.
> > > Salzman
> > > Sent: Wednesday, May 19, 1999 9:28 PM
> > > To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > Subject: RE: IEEE 802.3 Requirements
> > >
> > >
> > >
> > > Hi Ed, comments offered below on your ideas.
> > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Chang,
> > > > Edward S
> > > > Sent: Wednesday, May 19, 1999 10:44
> > > > To: Bruce_Tolley@xxxxxxxx; msalzman@xxxxxxxxxx
> > > > Cc: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > > Subject: RE: IEEE 802.3 Requirements
> > > >
> > > > First of all, all datacom equipment have built-in error-check
> routines
> > > to
> > > > count the number of retries with a given client.  When that number
> > > reaches
> > > > the preset "water-level", it will give up retry and report the
> problem.
> > > > These mechanisms are already in place, and we do not need to
> reinvent or
> > > > re-invest.  We may modify the error check routines to fit our
> purpose.
> > >
> > > Ed,  802.3 does not have access to any retry counters of any higher
> level
> > > protocols.  Furthermore, not all protocols rely on retries.  The MAC
> layer
> > > has access only to its own activities, which include send packet
> attempts.
> > > In a full duplex configuration the send attempts are always
> successful,
> > > unless the entire layer fails.  The only way to measure a live error
> count
> > > is to run some kind of OAM channel and to pass test frames over it.
> > > Furthermore, some coding schemes, can give abrupt indication of sync
> loss.
> > > In summary, at the MAC layer, it is difficult to assess channel
> > > deterioration.
> > >
> > > A practical approach is to detect link failure, shut it down, and then
> do
> > > link acquisition which includes link quality testing at full rate, and
> to
> > > then either declare the link dead or alive.  That's roughly what is
> done
> > > in
> > > 1GE and we can improve upon it for 10GE, or we can add optional
> > > improvements
> > > for, say, MAN applications.
> > >
> > > >
> > > > Second, we, TIA FO2.2, have studied many of the MM fibers in
> industry
> > > with
> > > > varieties of launch conditions; therefore, we should be able to
> > > > come up with
> > > > a realistic, optimized cable plant design to drastically improve the
> > > > performance, and at the same time, reject those DMD, or bad fibers.
> > > > Remember, those are defected fibers, which is wrong to be in the
> market
> > > in
> > > > the first place.  We have pretty good idea how it may shape up.
> > > > We are not
> > > > talking taking-chance with ignorance, or try-and-error.  We all
> > > > have product
> > > > responsibility; as a result, reliability and customer satisfaction
> are
> > > > always the first priority.  It implies that the rejection ratio is
> in
> > > the
> > > > minimum, limited to those DMD and bad fibers only.
> > >
> > > Ed, I am not sure what you are suggesting.  Perhaps you can offer a
> > > presentation on this idea in the meeting.
> > >
> > > Mike.