Some quick random notes towards future bloat work (fun?)

[dtaht]

@tohojo @richb-hanover @heistp @chromi (et al - normally I'd use the bloat list or a google doc for this, I don't know all the aliases folk use on github)

I have no idea what will do for a next project, if we do one. 7 years of debloating enough for y'all?

Whats left worth fixing?

Personally I have an hankering to go look hard at a "sane ecn", which in part involves looking at tcps and in part improving codel-ly responses to it. Other stuff might be fixing bloat in things like openvpn or wireguard. Am still in search of another wifi chipset worth fixing. Nobody seems very interested in speeding up cake, ebpf, or doing bobbie. As I have an early deployment of "fast" cake, running at 100mbit on wndr3800s, I personally need a faster shaper, so I took an old fork of that ( https://github.com/dtaht/sch_tart ) and will try to get it working at some point.

I could see trying to add better network stats awareness to various core applications, like netperf,
apache, ssh, and freeswitch, to get them to notice things like retransmits. "smartperf". Babel could also use some love here in how it blasts traffic. I'd like to be fiddling with audio at 2.7ms intervals.

I put a bunch of possibly worthwhile things for flent over here: tohojo/flent#148

On the tcp front, I've been forced of late to think about ecn issues hard ( systemd/systemd#9880 ) . I've done my best to ignore the whole issue for more than a few years now. Part of my problem is that few share my deep skepticism about it or my level of testing and the other is what it does to my BP when discussed. redteaming it would be reassuring.

Stuff I'd like to try includes:

fq

• can we make it faster?
• researching van's timer queue idea and virtualclock based fq and the etx qdisc

aqm

• Improving the bulk dropper (see: https://lists.bufferbloat.net/pipermail/codel/2018-August/002367.html )
• increase codel's marking frequency faster
• try to figure out of the l4s folk are entirely or only partially insane.

tcps (see also: systemd/systemd#9725 )

• if we are stuck at cwnd 2 and still getting loss, reduce the initial window, constrain growth for a while,
  pretend we are re-ordering (?).
• make cwnd 1 possible again
• decrease the mss dynamically as torrent used to do
• evolve tsq + pacing so that pacing is independent is independent of the cwnd
• an ect(0) - should at the very least constrain cwnd growth as it happens in the case of loss or reordering, I don't think it does. I'm also unsure if we have rfc compliant behavior on retransmits
• both ecn and loss on a RTT - cut back by more than half
• Fiddle with bbr
• try to incorporate some bbr ideas into cubic
• fiddle with quic

cake

• anything that could make it faster
• ISP version
• cake-mq

fq_codel

• Make sure the bsd version is right

BQL

• I'd like to see this scale better with multiple hardware queues
• AIMD version

website

• could use some love in general
• lartc finally died we can replace it
• hugo is at v44, and we are stuck at 18
• doing a better educational video
• pursuing publicity, picking another fight with the fcc
• more talks

videoconferencing

• try breaking the audio and video into different tuples, use the audio as a clock for the video
• try improving encoders to have better changes in network conditions

???
...

Or we could all declare victory and stay home merely enjoying our vastly better networks. I'm thinking of taking up starcraft 2 again. Anybody want to take on me as a Protoss? :)

[tohojo]

Dave Täht <[email protected]> writes:

normally I'd use the bloat list or a google doc for this

So what has gotten into you this time? ;)

I have no idea what will do for a next project, if we do one. 7 years of debloating enough for y'all? Whats left worth fixing?

Yeah, I think we're done. Let's just push out a press release declaring the internet is now perfect! /s

Personally I have an hankering to go look hard at a "sane ecn",

Go for it; AFAIK there are two efforts in the IETF related to ECN: The l4s stuff, and ABE: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-09 For my part, I have a thesis for finish; so no new commitments for the next several months...

Or we could all declare victory and stay home merely enjoying our vastly better networks. I'm thinking of taking up starcraft 2 again. Anybody want to take on me as a Protoss? :)

Haha, this could be fun; haven't played for ages! :)

…

-Toke

[chromi]

There are some interesting ideas and topics in the above. Some are even relevant to an ISP-grade Cake variant. The main trouble for me, as always, is funding. My landlord has been very accommodating, but even he has limits.

Or we could all declare victory and stay home merely enjoying our vastly better networks. I'm thinking of taking up starcraft 2 again. Anybody want to take on me as a Protoss? :)

I've never played Starcraft. I tried DOTA 2 once, and completely lost interest before completing my first training match. Now, if Cold Waters had a viable multiplayer mode... (it doesn't and never will, but still) - Jonathan Morton

[heistp]

On Aug 21, 2018, at 12:56 AM, Dave Täht ***@***.***> wrote: I have no idea what will do for a next project, if we do one. 7 years of debloating enough for y'all?

I’ll get back to you in five years. :)

Whats left worth fixing?

I’d like to see better clarification on, in an ideal world, what end hosts should do, what middle boxes should do and where it should all happen in the stack. Easy peasy.

Nobody seems very interested in speeding up cake, ebpf, or doing bobbie.

I’m interested in SMP cake as a way to speed it up, though not up to it yet myself. And eBPF, in general.

???

On the testing side, I feel we could have a better handle on how we help real world traffic. Two suggestions to improve it: - Request-pair support in irtt, to measure the difference between best effort traffic and traffic given strict priority (which I hope should estimate actual bloat time), and add this to the irtt smokeping probe. This is on my list. - Passive testing on real-world traffic, which I see was mentioned on the bloat list recently and I think may be the holy grail of evidence. Theoretical tests will always be open to criticism, and rightfully so. Can this be done with eBPF? I wonder if I shouldn’t port irtt to C and make it a broader testing tool, but I suspect there’s more important stuff to do. Like Jon, I’d also appreciate to find some funded work within bloat, or need to find it elsewhere at some point. Usually when I think of what needs to happen for that to be a reality though, I crawl under a rock and look for something to code, test or write. Admittedly, that’s not a great approach on something that needs a different kind of effort to make happen. Is anything happening with the WiFi simulator project? Is it worthy? In general, I’d like to put some focus into something deeper, and not jump between too many ideas, but I’ve still got old commitments within bloat to finish also. I’ll gradually be catching up on some emails. I was also a little perplexed today by that systemd thread. Best of luck to Doctor Toke! And lastly, an unsolicited historical reminder on what happened August 21, 50 years ago: https://nyti.ms/2wjzVC8 <https://nyti.ms/2wjzVC8>

[dtaht]

@chromi well redhat amazon google facebook etc are all still hiring like crazy. There aren't a lot of things out there for independent folk, nor 5 year long breakthrough projects. I think with sch_cake on your resume and your deep knowledge of tcp, all those companies would express an interest.

Same goes for you pete. You have serious fans within google.

Me, well, I'd hoped to spend the next year on my boat writing my phd thesis, but I think I'm going to go looking for a job with mere quarterly deadlines instead.

[dtaht]

@tohojo @chromi what starcraft race are you?