Re: [tsvwg] Traffic protection as a hard requirement for NQB

[Sebastian Moeller <[e-mail]>]

Dear Bob,


> On Sep 11, 2019, at 00:49, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian,
> 
>>>> [...]
>>> You're right that, when the NQB draft says it is compatible with l4s-arch, it means it is compatible with the structure of the architecture, not necessarily the specific recommended numbers in one of the example implementations in aqm-dualq-coupled.
>>> 
>> 	[SM] Well, as far as I can tell these are the only numbers around.
>> 
>> 
>> 
>>> Indeed, in Appendix A of aqm-dualq-coupled, note b says that two separate buffers might be preferred to a shared 250ms buffer [and the Low Latency buffer would not need to be more than a few ms].
>>> 
>> 	[SM] Indeed, except I can not find the part in brackets in that draft. 
> [BB] That's the reason it's in brackets.

	[SM] As a reader of an RFC I often like such details explicitly spelled out, especially with the rationale behind such a choice.

>> Setting the Low Latency buffer to only a few milliseconds, will then make the whole low latency queue susceptible of the attack scenario I described before, is that really an improvement (and helping your cause])? 
> [BB] It is intended to align incentives. If someone is minded to attack a queue, they always have numerous approaches available in their armoury. Per-flow traffic protection is designed to address that. 

	[SM] So why fight against making that kind of protection mandatory then?

> 
> You keep repeating the same arguments about vulnerability and keep ignoring the argument that vulnerability is not a reason for the IETF to mandate protection.

	[SM] Not ignoring, rather (so far) silently rejecting. RFC2119 states as justification for the use of imperatives "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm". And here I see the " limit behavior which has potential for causing harm" clause triggered. You might disagree with this assessment, but arguing that there is no justification for mandating SHOULD/MUST implement/enable queue protection seems a bit extreme.

> 
> Every RFC is vulnerable to such attacks (including other Diffserv PHBs). None make protection against such attacks mandatory. Because in the IETF MUSTs are standardization language, not general     importance language.

	No, I disagree, not all RFCs define new methods that can be used for targeted attacks in such a convenient way that an unprotected NQB-queue will. I am happy to discuss specific relevant other RFC's but argueing over the whole set of RFCs seems to be a waste of time.

> 
>> 
>>> That said, here's a strawman (i.e. not tested, but for you to bash) for adding NQB support to the DualPI2 example in appendix A of aqm-dualq-coupled:
>>> 
>>> * Classify NQB packets as well as L4S ECN into the Low Latency queue
>>> * Don't subject NQB packets to the L4S AQM (unless their ECN field is also L4S).
>>> 
>> 	[SM] You are talking about the ECN marking component only here?
> [BB] Yup, There's a special case in the aqm-dualq-coupled draft at S.2.5.1.1. for Not-ECN packets classified into the L queue in a 'no protection' case:
>             the L AQM 
>             SHOULD apply drop using a drop probability appropriate to
>             Classic congestion control and appropriate to the target
>             delay in the L queue
> 
> In DOCSIS, if the operator disables protection, it implements this special case using tail drop in the shallow buffer I mentioned. Alternatively, for a DualPI2 implementation without QProt, its L4S AQM could drop Not-ECT NQB packets with the square of the probability output by the L4S AQM.

	[SM]Thanks for clarifying!

> 
> 
>>> * During overload, subject all packets to the same drop prob (Classic, L4S and NQB)
>>> 
>> 	[SM] Is there any other option, unless one wants to effectively starve all other traffic "classes"?
> [BB] Access links generally do not include anything to handle overload attacks on their current (FIFO) links. Some ISPs provide DDoS detection, redirection and scrubbing services in their core. Access links are usually rudimentary, simple things though.
> 
> One could apply per-flow protection. However, here we're talking about options if the implementer has chosen not to implement traffic protection. 
>> 
>>> * add a 3ms sojourn limit for packets marked NQB (but not L4S), after which they are dropped
>>> 
>> 	[SM] Great idea, looking forward seeing this in the next dualQ draft! 
> [BB] I think you're misunderstanding the purpose of the appendix in the draft. It's an example for tutorial purposes.

	[SM] But this recommendation you gave for NQB is in violation with the dualQ draft recommendation:
"if separate queue protection is not provided, the L AQM SHOULD apply drop using a drop probability appropriate to Classic congestion control and appropriate to the target delay in the L queue"
A "target delay in the L queue" is not given explicitly, but looking at the pseudocode that might be this value would be around 1ms for L4S traffic (pi2: minTh+range = 475 + 525µs = 1 ms, curvy RED: T = 1ms), so without special casing for 3ms sojourn time the draft recommends 1ms sojourn time. What am I missing?





