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

[Magnus Westerlund <[e-mail]>]

Hi,

Another aspect is that as soon as you have multiple video streams like in a multi-party conferencing just setting the packet priority is likely to create a very non-optimized experience. In centralized conferencing an application aware node that can make the trade-off to drop all of the least prioritized packets for a single video stream, for example a temporal scalable layer of “B” pictures will have much less impact than having a non application aware router drop a random set of the least prioritized packets, i.e. dropping parts of the corresponding temporal scalable layer in multiple streams, thus resulting in that multiple media streams gets affected.

So in general I think the easiest ways of accomplishing what you want is to use a small number of DSCP code points (even 2 could work) with varying drop priorities and have the sender be smart about  how it marks the packets that would be the best to drop in case of congestion and then have the rate control react to any losses and adjust coding and streams etc, and adjust which packets that are marked to be acceptable to be dropped.

Cheers

Magnus

From: Lijun Dong <[e-mail]>
Date: Friday, 22 July 2022 at 12:52
To: Magnus Westerlund <[e-mail]>, [e-mail] <[e-mail]>
Cc: Stuart Clayman <[e-mail]>, Muge Sayit <[e-mail]>, Richard Li <[e-mail]>
Subject: Re: Draft on Discarding Priority of RTP Video Packets
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 <[e-mail]>
Date: Monday, July 18, 2022 at 5:11 AM
To: Lijun Dong <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Stuart Clayman <[e-mail]>, Muge Sayit <[e-mail]>
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-e98fd18660cf3543&q=1&e=f0c81611-62aa-4bec-b053-ebcd098bc236&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Frfc7657%252F%26data%3D05%257C01%257Clijun.dong%2540futurewei.com%257C532559792a6b442dd21a08da68b6a5f6%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C1%257C637937430982808062%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%257C%257C%257C%26sdata%3Dmg5PpX84N99Ct1FxgLwkn%252FaLx28yCwwsALbro9fFjdA%253D%26reserved%3D0> 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-07f92973524231b2&q=1&e=f0c81611-62aa-4bec-b053-ebcd098bc236&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Frfc8837%252F%26data%3D05%257C01%257Clijun.dong%2540futurewei.com%257C532559792a6b442dd21a08da68b6a5f6%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C1%257C637937430982808062%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%257C%257C%257C%26sdata%3DqFWlUE4rR1xPWZCjOTqnvbbOTH4Wq2%252B5%252BRY7%252BOL4x2M%253D%26reserved%3D0> is most relevant but you likely should look at https://datatracker.ietf.org/doc/rfc8835/<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7a69d33d5e3b2c6d&q=1&e=f0c81611-62aa-4bec-b053-ebcd098bc236&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Frfc8835%252F%26data%3D05%257C01%257Clijun.dong%2540futurewei.com%257C532559792a6b442dd21a08da68b6a5f6%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C1%257C637937430982808062%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%257C%257C%257C%26sdata%3DYJEOPW2Re%252FnIQw4xVX3CFPCT9qsyoRop%252FPK3Gae6MNE%253D%26reserved%3D0> 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 <[e-mail]> on behalf of Lijun Dong <[e-mail]>
Date: Wednesday, 13 July 2022 at 02:00
To: [e-mail] <[e-mail]>
Cc: Stuart Clayman <[e-mail]>, Muge Sayit <[e-mail]>
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-d4f23c73b860ee3c&q=1&e=f0c81611-62aa-4bec-b053-ebcd098bc236&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D31323334-501d5122-313273af-454445555731-a41c44a64e6e38d4%2526q%253D1%2526e%253Dc47fec5d-9c95-49a5-b2d2-0151f0c0a813%2526u%253Dhttps%25253A%25252F%25252Fnam11.safelinks.protection.outlook.com%25252F%25253Furl%25253Dhttps%2525253A%2525252F%2525252Fdatatracker.ietf.org%2525252Fdoc%2525252Fdraft-dong-priority-rtp-packet%2525252F%252526data%25253D05%2525257C01%2525257Clijun.dong%25252540futurewei.com%2525257Cf4f099e6e73948d8ec8b08da645f3cd2%2525257C0fee8ff2a3b240189c753a1d5591fedc%2525257C1%2525257C0%2525257C637932657449689304%2525257CUnknown%2525257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%2525253D%2525257C3000%2525257C%2525257C%2525257C%252526sdata%25253DZ1%2525252BLmuaJWeZHd6TIDI%2525252F0o3ukSdRXRNi8oZb1hKaxYro%2525253D%252526reserved%25253D0%26data%3D05%257C01%257Clijun.dong%2540futurewei.com%257C532559792a6b442dd21a08da68b6a5f6%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C1%257C637937430982808062%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%257C%257C%257C%26sdata%3DhEKfFcCU%252FWAbj7Kqc3NMuMfQ03uq1i3uiKpOJ%252BPyrkc%253D%26reserved%3D0>

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