RE: IEEE 802.3 Requirements

["Michael M. Salzman" <msalzman@xxxxxxx>]

Hi yet again.

The misconception here is that we (the MAC and higher layers) get to react
to the errors.  The errors, if they occurr and propogate in the encoded
symbol stream will usually cause severe code violations.  Most PMD/PHY
designs include feature to trigger the loss of link procedure at that point,
which allows the MAC to reset various things, and to attempt to restart the
link.  This is a practical and simple approach, which was adopted for the
1Gig MAC and it represents a good compromise among several objectives.  One
of its weaknesses is that it does not allow the PHY/MAC to express a
degradation of performance over time.  It only supports the notion of a link
up or down.

> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Chang,
> Edward S
> Sent: Thursday, May 20, 1999 13:30
> To: Drew Perkins; Chang, Edward S; 'msalzman@xxxxxxxxxx';
> 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
> Subject: RE: IEEE 802.3 Requirements
>
>
>
> Drew:
>
> The normal read errors, usually can be retried once, or twice to
> clear them,
> which are soft errors.  Of course, we are not going to over react to the
> soft errors, and shut down the link to start check fibers.
>
> On the another hand, those bad fibers cause hard errors, which can not be
> cleared, and eventually lead to the termination of connections.  If it
> happens to the link very often, it is not a soft error, and is a serious
> problem.  The terminal should be shut down for service -- find a
> bad fiber.
>
>
> When the retry routine is used, those features are already built-in;
> therefore, only minor modifications are needed.  However, to use MAC level
> CRC check to differentiate between soft errors and hard errors, we have to
> duplicate most of the retry routine to MAC level.
>
> Ed Chang
>
> -----Original Message-----
> From: Drew Perkins [mailto:drew.perkins@xxxxxxxxxxxx]
> Sent: Thursday, May 20, 1999 4:05 PM
> To: 'Chang, Edward S'; 'msalzman@xxxxxxxxxx';
> 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
> Subject: RE: IEEE 802.3 Requirements
>
>
> Ed,
> 	Your message has me confused. Why do we have to differentiate? How
> do we do this? Why is this any different from SONET B1 BIP errors?
>
> 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 Chang,
> Edward S
> Sent: Thursday, May 20, 1999 11:58 AM
> 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.
>