[FR]

[jlivingood]

Current behavior

Today, when users perform DNS lookups, the query response time (QRT) is highly variable based on any other usage of the user's connection or other traffic at any bottleneck links. This working traffic can cause latency to vary from tens of milliseconds to hundreds or more milliseconds.

Describe the desired feature
Add Dual Queue Low Latency Networking Support (NQB)

Please consider adding server-side support for IETF Non-Queue-Building (NQB) Per Hop Behavior (PHB) as outlined in the IETF TSVWG RFCs 9330, 9331, 9332 and https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/. Specifically, I would like the recursive resolver to set DSCP-45 marking in all packets sent back to users (stub resolvers) in DNS responses. This will have the benefit of marking DNS responses as suitable for placement in the low latency queue at bottleneck links supporting dual queue (such as a CMTS or Cable Modem).

NQB marking enables latency-sensitive traffic like DNS lookups to be handled in a separate queue from classic traffic. The result is that, even when competing with significant other LAN or access network traffic from a user, that the NQB-marked traffic will get very low working latency (usually close to what is observed for idle latency).

Comcast has tested this on resolvers in the lab as part of our low latency field trial of L4S and NQB and found it meaningfully reduced Query Response Times (QRT) under normal working conditions.

Comcast is currently the world's first ISP trialing this in the field and anticipates it being available to millions of end users in 2024.

Enable a new configuration parameter in the server enabling a resolver operator to turn on NQB support. That specifically will mean setting DSCP value 45 in the packet header. This configuration can either cover recursive responses or all outbound traffic from the server (there should be no downside to this).

Potential use-case

If Unbound is used by an ISP with NQB turned on, and the ISP supports the IETF's new dual queue networking standards, then QRT will be consistently low - even in the face of high queue building traffic like file uploads/downloads. This will provide a more consistent and speedy DNS lookup experience for end users.

Links / references

RFC 9330 https://www.rfc-editor.org/rfc/rfc9330.html
RFC 9331 https://www.rfc-editor.org/rfc/rfc9331.html
RFC 9332 https://www.rfc-editor.org/rfc/rfc9332.html
NQB PHB Draft https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
Comcast explainer for app developers https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/App-Developer-Guide.md
Comcast explainer for network operators https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Network-Config-Guide.md
Comcast field trial announcement https://corporate.comcast.com/stories/comcast-kicks-off-industrys-first-low-latency-docsis-field-trials

[edmonds]

This seems pretty easy to accomplish with a stateless host firewall rule marking the outbound responses by matching on the port number, unless you need the capability to selectively apply the marking to certain DNS responses and not others (e.g. based on domain name). What is the benefit to doing the marking inside the resolver?

A few years ago BIND removed and deprecated general purpose DSCP marking (not just marking with a particular value) from their daemon. See these two threads on the bind-users mailing list:

• https://lists.isc.org/pipermail/bind-users/2023-January/107166.html
• https://lists.isc.org/pipermail/bind-users/2024-February/108356.html

Skimming those threads again I don't believe anyone ever provided an example use case that couldn't be accomplished by marking on the host firewall or on a network element.

[gthess]

Hi @jlivingood, there is already the ip-dscp: option which enables DSCP for all outgoing traffic (both downstream and upstream). So using ip-dscp: 45 in your case would be enough?