On Thursday, March 12, 2015 11:31am, "Richard Smith" <smithb...@gmail.com> said:
> On 03/10/2015 05:12 PM, Dave Taht wrote: > >>> >>> This year I deployed 53 APs. I'll make an updated map showing where they >>> were deployed. >> >> So far as I know all the APs were fq-codeled, but the firewall/gw was >> not. > > How does this work? I thought the AP's in this setup were run as bridges. Pretty good question! Of course if AP's running as Ethernet bridges are bloated (meaning their queues can grow quite large) that's yet another reason that we need to make WiFi fast (by putting codel into the bridge function). Ethernet bridges should definitely manage their outbound queues to keep the queues in them on the average quite small (average < 2 frames in steady state). Otherwise, if the outbound queue runs at 802.11b rates, and the inbound queues run at 802.11ac rates, there will be a serious disaster. Since you can't ECN generalized Ethernet packets, codel would have to drop packets. And this might have been what David Lang is doing. (of course, it's perfectly reasonable if you know that the LAN is transporting an IP datagram, to ECN-mark those datagrams. This is what an Internet transport layer is allowed to do, which is why ECN is part of the envelope, not the contents of the end-to-end packet. The same argument applies to packets held for retransmission over an 802.11 link. It's perfectly OK to hold a packet outside the outbound queue for retransmission when the conditions to the destination get better, but that packet should not block the next packet coming in going to a different destination. The retransmission queue (which is there to improve reliability) is a different thing. [However, my intuition suggests that only one packet per next hop should be in the retransmission queue, and it should not stay there very long - after a period of time, let the sender at the next layer up figure out what to do. Propagation changes in the 10's of millisecond time frame. It won't get better if you wait 1/2 second or more] _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
