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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Toke,


> On Sep 7, 2019, at 00:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> 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...

	Yes, unfortunatley.

> 
>> 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

	Well, we could do 8 bytes DSCP in ASCII followed by ~1498Bytes randomness, but really which uploads actually use compression?


> 
>> 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.

	Sama as above, but maybe Pete could be convinced to do the read back of the first X bytes automatically.

> 
>> 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 ;)

Oh, I promise I will do this, occasionally ;)

Best Regards
	Sebastian