Original text:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del>  When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del>  RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del>  The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Reviewer comments:
and .
Also
The text currently reads: "The community should also consider other non-standard congestion controls known to be widely deployed," This is a compromise to land a mostly unrelated PR. NAME doesn't think it's fair to expect participants to test algorithms that aren't fully specified. I would argue that if such specifications exist and the algorithm is systemically important, it absolutely should be modeled. Moreover, if the algorithm is rather loosely described, in many cases there is open source code (often in a Linux fork!) that can be tested on a host, or in simulation frameworks like ns3. If an algorithm is a true black box, with no description besides marketing material, and no open-source code, I agree there is not much to be done. I also believe that while algorithms like this exist, they are not systemically important to the internet.
gorry: ns3 code is not super high fidelity.
Discussed at IETF 118: There's a danger if you see a realtime flow that goes faster than a best effort flow, since realtime is usually constrained by other factors (potentially needing time to move forwards to generate more data) Seems hard to imagine that something not specified is able to place a burden on anybody else. If you want others to do a thing, write it down and document it. Of course, there is no protocol police: we cannot prevent people from deploying whatever they want. Can we provide a carrot for people to play by the rules: Could be a SHOULD consider requirements and how to interact We have: Guidance for people who are writing specs that aren't yet part of the community How do we evaluate those protocols How do we ensure that fairness can exist with these Need to have a commitment from this WG to help and not just throw up new requirements for data and for those bringing new CCs to engage positively. Perhaps spelling this out clearly NAME to file issue to write something encouraging for people early on in the document Christian notes that separate queues between realtime and best effort are not actually a strong requirement To measure capacity you do need some sort of queue, or else you cannot measure
This info RFC has some sensible guidelines on RTP feedback frequency, if we need this: "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences".
Related to
Condition (1) is concerned with the behavior with respect to Reno and, thanks to our edits, Cubic. But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.

Revised text:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth.  <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered.  <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering.  <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as