netdev - Re: TCP's initial cwnd setting correct?...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Aug 2007 22:01:27 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	netdev@...r.kernel.org
Subject: Re: TCP's initial cwnd setting correct?...

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Mon, 6 Aug 2007 15:37:15 +0300 (EEST)

> ...Another thing that makes me wonder, is the tp->mss_cache > 1460 check 
> as based on rfc3390 (and also it's precursor rfc2414) with up to 2190 
> bytes MSS TCP can use 3 as initial cwnd...

I did the research and my memory was at least partially right.

Below is an old bogus change of mine and the later revert with
Alexey's explanation.

This seems to be dealing with receive window calculation issues,
rather than snd_cwnd.  But they might be related and you should
consider this very seriously.

commit 6b251858d377196b8cea20e65cae60f584a42735
Author: David S. Miller <davem@...set.davemloft.net>
Date:   Wed Sep 28 16:31:48 2005 -0700

    [TCP]: Fix init_cwnd calculations in tcp_select_initial_window()
    
    Match it up to what RFC2414 really specifies.
    Noticed by Rick Jones.
    
    Signed-off-by: David S. Miller <davem@...emloft.net>

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index d6e3d26..caf2e2c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -190,15 +190,16 @@ void tcp_select_initial_window(int __space, __u32 mss,
 	}
 
 	/* Set initial window to value enough for senders,
-	 * following RFC1414. Senders, not following this RFC,
+	 * following RFC2414. Senders, not following this RFC,
 	 * will be satisfied with 2.
 	 */
 	if (mss > (1<<*rcv_wscale)) {
-		int init_cwnd = 4;
-		if (mss > 1460*3)
+		int init_cwnd;
+
+		if (mss > 1460)
 			init_cwnd = 2;
-		else if (mss > 1460)
-			init_cwnd = 3;
+		else
+			init_cwnd = (mss > 1095) ? 3 : 4;
 		if (*rcv_wnd > init_cwnd*mss)
 			*rcv_wnd = init_cwnd*mss;
 	}
--------------------
commit 01ff367e62f0474e4d39aa5812cbe2a30d96e1e9
Author: David S. Miller <davem@...set.davemloft.net>
Date:   Thu Sep 29 17:07:20 2005 -0700

    [TCP]: Revert 6b251858d377196b8cea20e65cae60f584a42735
    
    But retain the comment fix.
    
    Alexey Kuznetsov has explained the situation as follows:
    
    --------------------
    
    I think the fix is incorrect. Look, the RFC function init_cwnd(mss) is
    not continuous: f.e. for mss=1095 it needs initial window 1095*4, but
    for mss=1096 it is 1096*3. We do not know exactly what mss sender used
    for calculations. If we advertised 1096 (and calculate initial window
    3*1096), the sender could limit it to some value < 1096 and then it
    will need window his_mss*4 > 3*1096 to send initial burst.
    
    See?
    
    So, the honest function for inital rcv_wnd derived from
    tcp_init_cwnd() is:
    
    	init_rcv_wnd(mss)=
    	  min { init_cwnd(mss1)*mss1 for mss1 <= mss }
    
    It is something sort of:
    
    	if (mss < 1096)
    		return mss*4;
    	if (mss < 1096*2)
    		return 1096*4;
    	return mss*2;
    
    (I just scrablled a graph of piece of paper, it is difficult to see or
    to explain without this)
    
    I selected it differently giving more window than it is strictly
    required.  Initial receive window must be large enough to allow sender
    following to the rfc (or just setting initial cwnd to 2) to send
    initial burst.  But besides that it is arbitrary, so I decided to give
    slack space of one segment.
    
    Actually, the logic was:
    
    If mss is low/normal (<=ethernet), set window to receive more than
    initial burst allowed by rfc under the worst conditions
    i.e. mss*4. This gives slack space of 1 segment for ethernet frames.
    
    For msses slighlty more than ethernet frame, take 3. Try to give slack
    space of 1 frame again.
    
    If mss is huge, force 2*mss. No slack space.
    
    Value 1460*3 is really confusing. Minimal one is 1096*2, but besides
    that it is an arbitrary value. It was meant to be ~4096. 1460*3 is
    just the magic number from RFC, 1460*3 = 1095*4 is the magic :-), so
    that I guess hands typed this themselves.
    
    --------------------
    
    Signed-off-by: David S. Miller <davem@...emloft.net>

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index caf2e2c..c5b911f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -194,12 +194,11 @@ void tcp_select_initial_window(int __space, __u32 mss,
 	 * will be satisfied with 2.
 	 */
 	if (mss > (1<<*rcv_wscale)) {
-		int init_cwnd;
-
-		if (mss > 1460)
+		int init_cwnd = 4;
+		if (mss > 1460*3)
 			init_cwnd = 2;
-		else
-			init_cwnd = (mss > 1095) ? 3 : 4;
+		else if (mss > 1460)
+			init_cwnd = 3;
 		if (*rcv_wnd > init_cwnd*mss)
 			*rcv_wnd = init_cwnd*mss;
 	}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html