[Cerowrt-devel] cerowrt 3.3.8-17 is released

[Dave Taht]

On Wed, Aug 22, 2012 at 12:23 PM, Kenneth Finnegan
<kennethfinnegan2007 at gmail.com> wrote:
> On Wed, Aug 22, 2012 at 11:54 AM, Dave Taht <dave.taht at gmail.com> 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=769764

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



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
with fq_codel!"