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

From: "Hickman, Brooks" <[email-masked]>
Date: Tue, 20 May 2003 13:40:50 -0700

>8.1. Forwarding Burdened Multicast Latency
>
>- Why 'Perform a baseline measurement of Multicast Latency'?  It is not
used
>in determining the Forwarding Burdened Multicast Latency.  You can run both
>tests for comparison.  The burdened test is a separate test.  Suggest to
>remove this.

Jerry, the FDB of the DUT/SUT is populated with the unicast addresses prior
to performing a baseline
test. The test is then performed with the DUT/SUT actually forwarding the
unicast traffic. This
also applies to section 8.2. 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Debby Stopp <[email-masked]>
Date: Tue, 20 May 2003 14:01:52 -0700

> > > 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.

The intent is *not* to reference the methodology as defined in RFC2889, but
rather to reference the existing traffic pattern terminology definition from
RFC2285 of fully meshed:

"3.3.3 Fully meshed traffic

   Definition:

      Frames offered to a designated number of interfaces of a DUT/SUT
      such that each one of the interfaces under test receives frames
      addressed to all of the other interfaces under test."

By adding Scott's suggestion of "unweighted", we make good use of the
existing definition w/out infering any additional methodological
particulars.

Debby Stopp

---

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 21 May 2003 09:00:06 -0700

Brooks,

Why perform the baseline at all?  How is the baseline metric used in
determining the burdened metric?

The point is that these are two separate tests.  They even have their own
sections.  The way it is written now, you can run test A, but you can not
run test B without first running test A.  It's the dependency that is the
issue.

If you remove the baseline measurement dependency from Forwarding Burdened
Multicast Latency, what breaks?  Are the burdened results INVALID if you
don't already have baseline results?

Jerry.

> -----Original Message-----
> From: Hickman, Brooks [mailto:[email-masked]]
> Sent: Tuesday, May 20, 2003 1:41 PM
> To: [email-masked]'
> Subject: [bmwg] Comments on draft-ietf-bmwg-mcastm-12.txt
> 
>

---

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 21 May 2003 09:12:56 -0700

Debby,

If you could rewrite the section so that it is clear what the two test
conditions are, that would be great.  I was not sure how to do that, so my
recommendation was based on section 4.4 writing style.

Can you take another look at sections 4.4.1, 4.4.2, and 4.4.3 before you
rewrite the Group Join Delay?  These three sections are different test
conditions.  Throughput is still determined using the same goalposts.
Figure 3, 4, and 5 are the same as Figure 1 with the word 'Tunnel' in
different places.

Any objection to naming the two test conditions?  A descriptive name would
be clearer that a Boolean state.  

Jerry.

> >One suggestion would be to divide this into two different 
> tests.  Put 
> >state 0 and method A under '6.1.1 Initial Group Join Delay'. 
>  Then put 
> >state 1 and method B under '6.1.2 Primed Group Join Delay'.
> 
> I don't recommend that this section be broken into two tests. 
>  Regardless of
> the two test conditions, delay is still determined using the 
> same goalposts,
> much like obtaining Latency or Throughput metrics while modifiers are
> present.  By stating the method used in the configuration 
> section of the
> report, one can easily compare if the delay metric is 
> affected under the two
> test conditions.

---

From: "Hickman, Brooks" <[email-masked]>
Date: Wed, 21 May 2003 10:57:20 -0700

Jerry,

The baseline measurement in the case of the burdened section includes
populating the FDB with unicast addresses. The test is then repeated with
the DUT/SUT actually forwarding the multicast traffic. Since the
"Join Delay' test in section 6.1 does not include this populating of the
FDB, the "baseline" would not be the same. This was why the text specifies a
baseline test first.  

