Re: [aqm] TCP ACK Suppression
David Lang <david@lang.hm> Thu, 08 October 2015 22:29 UTC
Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839781B2DEF for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 15:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXsLcm0uoyqD for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 15:29:56 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7BB1B2DEA for <aqm@ietf.org>; Thu, 8 Oct 2015 15:29:56 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t98MTiBI016152; Thu, 8 Oct 2015 15:29:44 -0700
Date: Thu, 08 Oct 2015 15:29:44 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5616E42D.5090402@isi.edu>
Message-ID: <alpine.DEB.2.02.1510081517470.3852@nftneq.ynat.uz>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5616DCD9.8@isi.edu> <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz> <5616E42D.5090402@isi.edu>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/cui7Tj7Z7yhXBSH9PVwM0it-yT4>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 22:29:58 -0000
On Thu, 8 Oct 2015, Joe Touch wrote: > On 10/8/2015 2:31 PM, David Lang wrote: >> On Thu, 8 Oct 2015, Joe Touch wrote: >> >>> On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: >>> ... >>>> Is this topic addressed in some RFC already? >>> >>> It's a direct violation of RFC793, which expects one ACK for every two >>> segments: >>> >>> 4.2 Generating Acknowledgments >>> >>> The delayed ACK algorithm specified in [Bra89] SHOULD be used by a >>> TCP receiver. When used, a TCP receiver MUST NOT excessively delay >>> acknowledgments. Specifically, an ACK SHOULD be generated for at >>> least every second full-sized segment, and MUST be generated within >>> 500 ms of the arrival of the first unacknowledged packet. >> >> actually, this is only a violation of the SHOULD section, not the MUST >> section. > > When you violate a SHOULD, you need to have a good reason that applies > in a limited subset of cases. > > "it benefits me" isn't one of them, otherwise the SHOULD would *always* > apply. > >> And if the Ack packets are going to arrive at wire-speed anyway (due to >> other causes), is there really an advantage to having 32 ack packets >> arriving one after the other instead of making it so that the first ack >> packet (which arrives at the same time) can ack everything? > > If the first ACK confirms everything, you're giving the endpoint a false > sense of how fast the data was received. This is valid only if the > *last* ACK is the only one you retain, but then you'll increase delay. why does it give the server a false sense of how fast the data was received? the packets don't have timestamps that the server can trust, they are just packets arriving. And if the server concludes something different from 32 packets arriving, each acking 2 packet, but all arriving one after the other at it's wire speed (let's say it's a slow network, only Gig-E) compared to a single packet arriving that acks 64 packets of data at once, it's doing something very strange and making assumptions about how the network works that are invalid. > Unless you know that the endpoint supports ABC and pacing, yes, there's > a very distinct advantage to getting 32 ACKs rather than 1. It also > helps with better accuracy on the RTT calculation, which is based on > sampling (and you've killed 97% of the samples). the 97% of the samples that I've killed would be producing invalid data for your calculation because they were delayed in returning. The one packet I'd deliver would be accurate for the last data it acks, the others would all give misleading info. >> And if there is such an advantage, does it outweight the disadvantages >> that the extra ack packets cause by causing highly asymmetric links to >> be overloaded and drop packets? > > Why is it so bad to drop packets? because forcing packets for other services to be dropped to make room for acks degrades those other services. > Cumulative ACKs will still work > properly in the presence of the losses. If you make reasonable progress, > you have to determine whether the lost ACKs should make you slow down. the problem isn't if acks are dropped, it's when the acks fill the available bandwidth so that other services get dropped. > AFAICT, this isn't horrible if you KNOW something specific about the > other end (ABC + pacing), but how can you know? In a closed deployment, > maybe. But this IMO is over-optimizing TCP for a very specific environment. > > TCP isn't supposed to be the most efficient in EVERY corner case. It's > supposed to *always work* in EVERY corner case. I don't see how it fails to work in this case. As people have pointed out, some cable routers have been doing this for 15 years and the Internet has not imploded from it yet, so the drawbacks of dropping these already-delayed and redundant ack packets cannot be the end-of-the-internet that you are painting it to be. We are talking about only doing this in one specific case, the case where other things have already caused some of the acks to be delayed to the point where later acks have 'caught up' with them on the network and both early and late acks are sitting in the same queue on the same device waiting to be sent at the same time. At this point there are three possiblilities 1. all the acks get sent back-to-back, wasting bandwith with their redundancy 2. send only the newest ack, trashing all the ones that would be redundant 3. the total of the acks that are queued exceeds the next transmit window, so only some of the acks get sent, the newest one doesn't and gets delayed further. we know that #2 doesn't break the Internet, it's within the range of responses permitted by the RFC SHOULD. It decreases load on congested links. But you keep insisting that it's a horrible thing to consider doing. David Lang
- [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression LAUTENSCHLAEGER, Wolfram (Wolfram)
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Clark Gaylord
- Re: [aqm] TCP ACK Suppression Steve Bauer
- Re: [aqm] TCP ACK Suppression Francini, Andrea (Andrea)
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression Rick Jones
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Dave Taht
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Simon Barber
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang