For those of you that have missed work happening in TSVWG – there are recent L4S and NQB docs that specify a method to achieve low latency via a 2nd network queue at bottleneck links. That depends on a client marking traffic using ECN – via ECT(1) or CE – and/or DSCP-45.
I am in the midst of leading a field trial of this technology in Comcast’s network and we’ve done some very limited testing of an on-network recursive resolver using DNS traffic marked on the client-side as DSCP-45 (we’d use ECN but have not yet implemented a supporting congestion control algorithm on the server). Initial results from a very small scale test suggest a 20% reduction in QRT for cached responses. We’re now looking for ideas on larger scale, longer-running DNS tests that average end users would be able to run – either by using a small probe that they’d install (a la RIPE Atlas) or app/script they could let run in the background on their computer. If you have suggestions on good ways to expand this low latency DNS testing or would like us to test something you developed – please let me know off-list. Thanks!! Jason More info: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb https://www.rfc-editor.org/rfc/rfc9330.html https://www.rfc-editor.org/rfc/rfc9331.html https://www.rfc-editor.org/rfc/rfc9332.html https://corporate.comcast.com/stories/comcast-kicks-off-industrys-first-low-latency-docsis-field-trials https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Week5-PartB.md
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
