Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Mar 21, 2019 at 01:41:28PM +0000, Zaheduzzaman Sarker wrote:
> Hi Benjamin,
> 
> Thanks for the comments. Please see inline below with [ZS] prefix.
> 
> BR
> Zahed
> 
> On 2019-03-07, 15:52, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:
> 
> 
> 
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     We don't really explain the usage of the "variation pattern index" that
>     I can see.
> 
> [ZS] right, that column could be removed. I think it is still there for potential reference in the discussion.
>     
>     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.
> 
> [ZS] hmm, I guess that is why that link will act as bottleneck link for a respective testcase. If the flows remain below that capacity it should not experience queuing and as you said anything above that capacity will observe queuing. The job of the congestion control algorithm will be to avoid queuing.

I think I was expecting "maximum capacity" to be more appropriate than
"minimum capacity".  Perhaps I'm confused about what is intended here.

>     Section 5.6, 5.7
>     
>     Do we want anyone to consider testing with alternative TCP congestion
>     control algorithms?
> 
> [ZS]The text should be read as the minimum one need to do and should encourage other to try with more alternatives. Will add the encouragement text (there is already one for multiple media sources).
>     
>     Section 6.1
>     
>     If you're not going to reference what scheme is used for implementing
>     priority, say how these priority values are interpreted.
> 
> [ZS] not sure I understood the comments here. I don’t think we have any recommendation of which priority schemes one need to use. The testers are free to use any priority scheme and the share of the available bandwidth must reflect the priority imposed on flows. What we can ask is to describe the scheme used in the test so that results can be interpreted clearly. Like a particular SCREAM (https://tools.ietf.org/html/rfc8298#section-4.1.2.8) implementation uses a credit based scheme, then presenting results that scheme needs to be described by the proponents. Will this work?

The example has priority values of 1 and 2 -- are higher numbers more
preferred or lower numbers more preferred?

>     Section 6.2
>     
>     nit: "delay-based" (hyphenated)
> [ZS] OK
>     
>     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.
> [ZS] there are two criteria here, 1) avoid starvation, 2) full utilization with fair share. In this particular test case the bottlenecks are not common for all the flows. The the S1-R1 flow will traverse both of the bottleneck. At time, it will share the bottleneck link with S2-R2 and further down the path it will share the bottleneck link with S3-R3. S1-R1 then obviously it will observe the minimum of the available bandwidth from all the bottlenecks present in the path (in this case C-D). As different flows are on the bottleneck the expectation is S2-R2 will fill the rest of the available bandwidth and none of them should starve. So, to me the text seems OK.

Thanks for the explanation.

-Benjamin

>     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.
> [ZS] OK
>     
>     
>     
>