From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B456521F0B5 for ; Wed, 22 Aug 2012 13:44:56 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so117185wib.10 for ; Wed, 22 Aug 2012 13:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rCRZmin2ckLfgxv2D1kysEO5ATrnSgm0RvZT1kNliKw=; b=tRxO8JxXo5JOXW8xGr2ysbiL6ZGWEePCNF7hmqF68v6Y5eZqLcfocAQKDh5FHen9Ov cEMZZiBiPmEweUDidi+3esdCC14QsfKeQqZNuGzEy6i2P2GcQPjcmEFcRF4NhDsY+oaD NoYeyNcD0FJcUP9njpZqOAa0xPOEKk2pFAjJ76teu/nhjCzWwb7AQljRF0NjZDFOjOxQ L2wwuYf7foDg6d6OsG+MDxXV1385R9Ph5VN8K5K1j3vSbpg9ZwY//f0qIZI6Nw1mN9EW uaUuZPw1SPWgal7gDPJwZ4W7aiB6P2Lcqb4DZ+Xol00VX9xjzJT/txTeBqhfqCqQqAGW z6RA== MIME-Version: 1.0 Received: by 10.180.100.133 with SMTP id ey5mr8780896wib.4.1345668294397; Wed, 22 Aug 2012 13:44:54 -0700 (PDT) Received: by 10.223.143.69 with HTTP; Wed, 22 Aug 2012 13:44:54 -0700 (PDT) In-Reply-To: References: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> <2998C331-777B-41B3-A6BC-8285461EF729@gmx.de> <1345516397.664231592@apps.rackspace.com> <1345659822.690830074@apps.rackspace.com> Date: Wed, 22 Aug 2012 13:44:54 -0700 Message-ID: From: Dave Taht To: Kenneth Finnegan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released 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: Wed, 22 Aug 2012 20:44:57 -0000 On Wed, Aug 22, 2012 at 12:23 PM, Kenneth Finnegan wrote: > On Wed, Aug 22, 2012 at 11:54 AM, Dave Taht wrote: >> and disabling or dropping the underused polipo proxy - >> > > I think the proxy being under-used could be fixed if we had CeroWRT > optionally advertise wpad when you start Polipo. When enabled, we > would just need the router to resolve wpad.local.domain the same as > gw.local.domain, and serve a gw.local.domain:80/wpad.dat file > containing something like: > > function FindProxyForURL(url, host){ > if (isInNet(host, "172.30.42.0", "255.255.255.0")) { > return "DIRECT"; > } > return "PROXY gw.local.domain:3128; DIRECT"; > } I note that the dns entry wpad.home.lan is enabled by default in cero's implementation of bind, and cero is distributing this information via dhcp as well, but dhcp alone seems not enough. Enabling the pac file makes sense... > WPAD is really how the proxy-on-a-LAN experience should be. The HUGE > issue with WPAD is that browsers (at least Firefox) switch to > resolving all DNS queries synchronously instead of async when they > detect a wpad configured network. Any gains from caching what little > web content is (advertised) as cacheable are lost many times over when > every DNS request causes the Firefox UI to FREEZE. Hit a page with > several different domains on it (and what websites don't make you > resolve analytics.google.com, twitter.com, plus.google.com, digg.com, > reddit.com, etc etc) and the entire Firefox GUI locks up for several > seconds. > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D769764 DNS queries should be resolved on the proxy, methinks. I'm not sure if what this bug describes is the blocking you are describing. > Just some food for thought. I would agree that in the face of memory > pressure, it should be one of the first things to go; the vast > majority of web servers aren't even configured correctly to mark > cacheable content, so caching is usually force by writing > pattern-matching rules which over-ride the (non-existent) caching > meta-data. My principal reasons for wanting to bring the concept of proxying back into realm of the home router is multi-fold, but doesn't actually involve caching (as that would require setting up a usb memory stick to do well) In the age when proxies ruled the earth, and wireless would actually drop packets (1995-2005), it made a lot of sense to have a web proxy on the wired/wifi boundry. 1) short RTTs compensate for excessive delays and packet loss on the wireless side, while providing an accurate RTT (and some buffering) to the wired-to-the-internet side 2) it makes possible doing ipv6 to ipv4 translation much easier - the wpad method can just as easily point to an ipv6 address. There were huge threads regarding the advantages and disadvantages of "split tcp" in the early days of the bloat list. Example: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000101.html Now that we have the beginnings of a sane drop strategy in place, and bloat has been thoroughly smashed through the stack (I am one line away from backporting "TCP small queues" btw), I think the overhead of running a web proxy on the router is low, and it could show benefit in the general case - keeping dns queries local, smoothing out wifi access patterns, and making possible the more native ipv6 transition (and testing) noted above. I really, really, really want to beat up on ipv6 as hard as possible... That said, what I care about right now in this upcoming release is that it not crash under stress, and I can get some good data back as to codel's behavior when not in a so tightly constrained memory environment. And/or find a memory leak. I will probably leave polipo enabled, if I can convince someone to test the current configuration... (hint, hint) > Kenneth Finnegan > blog.thelifeofkenneth.com --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!"