Ballot for draft-ietf-avtcore-rtp-circuit-breakers
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
Thanks for addressing my DISCUSS. --- (1) Did the WG discuss BCP status for this rather than PS? (2) Section 4.3: "If such a reduction in sending rate resolves the congestion problem, the sender MAY gradually increase the rate at which it sends data after a reasonable amount of time has passed, provided it takes care not to cause the problem to recur ("reasonable" is intentionally not defined here)." In later sections you explain that thresholds are not specified because they are application-dependent. I think that would be useful to note here too as the reason for not defining "reasonable," assuming that is the reason.
Thanks for address my discuss! Thanks for all the work and discussion! Final comment/question: Should reference [I-D.ietf-tsvwg-circuit-breaker] should be normative?
Thanks for working with me on my Discuss.
scott bradner performed the opsdir review
I just have a nit and a random query... - nit: The abstract says "It is expected that future standards-track congestion control algorithms for RTP will operate within the envelope defined by this memo." That seems both unwise and unlikely to work to me. Unwise in that you're trying to control the future which seems like it'll just generate heat and not light, and unlikely to work since it's not clear to me that any CC scheme can take into account circuit breaker constants configured on a node that may not be known anywhere else. I'd say better would be to say that we hope that future CC algorithms will be consistent with this and leave it at that. However, if that sentence is the product of a bunch of haggling then it's probably better to leave it as-is and I'll just hold my nose a bit;-) (Same sentence is in the intro - same comment.) - query: Assuming people have implemented some or all of this, I wondered if it'd be a good idea to document some of the ways in which those implementations went wrong, i.e. bugs already fixed, especially if there were any that'd result in the circuit not being broken when it ought be. But that's probably too late or better done in some other document for now, so feel free to ignore me.