Test Cases for Evaluating Congestion Control for Interactive Real-Time Media
draft-ietf-rmcat-eval-test-10

Thanks for the work on this document. I have only one minor nit to call out.

ID Nits reports:

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords.

     RFC 2119 keyword, line 458: '...didate proposals MAY show the effectiv...'

Section 1: s/controlled environment/controlled environments/

With the above change, I think the document is clear enough about where these tests should be run.

I share the Gen-ART reviewer's discomfort about the weak language in the security considerations section, but will leave it to the responsible AD to do the right thing.

We don't really explain the usage of the "variation pattern index" that
I can see.

Section 3

         +  Bottleneck-link capacity: defines minimum capacity of the
            end-to-end path

I'm not sure I'd describe this as the "minimum capacity of the
end-to-end path", since attempts to use anything larger than this value
will pile up at the bottleneck.

Section 5.6, 5.7

Do we want anyone to consider testing with alternative TCP congestion
control algorithms?

Section 6.1

If you're not going to reference what scheme is used for implementing
priority, say how these priority values are interpreted.

Section 6.2

nit: "delay-based" (hyphenated)

Section 6.3

   Expected behavior: The candidate algorithm is expected to achieve
   full utilization at both bottleneck links without starving any of the

I'm not sure how we can get "full utilization" at both bottlenecks, when
the links in question have different capacity ratios.

Section 11.2

Some of these may need to be normative references; e.g., if we require
default TCP congestion control (RFC5681) for the competing TCP flows,
then it's mandatory.