From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by mail.toke.dk (Postfix) with ESMTPS id AC0197C8DE7 for ; Sun, 10 Jan 2021 23:44:25 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LqWszm/a Received: by mail-io1-xd30.google.com with SMTP id w18so15937965iot.0 for ; Sun, 10 Jan 2021 14:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q0fPNEd1sFkYwhU3U96qdBaCmAww7JGREJlHwkA/Ne0=; b=LqWszm/ax3WgK1V2+yT9EVRJhnihQ6UcpmjZHZ6INOsFZzZof4bA8P8fNPcI+akocQ 4QApjwoau8gjyYMiYJNY9O/mYQMwZ9vEZyyt9WMvG61pqWDHBUW/GZ7OLHEi0ncwUjTw Nss5rBvMx1sOO/PoIhMJJb6F3lbKcJqihReqoNMWIRK2Z1alo1NmyK9kddRcQlauL+X3 VTHx78/0Z51iup0wTzRTm6xMhEpsSNeamDq0wgx/ZcfxTrhaGeMbJF4USiUcuRC7qsdJ cnOQOOWZWUdB4BEQnStwZjbmZo3yrBQJnnmtJwp+AoggORvQ+ACCoTpRPd5+Pi8I5fjf 7v9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q0fPNEd1sFkYwhU3U96qdBaCmAww7JGREJlHwkA/Ne0=; b=KYoInvLwnuwkXGfKbtjcNG3pvJHxE8PWkTK1jXa2pUv6500GIRGReDN2yvp22o46j+ klH+wA/pa+PZCEwM56KK4sc18psTMkfcG0DwzjuJSWAJQbB3BXX28jOMrHCu4jbiSVOG zAogzUPoWz9CP0j0XeIezygHg5iCOxFiOfMb649cP/iGE0e5PwYpcx2TMO4pu5XczXiN clVhLfbE+XizTsEtGq5SCmHCZWjRDPgR9mGP0gPosMsmZWJSvZToIP2+ho4HD5coqpwS uzDKWZ0w3+k3nzC4c9TH/Iew6opjYbLHrl/uKXnzUlrQQbtjUG7TpeXtZCCIzbjDdb8I lE0Q== X-Gm-Message-State: AOAM533pZsABPzc1ZXD5VO8tl32F8jV0nJ17IfzUJo+6VqoBjfZ9nLC6 JBP0VNbY5pmxQ2Hrmp48EeP2JTUt+ffa53GDFQY= X-Google-Smtp-Source: ABdhPJz4MYQ9BchFpzfTj3yPVESJgyN4tvGjKPtZ5V3pu58bxWvCgr+i6DO9KLBFa8LPJvDkGU4tGXYzDcHTzIc63hk= X-Received: by 2002:a02:6557:: with SMTP id u84mr11870758jab.82.1610318661054; Sun, 10 Jan 2021 14:44:21 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <87eeismnwy.fsf@toke.dk> From: Dave Taht Date: Sun, 10 Jan 2021 14:44:09 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MailFrom: dave.taht@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: VAZGHO7EKQYQFGIMAJN5OHMPODFFPEKI X-Message-ID-Hash: VAZGHO7EKQYQFGIMAJN5OHMPODFFPEKI X-Mailman-Approved-At: Mon, 11 Jan 2021 00:53:54 +0100 CC: Juliusz Chroboczek , 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: On Sun, Jan 10, 2021 at 2:23 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Juliusz Chroboczek writes: > > >> No, I don't think multiplexing more streams over the same five-tuple i= s > >> 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 require= s > > zero packet exchanges after negotiation (you just start sending data wi= th > > 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 cas= e. > > 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 wor= th > >> 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 few= er > >> 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! This is what we did in a videoconferencing app... in the 90s... with sfq... it gives a "clock" from the audio that should with fq_codel or especially cake give = very fastr congestion feedback.... awesome. I am really liking galene... > > >> (As an aside, is there a reference for the codec constraints in > >> browsers? And is it possible to tweak codec parameters, say to burn so= me > >> 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 indiction= s > > from the receivers to the sender, Gal=C3=A8ne terminates congestion con= trol on > > both legs. currently obeys congestion indication from the receivers, a= nd > > 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 th= e > > =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. Yo= ur > > 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 send= er > > 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 cod= ing > > (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= 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 th= e > > low resolution flow for intra prediction, and quality scalability, wher= e > > 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 packet= s > > 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 --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729