Subject: [tsvwg] public testing against an unusual misconfigured bbr ecn sender

From: Dave Taht <[email-masked]>
Date: Sun, 26 Apr 2020 17:06:29 -0700

dropbox appears to have bbrv1 enabled and is negotiating ecn, (at
least, in my location), but not responding to ecn signals.

this is a marvelous opportunity for y'all to test  all your single
queue/dualpi/fq pie/red/codel/ aqm and transport code against a
non-compliant cc mistakenly enabling ecn! Get some captures while you
can.

The 400MB file I've been using to test with (doing a "direct
download") is here:
https://www.dropbox.com/s/4d20jakm25xz4pu/linux.tgz?dl=0

Ironically enough, this file contains some flent data and packet
captures I was doing on the ath10k, and the act of taking that packet
capture on a low power cpu heisenbugged the test, so the data therein
is an object lesson of how NOT to take a capture when doing a test,
and f you look at that data you can see what screwing up a packet cap
test can look like.... so

---------- Forwarded message ---------
From: Dave Taht <[email-masked]>
Date: Sat, Apr 25, 2020 at 5:36 PM
Subject: dropbox, bbr and ecn packet capture
To: bloat <[email-masked]>, ECN-Sane
<[email-masked]>
Cc: Alexey Ivanov <[email-masked]>

I just did a rather large dropbox download. They are well known to be
using bbr and experimenting with bbrv2. So I fired off a capture
during a big dropbox download...

 It negotiated ecn, my fq_codel shaper and/or my newly ath10k
fq_codel's wifi exerted CE, osx sent back ecn-echo, and the rtt
results were lovely. However, there is possibly not a causal
relationship here, and if anyone is bored and wants to scetrace,
tcptrace or otherwise tear this cap apart, go for it.

http://flent-fremont.bufferbloat.net/~d/db.cap

--
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729