On Thu, 12 Mar 2015, dpr...@reed.com wrote:
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).
Even when acting as a bridge, there is a need to queue packets that go in each
direction, so the queuing discipline will come into play. Since this was built
from (almost) the latest CC code (it was compiled based on the image the
saturday before the conference, on monday they upgraded the kernel to 3.18, but
I didn't have time to get a new image tested before tuesday evening when we
started deployment)
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.
I just left this as the default OpenWRT CC settings, which are now fq_codel. We
were not doing any explicit ECN marking or dropping.
David Lang
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
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
