On Fri, Jan 4, 2013 at 7:35 PM, Dave Taht <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
