Subject: RE: Comments on draft-ietf-bmwg-mswitch-02

From: "Perser, Jerry" <[email-masked]>
Date: Tue, 29 Feb 2000 15:13:18 -0800

This is the first comments I have gotten on version 2.  I will incorporate
them along with some grammar errors that I have found.  I will have version
3 ready to post within a week.  I am assuming no one else has any comments
and I will be ready for last call.

> In general I approve of the progress made in draft 02. A few specific
> comments:
> 
> 5.5  Congestion Control
> 
> As noted in RFC 2285 section 3.7, backpressure is not the 
> only means of
> congestion control mechanism. Some switches implement forward 
> pressure, and
> some use a too-short IFG. This is a terminology nit, but for 
> the purposes of
> completeness it may be more accurate to refer throughout this 
> document to
> "congestion control," of which backpressure is one example.

I realized that in version 2 and renamed the test to congestion control.
I'll review the document to find any other instances.
 
> Appendix B: Generating Offered Load
> B.1 Frame Based Load
> 
> The third paragraph states that "All ports MAY NOT transmit 
> the same number
> of frames if their Iload is not the same.  An example would 
> be the Partially
> meshed overloading test." Not sure I follow here -- I don't 
> see anything in
> the partially meshed traffic test descriptions suggesting 
> procedures where
> different ports will have different Iloads. Have I missed something?

The idea here is a bi-directional partial meshed many-to-one with all ports
the same MOL.  With many ports going into one, the Iload must be reduced so
the single port is not over-subscribed.  This prevents the test from turning
into a QOS test.  Maybe the words "Partially meshed overloading" was
misleading.  I'll change it to "Partially meshed many-to-one."

> The final paragraph states that "Oload per port MAY be reported for
> diagnostic purposes." Per-port Oload may be intrinsically 
> interesting, for
> example in determining whether Oload variation exists 
> across multiple
> ports. I would delete the words "for diagnostic purposes" 
> since per-port
> Oload itself may be a useful measurement.

I agree with you technically and will change the document.  I put that
statement as a justification why one would report those numbers.  Per port
(or even per flow) statistics is available in our products.  People only
care about the aggregate, unless it is lower than they expected.  Only then
do we look at the per port statistics.

> B.2 Time Based Load
> 
> The fourth paragraph states that "all ports SHOULD stop 
> transmitting frames
> after the specified trial duration, within 100 PPM." This is the first
> reference to a PPM metric. What is the unit of measurement here?

PPM stands for "Parts Per Million".  It is a unit-less measurement same as
percentage.  100 PPM is the same at 0.01%.  It is used in Electrical
Engineering on crystals and other tight tolerance devices.

Is PPM appropriate here?  Should I keep all the tolerances in percentage?  I
don't know if IETF uses EE terms or if I have to define them.

---

From: "David Newman" <[email-masked]>
Date: Tue, 29 Feb 2000 22:15:16 -0500

((dn: All ports with the same MOL makes sense, but the draft now states that
"All ports MAY NOT transmit the same number of frames if their Iload is not
the same." Thus, it's not clear from the language in the draft whether all
ports do or do not have the same Iload. The context suggests Iload is equal,
but the language states otherwise.))

((dn: Certainly any acronym should be spelled out on first usage. But I
agree that expressing this as percentage would be easier to understand.))

dn