Re: [Dart] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt

[Michael Welzl <[e-mail]>]

On 21. juli 2014, at 13:08, Brian E Carpenter <[e-mail]> wrote:

> On 21/07/2014 14:00, Black, David wrote:
>> Karen,
>> 
>>>> What's the rationale for "certainly isn't viable" regarding different drop
>>>> precedences within a single SCTP session?
>>> [Karen] Ok - "certainly not viable" is too strong formulation.
>>> Having different drop precedences within the same SCTP CC context would,
>>> given that SCTP CC presently is drop driven only,
>>> results in that the whole data channel is impacted, from a CC perspective,
>>> by the highest drop precedence. But I realize that whether this is
>>> acceptable is a question indeed.
>> 
>> I think you're on to something here.  If the drop precedences only came into
>> play after the decision to drop a packet had been made, their effect would
>> probably be minimal, as they would only affect what to drop in a session, not
>> how much to drop.  OTOH, DiffServ AF is not intended to operate in that fashion
>> - the rationale for the 3 drop precedences per AF class was based on envisioning
>> the output of two-threshold rate shaper:
>> 	AFx1 - Within base or committed traffic profile
>> 	AFx2 - Beyond base/committed, but within excess or burst traffic profile
>> 	AFx3 - Completely out of profile
>> 
>> Hence the relative mix of those drop precedences can be expected to affect
>> the overall drop rate/probability seen in a session where those precedences
>> are mixed.
> 
> Yes. And it was clearly aimed at layered video, such that there was
> a benefit to the end user in dropping the least important layer
> during lossy periods. With anything like a TCP-like congestion
> control algorithm in sight, the effects may be completely bizarre.

Reordering could make this even worse. Could different drop precedences cause reordering?

Cheers,
Michael