[AVTCORE] Re: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review

["Lauri Ilola (Nokia)" <[e-mail]>]

Hi Magnus,

I’m starting to integrate the suggestions into the draft. This is what I added for additional clarifications under the security considerations section.

“A V3C session can consist of multiple sub-streams carried over different RTP streams. Security considerations such as source authentication SHOULD be applied to all its constituent sub-streams. All receivers of V3C data SHOULD exercise source caution and only receive data from senders that they can trust. Furthermore, this RTP payload format supports multiple RTP streams for different components necessary to produce the decoded output, thus it depends on that all RTP streams and the signalling components, e.g. SDP as well as RTCP, are authentic to what the sender intended.”

This is what I added under the congestion control section:

“This section only applies for unicast streaming, leaving considerations for multicast streaming out of scope.

As an example, both the sender and the receiver may have their own definition for an acceptable packet loss rate. In such a case the receiver may decide to quit a stream when it finds the packet loss rate too high. Similarly the sender may decide to drop a receiver when the reports it receives indicate packet loss rates that are too high from its perspective. These decisions can be made independently either by the receiver or the sender.

As an example of a bitrate adaptation technique, a sender or a receiver may adapt bitrates of specific sub-streams. The adaptation should be done in a manner that effects the quality of the experience as a whole, while keeping the subjective quality of experience as high as possible. In an implementation this could mean dropping less important sub-streams fully, or reducing the bitrates of the most important sub-streams throughout the session.”

Thanks for the suggestions.

Kind Regards,
-Lauri

From: Magnus Westerlund <[e-mail]>
Sent: Tuesday, January 20, 2026 4:46 PM
To: Lauri Ilola (Nokia) <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review

Hi Lauri,

Please see inline.

From: Lauri Ilola (Nokia) <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 20 January 2026 at 11:46
To: Magnus Westerlund <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review
You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Magnus,

I appreciate the suggestions. Trying to quickly address the most important topics you raise.

> 1.Security considerations: As you reply in worst case managing to instruct the endpoint to combine the wrong streams could result in at minimal the incorrect produced output, it may also crash the decoder. Thus, I think the security considerations needs a bit more than the standard boiler plate here and be explicit about the need to be able to trust the signalling for which streams to combine into one output, as well as the need for having source authentication on all the streams that are used as input when decoding.

This is why we recommend (with a SHOULD) to use the appropriate strong security mechanisms as described in RFC7201. We make this recommendation even though it is generally not the payload format's responsibility  to mandate what solutions are used to meet the security goals. To further address your concern however, would adding the following text in Section 11 help:

"V3C bitstreams can consist of multiple sub-streams of data and as such the security considerations like the source authentication SHOULD be applied to all its constituent sub-streams. All receivers of V3C data SHOULD exercise source caution and only receive data from senders that they can trust."

I think this gives a pretty clear recommendation, without forcing a specific implementation.

MW: Yes, that recommendation is good but very much focused on the RTP streams. What I see as missing is a similar warning and recommendation for the signalling. Because, if you use SDP bundle as the method to indicate which RTP Streams are part of a common context then an attack could potentially still manipulate this.

Multiparty sessions are also a challenge here as there are multiple endpoints, each with its own media source(s) being sent over multiple SSRCs. As in this case each endpoint would be identified based on CNAME. This do require a mutual trust between all endpoints unless the session choices to deploy the only source authentication algorithm we have that actual can do per endpoint source authentication for a multiparty session, namely TESLA. The point I am trying to make here is that VC3 is more vulnerable than many other due to multiple related streams, as well as signalling.

I personally would prefer to a call out of the increased threat surface for V3C. Maybe something like this.

This RTP payload format depend on multiple RTP streams for different components necessary to produce the decoded output, thus it depends on that all RTP streams and the signalling components, e.g. SDP as well as RTCP, are authentic to what the sender intended.




> 2.When it comes to the congestion control considerations I would note that also here it appears to needs a bit of discussion about the need to consider the full aggregate when adapting the bit-rates to ensure that the adaptation results in a proportional quality degradation, and not a much larger due to adapting the wrong stream.

We've discussed the congestion control aspects with other reviewers and have agreed to amend the draft with the following improvements:

"As an example, both the sender and the receiver may have their own definition for an acceptable packet loss rate. In such a case the receiver may decide to quit a stream when it finds the packet loss rate too high. Similarly the sender may decide to drop a receiver when the reports it receives indicate packet loss rates that are too high from its perspective. These decisions may be made independently either by the receiver and or the sender."

"This section only applies for unicast streaming, leaving considerations for multicast streaming out of scope."

We could further provide another example, that should alleviate the concerns. Would adding the following text in Section 8. help alleviating your concerns?

"As an example of a bitrate adaptation technique, a sender or a receiver may adapt bitrates of specific sub-streams. The adaptation should be done in a manner that effects the quality of the experience as a whole, and keeping subjectively the quality of experience as high as a intended. In an implementations this could mean dropping less important sub-streams as a whole, or reducing the bitrates of the most important sub-streams throughout the session.”

