From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Carsten Bormann <cabo@tzi.org>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] sce materials from ietf
Date: Sun, 1 Dec 2019 22:30:32 +0200 [thread overview]
Message-ID: <DDD6D919-AA33-4046-BB78-7F28E078EE36@gmail.com> (raw)
In-Reply-To: <CEEF5817-3F82-41E5-BEB3-74D1BC964410@gmx.de>
> On 1 Dec, 2019, at 9:32 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> 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).
>
> 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
next prev parent reply other threads:[~2019-12-01 20:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 20:08 [Bloat] " Dave Taht
2019-11-29 21:20 ` Jonathan Morton
2019-11-29 23:10 ` alex.burr
2019-11-30 1:39 ` Jonathan Morton
2019-11-30 7:27 ` [Bloat] [Ecn-sane] " Sebastian Moeller
2019-11-30 14:32 ` Jonathan Morton
2019-11-30 15:42 ` Sebastian Moeller
2019-11-30 17:11 ` Jonathan Morton
2019-12-02 5:38 ` Dave Taht
2019-12-02 7:54 ` Sebastian Moeller
2019-12-02 9:57 ` Pete Heist
2019-11-30 22:17 ` Carsten Bormann
2019-11-30 22:23 ` Jonathan Morton
2019-12-01 16:35 ` Sebastian Moeller
2019-12-01 16:54 ` Jonathan Morton
2019-12-01 19:03 ` Sebastian Moeller
2019-12-01 19:27 ` Jonathan Morton
2019-12-01 19:32 ` Sebastian Moeller
2019-12-01 20:30 ` Jonathan Morton [this message]
2019-12-01 17:30 ` Rodney W. Grimes
2019-12-01 19:17 ` Sebastian Moeller
2019-12-02 5:10 ` Dave Taht
2019-12-02 7:18 ` Sebastian Moeller
2019-12-01 18:06 ` David Collier-Brown
2019-11-29 22:55 ` Rodney W. Grimes
2019-11-29 22:58 ` Rodney W. Grimes
2019-11-30 2:37 ` [Bloat] " Dave Taht
2019-11-30 3:10 ` [Bloat] [Ecn-sane] " Rodney W. Grimes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DDD6D919-AA33-4046-BB78-7F28E078EE36@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cabo@tzi.org \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox