Re: [rtcweb] Issue with "priority" defined in rtcweb-transports

[Taylor Brandstetter <[e-mail]>]

I think the issue is that the example leads you to get the wrong idea about
what the priority is intended to effect. Does it affect encoding, or just
transport? Is the advice meant to say "give the codecs a 1:2 split of the
available bandwidth"? Or "give the codecs some split of the available
bandwidth determined elsewhere, then as packets are queued for
transmission, send them with a 1:2 weighted round-robin scheme or something
equivalent"? I interpreted it as the former. It may just be that I'm not
interpreting this as intended, and there really isn't an issue, other than
possibly needing some clarification.

On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand <[e-mail]>
wrote:

> Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
> >     For instance, screenshare-type video varies enormously in
> >     bandwidth (very low at static images, enormous at slide change) - if
> it
> >     competes against audio, a "relative" bitrate ratio will not be
> useful at
> >     all.
> >
> >
> > I think that's where it's important to get the terminology right; for
> > example, rtcweb-transports uses the term "capacity", which implies that
> > it's possible to use fewer bits than the capacity. Maybe that's the best
> > way to think of this. We also can allow some implementation flexibility.
> >
> >     Is there a way we can punt this?
> >
> >
> > If we do punt this, I still think we should remove the part of
> > rtcweb-transports that talks about the priority causing codecs to be
> > configured with send rates at these 1:2:4:8 ratios:
> >
> >        o  When the available bandwidth is known from the congestion
> control
> >           algorithm, configure each codec and each data channel with a
> >           target send rate that is appropriate to its share of the
> available
> >           bandwidth.
> >
> >
> > We should make it clear that the priority only affects the delivery of
> > packets (pacing decisions, QoS, SCTP priority), and not how the packets
> > are generated upstream. Assuming others agree.
>
> The words about configuring the codecs were intended as advice - most
> codecs are terrible at dealing with random lost packets (even with FEC
> and NACK and all that), so if the pacer is going to throw their packets
> away, the best thing to do is to not generate them.
>
> (Hierarchical coding schemes with frames that have no references to them
> work fine as long as you throw away complete frames, though. So
> sometimes it works.)
>
> This section is already headed with the words "Two example
> implementation strategies are:", so it should already be clear that it's
> advice, not normative language.
>
> I'm happy to weaken the words even more, but wouldn't want to lose the
> advice entirely.
>