Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness

[[e-mail]]

Hi Christoph,

Replies marked [RG]...

You wrote:

----- -----

Hello Ruediger,

thanks for your feedback! Please see inline:

> On Dec 22, 2021, at 11:16 PM, [e-mail] wrote:
> 
> Hi Marcus,
> 
> Noting that some more work needs to be added, I support adoption.
> 
> Some comments:
> - I'd appreciate if the draft was covering expectable operational scenarios, namely
>  * There may be no bottleneck buffer - the test/metric needs to detect that and act appropriate.

I'm not sure what you mean ? Every flow is limited by some bottleneck that sits somewhere. Sometimes, it's the last mile, sometimes it's the Wi-Fi connectivity, sometimes flows become CPU-limited. But there always is a bottleneck somewhere that is limiting things at which point a buffer is building up (even though that "buffer" may be just 1 packet large)

[RG] 1 packet or 0 packets in the case of policing. There may be drops, but no added delay. I'm sure, that this will occur someplace in one direction, whether this condition may affect up- and downstream of the same success, I can't tell.

>  * One might be interested in the metric while the test adds an insignificant load only. While receiver tries to consume service X, what's the metric seen from Y? 
>     (may help to clarify, whether the access causes trouble or another network section).

That would indeed be interesting for trouble-shooting and debugging. I believe this is out-of-scope though.

[RG] If this draft isn't about trouble-shooting and debugging, what is it about? Please mention that capturing above metric is out-of scope in the draft.

> - Measuring the maximum RPM as seen from the test server is part of the test or it isn't? That's not clear to me by now.
>  I'm favouring to make measuring the maximum RPM part of the test, this may help to scale results.

The methodology defines to only measure from the client as we are interested in responsiveness as a metric that is (as close as possible) representative of an end-user experience.

When you say "maximum RPM", do you mean that on an "idle" network?

[RG] Thanks for asking. Likely "idle network": the maximum number of RPM measured from the client if there's no load on the access. Once these are known, one can relate the minimum number to be measured by design to them (that's a ratio, if my English doesn't leave me).

> - The test set-up should prevent application as DoS attack tool.

The json-fetch at the beginning of the test allows server-side CDN deployments to "rate-limit" clients by simply delaying the response to the json-fetch.

What else do you have in mind regarding a DoS attack tool?

[RG] Spoofed addresses in any direction, unexpected messages, undesired automated activation in the background of a client.... ideally, there should be no possibility to activate such a test, if the client doesn't want that explicitly. I've also proposed an "emergency stop" for load tests for the capacity measurement metric, and I think such a function may be worth a thought for all kind of tests aiming to fully consume the capacity of a bottleneck.

Regards,

Ruediger