Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

[Colin Perkins <[e-mail]>]

> On 14 Jun 2016, at 15:20, Black, David <[e-mail]> wrote:
> 
>> This resulted in another issue, there are no specified marking behavior
>> that we define an appropriate response based on. When such a behavior is
>> defined one can update circuit breaker with a well defined response to
>> ECN-CE marks. So due to the lack of defined behavior we didn't see a
>> possibility for using SHOULD NOT, as we can't point to what should be
>> implemented. Thus we chose to propose MAY as it then is open to the
>> implementation if they can find a well working response or completely
>> ignore this.
> 
> My problem is that the new "MAY" sentence is unqualified:
> 
>>>   Given the above issues, implementations MAY ignore ECN-CE marks when
>>>   determining if the congestion circuit breaker triggers,
> 
> That invites implementers to ignore ECN-CE marks without giving this topic the
> level of consideration anticipated in this discussion and elsewhere in Section 7.
> If "SHOULD NOT" language is unworkable, please propose alternate text that
> qualifies applicability of the "MAY" - e.g., only after careful consideration of
> everything that we're now discussing and the rest of the text in Section 7.
> 
> I proposed "SHOULD NOT" because it appear that the original RFC 2119 definition
> of that term is a good fit to this situation:
> 
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>   there may exist valid reasons in particular circumstances when the
>   particular behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.

The issue with saying “implementations SHOULD NOT ignore ECN-CE marks”, is that it implies that they should respond to those marks. However, the outcome of the long discussion we had with Mirja was that there’s no consensus on what’s the correct response, and concern that implementations picking the wrong choice will hinder the deployment of ECN. 



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