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

[Bob Briscoe <[e-mail]>]

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:
>
>  1. [snip]
>  2. 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.

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.

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.

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



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] <mailto:[e-mail]>
>
> ----------------------------------------------------------------
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/