From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 D07963B2A4 for ; Tue, 12 Dec 2017 16:29:41 -0500 (EST) Received: by mail-qt0-x234.google.com with SMTP id 33so835394qtv.1 for ; Tue, 12 Dec 2017 13:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oHrNgaW0erX8o8Y/jB/+pSxxsS5RDZdTEHgVMMegvJE=; b=VPXG7pGagx5kpodasbR9uqgqmcU1nIypVndVgXDocyZ/YdjDxezuQraYbMDW6OyNcd 7yoa+PYN0f8yFcjC51+VSOaV1yub/WhxJ4B8pIR9Uk/mbagG07Av315eSMXhMRs+jeUL aBszcsVBiTkfImJy+ZYwUa+06LUWEEm+HyPlGap23P+/QL9EqDPYP1mxuw05YpPeeh5e 3CfdAyE8EdtdUo+r14Bn7cPoi+xG+pUGkHXqwQYh4bM9cqrPlne5C0B/vwDivgE/qCsT lCPFH9aXrjIHUxQxaKTN22YVrmeax8h//YvkrWeY72B7BGqdfAvsZxuZWzJtClgGQ0Sp CMNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oHrNgaW0erX8o8Y/jB/+pSxxsS5RDZdTEHgVMMegvJE=; b=fUqRtn2YXQFiWwhvi0GfxO7B7Q809ohXE+7Q0IuHemN5fGrmnkWcFnb0/AuykVhflJ co7z1xdBYxK2SXaTCNZ6z8qd3tL0wBA4YGIaQjOAzo8wwm+alkF+/xclaT6xboc+GMcl w7E10CQCKgKCXXOj+I6Er2/giMOb39ZEruTU6mrP7Ydi8chZd6I4hCF//4aq/kVW3jda RiosbyoYjFzdQCkV3LWgc+IoW7qT4fKqA+J/L2D+vaoXjKsdevAm/CJw+1PYkMQvDjpb wIbWd8msGwajlByEu8hJPTBxpwyNqedatihAL5DmJcnx/tsIV7UNIshy6RlBLPdN4ioJ FsMg== X-Gm-Message-State: AKGB3mLlro8nIa3ddT64cDhYAQs2/AADLuGQf0bqHVO49JYP0njAIhSY hfnTtqndGQaQkkwKTPoeP9ePpP0Hm4d4DCorICk= X-Google-Smtp-Source: ACJfBouDreSLDW9Zk+4TlYGSVSx2c0zjUqAinaKuc8KFH9kjk2ZhCDgBX7aoOzoWup0rTx6IAIhMqPbSA6aPTyYBbJE= X-Received: by 10.200.39.148 with SMTP id w20mr8311288qtw.178.1513114181380; Tue, 12 Dec 2017 13:29:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.179 with HTTP; Tue, 12 Dec 2017 13:29:39 -0800 (PST) Received: by 10.140.102.179 with HTTP; Tue, 12 Dec 2017 13:29:39 -0800 (PST) In-Reply-To: References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <019064B3-835C-4D59-BE52-9E86EE08CD02@gmx.de> From: Jonathan Morton Date: Tue, 12 Dec 2017 23:29:39 +0200 Message-ID: To: David Lang Cc: Benjamin Cronce , bloat Content-Type: multipart/alternative; boundary="001a11c0019849309705602b59ac" Subject: Re: [Bloat] benefits of ack filtering 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: Tue, 12 Dec 2017 21:29:41 -0000 --001a11c0019849309705602b59ac Content-Type: text/plain; charset="UTF-8" Taking into account a variety of scenarios, I have difficulty identifying a case where an ack deleted by a reasonably conservative algorithm would have given any practical benefit had it remained, *including* considerations of smoothness of ack-clocking. If the uplink isn't congested then no deletions occur; if it is congested then there's a high probability that a flow-isolation scheme would deliver several acks back to back between larger data packets, so an ack-clocked sender would still be "lumpy". That's without even considering aggregation and discrete MAC-grant links (ie. DOCSIS). Deleting unnecessary acks from a congested uplink also frees capacity for competing traffic, which I think we can agree is a good thing when it has no deleterous side-effects. I have not yet personally verified that the algorithm now in Cake matches my assumptions. If it doesn't, I'll push for modifications. Incidentally, I am of the opinion that ECE can safely be ignored for ack-filtering purposes. Normally ECE remains set in all acks until a CWR is heard in reply, so it only matters that the ECE signal isn't *delayed* - which ack-filtering actually helps to achieve. More sophisticated uses of ECE should also survive this as long as statistical independence is maintained. - Jonathan Morton --001a11c0019849309705602b59ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Taking into account a variety of scenarios, I have difficult= y identifying a case where an ack deleted by a reasonably conservative algo= rithm would have given any practical benefit had it remained, *including* c= onsiderations of smoothness of ack-clocking.

If the uplink isn't congested then no deletions occur; i= f it is congested then there's a high probability that a flow-isolation= scheme would deliver several acks back to back between larger data packets= , so an ack-clocked sender would still be "lumpy".=C2=A0 That'= ;s without even considering aggregation and discrete MAC-grant links (ie. D= OCSIS).

Deleting unnecessary acks from a congested uplink also frees= capacity for competing traffic, which I think we can agree is a good thing= when it has no deleterous side-effects.

I have not yet personally verified that the algorithm now in= Cake matches my assumptions.=C2=A0 If it doesn't, I'll push for mo= difications.

Incidentally, I am of the opinion that ECE can safely be ign= ored for ack-filtering purposes.=C2=A0 Normally ECE remains set in all acks= until a CWR is heard in reply, so it only matters that the ECE signal isn&= #39;t *delayed* - which ack-filtering actually helps to achieve.=C2=A0 More= sophisticated uses of ECE should also survive this as long as statistical = independence is maintained.

- Jonathan Morton

--001a11c0019849309705602b59ac--