[rmcat] AD review of draft-ietf-rmcat-nada

[Mirja Kuehlewind <[e-mail]>]

Hi authors, hi all,

There is one hard requirement that need to be addressed before I can move this document forward. Every RFC needs a security consideration section (see RFC 3552). Please add respectively text there. 

Also I have one technical question I would like to quickly discuss before I move this document to IETF last call. Sorry if this was discussed before in the wg but at least I don’t recap any discussion about this:

In section 5.2.2 the sending rate is calculated the following way:

r_send = r_ref + BETA_S*8*buffer_len*FPS.

This takes the reference rate that is calculated based on the congestion feedback and adds a term based on the buffer length. However, this seems to some extend counter-productive as the reference rate might decrease due to congestion and therefore the buffer might build up, and the final reaction is to simply send more data, even though the congestion might have gotten worse. I wonder after all if this behaviour is safe or could lead to even a congestion collapse because you might end up increasing your rate instead of decreasing in a congestion situation (especially as the encoder could actually ignore the reference rate and just keep filling up the buffer). 


And another (less critical) technical question: 

Section 6.3 discussed the target feedback interval and recommends some values. However, should that feedback interval depend on the RTT. E.g. if you have an RTT of 500ms, why do you need to send feedback every 100ms or 250ms?


Some other mostly editorial comments:

1) I would recommend to add informative reference for PIE, FQ-CoDel and RED in section 3.

2) Sec 4.3: “Values of the minimum rate (RMIN) and maximum rate (RMAX) will be provided by the media codec, as specified in [I-D.ietf-rmcat-cc-codec-interactions].”
This sounds like I-D.ietf-rmcat-cc-codec-interactions would be a normative reference, however, I think you just want to give this (expired) draft as an example, maybe say “… as e.g. outlined in [I-D.ietf-rmcat-cc-codec-interactions]” or something similar.

3) Sec 6.2: “These alternatives are currently under investigation.”
Given this document will not change anymore after publication as RFC, maybe rather say something like:
“These alternatives are part of the experiment this document proposes.”
Similar also at end of section 6.3.


And one more processing question:
RFC 7942 proposes an Implementation Status section that is intended to be removed on final publication as RFC. I guess in this case it would actually be valuable to keep the section. Is that the intention? If yes, we need to make sure this is communicated to the RFC editor. We can add a note in the IESG write-up or you can alternative add a note directly in the document.

Thanks,
Mirja