Re: [AVTCORE] Framemarking in video packets

worley@ariadne.com Sat, 20 August 2022 01:22 UTC

Return-Path: <worley@alum.mit.edu>
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 15682C1524CC for <avt@ietfa.amsl.com>; Fri, 19 Aug 2022 18:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.99
X-Spam-Level:
X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 DE6t9qTBnY9A for <avt@ietfa.amsl.com>; Fri, 19 Aug 2022 18:22:17 -0700 (PDT)
Received: from resqmta-a1p-077721.sys.comcast.net (resqmta-a1p-077721.sys.comcast.net [96.103.146.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A109C14F720 for <avt@ietf.org>; Fri, 19 Aug 2022 18:22:16 -0700 (PDT)
Received: from resomta-a1p-077060.sys.comcast.net ([96.103.145.238]) by resqmta-a1p-077721.sys.comcast.net with ESMTP id PD0lo5yrdjfy9PD9qoec3P; Sat, 20 Aug 2022 01:20:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1660958414; bh=eTEXIKf1mlRWeXGahP1oS4I1c4pkKsBFsfJMSdxOEFA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=SgdR8LL1vexOYGYNQkFxeIoz2iRqV84UNeesYiIEmRxJKRusb3AxBECU9hwjbPQUV mUAe6hMpTh+hUqsF5o+HU9x7aEqp8P+41JAdxKqEt/yB+Q+z+JcqJp/oLTg9+zibLi 3vte3E70TSRaDRIyR9NTnNLHiY6QakWHOKI2M7wfJzcbOxPWIk/Srh0zi9+CRnr10H 4E6cJNYsR+mFdvg3/oo9pkstYwjdzg2NpPVhOKaXso5tgkEPNZYv8/yBuyUHNy81iA zDvM7u98ewMD5aMIB+WGKCFlxYj15tdb5kxokQpz+XGvb6Hy6oIpC6NMLXFDns0TH3 p36+fpuVmQbag==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::24cb]) by resomta-a1p-077060.sys.comcast.net with ESMTPA id PD9noO4iBJiB8PD9oomvIK; Sat, 20 Aug 2022 01:20:13 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 27K1KBTB1873610 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Aug 2022 21:20:11 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 27K1KAYL1873606; Fri, 19 Aug 2022 21:20:10 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: "shihang (C)" <shihang9@huawei.com>
Cc: avt@ietf.org
In-Reply-To: <f18669643f9841d595611c28891cfd42@huawei.com> (shihang9@huawei.com)
Sender: worley@ariadne.com
Date: Fri, 19 Aug 2022 21:20:10 -0400
Message-ID: <87sflr90dx.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/kziZxJW0GYFRk2L6USscLFizFxE>
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: Sat, 20 Aug 2022 01:22:22 -0000

"shihang (C)" <shihang9@huawei.com> writes:
> 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.

The proposal is that the frammarking header extension would immediately
follow the flag header extension, so there is no need to record the
offset.  Thus the "flag data" would be a fixed value.  That would allow
the four bytes (flag ID, L, flag data) to all have fixed values.

> 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. 

The difficulty with that strategy is that it requies that the router be
able to determine which packets contain RTP and which do not.  But
there's no reliable way to detect that.

Dale