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

"Toerless Eckert (eckert)" <eckert@cisco.com> Wed, 10 July 2013 18:02 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A863921F9D50; Wed, 10 Jul 2013 11:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.487
X-Spam-Level:
X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHCH52Ixpan8; Wed, 10 Jul 2013 11:02:30 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39CE921F9DBC; Wed, 10 Jul 2013 11:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4297; q=dns/txt; s=iport; t=1373479350; x=1374688950; h=date:from:to:subject:message-id:mime-version; bh=4Krnakf2c8xhkFVZQbRn1doD4IUXOzkoPjHFhN9iwgA=; b=R8fvfXei5wYryAYq4/WluL2Lv8z2e3SARqJckvk5pxEivA28wqXSNDRz xdH07wdrnQkCDjhhcse4zdm2N1g5GmY8JZHKQQVHbpGfWKxLQExb/wsDH 90+AqnA62aqy6PYvs0IPhSZfBinWfwpPZ/acgoHJrrks+l2MFSTEhm4hs A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai4FAE+g3VGrRDoG/2dsb2JhbABagwkywWyBExZ0giMBAQE+KyAgAQMBAQEJGgQWBTIDBg8SCYgFDbdjj3CDA2wDiSWOMQGBKZAhgViBWRw
X-IronPort-AV: E=Sophos;i="4.87,1037,1363132800"; d="scan'208";a="82622009"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 10 Jul 2013 18:01:48 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6AI1lK7023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jul 2013 18:01:47 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6AI1lCI001615; Wed, 10 Jul 2013 11:01:47 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6AI1lVi001614; Wed, 10 Jul 2013 11:01:47 -0700
Date: Wed, 10 Jul 2013 11:01:47 -0700
From: "Toerless Eckert (eckert)" <eckert@cisco.com>
To: tsvwg@ietf.org, rtcweb@ietf.org, rmcat@ietf.org
Message-ID: <20130710180147.GA614@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Subject: [rtcweb] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 18:02:34 -0000

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: <A860EC86B79FA646BF3F89165A886264151D0AB9@xmb-aln-x11.cisco.com>

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> 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, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!