Re: [ippm] https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-03

[Sebastian Moeller <[e-mail]>]

Dear Marcus,

I apologize for forgetting to actually state, that I consider the draft, well reasoned and written. While I would appreciate discussion of the points I raised, I think this should be adopted, if need be as is.

On 9 January 2024 18:14:38 CET, Marcus Ihlar <marcus.ihlar=[e-mail]> wrote:
>Hi Sebastian,
>Since this review was submitted during an ongoing working group last call, it would be good to understand you support progressing this document given that you get sufficient answers to your comments and suggestions.
>Authors, it would be great if you could address the comments of this review.
>
>BR
>Marcus
>
>-----Original Message-----
>From: ippm <[e-mail]> On Behalf Of Sebastian Moeller
>Sent: Wednesday, 13 December 2023 21:05
>To: IETF IPPM WG <[e-mail]>
>Subject: [ippm] https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-03
>
>Dear List,
>
>I revisited my assessment of the actual calculation, and think we can do better (with little effort):
>
>
>"The responsiveness is then calculated as the weighted mean:
>Responsiveness = 60000 /
>(1/6*(TM(tcp_f) + TM(tls_f) + TM(http_f)) + 1/2*TM(http_s))
>
>This responsiveness value presents round-trips per minute (RPM)."
>
>And this makes sense for a single value result; though I believe that mixing up the self and the foreign probes into one aggregate is not the best we can do. At least for a standardized verbose output I think we should report self and foreign RPM values separately, exactly because they do measure subtly different things:
>foreign: inter-flow queueing
>self: intra-flow queueing
>
>these are not the same and hence aggregating them into a single number will not be the optimal to predict how well a link will behave under realistic loads.
>
>Especially, since the different types of queueing delay have different remedies (e.g. flow queuing will help foreign RPM, while AQMs will help self RPM, some more and some less).
>
>
>I also had a look at the recommendations regarding L4S testing:
>
>"As clients and servers become deployed that use L4S congestion control (e.g., TCP Prague with ECT(1) packet marking), for their normal traffic when it is available, and fall back to traditional loss-based congestion controls (e.g., Reno or CUBIC) otherwise, the same strategy SHOULD be used for Responsiveness Test traffic. This is RECOMMENDED so that the synthetic traffic generated by the Responsiveness Test mimics real-world traffic for that server."
>
>I think this at least needs to be selectable via command line switches (and the question arises whether working latency would not require a mix of L4S and non-L4S TCP flows with separate RPM reports for each type).
>
>Regards
>        Sebastian
>_______________________________________________
>ippm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ippm

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.