Re: [Bloat] Bloat done correctly?

[Sebastian Moeller <moeller0@gmx.de>]

Hi Alex,

On Jun 13, 2015, at 00:56 , Alex Elsayed <eternaleye@gmail.com> wrote:

> [...]
> Sure, the access link is debloated. But there's also the remote downlink, 
> etc. Our access link may not be the bottleneck for the ACKs.

	I am confused now, prioritizing ACKs will only work (reliably) on the access link (for normal end users, business contracts might be different) and the ISP will either ignore them or re-map them to zero. Often enough the access link really is the relevant bottleneck, but you are right there a number of situations where the congestion is upstream and neither de-bloating the home link nor prioritizing ACKs in the home network will help.


> 
> And yes, boosting sparse flows is likely a more beneficial behavior than 
> prioritizing ACKs specifically (especially on deeply asymmetric links)
> 
>>> 
>>> 1.) back off sending when the sending channel is not congested and
>>> 2.) resend a packet that _already arrived_.
>> 
>> But TCP ACKs are cumulative so the information from a lost ACK are also
>> included in the next, so you need to loose a stretch of ACKs before your
>> scenario becomes relevant, no?
> 
> Sure, though again the local access link isn't the only possible source of 
> congestion.

	But isn’t it the only link that is sufficiently under our control to allow to implement remedies?

> [...]
> 
> Sure, debloating more thoroughly is the best solution. It's just a nonlocal 
> solution, and until debloating conquers the world, local solutions have a 
> place.

	So currently the observation is that for most situations even 1-tier shaper+fq_codel as implemented in sqm-scripts helps to fight access link buffer bloat efficiently enough that ACK-priritization does not seem to be needed nor recommended anymore (well unless your router only allows playing ACK-games but does not offer flow fair queueing)

Best Regards
	Sebastian