Re: [tsvwg] Dual-Q Polcing

[Gorry Fairhurst <[e-mail]>]

See below.

On 25/05/2020 09:54, Sebastian Moeller wrote:
> Hi Gorry,
>
>
>> On May 25, 2020, at 10:39, Gorry Fairhurst <[e-mail]> wrote:
>>
>> So, this was your comment in Dual-Q:
>>
>> On 25/05/2020 09:13, Sebastian Moeller wrote:
>>> https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11#page-21
>>> :
>>> "Where the interests of users or flows might conflict, it could be
>>>     necessary to police traffic to isolate any harm to the performance of
>>>     individual flows.  However it is hard to avoid unintended side-
>>>     effects with policing, and in a trusted environment policing is not
>>>     necessary."
>>>
>> The general security considerations across section 4 seems reasonable to me.
>>
>> Did you have issues with that text wrt security considerations?
> 	[SM] Yes, certainly I have issues with that. The use of the subjunctive "could" indicates a purely hypothetical concern, or rather that this issue was not actually tackled empirically, yet.
I don't read "could" that way. I read this as this could-be-needed, 
interprettting this as a non-RFC2119 version of "MAY".
> Now, Bob argues* that experimental roll-out is required to test that hypothesis but at the same time fights nail and tooth to even add a MUST implement for his intended counter-measure against such a failure mode, the queue protection. As is this is safety-by-wishful-thinking, and that IMHO is not a solid basis for any IETF condoned experiment or standard.
> 	Initially the L4S argument was, abusing L4S signaling is self-defeating and hence will not happen, due to lack of incentives to do so. As far as I understand that position was retracted (or at least not publicly repeated on the list) based on the discussion, but it has not been replaced with anything else explaining why safety mechanisms can and/or should stay optional, besides hopes and wishes.

I'll let the document editor decide if they wish to respond about 
whether they think more is needed in this section of the DualQ-draft.

>
> Best Regards
> 	Sebastian
>
>
> *) Bob: "I can understand that many operators will be cautious with a new approach, which is why I agreed to design per-flow QProt for Low Latency DOCSIS, even though I do not believe it will eventually prove necessary. That, to me, is one of the open questions that only an Internet-wide experiment can answer, so please refrain from giving your opinion again - we have all heard it many times already."
>
> Note again, Bob's position is based on "believe" instead of hard cold numbers.
>
>> Gorry
Gorry