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

[Jonathan Morton <chromatix99@gmail.com>]

> On 1 Dec, 2019, at 6:35 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Belt and suspenders, eh? But realistically, the idea of using an accumulating SCE counter to allow for a lossy reverse ACK path seems sort of okay (after all TCP relies on the same, so there would be a nice symmetry ).

Sure, we did think of several schemes that used a counter.  But when it came down to actually implementing it, we decided to try the simplest possible solution first and see how well it worked in practice.  It turned out to work very well, and can recover cleanly from as much as 100% relative feedback error caused by ack loss:

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.  This is, incidentally, exactly what happens if the receiver *or* sender are completely SCE-ignorant, and looks very much like RFC-3168 behaviour, which is entirely intentional.

If feedback is systematically doubled by the time it reaches the sender, perhaps through faulty ack filtering on the return path, it will back off more than intended, the bottleneck queue will empty, and AQM feedback will consequently reduce or cease entirely.  Only a very serious fault would re-inject ESCE feedback once SCE marking has completely ceased, so the sender will then grow back towards the correct cwnd after a relatively small negative excursion.

The above represents both extremes of 100% relative error in the feedback, which is shown to be safe and reasonably tolerable.  Smaller errors due to random ack loss are more likely, and consequently easier to tolerate in a closed negative-feedback control loop.

 - Jonathan Morton