Re: [aqm] [tcpm] TCP ACK Suppression
David Lang <david@lang.hm> Sun, 11 October 2015 22:49 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 0A5271B2E98; Sun, 11 Oct 2015 15:49:45 -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 v89X5Ykw8eeZ; Sun, 11 Oct 2015 15:49:41 -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 7D57B1B2E9A; Sun, 11 Oct 2015 15:49:41 -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 t9BMnPZs008510; Sun, 11 Oct 2015 15:49:25 -0700
Date: Sun, 11 Oct 2015 15:49:25 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <561AD47B.9030602@isi.edu>
Message-ID: <alpine.DEB.2.02.1510111526050.10958@nftneq.ynat.uz>
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>
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/78lxy_espniDPWHlMv6EoedDnes>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "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: Sun, 11 Oct 2015 22:49:45 -0000
On Sun, 11 Oct 2015, Joe Touch wrote: > On 10/11/2015 2:18 PM, David Lang wrote: >> But you will notice that in both cases, I am in favor of reducing the >> number of packets on the wire. Packets not send can't interfere with >> other traffic. > > The degenerate case of this approach is a circuit. Take a look at > Morris's 1997 ICNP paper to see what happens when you end up with one - > or sometimes less than one - packet per round trip time. > > 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, so the proposal of putting a duplicate stretched ack into the queue for the next transmit window when you aggregate packets in the current transmit window should largely mitigate this. In addition, Since cablemodems have been doing this for 15 years, we should be able to get people to look at real-world traffic and tell us how much of a problem this is. > and increases > discretization effects in the TCP algorithms. This is where I disagree with you. The ACK packets are already collapsed time-wise. Whatever timing they had when they were generated, the fact that they are all sitting in the same queue at the same time means taht that timing has been lost, Nobody is adding latency by trying to recreate the time spacing, so the discretization (or as I've been calling it quantitization) of the traffic is happening even if every ACK packet is sent. My contention is that since this is already happening, consolidating the ACK packets into stretched ACKs doesn't make this any worse, and it saves network bandwidth (and decreases latency to the extent that data is acked faster than waiting for the entire chain or original ACKs to get through, especially if that would take multiple transmit windows). As a result, thinning the ACKs is kinder to the network. I am in no way advocating delaying any packet that could be sent, just combining those that have already been delayed. We're talking about ACK packets here, but any protocol that sends short TCP packets is potentially fair game (TCP/SSH for example). If the packets are all sitting in the same queue, they should be able to be combined. This happens on the sending server if multiple writes to the socket happen before the packet has been sent, it should be able to happen on the network as well (further reducing overhead by sending the same data with fewer packets) 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