Subject: A few more comments on the mswitch document

From: "Gene" <[email-masked]>
Date: Fri, 28 Jul 2000 21:48:53 -0700

General comments:
Trial Duration definition: Why is the test duration supposed to be max 300
seconds? It is probably sufficient to say
      "Trial Duration - The recommended Trial Duration is 30 seconds."
without further comment.

Sprinkled throughout the document, there is text of the form:
   "All ports SHOULD start transmitting their frames within 1%
   of the trial duration.  For a trial duration of 30 seconds,
   all ports SHOULD have started transmitting frames within
   300 milliseconds of each other."

Based on this assumption, as the trial duration grows (ie., 300+ seconds),
the relative start of transmission of each test port can be within 3 seconds
of each other - I'm not sure that's what we actually want to say.  The
relative start of transmission would be better off specified relative to
each port, rather than the overall duration, ie., all ports must start
within 'X' milliseconds of each other (regardless of test duration).

************************************************************
In section 5.1.4 Measurements:
   "Frame loss rate of the DUT/SUT SHOULD be reported as defined in
   section 26.3 [3] with the following notes: Frame loss rate SHOULD be
   measured at the end of the trail duration.  The term "rate", for this
   measurement only, does not imply the units in the fashion of "per
   second."

If this statement does not imply the units in the fashion of "per second",
what exactly does it specify?

************************************************************
In section 5.3.2 Setup Parameters
      "Local Traffic - A Boolean value of ON or OFF.  The frame sequence
      algorithm MAY be altered to remove local traffic.  With local
      traffic ON, the algorithm is exactly the same as a fully meshed
      throughput.  With local traffic OFF, the port sends frames to all
      other ports on the other side of the backbone uplink in a round
      robin type fashion."

If the algorithm is exactly the same as a fully meshed throughput test, then
why even define an entirely new test. Is there anything different?  I did a
diff on the two sections & I didn't come up with any significant
differences.  What is the difference between an SUT & a DUT in this case -
can't they both be treated as a system, much like the other RFC/drafts treat
the term "DUT/SUT"?

************************************************************
The two sections:
   5.2  Partially meshed one-to-many/many-to-one
   5.4  Partially meshed unidirectional traffic

are very similar. The major difference is that 5.2 defines both
unidirectional & bidirectional partially meshed traffic, while 5.4 is a
subset of 5.2 by defining only metrics for unidirectional traffic.

They would be better defined either as one test w/optionallly unidirectional
vs. bidirectional traffic flow OR as multiple tests:

It seems to me that there are 3 variations:
 1 - bidirectional partially meshed traffic
 2 - unidirectional, in a many to one type configuration   AND
 3 - unidirectional, in a one to many type configuration

These configurations are not specific to the interface type/speed.

************************************************************
In section 5.6.1 Objective:
   "The Forward Pressure test overloads a DUT/SUT port and measures the
   output for forward pressure [2].  If the DUT/SUT transmits frames
   with an interframe gap less than 96 bits (section 4.2.3.2.2 [4]),
   then forward pressure is detected."

The definition, from RFC 2285, reads:
      "Methods which depart from or otherwise violate a defined
      standardized protocol in an attempt to increase the forwarding
      performance of a DUT/SUT."

If we are to apply this methodology to a media other than ethernet, than to
specify the gap in terms of 802.3 is too specific.

In addition, this section includes the following section, under section
5.6.3 Procedure:
5.6.3.2 Minimum Interframe Gap

If this is the "Forward Pressure" test/methodology described in the
objective, it would be appropriate to label the section as "Forward
Pressure".

& more from the same section:

   "Test frames SHOULD be transmitted to the first port (port 1) of the
   DUT/SUT with an interframe gap of 88 bits.  This will apply forward
   pressure to the DUT/SUT and overload it at a rate of one byte per
   frame.  The test frames MUST be constructed with a source address of
   port 1 and a destination address of port 2.

It should be sufficient to state that the interframe gap is "less than the
defined standardized protocol.", rather than hard-coding a specific gap
value/type.

************************************************************
In section 5.7.3 Procedure:

   "This test MUST at a minimum be performed in a three-port
   configuration described below.  The test MAY be expanded to fully
   utilized the DUT/SUT in increments of two or three ports.  An
   increment of two would include an additional Learning port and Test
   port.  An increment of three would include an additional Learning
   port, Test port, and Monitoring port."

