Hi Jonathan,
> On Dec 1, 2019, at 20:27, Jonathan Morton <[email protected]> wrote: > >> On 1 Dec, 2019, at 9:03 pm, Sebastian Moeller <[email protected]> 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 > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
