From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by mail.toke.dk (Postfix) with ESMTPS id 735E5860AEB for ; Sat, 10 Jul 2021 18:49:03 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=X9WIpwmb Received: by mail-io1-xd31.google.com with SMTP id y8so16552528iop.13 for ; Sat, 10 Jul 2021 09:49:03 -0700 (PDT) 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=aphCagBJ9e7LvGQ5U5r2bOlyyZiHHo51u+2oZnOHphk=; b=X9WIpwmb2/Sf2W9doALyPaZ05hNqTF1Qjl4ileR8c2im9ubPVXBpQw7LNUANCUIFJR iuXTgkdUYu+qaFaGvqPGJ55joPn2RCabKxUTaEYTZIkWOtXhxFKmHZf4xMFmlOdIDu/9 Wdimmw3K8GcX26Ml+Rfr+NoJ+IzxIKbIwRp1NZ2X60dyvDJbKaQs3vm48nLzHbCz8K8s ljYjLfZ+Jf5LVQZQwPXPv8vlRB2cKxJ8k7XwYVItkhN4w8O32to4eVTPYum+KuQqCA5i nPWHui7Y5WEab6ODH4R3+dg9ZcY4G600jNDDKPPCYteiXBUIHSAXtp2NTegbyOs7CyZy sspg== 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=aphCagBJ9e7LvGQ5U5r2bOlyyZiHHo51u+2oZnOHphk=; b=uh9TT+wOFFFfhtJJLdwYeSAgFJurTMA4ypUcjzWsHBh3XJqfqRixnsrZF2anidnWc/ pIj8WuohqQQpOH52q5EdyzuXzR91mm0/yANFmsvc/awVhXlAFe6rb7v+1NVGS9fvaTWv 2NupzLO1cxT21WIaPVQAMOIdk+ROPaksnrJe6OaIcbT3HOsBVJlQ2YgXB7xYCpRbUf2w Yls9SC9F42oNP0oND60aEzV2H4CRqO3XYxhJZtaum6R15dtuAfM3/1f4yYNmG3MufACU q9u1BlkBk7H29up/vBVqIiZsZ1oXiBoKO9a0FLnrt/u6e/Ke39G4tVUVkMiCy0wBWoYP 5sDw== X-Gm-Message-State: AOAM533A+L4S+4rZ1gmmGMl4mB7CtoBKqUeASsABVHg2X7CBeDqAmzui St2DG5E7fy+KxwPXz5kaiIGid5xHEKsvVg0StF0= X-Google-Smtp-Source: ABdhPJw7CPyR9tcMc1+36AxdiPcPhibweyLHGabbg3rWYw/xoefhsHhgzY3C8pOhXnCZa+keHvV6so5oPS68/PUbAm0= X-Received: by 2002:a02:cad9:: with SMTP id f25mr13549194jap.97.1625935742426; Sat, 10 Jul 2021 09:49:02 -0700 (PDT) MIME-Version: 1.0 References: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> In-Reply-To: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe> From: Dave Taht Date: Sat, 10 Jul 2021 09:48:50 -0700 Message-ID: To: T H Panton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 5WUZSGQ3HJL725LJGK2SFGKX5ZDPVDVT X-Message-ID-Hash: 5WUZSGQ3HJL725LJGK2SFGKX5ZDPVDVT X-MailFrom: dave.taht@gmail.com 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; digests; suspicious-header CC: galene@lists.galene.org, Cake List 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 Sat, Jul 10, 2021 at 9:36 AM T H Panton wrote: > > > > > On 10 Jul 2021, at 17:15, Dave Taht wrote: > > > > tim panton wrote me just now on linked in: > > > > "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...." > > > > (so... chatting via email is preferred for me) > > > > 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 g= uise of > bandwidth estimation - The =E2=80=98simplest' is google=E2=80=99s REMB RT= CP message which basically > looks at the arrival time of packets and uses any _lengthening_ in the to= f to deduce the onset of > additional buffering in the path. Transport CC tries to expand this to ap= ply to all the streams muxed over a port > by adding an RTP header extension with an accurate (NTP) clock in it. thank you very much for this update. We can do MUCH better than ntp these days, gps being so common. > > The thing that drives design this is that losing a packet is catastrophic= for realtime video, > one dropped packet makes seconds (aka megabytes) worth of data un-rendera= ble. at least in my fq_codeled world, rfc3168 ecn is alive and well. It's just that marking and responding to ecn in the go library we are using (pion) is deeply buried. also SCE might finally take flight after the next ietf. It's easy to see fq_codel for the wifi chipsets we use overagressively attempt to drop packets for non-paced videoconferencing streams. (I never said fq_codel was perfect) I demoed that to juliusz a while back. Totally fixed if you mark at least the keyframes as ecn-capable. Even more fixable if sch_cake with its diffserv4 support is on the bottleneck path. > At 50 fps the frame interval is shorter than the roundtrip time on the pa= th (for VDSL users anyway - perhaps not fiber) > so a NAK/resend will fix it too late. In terms of the jamaphone across town I care mostly that the audio streams are perfect. Can lose a frame on the video here or there. But I groke we have issues here. Ideally I'd like to be running at 250 fps (4ms) which is like being 4 feet away from someone else in the band. > > So the strategy is to dynamically estimate the capacity of the path and t= ry to surf _just_ under that, ensuring minimal packet loss. I generally find enforcing the observed minimum via cake from a starlink, 5g or wifi link and staying there is best for videoconferencing apps, and it turns out low latency is often best for web and other forms of applications. Only if you are addicted to speedtest results do you need to care about bandwidth. > > I realise this is anathema to TCP folks, it certainly came as a shock to= me=E2=80=A6. to *most* tcp folks. Not all. RTTs are what a I hope an icreasingly high percentage will be caring about. > T. > > > > > My other fantasy is to somehow start using udplite for more things. > > > > 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. > > > > > > -- > > Latest Podcast: > > https://www.linkedin.com/feed/update/urn:li:activity:679101428493678592= 0/ > > > > Dave T=C3=A4ht CTO, TekLibre, LLC > --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC