From owner-freebsd-net@FreeBSD.ORG Mon May 25 16:19:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271B1106566C for ; Mon, 25 May 2009 16:19:30 +0000 (UTC) (envelope-from wangfangcs@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id D97558FC61 for ; Mon, 25 May 2009 16:19:29 +0000 (UTC) (envelope-from wangfangcs@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1834380ana.13 for ; Mon, 25 May 2009 09:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=0pytwPOlmduK3u4xH3N2rBwc6CN7Wzin7l1JV1l0ZVk=; b=bRi4qkYqOMqBf+6+cGr8kGGPtmIRUnjEFKm6l/HF/TdMzZp+hbntwTuIY5ED/GDdtK +Tjib4s1bSRVj80+6V8sSsuwseumocI7uVCNmLQR5DdrTmbjbN+NYcWEqNU0doiif8OW ApfkQP4HAjx66LCcer3cHflR3QQyB2noYgD0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=HPSNlv5/xU+vA91Apz7vaUIBjc6xpD0HwTwqyA78X1Idn8eWRevfbOodZbtTjhLqIZ idoVlEpIldPrT3nKphm8NDSFO4KOmeoWswOyYZj8op/oD/232gHo18JGf6rBB+mLwrNg oKz3Yxyo4tNBVDET293uDiKIRxzpG9UR73IqU= MIME-Version: 1.0 Received: by 10.100.178.9 with SMTP id a9mr12809342anf.11.1243266752888; Mon, 25 May 2009 08:52:32 -0700 (PDT) Date: Mon, 25 May 2009 23:52:32 +0800 Message-ID: From: Fang Wang To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problems in implementation TCP UTO described in RFC 5482 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 16:19:30 -0000 Hi! RFC 5482 specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout accordingly. That means the user timeout which is fixed currently can be changed. For more details about UTO, please read RFC 5482. The current user timeout is fact controled by retransmission times and intervals in TCP stack, that's 1+2+4+8+16+32+64+64+64+64+64+64+64=511 seconds and 12 retransmissions in total. After the last retransmission, it waits for another 64 seconds. Assume that a program set a 150 seconds user timeout, and of course we use exponential backoff, so first six intervals is 1,2,4,8,16,32,64 seconds and the last interval is 23 seconds. Here is the problem, after the last retransmission, we only waits for 23 seconds, that's not exponential backoff. And what if the last interval is 1 second, that means the last retransmission is useless. One alternative solution is reduce a retransmission and adjust the former intervals, for example 1,2,4,8,16,32,65. Or just leave it alone. But I think there may be some better ideas. Regards, Fang Wang