Re: [aqm] TCP ACK Suppression

Joe Touch <touch@isi.edu> Thu, 08 October 2015 22:11 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 95D611B2D94 for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 15:11:26 -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 X_WH8OLRq34m for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 15:11:25 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B5E1B2D8C for <aqm@ietf.org>; Thu, 8 Oct 2015 15:11:25 -0700 (PDT)
Received: from [10.123.86.139] (usc-secure-wireless-206-139.usc.edu [68.181.206.139]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t98MAjNJ016723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Oct 2015 15:10:46 -0700 (PDT)
To: Yuchung Cheng <ycheng@google.com>, David Lang <david@lang.hm>
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> <CAK6E8=ePXkK4-=As2QQJCZjOyK7-NvC2njiYrsLzGEsqqFDJxg@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <5616E9E2.3000806@isi.edu>
Date: Thu, 8 Oct 2015 15:10:42 -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: <CAK6E8=ePXkK4-=As2QQJCZjOyK7-NvC2njiYrsLzGEsqqFDJxg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t98MAjNJ016723
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/QiIDPKrJhyca-ux_rpSf1LAfB8o>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@cablelabs.com>, "aqm@ietf.org" <aqm@ietf.org>, touch@isi.edu
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:11:26 -0000

The fact that you need to do something to go fast does not make it safe
for everyone else.

Again, TCP is intended to work everywhere, not to work well anywhere.

Joe

On 10/8/2015 2:52 PM, Yuchung Cheng wrote:
> 
> 
> On Thu, Oct 8, 2015 at 2:31 PM, David Lang <david@lang.hm
> <mailto:david@lang.hm>> 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.
> 
>     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?
> 
> 
> I would like to add that GRO also cause stretched ACKs (acking up to
> 64KB), and GRO is crucial to reduce cycles for +10Gbps transfers on some
> architectures.
> 
> 
>     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?
> 
>     David Lang
> 
> 
>     _______________________________________________
>     aqm mailing list
>     aqm@ietf.org <mailto:aqm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/aqm
> 
>