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

Pete Heist <> Sun, 17 November 2019 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB7D21200CC for <>; Sun, 17 Nov 2019 00:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qXUhvXk68kKr for <>; Sun, 17 Nov 2019 00:22:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4358A1200C4 for <>; Sun, 17 Nov 2019 00:22:25 -0800 (PST)
Received: by with SMTP id bo14so613726pjb.1 for <>; Sun, 17 Nov 2019 00:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X9tHAVb5cT+oZSB5PHLyr2Kzm9ryvmyaWqb/NhCuYx4=; b=QEZ9wwtfQDYwiHRWlp/cLo8zOPEufBAyI+bSFrcuW8s/Mv6s9gpoQd3tYiI6qVV2Yb GziXL9Bv3g7r+kUe1Qax1XtR/ajhGFhNLNLd//7Gq8CMH6RDIW0RATtQvUidJmLfrlGy C63hUuA6OEjkDMiyNRmzON9krfto+5h7pu7wbws6Rnn4TfE9orL4N0CtIPbILhJB2MM1 ZtiOTr3DAc8H9KSM4duFc2JGy+NrcvdTbRplLdvEJ2EFmu8bkYtYh/R+CjhXHqFyVRoP dD8q7W5fL7O98dWG09zu5dNfPDS139X3VUWMqG40GqK610A7y9g/4H0EwfqBK0IjU4w8 gLAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X9tHAVb5cT+oZSB5PHLyr2Kzm9ryvmyaWqb/NhCuYx4=; b=N95F9Rj5XhWssvAaSrKSE0Nnbay6RP/AUqL+DQ0KKjJR5QcM0eq4FeY6eG3kessHOq QIMxcwylo60lY5UDTczGd8ihqs2/jXsO5ble6mSymXoy/2oN7CnIXJ45Vbj0JIoBAAbA QB6QQk42xwswk5qTeKSMWj/lAAtblb5Aj3h4XuIA00d9GCKPNbDES5kaJ5PW61/igje6 TzK6jSfVKw+0HBXMvDXoTT2xbgOSZUoEqnDs5rIk9DGb46YsDHHJxZWMUjE/1RmE2l2q AAZaVYRp4i4R6ZhscIggzoC48pXpQT/GxSDZYLTAx9IDMSiRyJzbaKXrXwYjFxTw3yf9 BGsw==
X-Gm-Message-State: APjAAAWHSAEkcdZpgbOtD2f3XfPm56Up/fomxdbrR8KX7t8C0FdKJWhp ja9MHauw3PMvNbFftI2/v6FfNQ==
X-Google-Smtp-Source: APXvYqzJ1Wmk/RJaTvLwwbDmOEjrDq5STrB6MImHGjPlXdBUMiptokuwpzqh0M/MOFDNjhCacCoD7w==
X-Received: by 2002:a17:902:9686:: with SMTP id n6mr23269790plp.249.1573978944459; Sun, 17 Nov 2019 00:22:24 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:f020:1c1d:47c2:5fac? ([2001:67c:370:128:f020:1c1d:47c2:5fac]) by with ESMTPSA id h13sm17858574pfr.98.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 00:22:23 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <>
In-Reply-To: <>
Date: Sun, 17 Nov 2019 16:22:21 +0800
Cc: Sebastian Moeller <>, Jonathan Morton <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <LEXPR01MB118358214565EA8E73B929539C700@LEXPR01MB1183.DEUPRD01.PROD.OUTLOOK.DE> <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] NQB - which DSCP to recommend?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2019 08:22:27 -0000

> On Nov 17, 2019, at 9:51 AM, Jonathan Morton <> wrote:
>> On 16 Nov, 2019, at 11:27 pm, Sebastian Moeller <> 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?