owner:draft-ietf-tsvwg-l4s-arch@ietf.orgtype_defect | by pete@heistp.net
There are several cases we've noticed where classic bottleneck detection will misidentify an L4S queue as an RFC 3168 queue:
paths with about 2ms or more of jitter
low capacity paths (tested 5 Mbps)
asymmetric links with bi-directional traffic
Although misidentifying an L4S queue as an RFC 3168 queue is safe in and of itself, it leads to performance issues, which increases the likelihood of bottleneck detection being disabled.
Test results around jitter and low capacity links are here:
owner:draft-ietf-tsvwg-l4s-arch@ietf.orgtype_defect| by pete@heistp.netThere are several cases we've noticed where classic bottleneck detection will misidentify an L4S queue as an RFC 3168 queue:
Although misidentifying an L4S queue as an RFC 3168 queue is safe in and of itself, it leads to performance issues, which increases the likelihood of bottleneck detection being disabled.
Test results around jitter and low capacity links are here:
https://github.com/heistp/sce-l4s-ect1#false-positives
An explanation of the results with asymmetric links and bi-directional traffic, along with links to test results is here:
https://mailarchive.ietf.org/arch/msg/tsvwg/-gx8R1jcwiCsX1_5cdnvl3kKlOs/
Issue migrated from trac:29 at 2022-01-31 12:36:11 +0000