Re: [AVTCORE] Framemarking in video packets Tue, 09 August 2022 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F38FC157B5C for <>; Mon, 8 Aug 2022 19:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_HI=-5, 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_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id de3zP-2KLBiZ for <>; Mon, 8 Aug 2022 19:43:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 920E9C14CF15 for <>; Mon, 8 Aug 2022 19:43:41 -0700 (PDT)
Received: from ([]) by with ESMTP id LEh8osnjFg8fXLFBcoUwbJ; Tue, 09 Aug 2022 02:41:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1660012900; bh=t0dQo7/GaWo3u7mc8g6+mjyGlLwLHlWWkyMrAlenYKQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZHBLJ0bwfPWlg8n8tM/FkZP2gO39SC5hgTyOSXh9BbwzMpRht5Nro6ozU5Ph+WaK/ ZNuYqJfRINqQAV0lDFm2eyEwqrHxj9Vjt26QaxANMPzwtaDVqrkS6NnKjI7E7Fmznl AjikABaHsoRSmsHjlV0eLXwpY8JPdv1wokrLZigsDp+JUgWufIvcOEYN8veFbl/FpY WWwIS+5+tRwFf54HlUNlm9NiOno+AOjH33zltvNXEsIEl6uNFSpnlyktwodN24iJjz z4ipwsFDTUvy5F5yFMaluoeT3mig3fMzCSKPTEbeGjzsiIzZtYqWY1RdU1Zx1X+Cli npkO064Pqt6Dg==
Received: from ([IPv6:2601:192:4a00:430::7b07]) by with ESMTPA id LFBaoAXrQ4zJQLFBaolKTh; Tue, 09 Aug 2022 02:41:39 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 2792fbGu428411 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 8 Aug 2022 22:41:37 -0400
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 2792fb7M428408; Mon, 8 Aug 2022 22:41:37 -0400
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: "shihang (C)" <>
In-Reply-To: <> (
Sender: (Dale R. Worley)
Date: Mon, 08 Aug 2022 22:41:37 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [AVTCORE] Framemarking in video packets
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Aug 2022 02:43:46 -0000

"shihang (C)" <> 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.