Re: [aqm] [tcpm] TCP ACK Suppression
David Lang <david@lang.hm> Tue, 13 October 2015 19:36 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 EDDCA1A8968; Tue, 13 Oct 2015 12:36:13 -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 7tAz_SveVkKG; Tue, 13 Oct 2015 12:36:12 -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 20B251A8965; Tue, 13 Oct 2015 12:36:12 -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 t9DJa1AG027663; Tue, 13 Oct 2015 12:36:02 -0700
Date: Tue, 13 Oct 2015 12:36:01 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Greg White <g.white@CableLabs.com>
In-Reply-To: <D2419657.54F70%g.white@cablelabs.com>
Message-ID: <alpine.DEB.2.02.1510131224050.6031@nftneq.ynat.uz>
References: <5618005A.8070303@isi.edu> <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> <CAJq5cE1KM-wxTB8nB_AbXcniLbCbHn6M=4bM0uaLRY2s=YNUjQ@mail.gmail.com> <D2419657.54F70%g.white@cablelabs.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/SGcAw-5piugN0E6btEJEP-dkigY>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>, "mallman@icir.org" <mallman@icir.org>, "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.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 19:36:14 -0000
On Mon, 12 Oct 2015, Greg White wrote: >> 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 agree, *iff* they are not DupACKs signalling packet loss. Do existing and > future cable modems take that subtle distinction into account? > > I presume that they are not discarding DupACKs or corrupting SACK in some way > (the whole point of specialized ACK handling is to ensure good TCP performance > after all), but since the algorithms are proprietary, for existing cable > modems I don't know. I will contact the developers as well as run some tests > on a few modems to get a better idea (and maybe Mikael already has some data > from his recent testing he could share?). For future modems, I can add an > explicit reference to RFC3449 in the DOCSIS 3.1 spec just in case implementers > aren't aware for some reason. It should also say that AQM is needed on the downstream side to protect against transmit bursts. The suggestion was posted early in this thread (but not in someting I can quickly find) that to harden the connection against the aggregate ACK being lost, it should be sent again in a separate transmit window. I latched onto that and think the right thing to do is to duplicate the aggregate ACK that's created and put it at the beginning of the queue that remains after the current transmit window. If there are more ACKs in the next transmit window, it will get aggregated into them and not cause any additional traffic. If there are not any more ACKs in the next transmit window, and the first ACK was lost, it will replace it with the minimum of delay If there are not any more ACKs in the next transmit window, and the first ACK was not lost, we are now transmitting a duplicate ACK, which may be interpreted as a signal to speed up tranmission (depending on the exact timing of the arrivials of these two ACKs). While this is not good, we already need to be protected from transmit bursts, so this is just another possible cause for such bursts. 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