From owner-freebsd-transport@freebsd.org Wed Jan 15 20:42:42 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3BEE11FCBC2 for ; Wed, 15 Jan 2020 20:42:42 +0000 (UTC) (envelope-from rs.ietf@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47yfQm491Kz3yvB; Wed, 15 Jan 2020 20:42:40 +0000 (UTC) (envelope-from rs.ietf@gmx.at) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579120950; bh=7lxXFIez7ra+c1BZORab57HwZeneholx/WZ0bilEDfo=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=SbuHPbpHXQIB1kCc0Hjgyt22rZz+Jn0+XNlC6TKiH+I0zY1oHAK/hTNW1tRKHPedv jy+LYB0VEa60OrJOBK40gc1CCvfLz9o6yT+33CBWyXpFrb0gcPWe97khFo2DchWh5R 5qeFmu9agbqkVbjMKJ0Z8Xo8kpNpdC7R8oORb3qs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.107] ([185.236.167.136]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgNcz-1jIcWn1yqV-00huy2; Wed, 15 Jan 2020 21:42:30 +0100 Subject: Re: [tcpm] ECN++ From: "Scheffenegger, Richard" To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Message-ID: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:lzfaD4KngQq7OG+TVhoLLX67a8ThhCGLwl836E5aVg64oXiKx9l n3X2IrH31ogzrTNOLArnlBAdM9j8FVQvT1ymXhTPXuKninsRuFd8TZ8NL1uFUl8LmPuJJeF 1YGolINqZ9j+tZB1oC7jbqVYLiDovFE7uLW/19+u+yhMRX0mZTpmtZfZIXXqd2cTCVjKB40 dbOSVmPeE+M9E+MHvnk6A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:sa2UCxDS7QA=:9ymjJscTgOZjs3vyf9Aj8O SVUYJffnN6uKuswda4kg+85zmoGI+EXfU6taAbjnbsQKzQEzxAp/EeExfvTWFWeJr3HlYxo8O FwEQJqmSt/+FGw65iXotSCTKR1hmpWdzjSCUnfzKwL8XN0YRVh/6/Y7XmJj9Sj01xY/zZVA/D h1864QLsPH7T5NX4KQthForGxoa4k9pA85F4ppo9VWlRV82GvAw3AukdkxPWxxvKO9YJT06a6 yFlWrw3otynsxlkeh/bqV0RuUUM6myr818sojetDzXerYlA/Sbh87QguIsRnjGI2nd5J6sMDN P3o3DQIoGlocR2EIta3ClTYPWIfNQbdbtMHO9sL1apo+GuliD9Fx45w3porZLoIuuHpEo/1uM REX/DSM9z2myMQvbsFG/aZxC3SkL6eJlNtRakafAcRjryH0b9c86bve3uhDNPHS6MOeNCbo7y n9QvRIV7ronyQI5oafLHlLvHCfIkNevxpaVPX8wOEsP1H+ZaN1UlU53EJEjN90bTVg7AmWw1U rHxm3klPYDi1YWvlIRDPFMHA8H0xYbcbrjbKUrb7OO5quA4uFDRMUEgHE6GtWJj3HEHhGlbU3 vbIY4gVzKXOHG51iqALH3lhunc/vtR1fKdCGjNEI180Gqb1u1khVQgRciVm0JV11Ne5nXSsQl y5XsMTHjdTk+ezUBJee33m5bYyFeb9NEdCROENXfOca1OiVRr3piADSXUwnf3yJtlka6YpmXB cd9z1czZhVJa+I5HXClfb8/PtRZ9TL5d4DVqH1OEWNXtuJ/xaB0bohgs/V9t+JLXn42DP6I0+ ulGLq/qJZasebUD+5IxEBYcq65LSiE6ezR1m8qUpSDZ//eB1LqGlha3lEdIEKMsxK+r2i59Bv gK4LTBR0qIz3zuGDd8EMKLwf2lSl5VcVN1ZSge7dTb1pazsWZrI13cRP+52R85GuZ1+baNuml ksJbGLUBTwi1h/FOEJqwlV/i7KpCUM77ozmE2A6xHBdExpEtBu3yb8X8jgqRgN+/dc6wHoM7s QYQGVQIzyGuKK0+w/uO44tQqqTZHxR+qTIofimEM8kRXLS3UwAl93YvqiIGGWgjeNPn+xg7y4 y6xpERzwG79FLt6V9Feh4xjZSfLHDhuHfLOtgvIcPg20yhfta2SVvyi2/cg1v3iviQzB3W2vM pMuJC5oMZ2OY30rZh2Xf0GNcMWv91LEwkITPusQFYuOCMLz6QljH9VPWfwFsHztq9GjwGcgHn N68MLbapj+RBjYkfXuxrggLjnXGWxpeqPWS0IPA== X-Rspamd-Queue-Id: 47yfQm491Kz3yvB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=SbuHPbpH; dmarc=none; spf=pass (mx1.freebsd.org: domain of rs.ietf@gmx.at designates 212.227.15.19 as permitted sender) smtp.mailfrom=rs.ietf@gmx.at X-Spamd-Result: default: False [-2.35 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; FREEMAIL_FROM(0.00)[gmx.at]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gmx.at]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCVD_IN_DNSWL_NONE(0.00)[19.15.227.212.list.dnswl.org : 127.0.3.0]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_MEDIUM(-0.85)[-0.846,0]; IP_SCORE(0.00)[ip: (-6.56), ipnet: 212.227.0.0/16(-1.16), asn: 8560(2.24), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.at]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sun, 02 Feb 2020 10:34:31 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 15 Jan 2020 20:42:42 -0000 X-Original-Date: Wed, 15 Jan 2020 21:42:28 +0100 X-List-Received-Date: Wed, 15 Jan 2020 20:42:42 -0000 Hi, Yet another interesting observation =E2=80=93 as fbsd currently doesn=E2= =80=99t refrain from marking SACK-retransmission to be not-ECT, you can actually end up getting a CE mark on a retransmission across a ECN-enabled congestion poin= t. Obviously this is better than loss=E2=80=A6 What happens next is, that fbsd "honors" that ECE mark, since it is in loss-recovery, not congestion-recovery. It adjusts the recovery_point to the current snd_max (rightmost sent segment), and adjusts ssthresh and cwnd by multiplicative decrease factor... Furthermore, it appears that it also resets the traversal of the SACK scoreboard (incidential a "good" thing, as a few earlier retransmissions also got dropped, not marked, and are being resent without an RTO). But in the context of ECN++, what would be the expected response here? I assume, that with the exception of the fresh traversal of the SACK scoreboard, the above steps seem sensible. Any thoughts on this interesting interaction between ECE (during SACK loss recovery)? Best regards, Richard Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: > Marcelo, Bob, > > I just noted that there is a slight oversight in FreeBSD currently, > which results in all session that are simultaneously ECN-enabled and > SACK-permitted to effectively send out retransmissions with the ECT0 > codepoint. > > Strictly speaking, this is in violation of RFC3168, but might also be a > good (nearly a decade long) validation of the performance of ECN++ for > all types of data segments (new and retransmitted ones), although at a > low and implicit exposure... > > > On that note, since I think ECN++ is quite valuable (with a number of > published research finding this change to be crucial), perhaps you can > summarize the outstanding issues (other than more reviewers required; I > admit I still haven't gone through all the delta between -04 and -05). > > Best regards, > =C2=A0 Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From owner-freebsd-transport@freebsd.org Sat Jan 25 15:47:31 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA9361F2CD0 for ; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 484gPb54z4z4f0s for ; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AC5FE1F2CCF; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) Delivered-To: transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AAF991F2CCE for ; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484gPb3fd5z4f0q for ; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 74548A847 for ; Sat, 25 Jan 2020 15:47:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00PFlVsL042697 for ; Sat, 25 Jan 2020 15:47:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00PFlVi0042696 for transport@FreeBSD.org; Sat, 25 Jan 2020 15:47:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: transport@FreeBSD.org Subject: [Bug 227303] TCP: huge cwnd does not slowly decay while app/rwnd limited, interacts badly with rwnd autosize Date: Sat, 25 Jan 2020 15:47:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rscheff@gmx.at X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: transport@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 02 Feb 2020 11:29:51 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 25 Jan 2020 15:47:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227303 Richard Scheffenegger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tuexen@freebsd.org --- Comment #7 from Richard Scheffenegger --- We have a partial fix (to not grow cwnd excessively when app limited) now. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-transport@freebsd.org Sat Jan 25 16:19:48 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F6251F34BA for ; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 484h6r3qNhz4gCD for ; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 833931F34B9; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) Delivered-To: transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8301F1F34B7 for ; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484h6r30wDz4gCC for ; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5E5D2ADAE for ; Sat, 25 Jan 2020 16:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00PGJmOL018365 for ; Sat, 25 Jan 2020 16:19:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00PGJm5F018362 for transport@FreeBSD.org; Sat, 25 Jan 2020 16:19:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: transport@FreeBSD.org Subject: [Bug 243590] TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf issues Date: Sat, 25 Jan 2020 16:19:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rscheff@gmx.at X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 02 Feb 2020 11:29:59 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 25 Jan 2020 16:19:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243590 Richard Scheffenegger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rscheff@gmx.at, | |transport@FreeBSD.org, | |tuexen@freebsd.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-transport@freebsd.org Sun Jan 26 02:08:52 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 46D2322B7D3 for ; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 484xBX1B2Hz4Q28 for ; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2887C22B7D2; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) Delivered-To: transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 284F222B7D1 for ; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484xBX0FFdz4Q27 for ; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 03C6519D41 for ; Sun, 26 Jan 2020 02:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00Q28pCI082170 for ; Sun, 26 Jan 2020 02:08:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00Q28p7R082169 for transport@FreeBSD.org; Sun, 26 Jan 2020 02:08:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: transport@FreeBSD.org Subject: [Bug 243590] TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf issues Date: Sun, 26 Jan 2020 02:08:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 02 Feb 2020 11:30:05 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 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: Sun, 26 Jan 2020 02:08:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243590 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-transport@freebsd.org Sat Jan 25 10:41:29 2020 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D7EB23B956 for ; Sat, 25 Jan 2020 10:41:29 +0000 (UTC) (envelope-from rs.ietf@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484XcS101rz4MMr; Sat, 25 Jan 2020 10:41:27 +0000 (UTC) (envelope-from rs.ietf@gmx.at) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579948878; bh=I5SztyzGmiwJb2U2aQx5dTwK+xQEXprJN8a3841DXWM=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=Fd6bd8Ch+sUz4xty4KfOjPbcfo2gecSocJWxjm+twwc9hUypvRS/rCZqwedqobdGC YiZhjBpF/c23pQzZ09FTqC/PiPXAhJ3UbieeVJhwTnMlM8Wwe3ZsSCn3ylaS+vlqEO dLUsnIkc/7aKFsH5COidsOvWiWH1iJlzXHOR6vNo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.249.64.52] ([217.70.211.10]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPokD-1jIAv701Hn-00MvIq; Sat, 25 Jan 2020 11:41:18 +0100 Subject: Re: [tcpm] ECN++ From: "Scheffenegger, Richard" To: "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Message-ID: Date: Sat, 25 Jan 2020 11:41:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:v4ptnx/ebscp41id6r+EjVbn4v4AQtSwm8WkATgtOJn7+lY1SCM OFY7aYDn6KFPtFgotqi7DVKnDkJuaui5QrOTFBgDhAis1odgHFgM8aX38NmrX/hIAkfJCRR 2T1AQ/Q7brt/MfrycHZGdQ6PSn6bvoGj/us4Sd9mVSMpJwkko7xaVy4xzq2AvDAW27sLnys onYAGdTIFbYI+nyitEIog== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:nOUA/135oJw=:woihVO0nYhQYldf5R41LzS rzbrUObSegyJR2kk+u4OclrPombyJkNhfyDnm9+67EVZu94hXR2By51zdNaqMop2mC2IzAC4D 3fNdP2svbx5y/yzLZMwbZYbjnhAS4xM10UcQo6lzPjjFoj/e1qN0/f6tFP+s44b6XTs/JVJ4n VW9KUZYqqaZluov/1M0acBHOZ5d/MS/b9owyXIhRauoIYJaESAwMkmDUx+lIcb2Q6fF0HvNqw 9dNUBDbhSgT1EkdzaIR76fEk1USHtkqOnVS7WoED9ZSO1kyy+bpsbv2+YfoHupcam4Mm4HhlX 8Io51FcqSxzgz92AbSHjZ8e/y6gUYFg9GsnkTGJL8LANpBsJ+E4fqz8DlgPaREQyY29sYe4kP QyG9gAiOvXfx/COzXYbV4/4AQZweA8wT1mEeqXRmjThsg9Nvp7v8TKuVeHCWn4gzriqOKuDnr GB4+TW4zAt5lIVMrf1oJuT5OfQVGRDH9TNxeHMNM90vpCRvfRtCyLCu4jvQxs63qAi0/1iMOc 9NtZDzNoD7HvP77j4Q29D8PiqSJpp3J2jllQ2+xigzepKAfWIu9tZiTRCIgxiuafZQCFpZ3GU AzZeosRk0TsXb0ag2vsxPb0COV3qWf5BB7Rs9XEYSkiNkkLKagh9MVYmaENfkq1KFGN1bwqpx 3gX0sSHwgzC4ue6Z8GMW6eO7JGx7BEJV2KHYPwUXvu9ZScYJ1mpeRE+RMdHDrBIfaxOXtAZaK yJ6mFcDoumI7D1In1BprsFbKeyyADB026pRqUE7vz9KDgmU6sfNbCeVXMLmVSs/YuvQI5hINh nFnZIBhUFIiV9OMm4rLdgZ1bIH07wtEDg9IXkHbLXm1ysuwb93dQ5488chnGRm3cYbDX0NsR6 MOpi6KWxWpiCgL+K0jmttZwSj3PfXs+FSaQxUGgvscCm7JjkjzI4TcE3sWKsRfHVyePJpZ+QC MQawY4K84DTfKuyI9yVG1yMNO5xeO02Tun+Jn5BpEtqJrv8uehsFfXi+RcOsAG04pjGV8rS4M vOh2nEoIuZ9Imfl3sCsCV85NLXdGcwf7PVh1Bb02wWgxzucszJ+uwm9YT8FbniDShybT5Xru9 TauZu/Xrf3OrvYWuB9ZCq34BY/N77gq3KYoiaspf+mZ+uRVYLkpxNiC1KrkNhbfv14pH3Zp7I Z+Tu7MGzlnBojLuaNOHlLG7wsH7a5XeMD9Gx7010bbGKKMQA75hkfoS6qnW4E+xFU9MW556sl n7gyr9CSBphKTvBqf X-Rspamd-Queue-Id: 484XcS101rz4MMr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=Fd6bd8Ch; dmarc=none; spf=pass (mx1.freebsd.org: domain of rs.ietf@gmx.at designates 212.227.15.18 as permitted sender) smtp.mailfrom=rs.ietf@gmx.at X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; FREEMAIL_FROM(0.00)[gmx.at]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gmx.at]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCVD_IN_DNSWL_NONE(0.00)[18.15.227.212.list.dnswl.org : 127.0.3.0]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-7.42), ipnet: 212.227.0.0/16(-1.15), asn: 8560(2.24), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.at]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sun, 02 Feb 2020 12:44:22 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 25 Jan 2020 10:41:29 -0000 Hi Group, Marcelo, Bob, Another update in this context, which IMHO may be discussed as an actual change of mechanism with ECN++. I was looking into the very poor interaction of ECN between a Linux client and a BSD server, with request-response workload. That is, where each side sends out less than MSS data, before the application waits for the other side to respond to this. Neal pointed out this statement in RFC3168: ...the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction. ... When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits. However, BSD is sending out the CWR as soon as possible - while Linux interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it is received with (new) data. But binding the CWR flag to a new data segment delays the ECN signaling loop artificially (for long runs of unidirectional transmitted data), and it is not clear what the benefit there would be, as the CWR flag is not retransmitted anyway (thus not bound to a point in the sequence number space). I therefore propose a change in the Generalized ECN draft, to lift the above restriction (while it is "only" a SHOULD, this is one more example of an overly strict receiving-side implementation), and no longer artificially delay the CWR signal - to become also more useful for passive measurements. Richard For those interested: The effect of ignoring the CWR on non-new-data segments by Linux is, that the ECE flag is left latched. Thus BSD continues window-after-window with cwnd reductions, and due to another bug where the ECN-induced reduction has no lower bound, eventually cwnd ends up at 0 Byte and is only increased to 1 Byte by a Timer - until by pure chance, the CWR is sent together with 1 new byte of data. But in the preceeding minutes, the session only saw progress by less than 1 byte / RTT... Am 15.01.2020 um 21:42 schrieb Scheffenegger, Richard: > > Hi, > > Yet another interesting observation =E2=80=93 as fbsd currently doesn=E2= =80=99t refrain > from marking SACK-retransmission to be not-ECT, you can actually end up > getting a CE mark on a retransmission across a ECN-enabled congestion > point. > > Obviously this is better than loss=E2=80=A6 > > What happens next is, that fbsd "honors" that ECE mark, since it is in > loss-recovery, not congestion-recovery. It adjusts the recovery_point to > the current snd_max (rightmost sent segment), and adjusts ssthresh and > cwnd by multiplicative decrease factor... > > Furthermore, it appears that it also resets the traversal of the SACK > scoreboard (incidential a "good" thing, as a few earlier retransmissions > also got dropped, not marked, and are being resent without an RTO). > > But in the context of ECN++, what would be the expected response here? > > I assume, that with the exception of the fresh traversal of the SACK > scoreboard, the above steps seem sensible. > > Any thoughts on this interesting interaction between ECE (during SACK > loss recovery)? > > Best regards, > =C2=A0=C2=A0 Richard > > > > Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: >> Marcelo, Bob, >> >> I just noted that there is a slight oversight in FreeBSD currently, >> which results in all session that are simultaneously ECN-enabled and >> SACK-permitted to effectively send out retransmissions with the ECT0 >> codepoint. >> >> Strictly speaking, this is in violation of RFC3168, but might also be a >> good (nearly a decade long) validation of the performance of ECN++ for >> all types of data segments (new and retransmitted ones), although at a >> low and implicit exposure... >> >> >> On that note, since I think ECN++ is quite valuable (with a number of >> published research finding this change to be crucial), perhaps you can >> summarize the outstanding issues (other than more reviewers required; I >> admit I still haven't gone through all the delta between -04 and -05). >> >> Best regards, >> =C2=A0=C2=A0 Richard >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm