Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

[Sebastian Moeller <[e-mail]>]

Hi Greg,



> On Sep 13, 2019, at 01:34, Greg White <[e-mail]> wrote:
> 
> Sebastian,
> 
> Since it seems we’re going in circles (or maybe it's a very slowly converging spiral), why don't I make the edits that I think you want to see, and then we can go from there.

	[SM] I am all for that approach, and I want to repeat that I realize that I am not the arbiter in this matter and convincing me (while nice from my perspective) is not important, convincing the chairs that my objections are baseless or handled well seems more important. 
	Since I seem to be the main person in this discussion with the "how does it look from the receiving end/end-user perspective" hat on, I will try to stay maximally critical (but let me repeat that I like the idea in general, modulo the side-effects I predict from a few of the detail-choices in the draft) that might be annoying on an inter-personal social level, but hopefully leads to a better technical soution.


> 
> Based on your arguments, I've agreed to add some detail in a section on "Applicability" that indicates more concretely that the intent of the NQB marking is not for capacity-seeking traffic.  That text will supplement the existing language in section 3 of the draft that currently reads:
> 
>  There are many applications that send traffic at relatively low data
>   rates and/or in a fairly smooth and consistent manner such that they
>   are highly unlikely to exceed the available capacity of the network
>   path between source and sink.  These applications do not make use of
>   network buffers, but nonetheless can be subjected to packet delay and
>   delay variation as a result of sharing a network buffer with those
>   that do make use of them.  Many of these applications are negatively
>   affected by excessive packet delay and delay variation.  Such
>   applications are ideal candidates to be queued separately from the
>   capacity-seeking applications that are the cause of queue buildup,
>   latency and loss.
> 
>   These Non-queue-building (NQB) flows are typically UDP flows that
>   send traffic at a lower data rate and don't seek the capacity of the
>   link (examples: online games, voice chat, DNS lookups).  Here the
>   data rate is essentially limited by the Application itself.  In
>   contrast, Queue-building (QB) flows include traffic which uses the
>   Traditional TCP or QUIC, with BBR or other TCP congestion
>   controllers.
> 
> If you can point out specifically what in that text led you to believe it was intended for capacity-seeking traffic, I would appreciate it.

	[SM] Given how much language lawyering is applicable on when parsing RFCs I would like to see more precision for the following terms:

"relatively low data rates" as an application developer how do I decide what is relatively low? Or put differently relative to what exactly. Also If I have a paced-UDP based video delivery application that does application level switches between different bitrates based on experienced buffering/capacity/delay (like a paced DASH equivalent over UDP, or given that the sending rate for each segment is essentially fixed even standard paced-DASH) does this qualify for NQB or not? I believe the draft should make it crystal clear what can and what can not be considered to be NQB material.

"such that they are highly unlikely to exceed the available capacity of the network path between source and sink" while I understand the thought behind this, it is simply impossible for an application to know that, given that "available capacity" is not fixed (also a sending application will have very little information about the available path capacity when it starts). Maybe I am being to pedantic here, but starting with a wrong premise irks me.

"(examples: online games, voice chat, DNS lookups)" this still has the DNS lookups which collide with rfc8325, I understand why giving DNS lookups a low latency treatment (as DNS latency this directly translates into browsing latency, albeit only for uncached entries), but keeping DNS here has consequences on the wifi section IMHO.

"Queue-building (QB) flows include traffic which uses the Traditional TCP" why the qualifier? As far as I understand TCPPraque would also be classified to the QB queue by virtue of being capacity seeking. In a sense Prague is included in the "other TCP congestion controllers" set, but I would prefer a less ambiguous wording like 

"In contrast, Queue-building (QB) flows include all flows which seek to utilize the full capacity of the link like all TCP flows, as well as many SCTP  and UDP flows, like QUIC"
If you want you can add "all TCPs independent of the used congestion controller". 
If you disagree and believe TCPPrague should be allowed in the NQB queue, then at say so explicitly (but as far as I understand you really want to exclude all TCPs).

Or put differently I would like to see a description of the behavior precise enough that I can easily deduce from a packet capture whether a given flow meets the NQB requirements, in a sense an enumerated list of expected behaviors and of behaviors that disqualify for NQB marking/treatment.
I believe that would be in agreement with the stated goal that "the NQB designation and marking would be intended to convey verifiable traffic behavior, not needs or wants"



	Conceptually my next issue is that I think just trusting the end-points to mark correctly is too optimistic and that any scheduler giving special treatment according to NQB-ness must be required to ascertain that each individual flow is behaving according to the NQB requirements and ideally re-mark non-compliant flows CS0 to protect downstream devices (if NQB maps to anything but AC_BE). This requirement mainly is driven by the side effects NQB will have on wifi, so if the special wifi power of NQB goes away, this issue gets less important to me (also there are wifi scenarios where queue protection as proposed upstream will not be sufficient).


	Final and strongest objection: incompatibility between current wifi gear and NQB. 

I hope we can all agree that :

a) Wifi is a shared system not only between up- and downstream between stations and APS, but also due to the fact that the same frequency bands are often shared between different wifi networks (either directly be using the same center frequency band, or by overlap of the side-bands).

