[Galene] Re: Logging

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Juliusz Chroboczek <jch@irif.fr> writes:

>> So in this case, how is using a TURN server different than just having
>> Galene itself listen on a bunch of UDP ports and offer each of those?
>
> Short answer: Galène needs hundreds or even thousands of ports.  TURN can
> use a single port, which you can pick such that it's accessible from your
> clients.
>
> Long answer.  Galène uses WebRTC.  WebRTC uses RTP.  RTP transmits
> a collection of tracks.  RTP can work in two modes:
>
>   - port multiplexing: use the UDP port to associate packets with tracks;
>   - SSID multiplexing: multiplex over a single UDP 5-uple, and use data in
>     the RTP header to associate packets with tracks (this is called
>    "bundling" in WebRTC).

Ah, I see. I think I was mentally assuming SSID multiplexing, so that's
what I was missing. Thanks for the clarification!

> Now, there are two limitations:
>
>   1. Pion is unable to use a single local UDP port for multiple RTP
>      sessions: it uses a distinct UDP port for every RTP session, even if
>      sessions have dinstinct remote addresses;
>
>   2. Galène uses a distinct RTP session for every stream (pair of audio
>      and video tracks); in other words, Galène ony bundles at most one
>      video and one audio track.
>
> Fixing (2) is not a high priority, since it would make the code way more
> complex (bundling is fragile, there are some limitations to what you can
> do when bundling streams with different configurations and some limitations
> to how you can mutate a bundle without tearing it down).  It might
> cause issues with AQMs (is it a good idea to use the same 5-uple for
> different videos?), but you're the specialist here.

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.

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

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.

(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?)

Another packet-based optimisation that could be interesting to try out
is to mark packets containing video key frames as ECN-capable. If the
bottleneck AQM respects ECN, that would prevent key frames from being
dropped. Ideally you'd also actually respond to CE markings, of course,
but just doing selective marking of the ECN-capable bit inside the
stream would theoretically make it possible to protect key frames while
still reacting normally to drops of other data packets...

-Toke