You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: