Subject: RE: [bmwg] draft-ietf-bmwg-mcastm-11.txt

From: Debby Stopp <[email-masked]>
Date: Thu, 17 Apr 2003 12:21:24 -0700

brooks wrote:
> The sentence:
>
> "Therefore, before an initial, measured forwarding test
> trial, the test
> apparatus MUST
>  generate test traffic utilizing the same addressing
> characteristics to the
> DUT/SUT
>  that will subsequently be used to measure the DUT/SUT response."
>
> implies priming is only needed when performing forwarding
> rate tests. This
> would also apply for latency or throughput testing as well.

I believe this text has been taken out of context; however, in all fairness,
it could certainly be clarified.  I suggest the following replacement text:

"Therefore, prior to running any tests that require forwarding of multicast
or unicast packets, the test apparatus MUST generate test traffic utilizing
the same addressing characteristics to the DUT/SUT that will subsequently be
used to measure the DUT/SUT response."

> Second Item
>
> Section 5.1 Multicast Latency
>
> Seventh Paragraph States:
>
>      "The test apparatus MUST record the time of the
> successful detection
>      of a tagged frame from a tested egress interface with a
> timestamp,
>      Timestamp B.  A set of Timestamp B values MUST be
> collected for all
>      tested egress interfaces of the DUT/SUT.  See RFC 1242
> [Br91] for
>      additional discussion regarding store and forward
> devices and bit
>      forwarding devices."
>
>
> The goalposts which are being referenced will be dependent
> upon what type of
> measurement(Store and Forward or bit forwarding) is being
> made. I think that
> it would provide clarity by replacing the last sentence with
> the following:
>
> "Note that the nature of the latency measurement(i.e., "store
> and forward"
> or "bit forwarding"),
>  defined in section 26.1 of RFC1242 impacts the bit that
> Timestamp A and
> Timestamp B references."

Hmm.  There is no section 26.1 in RFC 1242.  Section 3.8 in 1242 has a very
nice description of store & forward vs. bit forwarding, however.

In RFC 2544, section 26.2,
   The latency is timestamp B minus timestamp A as per the relevant
   definition frm RFC 1242, namely latency as defined for store and
   forward devices or latency as defined for bit forwarding devices.

Note that this section just ref's back to the definition in 1242.

Debby Stopp