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

["Black, David" <[e-mail]>]

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

Understood, and I'm not asking for that.  I view the current text as providing implementers
with too much latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
want to think about this problem space in the first place).

Could someone propose initial text to qualifies the current "MAY ignore" statement?

I'm looking for some sort of applicability and prerequisite text that describes the
situations and design aspects that ought to be considered before an implementation
decides to ignore ECN-CE marks.  

Thanks, --David

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Wednesday, June 15, 2016 11:04 AM
> To: Black, David
> Cc: Magnus Westerlund; IETF AVTCore WG; [e-mail]; tsvwg
> Subject: Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-
> circuit-breakers-16
> 
> > 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/
> 
> 
>