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

[Sebastian Moeller]

Hi Jonathan,


> On Dec 1, 2019, at 17:54, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 1 Dec, 2019, at 6:35 pm, Sebastian Moeller <moeller0 at 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