From owner-freebsd-fs@FreeBSD.ORG  Fri Oct 14 16:21:24 2005
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
X-Original-To: fs@freebsd.org
Delivered-To: freebsd-fs@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2525A16A41F
	for <fs@freebsd.org>; Fri, 14 Oct 2005 16:21:24 +0000 (GMT)
	(envelope-from rees@citi.umich.edu)
Received: from citi.umich.edu (citi.umich.edu [141.211.133.111])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0D6C943D5E
	for <fs@freebsd.org>; Fri, 14 Oct 2005 16:21:22 +0000 (GMT)
	(envelope-from rees@citi.umich.edu)
Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.133.51])
	by citi.umich.edu (Postfix) with ESMTP id 8D1571BBDE;
	Fri, 14 Oct 2005 12:21:22 -0400 (EDT)
To: rick@snowhite.cis.uoguelph.ca
From: Jim Rees <rees@umich.edu>
In-Reply-To: rick@snowhite.cis.uoguelph.ca, Fri, 14 Oct 2005 12:07:23 EDT
Date: Fri, 14 Oct 2005 12:21:22 -0400
Sender: rees@citi.umich.edu
Message-Id: <20051014162122.8D1571BBDE@citi.umich.edu>
Cc: fs@freebsd.org
Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from
	Linux/SunOS clients 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2005 16:21:24 -0000

  ps: It would be nice if someone with the right expertise could explore
      other things in TCP specifically for NFS. For example, I don't see
      why a retransmit timeout should go above about 100msec

nfs/rpc shouldn't retransmit at all over tcp except when there has been a
reconnect.  Tcp might retransmit, but modern implementations will always
choose the right timeout dynamically, unless packet loss is excessive.