Subject: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Feb 2016 16:19:38 -0600

Hi,

This is my AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13. 
While I do have some comments and questions, I don't think anything here 
needs to block IETF last call. Please address these along with any other 
last call feedback.

Thanks!

Ben.

Substantive
===========

-4, third paragraph, sentence starting with "This approach SHOULD NOT be 
used..."

Does this mean that, in addition to the fact that non-RTCP peers 
shouldn’t be on the network in the first place, a circuit-breaker 
implementation shouldn’t talk to them even if they are? That is, even 
if the peer has a "good reason" (in an RFC 2119 sense) to violate that 
SHOULD, circuit-breaker implementations should ostracize it? :-)

-4.2, last paragraph, sentence starting with "In this case"

Does this imply that the SHOULD only applies if the sender has reason to 
believe that the SR or RR packets will be too large? or should the 
sender always behave this way?

How does this relate to the guidance (MAY) in section 8?

- 4.3, 6th paragraph:"Implementations that desire this extra sensitivity 
MAY use the full TCP throughput equation in the RTP circuit breaker. "

Is there potential for the extra sensitivity to do harm (beyond the 
higher calculation complexity)?

-4.4, 2nd to last paragraph, last sentence:

Is there any potential guidance on reasonable lower limits to the time 
period considered "significant"?

- 12.2:

It seems like the following references might should be normative: 
I-D.ietf-tsvwg-circuit-breaker, RFC3168, RFC6679

Editorial
=========

- Abstract
s/"will deteriorate"/"will cause the deterioration of"
-- "This acts as a safety measure..."
What is the antecedent for “this”? Congestion control? The 
deterioration? (Also, this sentence contains a comma splice)

- 1:
A very short definition of what we mean by "circuit breaker" might be 
useful.

- 3:
It's a little odd to find 2119 keywords imbedded in term definitions. 
You might consider moving those to procedure sections. (OTOH, it may not 
be worth changing this late in the process.)

-4.2, last paragraph:
What would it even mean to maintain a timeout past the end of the 
related stream?

-4.3,

-- paragraph 6:
typo: s/throughout/throughput

-- paragraph 9: "MUST record the value of the fraction
    lost field in the report block"

Does this mean the field _from_ the report block? (That is, you aren't 
_writing_ the value in the report block?)

-9, last paragraph:

Is this paragraph really related to security? It sounds more like an 
operational consideration.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Feb 2016 16:39:08 -0600

Hi,

I had one additional question that I forgot to include:

There was a brief thread on the wg list about practical implementation 
experience. Simon started the conversation starting with [1]. Has that 
conversation been resolved, at least to the extent it can?

[1] 
https://mailarchive.ietf.org/arch/msg/avt/3MHdwQzBhpYzTiM5SJeHLnULEbs

Thanks!

Ben.

On 24 Feb 2016, at 16:19, Ben Campbell wrote:

> Hi,
>
> This is my AD Evaluation of 
> draft-ietf-avtcore-rtp-circuit-breakers-13. While I do have some 
> comments and questions, I don't think anything here needs to block 
> IETF last call. Please address these along with any other last call 
> feedback.
>
> Thanks!
>
> Ben.
>
>
> Substantive
> ===========
>
> -4, third paragraph, sentence starting with "This approach SHOULD NOT 
> be used..."
>
> implementation shouldn’t talk to them even if they are? That is, 
> even if the peer has a "good reason" (in an RFC 2119 sense) to violate 
> that SHOULD, circuit-breaker implementations should ostracize it? :-)
>
> Does this imply that the SHOULD only applies if the sender has reason 
> to believe that the SR or RR packets will be too large? or should the 
> - 4.3, 6th paragraph:"Implementations that desire this extra 
> sensitivity MAY use the full TCP throughput equation in the RTP 
> circuit breaker. "
>
> You might consider moving those to procedure sections. (OTOH, it may 
> not be worth changing this late in the process.)
>
> -4.2, last paragraph:

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Feb 2016 17:02:12 -0500

> conversation been resolved, at least to the extent it can?

As far as I am concerned:

- The authors added good text about how to handle non-conforming
implementations.

- Even with that text, non-conforming implementations are so common in
practice as to make this whole idea inapplicable to the SIP world in
general. I admit WebRTC might be different and having WebRTC endpoints
implement this algorithm would probably make sense, because they would
be less likely to have to interoperate with broken implementations.

Just my 2 cents.

Simon