Re: [tsvwg] NQB - which DSCP to recommend?

[Pete Heist <[e-mail]>]

> On Nov 17, 2019, at 9:51 AM, Jonathan Morton <[e-mail]> wrote:
> 
>> On 16 Nov, 2019, at 11:27 pm, Sebastian Moeller <[e-mail]> wrote:
>> 
>> to cut though too many words and detailed arguments, the choice before us seems ultimately between:
>> 
>> A) a DSCP that will give NQB precedence on most existing wifi networks out there, like Greg's0x2A, on the hope that this will have no/little negative side-effects, but maximizing the number of users/networks that potentially can enjoy NQB's promise of low latency over wifi networks.
>> 
>> B) a DSCP that will map NQB into AC_BE and hence will not give NQB precedence over "normal traffic" by default, like my proposed 0x6, knowing that there will be no side-effects, but limiting the number of users seeing the "full potential" of the NQB PHB over wifi.
>> 
>> So it is effectively a decision between potential gain and risk. 
>> IMHO the risk is substantial and easily confirmed in the lab (run flent's rrul_cs8 test through an WMM AP and see the higher AC's dominate AC_BE) but hard to diagnose in the field, while the gain is mostly based on lab experiments and not guaranteed to to actually work as designed out in the real world (at least I have not seen any published data). 
>> 	So I vote for B), it does not necessarily be 0x6, as long as it by default stays in AC_BE. So Jeromes proposal of placing NQB "into CS3" is just as acceptable to me. 
> 
> I agree with Sebastian here.
> 
> To put a finer point on the argument, note that the negative effects on wifi performance are most likely to be noticeable to close *neighbours* of each subscriber using NQB traffic, if the latter falls into AC_VI.  This is simply due to the way that the wifi MAC contends for the shared RF medium.  This is technically known as an "externalised risk", and is something the IETF should be very concerned with avoiding.

Hi Greg, while on the ‘ietf’ WiFi network, I tested traffic with fping and irtt as follows:

fping -O 0 -c 10 <router ipv4 addr> # all round trips passed
fping -O 0x20 -c 10 <router ipv4 addr> # CS1, all round trips passed
fping -O 0x80 -c 10 <router ipv4 addr> # CS4, no round trips passed
fping -O 0xa0 -c 10 <router ipv4 addr> # CS5, no round trips passed
fping -O 0xa8 -c 10 <router ipv4 addr> # EF, no round trips passed

irtt client -d 10s --dscp=0 <irtt server ipv6 addr> # all round trips passed
irtt client -d 10s --dscp=0x20 <irtt server ipv6 addr> # CS1, all round trips passed
irtt client -d 10s --dscp=0x80 <irtt server ipv6 addr> # CS4, only first round trip passed
irtt client -d 10s --dscp=0xa0 <irtt server ipv6 addr> # CS5, only first round trip passed
irtt client -d 10s --dscp=0xa8 <irtt server ipv6 addr> # EF, only first round trip passed

Note that the -O flag for fping (on Mac) and the (poorly named) --dscp flag for irtt both specify the _entire_ DS (former TOS) field.

The results suggest that, regardless of which DSCP value is chosen, applications may need to be prepared to fall back to DSCP 0. Perhaps worth an addition to the draft?