> On 20 May, 2016, at 17:42, Kathleen Nichols <nich...@pollere.com> wrote: > >> How big a problem is this in the real world? ARe we working on a >> theoretical problem, or something that is actually hurting people? > > The above seems like it should be the FIRST thing to consider.
Fragmented packets *are* a real-world problem, IMHO, in that iperf3 in UDP mode produces lots of them by default, and hardware vendors tend to use tools like iperf3 UDP (in a Faraday cage, no less) to demonstrate the throughput of their new kit. Historically, that’s been the method which produces the biggest and most impressive numbers, because there is almost no reverse traffic contending for airtime. Currently fq_codel does a *really bad* job of showing high iperf3 UDP numbers, even though it shows very good real-world TCP performance, and that is likely to severely put off hardware vendors from deploying fq_codel by default - because it’s not the TCP goodput numbers that they like to use for marketing. And that’s a real-world problem when increasing AQM deployment is a real-world goal. However, I think the relatively straightforward fix of isolating fragmented packets (including the initial fragment, in which the transport header remains visible) only by addresses should be sufficient. This will keep the different parts of each packet together (to the extent they were together on ingress) and allow more of them to be successfully reassembled, allowing iperf3 to show numbers closer to the no-AQM case. I’ve already described why it should be sufficient for real-world traffic as well. Reassembling fragmented packets would also work, provided they are only re-fragmented *after* passing through the qdisc, but carries dangers of its own due to the resources required for reassembly. Presently those costs are borne by the receiving host, which is in a better position to do so. - Jonathan Morton _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel
