Ubuntu seeding and bufferbloat

Harvy66

Ubuntu 16.04 LTS was released this morning and I like to help seed opensource stuff. Look at how my loss spiked to 11% for a short bit. That's my ISP's anti-bufferbloat. As you can see, my max ping was under 30ms even though my loss shot up. At the 1min interval, it was actually almost 17% for the max.

Why such high loss you ask? Too many seeders with over 2,000ms of bufferbloat flooding me with resent packets. Bufferbloat can make TCP a not a good citizen for congestion control algorithms that only care about loss. Fortunately it's only an issue for downloading and only for seeders using TCP. Once my download starts to get moving, uTP is the most common protocol and it's latency aware.

UbuntuSeed.png_thumb

richb-hanover

Thanks for this report. It shows important results about the value of controlling bufferbloat everywhere in every cable/dsl modem, router, etc.

I see that packet loss and delay spiked just at 07:00, presumably when 16.04 LTS became available. I'd like to pass these measurements along to the bufferbloat team, and would like to ask a couple more questions:

Where are you measuring packet loss and ping times? From pfSense to … ?
I agree that bufferbloat could responsible, but do you have other evidence/measurements that indicate that your server was seeing re-transmits after 2000 msec?
Do you run fq_codel other other SQM (smart queue management) in your firewall?

Thanks!

Harvy66

The default gateway target, which seems to be a DHCP server in my ISP
While I didn't wireshark it this time, I have done so in the past. What I saw was a bunch of dup packet responses getting sent from my WAN. WAN ingress was 100Mb/s and LAN egress was about 70Mb/s. PFSense seems to have filtered out the already acknowledged traffic and responded on behalf of my computer. When I did a trace route to these target IP addresses, while I was still downloading from them, I saw normal 2ms ping here, 10ms ping there, 20ms ping there, then right before it got to the seeder, 2,000+ ms pings. I samples about 10 TCP connections that were causing all of those dup packet responses, and they all had the same large ping jump 1-2 hops away from reaching them, but otherwise good hop pings within their ISP's network. Just not the last 2.
I do use HFSC and CoDel

My ISP does also have some unidentified AQM. All I know is without any shaping on my end, DSLReports says I get about 20-30ms of buffer bloat. With shaping on my end, I get bloat down to about 1ms. This is also reflected when I had a DOS volume attack tested against my connection. I had a service send 110Mb/s at my 100Mb connection and I saw about 10% loss and typically 30ms-40ms of latency. Even when pushed to 200Mb flood, still 30ms-40ms, but something like 50%+ loss. I forget exactly how much, but my connection was dead.