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