Re: [Mops] my summary of feedback for "A Use Case of Packets' Significance Difference with Media Scalability"

["Holland, Jake" <[e-mail]>]

Hi Lijun,

Regarding the request for a reference about DiffServ at the packet level, I’ll just point out that the original definition in RFC 2474 section 3 describes what the diffserv field does as “select the PHB a packet experiences at each node”, which is a per-packet thing to do:
https://datatracker.ietf.org/doc/html/rfc2474#section-3

I’m not sure if you were asking a different question; I thought this was obviously true just because of the way it’s implemented as independent markings in the IP header of the different packets?

There would of course be some constraints on doing this—whatever is doing the marking would have to understand which packets should be marked which way, so some of the features commonly implemented to do marking in routers at network boundaries based on flow characteristics might not be usable, for instance (outside of translating one mark to another). Most likely taking this approach would mean marking packets at the sender (e.g. by using an IP_TOS setsockopt before sending different kinds of packets, according to knowledge in the sending application).

Sorry for leaving you hanging, I didn’t realize you didn’t know this and were waiting for more info after last time.

Also, if you look more deeply into this approach, you should take note that it will have limited applicability because of the limited applicability of diffserv (see e.g. “Exploring DSCP modification pathologies in the Internet” by Custuro, Secchi, and Fairhurst), so it would most likely be suitable only for usage on controlled paths.

I wasn’t clear whether that was part of your intended scope or not, but since the draft seemed to talk about diffserv as if it could not be different between different packets in the same stream, I was mainly just aiming to clear up what looked like a point of confusion without addressing others, not really making a recommendation that I thought diffserv would meet your needs.

With that said, to answer your other question, I think there are probably more significant gaps in the doc to address before this would start to look interesting to me to see move forward.

For instance, this work doesn’t seem to cover quantitative experiments demonstrating the QoE gains from differentially reducing loss on I-frames in different levels of loss in a network and what kind of practical impact this sort of differential treatment would have with current codecs and current networks, nor talk about ways to take application level approaches toward solving it with existing protocols, nor whether this would be tractable with approaches like codecs that use more redundancy for I frame data, or if there’s any other approaches that were considered and rejected.

Overall, an examination of the problem space and how much can be gained in what specific target environments (and probably why current approaches can’t be tuned to better address it) seems like a missing motivating piece for spending much time looking at attempting the use of something as tricky as diffserv for this kind of problem.  But I’d certainly be very interested to see what kinds of gains in QoE can be achieved with differential treatment of frames in existing protocols (e.g. making use of the features in SRT and QUIC, or adding FEC frames in QUIC to reduce rexmit needs predictably on high-value packets, or something along these lines)

HTH.

Best,
Jake


From: Lijun Dong <[e-mail]>
Date: Tue,2021-11-09 at 10:06 AM
To: "[e-mail]" <[e-mail]>
Cc: Richard Li <[e-mail]>om>, Kiran Makhijani <[e-mail]>
Subject: [Mops] my summary of feedback for "A Use Case of Packets' Significance Difference with Media Scalability"

Dear MOPS

Hope the IETF meeting going well on your end.

Although I might not have the slot to present the updated version of the contribution again in the MOPS session, I want to bring your attention and solicit more comments from you through our email list.

Here is the summary of feedbacks from the last meeting:


  *   The comments are mainly related to how to reveal the characteristics of microblocks contained in the packet to the network and implement the selective packet dropping at packet level.
  *   For the comment from Jake regarding DiffServ could be applied at the packet level, I would like the help to find the reference(s) about it. After I confirm it is doable, I will update the draft accordingly by removing this shortcoming of DiffServ, but indicating DiffServ could be one implementation method.
  *   Very glad that the concept is very well received: it is beneficial to improve QoE of video streaming by reducing the packet dropping granularity from current traffic class level to the individual packet level, even portions within the packet.
  *   Yes, exactly, we need such information of whether this packet is significant or not to be revealed to the network nodes. For example, an API could be implemented to input such information or metadata from the application. which might be mapped to IPv6 extension header, IPv4 options or a dedicated metadata field in the IP header.

For the updated version, I mainly added more discussion on the important characteristics of MPEG video packets that would affect the packet significance and the requirements that need to be satisfied by both video applications and network side.
https://datatracker.ietf.org/doc/draft-dong-usecase-packet-significance-diff/01/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dong-usecase-packet-significance-diff/01/__;!!GjvTz_vk!EoB5EPeNoMvU35fS3wsZEtnJ4brfTtML1oo7biF7XOn84s8nSNjyacoL6M0Nrao$>

I attached some new slides for your reference. I would like to receive more suggestions on how to improve the draft and how to move forward.

Thanks for your attention during this busy week.

Lijun