Subject: Re: I-D ACTION:draft-ietf-bmwg-mswitch-01.txt

From: John Dawson <[email-masked]>
Date: Tue, 08 Jun 1999 16:12:24 -0700

My primary concern relates to the fact that manufacturers are cheating the
test process using forward pressure and back pressure and then declaring
themselves as the best products on the market.  The foot note regarding the
fact that the test was cheated is often obscured or omitted.  This in turn
causes extreme pressure for other manufacturers to cheat the test processes
also.

I do not see how we will get meaningful numbers that can be compared across
products unless offered load is measured.  At a minimum I would argue that
all tests that publish intended load numbers must disable flow control
processes on the test equipment side.  I would also argue that tests using
intended load should exclude all reporting of half duplex bi-directional
results.  Without knowing the offered load, half duplex bi-directional
results have no direct correlation between intended load and offered load.
I feel it is inappropriate for these half duplex bi-directional numbers to
be published in trade reports and/or advertised in marketing materials.

If people think these restrictions go too far then my alternative position
would be that the test process MUST flag all 100% half duplex
bi-directional results as a positive confirmation of non-standard media
access techniques.  I don't believe that a switch can claim to pass at 100%
half-bi when a cable connecting directly between test ports will fail.

John
----------------------------------
At 11:09 AM 6/8/99 +0200, Robert Mandeville wrote:
>I agree that some nitpicking is in order on the point of deciding how
>offered load is to be apprehended. Indeed offered load cannot be specified
>but only measured. Intended load is specified, as you also rightly point
>out. I don't want to cause a revolution here but let's look at what we all
>do in practise. We report intended load and then the measured forwarding
>rate. We may see that offered load is less than intended load, as for
>example when we deliberately oversubscribe a given output port, but we still
>want to characterize such a test as a congestion test, in which case we have
>to refer to intended load and not offered load. I conclude that we MUST
>report intended load and not offered load. We simply need be aware that in
>half duplex mode offered may differ significantly from intended load. I am
>aware that this does not concord with 2285. I am not sure how changes are
>made if the group agrees with what we, I think, are both saying here.
>
>
>
>----- Original Message -----
>From: Kevin Dubray <[email-masked]>
>To: <[email-masked]>
>Sent: Friday, June 04, 1999 3:08 PM
>Subject: Re: I-D ACTION:draft-ietf-bmwg-mswitch-01.txt
>
>
>> Forwarded from [email-masked]:
>>
>> I have a concern with respect to offered load.  I realize that I may be
>> nit picking, but I feel that their is a very important concept that is
>> not being properly communicated.  The concept deals with intended versus
>> offered load.
>>
>> The draft document uses some boiler plate material in a number of
>> sections.
>>
>>    Forwarding rate (FR) of the DUT/SUT ... MUST be reported as the
>> number
>>    of frames per second that the device is observed to successfully
>> transmit
>>    to the correct destination interface in response to a specified
>> offered
>>    load. The offered load MUST also be cited.
>>
>> My concern relates the usage of the phrase, specified offered load.  An
>> offered load can not be specified, it can only be measured.  An intended
>> load can be specified, but it does not guarantee a specific offered
>> load.
>>
>> So if offered load is measured, what is the measurement period and how
>> are
>> large bursts of half-duplex traffic to be considered?  This is a sticky
>> issue as bursty traffic will have very non-uniform transmission rates
>> due
>> to capture effects on the wire.  The offered load will not be a
>> constant,
>> but can be averaged over the course of the entire test.  This is further
>> complicated by the fact that even though all ports will start
>> transmitting
>> at the same time, the test will finish transmitting differently on every
>> port (i.e. ports that capture the wire early in the test process will
>> transmit a fixed number of packets before other ports that mostly defer
>> in early parts of the test process).
>>
>> Any ideas?  Is this as serious as I think, or am I nit picking
>> unnecessarily.
>> John
>>
>
>
>

---

From: "Robert Mandeville" <[email-masked]>
Date: Wed, 9 Jun 1999 07:25:32 +0200

I don't how see how the measures against cheating you offer are any more
effective than the explicit statement in RFC 2285. This is the strongest
statement contained in just about any RFC that I know of. Remember also that
the IETF is not a police force.
Bob