From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1610324404; bh=HvPCsJFG9HoVS1fEpFCTGPchVvpDws7MSQbSA4Wf/yI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=c0ua/ZiT9XKh/7tT22e9KSWbLGQQ9jzTM1YR7gwsJjpXiHKtMJn0AUwqSerEgrZ1h gEfvFDxF7DYUgzlAiyAXL9avtDBYGXqjLWyGe9QvIvgykenBqquEM90mF9Z/aSF3Sv 2ncWrmlpDUCAuysL88saD2wSIrZfUdt4YSNhjdWJBv3hxqg4jXTPRrzmf7+TxODdFf PeLZevT58UV0Ua4tRaFbHg8/GHFtj7MRZhEeRLiNU0SgYpBGu7HPnFqe2GGMFrMDKs btxo5ClUjrvLq8UoYo/uYc1KpvPddcGD8pbUbBkFN9uRx2c4GLTnH81i35n2pNVDfr O/h145vM4edaA== To: Juliusz Chroboczek In-Reply-To: <878s9049pm.wl-jch@irif.fr> References: <875z485swt.wl-jch@irif.fr> <87wnwnha9w.fsf@toke.dk> <87v9c77e20.wl-jch@irif.fr> <87turrh6y2.fsf@toke.dk> <87mtxj789e.wl-jch@irif.fr> <87o8hzgr4j.fsf@toke.dk> <871rev6w4a.wl-jch@irif.fr> <87im87gdy3.fsf@toke.dk> <87wnwmnsj9.wl-jch@irif.fr> <877dokhpja.fsf@toke.dk> <87lfd04ye5.wl-jch@irif.fr> <87eeismnwy.fsf@toke.dk> <878s9049pm.wl-jch@irif.fr> Date: Mon, 11 Jan 2021 01:20:04 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bldwmiiz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: GXJ3OV3IO2SG3U3B6BDCBCJW5PXRX4BW X-Message-ID-Hash: GXJ3OV3IO2SG3U3B6BDCBCJW5PXRX4BW X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Dave Taht , galene@lists.galene.org X-Mailman-Version: 3.3.2 Precedence: list Subject: [Galene] Re: Congestion control and WebRTC [was: Logging] List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Juliusz Chroboczek 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=C3=A8ne is mea= nt to > be usable for lectures with hundred of students. When a user clicks > =C2=AB Ready =C2=BB, a stream with up to two tracks is established in the= client->server > direction. Gal=C3=A8ne then determines the set of clients that have expr= essed > 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=C3=A8ne's client limits the rate to 700kbit/s by default (in the >>> =C2=AB Send =C2=BB entry in the side menu). > >> Right, but the browsers do? > > They do, and Gal=C3=A8ne 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