Re: [AVTCORE] Stephen Farrell's No Objection on draft-ietf-avtcore-rtp-circuit-breakers-15: (with COMMENT)

[Colin Perkins <[e-mail]>]

> On 3 May 2016, at 23:26, Stephen Farrell <[e-mail]> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-avtcore-rtp-circuit-breakers-15: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 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.)

In some sense, it’s stating the obvious. If an endpoint implements the RTP circuit breaker, which will stop the flow if packet loss exceeds a certain threshold, then any congestion control running in parallel had better make sure the packet loss rate staying below that threshold if it wants the flow to continue. I’m open to suggestions to improve the text.

> - 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.

There’s been some list discussion, and implementers have found bugs in RTCP handling in other implementations as a result of implementing the circuit breaker. This might be better handled in a -bis draft in a few years, once we’ve got more experience with the combination of this and the RMCAT congestion control algorithms. 

Cheers,
Colin





-- 
Colin Perkins
https://csperkins.org/