> From: Perser, Jerry [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2003 9:00 AM
> To: [email-masked]'
> Subject: RE: [bmwg] Comments on draft-ietf-bmwg-mcastm-12.txt
> 
> 
> Brooks,
>

---

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 21 May 2003 15:02:09 -0700

Brooks,

I do not understand.  Where in the 'baseline measurement' (section 5.1) do
you 'populating the FDB with unicast addresses'?  I do not see any unicast
traffic in the Multicast Latency Test.  From my reading of section 5.1, it
was a pure multicast measurement.

I also do not understand how the measurement done in section 5.1 is used to
calculate the measurement in section 8.1.  From my understanding, these are
two independent tests with independent metrics.

Jerry.

> From: Hickman, Brooks 
> Sent: Wednesday, May 21, 2003 10:57 AM
> To: Perser, Jerry; [email-masked]'
> The baseline measurement in the case of the burdened section 
> includes populating the FDB with unicast addresses. The test 
> is then repeated with the DUT/SUT actually forwarding the 
> multicast traffic. Since the
> "Join Delay' test in section 6.1 does not include this 
> populating of the FDB, the "baseline" would not be the same. 
> This was why the text specifies a baseline test first.  
>

---

From: "Hickman, Brooks" <[email-masked]>
Date: Wed, 21 May 2003 16:21:56 -0700

Jerry,

That was the point I was trying to convey. You are correct that the tests
described in sections 5.1(Multicast latency) and section 6.1(Group Join
Delay) describe only multicast traffic being offered. There is no discussion
of unicast in those sections. The intent of the burdened test is to first
populate the FDB of the DUT/SUT with unicast addresses and obtain a latency
or group join delay measurement as described in the applicable sections 5.1
or 6.1, respectfully. In the baseline(Section 8.1/8.2), no unicast frames
are being offered to the DUT/SUT, only the FDB be populated with unicast
addresses.

For example;

- Group join measurement in section 6.1 is obtain with no unicast entries in
the FDB.
- Baseline measurement obtained in section 8.1 is obtained with unicast
entries in the FDB, but no
actual forwarding of unicast frames.

The test is repeated with the DUT/SUT forwarding the unicast addresses.

You will note the "difference" between using the results of the join group
delay using the procedure
in section 6.1 and the "baseline" as described in section 8.1 is the
presents of unicast addresses in the FDB of the DUT/SUT.

> Sent: Wednesday, May 21, 2003 3:02 PM
> To: [email-masked]'

---

From: "Hickman, Brooks" <[email-masked]>
Date: Wed, 21 May 2003 16:57:00 -0700

Jerry,

Correction(Pushed send button to soon). The two sections I sent specified
6.1 and 8.1 in the example. Should
have been 6.1 and 8.2.

For example;
 
- Group join measurement in section 6.1 is obtain with no 
unicast entries in the FDB.
- Baseline measurement obtained in section 8.2 is obtained with unicast
  entries in the FDB, but no actual forwarding of unicast frames.
 
 The test is repeated with the DUT/SUT forwarding the unicast 
 addresses.

 You will note the "difference" between using the results of 
 the join group delay using the procedure in section 6.1 and the
 "baseline" as described in section 8.2 is the presents of unicast
 addresses in the FDB of the DUT/SUT.

> Sent: Wednesday, May 21, 2003 4:22 PM

---

From: "Hickman, Brooks" <[email-masked]>
Date: Thu, 22 May 2003 15:27:55 -0700

Based on the comments from the last call, the following changes are being
incorporated in the -12 I-D. 

Section 4.1 Mixed Class Throughput:

FROM:

 o	The DUT/SUT MUST learn the appropriate unicast addresses; and"

TO:

 o  The DUT/SUT MUST learn the appropriate unicast and multicast
addresses; and"

FROM:

"Mixed class throughput measurement is defined in RFC2432 [Du98]. A
search algorithm MUST be utilized to determine the Mixed Class Throughput."

TO:

"Mixed class throughput measurement is defined in RFC2432 [Du98]. A
search algorithm MUST be utilized to determine the Mixed Class Throughput.  
The ratio of unicast to multicast frames MUST remain the same when
varying the intended load."

Section 5.2. Min/Max Multicast Latency: 

"The following results MUST be reflected in the test report:

   o	The Max/Min value
   o	The set of all latencies with respective time units related to the
      tested ingress and each tested egress DUT/SUT interface."

TO:

The following results MUST be reflected in the test report:
   o	The Max/Min value

The following results SHOULD be reflected in the test report:
   o	The set of all latencies with respective time units related to the
      tested ingress and each tested egress DUT/SUT interface."

Section 6.1 Group Join Delay 

Modified text for Join Delay test to include ref of state 0/1 discussed at
the start of the procedure.
While there was a suggestion to break the test out into two separate tests,
it was felt that doing so would cause more confusion. There is only one
definition for the group join delay specified in the terminology RFC2432.
The test is making the same measurement, only the context(i.e. - State of
the MFDB in the DUT/SUT) in which that measurement is made is different
between the two methods.

WAS:

Method A:

Method A assumes that the Multicast Forwarding Database <MFDB> of 
the DUT/SUT does not contain or has not learned the specified multicast
group address.  

Method A assumes that the Multicast Forwarding Database <MFDB> of the
DUT/SUT does not contain or has not learned the specified multicast group
address; specifically, the MFDB MUST be in State 0. 

WAS:

Method B:

Method B assumes that the MFDB of the DUT/SUT does contain the specified
multicast group address.

IS:

Method B assumes that the MFDB of the DUT/SUT does contain the specified
multicast group address; specifically, the MFDB MUST be in State 1.

Section 8.2 Forwarding Burdened Group Join Delay 

WAS:

"Similar to Section 6.1, the following configuration parameters MUST be
reflected in the test report:

o	Frame size(s) 
o	Number of tested egress interfaces on the DUT/SUT 
o	IGMP version
o	Offered load to ingress interface
o	Total number of multicast groups
o	Offered load to burdening ports
o	Total number of burdening ports"

IS:

"Similar to Section 6.1, the following configuration parameters MUST be
reflected in the test report:

o	Frame size(s) 
o	Number of tested egress interfaces on the DUT/SUT 
o	IGMP version
o	Offered load to ingress interface
o	Total number of multicast groups
o	Offered load to burdening ports
o	Total number of burdening ports
o	Method used to measure the join delay metric"