Subject: Re: ifInOctets/ifOutOctets on Ethernet

From: "Dan romascanu DVP-TA" <[email-masked]>
Date: Thu, 30 Jul 98 14:06:42 +0300

John,

We should carefully consider what changes we bring, so that we reflect a 
solution that is both 'clean' and does not shatter the existing 
implementations for 10/100. I hope such a solution does exist. 

If we stick to the definition in 3.2.7. we need to change the text in 
3.4. as definitively ifOutOctets and ifInOctets as defined in RFC 2233 do 
not map to aOctetsTransmittedOK and aOctetsReceivedOK. The difference 
needs to be clarified.

>The questions we should consider, and clearly document
> decisions to, are:
> 
>   - Should these counts include the PREAMBLE and SFD fields?
> 

The way we define it today does not include PREAMBLE and SFD. I do not 
know how many exising implementations this would break, but a change 
would definitively create an inconsistency.

>   - On half-duplex Gigabit, should these counts include the EXTENSION
>     field?
> 

If somebody out there does half-duplex Gigabit (?) and cares, let him 
talk.

>   - Should these counts include octets in invalid frames?  If so, just 
>     for the InOctets, or for both?
> 

Our definition in 3.2.7. contradicts the ifInOctets and ifOutOctets 
definitions. I do not know if existing implementations could possibly 
support the 'correct' Interfaces MIB definition, without significant 
cost. Allover, I rather prefer remaining the way it is defined today in 
3.2.7., but clearly state and explain the differences and exceptions that 
we make for the Ethernet interfaces.

Dan

--------------------------------------------------------------------------
------
Dan Romascanu,
Systems Architecture Group Manager,
LANNET Ltd.,
Voice: 972-3-645-8414, e-mail: [email-masked]
--------------------------------------------------------------------------
------

---

From: John Flick <[email-masked]>
Date: Thu, 30 Jul 1998 11:56:02 -0700 (PDT)

> implementations for 10/100. I hope such a solution does exist. 

The text I quoted from Section 3.2.7 was new to RFC 2358.  I wrote it, 
and there was no discussion on the mailing list.  Only one person
questioned it, and that was long after Last Call.  I mainly raised
this to call peoples attention to the text in RFC 2358, Section 3.2.7,
and verify that it really matches current implementations.

 > not map to aOctetsTransmittedOK and aOctetsReceivedOK. The difference 

I am planning to add the following text to Section 3.4:

   * Note that the octet counters in IF-MIB do not exactly match the
   definition of the octet counters in IEEE 802.3.  aOctetsTransmittedOK
   and aOctetsReceivedOK count only the octets in the clientData and Pad
   fields, whereas ifInOctets and ifOutOctets include the entire MAC
   frame, including MAC header and FCS.  However, the IF-MIB counters
   can be derived from the IEEE 802.3 counters as follows:

     ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK)
     ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK)

This text assumes that the text in 3.2.7 is correct.

 > would definitively create an inconsistency.

I just want to make sure that current implementations of IF-MIB on
Ethernet are not including PREAMBLE and SFD.  If they are, then 
RFC 2358 is wrong and should be corrected.  For now, I am assuming
2358 is correct, until someone contradicts me.

 > If somebody out there does half-duplex Gigabit (?) and cares, let him 

:-)  I just want to know what the text for son-of-2358 should say
here: include it or no?  Extension octets are entirely new with
Gigabit, and we need to decide how to treat them.  For now, I am
assuming that they would NOT be included in the octet counters.

 > we make for the Ethernet interfaces.

Again, I want to make sure that current implementations of IF-MIB for
Ethernet match what I wrote in RFC 2358.  If not, RFC 2358 is wrong
and needs to be corrected.  To write the correct text requires that we 
understand what current implementations are doing.  Basically, I am
assuming that RFC 2358 is correct, and challenging anyone who
disagrees to prove me wrong.  I think that you are correct that trying 
to count octets in invalid frames opens up the can of worms of exactly
which packets we do count.  Collision fragments?  Short events?  Most
LAN controllers ignore these, and don't even notify the driver when
they occur.  What about on transmit?  Include octets from collision
fragments that we generate?  Again, most LAN controllers don't provide 
any way for the driver to find out about these.

Again, my default assumption is that the text in RFC 2358 does not
need to change.  Anyone who disagrees needs to speak up.

John