> 
> I have no intention of adding NQB support to that tutorial example, which needs to focus on explaining the Coupled DualQ, not get cluttered up with extraneous details like optional extra DSCPs, and corner case pseudocode.

	[SM] Sure, that draft is on the longish side already. How about then also removing the following section:

"In addition, an operator could use other identifiers to classify certain additional packet types into the L queue that it deems will not risk harm to the L4S service.  For instance addresses of specific
   applications or hosts (see [I-D.ietf-tsvwg-ecn-l4s-id]), specific Diffserv codepoints such as EF (Expedited Forwarding) and Voice-Admit service classes (see [I-D.briscoe-tsvwg-l4s-diffserv]) or certain protocols (e.g.  ARP, DNS).  Note that the mechanism only reads these identifiers.  [I-D.ietf-tsvwg-ecn-l4s-id] says it "MUST NOT alter these non-ECN identifiers"."

As this set seems to have a large intersection with the NQB set and hence would ideally have the same treatment?

> 
> But we are planning to add NQB support to the Linux reference implementation of DualPI2.
> 
>> Until then I will assume 250ms/2 as the likely default value. 
> [BB] That would be a very poor assumption. The shared buffer is 250ms to absorb Classic bursts, and the L4S queue just shares a part of that buffer that is typically tiny.

	[SM] Sure typically, but worst case is actually 250ms. I am not much interested in discussing best or average cases here, I want to talk about the pathological cases, or rather those in which queue-protection could potentially help.

> 
> If an implementation used separate buffers, I would advise physical buffer of 250ms at the link rate for Classic and perhaps 4ms at the link rate for L4S, but with this 3ms sojourn limit applied within that.
> 
>> I also note that this adds another complication to dualQ, basically multiplexing a dropping regime into an ECN based system.
> [BB] There would be an extra 'if' per packet (which is why we just used tail drop in a shallow buffer in DOCSIS).
>> 
>>> * It might be necessary to tune down the L4S scheduling weight to bolster the incentive against mismarking, e.g. 3/4 not 15/16.
>>> 
>> 	[SM] You mean the part in the dualQ draft that says " if L4S traffic is over-aggressive or unresponsive, the scheduler weight for Classic traffic will at least be large enough to ensure it does not
>>       starve."? I would not actually direct attention to this part of the dualQ rfc, as for a system that claims to share between L4S and standard-compliant flows only giving 1/16th to the standard-compliant flows is a problem.
>> 
> [BB] You've completely missed the point of the coupling and how it overrides the scheduler. Please read the explanation in the draft (search for the three places where '1/16' is mentioned). It's no wonder you're not impressed with the design if you don't understand how it works.

	[SM] Again, I am not interested in discussing best case scenarios here. The quoted text explicitly allows for a scenario where "L4S traffic is over-aggressive or unresponsive" (which in theory could be avoided by mandatory queue protection?) which will lead to starvation of the standard-compliant queue, so you assign 1/16 of the bandwidth for standard-compliant traffic in that case. Which is a tad below the naively expected 1/1for equal sharing. Now this might be an unlikely scenario, but it certainly is not one I invented, but one from the dualQ RFC that I consider problematic.
	Note how this discussion is unrelated to the normal sharing between TCP-friendly flows and L4S-flows caused by the coupling?


> 
>>> The alternative specified for DOCSIS is to use a 10ms low latency buffer but also to implement per-flow queue protection (which can be disabled by the operator).
>>> 
>> 	[SM] If we are talking about [DOCSIS-MULPIv3.1]  Cable Television Laboratories, Inc., "MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.1-I18-190422", April 22, 2019,
>>               
>> <https://specification-search.cablelabs.com/ CM-SP-MULPIv3.1>
>> .
>> 
>> In Annex N I read: I read: 
>> BUFFER_SIZE                // The size of the buffer for the LL service flow [B]
>>                            //  (see Section C.2.2.7.11.5). A value of 10 ms multiplied
>>                            // by the Maximum Sustained Rate (MAX RATE) is recommended
>> 
>> Naively, I would say this is only 10 ms if MAX RATE equals 1, no? What am I missing.
>> 
> [BB] That means the buffer size in bytes (indicated by '[B]') is 10ms multiplied by MAX_RATE given in the appropriate units (B/ms).\

	[SM] Thanks, my bad, I mis-interpreted that (glad I cited the text though to at least indicate where I screwed up).

> 
> Regards
> 
> 
> 
> Bob
> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>> 
>>> HTH
>>> 
>>> 
>>> 
>>> Bob
>>> 
>>> 
>>> 
>>>> 
>>>> Best Regards
>>>> 	Sebastian
>>>> 
>>>> 
>>>> 
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe                               
>>> http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/