[Cerowrt-devel] [Bloat] great interview on the scale conference wifi successes

[David Lang]

On Thu, 12 Mar 2015, dpreed at reed.com wrote:

> On Thursday, March 12, 2015 11:31am, "Richard Smith" <smithbone at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>