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=1610317425; bh=xzjFfkGLG1GT041jGbSgIEm9qiQQul0+8Uo3pN8Zaa0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I6qRiDCTaHSkjNuwRQR7oi/AJWjJojV/wYdqyX4geu8A2cd2oObQHCa39SW0wsu9t 5+k1jc8xs4QC8kidFHO+Ife1TrHzCrZAwhZCVghUo4Vq60XRh6mdY6ESv7+55yNRga MhyQqwqeALPh9tOZKXypPnyOcwgNTmHULzhriY5yO5eUZo3vhIZTTdcB/tr/4zqvOa bGC0l3pVxWfHQjLFBUl3ygjCwdN+UpMfgT0krhbR0BQ/GOa7G8xSgJL1NXPnkL7tja gnQ7ah1gE1iWCGObcxRAA6yXWsVdCvbGY0h6O//jRs5FoofosYEjlxXD2BhAh70kuE gvvlCRot/mLNg== To: Juliusz Chroboczek , Dave Taht In-Reply-To: <87lfd04ye5.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> Date: Sun, 10 Jan 2021 23:23:41 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87eeismnwy.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RLYDYWU7VR7X33T26RFXDBXYXIWB45XG X-Message-ID-Hash: RLYDYWU7VR7X33T26RFXDBXYXIWB45XG 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: 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: >> 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! >> (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=C3=A8ne terminates congestion contr= ol 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=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? > 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 =C2=AB discardable =C2=BB frames can be dropped b= y 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