From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "MX2.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 78AFF21F115; Mon, 14 Jan 2013 00:32:19 -0800 (PST) Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Jan 2013 00:32:17 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0E8WHbc013496; Mon, 14 Jan 2013 00:32:17 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Mon, 14 Jan 2013 00:32:17 -0800 From: "Eggert, Lars" To: Dave Taht Thread-Topic: [Bloat] if we're going to break middleboxes with TFO... why not go for more gusto? Thread-Index: AQHN8P1u7mhmypTS3EOXey3t27lF8JhJB3GA Date: Mon, 14 Jan 2013 08:32:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0164BCFC1F4DF04AABC28B8FF4FB8A50@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , bloat Subject: Re: [Cerowrt-devel] [Bloat] if we're going to break middleboxes with TFO... why not go for more gusto? 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: Mon, 14 Jan 2013 08:32:19 -0000 Hi, On Jan 12, 2013, at 20:45, Dave Taht wrote: > I got pointed at rfc6013 (TCPCT) recently which looked like it solved > a raft of problems TFO doesn't solve. also note that it is not an IETF standard but an independent submission to = the RFC Editor. (That's not to say it's a bad proposal.) IIRC, the author did not want to work on this in the IETF, the result is th= at TCPCT uses the experimental option numbers and must not be used over the= wider Internet. Unless the author submits it to the TCPM WG, TCPCT is unli= kely to get an option number assigned by IANA. Lars >=20 > Biggest problem it has though is that it eats all the remaining TCP > option space. I wonder if anyone tried implementing something similar > over UDP? >=20 > More readable detail than the rfc here: >=20 > http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat