From owner-freebsd-net@FreeBSD.ORG  Fri Apr 11 13:19:02 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 686BD37B401
	for <freebsd-net@freebsd.org>; Fri, 11 Apr 2003 13:19:02 -0700 (PDT)
Received: from web10402.mail.yahoo.com (web10402.mail.yahoo.com
	[216.136.130.94])
	by mx1.FreeBSD.org (Postfix) with SMTP id 08F0943FAF
	for <freebsd-net@freebsd.org>; Fri, 11 Apr 2003 13:19:02 -0700 (PDT)
	(envelope-from opolyakov@yahoo.com)
Message-ID: <20030411201901.98887.qmail@web10402.mail.yahoo.com>
Received: from [67.112.212.200] by web10402.mail.yahoo.com via HTTP;
	Fri, 11 Apr 2003 13:19:01 PDT
Date: Fri, 11 Apr 2003 13:19:01 -0700 (PDT)
From: Oleg Polyakov <opolyakov@yahoo.com>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1989487801-1050092341=:98618"
Subject: RFC3390 implementation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Apr 2003 20:19:02 -0000

--0-1989487801-1050092341=:98618
Content-Type: text/plain; charset=us-ascii
Content-Id: 
Content-Disposition: inline

Nice to see RFC3390 implemented. It looks like it worth mention in tuning(7).

While we on it - there is section 2 in RFC:

>2.  Implementation Issues
>
>   When larger initial windows are implemented along with Path MTU
>   Discovery [RFC1191], and the MSS being used is found to be too large,
>   the congestion window `cwnd' SHOULD be reduced to prevent large
>   bursts of smaller segments.  Specifically, `cwnd' SHOULD be reduced
>   by the ratio of the old segment size to the new segment size.
>

So we need to take care of cwnd reduction in tcp_mtudisc function.
Here is a patch attached.

Or we may do it conditionally depending on tcp_do_rfc3390 variable.

----
Oleg

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
--0-1989487801-1050092341=:98618
Content-Type: text/plain; name="p3b.txt"
Content-Description: p3b.txt
Content-Disposition: inline; filename="p3b.txt"

--- tcp_subr.c.orig	Fri Apr 11 13:05:53 2003
+++ tcp_subr.c	Fri Apr 11 13:06:27 2003
@@ -1449,6 +1449,14 @@
 #endif
 		if (so->so_snd.sb_hiwat < mss)
 			mss = so->so_snd.sb_hiwat;
+		/*
+		 * Follow suggestion in RFC 3390 to reduce the congestion
+		 * window by the ratio of the old segment size to the new
+		 * segment size.
+		 */
+		if (mss < tp->t_maxseg)
+			tp->snd_cwnd = max((tp->snd_cwnd / tp->t_maxseg) *
+			    mss, mss);
 
 		tp->t_maxseg = mss;
 

--0-1989487801-1050092341=:98618--