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

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

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.


-- 
Dave Täht

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