Re: [tsvwg] Dual-Q Polcing

[Sebastian Moeller <[e-mail]>]

Hi Gory,

more below in-line.


> On May 25, 2020, at 11:02, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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".

	[SM] Which boils down to the same more or less, IMHO. Point being instead of attempts at measuring realistic traffic scenarios (like e.g. flows using different initial window sizes as some CDN's are known to use, see https://www.comsys.rwth-aachen.de/fileadmin/papers/2019/2019-rueth-iwtnsm.pdf), all that is offered is a hope. I certainly also hope that this will not become an issue, but IMHO that does not take tho onus from the designers/developers of a solution to test under realistic adversarial traffic conditions, before simply relaying on hope. Why is that view even contentious? 
	Is everybody else convinced that L4S offers a sufficiently safe design and was tested with the to be expected level of adversarial traffic patterns to confirm the design's safety in the real-world?

Best Regards
	Sebastian



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