RE: [bmwg] Comments on draft-ietf-bmwg-mcastm-12.txt

[Scott Poretsky <[e-mail]>]

Brooks, Sounds good.  Scott

At 12:30 PM 5/19/2003 -0700, Hickman, Brooks wrote:
> > In 4.1,  change 'The DUT/SUT MUST learn the appropriate unicast
> > addresses' to 'The DUT/SUT MUST learn the appropriate unicast and
>multicast
> > addresses' as Jerry recommended.
>
> >This issue is already dealt w/nicely in global section 3.1 - why do we need
> >to repeat it again?
>
>My take on this is that the current text might make it confusing in regards
>to the authors intent
>with respect to "priming" the DUT/SUT. Section 3.1 does specify that:
>
>      "Therefore, prior to running any tests that require forwarding of
>multicast or unicast
>      packets, the test apparatus MUST generate test traffic utilizing the
>same addressing
>      characteristics to the DUT/SUT that will subsequently be used to
>measure the DUT/SUT
>      response."
>
>
>However, the mixed class specifies that:
>
>           o The DUT/SUT MUST learn the appropriate unicast addresses;
>             and
>
>Basically, prime the DUT/SUT with unicast only. Does this override the
>global requirement in section
>3.1 not? I think that it should include multicast so there is consistency
>between the two sections(Global section and mixed class section).
>
>
>
> > In 4.1, state it is "unweighted" round-robin.
>
>I would suggest changing to:
>
>"The unicast class frames MUST be configured to transmit in a round-robin
>fashion to all of the destination port as specified in RFC2889."
>
>The traffic pattern is clearly specified in RFC2889, which is an
>"unweighted" round-robin traffic pattern.
>
>
> > In 5.2, report min, max, and average latency for each multicast group.
>Eliminate "set of all latencies".
>
>Note that the procedure for the latency test is a "blip" test as described
>in RFC2544(One tagged frames in the middle of the burst). There is only one
>latency value for each port which is why the wording is a "set of latency
>measurements". In regards to the MUST versus a SHOULD. I would not have an
>issue with it being a SHOULD for consistency, since the metric for the
>Min/Max Latency test is the difference between the minimum and maximum
>latencies and not the latencies themselves. However, as an implementer, I
>would always want to present the set of latencies along with the Min/Max
>value.
>
>
> >- The search algorithm use to determine the Mixed Class Throughput.  Does
>it
> >maintain the multicast to unicast ratio, or can you change the load on one
> >class only?  My opinion is that you MUST change both classes.  Please
> >clarity in the I-D.
>
>
>Since we are dealing with two traffic classes(Multicast AND unicast) versus
>only one(Multicast) with the other throughput tests, it might be good to add
>the following to the last paragraph in the mixed class throughput procedure:
>
>"The ratio of unicast to multicast frames MUST remain the same when varying
>the intended load."
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg