From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id F18B121F3DD for ; Fri, 12 Jun 2015 11:52:05 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z3U3b-0002ij-9B for bloat@lists.bufferbloat.net; Fri, 12 Jun 2015 20:51:59 +0200 Received: from 50.245.141.77 ([50.245.141.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2015 20:51:59 +0200 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2015 20:51:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alex Elsayed Date: Fri, 12 Jun 2015 11:51:50 -0700 Message-ID: References: <6AD8E150-5751-43AC-8F6C-8175C1E92DE1@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 50.245.141.77 User-Agent: KNode/4.14.6 Subject: Re: [Bloat] Bloat done correctly? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:52:34 -0000 Sebastian Moeller wrote: > Hi Benjamin, > > To go off onto a tangent: > > On Jun 12, 2015, at 06:45 , Benjamin Cronce > 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 1.) back off sending when the sending channel is not congested and 2.) resend a packet that _already arrived_. 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.