Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 22:16 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 9EDD11B4DBD; Fri, 9 Oct 2015 15:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, 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 VuKVu5pA5dOL; Fri, 9 Oct 2015 15:16:49 -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 605B21B4DC7; Fri, 9 Oct 2015 15:16:49 -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 t99MGfxT024910; Fri, 9 Oct 2015 15:16:41 -0700
Date: Fri, 09 Oct 2015 15:16:41 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <56183B49.4000506@isi.edu>
Message-ID: <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@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/70R6H__01YMVU6R9F_7pHZEak5U>
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:16:50 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> On 10/9/2015 3:02 PM, Greg White wrote:
>>
>>
>> On 10/9/15, 2:04 PM, "Mark Allman" <mallman@icir.org> wrote:
>>
>>>
>>>> 1) *you* shouldn't be using a mechanism that destroys information for
>>>> others
>>>> 2) *you* don't know where your mechanism will have an impact
>>>> 3) you claim this might be safe *if* AQM is widely deployed
>>>
>>> tl;dr summary: myopia is why we can't have nice things
>>
>> Too true.  DOCSIS would have been much cleaner if we didn't have to deal
>> with the fallout from the myopic TCP designers.  :-P
>
> 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)

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

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

Those are the real-world choices.

David Lang