From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by mail.toke.dk (Postfix) with ESMTPS id 33B3B860AC8 for ; Sat, 10 Jul 2021 18:36:45 +0200 (CEST) Received: (qmail 23553 invoked from network); 10 Jul 2021 16:36:44 -0000 X-APM-Out-ID: 16259350042355 X-APM-Authkey: 255286/0(253943/0) 97 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Jul 2021 16:36:44 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 808BB80EFD; Sat, 10 Jul 2021 17:36:44 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AO1coGRc5ZOV; Sat, 10 Jul 2021 17:36:44 +0100 (BST) Received: from phage-rock.fritz.box (p54ac5f03.dip0.t-ipconnect.de [84.172.95.3]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 443E780B6F; Sat, 10 Jul 2021 17:36:44 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: T H Panton In-Reply-To: Date: Sat, 10 Jul 2021 18:36:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> References: To: Dave Taht X-Mailer: Apple Mail (2.3608.120.23.2.7) X-MailFrom: tim@pi.pe X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: NTLXHPFTKBTKF53II5KA3YZVAI4335GT X-Message-ID-Hash: NTLXHPFTKBTKF53II5KA3YZVAI4335GT X-Mailman-Approved-At: Sun, 11 Jul 2021 13:05:14 +0200 CC: galene@lists.galene.org X-Mailman-Version: 3.3.4 Precedence: list Subject: [Galene] Re: using up more ports in ipv6 for better congestion control List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On 10 Jul 2021, at 17:15, Dave Taht wrote: >=20 > tim panton wrote me just now on linked in: >=20 > "It is still possible. Just set bundle-policy to max-compat and you'll > get one stream for audio and one for video. Turn off rtcp-mux and > you'll get 4 ports (voice, video, voice-RTCP, video-RTCP) - But your > ability to connect will drop significantly (according to Google's > data) and your connection setup time will increase. Even with port > muxing congestion control is still possible, it just works > _differently_ - which arguably it should, because realtime video has > quite different needs from streaming or file transfer. Happy to have a > chat about this...." >=20 > (so... chatting via email is preferred for me) >=20 > I am also under the impression that the congestion control > notifications in rtcp are essentially obsolete in the rfc, mandating a > 500ms interval instead of something sane, like a frame? Oh, no, the congestion control is _very_ much alive in webRTC but under = guise of=20 bandwidth estimation - The =E2=80=98simplest' is google=E2=80=99s REMB = RTCP message which basically looks at the arrival time of packets and uses any _lengthening_ in the = tof to deduce the onset of additional buffering in the path. Transport CC tries to expand this to = apply to all the streams muxed over a port by adding an RTP header extension with an accurate (NTP) clock in it. The thing that drives design this is that losing a packet is = catastrophic for realtime video, =20 one dropped packet makes seconds (aka megabytes) worth of data = un-renderable. At 50 fps the frame interval is shorter than the roundtrip time on the = path (for VDSL users anyway - perhaps not fiber) so a NAK/resend will fix it too late. So the strategy is to dynamically estimate the capacity of the path and = try to surf _just_ under that, ensuring minimal packet loss. I realise this is anathema to TCP folks, it certainly came as a shock = to me=E2=80=A6. T. >=20 > My other fantasy is to somehow start using udplite for more things. >=20 > The context for this of course is my never ending quest to have an IP > based video and audio streaming system good enough to have a band > playing with each other across town. >=20 >=20 > --=20 > Latest Podcast: > = https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ >=20 > Dave T=C3=A4ht CTO, TekLibre, LLC