heistp / l4s-tests

Tests of L4S
BSD 2-Clause "Simplified" License
12 stars 2 forks source link

Single-queue RFC3168 AQMs #2

Open jlivingood opened 9 months ago

jlivingood commented 9 months ago

A risk is documented a bit disingenuously. A key risk is about single-queue RFC3168 AQMs but the document says there is no info on any such deployments - but in too-neutral of a way that may mislead a reader. While highlighting the risk you may wish to note that it is largely theoretical given no one is aware or any scale deployment of single-queue RFC3168 AQMs. If you are aware of those, then they should be documented and the volume of traffic relative to the total volume of traffic should be cited.

heistp commented 9 months ago

The risk is more serious than just from deployed single queue RFC 3168 AQMs though. The Likelihood section documents that even when FQ is deployed (i.e. fq_codel, the default in many Linux OSs, and on many WiFi routers), L4S and non-L4S traffic can end up in a shared RFC 3168 signaling queue when they're in the same tunnel, or wind up in the same queue due to a hash collision. Most traffic in the same tunnel shares the same 5-tuple hash, and will thus end up in the same RFC3168 signaling queue, in the case of fq_codel or Cake, for example.

Unless this is tested for explicitly, it may well go unnoticed, or rather "unattributed", as when a problem occurs that affects their QoE in some way, it's unlikely that the user will be able to identify this as the reason.