Hi Jonathan,
> On Dec 1, 2019, at 17:54, Jonathan Morton <chromati...@gmail.com> wrote:
>
>> On 1 Dec, 2019, at 6:35 pm, Sebastian Moeller <moell...@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.
+1; simplicity has its own elegance.
> 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.
Well, that seems undesirable?
> 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.
Am I right to assume that the fault tolerance requires a relative
steady ACK stream though?
>
> The above represents both extremes of 100% relative error in the feedback,
> which is shown to be safe and reasonably tolerable.
Great that the current simple scheme is safe (and for my pie in the sky
"let's high-jack the URG pointer" scheme essential, since there are valid
existimg users of the URG mechanism, at least google tells me that both ftp and
telnet are candidates; bit seem rare enough though that giving these 16+1 bits
something else to do might be fun).
> Smaller errors due to random ack loss are more likely, and consequently
> easier to tolerate in a closed negative-feedback control loop.
Fair enough.
Best Regards
Sebastian
>
> - Jonathan Morton
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
