Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)

["Cheng-Jia Lai (chelai)" <[e-mail]>]

Yes, NM could also work with ECN (and it should be made so). In fact, we did implementation using WRED on routers that support ECN markings. If RTP endpoints support ECN markings, WRED will mark ECN instead of dropping the packets as avg Q size is between min & max threshold. But it still suffers from unfairness at congestion, where the avg Q size starts to exceed the max threshold for the lowest priority packet class...

We did experience a hard time trying to properly configure WRED parameters for preferential dropping of video packets with our NM implementation... It is a good insight you said here: maybe it is worth exploring how our work can perhaps use other AQM algorithms like CoDel, PIE, etc.

In fact, NM doesn't need specific AQM to drop by probabilities... it will be interesting to see how it can work with delay-based dropping. However, NM does require some "weighted" version of those AQMs. Hopefully a weighted version (if any) won't introduce new parameters (or too many) to configure the AQM.

Regards,
CJ


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave Taht
Sent: Wednesday, July 10, 2013 12:02 PM
To: Toerless Eckert (eckert)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)

On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert)
<[e-mail]> wrote:
> When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea
> that we think has shown to provide good value is to intelligently drop in the network
> preferentially the least important packets within a video flow, for example non-referenced
> P-frames, because their loss creates the lowest impact to video quality.

I've begun to look at webrtc of late in the context of fq_codel.

One thing that might work would be ECN marking important frames and
not ECN marking
others. Problem overall is that ecn can be gamed and is largely not
enabled, and so on...

> One of the main concerns raised against such schemes was one of fairness. If flows
> would start to indicate different priorities for packets in them, how would we
> be able to avoid that flows would indicate all their packets to be of high priority
> to shift packet drops to other flows. Or even more importantly: how could we motivate
> flows to indicate that some of their packets are low priority without them having to
> fear that they would experience more loss than than flows that don't do this.

same gaming problem...

> So, there is one draft that we would like to present (presumably in TSVWG)  explaining
> how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt
>
> (Actually, this is how we did solve the problem in our implementatin of intelligent dropping,
>  so this is not theoretical).

In the case of the fq_codel algorithm I can see a "delayed drop"
mechanism happening,
where upon deciding to drop, it could defer a drop up to a few packets
based on the classification
of the packet, say 3 packets at most. Since flows are already
identified, this is kind of easy
by adding another state variable...

At the moment what I have deployed and tested most is a simple 3 tier
fq_codel based shaper,
which has a priority, best effort, and background queue. The priority
queue is generally only DNS traffic,
the background is only CS1, and fq_codel does such a good job with
sparse streams in
the general case that for VOIP, etc on the networks I fiddle with,
there is no point in having
much more than the BE queue. And presently all other markings are ignored.

video is another story. (or could be, I don't know enough about
webrtc's behaviors to
"see" what will happen)

So I can see trying to utilize the AF markings as you describe in your
draft in codel's
drop decision. While this is also subject to being gamed, the
disincentives are slight.

This is a little different from using "drop probability" as the
decider, however, but I
would hope that this mapping of the old AF style random drop ideas
into the new style delay
ideas could work...

And what codel depends on is a definition of "TCP friendly". That if a
stream is not
going to behave in a tcp friendly manner, then an entirely different
strategy for such
flows seems necessary, and glomming on some additional state isn't going to
be the right thing.

> Now granted, the problem of fairness is but one element of building a complete ssytem
> around the idea of intelligent dropping, so if folks here on the lists would like to
> see for example
>
>   a) how well can it work in routers to shift packet drops to low-prio packets

I guess where I fall apart here is how to shift the encoders to send thinner
streams at  any level of packet drop.

>   b) whats the evidence that it's good for video quality
>   c) How should we do the marking best going forward

> Then please let us know. We'd be very interested to provide insight into the parts of
> those pieces that we have also worked out or discuss the ones we have not (primarily c ;-)

I'd be interested in specific codecs, example video streams, and test
scripts to try
and fiddle with this, as well as viable metrics.

>
> Thanks!
>     Toerless
>
> In-Reply-To: <[e-mail]>
>
> On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote:
>> Hi all,
>>
>> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments.
>>
>> Best regards,
>> CJ
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, February 08, 2013 6:25 PM
>> To: Cheng-Jia Lai (chelai)
>> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip)
>> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt
>>
>>
>> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt
>> has been successfully submitted by Cheng-Jia Lai and posted to the
>> IETF repository.
>>
>> Filename:      draft-lai-tsvwg-normalizer
>> Revision:      00
>> Title:                 Normalization Marker for AF PHB Group in DiffServ
>> Creation date:         2013-02-08
>> WG ID:                 Individual Submission
>> Number of pages: 15
>> URL:             http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer
>> Htmlized:        http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00
>>
>>
>> Abstract:
>>    This memo describes a Normalization Marker (NM) at DiffServ (DS)
>>    nodes to normalize the distribution of DS codepoint (DSCP) markings
>>    for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group.  NM is
>>    useful for traffic conditioning with Active Queue Management (AQM)
>>    when the AF PHB group is deployed for multimedia service classes that
>>    carry video packets with advanced codec technologies.  Using NM can
>>    offer an incentive that is however missing in today's ecosystem of
>>    practical deployment, i.e., when congestion occurs in the AF PHB
>>    group, the network should allow a video codec to benefit from its
>>    effort of generating finer layers of intra-flow precedence (IFP) with
>>    discardable packets in a more balanced distribution.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> --
> ---
> Toerless Eckert, [e-mail]
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html