From owner-soc-status@FreeBSD.ORG Sun Jun 14 16:47:59 2009 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE52D1065672; Sun, 14 Jun 2009 16:47:59 +0000 (UTC) (envelope-from wangfangcs@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id A8C408FC14; Sun, 14 Jun 2009 16:47:59 +0000 (UTC) (envelope-from wangfangcs@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1126706wfg.7 for ; Sun, 14 Jun 2009 09:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=wyT079CSxElXoONzcpEDJ094jJZ5WRoXQb1nbQ2JqRU=; b=tzTT3kE8vkB9AIyNeb4vhIL8qDaomiLe6fpSXFlIJ2TJzmJxe7kgKObdo8MroR4it+ azhDMEpZzY+JGri4rjrFOu78mwm/5brwky6GfK4vmr8eAa7TcM+ahQMs5WxJB1jWg7nu M59sxDoLoINBqChPZ8T8iww3XtJeAJ6h7bllg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=u9KiM3cOBYK93WJ1tckOW7PU/OeVucVtLyGCKpLvcJgJmd/2T17ZWTdmM9NWskXnTw Jo2W+5UEZZAPzdv37SlBVWGp+7Rc8W8H6+tmqnnmZPoWCNxy9zxgwwzLFOjbPYxmmXDa Aqb+9o/QQLPw18fj2oiQI8L/NNDvdrv0GxqUU= Received: by 10.142.110.10 with SMTP id i10mr2456549wfc.300.1244998079070; Sun, 14 Jun 2009 09:47:59 -0700 (PDT) Received: from fwen-thinkpad ([222.20.102.196]) by mx.google.com with ESMTPS id 27sm7963490wfa.2.2009.06.14.09.47.56 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 09:47:58 -0700 (PDT) Date: Mon, 15 Jun 2009 00:47:53 +0800 From: "wangfangcs" To: "rpaulo" , "soc-status" Message-ID: <200906150047512037622@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: tcputo status report 2 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 16:48:00 -0000 Hi, The job in this week can be divided into two parts. The first part is finish the UTO relative input and output sequence. Because the TCP User Timeout Option is an advisory TCP option that does not change processing of subsequent segments. Consequently, the specification does not define a reliability handshake for UTO option exchanges. But implementations should implement local mechanisms to improve delivery reliability. For passive open, syncache needs to be modified. And because syncache does not use tcp_output(use ip_output directly), it's not complex. For active open and the situation that there is no place in tcp header for UTO in SYN segment, it needs to be handled in tcp_output. For outgoing UTO option, if the outgoing segmeng is a SYN segment or a data segment, put UTO option in the segment if there is enough space, and record the outgoing sequence plus data length as carrier sequence. Retransmit the UTO option until the carrier sequence is acked by other peer. The second part is the UTO timer strategy. In the case of UTO is disabled and user or other side does not use UTO, use the original retransmission strategy. Otherwise, get the user timeout value according to RFC5482. I use two variables to implement uto timer strategy, first is t_impl_uto, that's the value get according to RFC5482, second is t_left_uto. When doing the first retransmission, set t_left_uto=t_impl_uto, then if doing more retransmissions, reduce t_left_uto every time by the retransmit interval. If t_left_uto goes to zero, drop the connection. Regards, Fang Wang 2009-06-15