Re: [aqm] [tcpm] TCP ACK Suppression

Joe Touch <touch@isi.edu> Fri, 09 October 2015 22:24 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 11A661B4DBF; Fri, 9 Oct 2015 15:24:42 -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 7c2oLuxqBIf9; Fri, 9 Oct 2015 15:24: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 5888D1B4DB7; Fri, 9 Oct 2015 15:24: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 t99MOJYS006232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2015 15:24:19 -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>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <56183E93.1010308@isi.edu>
Date: Fri, 09 Oct 2015 15:24:19 -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.1510091511540.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/CNZq94awNoRAry5WAaP1lcOaMnU>
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:24:42 -0000


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

>> Why are you blaming TCP?
> 
> first off, didn't you see the smiley?
> 
> But treating your question as serious, it's because as RFC3449 shows,
> highly assymetric networks or networks with other traffic on them don't
> work with TCP the way you want it to work. So the option is to modify
> TCP or tinker with the packets to leverage less commonly used features
> of TCP (or features that are implicit in the design rather than explicit)

The former is always on the table - that's what TCPM is for.

The latter has always been problematic, exactly because it's subject to
tragedy-of-the-commons. TCP is a contract between the endpoints, and
whenever a middlebox starts modifying those packets, IMO it becomes a
party to that contract that needs to be taken very seriously (smiley
faces aside ;-)

>> A DOCSIS router ought to route. If it left the packets alone, IMO we'd
>> all be better off.
> 
> So you would rather have people getting slower downloads than have
> network equipment modify packets?

I would rather people get slower downloads than break TCP in ways we
won't see for 5 years or inhibit the extension of TCP in new ways that
might be even more beneficial.

> Those are the real-world choices.

There were other cable modem companies that tried similar "tricks" in
the past and got in a lot of hot water for making a box that went a LOT
faster for *their* customers.

TCP works when everyone plays by the same conservative rules. There has
always been a choice to break those rules for individual gain, and there
has always been a reason we try very hard to avoid that.

Joe