RE: RUNT Packets
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.