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

["Black, David" <[e-mail]>]

[Writing as an individual]

The core of my current views is this:

> ... “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 see serious potential here for a "tragedy of the commons" outcome where lots of QB traffic is sent marked NQB because the resulting latency is (at least initially) lower.

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

I want to see clear and convincing evidence that the "tragedy of the commons" outcome is highly unlikely, which this text ...

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

... is not.

The above text not only reverses the burden of proof but also changes the question from whether a "tragedy of the commons" is possible to whether it will always (categorically) happen - the resulting straw proposition is then easy to demolish.  Nice try, no sale ... or as Sebastian writes:

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

I agree.  As for requirements language ...

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

... a common IETF approach to this sort of uncertain situation is "MUST implement, SHOULD use" with discussion of when the "SHOULD" may not apply and/or possible consequences of ignoring the "SHOULD."  The underlying rationale is that the functionality will be available for use if/when the need for it is discovered in a fashion that surprises the network operator.  It is much easier to relax "MUST implement" based on implementation experience than it is to upgrade "SHOULD implement" as the former doesn't have the potential to break any "running code" implementations.

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

I understand the TCP congestion control history, and the even-more-relevant ECN for TCP history, where there was a serious potential for a "tragedy of the commons" outcome - ignoring ECN congestion indications was a potential new way to cause congestion collapse of the Internet (fortunately, that did not happen).  There are at least a couple of aspects that seem rather different in the current situation:
- At the time, the IETF community had strong influence over the important TCP stacks. 
	The network stacks have gotten much more diverse since then, and a lot of NQB traffic
	can be expected to come from applications that have a much weaker relationship to the IETF community.
- Switching away from TCP to UDP was a high hurdle, e.g., as TCP uses stream sockets, whereas UDP uses datagram sockets, and ECN functionality was in the core of TCP implementations.
	The hurdle here is much lower, particularly for applications that already use UDP.

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

I concur with Sebastian that the onus is on the proposers of the complexity/cost savings to demonstrate that the resulting designs are safe for the Internet.  I'm reminded by analogy of something that my software engineering professor said back when I was in grad school - "I can make the code run arbitrarily fast if it doesn't have to be correct." [Mary Shaw]

Thanks, --David

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: Tuesday, September 3, 2019 5:15 AM
> To: Bob Briscoe
> Cc: Black, David; [e-mail]
> Subject: Re: [tsvwg] Traffic protection as a hard requirement for NQB (was:
> WG adoption of draft-white-tsvwg-nqb!)
> 
> 
> [EXTERNAL EMAIL]
> 
> 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/