RE: IEEE 802.3 Requirements
- To: msalzman@xxxxxxxxxx, stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
- Subject: RE: IEEE 802.3 Requirements
- From: "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>
- Date: Thu, 20 May 1999 09:44:29 -0400
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Thanks very much for offering solutions to the idea.
I agree that 802.3 does not have the access to the retry counters, which
resides in the Transport Layer, TCP. There are several classes of TCPs.
Among them, the protocol "TCP over Ethernet" is specifically designed to
communicate the fault status, retry failure, to MAC level. We can use it to
shut down and ask servicemen to check for bad fibers.
Alternately, your solution is also very practical and simple, which is easy
We can perfect both methods for users as options, so they can chose
whichever fit them the
Thanks again for providing an alternative solution.
From: Michael M. Salzman [mailto:msalzman@xxxxxxx]
Sent: Thursday, May 20, 1999 12:28 AM
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
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.