Re: [aqm] ACK Suppression

dpreed@reed.com Wed, 07 October 2015 19:52 UTC

Return-Path: <dpreed@reed.com>
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 B446D1B2FC4 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 12:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 Ay1FGlk5iWF0 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 12:52:19 -0700 (PDT)
Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867131B2FC7 for <aqm@ietf.org>; Wed, 7 Oct 2015 12:52:19 -0700 (PDT)
Received: from smtp25.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 72648180271 for <aqm@ietf.org>; Wed, 7 Oct 2015 15:52:18 -0400 (EDT)
Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 66D71180113 for <aqm@ietf.org>; Wed, 7 Oct 2015 15:52:18 -0400 (EDT)
X-Sender-Id: dpreed@reed.com
Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Wed, 07 Oct 2015 19:52:18 GMT
Received: from reed.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id 5713580041 for <aqm@ietf.org>; Wed, 7 Oct 2015 15:52:18 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 7 Oct 2015 15:52:18 -0400 (EDT)
Date: Wed, 07 Oct 2015 15:52:18 -0400
From: dpreed@reed.com
To: aqm@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20151007155218000000_47829"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <mailman.1487.1444233956.7953.aqm@ietf.org>
References: <mailman.1487.1444233956.7953.aqm@ietf.org>
X-Auth-ID: dpreed@reed.com
Message-ID: <1444247538.3556484@apps.rackspace.com>
X-Mailer: webmail/11.5.7-RC
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/Q5UpTJAx__NOtn5hRgxoNxArRsI>
Subject: Re: [aqm] 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: Wed, 07 Oct 2015 19:52:22 -0000

I presume this is not a serious focus of the AQM group. So maybe I'm wasting my time by writing about this.
 
Nonetheless I am troubled by the very fact of the discussion taking place, for two reasons:
 
1) TCP ACKs are TCP's business only.  It's not a gateway or router's job to get involved in or to understand end-to-end protocols, *even if* the router thinks it knows exactly what the endpoints' goals are.  And the router cannot know that for every protocol, not even the many higher level protocols on top of TCP, which use TCP quite differently.  The idea that routers can be omniscient, merely by looking at packets and taking the designers' personal prejudices into account, seems ridiculous. TCP endpoints on both ends of a connection can reduce the number of ACKs they send if they want. If ACKs are filling up buffers in intermediate routers, just drop them or mark them to notify that they are contributing to congestion.  The endpoints have to slow down something, and they can slow down ACKs by mutual agreement.
 
2) The hypothetical that there will be a sufficiently long sequence of ACKs for a single end-to-end flow buffered in a single router queue may seem plausible, *until it becomes clear that in the big picture, having so many packets in a queue means that the network is extremely congested by that point*.  In other words, in order for this "optimization" to apply, you would have to operate the network at an unacceptable operating point! It's like saying that when a highway has slowed to a crawl, we can load all the cars going to a particular destination onto  single "car carrier" to save gas. Far better to insure that queues are not built up!  The purpose of queueing is to absorb bursts that can't be anticipated, not to build up congestion in order to have enough data to perform a dubious optimization that can best be done at the source of traffic in cooperation with the destination.
 
It's said that in committees the amount of time spent on trivialities far exceeds the time spent on important issues.  That seems to be true as I watch the discussion on this list.
 
There are real congestion problems in the real Internet.  Real engineers would be working on solving them with practical solutions that actually work.  I see none of that here.  It's very, very sad.  We still have serious "bufferbloat" in most access networks nationwide, and lots of gear sold by the biggest brand name vendors of both high-speed fiber/copper access and packet wireless data access that is allowing queueing of between 1/2 second to 4 seconds to build up and sustain itself.
 
But this group dithers.