Congestion Control Requirements for Interactive Real-Time Media
Note: This ballot was opened for revision 06 and is now closed.
Spencer Dawkins Yes
(Ted Lemon) Yes
Comment (2014-11-25 for -08)
This is a clear, readable document that I think will be useful to people trying to understand what work is being done and why. Thanks for doing it!
(Jari Arkko) No Objection
(Richard Barnes) No Objection
Alissa Cooper No Objection
Comment (2014-11-24 for -08)
= Section 2 = "The algorithm must consider the case where offered loads are less than the available bandwidth at any given moment, and may vary dramatically over time" A requirement for an algorithm to "consider the case" seems a bit odd and makes me wonder what the real requirement is.
(Adrian Farrel) No Objection
Comment (2014-11-20 for -08)
I have no objection to the publication of this document, but I found the reference to routing changes in Section 2 bullet 1,C to be peculiar. While it is true that "routing changes" may alter or remove bottlenecks or change the bandwidth available, a change in routing might have no affect on these things. I wonder whether you really want to talk about reacting to changes in bottlenecks and available bandwidth rather than changes in routing? That is, you don't actually care what has caused the change to the measures that lead to congestion: you care about the congestion itself. For example, if you were operating over a variable bandwidth link (such as a microwave link) the changes could arise without any routing change.
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
(Barry Leiba) No Objection
Comment (2014-11-19 for -08)
This seems Mostly Harmless (tm).
(Kathleen Moriarty) No Objection
Comment (2014-11-24 for -08)
Thanks for addressing the SecDir reviewers comments and adding text to the security considerations section to reflect the possible impact of such attacks. I see Spencer's response that a sentence or two will be added, but don't see an actual change from the -05 draft. Here is Steve's recommendation that Spencer agreed with and I think it would be helpful (but only have this as a comment as it's not something to block on, but could improve the section): However, I think that one sentence should probably be added. The section says “Attacks that increase the perceived available bandwidth are conceivable, and need to be evaluated.” While this is true (and disregarding the spelling errors for the moment), I believe it is the most concerning part of the security considerations section and therefore deserves more attention. I suggest adding a sentence reflecting on the possible impact of such attacks. For example, this sentence could be added after the one that I just quoted: “Such attacks could result in starvation of competing flows and permit amplification attacks.” Adding such a sentence may provide guidance to readers who are congestion control experts not familiar with security and therefore not likely to understand the implications of the existing, brief text. https://www.ietf.org/mail-archive/web/secdir/current/msg04972.html Thank you!
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
(Brian Haberman) Abstain
Comment (2014-11-21 for -08)
I have been on record as saying that publishing these "requirements documents" as RFCs is bad practice. They serve no purpose as standalone documents. Requirements are living entities until the protocol specification that satisfies them is published. I would rather see these maintained in a wiki or living I-D and either not published or published as an appendix to the corresponding protocol specification. That being said, I will not stand in the way of this document.