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

["Conrad C. Nobili" <[e-mail]>]

A binary search for a zero loss rate with our old throughput tests
found a single value, to 1 PPS granularity.  It did this relatively
quickly for the slower link technologies that were the order of the
day.  As the link speeds went up by factors of ten and a hundred,
maintaining the 1 PPS granularity meant that binary searches for
a ZLR took log2(10) or log2(100) more trials.  However there are
other tricks available if you want to reduce the number of trials.
In the old Harvard NDTL we had tweaked our software to "cheat" a
bit on the binary search.  We had our binary search go 80% of the
way toward its next goal instead of half way.  That way we found
the common media rate devices and bricks a bit more quickly than
we would have with a POBS.  So, there may be some technique like
that which can help some.

But these tests aren't really interesting in the cases of media
rate devices and bricks.  In those cases, neither a PLR nor a THRU
test gives you much more information than the other.  In the more
interesting cases, you really do get more information by having
both of the tests.  The PLR test, with its (10% traditionally)
slices through the performance space, gives you a general outline
of the performance curve.  The THRU test gives you a single more
accurate (1 PPS granularity traditionally) ZLR number.  Remember,
we used to see all sorts of perverse performance behavior, and I
presume we still want these tests to find and show such behaviors
where they still exist.  So, if a device is a "dribbler" I want to
be able to find that and see that the PLR tests show near perfect
performance at all rates, but that the THRU test gives a very low
number.  If a device has a periodic or other non-load-related issue
I also want to be able to see that somewhere (in which case we need
long trials and/or many of them).

I'm not really proposing any specific changes or wording.  I just
thought these perspectives might help somehow.  (And a gentle prod
from Kevin helped to stir me I confess.)

--cn, ex-NDTL, hoping this is somehow helpful ...

Conrad C. Nobili  [e-mail]  Harvard University UIS/NOC

On Thu, 18 Oct 2001, Debby Stopp wrote:

> kevin wrote:
> > I have no problem modifying the collection algorithm to reduce
> > collection
> > time; the issue that I have is that RFC 1242 defines throughput as the
> > _maximum_ lossless forwarding rate.  Your proposed algorithm won't 
> > necessarily preserve this.  
> > 
> > A hybrid approach might work here:  use your 10% (or smaller ;-)
> > decrements
> > to narrow the binary search area.  Then apply the binary-search like
> > technique
> > to find the maximum, lossless forwarding rate.
> > 
> > Then we don't recast RFC 1242's meaning of throughput via a 
> > methodology 
> > statement.  
> 
> 
> Hmm.  I don't believe I've actually stepped on RFC 1242's def of throughput
> by suggesting a different methodology, from 1242:
> 
> "Definition:
>                 The maximum rate at which none of the offered frames
>                 are dropped by the device.
>  
>         Discussion:
>                 The throughput figure allows vendors to report a
>                 single value which has proven to have use in the
>                 marketplace.  Since even the loss of one frame in a
>                 data stream can cause significant delays while
>                 waiting for the higher level protocols to time out,
>                 it is useful to know the actual maximum data
>                 rate that the device can support.  Measurements should
>                 be taken over a assortment of frame sizes.  Separate
>                 measurements for routed and bridged data in those
>                 devices that can support both.  If there is a checksum
>                 in the received frame, full checksum processing must
>                 be done."
> 
> There's no mention in there re: binary search or any other specific
> algorithm to find the "maximum rate at which none of the offered frames are
> dropped".
> 
> However, I have no problem compromising, how about this:
> 
> "Similar to the Frame loss rate test in RFC 2544, the first trial SHOULD be
> run for the frame rate that corresponds to 100% of the maximum offered load
> for the frame size on the input media. Repeat the procedure for the rate
> that corresponds to 90% of the maximum offered load, then again for 80% of
> this load and so on. This sequence SHOULD be continued (at reducing 10%
> intervals) until there are two successive trials in which no frames are
> lost. The maximum granularity of the trials MUST be 10% of the maximum
> offered load; a finer granularity is encouraged.
> 
> Alternately, the first trial MAY be run for a frame rate that is well known
> to correspond to 0% frame loss; consecutive trials MUST be run at regular
> increasing intervals of 10% of the maximum offered load.  When loss is
> encountered, perform a binary search between the loss point and the last
> zero-loss point to determine the throughput metric. "
> 
> Debby
> 
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/bmwg



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