Subject: RFC2665 questions

From: "Sid Schrum" <[email-masked]>
Date: Fri, 17 Dec 1999 14:29:44 -0500

RFC2665 Working Group,
I am studying RFC2665 in preparation for defining hardware event counters
for an Ethernet product, and several questions/issues came up in reading the
RFC.  I was hopeing that members of the working group would provide feedback
on these two items:

1) On page 9 of RFC2665, in the description for "ifInErrors", it is
recommended that "dot3StatsSymbolErrors" be included in the "ifInErrors"
count.  This does not appear to be correct to me.  I have two concerns:
  a) "ifInErrors" should be incremented for PACKETS that were DISCARDED due
to errors in them.  However, "dot3StatsSymbolErrors" will be incremented for
collision fragments that also have Symbol Errors in them.  Collision
fragments are not packets, and collision fragments, with or without errors,
are discarded by the MAC because the network was never acquired by the
transmitting stations, and therefore no valid packets have been tranferred.
  b) More importantly, it appears to me that the recommendation for
implementing "ifInErrors" will result in double-counting symbol errors in
certain cases.  Symbol Errors are essentially PHY layer events, that the MAC
is only indirectly aware of (see 802.3-1998 Clause 30.3.2.1.5 - this is part
of "30.3.2.1 PHY device attributes".  The 802.3 Reconciliation sub-layer
maps Symbol Errors into FCS errors, therefore "dot3StatsFCSErrors" should be
incremented for packets with a valid length that experience a Symbol Error
(see note at the end of Clause 30.3.1.1.6).  Since "IfInErrors" includes
both the FCS and Symbol Error counts, then it will advance twice for Symbol
Errors that occur in valid length frames.

Am I misunderstanding something or is there an issue in this area of
RFC2665?  Any and all comments that would shed some light on this are
appreciated.

2) In RFC2665, Section 3.0 on page 4, it states that an attempt has been
made to minimize redundancy in the definition of the counters.  The
802.3-1998 "aFramesLostDueToIntMACXmitError" counter is represented by the
RFC2665 "dot3StatsInternalMacReceiveErrors" counter.  Why is
"aFrameLostDueToIntMACXmitError" not represented by the "ifInDiscards"
counter?  For Ethernet interfaces, what are the theoretical and practical
differences between "ifInDiscards" and "dot3StatsInternalMacReceiveErrors"?

Sincerely,

Sid Schrum