From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CA97B21F17F for ; Fri, 4 Jan 2013 19:35:38 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id c14so20844993ieb.28 for ; Fri, 04 Jan 2013 19:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dcmU/RPnFGl/lYk2KdG2JFxGE/rshfYlQO9XMfFn8Uk=; b=FYYpLnxsI2ftm5G183Ytlu3P1C9NhOs+H4XiawK3ih6IZS/T+0z9sDE6bOmIYX8UGD K4nYg1QKMUqvdpsZVr/4gCnEbBPxQFySj00VnqkKceqYGSgxfI9GWAKGqXNRjRDEvmJG YFwrY0OkUn9nqQUOj8NTHVmMCVZggAMEJXvZ+O2M0/27vZCncnVHnPfNzNeqxfQqLmYg Ec0HPkVk8PQ+YPHiZfSPT9s7b9nAPaenhuQJxoLAReCq9LQ+CLC38I2NM79AsHIjwkMh +CG54C/+jBtppSbweLXS9x8kcrBA4XRyUlyihV3bAYrC7axuzqIuSKZGtcI4Gce5JtVZ vZsw== MIME-Version: 1.0 Received: by 10.43.92.72 with SMTP id bp8mr41377258icc.49.1357356938122; Fri, 04 Jan 2013 19:35:38 -0800 (PST) Received: by 10.64.135.39 with HTTP; Fri, 4 Jan 2013 19:35:37 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Jan 2013 19:35:37 -0800 Message-ID: From: Dave Taht To: Ketan Kulkarni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jerry Chu , Eric Dumazet , Yuchung Cheng , cerowrt-devel Subject: Re: [Cerowrt-devel] TFO crashes cerowrt 3.7.1-1 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 03:35:39 -0000 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=3D4 time=3D10.76 ms Typical result, polipo, useTCPFastopen =3D true in it's config and /proc/sys/net/ipv4/tcp_fastopen =3D 3 on both sides.... connected to 172.26.3.4:80 (274 bytes), seq=3D4 time=3D6.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. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html