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

ken carlberg <> Thu, 11 July 2013 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A01921F9C6D; Thu, 11 Jul 2013 09:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pqbv-+O-XZ3S; Thu, 11 Jul 2013 09:05:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2916621F9F4C; Thu, 11 Jul 2013 09:05:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zZNnM09X3aVQDZwGbcmvuadW1XS1GoF3JpGeUovatK8=; b=h23GCqdPprhQ2OoEgPk6Uiego+EIVZUlpBS/FeyIE/NGNsSe64wCjQRNZgczw5Y3oWqJi8/3jgWMR1XX1qG2llpWqwm5zRlOwOqOr1lT7s9Eaz6qzfK1F0cD7dNIddpq;
Received: from ([]:37990 helo=[]) by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <>) id 1UxJMZ-003R6H-4J; Thu, 11 Jul 2013 17:04:59 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: ken carlberg <>
In-Reply-To: <>
Date: Thu, 11 Jul 2013 12:04:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.1508)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: acl_c_relayhosts_text_entry:|
X-Mailman-Approved-At: Mon, 15 Jul 2013 08:47:47 -0700
Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jul 2013 16:05:32 -0000


some food for thought...

about 10 years ago, I put together a draft that added an optional TLV prioritization header to RTP to accomplish something similar in terms of having the app decide which was the better RTP packet to drop during times of congestion.  My aim was to have these decisions made at forwarding application-layer gateways that did not act as a RTP/RTCP endpoint.  The strength of the approach (in my opinion :-) was that it could span pockets of non-diff-serv regions and still carry significance downstream.  The weakness was the need for DPI if one wanted to make a more informed decision along the path about dropping a packet.

I wonder if such a dual-layer design might be helpful in your efforts.  In any case, I have an interest in the normalizer draft.


On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) <> 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.
> 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.
> 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).
> 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
>  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 ;-)
> Thanks!
>    Toerless
> In-Reply-To: <>
> 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: [] 
>> 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:   
>> Status:
>> Htmlized:
>> 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,
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!