Re: [tsvwg] Dual-Q Polcing

[Gorry Fairhurst <[e-mail]>]

See below, I'll try to explain how I hope this can focus on the documents.

On 25/05/2020 11:00, Sebastian Moeller wrote:
> 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.
Not really, this document is proposed as an AQM Spec. To me, traffic 
management, scheduling, etc belong in a draft about architecture or 
operations. So, a conversation needs to focus on the appropriate 
document and a specific section.
> 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

I do like data - that is good.

But, my email is urghing you to separate the pieces.

If for instance, one was to consider traffic unresponsive to ECN 
signals, then this is a particular case of non-conformant traffic - we 
all see non-conformant traffic in networks for various reasons and need 
to have tools and methods to deal with that - what a network decides to 
actually use will depend on many things. For example, it wouldn't be 
wise to suggest a scheduling-based approach eliminates all the problems 
- in some parts of the network this has always been the case, in other 
places it is not a useful technique. similarly circuit-breaker methods 
have their place, as likely does a policer.

Anyway, what I am suggesting is decide on a topic, relate this to a 
particular topic and a particular draft.

Gorry

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