Re: [Cerowrt-devel] TFO crashes cerowrt 3.7.1-1

[Dave Taht <dave.taht@gmail.com>]

On Fri, Jan 4, 2013 at 7:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> It's rather fun to explore a new protocol on a friday night!, but this
> thread is getting out of hand. I created a bug for it here:
>
> https://www.bufferbloat.net/issues/418
>
> I don't mind if we continue to discuss it here, but do put packet
> captures on the bug, please...
>
> I scripted up a few tests that hopefully duplicate what ketan was
> trying to do. (ketan?) and put up packet captures of the succesful
> tests to an x86_64 box I had handy....
>
> I will put a sacrificial cerowrt box back up with a serial port on it
> before sunday....
>
> I noted in the bug above (with more detail)
>
> On a x86_64 path over a 4 hop wifi mesh network, httpping using polipo
> as a proxy not only "worked", but roughly halved the time taken by a
> ~40kbyte http GET.
>
> Typical httpping result, polipo, no TFO
>
> connected to 172.26.3.4:80 (274 bytes), seq=4 time=10.76 ms
>
> Typical result, polipo, useTCPFastopen = true in it's config and
> /proc/sys/net/ipv4/tcp_fastopen = 3 on both sides....
>
> connected to 172.26.3.4:80 (274 bytes), seq=4 time=6.61 ms
>
> Impressive!
>
> If the security issues with the idea are resolved (I'm aware of the
> prior effort to do this but haven't thought deeply about how TFO
> attempts to resolve those issues), and TFO can be deployed, it will be
> a win for a wide range of latency sensitive tcp traffic types.

Spoke WAY too soon on the performance front, looks like we get a RST
from one of the (3.6.11) middleboxes in that testbed before we get the
whole file.

put up a new capture on

https://www.bufferbloat.net/issues/418

Calling it a night.

>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html