Re: RUNT Packets
Shimon,
The ability of upper layer protocols to handle data loss only compounds the
problems of application latency over IP services and networks. For the
so-called "promise" of IP services and networks is to provide global shared
access, the quality of that remains very poor compared to standard voice
Plain Old Telephone Service (POTS) networks. In order to be able to even
get close to POTS quality, the issue of data loss MUST be addressed. The
only way that will occur, will be if it is known why the data is being
lost. One of the most frustrating issues with attempting to troubleshoot
Packet Over SONET (POS) data loss problems is that there is no MIB function
that states why packets get dropped in the interface. One of the hopes
that I have is that, in addition to being less expensive, 10GbE WAN
interfaces will be more reliable than the POS interfaces have been. One of
the primary ways for improving the reliability of an interface is to have
an error reporting scheme that reports ALL potential errors. That way, if
errors do occur on a regular, repeating basis, the causes of those errors
can be investigated and resolved. In order to determine the repetition,
counters are necessary. As for backward compatibility, adding error
counters to one MAC that are not in an older one will not effect their
ability to interoperable. Adding the error counters to the MAC will
continue to improve the functionality and reliability of Ethernet, as a
whole, in the future. I do not know what kind of impact that will have on
the gate count or complexity of the MAC devices to be able provide these
counters. I would like to see one of the MAC chip developers make a
comment on this.
Thank you,
Roy Bynum
At 03:59 PM 11/16/00 -0800, Shimon Muller wrote:
> > I have to disagree with your statement of "The MAC silently discards
> packets
> > that are shorter than the minimum". When MAC is receiving a packet and
> > forwarding the packet data to the host. If the the EOP comes before 64th
> > byte, MAC needs to inform host to discard the packet and that packet needed
> > to be counted in RMON. Otherwise we will see packets disappear (packet
> counts
> > mismatch) if they are shortened by what ever reasons.
>
>I am still not convinced why this event has to be reported to RMON. Packets
>on networks disappear all the time for various reasons, and the higher level
>protocols know how to deal with that. Not everything has to be handled in
>Layer 2. But for the sake of argument let's assume that it is desirable.
>
>
> > Standard doesn't need to say anything about it, but saying "The MAC
> silently
> > discards packets that are shorter than the minimum" is not good.
>
>Well, guess what? This is exactly what the standard says now:
>
> Sub-clause 4.1.4:
> "j) Discards received transmissions that are less than a minimum length."
>
> Sub-clause 4.2.4.2.2:
> "The shortest valid transmission in full duplex mode must be at least
> minFrameSize in length. While collisions do not occur in full duplex
> mode MACs, a full duplex MAC nevertheless discards received frames
> containing less than minFrameSize bits. The discarding of such a frame
> by a MAC is not reported as an error."
>
>It appears in another few places, but this should do.
>
>We had this in the standard for years and it never was a problem. I don't
>think we should do anything different now. If somebody wants to count these
>fragments, he is free to do so. But, mandating it now would make a lot of
>MACs non-compliant.
>
>
> > And I believe most MACs in the market count undersized packets.
>
>I don't think so.
>The MAC has no way of distinguishing a collision fragment from a "short
>packet". Therefore, on a shared Ethernet network this counter will count
>lots of collision fragments. And, by the way, there are still a lot of
>shared Ethernet networks out there...
>
>
> > Of course, most undersized packets don't come with good CRC. But we can't
> > make this kind of assumption.
>
>It doesn't matter. If the packet is shorter than 64 bytes, the MAC doesn't
>check the CRC.
>
>
>So, to make a long story short, I don't think we need to make this more
>complicated than necessary. This is not a new issue, and so far it did
>not prevent us from doing the right thing.
>
>
> Shimon.