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

[Jonathan Morton]

> On 1 Dec, 2019, at 9:03 pm, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
>> 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?

As a safety valve, getting a CE mark is greatly preferable to losing congestion control entirely, or incurring a packet loss as the other alternative congestion signal.  It would only happen if the SCE signal or feedback were seriously disrupted or entirely erased - the latter being the *normal* state of affairs when either endpoint is not SCE aware in the first place.

> Am I right to assume that the fault tolerance requires a relative steady ACK stream though?

It only needs to be sufficient to keep the TCP stream flowing.  If the acks are bursty, that's a separate problem in which it doesn't really matter if they're all present or not.  And technically, the one-bit feedback mechanism is capable of precisely reflecting a sparse sequence of SCE marks using just two acks per mark.

> I fully agree that if ACK thinning is performed it really should be careful to not loose information when doing its job, but SCE hopefully can deal with whatever is out in the field today (I am looking at you DOCSIS uplinks...), no?

Right, that's the essence of the above discussion about relative feedback error, which is the sort of thing that random ack loss or unprincipled ack thinning is likely to introduce.

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).

 - Jonathan Morton