Subject: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

From: "Hickman, Brooks" <[email-masked]>
Date: Mon, 21 Apr 2003 12:10:35 -0700

The current procedure for the join test in section 6.1 requires that that
the multicast traffic be offered to the DUT. Then, the destination port(s)
issue a group membership report to join the offered multicast group(s).

There has been a suggestion that the test should include a port that joins
all of the multicast groups at the start of the test. This additional port
would not be used to make any join delay measurements, but would be used to
"prime"(Section 3.1) the DUT, so that it is actually forwarding the
multicast groups before receiving the IGMP group membership report(s). It
has been augured that if no such priming of the DUT is performed, then there
may be a CPU resource contention problem between the multicast frames and
the IGMP message processing and therefore would not measure the actual
"processing time" of an IGMP group.

Again, any input from the reflector would be appreciated and welcome.

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

---

From: Tony DeLaRosa <[email-masked]>
Date: Tue, 22 Apr 2003 16:39:43 -0700

Brooks,

Your proposed procedure actually requires more DUT processing than the
current one.  

The current procedure does not forward the multicast traffic since the
Multicast Forwarding Information Base (MFIB) does not have the group
address.  Hence the multicast packets received will be inspected and
dropped. 

Your proposed procedure dictates forwarding multicast packets to an
uninstrumented port to reduce CPU cycles.  However, the DUT must rewrite the
Layer 2 information for all the forwarded packets.  In addition, since the
uninstrumented port is receiving multicast packets, the DUT must also
replicate the packet for any subsequent ports that join that multicast group
address.  This may affect the test results.

To summarize:

DUT Resources required on current procedure
	- Analyzing the packet

DUT Resources required on proposed procedure
	- Analyzing the packet + rewriting the layer 2 header + replicating
the packet for subsequent group joins

I would recommend that the current procedure be used and be limited to one
port in order to avoid using CPU resources to replicate multicast packets.

---

From: Tony DeLaRosa <[email-masked]>
Date: Tue, 22 Apr 2003 16:39:43 -0700

Brooks,

To summarize:

---

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 23 Apr 2003 10:41:37 -0700

Tony,

I am not sure L2/L3 switches work the way you describe them.  Analyzing the
packet is simply if it is not in the FDB, then send it to the CPU. The
"writing the layer 2 header + replicating the packet for subsequent group
joins" are handled by hardware ASICs.

The problem is that frames not in the FDB go to the CPU for processing.
This includes the first unicast/multicast frames to a flow,
unicast/multicast with no route, and control plane frames (ARP, IGMP, OSPF,
BGP4, etc.).

Brooks was trying to prevent a DOS type attack on the CPU so that it can
handle the IGMP frame quickly and give an accurate Group Join Delay
measurement.

I would like to hear from any of the switch vendors on the reflector.  Does
your box handle multicast frame replicating in hardware or by the CPU?  Is
IGMP membership reports hardware or CPU?

Jerry.

> From: Tony DeLaRosa [mailto:[email-masked]]
> Sent: Tuesday, April 22, 2003 4:40 PM
> To: [email-masked]'
> Subject: FW: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)
> 
> 
> Brooks,
>

---

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 23 Apr 2003 10:41:37 -0700

Tony,

Jerry.

---

From: "John Dawson" <[email-masked]>
Date: Wed, 23 Apr 2003 10:54:37 -0700

Does your box handle multicast frame replicating in hardware or by the CPU? 
>> Hardware

Is IGMP membership reports hardware or CPU?
>> CPU

I believe that is typical for many switches.

John

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2003 10:42 AM
To: BMWG (E-mail)
Subject: RE: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

Tony,

Jerry.

---

From: "John Dawson" <[email-masked]>
Date: Wed, 23 Apr 2003 10:54:37 -0700

John

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2003 10:42 AM
To: BMWG (E-mail)
Subject: RE: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

Tony,

Jerry.

---

From: Debby Stopp <[email-masked]>
Date: Wed, 23 Apr 2003 15:07:49 -0700

All -

Although the discussion of the inner workings of a router or a switch may be
interesting to some, it falls outside the scope of the BMWG.  

From a black box testing perspective, there are two test metrics where 'join
delay' would be interesting:

 1) Starting from a clean slate, state 0, address not present in the MFDB.
   In this scenario, the metric represents the time the DUT takes to add the
address to the MFDB and begin forwarding the multicast packet.

 2) The address is already present in the MFDB, as there is one or more
egress ports that have previously joined and are currently receiving
multicast packets.
    In this scenario, the metric represents the time the DUT takes to update
the MFDB and begin forwarding the multicast packet to the newly joined
egress port<s>.

The current methodology only addresses the first metric, however I believe
both metrics have merit.  With very little modification to the existing
text, the join delay methodology can be modified to allow the user community
the flexibility to select the type of metric they prefer to collect.

Debby