Re: [AVTCORE] Framemarking in video packets

"shihang (C)" <shihang9@huawei.com> Wed, 10 August 2022 11:26 UTC

Return-Path: <shihang9@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 0043DC138FA7 for <avt@ietfa.amsl.com>; Wed, 10 Aug 2022 04:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOxXlpJdB5VC for <avt@ietfa.amsl.com>; Wed, 10 Aug 2022 04:26:54 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2C1C138FA5 for <avt@ietf.org>; Wed, 10 Aug 2022 04:26:54 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M2nbH4jX0z67KQt for <avt@ietf.org>; Wed, 10 Aug 2022 19:22:19 +0800 (CST)
Received: from dggpemm500017.china.huawei.com (7.185.36.178) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 10 Aug 2022 13:26:51 +0200
Received: from dggpemm500017.china.huawei.com (7.185.36.178) by dggpemm500017.china.huawei.com (7.185.36.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 10 Aug 2022 19:26:49 +0800
Received: from dggpemm500017.china.huawei.com ([7.185.36.178]) by dggpemm500017.china.huawei.com ([7.185.36.178]) with mapi id 15.01.2375.024; Wed, 10 Aug 2022 19:26:49 +0800
From: "shihang (C)" <shihang9@huawei.com>
To: "Dale R. Worley" <worley@ariadne.com>
CC: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] Framemarking in video packets
Thread-Index: AQHYq5mLX+LnqAe11UC+IZCff4s4t62l7ULA
Date: Wed, 10 Aug 2022 11:26:49 +0000
Message-ID: <f18669643f9841d595611c28891cfd42@huawei.com>
References: <c014bc07810e4810a0bb414b92558b56@huawei.com> (shihang9@huawei.com) <877d3i16la.fsf@hobgoblin.ariadne.com>
In-Reply-To: <877d3i16la.fsf@hobgoblin.ariadne.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.128]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/QetS-ANXBjlDuieTkSrDhKwZRSI>
Subject: Re: [AVTCORE] Framemarking in video packets
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 10 Aug 2022 11:26:57 -0000

Got it. 

   For "one-byte" header extensions:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0xBE    |    0xDE       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |flag ID| L=2   |     flag data                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ID    | L     | framemarking data ...                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   For "two-byte" header extensions:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x100           |appbits|           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | flag ID       |     L=1       |     flag data                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ID            | L             | framemarking data ...         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>From the extension format you give, the 32 bit also contains ID, length and value, just like an extension header. The difference is that the ID is a fixed global value instead of a local value negotiated by SDP. It looks like creating a special purpose header extension entry which identify and locate the framemarking extension.
I wonder if 16 bit is enough unless you want to put some data into the flag data field such as the offset of the framemarking extension header.

> I suppose we could propose that, *if the sender was to use framemarking according to the proposal* it would have to use a particular extension ID.  But that doesn't suffice for my purpose, which is for a router to be able to (1) determine which packets are according to the proposal, and then (2) be able to isolate the framemarking extension easily.  The reason is that even if we declare a fixed global ID for the extension, that is at most a 16-bit fixed value to be searched for in the packet, which would have a lot of false positives for the identification step.
The router can recognize framemarking with a fixed global ID by iterating the list of header extensions until a match is found. In this way, there will not be false positive. To reduce the iteration overhead, we can force the framemarking extension to appear on the first one. 

Best regards,
Hang Shi

-----Original Message-----
From: Dale R. Worley <worley@ariadne.com> 
Sent: Tuesday, August 9, 2022 10:42 AM
To: shihang (C) <shihang9@huawei.com>
Cc: avt@ietf.org
Subject: Re: [AVTCORE] Framemarking in video packets

"shihang (C)" <shihang9@huawei.com> writes:
> Are you suggesting that we modify the RFC 8285 to reserve a global ID 
> for framemarking extension? By using the fixed global ID, you remove 
> the signaling process when using the framemarking extension, right?

I don't have a truly solidified proposal.  I suppose we could propose that, *if the sender was to use framemarking according to the proposal* it would have to use a particular extension ID.  But that doesn't suffice for my purpose, which is for a router to be able to (1) determine which packets are according to the proposal, and then (2) be able to isolate the framemarking extension easily.  The reason is that even if we declare a fixed global ID for the extension, that is at most a 16-bit fixed value to be searched for in the packet, which would have a lot of false positives for the identification step.

The novel part of my proposal is that it supports the router being able to identify many more layers of the video stream than would be possible with a single AF-set of DSCP codepoints, and it does so by providing a way to insert a global, fixed 32-bit value that shows where the framemarking extension is.

Of course, there may be better methods.

Dale