RE: RUNT Packets
Roy,
Without any intention to continue this thread, I would like to repeat what
was mentioned earlier that most MACs (at least I know
four of them) implement RUNT counter. So it is not an issue of logic but
standardization only. I am sure people will
implement it in 10G MAC too irrespective of whether 802.3ae defines it or not.
Regards,
Tripathi.
At 09:53 AM 11/18/00 -0600, Roy Bynum wrote:
>Pat,
>
>As an individual that has had to trouble shoot data networks, I wonder if
>there may not be an advantage to adding a "RUNT" object to the MIB. This
>will add one tool to reduce the need for external trouble shooting
>equipment and/or RMON processing in order to determine problems with a
>link or upstream switch. The downside to this is the additional gates
>required to add the counters and other logic that would go with this. Can
>you give some guidance on what that "cost" will be?
>
>Thank you,
>Roy Bynum
>
>At 04:08 PM 11/16/00 -0700, 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/
Best Regards,
Devendra Tripathi
Vitesse Semiconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050