Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
RFC 8083

Note: This ballot was opened for revision 14 and is now closed.

(Ben Campbell) Yes

Alissa Cooper (was Discuss) Yes

Comment (2016-06-13 for -16)
No email
send info
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.

(Spencer Dawkins) (was Discuss) Yes

Comment (2016-04-26 for -14)
No email
send info
Thanks for working with me on my Discuss.

Mirja K├╝hlewind (was Discuss) Yes

Comment (2016-06-13 for -16)
No email
send info
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?

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Stephen Farrell) No Objection

Comment (2016-05-03 for -15)
No email
send info
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.

(Joel Jaeggli) No Objection

Comment (2016-05-04 for -15)
No email
send info
scott bradner performed the opsdir review

Suresh Krishnan No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection