From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 25D8421F30B for ; Thu, 12 Mar 2015 09:13:50 -0700 (PDT) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 824AC18032B; Thu, 12 Mar 2015 12:13:49 -0400 (EDT) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 62BC2180235; Thu, 12 Mar 2015 12:13:49 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Thu, 12 Mar 2015 16:13:49 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id 52C8A80041; Thu, 12 Mar 2015 12:13:49 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 12 Mar 2015 12:13:49 -0400 (EDT) Date: Thu, 12 Mar 2015 12:13:49 -0400 (EDT) From: dpreed@reed.com To: "Richard Smith" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <5501B16E.9040207@gmail.com> References: <5501B16E.9040207@gmail.com> X-Auth-ID: dpreed@reed.com Message-ID: <1426176829.336613096@apps.rackspace.com> X-Mailer: webmail/11.3.13-RC Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Bloat] great interview on the scale conference wifi successes X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:14:19 -0000 On Thursday, March 12, 2015 11:31am, "Richard Smith" = said:=0A=0A> On 03/10/2015 05:12 PM, Dave Taht wrote:=0A> =0A>>>=0A>>> This= year I deployed 53 APs. I'll make an updated map showing where they=0A>>> = were deployed.=0A>>=0A>> So far as I know all the APs were fq-codeled, but = the firewall/gw was=0A>> not.=0A> =0A> How does this work? I thought the A= P's in this setup were run as bridges.=0A=0APretty 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).=0A=0AEthernet bridges should d= efinitely manage their outbound queues to keep the queues in them on the av= erage quite small (average < 2 frames in steady state). Otherwise, if the o= utbound queue runs at 802.11b rates, and the inbound queues run at 802.11ac= rates, there will be a serious disaster.=0A=0ASince you can't ECN generali= zed 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 yo= u know that the LAN is transporting an IP datagram, to ECN-mark those datag= rams. 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.= =0A=0AThe 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 t= hat packet should not block the next packet coming in going to a different = destination. The retransmission queue (which is there to improve reliabili= ty) is a different thing. [However, my intuition suggests that only one pa= cket 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 l= ayer up figure out what to do. Propagation changes in the 10's of milliseco= nd time frame. It won't get better if you wait 1/2 second or more]=0A=0A=0A