Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 22:31 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 473121B2B3E; Fri, 9 Oct 2015 15:31:29 -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 4YBKfdmmaiuX; Fri, 9 Oct 2015 15:31:24 -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 0F51A1B2A60; Fri, 9 Oct 2015 15:31:23 -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 t99MVE27025049; Fri, 9 Oct 2015 15:31:14 -0700
Date: Fri, 9 Oct 2015 15:31:14 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <56183E93.1010308@isi.edu>
Message-ID: <alpine.DEB.2.02.1510091528320.3717@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>
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/sihzw9Vla1iQ4S_mWm6ooHM4hMA>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>, "mallman@icir.org" <mallman@icir.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: Fri, 09 Oct 2015 22:31:29 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> On 10/9/2015 3:16 PM, David Lang wrote:
> ...
>>> Wouldn't it have been cleaner with more appropriate network provisioning?
>>
>> "more appropriate network provisioning" is not always going to result in
>> more bandwidth the way you want it to.
>>
>> If there is established infrastructure that can handle X in one
>> direction and 100X in the other direction, but "appropriate network
>> provisioning" requires that the ratio never be more than 3x, it's not
>> going to magically increase bandwidth in one direction, all it can do is
>> cap bandwidth in the other direction (throwing away capacity)
>
> Sure, but we're dealing with a problem that arises when the ratio can't
> support 40:1. That's quite an asymmetry except in extreme cases where we
> already know extreme measures are required (e.g., satcom with telco
> backchannels).

that's not the only situation we're talking about here.

Also, keep in mind that your 40:1 ratio assumes that there is no traffic going 
the other direction.

If you have one person trying to watch streaming video while another person is 
uploading pictures to facebook, you can run into trouble at much more even 
ratios.

<skipping the rest since it seems we are talking past each other, each restating 
the same things>

David Lang