MW: I think adding this paragraph would be good. I would however note that for middlebox performing adaptation achieving this might be difficult without additional information. But, that has always been a struggle, a good example would be the whole discussion around frame marking and layered codecs in general.


> When it comes to the general multiplexing description, including using SSRC grouping I think addressing this will have some significant impact on the time to publish this document. If that is worth it would be highly dependent if there exists usage of this that would benefit from that description. However, as you have a BUNDLE case it might be fine for the initial usage. Thus, it might be simpler to just go ahead for now, and if the actual deployments runs into use cases with need to more clearly express things for example multiple sources per direction in the same set of RTP session(s) then extensions may be warranted.

I agree, timeline-wise this could affect the publication. This could be further discussed later on. It might be just clarifying how existing tools can be used.

> I still think this draft could have benefited from an additional architectural section between Section 4 and 5 that would have discussed how RTP sessions vs streams (SSRCs) are best used for some use cases. I think that would have simplified the rest of the description.

Maybe we should put this on the list of potential further improvements. I've tried to keep the format of the payload specification as close to other NAL unit based RTP payload formats.

MW: Yes, I think that is likely appropriate.

I hope this helps to resolve your remaining concerns.

MW: Yes, I think it does after you considered if the security considerations.


Kind Regards,
-Lauri

