From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 47C613B29D; Sun, 1 Dec 2019 14:17:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575227838; bh=2qKxDDvkdueyR6dl8gFO6MuFNATDgedEcQp1XPbaRII=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=O/nga7TEf0ZW8qsroVRDwzYYKUZ5SwSDyJTNvqXrpbUe3EoULRfQu2s9ExfCLUMff QzQ0zuvE1caWAhft8otdnuiPCeDFybZ3HDCt+CsFjLOcIvjFV8HP+POU4j22OEEpYF 2LsIUfRlvldBqrARuy4dnPxgjpNSonmWtvsHK4d4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([95.116.232.196]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtfJd-1hmqIr383D-00v436; Sun, 01 Dec 2019 20:17:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <201912011730.xB1HUERp026709@gndrsh.dnsmgr.net> Date: Sun, 1 Dec 2019 20:17:17 +0100 Cc: Jonathan Morton , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <201912011730.xB1HUERp026709@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:SML7S94EycEU+bgDXv5Ij0ZL5b4uq+WGJebYJxtLTtr7N3i2oHE oZIZ7zTkR3z22sltA0Hx84HdUwx5AKtq+7b8N116alE1MXFTd8ifwadcXrn6N1P3uc0tNSS 69ch3jbpFT+g4ZMOVLKkN+5tGz/uslcugKT8Vf0pVqQMMeAqfHTrGRIcgfn1cVOL4XzNZO1 6qoXvvlIQEM8U3H9PfKGw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:syboRG1uqG0=:Njlk3G/SuD1NByYdto4MC/ y63cJ01tSKgOnz7MqHe7tWXbnJDldr2qPy3dTFawLgmy0tuWgM20OQQ8QZ9rfoOrTBQOfZ6JZ vkZ2ltJNXz14cae3Z2NmRMdjUSJgjnSFKxWALTpYCz4gutwVxQr5vwHU5JXt7Xlb/N5qcSY9i f58nkUabbqOmqi5a1w7q+nDqZGIJYWGYjL04SQypFXbveZZx6IsV0kP0iOv+4JOZAhomrM+WD CVpQ5eVWpRIcIeyblulk8c47W7yB3EmG+CPFSiOpvoAHJTs5qD9g8Q2Ec390PDwAFyWhs5BbP bqtBAR/pLty7YW9ft06n0MSVMUchTcS5AmzdkPcAWMIbTgYzCyPvU7+CFfpAMDoVpPcELjepT lwoYLAvI/l8In75uexOEf0F/ops3qM5e3UQtoXozol/Z2pHuZGMPBguSYYv4XOfZjHL6UI2Hy WseJAA2SBDbpUC2t5umkiLX0FuGel0eQB4GjRALmpbyHW3y6eT5lGVMgUzQIU9vNxMXzNrVsy SbPErEO0D52acE/1F0X5lPDa+E0tOIzjZjLrHu/owsUtTKlS5Dj4Kzlr8W3cImC4gN/TOkKLO o0PWJBsyKcGUDLOy/Cup43qkVeItwP1YD/wG2K/Hk3HeHcImOEA29oCZ6kW1FLZ0v31ZgMuCY 1E7zLHGU1nmFnnlrkTt5vpL6bifiQ2RDA1SS0fw5bW2Q/JTXvzuy5jLpVwVlXkco4tf+3zfXg jKWFIAPG1i88wxXJSGbSiap/C7LhEOZxfna9BCye1W1fESCExy5ObODzK9JKwXU0gaBPMcZdf HOJoXJbnUrnOjg6/EbRk434u/Fk081yGT3uBW3E5fxnOTcFuzSI/XONq1CW5Y0SvE5ElesSC5 V+vlPRtD4NHoQkREeP4k79OChonsyyELb9ZfEFk+WRsOacQWRnBT7sB/bEucsrpsue1T7ZELV tEjl4U3JgdR+mwWb2aeeK1hG0JVNgmCDc4kHRK+2HXOAlZ3bXLprNiWOfrNMkVMU386IZxrxh vC3d7QVXDS+5JGaeblyq/q30QHbYnhla3xhEK7Pnrxww6AYsGy4TF4cD2hf5AAY9YMR1Zw+bD jR5Hm9pe/KcxroYaGLodqyGrqCzm/xX1BzEy4TWa1i0k/hlHcClp8Yl7kZQuf13nmJNAyh005 rjBvMpWAKJnbk7CZUiHrq2vHHd/MIJksdxgPGosZjFi1bS5VEJzv2vzP8o4C906XFB/TT7FtH a7FqaIhHXIAlP1z9T48ts6k5N/W8MSaO3f58hgA== Subject: Re: [Bloat] [Ecn-sane] sce materials from ietf X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 19:17:20 -0000 Hi Rodney, > On Dec 1, 2019, at 18:30, Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> = wrote: >=20 >> Hi Jonathan, >>=20 >>=20 >>> On Nov 30, 2019, at 23:23, Jonathan Morton = wrote: >>>=20 >>>> On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote: >>>>=20 >>>>> There are unfortunate problems with introducing new TCP options, = in that some overzealous firewalls block traffic which uses them. This = would be a deployment hazard for SCE, which merely using a spare header = flag avoids. So instead we are still planning to use the spare bit - = which happens to be one that AccECN also uses, but AccECN negotiates in = such a way that SCE can safely use it even with an AccECN capable = partner. >>>>=20 >>>> This got me curious: Do you have any evidence that firewalls are = friendlier to new flags than to new options? >>>=20 >>> Mirja Kuhlewind said as much during the TCPM session we attended, = and she ought to know. There appear to have been several studies = performed on this subject; reserved TCP flags tend to get ignored pretty = well, but unknown TCP options tend to get either stripped or blocked. >>>=20 >>> This influenced the design of AccECN as well; in an early version it = would have used only a TCP option and left the TCP flags alone. When it = was found that firewalls would often interfere with this, the three-bit = field in the TCP flags area was cooked up. >>=20 >>=20 >> Belt and suspenders, eh? But realistically, the idea of using an = accumulating SCE counter to allow for a lossy reverse ACK path seems = sort of okay (after all TCP relies on the same, so there would be a nice = symmetry ). >> I really wonder whether SCE could not, in addition to its current = bit, borrow the URG pointer field in cases when it is not used, or not = fully used (if the MSS is smaller than 64K there might be a few bits = leftover, with an MTU < 2000 I would expect that ~5 bits might still be = usable in that rate case). I might be completely of to lunch here, but = boy a nice rarely used contiguous 16bit field in the TCP header, what = kind of mischief one could arrange with that ;) Looking at the AccECN = draft, I see that my idea is not terribly original... But, hey for SCE = having an additional higher fidelity SCE counter might be a nice = addition, assuming URG(0), urgent pointer > 0 will not bleached/rejected = by uninitiated TCP stacks/middleboxes... >=20 > We need to fix the ACK issues rather than continue to work around it. = Ack thinning is good, as long as it does not cause information loss. = There is no draft/RFC on this, one needs to be written that explains you = can not just ignore all the bits, you have to preserve the reserve bits, = so you can only thin if they are the same. Jonathan already fixed Cake = (I think that is the one that has ACK thinning) to not collapse ACK's = that have different bit 7 values. Well, I detest ACK thinning and believe that the network should = not try to second guess the users traffic (dropping/marking on reaching = capacity is acceptable, but the kind of silent ACK thinning some DOCSIS = ISPs perform seems actively user-hostile). But thinning or no thinning, = the accumulative signaling is how the ACK stream deals with (reasonably) = lossy paths, and I think any additional signaling via pure ACK packets = should simply be tolerant to unexpected losses. I fully agree that if = ACK thinning is performed it really should be careful to not loose = information when doing its job, but SCE hopefully can deal with whatever = is out in the field today (I am looking at you DOCSIS uplinks...), no? >=20 > Note that I consider the time of the arriving ACKS to also be = informaition, RACK for instance uses that, so in the case of RACK any = thinning could be considered bad. =20 I am with you here, if the end-points decided to exchange = packets the network should do its best to deliver these. That is = orthogonal to the question whether a every-two-MSS packets ACK rate is = ideal for all/most applications. > BUTT I'll settle for not tossing reserved bit changes away as a "good = enough" step forward that should be simple to implement (2 gate delay = xor/or function). Fair enough, question is more, what behavior happens out in the = field, and could any other bit be toggled ACK by ACK to reduce the = likelihood of an ACK filte to trigger? Best Regards Sebastian >=20 >> Sebastian >>> - Jonathan Morton > --=20 > Rod Grimes = rgrimes@freebsd.org