Re: [Bloat] Bloat done correctly?

[Sebastian Moeller <moeller0@gmx.de>]

Hi Alex,

On Jun 12, 2015, at 20:51 , Alex Elsayed <eternaleye@gmail.com> wrote:

> Sebastian Moeller wrote:
> 
>> Hi Benjamin,
>> 
>> To go off onto a tangent:
>> 
>> On Jun 12, 2015, at 06:45 , Benjamin Cronce
>> <bcronce@gmail.com> wrote:
>> 
>>> [...]
>>> Under load while doing P2P(About 80Mb down and 20Mb up just as I started
>>> the test) HFSC: P2P in 20% queue and 80/443/8080 in 40% queue with ACKs
>>> going to a 20% realtime queue http://www.dslreports.com/speedtest/622452
>> 
>> I know this is not really your question, but I think the ACKs should go
>> into the same queue as the matching data packets. Think about it that way,
>> if the data is delayed due to congestion it does not make too much sense
>> to tell the sender to send more faster (which essentially is what ACK
>> prioritization does) as that will not really reduce the congestion but
>> rather increase it. There is one caveat though: when ECN is used it might
>> make sense to send out the ACK that will signal the congestion state back
>> to the sender faster… So if you prioritize ACKs only select those with an
>> ECN-Echo flag ;) @bloat : What do you all think about this refined ACK
>> prioritization scheme?
> 
> I'd say that this is wrongly attempting to bind upstream congestion to 
> downstream congestion.
> 
> Let's have two endpoints, A and B. There exists a stream sent from A towards 
> B.
> 
> If A does not receive an ack from B in a timely manner, it draws inference 
> as to the congestion on the path _towards_ B. Prioritizing acks from B to A 
> thus makes this _more accurate to reality_ - a lost ack (rather than the 
> absence of an ack due to a lost packet) actually behaves as misinformation 
> to the sender, causing them to

	So my silent assumption was that we talk about a debloated access link, after all this is the bloat list and we think we have solved most of that problem. So there is no major congestion on the part of the uplink where prioritization would work (the home router’s egress interface), so not misinformation there. As I started in another mail to Benjamin, instead of ACK prioritization I would de-bloat the access  link ;)
	I add that the currently recommenders solution shaper+fq_codel or cake both give some precedence to sparse flows, which does boost small packets like ACKs (until there are too many competing spade flows then all flows are treated as non-sparse, both AQMs also IIRC preferably drop/mark packets from large flows so ACKs will still get some love on upstream congestion).

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

> 
> The latter point is a big one: Prioritized ACKs (may) reduce spurious 
> resends, especially on asymmetric connections - and suprious resends are 
> pure network inefficiency. Especially since the data packets are likely far 
> larger than the ACKs. Which would _also_ get resent.

	But for the spurious resends you either breed to drop several ACKs in a row or delay the ACKs long enough that the RTO triggers; both are situation I would recommend to avoid anyways ;) So I am still not convinced on the ACK priority rationale, assuming a de-bloated access link. If you have enough control over the link to implement ACK games, I believe you are better off de-bloating it more thoroughly… Again not an expert just a layman’s opinion.

Best Regards
	Sebastuian


> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat