From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 CF3D73B29D; Sun, 1 Dec 2019 14:27:19 -0500 (EST) Received: by mail-lf1-x133.google.com with SMTP id 203so26215169lfa.12; Sun, 01 Dec 2019 11:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HxqgnaBOO+zuI0hDoKEzmEVlWQbMYg9PUbsD9YfLnLU=; b=EzM5Kd0l5IsaO+OHB4o3QdI7a/uT4qca/Xl2mQRsJtSRgxiZNaV2uFgxdus4S8eoJd RHWfZmLFADzNa5FkdixoAG5ayk/10TutRO01t69gVvLxSvU+dyyAl4t/TvW4QwbsW6Ju iIuqHa6wd7PVjxemhy17dbb+08Q8u0dc5jTDcnqHRIeSqHMDAzGRBQ6JUCQULgsjahG/ J3q8kBtHUavQ1dEHp8g4j7+2ZPlex32xiHrNt7I+UmZ+CQRZ56uNGC+EsuMHUryeO6eg wtS1THui5T+13VAeehlrzfm2ogB+Y4GngR8BTjW55lLNISdRUG9oZyabK2f0eXc2eBr+ cdVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HxqgnaBOO+zuI0hDoKEzmEVlWQbMYg9PUbsD9YfLnLU=; b=ByqOT9lvkuh3HB82+FZ3hpLoW7v/cDFh+RBlbaL0T35FsfqqbltFjUrHveygvYS1gy w1/AkGXkkjWXOwGg0O6gq45D3ljWsTK70YGy3NwSbBnRd04YyIUf7WPZvqLf3zuV7vO1 2lH5eV1/w9D8/dCAr9T1HIpAz0ImGS7sAZVo0XChK2uiIlFJlfs+BE2fCafJaiRpt48u kEWrfDlK8rBzOGnhQE60/LEi7oTAR3DGGj3rFCFHrawkfr2KHVSK4tYsYQvKDQyfKCWv BUBHCwifVl4PY2Q5LMkLbGhOTBH+T+0Lp/1PesHk/8nDFkU1FjK73LMQWJWuhIdAq/XM nQ6Q== X-Gm-Message-State: APjAAAXwrnCNRAwp8CxttLAzB3Vro6ViQTG8eB2D+Z5MWsNgUDLiuIMF FqG6ko/TqTU9fIpx2Signu0= X-Google-Smtp-Source: APXvYqxlBr458GhXKwClVwROS3XiGi4DFG1x7In1FKASArnopjM1qNpbNOh0B5i4kvSQK0mbNAJKEg== X-Received: by 2002:a19:ae10:: with SMTP id f16mr25714905lfc.147.1575228438640; Sun, 01 Dec 2019 11:27:18 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id p4sm13889852lji.107.2019.12.01.11.27.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Dec 2019 11:27:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <337C951B-1812-4F20-89CE-F8B6BCF3B7C8@gmx.de> Date: Sun, 1 Dec 2019 21:27:16 +0200 Cc: Carsten Bormann , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com> <297503679.4519449.1575069001960@mail.yahoo.com> <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> <156EA284-C01D-4FAA-89F4-DB448795F7FC@gmx.de> <385CF47C-17AD-4A62-9924-068E1485FFD5@gmail.com> <8C5FD2CE-D24F-4998-A636-8F85279C67BA@gmail.com> <02703449-D6CE-497D-BDBD-D79542D0EACF@gmx.de> <349F14BC-683C-431E-BE8F-8574880F04B9@gmail.com> <337C951B-1812-4F20-89CE-F8B6BCF3B7C8@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) 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:27:20 -0000 > On 1 Dec, 2019, at 9:03 pm, Sebastian Moeller wrote: >=20 >> If less feedback is observed by the sender than intended by the AQM, = growth will continue and the AQM will increase its marking to = compensate, ultimately resorting to a CE mark. =20 >=20 > Well, that seems undesirable? As a safety valve, getting a CE mark is greatly preferable to losing = congestion control entirely, or incurring a packet loss as the other = alternative congestion signal. It would only happen if the SCE signal = or feedback were seriously disrupted or entirely erased - the latter = being the *normal* state of affairs when either endpoint is not SCE = aware in the first place. > Am I right to assume that the fault tolerance requires a relative = steady ACK stream though? It only needs to be sufficient to keep the TCP stream flowing. If the = acks are bursty, that's a separate problem in which it doesn't really = matter if they're all present or not. And technically, the one-bit = feedback mechanism is capable of precisely reflecting a sparse sequence = of SCE marks using just two acks per mark. > 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? Right, that's the essence of the above discussion about relative = feedback error, which is the sort of thing that random ack loss or = unprincipled ack thinning is likely to introduce. Meanwhile, an ack filter that avoids dropping acks in which the reserved = flag bits differ from its successor will not lose any information in the = one-bit scheme. This is what's implemented in Cake (except that not all = the reserved bits are covered yet, only the one we use). - Jonathan Morton