User based, long duration tests seem fundamentally flawed. QoE for users
is driven by user expectations. And if a user won't wait on a long test
they for sure aren't going to wait minutes for a web page download. If
it's a long duration use case, e.g. a file download, then latency isn't
typically driving QoE.
Not: Even for internal tests, we try to keep our automated tests down to
2 seconds. There are reasons to test for minutes (things like phy cals
in our chips) but it's more of the exception than the rule.
Bob
0) None of the tests last long enough.
The user-initiated ones tend to be shorter - likely because the
average user does not want to wait several minutes for a test to
complete. But IMO this is where a test platform like SamKnows, Ookla's
embedded client, NetMicroscope, and others can come in - since they
run in the background on some randomized schedule w/o user
intervention. Thus, the user's time-sensitivity is no longer a factor
and a longer duration test can be performed.
1) Not testing up + down + ping at the same time
You should consider publishing a LUL BCP I-D in the IRTF/IETF - like in
IPPM...
JL
_______________________________________________
Rpm mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/rpm
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
