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

[Taylor Brandstetter <[e-mail]>]

Bernard, I think you're describing a situation where the flows would (or at
least should) use different congestion controllers, but this guidance is
for "[w]hen an WebRTC endpoint has packets to send on multiple streams that
are congestion-controlled under the same congestion control regime".

Also, a sidenote: I'm realizing now that we probably don't want to use
RTCPriorityType to indicate which simulcast stream should be allocated bits
first. That's still mixing up QoS with something that should be
independent. Could we use the order of the RTCRtpEncodingParameters list?
If their order in the list determines the order of the RIDs in
"a=simulcast", then this already indicates preference. JSEP doesn't
explicitly say how the order is determined, though.

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

> Throwing away packets at sender is only supposed to happen at all after
> congestion is detected. The idea is that the sender can do a better job of
> deciding what to discard than the router can.
>
>
> Den 18. oktober 2017 01:23:06 CEST, skrev Bernard Aboba <
> [e-mail]>:
>>
>> 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 <[e-mail]
>> > 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 <[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.
>>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>