Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: T H Panton <tim@pi.pe>
Cc: galene@lists.galene.org, Cake List <cake@lists.bufferbloat.net>
Subject: [Galene] Re: using up more ports in ipv6 for better congestion control
Date: Sat, 10 Jul 2021 09:48:50 -0700
Message-ID: <CAA93jw4c6h3TCqyBkxY5POoFEUN6Q4OiV3-qcJgQV=fHf4AVgA@mail.gmail.com> (raw)
In-Reply-To: <35ECF0D3-B549-4C43-868F-58021E7F2BDD@pi.pe>

On Sat, Jul 10, 2021 at 9:36 AM T H Panton <tim@pi.pe> wrote:
>
>
>
> > On 10 Jul 2021, at 17:15, Dave Taht <dave.taht@gmail.com> 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 guise of
> bandwidth estimation - The ‘simplest' is google’s 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.

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-renderable.

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 path (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 try 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….

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:6791014284936785920/
> >
> > Dave Täht CTO, TekLibre, LLC
>


-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

  reply	other threads:[~2021-07-10 16:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10 15:15 [Galene] " Dave Taht
2021-07-10 15:19 ` [Galene] " Dave Taht
2021-07-10 16:36 ` T H Panton
2021-07-10 16:48   ` Dave Taht [this message]
2021-07-11 11:19   ` Juliusz Chroboczek
2021-07-15 14:17     ` Sean DuBois
2021-07-16  1:36       ` Juliusz Chroboczek
2021-07-16 14:25         ` Sean DuBois
2021-07-15 16:26     ` T H Panton
2021-07-16  1:37       ` Juliusz Chroboczek
2021-07-16 14:46         ` T H Panton
2021-07-16 17:48           ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA93jw4c6h3TCqyBkxY5POoFEUN6Q4OiV3-qcJgQV=fHf4AVgA@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=galene@lists.galene.org \
    --cc=tim@pi.pe \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Galène videoconferencing server discussion list archives

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.galene.org/galene

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 galene galene/ https://lists.galene.org/galene \
		galene@lists.galene.org
	public-inbox-index galene

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git