Re: [Bloat] [Cerowrt-devel] Ubiquiti Launches a Speed Test Network

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Toke,
>
>
>> On Sep 6, 2019, at 19:59, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> Hi Toke,
>>> 
>>>> On Sep 6, 2019, at 10:27, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>> 
>>>> Mikael Abrahamsson <swmike@swm.pp.se> writes:
>>>> 
>>>>> On Wed, 4 Sep 2019, Matt Taggart wrote:
>>>>> 
>>>>>> So an interesting idea but they have some things they could improve.
>>>>> 
>>>>> I've been considering what one should run in parallel with the speed test 
>>>>> to get an impression if the speedtest impacts performance of other flows / 
>>>>> realtime flows, similar to what dslreports speedtest does.
>>>>> 
>>>>> I've considered running one or several simulated voip calls (50pps) and 
>>>>> record RTT, PDV, packet loss etc for this session.
>>>>> 
>>>>> It would be interesting to hear any suggestions people have for a fairly 
>>>>> simple codebase that does this that can be included in these kinds of test 
>>>>> clients (both server and client end, and of course one that protects 
>>>>> against reflection attacks etc).
>>>>> 
>>>>> iperf3 can be used for this, but from what I can see the iperf3 server 
>>>>> code isn't very friendly to multiple parallel tests or even resilient 
>>>>> against hung clients that doesn't close the test nicely.
>>>>> 
>>>>> I also considered using WebRTC or VoIP libraries, does anyone know what 
>>>>> RTT/PDV/packet loss data can be extracted from some common ones?
>>>> 
>>>> Pete coded up this wonderful tool for UDP-based latency testing; it's
>>>> even supported in Flent, and available on some (all?) the public-facing
>>>> servers:
>>>> 
>>>> https://github.com/heistp/irtt
>>> 
>>> This reminds of a tangentially related question, do we/could we
>>> actually write the requested DSCP into the packet payloads so we could
>>> see/display dscp bleaching/remapping packets experience during
>>> transit? For irtt, ping and even netperf TCP/UDP flows?
>> 
>> irtt could definitely do this; not sure if it does. Ping and Netperf,
>> probably not...
>
> From man ping (on linux):
> -p pattern
>               You may specify up to 16 ``pad'' bytes to fill out the packet you send.  This is useful for diagnosing data-depen‐
>               dent problems in a network.  For example, -p ff will cause the sent packet to be filled with all ones.
>
> From man ping (macosx 10.14):
> -p pattern
>              You may specify up to 16 ``pad'' bytes to fill out the packet you send.  This is useful for diagnosing
>              data-dependent problems in a network.  For example, ``-p ff'' will cause the sent packet to be filled
>              with all ones.

Yeah, but you can't read back the output...

> With fping I come up empty
>
> From man netperf (not sure how this wirks for servers):
> -F fill_file
>               Pre-fill the send buffers with data from the named file. This is intended to provide a means for  avoid-
>               ing buffers that are filled with data which is trivially easy to compress. A good choice for a file that
>               should be present on any system is this manpage - netperf.man.  Other files may be provided as  part  of
>               the distribution.:
> (so this would require us to distribute/generate 63 files for each dscp?)

We're already using -F /dev/urandom to prevent the netperf data from
being compressible... And also, this cannot be read back.


> From irtt help client:
> --fill=fill    fill payload with given data (default none)
>                none: leave payload as all zeroes
>                rand: use random bytes from Go's math.rand
>                pattern:XX: use repeating pattern of hex (default 69727474)
> --fill-one     fill only once and repeat for all packets
> --sfill=fill   request server fill (default not specified)
>                see options for --fill
>                server must support and allow this fill with --allow-fills

As above, we're doing --fill=rand today.

> This might actually work, and if it required a packetdump to compare
> DSCP and intended DSCP that would already be much better than what we
> have today, no?

Well, I'm sorta skeptical that anyone would actually look at those
packet dumps ;)