Reviewer: Sean Turner Review result: Has Nits Hi! I'm no congestion control expert so nothing in the main body jumped out at me. I did take a little time to review some security considerations for other congestion control RFCs and just wanted to make sure the same kind of information is getting addressed. I indicated the result of this review as "has nits" because there is a pretty good chance I am just suggesting some editorial tweaks. The security considerations rightly points out that this mechanism is susceptible to the same kind of attacks as TCP (e.g., hijack, replacement) and what mitigations to use (i.e., integrity protection of the RTCP feedback messages). But, what is missing is what happens if these attacks succeed: DoS or in the worst case congestion collapse? So, maybe instead of: 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. Maybe: As such, it is vulnerable to attacks where feedback messages are hijacked, replaces, or intentionally injected with misleading information resulting in denial of service, similar to those that can affect TCP. Also, unless I've completely misread this paragraph it seems like you are talking about two things: 1) it's just like TCP, and 2) "The modification of sending rate ...". So, maybe split the paragraph along those lines. Further questions: 1. Are there any concerns related to a greedy receiver who wants to gobble up more than its fair share of network bandwidth? 2. Seems like maybe you also need to refer to the RTP/RTCP security considerations because it seems like security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms. Cheers, spt