Why must the test be expanded in increments of two or three ports?  As each
additional receive port is added, it is, essentially, listening or
monitoring for flooded frames at the same time as it receives valid frames.
The requirement for a monitoring port per learning port is superfluous.

************************************************************
In section 5.7.5 Reporting format:

      "The flood count on Tport during the test portion of each test.
      If the number is non-zero, this is an indication of the DUT/SUT
      flooding a frame in which the destination address is not in the
      address table."
<snip>
      "The flood count on Lport during the test portion of each test.
      If the number is non-zero, this is an indication of the DUT/SUT
      flooding a frame in which the destination address is not in the
      address table.

      The flood count on Mport.  If the value is not zero, then this
      indicates that for that test iteration, the DUT/SUT could not
      determine the proper destination port for that many frames.  In
      other words, the DUT/SUT flooded the frame to all ports since its
      address table was full."

If you are going to use the Tport & the Lport as monitoring devices (ie.,
devices listening for flooded frames), then why do you need a dedicated
monitoring port?

************************************************************
In section 5.9.1 Objective:
   "The objective of the Errored frames filtering test is to determine
   the behavior of the DUT under error or abnormal frame conditions.
   The results of the test indicate if the DUT/SUT filters the errors,
   or simply propagates the errored frames along to the destination."

All that is very generic; however, the procedure is very specific to a
10/100 interface; is this test only applicable on a 10/100 interface?
Should it be extended to include other media, such as gigabit and PoS?...

************************************************************
The following paragraphs use an inappropriate reference to capitialized
"MAY" & "MUST". This methodology is measuring the behaviour of the DUT/SUT,
not specifying it.

In section 5.9.3 Procedure:
   "Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes
   from being propagated through the DUT/SUT section 4.2.4.2.1 [4].
   Oversized frames transmitted to the DUT/SUT should not be forwarded.
   DUT/SUT supporting tagged Frames MAY forward frames up to and
   including 1522 bytes long (section 4.2.4.2.1 [5])."

   "Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes
   from being propagated through the DUT/SUT section 4.2.4.2.1 [4].
   Oversized frames transmitted to the DUT/SUT should not be forwarded.
   DUT/SUT supporting tagged Frames MAY forward frames up to and
   including 1522 bytes long (section 4.2.4.2.1 [5]).

   Undersize - The DUT/SUT MUST filter frames less than 64 bytes from
   being propagated through the DUT/SUT (section 4.2.4.2.2 [4]).
   Undersized frames (or collision fragments) received by the DUT/SUT
   must not be forwarded.

   CRC Errors - The DUT/SUT MUST filter frames that fail the Frame Check
   Sequence Validation (section 4.2.4.1.2 [4]) from being propagated
   through the DUT/SUT.  Frames with an invalid CRC transmitted to the
   DUT/SUT should not be forwarded.

   Dribble Bit Errors - The DUT/SUT MUST correct and forward frames
   containing dribbling bits.  Frames transmitted to the DUT/SUT that do
   not end in an octet boundary but contain a valid frame check sequence
   MUST be accepted by the DUT/SUT (section 4.2.4.2.1 [4]) and forwarded
   to the correct receive port with the frame ending in an octet
   boundary (section 3.4 [4]).

   Alignment Errors - The DUT/SUT MUST filter frames that fail the Frame
   Check Sequence Validation AND do not end in an octet boundary.  This
   is a combination of a CRC error and a Dribble Bit error.  When both
   errors are occurring in the same frame, the DUT/SUT MUST determine
   the CRC error takes precedence and filters the frame (section
   4.2.4.1.2 [4]) from being propagated."

************************************************************
In section 5.9.5 Reporting format
   "For each of the error conditions in section 5.6.3, a "pass" or "fail"
   MUST be reported.  Actual frame counts MAY be reported for diagnostic
   purposes."

If this methodology reports, as a metric, a "pass" or "fail" status, then
the tester is making a judgement on the abilities of the DUT/SUT, which has
not been the intent of the BMWG documents in the past.

A better reporting mechanism would be to report the transmitted frames,
received frames & frame loss, as defined in RFC 1242, & allow each tester to
make the judgement w.r.t pass/fail.