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

[Toerless Eckert <[e-mail]>]

On Mon, Jul 18, 2022 at 12:11:27PM +0000, Magnus Westerlund wrote:
> Hi Lijun,
> 
> I am trying to understand what is the actual problem you are trying to solve here?

Improving video quality under congestion for real-time video traffic.

Example: When you have in a router queue overrun between three video flows,
two of which have I-frame packets, the other one just non-reference P-frame packets, then
you resolve the burst collision by discarding those lowest-priority packets. 

Without this optimization, you would have a visible outage as long as a GOP size
(or retransmission requests) when I-frame data is dropped (i am simplifying here for
sake of example). When just non-reference frame data is dropped, good receiver might
be able to render this almost invisible, by using some more or less avanced disguise
techniques. Such as frame duplication (most lame one).

Is that a benefit that would appeal to you or that you think would be beneficial
to be furthre explored by the IETF ?

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

Dealing with anything DSCP is painfull. You can certainly set up queuing for the
different AF classes to be operating without reordering in a router. If you
are reading RFC7657 to imply that you MUST NOT build an application system
mixing AF classes in the expectation of the network to be set up not to
cause re-ordering, then it simply turns e.g. AF4x into even less useful than
they otherwise are. But that is just me not being a big fan of DSCP after
having worked with too much pain in customer trying to applying them beneficially.

Aka: If we as IETF think the problem is worth to be solved, i hope we are open
to discussions avbout how to best do this - instead of primarily focissing
on bringing up all the problems that existing IETF standard might bring to the
table (we all know how they do).

> 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/ is most relevant but you likely should look at https://datatracker.ietf.org/doc/rfc8835/ also. This do create priority based usage of DSCP based on the common classes.

Have you seen any deployment guide and performance measurement made against it ?
I always considered that document to be well intentioned but ultimately badly
explored. Aka: It does not enable easy deployments, especially when you
try to figure out what and how to assign high/med/low priorities.

Aka: I think for this discussion, that RFC is a red herring.

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

Given the long history of existing DSCP, it would certainly be a lot saner
to come up with three new DSCP for these drop priorities, especially
for interdomain use. But of course thats ultimately up to IETF. IMHO
every baby step we're able to take could help.

I am of course a fan of having better than DSCP indications on-path.
RTP header extensions like i proposed (see other reply), or IPv6 extension
header. The latter being the architecturally cleanest and of course therefore
least easily deployed option ;-)

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

See my example above. That has been done and proven to be effective.

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

Yes, where is the ATM network with early packet drop through markings of which cells belong to a packet, when you need it ;-)

Aka: If you had not only discard priority, but also a frame-identifier (efectively like
we had in ATM, or before we considered IP fragmentation evil), you could easily discard
whole packets. Have not tried to investigate if this would be significantly harder at
current router speed than it was back in the ATM days. It seems that IP fragmentation
makes a bit of a revival, in advanced hardware, not sure.

In my practical experience though, this has not become important
given how non-reference P-frames have most often fit into a single packet, and/or
the single-packet dropping in a queue can be build effectively to get rid of
most of the lower-priority packets (at least up to ATM PPD performance levels). 

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

Indeed.

Cheers
    Toerless

> 
> 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-501d5122-313273af-454445555731-a41c44a64e6e38d4&q=1&e=c47fec5d-9c95-49a5-b2d2-0151f0c0a813&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dong-priority-rtp-packet%252F%26data%3D05%257C01%257Clijun.dong%2540futurewei.com%257Cf4f099e6e73948d8ec8b08da645f3cd2%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637932657449689304%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DZ1%252BLmuaJWeZHd6TIDI%252F0o3ukSdRXRNi8oZb1hKaxYro%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
> 
> 
> 

-- 
---
[e-mail]