RE: RUNT Packets
So while messages pass on the net, Howard goes and puts the lie to may claim
that no one in the thread has proposed any MAC or MIB changes. [sigh]
--Bob
-----Original Message-----
From: Howard Frazier [mailto:millardo@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, November 16, 2000 4:28 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: Re: RUNT Packets
There is something to be said for making the RMON and 802.3 MAC sublayer
counters match up, once and for all.
I have spent more time explaining the differences than I would have spent
on simply making them the same. We are kidding ourselves if we think
that the RMON statistics aren't important. We are also perpetuating an
inefficient process if we continue to crank up the speed in 802.3 while
leaving it up to another group to finish the management work. The community
of implementers and users that we serve needs to have all of the MAC
sublayer
statistics defined for each operating speed.
With the scope of the "service to humanity" work that is already being
done on clause 4, adding in counters for undersized receive events
(whether they be RUNTS, UndersizePkts, or the ever-popular "flying
pygmies") should be no big deal. It would save a lot of people a lot
of head scratching if we did it.
Howard Frazier
DomiNet Systems
pat_thaler@xxxxxxxxxxx wrote:
>
> Bob,
>
> Undersized packets is something that RMON may have on object for without
> 802.3 having a corresponding object. If so, either we can't say anything
> about how it is counted because we don't define the object or we can add
the
> object. To add it in the same way that other MAC frame counters are
handled,
> we will have to put it into the Pascal of 5.2.4 and probably 4.2.9. The
> status quo is that its definition is up to RMON.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Grow, Bob [mailto:bob.grow@xxxxxxxxx]
> Sent: Thursday, November 16, 2000 10:45 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RE: RUNT Packets
>
> As Louis said, we we are really focused on undersized frames. For example
> in RMON, undersized frames are either directly counted (e.g.,
> etherStatsUndersizePkts) or included in the filter for a counter (e.g.,
> etherStatsFragments)
>
> --Bob
>
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Thursday, November 16, 2000 9:12 AM
> To: bob.grow@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Subject: RE: RUNT Packets
>
> Bob,
>
> The important point is that runts are not counted by MACs. The MIB
> definition that Geoff provided is for aRunts which is a _repeater_ MIB
> object. The MAC silently discards packets that are shorter than the
minimum.
> It has no counter for them. The counter update process,
> LayerMgmtReceiveCounters, only runs when a packet that meets minimum
packet
> size is received. (See 4.2.9 for the MAC receiver and Table 30-1 for a
> listing of MIB objects.)
>
> Unless someone is proposing creating a new runt MIB object, runts do not
> apply to 10 Gig Ethernet because we do not have repeaters.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Grow, Bob [mailto:bob.grow@xxxxxxxxx]
> Sent: Wednesday, November 15, 2000 3:22 PM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RE: RUNT Packets
>
> Pat:
>
> I probably over simplified the 10 Gb/s explanation of runts, my appologies
> to those confused by it. Those that want the precise answer can read the
> MIB definition that Geoff Thompson posted from the standard.
>
> I was only addressing the noise hit causing detection of an end delimiter,
> and transmitting a smaller than minimum frame (a protocol error). Many
see
> a high runt count as reason to suspect a device is transgressing protocol
by
> transmitting the runts.
>
> In my haste to get the first draft of clause 46 out, any noise hit
yielding
> one (or more) control characters at the RS would terminate the frame,
> including those noise hits converted to Error by the PCS. The change
agreed
> to in Tampa was to exclude Error control characters from terminating the
> frame, thus significantly reducing the number of noise hits that will
result
> in counting a runt packet. This basically places the burden of
deliminating
> the frame on the PCS without the RS changing that determination.
>
> --Bob Grow
>
> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Wednesday, November 15, 2000 1:52 PM
> To: Grow, Bob; 'James Colin'; stds-802-3-hssg@xxxxxxxx
> Subject: RE: RUNT Packets
>
> Bob,
>
> I do not understand your point. At lower speeds, there are four possible
> causes of a runt -
>
> A noise hit causes a short event on a segment which arrives at a repeater,
> since ther repeater never transmits less than a minimum size fragment it
> sends a runt.
>
> A collision fragment
>
> A noise hit that causes an end delimiter to be detected in error.
>
> Someone transmitted a frame smaller than the minimum frame size. (Is this
> the protocol error you referred to?)
>
> Therefore, at the lower speeds, runts can be caused by noise, the normal
> operation of CSMA/CD or transmission shorter than the minimum. For full
> duplex they are only caused by noise or transmission shorter than minimum.
>
> Pat
>
> -----Original Message-----
> From: Grow, Bob [mailto:bob.grow@xxxxxxxxx]
> Sent: Tuesday, November 14, 2000 10:52 AM
> To: 'James Colin'; stds-802-3-hssg@xxxxxxxx
> Subject: RE: RUNT Packets
>
> A minimum frame size was established at 10 Mb/s to assure that collisions
> were detected. Shorter "runt" frames are an error and are commonly
counted
> and monitored in management databases. In the desire to maintain
> consistency over all speeds of ethernet, we should attempt to preserve
> similar error properties. If the RS turns an error created by
transmission
> noise into a protocol error (e.g., runt frame) we are violating the
> objective to make things look the same.
>
> --Bob Grow
>
> -----Original Message-----
> From: James Colin [mailto:james_colin_j@xxxxxxxxx]
> Sent: Tuesday, November 14, 2000 2:50 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RUNT Packets
>
> Louis, Bob
> Can you explain the term "runt packets"?
> Thank you,
> James
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.yahoo.com/