b) no currently deployed wifi gear (NICs and APs) supports special treatment for NQB flows.

c) most deployed gear supports access classes and will in all likelihood use the default DSCP to AC mapping you described in a different post. (as far as I can tell WMM is mandatory for wifi >= 802.11n)

d) The AC priority system is essentially a (weak) precedence system (lower ACs might sneak in a tx_op even with higher AC queues full, but that is gong to be rare and can result in multi second delays for packets in the lower ACs, as observed in my home network). So in traditional thinking using ACs requires some sort of access control/rate limiting to avoid undesired starvation issues.

e) For quite a number of end-users the wifi rate is what limits the internet access and not the access link itself (at least for higher bandwidth internet plans in crowded RF environments like apartment buildings)

f) NQB is not intended to reduce the "performance of QB flows" but rather isolate well behaving sparse and/or paced fixed-rate traffic from the transient queue building effects of non-paced non-rate-limited flows.

g) NQB is intended such that  "that malicious or badly configured nodes can't abuse it."

h) NQB traffic is not rate limited or rate policed. Even if each individual flow is self rate-limiting the aggregate clearly is not intended to be.

i) For QB flows, the QB queue provides better performance (considering latency, loss and throughput) than the NQB queue

j) NQB-marking (hopefully) will one day survive end to end.

Now, from e) it follows that the ISPs upstream NQB aware AQM will not trigger in quite a number of instances, so making sure that NQB does no harm is up to the wifi gear. Due to h) it is clear that NQB traffic will be able to saturate the wifi link. Together with c) and d) this means that the mapping of NQB to AC by the default rules will define the precedence level of the saturating traffic. Due to a) good wifi citizens try to be considerate in not hogging a channel to themselves (and due to CSMA/CA users on the same channel should stochastically share tx_ops "fairly" in each AC). Most wifi traffic currently is using AC_BE, but due to j) and h) that might change in the future.

I now argue that using anything but AC_BE for NQB will violate f) and g). Essentially in this not unlikely scenario NQB will confer a super-power (lower latency and higher bandwidth) without any checks and balances (incompatible with g)). 
To make it explicit, with ACs > BE in play, AC_BE will essentially only get the left-over bandwidth, which runs counter to i) as now QB flows need to mark themselves such that they also get scheduled into the same AC as NQB to get a level playing field.


For me that obviously means that the choice of DSCP for NQB needs to take care that the above scenario can not happen.
So I vote to follow Ruediger's proposal for a 000xx1 codepoint for the intended PHB such that the status quo is not negatively affected. With the added bonus that this now has a chance of actually surviving end to end today.
NQB aware APs/NICs can then implement proper NQB handling with or without selective priority boosting to different ACs while making sure no other flows/APs are starved.


Since I have made this point several times, without convincing you, I would be happy to hear your rationale why this scenario is unlikely enough to still justify aiming for a DSCP that maps to a AC > BE?
Ideally that rationale would be more refined than just noting, that this kind of abuse is possible already today, the aim should be to at least "do no harm", not just "do not make it significantly worse".


Best Regards
	Sebastian