Re: [Bloat] [Ecn-sane] sce materials from ietf

[Jonathan Morton <chromatix99@gmail.com>]

> 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