[Rpm] [EXTERNAL] Re: [Starlink] Researchers Seeking Probe Volunteers in USA
rjmcmahon at rjmcmahon.com
Mon Jan 9 14:19:59 EST 2023
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.
>> 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
> Rpm mailing list
> Rpm at lists.bufferbloat.net
More information about the Rpm