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 7BC9421F1B0; Wed, 12 Dec 2012 02:45:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,265,1355126400"; d="scan'208";a="718441695" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Dec 2012 02:45:02 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qBCAj2lM014714; Wed, 12 Dec 2012 02:45:02 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.26]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 02:45:02 -0800 From: "Eggert, Lars" To: Ketan Kulkarni Thread-Topic: [Bloat] TCP TFO client behaviour Thread-Index: AQHN179vci+wDj/+pEaQU+AZEXH+CZgVghaA Date: Wed, 12 Dec 2012 10:45:01 +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: <55B305FCD3E41B4B92AF38C2909C0B34@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 12 Dec 2012 05:13:15 -0800 Cc: "" , bloat Subject: Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour 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: Wed, 12 Dec 2012 10:45:06 -0000 I suggest you discuss this on tcpm@ietf.org, where TFO is being developed. Lars On Dec 11, 2012, at 17:48, Ketan Kulkarni wrote: > Hi, > I am testing tcp tfo behavior with httping client and polipo server. >=20 > One observation from my TFO testing -If for a connection server sends a > cookie to client, client always does TFO for subsequent connections. This > is ok. >=20 > If for some reason, server stops supporting TFO (either because server go= t > restarted without TFO support (in my case) or because path changed and th= e > nw node is dropping packet with unknown syn option or stripping the > option), client does not clear up its cookie cache. It always sends data = in > syn and server never acks the syn-data and client retransmits. >=20 > As per kernel code -if syn-data is not acked it is retransmitted > immediately - with the assumption first syn was dropped (but the assumpti= on > server stopped supporting TFO might not have been considered) >=20 > My opinion is to flush the cookie for this server and re-attempt the cook= ie > "negotiation" on subsequent connection. >=20 > Your thoughts? >=20 > Thanks, > Ketan > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat