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

[Sebastian Moeller]

Hi Jonathan,



> On Dec 1, 2019, at 20:27, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> 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.

	Well, yes, I fully agree, I was referring to the "less feedback is observed by the sender than intended" part; I think it is great that SCE is safe by design in this regard.


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

	"unprincipled ack thinning" nice description.


> 
> 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?

Best Regards
	Sebastian

> 
> - Jonathan Morton
>