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

"Cheng-Jia Lai (chelai)" <> Thu, 11 July 2013 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A64A711E81B8; Thu, 11 Jul 2013 15:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OkV7TGImtcal; Thu, 11 Jul 2013 15:12:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 878A121F9F71; Thu, 11 Jul 2013 15:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7145; q=dns/txt; s=iport; t=1373580768; x=1374790368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NUnOPGj7zzwp20P6uiTxzgY1YkvIZDpAnv+QSQYKbiQ=; b=eEwnJIK47h+N2O6rxImHnqu8lXo6APSzs0CINzpwp3jItXvh3omTgvwv cBhkJAk/ho1nyOVMTzPcptmSA/qv0smcJo3IZOfxtruR9sDMKzpCQuj7H lvGm1w7Ch+rmjbemK6wT+Uvdqegz+Asewa4f5oJYVvhYBUvfzym0n2Ynm k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="233612568"
Received: from ([]) by with ESMTP; 11 Jul 2013 22:12:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6BMClOL011042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 22:12:47 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 17:12:47 -0500
From: "Cheng-Jia Lai (chelai)" <>
To: ken carlberg <>, "Toerless Eckert (eckert)" <>
Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)
Thread-Index: AQHOflB/BP/LxZhvSUuqg6JURoTBKJlgAPVA
Date: Thu, 11 Jul 2013 22:12:46 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
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 22:12:53 -0000


Thanks very much for the comment and showing an interest in our draft.

Yes, I agree it is beneficial if the intra-flow priorities info can be carried in some bit field other than DSCP markings. I guess we need to better clarify that NM is not necessarily specific to AF PHB but potentially applicable to other service classes. (In fact, our implementation did try DPI in RTP and H.264 NAL unit header for that, with some limited overheads in packet processing.)

We know there can be a lot of intelligent ways to carrying priorities in packets (e.g. your TLV in RTP hdr) which are likely beyond our knowledge and expertise, so we just introduced the CB mode in Section 3.1, quoted as follows:

"When NM operates in "color-blind" (CB) mode, which is optionally
   supported, it reads certain bits field(s) other than the AF-markings
   in the packets to determine the actual drop precedence of that
   packet.  This implies that NM may need DPI in the packets, e.g.
   parsing into H.264 AVC header in each RTP packets, or alternatively
   use some method where the drop precedence is carried from the encoder
   in a customized bits field other than the AF-marking in each packet."

CB might not be the best name... sorry if confusing. Anyway, we hope this allows NM to collaborate better with video endpoints.


-----Original Message-----
From: [] On Behalf Of ken carlberg
Sent: Thursday, July 11, 2013 9:05 AM
To: Toerless Eckert (eckert)
Subject: Re: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)


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!