Subject: Please Review mcast-02

From: [email-masked] (Kevin Dubray)
Date: Mon, 2 Mar 1998 10:34:10 -0500

Fellow BMWG'ers:

I'm trying to update the lastest Multicast benchmarking terminology
draft.  Would you please review and comment on the following 
sections:

    3.5 - Overhead (Group join/leave delay)
    3.6 - Capacity

While you ponder these metrics, consider if there are additional
overhead or capacity metrics that should be offered. 

A pointer to <draft-ietf-bmwg-mcast-02.txt> is:

     ftp://ftp.ietf.org/internet-drafts/draft-ietf-bmwg-mcast-02.txt 

Thanks,
Kevin

---

From: [email-masked]
Date: Wed, 11 Mar 98 09:56:36 -0500

Kevin, 

A couple of comments.

On group join delay: Given that you're working in microseconds, it might help to
use somewhat more granular terminology than "the time duration." For example, 
the definition might specify the interval between receipt of the last bit of a 
group membership report and transmission of the first bit of an mcast packet. 
(Of course, I'm assuming here that this is a LIFO measurement.)

BTW, I disagree with the suggestion that because this is a protocol measurement,
all implementations will return essentially the same result. Tests of other 
protocols (I'm thinking of LANE here) have demonstrated dramatically different 
results from different implementations.

On group capacity: It may be worth reinforcing the notion that capacity and 
forwarding rate are orthogonal. A device supporting a large number of mcast 
groups might not be able to forward traffic at wire rate, and conversely a 
device at wire rate might not be able to learn about many mcast groups. 

Bob Mandeville went around and around on this while devising MAC address 
learning tests. He ultimately settled on two tests--one that measured maximum 
*number* of addresses learned and one that measured maximum learning *rate*. The
former involves a relatively low learning rate, and the latter involves a 
relatively small number of addresses. Of course, it's desirable that a device be
able to put up big numbers on both counts--but they're different measurments.

Dunno if mcast involves a similar (non-)relationship between rate and number. If
so, it may be worth noting.

dn

______________________________ Reply Separator _________________________________
Subject: Please Review mcast-02 
Author:  <[email-masked] (Kevin Dubray) > at dcm_smtp
Date:    3/2/98 10:34 AM

Fellow BMWG'ers:

Thanks,
Kevin