[Galene] Re: using up more ports in ipv6 for better congestion control

[Dave Taht <dave.taht@gmail.com>]

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