Re: [aqm] TCP ACK Suppression

Yuchung Cheng <ycheng@google.com> Wed, 07 October 2015 19:30 UTC

Return-Path: <ycheng@google.com>
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 45EC81AD0C8 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 12:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 zPTECHbBzaiQ for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 12:30:08 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDE11AD0C9 for <aqm@ietf.org>; Wed, 7 Oct 2015 12:30:08 -0700 (PDT)
Received: by vkao3 with SMTP id o3so18342787vka.2 for <aqm@ietf.org>; Wed, 07 Oct 2015 12:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B/heLFTeB18MBVZAybnlHpEgQBjgAQWzGHP6OirOz/I=; b=BSh611gzyNvf2FZ2W5Gxr6vbVPzJVFPZz5IBcD4LLlOtgxK3SuMNV0V3KSbCxAzTZ/ ahlihDNknPXEdQ/oLwE5gB9020b/GPP2+yOOM4wCKnRQ2Ju4pfqfO6q8IPwXlMwaEFR4 kXUBpQ7ME5VCsPw7jqQHvcSFe4j6VWOaJeoEnXVCjcm7J+EAgrMjhA+zJ6EOlf6ezCF5 hdhWUjUUEIB0DanDAh9o8SK7lv70dhv6/d5k0pmVAhtnevO1t5sgt2Gj7aoihvSF05tL 5l4a/42c/tyZCMrJDA9WvXFcitcmBw9ecWMC+efR9HIRaO2CpzMRKEr/TLkADjs4EY8O B/0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B/heLFTeB18MBVZAybnlHpEgQBjgAQWzGHP6OirOz/I=; b=CvVKglt17SXJj4hcaAhZuAOueiW7p43DrzsecZQfohK6sJ0AUQ6OX3p8Xv1mhqSlvW utg4g6Q1zkc5ldbXIDLzRVu29cw0Bzv6t6FhL3mSIgUg7kcZlwV97xPE86LZjOsii+GA wYSOMKROp5vbJ+o2WIp12T7RWvH7hkp1TTKbnx/rWGrRzjIotDt8+4bPxyXLmOrRgZYv Ux6g3uAA3ywhVhxWJxHZe72Cg0YHZ5xEKybAVn35BG/HJpvYY6RIo4foFpdcBY3yI4TD bOV7T0CuIjDuw9HWgCiUfsFWAJdBmqw+Nh/b4U/DliZQrV//pb3k53mfSyWFK8lbQhMJ itzA==
X-Gm-Message-State: ALoCoQkRXw6ffr9K+Zi/mWWGyveo2ZT8gtSPgJna4XETG96gUmp33cb1C52CMDA0kjXgZzWI036T
X-Received: by 10.31.149.88 with SMTP id x85mr2433656vkd.103.1444246207381; Wed, 07 Oct 2015 12:30:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.193.86 with HTTP; Wed, 7 Oct 2015 12:29:27 -0700 (PDT)
In-Reply-To: <1BFAC0A1D7955144A2444E902CB628F865B0C249@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <CAFxEvqouQv-xkLWXxxBTw5swSFazWSb_Hak3ZOmnBSeQbE20hw@mail.gmail.com> <1BFAC0A1D7955144A2444E902CB628F865B0C249@US70TWXCHMBA12.zam.alcatel-lucent.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 7 Oct 2015 12:29:27 -0700
Message-ID: <CAK6E8=ekLRCA-_TcOOfDk1QYs_BHGoCk9t4sqmn++A6EU17bPg@mail.gmail.com>
To: "Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/i__3luJBePDwUYpwbUVjfx4MS3o>
Cc: Steve Bauer <bauer@mit.edu>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, "aqm@ietf.org" <aqm@ietf.org>, Greg White <g.white@cablelabs.com>
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: Wed, 07 Oct 2015 19:30:10 -0000

On Wed, Oct 7, 2015 at 8:50 AM, Francini, Andrea (Andrea)
<andrea.francini@alcatel-lucent.com> wrote:
> How about the effect of ACK suppression on the growth of the congestion window, for TCP sources where the trigger for window growth is the arrival of an ACK, not the number of bytes it acknowledges?
>
> The Appropriate Byte Counting (ABC) option (https://tools.ietf.org/html/rfc3465) was addressing a similar issue with delayed ACKs, but it looks like it is no longer available in Linux (http://www.spinics.net/lists/netdev/msg225164.html).
>
> Is there another workaround already available?
Yes. Linux removed abc support b/c it simply does not need that. For
congestion control, Linux always pays attention to how many actual
(mss-sized) data packets are acked or sacked (i.e., delivered), not
how many acks received.

Similarly, it does not count "3" dupacks to trigger fast recovery (in
SACK). It counts how many packets are delivered out of order. So
literally you can compress ack w/ SACK options too.

Having said that, big stretch acks introduce big data bursts in a
ack-clocking sliding window protocol. Hence fq/pacing really helps on
DOCSIS links.

>
> Andrea
>
>
> -----Original Message-----
> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Steve Bauer
> Sent: Wednesday, October 07, 2015 7:41 AM
> To: LAUTENSCHLAEGER, Wolfram (Wolfram)
> Cc: Greg White; aqm@ietf.org
> Subject: Re: [aqm] TCP ACK Suppression
>
> On Wed, Oct 7, 2015 at 3:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram)
> <wolfram.lautenschlaeger@alcatel-lucent.com> wrote:
>> Is this specialized upstream TCP ACK handling, particularly the
>> prioritization a general recommendation in all access technologies?
>> Perhaps it should be, since otherwise up and downstream TCP flows interfere
>> in a crazy queue oscillation that is typically misinterpreted by AQMs.
>> Is this topic addressed in some RFC already?
>
> See:
>
> RFC 3449: TCP Performance Implications of Network Path Asymmetry
> https://tools.ietf.org/html/rfc3449
>
> in particular section 5.2
>
>      5.2 TYPE 1: Reverse Link Bandwidth Management ...................19
>        5.2.1 ACK Filtering ...........................................20
>        5.2.2 ACK Decimation ..........................................21
>
> Steven Bauer
> MIT
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm