Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 18:48 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 832B21B49F0 for <aqm@ietfa.amsl.com>; Fri, 9 Oct 2015 11:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 D_UwyjUF0znn for <aqm@ietfa.amsl.com>; Fri, 9 Oct 2015 11:48:37 -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 4B3A91B4A0B for <aqm@ietf.org>; Fri, 9 Oct 2015 11:48:35 -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 t99ImRLd023525; Fri, 9 Oct 2015 11:48:27 -0700
Date: Fri, 09 Oct 2015 11:48:27 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5617F5B4.2090307@isi.edu>
Message-ID: <alpine.DEB.2.02.1510091146520.3717@nftneq.ynat.uz>
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> <5616E42D.5090402@isi.edu> <alpine.DEB.2.02.1510081517470.3852@nftneq.ynat.uz> <5616FAFA.5020707@isi.edu> <alpine.DEB.2.02.1510081647590.3852@nftneq.ynat.uz> <DM2PR0301MB065553C4CF55E7A6E5E23317A8340@DM2PR0301MB0655.namprd03.prod.outlook.com> <alpine.DEB.2.02.1510081731260.3852@nftneq.ynat.uz> <DM2PR0301MB06554D0E836BC2A8F67E12F2A8340@DM2PR0301MB0655.namprd03.prod.outlook.com> <alpine.DEB.2.02.1510082055510.2943@nftneq.ynat.uz> <CAK6E8=c_h2dMstJSSO9ATh1XUgriWOyeVixk4DHi+PAjO6LSMg@mail.gmail.com> <5617F5B4.2090307@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/5wUIUK5griTVbyNF5ymgC2w2tkE>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Christian Huitema <huitema@microsoft.com>, "aqm@ietf.org" <aqm@ietf.org>, Yuchung Cheng <ycheng@google.com>, 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: Fri, 09 Oct 2015 18:48:39 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> On 10/9/2015 10:04 AM, Yuchung Cheng wrote:
>>     That definitely contradicts the TCP specs. So it is very much in
>>     "don't go there" territory...
>>
>> By 'not going there' you are crippling people's networks for the sake of
>> following a spec. Rather than following the letter of the old spec, we
>> should be looking at the reasons for it, and reasons to make exceptions.
>> There is a long history of introducing new things that break the old way
>> of doing things, from breaking "classful" network routing to Anycast,
>> there are lots of things that "broke" the old way of doing things.
>
> There's a useful less on here:
>
> Van Jacobson, in an unpublished appendix to his Sigcomm 1988 paper on
> congestion control, discussed how TCP should restart after idle, and
> that this would require a "time since last sent" timer. A footnote to
> that text noted that there was already a "time since last received"
> timer, and that - 'since TCP traffic is typically symmetric', it would
> be reasonable to use that timer for slow-start restart after idle.
>
> A few years later, when developing HTTP, Tim Berners-Lee said that he
> didn't want to use FTP for file transfers because it would open two
> connections for one file from one location (one for control, one for the
> file). He said that was heavyweight, and that (paraphrasing), 'most of
> the time, we'll only get one file from a location'. So we ended up with TCP.
>
> When the web became more sophisticated, users wanted many files from one
> server for each page visited (images, formatting, etc.). What we ended
> up with was burst after idle for HTTP traffic.
>
> I.e., there are a lot of things there for a reason. Yes, nothing is
> immutable, but simply claiming "I need it now" and "nobody has
> complained" isn't considered a reasonable way to deploy changes in the wild.

similarly, it's not right to assume that the conditions haven't changed.

In this case, we have a changed situation. The ACKs are _not_ going to flow 
at their 'natural' rate. That assumption has already failed. What we are 
discussion is the impact of these changes in the face of this broken assumption.

David Lang