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

[Harald Alvestrand <[e-mail]>]

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.