Hi Alex,
On Jun 13, 2015, at 00:56 , Alex Elsayed <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
