Re: [aqm] [tcpm] TCP ACK Suppression
Joe Touch <touch@isi.edu> Tue, 13 October 2015 14:55 UTC
Return-Path: <touch@isi.edu>
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 D4D2E1B45CC; Tue, 13 Oct 2015 07:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iUdCXtSo7_5x; Tue, 13 Oct 2015 07:55:29 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1ED71B45CA; Tue, 13 Oct 2015 07:55:28 -0700 (PDT)
Received: from [128.9.176.211] (c2-vpn02.isi.edu [128.9.176.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t9DEsx68006639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Oct 2015 07:55:02 -0700 (PDT)
To: David Lang <david@lang.hm>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@isi.edu> <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz> <56183E93.1010308@isi.edu> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@isi.edu> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz> <5618AF0A.4010101@isi.edu> <alpine.DEB.2.02.1510101439090.1856@nftneq.ynat.uz> <alpine.DEB.2.02.1510101525170.1856@nftneq.ynat.uz> <F62FF3E5-EC9E-4534-B005-2A987C63C41D@gmail.com> <alpine.DEB.2.02.1510102042280.1856@nftneq.ynat.uz> <5619F00A.2040009@isi.edu> <alpine.DEB.2.02.1510111358310.2053@nftneq.ynat.uz> <561AD47B.9030602@isi.edu> <alpine.DEB.2.02.1510111526050.10958@nftneq.ynat.uz>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <561D1B40.2060006@isi.edu>
Date: Tue, 13 Oct 2015 07:54:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1510111526050.10958@nftneq.ynat.uz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/Cj5C39G8CcDcifpAagR8m-yenB8>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, touch@isi.edu, "mallman@icir.org" <mallman@icir.org>, "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, Jonathan Morton <chromatix99@gmail.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] [tcpm] 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: Tue, 13 Oct 2015 14:55:31 -0000
David, On 10/11/2015 3:49 PM, David Lang wrote: >> One of the reasons we use packets is to provide more timely, >> fine-grained feedback between endpoints. Aggregating them at the source >> or in the network (rather than at the receiver) can amplify reaction to >> packet loss (when the aggregate ACK is lost) > > the issue of amplified reaction to packet loss is a valid one, but > packet loss is still pretty rare, But you claim to need to drop the ACKs to avoid dropping other packets. What's to say that 1) the ACKs won't end up getting dropped in your system or 2) the ACKs won't get dropped further downstream? Again, *you* don't know. ... >> and increases >> discretization effects in the TCP algorithms. > > This is where I disagree with you. The ACK packets are already collapsed > time-wise. Time is only one element of the discretization. The other is fate sharing - dropping one aggregate ACK has the effect of dropping the entire set of un-aggregated ones. The stream of unaggregated ACKs gives TCP a robustness to drops, but you're now forcing a large burst of drops for a specific packet type. That's the problem. We've gone round this issue for a lot of messages, but the key point is that this isn't a new idea, nor are the numerous considerations and concerns. Ultimately, if you have too many packets from a protocol that reacts to congestion, the correct solution is to provide that feedback and let the ends figure out how to respond. That's the only solution that will work when (not if) new messages or encrypted headers enter the picture. These kinds of in-network hacks are what's really killing the ability of the Internet to evolve. Joe
- [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