Re: [tsvwg] Traffic protection as a hard requirement for NQB (was: WG adoption of draft-white-tsvwg-nqb!)

[Sebastian Moeller <[e-mail]>]

Dear Bob,

allow me to chime in.

> On Sep 2, 2019, at 16:47, Bob Briscoe <[e-mail]> wrote:
> 
> David,
> 
> Thanks for your closing remarks on the NQB adoption call. 
> You say your last point is open for discussion, so I will dive straight in to start that discussion.
> 
> On 30/08/2019 16:40, Black, David wrote:
>> 	• [snip]
>> 	• The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation. [snip]
>>  
>> In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.
> I think we should be wary of making traffic protection a hard requirement at such an early stage in our knowledge of the NQB behaviour. I believe this is a case where the market, not the IETF, ought to decide whether protection is required. 

	[SM] The draft says "... it is worthwhile to note that the NQB designation and marking would be intended to convey verifiable traffic behavior, not needs or wants." in the light of this requirement it seems obvious that a hop willing to honor that DSCP should/must actually verify the traffic behavior, no? Requiring behavior to according to a set of requirements but not enforcing these requirements seems very very optimistic.


> 
> The draft claims incentives can be aligned by an implementation being arranged to ensure that NQB traffic benefits from NQB marking and QB traffic benefits from QB marking. Incentives are hard to guess, so that may or may not be true. However, I don't think we (the tsvwg/IETF) can state categorically that it is not true.

	[SM] I would have thought it would be on those claiming a laxer enforcement model to proof that that model is sufficient?

> 
> The draft makes the point that, even if incentives are aligned, queue-building traffic could be mismarked as NQB, either accidentally or maliciously. That's a sound reason for an implementer to include traffic protection, but I don't think it's a good reason for us (the tsvwg/IETF) to require them to.
> 
> While there is no operational experience of NQB deployments, I think the market (i.e. most early-adopting operators) will want the warm feeling of some form of traffic protection. But as we get more experience we might find incentives really are aligned. And we might find accidents and malice are not a significant problem.

	[SM] @ the chairs, how hard would it be to retroactively change from a SHOULD to  a MUST? If it is easy I agree with Bob that a SHOULD would be nice, but if it is hard I would vote for a MUST as that seems to be the safer option.

> 
> So I think the current 'SHOULD' is the right call. It could be beefed up with warnings on the risks of not providing protection - not least the risk no early adopter will want to use such an implementation. 
> 
> 
> 
> As an analogy, when TCP congestion control was first developed, it was known that end-systems could run a subverted TCP algorithm or just use unresponsive UDP. At that time, the view could have been taken that per-flow scheduling would have to be a 'MUST' requirement for all Internet bottlenecks.
> As it has turned out, the Internet does have /per-user/ scheduling at bottlenecks,

	[SM] Question is this universally true? I am not 100% sure. My access link is limited by my contracted rate, but due to oversubscription there is no guarantee that on a congested link between my home and my ISP's traffic-shaper/the wider internet I get a share that reflects my "per-user" fraction of the shared capacity. 
	I fail to see any scheduler beyond my ISPs traffic shaper that has a wholistic-enough view to classify traffic based on "user" (think NATed IPv4 address, but variable length IPv6 prefixes, plus a router's ipv6/64), could you elaborate please? 

> but there has been little need for /per-flow/ scheduling for capacity sharing (yes, FQ exists, but it's not needed for capacity sharing).
> 
> In the TCP case, it turned out that a delicate balance of incentives proved sufficient to allow most Internet equipment to be simpler and cheaper. There is a poorly understood balance of incentives in the NQB case. So let's not require equipment to be more complex than it might need to be, at least not yet.

	[SM] I believe for malicious actors NQB will be a attractive DSCP as it promised to allow doing harm even at low bandwidth (just send a low average rate in lumpy bursts and I would expect an NQB-honoring L4S scheduler to get into trouble*, without requiring a large offensive traffic load, keeping it cheap and hard to detect yet sufficiently disruptive to rob the low latency queue of its intended functionality).


*) This is a hypothesis I have not confirmed in any way, but it seems to be in line with how I understand dual queue aqm to work (so it might be more of a reflection of my level of understanding and not so much of dual queue aqm). Please correct me if this seems wrong.

> 
> u
> 
> Bob
> 
> 
>>  
>> Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
>> ----------------------------------------------------------------
>> David L. Black, Senior Distinguished Engineer
>> Dell EMC, 176 South St., Hopkinton, MA  01748
>> [phone] New    Mobile: [phone]
>> [e-mail]
>> ----------------------------------------------------------------
>>  
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/