Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
draft-ietf-avtcore-rtp-circuit-breakers-18
Yes
(Ben Campbell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Alissa Cooper Former IESG member
(was Discuss)
Yes
Yes
(2016-06-13 for -16)
Unknown
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.
Ben Campbell Former IESG member
Yes
Yes
(for -14)
Unknown
Mirja Kühlewind Former IESG member
(was Discuss)
Yes
Yes
(2016-06-13 for -16)
Unknown
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?
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2016-04-26 for -14)
Unknown
Thanks for working with me on my Discuss.
Alia Atlas Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -15)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -15)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-05-04 for -15)
Unknown
scott bradner performed the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -15)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-03 for -15)
Unknown
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.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -15)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -15)
Unknown