Re: [aqm] [tcpm] TCP ACK Suppression

Joe Touch <touch@isi.edu> Fri, 09 October 2015 22:39 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 532D71B2D83; Fri, 9 Oct 2015 15:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 79c6LhQqA2By; Fri, 9 Oct 2015 15:39:40 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA511B2D7F; Fri, 9 Oct 2015 15:39:40 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t99MdAeH008748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2015 15:39:10 -0700 (PDT)
To: David Lang <david@lang.hm>
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> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz>
From: Joe Touch <touch@isi.edu>
Message-ID: <5618420E.9040609@isi.edu>
Date: Fri, 09 Oct 2015 15:39:10 -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: <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/ttssyMshLz2t32ITpo_wdwvLFWs>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, touch@isi.edu, "mallman@icir.org" <mallman@icir.org>, "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.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: Fri, 09 Oct 2015 22:39:41 -0000


On 10/9/2015 3:31 PM, David Lang wrote:
> 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.

FWIW, I wasn't - I was assuming that 40:1 is fine if what you intend to
support is browsing only.

> 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.

Restated, you run into trouble because you sold a service you didn't
provision for ;-)

(or, more to the point, you took a gamble that you could sell a useful
service with a particular assumption about traffic ratios, and that
assumption no longer holds)

Again, IMO TCP isn't to be tampered with merely to support a business
model, and that's all I see so far.

Joe