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

[Mirja Kuehlewind <[e-mail]>]

Hi Xiaoqing,

Thanks for your replies. This sounds all good to me. Please go ahead with the update and present those in the meeting to make sure the group is aware of the changes. I will start IETF last call then after then meeting (assuming no further discussion is needed after the meeting).

Mirja


> On 18. Jul 2019, at 05:52, Xiaoqing Zhu (xiaoqzhu) <[e-mail]> wrote:
> 
> Hi Mirja,
> 
> Thanks a lot for your review of the document. A few of the co-authors have discussed over them. Please find our replies below inline (tagged [Authors]).  We intend to update the draft as planned and present the changes at the upcoming IETF 105 meeting.  
> 
> Please let us know if you have any additional comments regarding these changes. 
> 
> Best,
> Xiaoqing
> 
> On 7/5/19, 8:57 AM, "Mirja Kuehlewind" <[e-mail]> wrote:
> 
>    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. 
> 
> [Authors]  Thanks for the reminder. We intend to add the following text for the next "Security Consideration" section: 
> 
> The rate adaptation mechanism in NADA relies on feedback from the receiver. As such, it is vulnerable to attacks where feedback messages are hijacked, replaces, or intentionally injected with misleading information, similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback message is at least integrity checked.  The modification of sending rate based on send-side rate shaping buffer may lead to temporary excessive congestion over the network in the presence of a unresponsive video encoder. However, this effect can be mitigated by limiting the amount of rate modification introduced by the rate shaping buffer, bounding the size of the rate shaping buffer at the sender, and maintaining a maximum allowed sending rate by NADA.  
> 
>    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). 
> 
> 
> [Authors]  Thanks for raising this concern. We agree that without applying any other guiderails, the equation as it is currently described in the draft may lead to excessive congestion in the presence of an unresponsive video encoder and an unlimited rate shaping buffer.  In practical systems, one can further bound the modification introduced by the rate shaping buffer by bounding both the size of the rate shaping buffer and amount of rate changes (so that it's only within a few percent of the reference rate), along with choosing an appropriate scaling parameter BETA_S.  
> 
> [Authors] Note further that this modification is not part of the core congestion control algorithm, but rather a mechanism at the sender for mitigating end-to-end frame delivery delay of the media streams. Its applicability largely depends on whether the rate shaping buffer information is exposed outside of the video sender. 
> 
> [Author] In light of the above considerations, we'll explicitly add some bounding conditions to the equation of calculating r_send in Section 5.2.2., and will also update the recommended value of BETA_S (and, for that matter, also BETA_V) based on simulation studies.  Will report back on the updated parameter values after our simulation study efforts on completed. We will also add a paragraph of discussion to reflect the above points in that section of the draft. 
> 
> 
>    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?
> 
> [Authors]  Note that the NADA rate adaptation is calculated not only from the reported congestion level (i.e., relative one way delay in the absence of packet losses), but also the _change_ in consecutive reports of congestion levels (i.e., the derivative of the congestion signal).  As such, more frequent feedback messages translates to better estimates of the congestion derivative, since we are approximating the derivative using difference equations.  That is the main reason why the recommended feedback interval is at 100ms. 
> 
> [Authors] We have presented in previous WG meetings extensive studies (via both theoretical analysis and numerical and simulation studies) on the impact of feedback interval, and have shown that while stability of the system holds for feedback intervals up to 500ms, the system response time does slow down with increasing feedback interval values.  More details can be found at the link below for the reasoning behind our recommended feedback interval of 100ms to cover a wide range of propagation delays at a reasonable tradeoff between feedback overhead vs. responsiveness: 
> 
> https://datatracker.ietf.org/meeting/95/materials/slides-95-rmcat-5.pdf
> 
>    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.
> 
> [Authors]  Thanks for the above editorial suggestions. We'll incorporate all of them. 
> 
> 
>    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.
> 
> [Authors] You are right that we do intend to include this section (similar to how we proceeded with the video-traffic-model draft).  We can add a note directly in the document to state that we intend to keep the reference to our open-source implementation in the final draft. 
> 
> 
> [Authors] Thanks again for your thorough review and helpful suggestions! 
> 
>    Thanks,
>    Mirja
> 
> 
> 
> 
> 
> 
>