Re: [dispatch] Draft on Discarding Priority of RTP Video Packets

Lijun Dong <lijun.dong@futurewei.com> Fri, 22 July 2022 16:50 UTC

Return-Path: <lijun.dong@futurewei.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41934C1388CE for <dispatch@ietfa.amsl.com>; Fri, 22 Jul 2022 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 FbnaISoEZprF for <dispatch@ietfa.amsl.com>; Fri, 22 Jul 2022 09:50:51 -0700 (PDT)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2118.outbound.protection.outlook.com [40.107.212.118]) (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 4C1E6C14EB1E for <dispatch@ietf.org>; Fri, 22 Jul 2022 09:50:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UxPCnznBf5yy2hCSzjNCObnk2XLjbZd+Xz03b4eVnSORnTMaTvS7WM4F46sSApvrrKXo70BzB8sG+o5qkkChZ4PM5EJ/Jsft3/2aDgEM2THlp8txz8yR8founjgaLgVz6scOSUktY9cl/B1hs7jOjFP/CBAs0vs1WUP4CQ9ukB0owwh4UQ+rblUqT1XjApayZJJtN1QCUuNjgN8BVcHXHm5WZ4Iz8giRolwCrzACrzmqBHtEuRlnN/p1cMVr3R1bzTlqIAZ69b8VFIyQSsgqfywmG1pqMHtOT1x/ai6MSmKkwl3QsTQyBnIYf1zmbt3rl0xWMSCzX/T/pjl4y9KV2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C4R8BDd0AzabFJSo6LWtQZh6KMUunRRjBK3SZbpAMuc=; b=Rte1euzDw6MTSsR93iu0TAgWmiJNOmmpB09X7D+Ox0SmOjZ9LRUJrEjSg1YAL0W5HQgxHbLOOZRfG2Ck/TDwhsH8t0BI31Jjb9IHuGOF+keRvg7+gzXWzksWi6lQsHBGiqCbqDe8etyDRi72vFbSdvmKqpEeUfQpvkdHXmmX8bYLCpOSd/MDAvl48CuWZvvcxm2EzD7GgF6Rok9MN/+MAtWNalD+/kHlnTyJYXRpTg/n4VAi2dBdsGz31w90FMPxfdWuLHT8/MsHU0TSe/axHB4yROBZIro1O7VN5hHP8esiviXyNRSG73rc8qvA9VGCWGBevRSdRg0Bd5XZq1a1dw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C4R8BDd0AzabFJSo6LWtQZh6KMUunRRjBK3SZbpAMuc=; b=MEvJEUxfT9DcAMvKCcedYihm0lq4rGCgltxvNkvCAGEcIhtMunjCSKhSOUyxI4UEMfXRDYR7bp1B9TmFwPrUoTh4p5OyY/p4f4fDcSircu+BLApiBe2ksXA7Dte+QZOucNwWreSOsjSSmO6IIUQ7ZiXiwiXFIvQkbHXFGf9W8gM=
Received: from BY5PR13MB3491.namprd13.prod.outlook.com (2603:10b6:a03:1a8::12) by BY3PR13MB4865.namprd13.prod.outlook.com (2603:10b6:a03:36c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.1; Fri, 22 Jul 2022 16:50:46 +0000
Received: from BY5PR13MB3491.namprd13.prod.outlook.com ([fe80::21a4:28b9:927a:9727]) by BY5PR13MB3491.namprd13.prod.outlook.com ([fe80::21a4:28b9:927a:9727%7]) with mapi id 15.20.5482.001; Fri, 22 Jul 2022 16:50:46 +0000
From: Lijun Dong <lijun.dong@futurewei.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "dispatch@ietf.org" <dispatch@ietf.org>
CC: Stuart Clayman <s.clayman@ucl.ac.uk>, Muge Sayit <mugefesci@gmail.com>, Richard Li <richard.li@futurewei.com>
Thread-Topic: Draft on Discarding Priority of RTP Video Packets
Thread-Index: AQHYlktSPMI6bAI7k0KoM/nyaaAHya2EDn8CgAYl8gA=
Date: Fri, 22 Jul 2022 16:50:46 +0000
Message-ID: <984B7166-4090-448F-8450-462669D12448@futurewei.com>
References: <00C16072-6D43-44AB-AEFC-3A586DA28804@contoso.com> <PA4PR07MB84146F9BA13E899BF3807CD3958C9@PA4PR07MB8414.eurprd07.prod.outlook.com>
In-Reply-To: <PA4PR07MB84146F9BA13E899BF3807CD3958C9@PA4PR07MB8414.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 513ba3f6-47d5-4171-1a74-08da6c02533b
x-ms-traffictypediagnostic: BY3PR13MB4865:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: C+b5yv+5ResyNR0G+O5p1On9bkImlQJwaBTfSH1ojVMKAKMSNJa3Xl+WAldVJ3cZS9+j43+hMFj0oO/nppTs7nsmHduT1ENwnB2y7AoZKSY1HaLLaosToPKsKIp9aJVjd6hoUz8A14CPD7gr562dVZbw+EvO9PH5OzRiP+4E1stnwam5f2hB+K08F5wu3XYGpODB7+rKy758HkDqPCLASgy6gtc8AP20gILwVzrhWyMoc3UFVym0DPLyLLIwRuBw80lmkX4gLX3P+YthC/QF99Khh2qHVMXKhWCw50DO3VGWJKwJyAxE9B/rZxXi8GPsrw+IwPKMlLKzIGfh5DcA1bLgNSu8JQk8IPc8RIC18P0jHdp/SaWr1XtFNlt+zGDAP449vvd8RvXlB2XkTaQCcL1j/0Kk8dmIA3QXN7hCc++ynGpm6/KxyKH+T3m0TOMkM2EGSGEiz1QAxHGNRfyRQ/KA7SvZlGCXe048YkavlzgFEjf6M+U3iTuTF1N/KLoJQyY87ibRHpDLeEiuKCTzNZeBxD5HSDVA7Ajy7EC0+a1y2kIum/L1ZjX0DWK+KAbcZxHzZnl1g62oTtHc68+mkcvIpZanJf6DW7GmGqo4ZVMNyDU3qc8AnqX29848OyTy0KRFgsAKn4e9uHWso5otQTzXZPadJW6ISHxC3DG6bpUj+J/WU3l9FXVvjXv5UV3c5djlNo1PKI73/NvMrs1a6pEb4e6YF3CAQJialStaBqKghsLbINgYZ2m8Qaibvurn3YfgARyHbXfzK98rpOG/9jy/dgCp/OC29ibEWc1LV2inKfH0eMda/Ur00vjn1b3U0F59ezVwOIGY6cLRwof/Lo4pX78JxMg9rPS3HIx9GUKXA4Paa6jUpIWXOHlNj7LWVT0jAFxNx4ZjKR2DysPWHYjMWc04CTVg1niFw4HpwD1LfZeEmVvWXjk08BCK3/z/
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3491.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(136003)(366004)(396003)(39840400004)(346002)(38070700005)(8936002)(166002)(38100700002)(26005)(122000001)(107886003)(186003)(33656002)(86362001)(2616005)(110136005)(53546011)(966005)(478600001)(83380400001)(6486002)(6512007)(54906003)(36756003)(6506007)(316002)(66476007)(66946007)(76116006)(66446008)(4326008)(5660300002)(8676002)(64756008)(66556008)(2906002)(41300700001)(44832011)(71200400001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: FCwtBqiVXDq09wBEFcWhiQdLZvH3w6WJV5yqs4bTaX7bIsF1XT/Wx66cfuU5X62A+mURdBzVMO28jIH/qcT41x0O42bEMqDmv8KWYGkEJ13UviVhqLvkPCqNYpiOHOSyUS3dlpdLKHHLKeuMebqkJhU07Nm3ejUdjkAx8NXMmkjdyKFqtk5LEz0evQHmS3+FHBBeu/9UFVq3oIVbwEhCiXok7P3qyDofeSfuGM8DXrfyK2vdpQb7RGqsrSTNqXvCBzPGzmwB5UZDPqxNL7ABL2XbSSWtyknvRlTrHwzUB/wzc7xXisvE0MpvsoYjza6i9wp4rMgZPlrl2RNQtt/h3u/Fn7Q31B8p8eEQNTwqr2ZUd+n9ukm8N8hdMV46r7bMsJxKmLM1QD7KIP2/NW/gTwzNMi8JN20egPKHIcJanaCTWq27BIy+B/kfxpuyO+I3ocWL+1zOaD28X24TfBrmMtXtVW3oHE0nbumFkMvBf8yPhxObdARJdRypSxXqHdjTzsIPfp7O36NWmSdUYkp1HGLRAtM5QFKXn5aJcDLxaB3OGP7sksljL6OpsWRoFj2yf/sfaoiprTfHbr39STd+6tfiWXQxgMNm5jr5u+Q31cTwy4B2181D1lS9BPI7HW1PbM2UjUda1FFUXwalj1jJ6pmOYBHBtbJKP5VnfFph8otwssX110YWJ3O5+sCZCCpw/5kphOXS4776wRc1RfEg1iCh7hR5VJEbBVClZJhfY+s4fOzsnfpDmURZM+ZzVUud1WCTQnMsRYBgv1//+XUe19lGQBbDJhNPazZEe0wm+rhlkNXfIUjuOIRjrnkOn18hkeZ3e4wK8++dEvqJahKdz4S4VINT0uNK3QTm2QUETj6UVb/dQAnecYyqctD+rv4BpBIQr9m5bpUcy8Fr9Za8epFsQwrU+OJRQMlQvg+7qmzgqdi64GM/yKhs6vkM1vaiUWtoKgJJGdejurgnClZLVNmQz+ptbmVQUKmOn/kw42UZ4K8xo4YqgTDkLpuPGYqLfGqrm3XKxjJzXA+7vMcQSvcaCATHnS0AhLAeiinPqmHa3r6Vwaf/hWTzFtO1RphjBSQ65Keg4pwMsFik+7QdyShvjwPEudsNWOZXN9vKgqG+uilzWz3newJkUoiHhCRTPQBD6F/JDm69EOXZb2RwEpEUIckwl0pajBpmw/rotCAy9/gSkCDDyeEpTwF8icyRnPJPI1041WO1w1cnR8297xkpwJJX3+2B72x9npM/2gGQNYlCRzhD+/+och9/AkCWLF+EfK1IM+mefl+Ltm083nKIsdxCr3Vvu+LXsEyb+Bd2vk8f6CDRxEhB0x3obAeM1m3PwWCQQ8GZ4/9A0p78DJ2XZrwHvyZlFYDR73lzdDyBwHK68x94AUbJ2NJ7p7RePZII3MyAkFtnQuIVQLAwguOiCjojC7Tg9qEBPqzXUy+3asUwv+EfIYvcIRnVDg8WCpZZdpd9N7pVT/MJd+OMKgMSKGuIexgIwXGMRbJ1rufsznvpSApCvMVobjvnYVrFPLxcEu3DkGKO5+m7r2s0KlcVkRPvEtkffIX2fML9jbyJKj3zoM1U2iH2C6fLHD/a
Content-Type: multipart/alternative; boundary="_000_984B71664090448F8450462669D12448futureweicom_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3491.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 513ba3f6-47d5-4171-1a74-08da6c02533b
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2022 16:50:46.7838 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jV/avQYuZHD6EnUAYmzfkTxGRHeQEBa0ww9oKS7LC522KHH8tgRpA8O5OOZOQlLUQPnIG8jBH7LQ8ZFmXBfb3A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR13MB4865
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/1BX-PZv0Mnf54583o7PlJA5h4NQ>
Subject: Re: [dispatch] Draft on Discarding Priority of RTP Video Packets
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2022 16:50:56 -0000

Hello Magnus

Thank you very much for your comments. They are very helpful.

I did read all the drafts that you included in this email. I will have some discussion on RFC 7657 in the presentation slide.

The actual problem that I want to solve, is to enable dropping precedence at packet level. Within a video streaming flow, the packet payload would decide the importance of the packet for decoding and QoE of end user. However, with the encapsulation of UDP and IP header, the RTP header (or any extension header), and the NAL unit header are not visible to network layer. The routers would not be able to make the differentiated treatment at packet level when network congestion happens. The draft discusses whether mapping those priority indicators to DSCP is a feasible solution to achieve this. If the DSCP value is limited and not the best solution for it as you mentioned in your email, then are there any other solutions that community would be interested in proposing.

And I agree with you, this draft probably is relevant to AVTCORE. Going to dispatch firstly would help me receive more guidance like what you gave on which WG might be a good fit.

Thank you! I hope to talk to you in-person if you attend the onsite meeting.

Lijun

From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Monday, July 18, 2022 at 5:11 AM
To: Lijun Dong <lijun.dong@futurewei.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Cc: Stuart Clayman <s.clayman@ucl.ac.uk>, Muge Sayit <mugefesci@gmail.com>
Subject: Re: Draft on Discarding Priority of RTP Video Packets

Hi Lijun,

I am trying to understand what is the actual problem you are trying to solve here?

I would like to point out that you haven’t take to hard the recommendations in the DART RFC: https://datatracker.ietf.org/doc/rfc7657/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc7657%2F&data=05%7C01%7Clijun.dong%40futurewei.com%7C532559792a6b442dd21a08da68b6a5f6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637937430982808062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=mg5PpX84N99Ct1FxgLwkn%2FaLx28yCwwsALbro9fFjdA%3D&reserved=0> into account as you are mixing AF traffic classes for a stream. That can result in reordering, if that is to large to make the RTP receiver buffer unhappy is hard to be certain of, but likely a particular RTP stream should stay within one AF class and only modulate drop precedences.

Neither does it look like you have looked at the specification that do exist in this space, namely the one on QoS for WebRTC where https://datatracker.ietf.org/doc/rfc8837/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8837%2F&data=05%7C01%7Clijun.dong%40futurewei.com%7C532559792a6b442dd21a08da68b6a5f6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637937430982808062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=qFWlUE4rR1xPWZCjOTqnvbbOTH4Wq2%2B5%2BRY7%2BOL4x2M%3D&reserved=0> is most relevant but you likely should look at https://datatracker.ietf.org/doc/rfc8835/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8835%2F&data=05%7C01%7Clijun.dong%40futurewei.com%7C532559792a6b442dd21a08da68b6a5f6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637937430982808062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=YJEOPW2Re%2FnIQw4xVX3CFPCT9qsyoRop%2FPK3Gae6MNE%3D&reserved=0> also. This do create priority based usage of DSCP based on the common classes.

I think the real problems in this space are primarily. First knowing which DSCP you can actually use, i.e. are you knowing and allowed to use the DSCP values you want to use in this local domain and will they survive and be meaningful into the relevant domains?

The other issue that Roni Even’s draft goes more into is how to you figure out what you can actually drop in a reasonable way to have minimal long term effects. Trying to do this efficiently without maintaining state like a MANE can do, is actually hard. And in most cases when one packet have been dropped as part of a structure, it would be best to drop all. But that can’t really be communicated in DSCP.

Also, you appear to not have made AVTCORE WG aware of this work. I would think that this is would be highly relevant to that WG.

Cheers

Magnus

From: dispatch <dispatch-bounces@ietf.org> on behalf of Lijun Dong <lijun.dong@futurewei.com>
Date: Wednesday, 13 July 2022 at 02:00
To: dispatch@ietf.org <dispatch@ietf.org>
Cc: Stuart Clayman <s.clayman@ucl.ac.uk>, Muge Sayit <mugefesci@gmail.com>
Subject: [dispatch] Draft on Discarding Priority of RTP Video Packets
Hi dispatch:

I want to share my recently submitted draft on “Discarding Priority of RTP Video Packets”.

https://datatracker.ietf.org/doc/draft-dong-priority-rtp-packet/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-501d5122-313273af-454445555731-a41c44a64e6e38d4%26q%3D1%26e%3Dc47fec5d-9c95-49a5-b2d2-0151f0c0a813%26u%3Dhttps%253A%252F%252Fnam11.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-dong-priority-rtp-packet%25252F%2526data%253D05%25257C01%25257Clijun.dong%252540futurewei.com%25257Cf4f099e6e73948d8ec8b08da645f3cd2%25257C0fee8ff2a3b240189c753a1d5591fedc%25257C1%25257C0%25257C637932657449689304%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DZ1%25252BLmuaJWeZHd6TIDI%25252F0o3ukSdRXRNi8oZb1hKaxYro%25253D%2526reserved%253D0&data=05%7C01%7Clijun.dong%40futurewei.com%7C532559792a6b442dd21a08da68b6a5f6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637937430982808062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=hEKfFcCU%2FWAbj7Kqc3NMuMfQ03uq1i3uiKpOJ%2BPyrkc%3D&reserved=0>

It is observed that significance difference or discarding priority might exist among RTP packets which encapsulate video streaming data with the existing modern video codecs. So selectively dropping RTP packets according to their significances could be a complementary mechanism when dealing with network congestion and improve end user’s QoE. The draft proposes that the video source or edge node with media-awareness could perform mapping of RTP packet discarding priority carried in RTP NALU header to a DSCP value, such that the priority-based dropping could happen at the packet level when network congestion happens.

I look forward to your generous comments and suggestions.

Lijun