Re: [Rpm] [EXTERNAL] Re: [Starlink] Researchers Seeking Probe Volunteers in USA

[rjmcmahon <rjmcmahon@rjmcmahon.com>]

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
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm