RE: RUNT Packets
Geoff,
Thank you for explaining a means of adding this additional troubleshooting
functionality to the 802.3 MAC. I suspected that it would be "out of
scope" but still feasible from an implementation standpoint. If "vendors"
do implement a "RUNT" or "SHORT FRAME" counter, would it be considered as
"non-compliant" or as "compliant" with an additional feature? As with
another feature that has crept into the implementations of GbE, would
802.3WG then get involved, or would it leave that to IETF?
Thank you,
Roy Bynum
At 02:04 PM 11/18/00 -0800, Geoff Thompson wrote:
>Louis et al-
>
>Pat is correct here. Please note the Scope and Purpose of our approved PAR
>for P802.3ae.
>========================
>6. Scope of Proposed Project
>{what is being done, including technical boundaries on the work}
>[Define 802.3 Media Access Control (MAC) parameters and minimal
>augmentation of its operation, physical layer characteristics and
>management parameters for transfer of LLC and Ethernet format frames at 10
>Gb/s using full duplex operation as defined in the 802.3 standard.
>In addition to the traditional LAN space, add parameters and mechanisms
>that enable deployment of Ethernet over the Wide Area Network operating at
>a data rate compatible with OC-192c and SDH VC-4-64c payload rate.]
>
>7. Purpose of Proposed Project:
>[The purpose of this project is to extend the 802.3 protocol to an
>operating speed of 10 Gb/s and to expand the Ethernet application space to
>include Wide Area Network links in order to provide a significant increase
>in bandwidth while maintaining maximum compatibility with the installed
>base of 802.3 interfaces,
>previous investment in research and development, and principles of network
>operation and management.]
>=========================
>A change to the MAC to count RUNTs is not necessary to do the speed jump
>and I would judge it to be out of scope.
>If Louis wants to do a separate project to align the operation of 802.3
>MAC management to the RMON then he should do a call for interest. By the
>way, the traditional criteria in the IETF for including an item in the MIB
>is way below our 75% threshold and has more to do with whether anybody has
>implemented it than with it is the industry consensus to include it.
>
>Let's move on.
>
>Geoff
>
>At 10:11 AM 11/17/00 -0700, pat_thaler@xxxxxxxxxxx wrote:
>
>>Louis,
>>
>>We are writing a standard and need to keep focused on what is in scope for
>>the standard to define.
>>
>>The MAC defined in 802.3 doesn't forward a packet to the host until it has
>>checked. Of course, some implementations may start forwarding the packet
>>earlier, but providing some mechanism to cause discard of an errored frame
>>that the MAC has started to forward is an implementation issue for those
>>MACs and not an 802.3 issue.
>>
>>The MAC defined in 802.3 also does not take any action with an undersized
>>frame other than discard it. It does not do any counter update for an
>>undersized frame. We haven't changed this aspect of the MAC definition. It
>>has been this way always. Of course, an implementation or an IETF management
>>standard such as RMON is always free to add additional managed objects that
>>cover items we did not put in the 802.3 MAC decision. In that case, it is up
>>to the implementor or the IETF folks to define the way that object works.
>>The alternative is for someone to propose adding the object to 802.3
>>management.
>>
>>I do not see why we are continuing to discuss this subject. Are you
>>proposing some action for 802.3ae?
>>
>>Regards,
>>Pat
>>
>>-----Original Message-----
>>From: Louis Lin [mailto:louislin@xxxxxxxx]
>>Sent: Thursday, November 16, 2000 2:20 PM
>>Cc: stds-802-3-hssg@xxxxxxxx
>>Subject: Re: RUNT Packets
>>
>>
>>
>>Hi,
>>
>>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
>>mis-match) if they are shortened by what ever reasons.
>>
>>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. And I
>>believe most MACs in the market count undersized packets.
>>
>>Of course, most undersized packets don't come with good CRC. But we can't
>>make this kind of assumption.
>>
>>Regards,
>>
>>Louis
>>
>>Shimon Muller wrote:
>>
>> > > The important point is that runts are not counted by MACs.
>> > > The MAC silently discards packets that are shorter than the minimum.
>> > > It has no counter for them.
>> >
>> > Pat is absolutely correct.
>> >
>> > > Unless someone is proposing creating a new runt MIB object, runts do not
>> > > apply to 10 Gig Ethernet because we do not have repeaters.
>> >
>> > I do not believe we should create such an object.
>> > Just ignore the "shortened" frame. This is not something that is expected
>> > to happen very often. And if it does, there are going to be other errors
>> > that will give you plenty of indication that something is broken.
>> >
>> > Shimon.