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

[Sebastian Moeller <[e-mail]>]

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