Re: [tsvwg] Dual-Q Polcing

[Gorry Fairhurst <[e-mail]>]

I'm going to leave others to pick-up on just a few details at the end.

On 27/05/2020 09:58, Sebastian Moeller wrote:
> Hi Gorry,
>
>
>> On May 25, 2020, at 12:22, Gorry Fairhurst <[e-mail]> wrote:
>>
>> See below, I'll try to explain how I hope this can focus on the documents.
> 	[SM] Sure, I just want to note that I see the lack of properly assessing and addressing the security questions, not an issue about the wording of a few specific paragraphs, but rather a systematic decision that permeates the whole dratfs. Hence fixing these will not result in just a few changes to the security considerations section IMHO. Sure we can discuss these specifically, but I do not believe that we will be able to remedy that whole rather cavalier approach to security there.
>
>
>> 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.
> 	[SM] I disagree, I cited two closely related sections from both the dual queue coupled AQM and the L4S arch drafts, that both display the same cavalier approach to safety ("could be necessary", "it is hoped..."). I consider it essential to align all L4S drafts with reality.
>
>> So, a conversation needs to focus on the appropriate document and a specific section.
> 	[SM] Let's focus on the big picture first, please. I do not intend to go on a quixotic quest against wind-mills, if the consensus in the WG is that none of these changes I argue for are necessary in the first place. (I will keep speaking my mind, but I will not embark of detailed text exegesis if I perceive this to be a fools errand).
>
>
>>> 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.
> 	[SM] That leaves me puzzled. Given the absolute lack of testing under realistic conditions that will be encountered at the ISP customer edge (including, bi-directionally saturating loads, asymmetric links, multi-hop paths across countries/oceans (where multiple nodes will add to latency and jitter), ... ), I fail to understand how we actually continue with text details, while the proof that the core promises actually are deliverable in the real-world is still missing? Rearranging the deck chairs of a certain ship of the White Star Line comes to mind.
>> But, my email is urging you to separate the pieces.
> 	[SM] Divide et impera, eh? ;)
>
>> 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.
> 	[SM] We need to address the fact that L4S will make this issue more urgent, until now ECN is mostly an "also ran" so playing games with ECN will have little ROI, once the DOCSIS-edge is switched to L4S that value equation changes massively (and to their credit CableLabs created and mandated? the queue protection system to avoid this easy to predict pitfall).
>
>
>> For example, it wouldn't be wise to suggest a scheduling-based approach eliminates all the problems
> 	[SM] +1; but in reality eleminating "all problems" typically is not feasible, but concluding from a perfect solution is not possible/desirable, that no solution is just as good, seems a bit counter-intuitive.
>
>
>> - 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.
> 	[SM] Gorry, please help understand, how a circuit breaker is going to help against the new class of attacks made possible by the L4S core design: non-paced bursts of ECT(1)-marked packets, that over a multi-dozens of millisecond window average out to below capacity rate, yet repeatedly drive the dualQ AQM into overload protection? This completely takes L4S, low-latency and low-loss promises off the table, yet is really hard to detect from just monitoring the incoming and outgoing aggregate traffic levels.
> 	Now, it s well possible that I misunderstand what a circuit breaker is and how sensitive it can be while still staying useful, but I can not help to think that the interactions between the promosed components have not yet been carefully thought through, let alone tested.
>
>> Anyway, what I am suggesting is decide on a topic, relate this to a particular topic and a particular draft.
> 	[SM] QUESTION: We have been promised a less enthusiastic worded version of these drafts, are these forth-coming? I would like to avoid spending time with a soon to be replaced version. (Not that I expect that the result of my text exegesis will actually flow back into the drafts, Bob has made it abundantly clear, that he emphatically does not share my risk assessments).
>
> Best Regards
> 	Sebastian
>
>
>> 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

-- 

I would generally encourage people to separate security considerations 
from congestion control/traffic sharing issues.

Reducing claims about performance/features in drafts is always welcome. 
For the WGLC, we need to finally balance protocol design goals, against 
claims of what is offered, and doing this before WGLC is generally helpful.

The WG Chairs and ADs have been discussing what topics should best be 
included in which documents. My own suggestion would be to allow a few 
weeks for the document editors to digest this and then propose what 
needs to be done in the next steps to take this forward.

Gorry

G. Fairhurst, School of Engineering