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

[<[e-mail]>]

Toerless,

discussion seems to conclude with:

- fairness must be enforced if senders don't set DSCPs according to the global
  fairness scheme.
- video applications have a hard time setting DSCPs anyway due to a missing API.
- ECN is not meant to indicate drop priorities and offers an insufficient
  number of states.

It might be easier to use a single PHB/DSCP and add PCN like ECN. In an e2e mode with receivers giving PCN congestion feedback to senders. My definition of PCN would be "rate control on a congested link" (rather than admission control and traffic termination as applied by the WG - I've been involved in the WGs work).

This should result in:
- avoidance of sudden overload in that class (no burst drops)
- rate adaption of senders if congestion is pending
- a simpler design as compared to what you and Ken discussed

I'm going to drop another message soon.

Regards,

Ruediger

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Toerless Eckert (eckert)
Sent: Friday, July 12, 2013 3:00 AM
To: Dave Taht
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 12:02:26PM -0700, Dave Taht wrote:
> 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.

True. But i think there are at least 3 layers of priority that would
really be great to have: really important packet (long term reference
frames), "normal" packets, and low-proirity-packets (eg: discardable P).
And ECN could only do two.

Most of the time when you would want intelligent dropping, your drop
rate should be fairly low, eg< 20% instantaneous within the queue. If
you can do discardable P-frames it's of course best to drop those first.
Only when you instantaneously have really big bursts would you want to
drop "normal" packets and refrain to protection really important packets.

This does work really well with different queue-length (or WRED profiles).
If you only had two priorities (via ECN) it's hard to say how you
would best assign these two priorities to at least those three priority
levels.

> Problem overall is that ecn can be gamed and is largely not
> enabled, and so on...

Well. The gaming could be inhibited exactly by this draft because it
would try to guarantee the same amount of drops on a per-flow or "class"
basis, so if you're trying to game the system, you would be put into
your own class and would still see the same amount of drops as other flows.

Well, the main issue is really to redesignate ECN for a different
semantic than what it has today. And indicating packet priority is just
not quite the same as congestion feedback.

> 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...

Yes, this is all quite interesting. We also played around with droppping
during enqueuing vs. during dequeuing, so there are a bunch of things
that could optimize intelligent dropping if you can build a more
intelligent queue.

[...]

>
> 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.

Lets separate the marking from the mechanism to inhibit gaming. This
draft really is about the latter, and the marking described with AF is
really just an example. Yes, it would be lovely to agree on markings
too.

> 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.

Who stood up at RMCAT some time back and claimed to have worked for
> 10 years on TCP and declared TCP not self friendly to itself, so RMCAT
shouldn't bother ? ;-))

Kidding aside: Intelligent dropping IMHO makes perfect sense when being
applied to RT traffic sharing a queue friendly with TCP. And intelligent
dropping can then still improve the performance.

I am pretty positive though that RMCAT traffic in general will behave
better and get lower delay and more video-appropriate loss if it can have
its own queue. Primarily because it will just take decates to root out
all the bad TCP traffic.

I don't think that the strategies if you do or if you don't share the queue
with TCP would be fundamentally be different.

> 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.

Video codec coders are known to be able to do crazy cool things.
There are a bunch of known mechanisms and probably more proprietary ones.

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

Sure. Best done in person. If we're going to be at the WG for this, we can
talk on the side how we've been doing this.

Cheers
    Toerless

> > 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

--
---
Toerless Eckert, [e-mail]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!