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

In practice, many enterprise networks do their own policing/re-marking, so
browser-enforced bandwidth limitations may bear no relation to corpnet
policies.  For example, an enterprise may have its own policies on what
traffic should be marked "high priority" and how much bandwidth it should
be allocated.  As a result, the traffic marked by the browser with a
particular DSCP might be re-marked and different bandwidth limits might be
imposed. As a result, traffic that the browser would chose to drop due to
its own limits might have been allowed to pass through, and traffic the
browser would not drop might be dropped later.  In these situations, it
probably makes more sense for the browser just to mark traffic and let the
enterprise network re-mark and impose its own bandwidth limits as necessary.

On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter <deadbeef@google.com>
wrote:

> 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 <harald@alvestrand.no>
> 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.
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>