[Bloat] RTMFP improvements from Michael Thornburgh

[Dave Taht]

This is extracted from a chat conversation with Michael Thornburgh
with his permission. I too have experimented with OBS and twitch
streaming and felt it needed some love, in particular.

https://github.com/zenomt/rtmfp-cpp#delay-based-congestion-detection .


...

Hi Dave. For some reason I keep working on RTMFP, the real-time
protocol I co-created at Adobe ("some reason" == I still think it's a
better holistic solution than the mish-mash of stuff that's WebRTC,
and QUIC). A while ago I added ECN support. Unfortunately, no networks
I regularly use (my android phone + TMobile, Cruzio) seem to have any
AQM+ECN deployed.

 I'm not really a fan of E2E delay-based bufferbloat mitigations
because there are too many false signals and there's a better real
solution. but because of reality, i held my nose and added delay-based
congestion detection to my RTMFP implementation. I had a few insights
while doing it that I thought you might find interesting (which of
course might be totally obvious, but i didn't find written down
before), mostly around clearing/resetting "baseline RTT" in more
circumstances to try to avoid permanent starvation.

I wrote an explanation (including how it works and how to turn it on)
here: https://github.com/zenomt/rtmfp-cpp#delay-based-congestion-detection
.

I've found it works very well on my TMobile LTE connection when the
signal is highly variable (like walking around my house and through
known coverage shadows). I haven't done experiments yet with
bidirectional traffic and mixes with delay-insensitive traffic, nor
have I simulated different scenarios beyond my own real-world testing.
I hope to have time for that soon, and to write up findings vs
something like SCReAM. this is also an invitation to check out RTMFP
(RFC 7016) and my impl!!!

more eyes on rtmfp would make me happy. :)

There's a bunch of stuff in my RTMFP implementation's CC that might
not be obvious without getting deep in the code. I should probably add
more exposition in the README. The CC is window-based but with
modified AIMD parameters for real-time (cut 1/8 instead of 1/2 on
congestion signal, but grow more slowly when things are good to
balance) and with slower slow-start for real-time. "congestion signal"
is loss or ECN-CE, or extra delay > thresh if enabled. transmission
uses a hybrid of ack-clock and a burst-avoiding pacer. i could talk
about it all day if you're curious. :) or just point you at relevant
parts of the code or RFC.

I think one of the big problems with people streaming on twitch (and
other services) is bad RTMP implementations. OBS, as far as i can
tell, still hasn't heard of TCP_NOTSENT_LOWAT. that, a good ABR for
your encoder, and actually-good real-time treatment for data queued in
RTMP can make a giant difference for quality and latency. of course
none of those things can fix a router that's bloating up! and
delay-sensitive ABR algorithms will drive to 0 if there isn't some
other reservation (like i saw at that link with trying to allocate
3Mbps of 5Mbps for twitch with DSCP).

-miketh