[Bloat] Bloat done correctly?

[Alex Elsayed]

Sebastian Moeller wrote:

> Hi Alex,
> 
> On Jun 12, 2015, at 20:51 , Alex Elsayed
> <eternaleye at gmail.com> wrote:
> 
>> Sebastian Moeller wrote:
>> 
>>> Hi Benjamin,
>>> 
>>> To go off onto a tangent:
>>> 
>>> On Jun 12, 2015, at 06:45 , Benjamin Cronce
>>> <bcronce at 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).

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.

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.

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

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.

> Best Regards
> Sebastuian
> 
> 
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat