[Galene] Re: about packet pacers

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

I was terribly busy when this thread went by.

On Fri, Aug 6, 2021 at 4:01 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> >> Toke, would you have some input regarding this:
> >> - do you think that in this use case monitoring a pacer with the target
> >> bitrate would have real added value?
>
> > Hmm, so the idea here would be that we know the bitrate of the stream
> > from the codec setting, and from that we can compute the packet-level
> > bitrate (by adding the packet overhead) and pace out the packets at that
> > rate? [...]
> > One question is whether the codec can be relied upon to stay within a
> > certain bitrate and over what timescales?
>
> No, but we know where the current frame ends, and we know when the next
> frame is due.  So we can spread the current frame smoothly over the
> interval between the current frame and the next one.  That will break when
> we get variable frame-rate codecs, but we'll cross that bridge when we get
> there.
>
> This is not what the GCC draft recommends[1]: what they suggest is to
> consider the target bitrate (the one that the congestion controller yields)
> and send a burst of up to 5ms*rate every 5ms.

That draft is old, and I don't know the right answer, but I'm pretty sure that's
not the right answer.

> [1] https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02#section-4
>
> > On Linux you can use the SO_TXTIME socket option to get the kernel to
> > pace the packets for you; but that only works if there's a qdisc
> > installed that can handle the pacing (such as sch_fq), and it's hardly
> > cross-platform, so dunno if that will work?

I would like to try this - as the simplest possible implementation to
experiment with.

>
> I'd rather we did the pacing in the application, since that will allow us
> to drop packets more selectively: if we drop a packet due to congestion
> control, then we want to continue dropping until the end of the frame.

To be clear this is when you are dealing with galene being internally congested,
blocking so much on write that it needs to drop a frame?

> What's more, both the VP8 and VP9 codecs can be configured in a mode where
> they regularly schedule a "droppable" frame that is not used for
> intra-prediction (it's part of the simulcast implementation).

oh, excellent. Are you using this at all at this point, to probe for
more bandwidth.

>
> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC