From owner-freebsd-transport@freebsd.org Thu Jan 28 20:24:32 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10C1EA3CEB3 for ; Thu, 28 Jan 2016 20:24:32 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E56E91E7A for ; Thu, 28 Jan 2016 20:24:31 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id E4C0BA3CEB2; Thu, 28 Jan 2016 20:24:31 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4524A3CEB1 for ; Thu, 28 Jan 2016 20:24:31 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA20F1E79 for ; Thu, 28 Jan 2016 20:24:31 +0000 (UTC) (envelope-from gallatin@netflix.com) Received: by mail-pf0-x236.google.com with SMTP id 65so28960170pfd.2 for ; Thu, 28 Jan 2016 12:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=Mevii8BOAH1vfCJ3cUGCzQExyc45Ln8TDgS+yUfzvyA=; b=MPMCsDQo1Uw6PcOMhqPwAciggI2lUepnt6tBFGm+GzwujTfUcnnTSoyV1HgaI7V5hv 55xihK4s4tczsfcE1uvIMJnYwUdM9AVU9c2wWbIAF8gLSJ0mHkJwq09kfd5s5MacI6nD +Fl3oi+Jw+uOsu9NjS5qYCrKXa2OaDPVMDfqE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=Mevii8BOAH1vfCJ3cUGCzQExyc45Ln8TDgS+yUfzvyA=; b=PBbuuLOnON8DDEG9Hs068sVk6kEXhyoUSUljA96O6zrSCmqF7AD274Ecw3rUkV7B/S UYRg8R0nEHnkW9CTjTS3rl7ugnVr2EUFkc9sl4ldCWCRSYEGlTW1BHAOtHinFIjyTxIQ BegdWJO90O8BkQxO9Dgqq4P/rd7oARsre8dKTMrubdTbAxuSHNzyhWI9spezBGrKrZ/3 sbphcehVqHW3ddv6SXXuVyr3F2KnICDpyuRnPOnZ32kHSTS1rPACaCHi1a9Ml+IbhLSy 2/2RVoos88+0EqHmaIfgaAdSZRRc3yc+SdFR5lzQofJPkckLpQKB7GisNIFU47K6Tnoj mOlA== X-Gm-Message-State: AG10YOTdWDcDsqFaW0Lp/JMR8x1MH3j31Nv5ywc8ahH1miAMPqNxesBZoBW66dTKBr7wnTJZ X-Received: by 10.98.69.209 with SMTP id n78mr7341200pfi.81.1454012671251; Thu, 28 Jan 2016 12:24:31 -0800 (PST) Received: from [192.168.200.3] (c-73-147-115-187.hsd1.va.comcast.net. [73.147.115.187]) by smtp.gmail.com with ESMTPSA id l9sm18409162pfb.29.2016.01.28.12.24.30 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 12:24:30 -0800 (PST) To: transport@freebsd.org From: Andrew Gallatin Subject: xmit_more / packet batching Message-ID: <56AA78FD.1010007@netflix.com> Date: Thu, 28 Jan 2016 15:24:29 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:24:32 -0000 I brought up packet batching in today's meeting, and mentioned Mellanox asking about a feature like xmit_more in Linux. To recap, "xmit_more" is a flag to an skb in linux that the stack can use to tell the driver that there are more packets coming immediately, and so it is allowed to delay writing any doorbells to notify the NIC about the transmission. This offers a fairly large amount of savings, and it avoids mmio access to the NIC doorbells, and (in Mellanox's case) can be used to reduce transmit completions. There is a description in more detail of how it works in linux at http://netoptimizer.blogspot.com/2014/10/unlocked-10gbps-tx-wirespeed-smallest.html (as I said .. benchmarks .. ) It looks like they are bulking up things as they come out of their qdisc layer, above the drivers. Note that they have a fairly sophisticated set of qdiscs that are usable with modern, multi-queue drivers, as well as centralized software queuing that all drivers use. Without properly adding all those layers, the simplest thing to do would be to just have tcp_output (and other proto output routines) set a similar flag when they are looping, and sending down mbufs to ip_output. The problem with that is simply that (at least for our internet facing workloads at netflix), sending more data on a socket than the tso max seg size is quite rare. (see appended dtrace output from a machine serving ~90K connections at ~85Gb/s) What is unclear to me is whether or not linux would see any benefit from xmit more in our sort of workload. My guess is that it would not, as the qdiscs will not be delaying things, and they'll still be mostly limited to client ack packing, so will also rarely be sending more than a TSO max seg size. Drew c094.ord001.dev# dtrace -s ./xmit_len.d dtrace: script './xmit_len.d' matched 1 probe ^C 0 value ------------- Distribution ------------- count < 1514 |@@@ 1454289 1514 |@@@@@@@@ 4601582 2514 |@@@@@@ 3529106 3514 |@@@@@ 2902881 4514 | 150322 5514 |@@@ 1433990 6514 |@ 722206 7514 | 121788 8514 |@ 855718 9514 |@ 441330 10514 | 86424 11514 |@ 742827 12514 |@ 405603 13514 | 33753 14514 |@ 432492 15514 |@ 451240 16514 |@ 309429 17514 | 67458 18514 | 243994 19514 | 275286 20514 | 27206 21514 | 198855 22514 |@ 291526 23514 | 20636 24514 | 210524 25514 | 175945 26514 | 13526 27514 | 156973 28514 | 174066 29514 | 115377 30514 | 24194 31514 | 138833 32514 | 104053 33514 | 23385 34514 | 131241 35514 | 92529 36514 | 27125 37514 | 88839 38514 | 76915 39514 | 6554 40514 | 86519 41514 | 70078 42514 | 55289 43514 | 16175 44514 | 74943 45514 | 66529 46514 | 12766 47514 | 66808 48514 | 51397 49514 | 14020 50514 | 46155 51514 | 37579 52514 | 9177 53514 | 39342 54514 | 31170 55514 | 8080 56514 | 34876 57514 | 40574 58514 | 32921 59514 | 6768 60514 | 30252 61514 | 25051 62514 | 5609 63514 | 174059 >= 64514 |@ 445810 0 65516 c094.ord001.dev# cat xmit_len.d fbt::mlx5e_xmit:entry { m = (struct mbuf *)arg1; /* @len[0] = quantize(m->M_dat.MH.MH_pkthdr.len); */ @len[0] = lquantize(m->M_dat.MH.MH_pkthdr.len, 1514, 65000, 1000); @m[0] = max(m->M_dat.MH.MH_pkthdr.len); } From owner-freebsd-transport@freebsd.org Fri Jan 29 04:38:13 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F84DA72F81 for ; Fri, 29 Jan 2016 04:38:13 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 527F91D71 for ; Fri, 29 Jan 2016 04:38:13 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 517C7A72F80; Fri, 29 Jan 2016 04:38:13 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51155A72F7F for ; Fri, 29 Jan 2016 04:38:13 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD191D70 for ; Fri, 29 Jan 2016 04:38:13 +0000 (UTC) (envelope-from yongmincho82@gmail.com) Received: by mail-pa0-x231.google.com with SMTP id yy13so34641249pab.3 for ; Thu, 28 Jan 2016 20:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=J0hWhGe3YAW/yk9SwWUJjNgB9u6Yw9goB26nUrnK/Rw=; b=GZtl5xw8jCCdM1uhQKRiYaHvEaZzOt9aZhrNbPobUDOtrl+qVZ/jiUrfteM+VYyUfl fVdAAvr8TFTWbytLqoseUOxJhS5reBO+z4LMVmoPfA5jQWqH/ni69OSTcLkXTf9YPS4P ky73a6z5QTVsl5YMpFCIUK63EAD6+rnZga866ipx1gurEVskKwQsZ757uI1RzFBbpI/A P0nAOV2OyQ6gwCbM3mGP65H2HZ9b4hhDeKH/rs+RcA937somx34mcbIELAO84My3b0rQ LSJJXdZRPJHAUp939NOFku214acyZRtKKf4p27g0pj69bP/VAPRRi473RHTSbEPZzpii hT7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=J0hWhGe3YAW/yk9SwWUJjNgB9u6Yw9goB26nUrnK/Rw=; b=TaH4fdUMwVlaFWaFoQgNscN5vhM/BEXjnT0o1er2uCJI9nKB5lKsUOVII0akmC/aNW oti8sTfSVjwXGsf7TZ2XuO35EiH0pTTVEVSHzc/Lwn/8upKUXRuVeUPQGbDVxQtij8wg /RcgmmeOlPqzRHHp/H5jUYtEeZP8Ul5hKHY2JUA+jduJrP2MfhFO+9lnASLMJP8p2N6B uQIrUJaeLN1OjgpsVuS6XZYbUXVbcZ6AhqSMuAZ9mqfo787oMZxkRKOaE/I3hwFaFId5 P04YRejosdZ1WO2jUr3IY9byYdsOna8JJiN2m/+pI/zXJmHCmQVH7MbPDw7VoJDHlpbY VI6A== X-Gm-Message-State: AG10YORUtwUKg8Y8urMT9+Celn3KlLLgUrLBV7YiNiBtHGmoD0XoH7OqoWXyRKHSDNEnBA== X-Received: by 10.66.122.8 with SMTP id lo8mr10587738pab.35.1454042291608; Thu, 28 Jan 2016 20:38:11 -0800 (PST) Received: from yongmincho-All-Series ([106.247.248.2]) by smtp.gmail.com with ESMTPSA id p20sm19872381pfi.86.2016.01.28.20.38.10 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 28 Jan 2016 20:38:11 -0800 (PST) Date: Fri, 29 Jan 2016 13:38:18 +0900 From: Yongmin Cho To: transport@freebsd.org Subject: Restarting Idle Connections Message-ID: <20160129043817.GA9865@yongmincho-All-Series> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 04:38:13 -0000 Hi, all. I have an opinion about net.inet.tcp.initcwnd_segments. You know, snd_cwnd is restarted transmission after a long idle period(Current RTO). And, All of congestion control algorithm is using newreno_after_idle function after a long idle period. But, The newreno_after_idle function is not using initcwnd_segments. I think, The initcwnd_segments should be used in newreno_after_idle function, If the newreno_after_idle is called. I referred to rfc6928. Please check my opinion. Thank you in advance your answers. From owner-freebsd-transport@freebsd.org Fri Jan 29 21:51:28 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42BFBA73A8E for ; Fri, 29 Jan 2016 21:51:28 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2987A1F3A for ; Fri, 29 Jan 2016 21:51:28 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 26EA8A73A8D; Fri, 29 Jan 2016 21:51:28 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 267DBA73A8C for ; Fri, 29 Jan 2016 21:51:28 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B05B1F39 for ; Fri, 29 Jan 2016 21:51:27 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id BDD6EB890; Fri, 29 Jan 2016 13:51:21 -0800 (PST) Date: Fri, 29 Jan 2016 13:51:21 -0800 From: hiren panchasara To: Yongmin Cho Cc: transport@freebsd.org Subject: Re: Restarting Idle Connections Message-ID: <20160129215121.GJ33155@strugglingcoder.info> References: <20160129043817.GA9865@yongmincho-All-Series> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AXxEqdD4tcVTjWte" Content-Disposition: inline In-Reply-To: <20160129043817.GA9865@yongmincho-All-Series> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:51:28 -0000 --AXxEqdD4tcVTjWte Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01/29/16 at 01:38P, Yongmin Cho wrote: > Hi, all. >=20 > I have an opinion about net.inet.tcp.initcwnd_segments. > You know, snd_cwnd is restarted transmission after a long idle > period(Current RTO). > And, All of congestion control algorithm is using newreno_after_idle > function after a long idle period. > But, The newreno_after_idle function is not using initcwnd_segments. > I think, The initcwnd_segments should be used in newreno_after_idle > function, If the newreno_after_idle is called. > I referred to rfc6928. >=20 > Please check my opinion. You are absolutely right. We (FreeBSD) adopted initcwnd to be 10 segments but never bothered to update newreno_after_idle() function to reflect that in calculating cwnd after idle period. Though the comments in that function clearly says: "The restart window is the initial window or the last CWND, whichever is smaller." I think we should make following change to accommodate it: diff --git a/sys/netinet/cc/cc_newreno.c b/sys/netinet/cc/cc_newreno.c index 97ec35f..5210a45 100644 --- a/sys/netinet/cc/cc_newreno.c +++ b/sys/netinet/cc/cc_newreno.c @@ -166,6 +166,10 @@ newreno_after_idle(struct cc_var *ccv) * * See RFC5681 Section 4.1. "Restarting Idle Connections". */ + if (V_tcp_initcwnd_segments) + rw =3D min(V_tcp_initcwnd_segments * CCV(ccv, t_maxseg), + max(2 * CCV(ccv, t_maxseg), + V_tcp_initcwnd_segments * 1460)); if (V_tcp_do_rfc3390) rw =3D min(4 * CCV(ccv, t_maxseg), max(2 * CCV(ccv, t_maxseg), 4380)); Any inputs? Cheers, Hiren --AXxEqdD4tcVTjWte Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWq97WXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lf38H/2mwyoYYc0ag1MVE1uzhZ0rL K2KTnjZnXFuAw6FLgmUtgNw1ykWD2IjhTmNmzTw03KPmQuKj+FyZUHg78hu4kA/l CbaiIO+1EHw9+aT+2yzZgK5yZLdTIF873sBoCdPWUP826WLjhPuxVox0CPOWzhw1 XuoSOLYZjsTGysdoMA3AyLOB+ESEC4V1Blf5SocdJPDF0y1Cpes3E6HuXxfix3ee kj9bKCZL9jU8DAGZHdT9WwF8qfxqRjzhlOUtzY+3pBxglzXPzlhaxS0mGX/W23Jr MHS9NleAh6M0Ot5M8X8WlXxvwqQdfssKAB3m9JIoTxldbqPRjKOhKALcoG8pqHo= =TCcb -----END PGP SIGNATURE----- --AXxEqdD4tcVTjWte-- From owner-freebsd-transport@freebsd.org Fri Jan 29 21:58:51 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83DDBA73D1D for ; Fri, 29 Jan 2016 21:58:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6A00712B0 for ; Fri, 29 Jan 2016 21:58:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 659A2A73D1C; Fri, 29 Jan 2016 21:58:51 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B382A73D1B for ; Fri, 29 Jan 2016 21:58:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3089412AF for ; Fri, 29 Jan 2016 21:58:50 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 3844BB918; Fri, 29 Jan 2016 13:58:50 -0800 (PST) Date: Fri, 29 Jan 2016 13:58:50 -0800 From: hiren panchasara To: Yongmin Cho Cc: transport@freebsd.org Subject: Re: Restarting Idle Connections Message-ID: <20160129215850.GK33155@strugglingcoder.info> References: <20160129043817.GA9865@yongmincho-All-Series> <20160129215121.GJ33155@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wRokNccIwvMzawGl" Content-Disposition: inline In-Reply-To: <20160129215121.GJ33155@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:58:51 -0000 --wRokNccIwvMzawGl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01/29/16 at 01:51P, hiren panchasara wrote: > On 01/29/16 at 01:38P, Yongmin Cho wrote: > > Hi, all. > >=20 > > I have an opinion about net.inet.tcp.initcwnd_segments. > > You know, snd_cwnd is restarted transmission after a long idle > > period(Current RTO). > > And, All of congestion control algorithm is using newreno_after_idle > > function after a long idle period. > > But, The newreno_after_idle function is not using initcwnd_segments. > > I think, The initcwnd_segments should be used in newreno_after_idle > > function, If the newreno_after_idle is called. > > I referred to rfc6928. > >=20 > > Please check my opinion. >=20 > You are absolutely right. We (FreeBSD) adopted initcwnd to be 10 > segments but never bothered to update newreno_after_idle() function to > reflect that in calculating cwnd after idle period. Though the comments > in that function clearly says: > "The restart window is the initial window or the last CWND, whichever is > smaller." >=20 > I think we should make following change to accommodate it: >=20 > diff --git a/sys/netinet/cc/cc_newreno.c b/sys/netinet/cc/cc_newreno.c > index 97ec35f..5210a45 100644 > --- a/sys/netinet/cc/cc_newreno.c > +++ b/sys/netinet/cc/cc_newreno.c > @@ -166,6 +166,10 @@ newreno_after_idle(struct cc_var *ccv) > * > * See RFC5681 Section 4.1. "Restarting Idle Connections". > */ > + if (V_tcp_initcwnd_segments) > + rw =3D min(V_tcp_initcwnd_segments * CCV(ccv, t_maxseg), > + max(2 * CCV(ccv, t_maxseg), > + V_tcp_initcwnd_segments * 1460)); - if (V_tcp_do_rfc3390) + else if (V_tcp_do_rfc3390)=20 But you get the idea. :-) Cheers, Hiren > rw =3D min(4 * CCV(ccv, t_maxseg), > max(2 * CCV(ccv, t_maxseg), 4380)); >=20 > Any inputs? >=20 > Cheers, > Hiren > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQF8BAABCgBmBQJWq97WXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 > QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lf38H/2mwyoYYc0ag1MVE1uzhZ0rL > K2KTnjZnXFuAw6FLgmUtgNw1ykWD2IjhTmNmzTw03KPmQuKj+FyZUHg78hu4kA/l > CbaiIO+1EHw9+aT+2yzZgK5yZLdTIF873sBoCdPWUP826WLjhPuxVox0CPOWzhw1 > XuoSOLYZjsTGysdoMA3AyLOB+ESEC4V1Blf5SocdJPDF0y1Cpes3E6HuXxfix3ee > kj9bKCZL9jU8DAGZHdT9WwF8qfxqRjzhlOUtzY+3pBxglzXPzlhaxS0mGX/W23Jr > MHS9NleAh6M0Ot5M8X8WlXxvwqQdfssKAB3m9JIoTxldbqPRjKOhKALcoG8pqHo=3D > =3DTCcb > -----END PGP SIGNATURE----- --wRokNccIwvMzawGl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWq+CaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lRREH/18ytIKn9KLieBe7i/G2dLkX ROCsl1Ed6WPhmaIL3HmuD6mjIWttQODEtJmVfaeGwr+pM0vNTeJNoiRBQvyrEdQH 0VupIQQP2pLfuATIkh+vDvzYPkHwSQWxRbKa3lUG5JaXEPnKD+yFyAUhLg9G/E7L yf2WjByMK0mdE/Lhuycg4vYrBimQboewiUwHVvrwaI68WGylbuG5P2xLqSl4fzly Mrf66SyNy+rmYKBGAIajGAnT6I1bchJnzJ+IP6s0CMT8OrY/7ck1owPcGNvU+NUc YGas/ni3QTNtA1Xchtql8WA5GM8n6qYmxukTWwKHbywwTRXVueJ6qxppgzKK2K4= =64N6 -----END PGP SIGNATURE----- --wRokNccIwvMzawGl-- From owner-freebsd-transport@freebsd.org Fri Jan 29 23:23:30 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86909A72999 for ; Fri, 29 Jan 2016 23:23:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 736241725 for ; Fri, 29 Jan 2016 23:23:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 7063CA72998; Fri, 29 Jan 2016 23:23:30 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FF16A72997 for ; Fri, 29 Jan 2016 23:23:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 604DA1724 for ; Fri, 29 Jan 2016 23:23:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 984C1BD57; Fri, 29 Jan 2016 15:23:29 -0800 (PST) Date: Fri, 29 Jan 2016 15:23:29 -0800 From: hiren panchasara To: Yongmin Cho Cc: transport@freebsd.org Subject: Re: Restarting Idle Connections Message-ID: <20160129232329.GL33155@strugglingcoder.info> References: <20160129043817.GA9865@yongmincho-All-Series> <20160129215121.GJ33155@strugglingcoder.info> <20160129215850.GK33155@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8SdtHY/0P4yzaavF" Content-Disposition: inline In-Reply-To: <20160129215850.GK33155@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 23:23:30 -0000 --8SdtHY/0P4yzaavF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01/29/16 at 01:58P, hiren panchasara wrote: > On 01/29/16 at 01:51P, hiren panchasara wrote: > > On 01/29/16 at 01:38P, Yongmin Cho wrote: > > > Hi, all. > > >=20 > > > I have an opinion about net.inet.tcp.initcwnd_segments. > > > You know, snd_cwnd is restarted transmission after a long idle > > > period(Current RTO). > > > And, All of congestion control algorithm is using newreno_after_idle > > > function after a long idle period. > > > But, The newreno_after_idle function is not using initcwnd_segments. > > > I think, The initcwnd_segments should be used in newreno_after_idle > > > function, If the newreno_after_idle is called. > > > I referred to rfc6928. > > >=20 > > > Please check my opinion. > >=20 > > You are absolutely right. We (FreeBSD) adopted initcwnd to be 10 > > segments but never bothered to update newreno_after_idle() function to > > reflect that in calculating cwnd after idle period. Though the comments > > in that function clearly says: > > "The restart window is the initial window or the last CWND, whichever is > > smaller." > >=20 > > I think we should make following change to accommodate it: [snip] https://reviews.freebsd.org/D5124 Cheers, Hiren --8SdtHY/0P4yzaavF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWq/RuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l4zkIAIfTlu5QhtMcZG/+l3K+aSKZ vd8z8P1Mo2nmz3AaHckF3+U+PpuCURubtPninkHVEx5+bD/UiQIx7KUv/yk+vglY wDQY1EXYOERZ2WGdOfC0KRzVLU6T5HoU+MHGyZaIsKxxivmJwP4ritJ1DxUnenxM G9vUkCZIYLc0CxMqL2EBDlQj94mGhe2WauvyJuHZ07Td+4wH5cu2PMG+wqFizg62 jl7BKNvarqc1hjSpKdiAXsgRtxS97q93RhK8/tHIAJetO2dd/nTjpa+4ziGK6xyW XZeU81EvvTOyNX9+ScB+WgywsrYueGwJpe2VWtLrR/8guvQeEzTo3AJCt0G01WY= =+d/g -----END PGP SIGNATURE----- --8SdtHY/0P4yzaavF--