[Galene] Re: Congestion control and WebRTC [was: Logging]

[Dave Taht <dave.taht@gmail.com>]

On Sun, Jan 10, 2021 at 2:23 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Juliusz Chroboczek <jch@irif.fr> writes:
>
> >> No, I don't think multiplexing more streams over the same five-tuple is
> >> a good idea if it can be avoided. If the bottleneck does per-flow
> >> queueing (like FQ-CoDel), you'd want each video flow to be scheduled
> >> separately I think.
> >
> > Tere's a tradeoff here.  Using port multiplexing gives more information to
> > middleboxes, but using SSID multiplexing reduces the amount of ICE
> > negotation -- adding a new track to an already established flow requires
> > zero packet exchanges after negotiation (you just start sending data with
> > a fresh SSID), while adding a new flow for port multiplexing requires
> > a new set of ICE probes, which might take a few seconds in the TURN case.
>
> So in this instance a new flow happens when a new user joins and their
> video flow has to be established to every peer?
>
> >> Another couple of ideas for packet-level optimisations that may be worth
> >> trying (both originally articulated by Dave Taht):
> >
> > Why is Dave not here?
>
> I dunno; why aren't you here, Dave? :)
>
> >> In the presence of an FQ-CoDel'ed bottleneck it may be better to put
> >> audio and video on two separate 5-tuples: That would cause the audio
> >> stream to be treated as a 'sparse flow' with queueing priority and fewer
> >> drops when congested.
> >
> > Uh-huh.  I'll send you a patch to do that, in case you find the time to
> > test it.
>
> Sounds good, thanks!

This is what we did in a videoconferencing app... in the 90s... with
sfq... it gives
a "clock" from the audio that should with fq_codel or especially cake give very
fastr congestion feedback....

awesome. I am really liking galene...

>
> >> (As an aside, is there a reference for the codec constraints in
> >> browsers? And is it possible to tweak codec parameters, say to burn some
> >> bandwidth to enable really high-fidelity audio for special use cases? Or
> >> is Opus so good that it doesn't matter?)
> >
> > A typical laptop microphone has rather poor frequency response, so Opus at
> > 48kbit/s is as good as the original.  It's just not worth reducing the
> > audio rate upon congestion, it's the video rate that gets reduced.
>
> Right, I see. Looking at the commit that introduced codec support, it
> looks pretty straight-forward to crank up the bitrate; maybe I'll
> experiment with that a bit (but not using my laptop's microphone).
>
> > As to the video rate, you've got plenty of exciting knobs.
> >
> > 1. Congestion control.  As implemented in modern browsers, WebRTC uses two
> > congestion controllers: a fairly traditional loss-based controller, and an
> > interesting delay-based one.  This is described here:
> >
> >   https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02
> >
> > Unlike some other video servers, that mere forward congestion indictions
> > from the receivers to the sender, Galène terminates congestion control on
> > both legs.  currently obeys congestion indication from the receivers, and
> > implements the loss-based congestion controller for data received from the
> > sender.
> >
> >   https://github.com/jech/galene/blob/master/rtpconn/rtpconn.go#L956
> >
> > We do not currently implement the delay-based controller, which causes
> > collapse if the sender is on a low-rate bufferbloated network.  That is
> > why Galène's client limits the rate to 700kbit/s by default (in the
> > « Send » entry in the side menu).
>
> Right, but the browsers do?
>
> > Implementing the delay-based controller is number 1 on my wishlist.  Your
> > help would be greatly appreciated.
>
> Can't promise any hacking time, unfortunately, at least not short-term.
> Happy to test out stuff, though :)
>
> > 2. Sender-side tweaks.  The sender has a number of knobs they can tweak,
> > notably maximum bitrate (separately for each track), and hints about
> > whether to prefer framerate or image quality upon congestion.  The sender
> > can also pick the webcam resolution, and they can request downscaling
> > before encoding.
>
> Ah, hence the "blackboard mode" - gotcha!
>
> > 3. SVC.  The technology that excites me right now is scalable video coding
> > (SVC), which I believe will make simulcast obsolete.  With VP8, the
> > sender can request that some frames should not be used as reference for
> > intra prediction; these « discardable » frames can be dropped by the
> > server without causing corruption.  VP9 implements full scalability:
> > temporal scalability, as in VP8, spatial scalability, where the codec
> > generates a low resolution flow and a high resolution flow that uses the
> > low resolution flow for intra prediction, and quality scalability, where
> > the codec generates frames with varying quality.
> >
> >   https://en.wikipedia.org/wiki/Scalable_Video_Coding
> >
> > I'm currently planning to skip simulcasting, which I feel is an
> > obsolescent technology, and experiment with SVC instead.  Implementing the
> > delay-based controller is a higher prioerity, though.
>
> Uh, hadn't heard about that before; neat!
>
> >> Another packet-based optimisation that could be interesting to try out
> >> is to mark packets containing video key frames as ECN-capable.
> >
> > Keyframes can be huge (120 packets is not unusual), it wouldn't be
> > resonable to mark such a burst as ECN-capable without actually reacting to
> > CE.  And if we drop part of the keyframe, we'll NACK the missing packets
> > and recover 20ms + 1RTT later.
>
> Hmm, right, okay I see what you mean...
>
> >>> Ideally you'd also actually respond to CE markings,
> >> RFC 6679.  I don't know if it's implemented in browsers.
> >
> > It is not.
>
> Ah, too bad :(
>
> -Toke



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729