Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Standardization of RUNT Packet counters




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.  This may not 
be the correct reflector for these comments; but given that most, if not 
all, of the serious 802.3 developers are on this reflector; and the subject 
has come up; I will make these comments and let it rest for a while.

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?  If 802.3WG does not get involved, 
what are the chances that the accumulation of "features" would start to 
make the implementations from different "vendors" will be perceived as 
incompatible in one way or another?  Notice that I used the word 
"incompatible" instead of the word "interoperable".  This is what happened 
to SONET.  All of the SONET vendors systems are interoperable, but many of 
them are incompatible from an operations viewpoint.  The allowable 
"options" and accumulation of features has made it difficult, if not 
impossible to put one vendors system in the middle of systems from another 
vendor.  Most of this has to do with the way network element management is 
implemented and the use of the Data Communications Channel (DCC) in the 
SONET overhead.  (This is one of the primary reasons that those of us that 
have worked in this area have not wanted to have anything but the 
interoperable minimum be part of P802.3ae.)  This is already a potential 
problem with GbE and "jumbo frames".

At the next plenary, perhaps it would be good to have a discussion about 
this in the executive meeting.  The executive officers should be able to 
make a determination as to whether "incompatible" features are a risk to 
the standard and need to be brought into the standard, and if so, when.

Thank you,
Roy Bynum


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@agilent.com 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@lsil.com]
>>Sent: Thursday, November 16, 2000 2:20 PM
>>Cc: stds-802-3-hssg@ieee.org
>>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.