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

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

Juliusz Chroboczek <jch@irif.fr> writes:

>> So in this instance a new flow happens when a new user joins and their
>> video flow has to be established to every peer?
>
> When a user joins, nothing much happens: remember that Galène is meant to
> be usable for lectures with hundred of students.  When a user clicks
> « Ready », a stream with up to two tracks is established in the client->server
> direction.  Galène then determines the set of clients that have expressed
> interest in this flow (through the "request" message), and establishes n -
> 1 streams in the server->client direction.
>
> In the bundle case (which is what we currently do), each of the flows is
> an RTP session (a UDP flow).  In the non-bundle case, each of the flows is
> one or two RTP sessions, one per track.

OK. So in the current case, the latency for each other user to see a new
video flow when someone clicks "enable video" is a bit longer because
there's a handshake for each peer. Whereas in SSID multiplexing you
could skip the handshake?

>>> 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?
>
> They do, and Galène provides them with all the data they need to do their
> job.  So currently you have state-of-the-art congestion control in the
> server->client direction, but only basic loss-based congestion control in
> the client->server direction.  Which is good enough for lecturing (you
> usually try to give your lecture over an uncongested link) but sometimes
> suboptimal during departmental meetings (some people need to lock
> themselves in the attic in order to get away from their children).

Oh, right, so the server will also respond to the delay signals from the
clients' receiver-side? I.e., the only thing you haven't implemented is
the delay processing on the receiver side (from the last paragraph of
section 3 of draft-ietf-rmcat-gcc-02)?

-Toke