[AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension

Roni Even <roni.even@huawei.com> Thu, 18 May 2017 09:17 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6FD129B28 for <avt@ietfa.amsl.com>; Thu, 18 May 2017 02:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSyrEZ7PLE2T for <avt@ietfa.amsl.com>; Thu, 18 May 2017 02:17:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D3F129B2B for <avt@ietf.org>; Thu, 18 May 2017 02:12:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNH07552; Thu, 18 May 2017 09:12:08 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 18 May 2017 10:11:34 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.49]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Thu, 18 May 2017 17:11:29 +0800
From: Roni Even <roni.even@huawei.com>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Adding information to draft-ietf-avtext-framemarking non-scalable extension
Thread-Index: AdLPtmQIVl+AIPLPSRetVeYcA2dzZg==
Date: Thu, 18 May 2017 09:11:29 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7CC6EA@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.201.202]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD7CC6EADGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.591D656B.00C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bede08879e482f5afcf28eecaa11f0a1
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Op5x4zZt0aSdsQFju7rAEUw5xfY>
Subject: [AVTCORE] Adding information to draft-ietf-avtext-framemarking non-scalable extension
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2017 09:17:30 -0000

Hi,
The current support for non-scalable frame marking provide limited information for making good decisions about which packets to drop in congestion case. Currently there is only 1 bit for marking discardable packets.

I propose using three of the remaining  four bits (currently 0000) with the following semantics:

Low motion bit (M) - specifying that this stream or the current packets have low motion (example - a conference room meeting ), removing them will just reduce the frame rate with less artifacts comparing with a live video of a basketball game.
Priority (P) two bits - allowing to prioritize frames in a stream. For example if we have a sequence (IBBBBPBBB...) even though all B frames may be defined as discardable, they may have different relation to the other frames and by using priority we can make better discarding decisions.

The way it may work for example  is that when there is a need to discard packets  the middlebox will choose from the discardable packets the ones with low motion and low priority and continue dropping low motion and higher priority. The dropping policy should be implementation dependent.


Roni Even