From: Magnus Westerlund <[e-mail]<mailto:[e-mail]>>
Sent: Monday, January 19, 2026 3:50 PM
To: Lauri Ilola (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review

Hi,

This is a follow up TSV-ART review.

Summary rating: Ready with Issues.

Sorry, I missed this email before Christmas. I just took another look at the updated draft -14. It does addresses some of the issues that I raised. However, I think the following issues should be addressed before publication.


  1.  Security considerations: As you reply in worst case managing to instruct the endpoint to combine the wrong streams could result in at minimal the incorrect produced output, it may also crash the decoder. Thus, I think the security considerations needs a bit more than the standard boiler plate here and be explicit about the need to be able to trust the signalling for which streams to combine into one output, as well as the need for having source authentication on all the streams that are used as input when decoding.
  2.  When it comes to the congestion control considerations I would note that also here it appears to needs a bit of discussion about the need to consider the full aggregate when adapting the bit-rates to ensure that the adaptation results in a proportional quality degradation, and not a much larger due to adapting the wrong stream.

When it comes to the general multiplexing description, including using SSRC grouping I think addressing this will have some significant impact on the time to publish this document. If that is worth it would be highly dependent if there exists usage of this that would benefit from that description. However, as you have a BUNDLE case it might be fine for the initial usage. Thus, it might be simpler to just go ahead for now, and if the actual deployments runs into use cases with need to more clearly express things for example multiple sources per direction in the same set of RTP session(s) then extensions may be warranted.

I still think this draft could have benefited from an additional architectural section between Section 4 and 5 that would have discussed how RTP sessions vs streams (SSRCs) are best used for some use cases. I think that would have simplified the rest of the description.

Cheers

Magnus



From: Lauri Ilola (Nokia) <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 9 December 2025 at 14:42
To: Magnus Westerlund <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review
[You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hello Magnus!

Thanks for the thorough feedback. Let me try to address these over email here. I've implemented your suggestions below, except for the few clarifications that I wanted to ask.

Regarding Section 9.3.

You are correct that there are multiple ways of transmitting the atlas data and the video data. V3C has a concept to allow packing multiple video component in the same video frame so you can only end up needing one video stream. Together with the video you'll need the atlas stream in case the atlas data is dynamic. Alternatively the draft allows sending atlas data as part of the SDP, if it doesn't change over the session - which is the scenario that allows you to only stream on video for the volumetric experience. I'll try to clarify these two methods more clearly in the draft to avoid any confusing on the readers part.

Your point on ssrc-group is also well made and could be yet another way of grouping the different components. Would it make sense to add this as yet another way for grouping the data under the clarified section on grouping V3C components? It would probably just need a new <semantics> parameter to clarify the nature of grouping, correct?

Regarding Section 8.

> Due to how the full media representation when using V3C is dependent on having both the ATLAS as well as the component video streams the response to congestion control limitations are far from trivial. I think some clarification to the implementer here is needed on how it should behave when forced to reduce the aggregate bandwidth and how to consider inter stream prioritization. This issue is clearly different from what scalable video codecs encounter when being bandwidth limited where it is usually clear how to reduce the bit-rate.

This is an astute observation. You are absolutely correct that this is far from trivial and could be something that will set one implementation apart from another implementation. Many services and receivers may have different opinions how the adaptation should be performed depending on the available hardware and processing at hand. Specifying it here could be rather limiting and as such we propose to follow the bare minimum methods as written in the draft. I don't believe proper adaptation is as simple as defining media stream priorities, but some streams are for sure more important than others. For example, for one application it may be absolutely ok to drop color or texture information and stream only black and white data as a method for adaptation. Another application may be prefer increasing the noise for the rendering, by dropping occupancy information and trying to derive occupancy form depth & color videos. Do you consider this a road-blocker if we don't fix definitely the adaption in the specification?

Regarding Section 11.

> I think this format needs an additional security consideration due to the grouping. That is that for correct decoding the signalling system needs to correctly indicate the combination of the V3C Atlas stream and the component streams. If an attacker is able to manipulate this information the senders intention will not be represented.

This would mean that an attacker, if able to manipulate the SDP, would be able to direct atlas data to video decoder and vice versa, or that video codec components would be reconstructed incorrectly. This would likely cause the decoder to crash. Similar problems would occur, when a video and audio streaming session would be attacked and the bitstreams would be directed to incorrect decoders. This sounds like something that should have a default mechanism to protect against these kind of attacks. Do you know if there is a standard that would be addressing this?

> If I manipulate the ATLAS information can I significantly increase the decoding information. For example forcing magnitude more iterations over the underlying component video stream data to create the Volumetric representation?

Manipulation of the atlas data, would likely cause mis-indexing of video textures and result in crashing the decoder. How the decoders handle falsified atlas data is very much left to the decoder implementation. Smart implementations would have means of detecting such manipulations (for example counting how many texel read operations are made per pixel), but less smarter decoders could end up in infinite loops if not careful. I'm unsure how this sort of attacks could be prevented other than urging for carefulness from the decoder implementers. Would it be sufficient to add a note urging for such carefulness?

Thanks again for the constructive suggestions. Looking forward for your suggestions.

Kind regards,
-Lauri

-----Original Message-----
From: Magnus Westerlund via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 28, 2025 3:50 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: draft-ietf-avtcore-rtp-v3c-12 ietf last call Tsvart review


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Document: draft-ietf-avtcore-rtp-v3c
Title: RTP Payload Format for Visual Volumetric Video-based Coding (V3C)
Reviewer: Magnus Westerlund
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [e-mail]<mailto:[e-mail]> if you reply to or forward this review.

High level issue:

I think this document is not clear enough on the different alternatives that is actually supported for transmitting the ATLAS data and the component video data.

Section 4.1 gives the impression that one can combine all data needed for one V3C represenation into a single video stream, i.e. being sent over a single RTP SSRC.

Section 9.2 instead talks about how to have seperate V3C with the atlas data, and then component video streams over other RTP streams (SSRC).

For the later there exists a plentora of possible multiplexing models. With what is being defined in section 9.2-9.4. With the defined grouping of V3C one can clearly do both RTP session based multiplexing as well as bundled. The examples in Section 9.3 appears to indicate that one need uniquie media lines in SDP per complete V3C representation and that one can't setup one media line per type and simple use multiple SSRC in each one complete set across the media line to generate one media representation? Or even by just establishing one payload type per type and then use RFC 5576 ssrc-group to indicate a set of SSRCs that are part of one representation. Wouldn't it make sense to have a ssrc-group for V3C?

Having read the document I think there is a need for a dedicated section that defines which combinations that are possible and what external from RTP/RTCP support these needs in providing the grouping.

Can you confirm that you have not identified anyway of using RTP/RTCP mechanisms that exist to identify the set of SSRCs that are part of one representation?

Another significant issue is the one for Section 8: regarding bit-rate adaptation for this payload format and its component stream.

Section 7.1:

Published specification: Please refer to [ISO.IEC.23090-5]

I think this needs to indicate the RFC that defined the RTP payload format, as that is the specification for which the media type is being registered.

Restrictions on usage: N/A

I think the recommened text from RFC 8088 for this field still applies:

This media type depends on RTP framing and, hence, is only defined
      for transfer via RTP [RFC3550].  Transport within other framing
      protocols is not defined at this time.

Section 8:

Due to how the full media representation when using V3C is dependent on having both the ATLAS as well as the component video streams the response to congestion control limitations are far from trivial. I think some clarification to the implementer here is needed on how it should behave when forced to reduce the aggregate bandwidth and how to consider inter stream prioritization. This issue is clearly different from what scalable video codecs encounter when being bandwidth limited where it is usually clear how to reduce the bit-rate.

Section 9.

Please add a reference to RFC 8866 in the first sentence.

Section 9.1:

I would recommend that one are clear that "byte-string" is using the definition that exists in RFC 8866.

Section 11:

I think this format needs an additional security consideration due to the grouping. That is that for correct decoding the signalling system needs to correctly indicate the combination of the V3C Atlas stream and the component streams. If an attacker is able to manipulate this information the senders intention will not be represented.

Secondly:

This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.

If I manipulate the ATLAS information can I significantly increase the decoding information. For example forcing magnitude more iterations over the underlying component video stream data to create the Volumetric representation?