Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support NQB for Dual Queue Low Latency Networking #357

Open
jlivingood opened this issue Mar 22, 2024 · 0 comments
Open

Comments

@jlivingood
Copy link

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 client-side support in the stub resolver 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 stub to set DSCP-45 marking in all packets sent outbound to DNS recursive resolvers. This will have the benefit of marking DNS queries 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 stub resolver enabling a user to turn on NQB support. That specifically will mean setting DSCP value 45 in the packet header.

Potential use-case

If NQB turned on, and a 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant