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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 May 2016 15:26:44 -0700

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

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 4 May 2016 11:39:16 +0100

> On 3 May 2016, at 23:26, Stephen Farrell <[email-masked]> wrote:
> 

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.

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 May 2016 10:00:12 -0500

On 4 May 2016, at 5:39, Colin Perkins wrote:

[...]

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

How about restating it to describe the consequences if a parallel 
congestion control allows packet loss rates to exceed the threshold?

[...]

Thanks,

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 May 2016 16:41:37 +0100

> On 4 May 2016, at 16:00, Ben Campbell <[email-masked]> wrote:
> 
> How about restating it to describe the consequences if a parallel congestion control allows packet loss rates to exceed the threshold?

“To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by the RTP circuit breaker algorithms”? 

Or “…will need to keep packet loss rates within the envelope permitted by the RTP circuit breaker algorithm”?

Colin

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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 May 2016 12:36:09 -0400

On 10 May 2016, at 11:41, Colin Perkins wrote:

  the text.
> “To avoid triggering the RTP circuit breaker, any standards-track 
> congestion control algorithms defined for RTP will need to operate 
> within the envelope set by the RTP circuit breaker algorithms”?
>
> Or “…will need to keep packet loss rates within the envelope 
> permitted by the RTP circuit breaker algorithm”?

I am okay with either, with a slight preference towards the first.