Date: Thu, 25 Nov 1999 19:19:04 -0800 (PST) From: aron@cs.rice.edu To: freebsd-gnats-submit@freebsd.org Subject: kern/15095: TCP's advertised window is not scaled immediately upon discovering use of Window scale option Message-ID: <19991126031904.C235714E58@hub.freebsd.org>
index | next in thread | raw e-mail
>Number: 15095
>Category: kern
>Synopsis: TCP's advertised window is not scaled immediately upon discovering use of Window scale option
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Nov 25 19:20:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator: Mohit Aron
>Release: FreeBSD 3.3-RELEASE
>Organization:
Rice University
>Environment:
FreeBSD luzern.cs.rice.edu 3.3-RELEASE FreeBSD 3.3-RELEASE #5: Tue Oct 19 11:56:31 CDT 1999 aron@luzern.cs.rice.edu:/usr/src/sys/compile/LUZERN i386
>Description:
The FreeBSD implementation does not scale the advertised window
immediately when it discovers that window scaling is being used. The result
is that irrespective of advertised window, in the first round-trip after
connection establishment, a FreeBSD TCP sender cannot send more data than
the unscaled value of advertised window.
One can argue that this is not important given that TCP does slow-start in
the first round-trip. Well, people are looking at rate-based pacing where
you don't have to do slow-start. Also the above is important in LANs where
FreeBSD doesn't use slow-start. In my case, I'm emulating a WAN to see
the benefits of rate-based pacing and so is extremely important.
>How-To-Repeat:
Try running a TCP transfer over an emulated (or an actual) WAN. Make
sure that slow-start is turned off (it is if FreeBSD thinks its operating
on a LAN - i.e the other host has the same subnet address). Also ensure
that RFC1323 is being used (i.e. Window scaling is in effect) and the
flow control window is big enough on the TCP receiver. Use tcpdump to
check the number of packets sent in the first round-trip - these will
correspond to the unscaled value of the advertised window.
A simpler method to repeat the problem is to instrument the kernel
to print out the value of the variable tp->snd_wnd when TCP starts
sending data. You'll see that it corresponds to the unscaled value of
the flow control (or advertised) window.
>Fix:
The following patch applied to /sys/netinet/tcp_input.c fixes the problem:
--- /sys/netinet/tcp_input.c Sun Aug 29 11:29:54 1999
+++ tcp_input.c Wed Nov 10 15:39:49 1999
@@ -857,6 +857,9 @@
(TF_RCVD_SCALE|TF_REQ_SCALE)) {
tp->snd_scale = tp->requested_s_scale;
tp->rcv_scale = tp->request_r_scale;
+
+ tp->snd_wnd <<= tp->snd_scale;
+ tiwin = tp->snd_wnd;
}
/* Segment is acceptable, update cache if undefined. */
if (taop->tao_ccsent == 0)
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991126031904.C235714E58>