Subject: [bmwg] Some questions/comments on the multicast draft.

From: Kevin Dubray <[email-masked]>
Date: Thu, 11 Oct 2001 20:45:23 -0400

On <draft-ietf-bmwg-mcastm-07.txt>:

1. Section 2. You may wish to review your wording on the usage of
   RFC 2119.  Please consider adding wording like:

   "RFC 2119 defines the use of these key words to help make the 
   intent of standards track documents as clear as possible.  While
   this document uses these keywords, this document is not a 
   standards track document."

   It may help speed subsequent review.

2. Section 3, Test Setup.  RFC 2432 explicitly constrains focus to
   a "one source port to many destination profiling."  This I-D
   opens the possibility about n-to-n types tests with the statement
   "...this MAY be extended to multiple source and multiple 
   destinations."  I believe it would be beneficial to state, 
   "The set of methodologies presented in this draft are for single
   ingress, multiple egress scenarios as exemplified by Figures 1
   and 2.  Methodologies for multiple ingress, multiple egress 
   scenarios are beyond the scope of this document." 

   The I-d requires test devices to embed "recognizable" patterns 
   in the frame payload.  Shouldn't it be a requirement that 'test 
   equipment MUST validate the correct and proper forwarding actions 
   of the devices they test' - and leave the various implementation 
   details of validation mechanisms (embedded payload patterns) up 
   to the tool vendors?

3. Section 4.1, Mixed Class Throughput, presents a collection 
   heuristic that departs from RFC 2544. (I.e., decreasing 10%
   increments from the Max Offered Load, until no loss is
   encountered twice consecutively vs. 2544's binary search-like
   mechanism.) 

   Is this OK with everyone?

   If so, the last sentence in the procedure states , "The maximum 
   granularity of the trials MUST be 10% of the maximum rate, a 
   finer granularity is encouraged."  I think I know what you
   mean, but I wonder if there's a better way to say it.  In
   any event, I'd suggest employing established terminology 
   (e.g. Maximum Offered Load?)  Also, wording should be added 
   to reinforce the degree of error this approach would introduce.

   Trial duration aren't specified or suggested; recording trial
   duration is not required in reporting in this or many of 
   the forwarding tests.  Oversight?

4. Aggregated Multicast's Throughput, Section 4.3, doesn't specify 
   whether the "throughput" determination heuristic used is based on 
   RFC 2544 or the one introduced in section 4.1.  I believe this
   would be beneficial to clearly articulate which one.  

   The results paragraph talks about reporting frame loss. (
   Throughput -should be zero, right?)  The defining RFC talks to 
   recording measurment units of  (N,t) where N is the number of 
   destination ports tested and t is the associated throughput.

   In addition, the notion that "t" is expressed relative to the input
   source stream is missing in the I-D.

   It might be helpful to add wording such as "constructing a table 
   from the measurements might be useful in illustrating the effect 
   of modifying the number of active egress ports on the tested 
   system". 

5. Section 4.4, Encapsulation/Decapsulation (Tunneling) Throughput,
   doesn't provide substantial insight to the methodological approaches
   taken.  I'd recommend deleting it.  If it is thought best to
   keep the dialog, I'd consider discarding Figure 3.  It doesn't add 
   much value, and it appears to use reference labels for text that 
   no longer appears. ;-)

6. Section 4.4.1, Encapsulation Throughput. In much of this I-D,
   the RFC 2432 definition is recast as an "Objective", generally
   word for word.  Here, RFC 2432's definition is explicitly modified
   to provide for collection across a SUT.  This is not the intent
   of RFC 2432's definition for this metric.  This is a single device
   characterization only.  The wording and subsequent methodology MUST
   be changed to reflect that.

   Also, throughput is cited to be calculated a la RFC 2544! This is
   inconsistent with the throughput methodology of the I-D's other
   throughput measurements.

I think that's enough from me for now.  In it's current form, the draft 
contains enough inconsistencies with its parent document, RFC 2432, 
and itself to advance it beyond the WG, IMO. 

-Kevin

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

---

From: Kevin Dubray <[email-masked]>
Date: Fri, 12 Oct 2001 08:29:37 -0400

> and itself to advance it beyond the WG, IMO.

Ughh.  That last phrase should read "NOT to advance it beyond the
WG, IMO."

Sorry for the mixed signals,

-Kevin