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

["Ben Campbell" <[e-mail]>]

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