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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
