From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 8F3313B29D; Sun, 1 Dec 2019 15:30:35 -0500 (EST) Received: by mail-lj1-x22e.google.com with SMTP id e10so28352635ljj.6; Sun, 01 Dec 2019 12:30:35 -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=+5m//fTKLrxlEkVLf9sWxeIDNwizGD9+8Y1MB1lXH2w=; b=dBhCzA7wSInwuhjSXTYxfD9aGv5/ShSzOPpFAesTL2Wn/pj32zlNW8bXnp1mtjNLsu NMR5W3C0KTI5NuP4d0pwH69Ho8OsIuCdeYkL+gG5VkTKDlG8vZjgqmYJKRChMvxLlbqG /aXJJ8U/6fgGmPd8rV0ZU2UjVf2K7QRY+7eFJTp1fZlXftL+nYSsdzvyyaqCflGyXZ79 BufpOUkisK5cDXoZ+m/aALpcMwxCkdKqdujDU/OP/lj3I836/3cc46ZigAI+b4FlvkMK NFI4ZqC6umhTND06Aq9vcVXHrT+wPue7jFbEz06zIN6W9GyyBl2yaSHrPsSZXHnjtILi dkXg== 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=+5m//fTKLrxlEkVLf9sWxeIDNwizGD9+8Y1MB1lXH2w=; b=fpgPNPbsG6SBaaiq8ng0+IjqsRvobzFL5V5MAx8saBuUFM8fGcox6Kaa5gvwOjE/Jc GuaFVDfKDu/Tw5ReZ7xa6vSl6ury2CNXw9alUiS+l8rKK5T5uX+M0XLQMeZlV6PkNhTF iKLoVE1G9pW4mwwJ1fYArpWimj0VS8x1+AUs8E7wVZ0XX5tw0U7ahK8fW/HhCy55ZLLM LGhMecqYhgyqPx+8zAFrR1Fx8lTDxG7SWk0YXELP0Wlootin0jwyhn4H6V5M+J+MhTJj kVg7HtJNe1hwcEcLNYIauQnhXfs0cwIijykaEQ23mGh8kKgoA9ht+Tn9r59iYEjZPKpT Xleg== X-Gm-Message-State: APjAAAXM6Lo53MGPqT187QkkSZRUAtxfmrrcM5c1JdyR7hJ2yBzDHjty IrY+TZzBRyIhy6vvuO/Lcpk= X-Google-Smtp-Source: APXvYqxiMSSa4nyfjayq8oxndGdPDyaEXbfkvZ730RdsMsftf/C98HAHMkiAa93ze2zmdL8KecOG1Q== X-Received: by 2002:a2e:9f47:: with SMTP id v7mr7107719ljk.124.1575232234536; Sun, 01 Dec 2019 12:30:34 -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 d24sm13744957ljg.73.2019.12.01.12.30.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Dec 2019 12:30:33 -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: Date: Sun, 1 Dec 2019 22:30:32 +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: [Ecn-sane] [Bloat] sce materials from ietf X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 20:30:35 -0000 > On 1 Dec, 2019, at 9:32 pm, Sebastian Moeller wrote: >=20 >> 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). >=20 > So, to show my lack of knowledge, basically a pure change in sequence = number is acceptable, any other differences should trigger ACK = conservation instead of filtering? You are broadly correct, in that a pure advance of acked sequence number = effectively obsoletes the earlier ack and it is therefore safe (and even = arguably beneficial) to drop it. However a *duplicate* ack should *not* = be dropped, because that may be required to trigger Fast Retransmission = in the absence of SACK. Cake's ack filter is a bit more sophisticated than that, in that it can = also accept certain harmless changes within TCP options. I believe = Timestamps and SACK get special handling along these lines; Timestamps = can always change, SACK gets equivalent "pure superset" logic to detect = when the old ack is completely covered by the new one. Other options = not specifically handled are treated as disqualifying. All this only occurs in two consecutive packets which are both acks for = the same connection and which are both waiting for a delivery = opportunity in the queue. An earlier ack is never delayed just to see = if it can be combined with a later one. The result is a better use of = limited capacity to carry useful payloads, without having to rely on = dropping acks by AQM action (which Codel is actually rather bad at). - Jonathan Morton=