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

[Juliusz Chroboczek <jch@irif.fr>]

> 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.

> Another couple of ideas for packet-level optimisations that may be worth
> trying (both originally articulated by Dave Taht):

Why is Dave not here?

> 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.

> (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.

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).

Implementing the delay-based controller is number 1 on my wishlist.  Your
help would be greatly appreciated.

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.

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.

> 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.

> Ideally you'd also actually respond to CE markings,

RFC 6679.  I don't know if it's implemented in browsers.

-- Juliusz