Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Sat, 10 October 2015 05:58 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 7AD981B2BF2; Fri, 9 Oct 2015 22:58:49 -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 re7Pv3MP31Vy; Fri, 9 Oct 2015 22:58:47 -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 9A0511B2BED; Fri, 9 Oct 2015 22:58:47 -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 t9A5wYgm027260; Fri, 9 Oct 2015 22:58:34 -0700
Date: Fri, 9 Oct 2015 22:58:34 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <561891C3.90004@isi.edu>
Message-ID: <alpine.DEB.2.02.1510092134190.15683@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> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@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/cvGWHISrU2A72W3lDmoEknBxhOg>
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: Sat, 10 Oct 2015 05:58:49 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> On 10/9/2015 7:14 PM, David Lang wrote:
>> The problem with proposals like that is just like RFC3449 says, the
>> source can't know what the network looks like to decide if there is a
>> benefit to reducing ACKs.
>
> To understand your position, is your conclusion that if it benefits a
> single place in the network, then that's enough of a view to know that
> it's safe and beneficial throughout the network?

No.

But when something shows clear beneifts when deployed, clear problems need to be 
identified to counter those benefits, or alturnative methods of solveing the 
problem need to be shown.

I didn't know about it initially (I was working from experience and logic), 
RFC3449 has explored many of the problems that cause and result from fewer than 
1 ACK per 2 data packets, including worrying about the timing of the ACK 
packets.

As much as you seem to want to make this discussion about cable modems and 
highly assymetric links, this discussiona ctually started  from the position of 
packets in a particular flow being sent in bursts due to non-endpoint related 
reasons. It started with AQM queues, but radio networks (Wifi and Cell) have 
similar behavior (packets queue until a transmit window is available, tehn a 
bunch are sent at once)

Cable modems were introduced to the discussion to counter the thought that 
sending fewer ACKs would destroy the Intenet.

RFC3449 doesn't completely address the current situation, but it provides a very 
good place to start, and it seems to me that the solitions it explores to 
address the conerns that it (and you) raise are actually being addressed pretty 
completely. There are still some areas to talk about (ECN interaction for 
example) and we wshould be talking about those issues rather than arguing that 
the proposal violates holy writ.

you want a network where packets are just forwarded with no modification and no 
delays. Unfortunantly such a network does not match the real world any longer 
(and it only approximated the real world in the first place) Shared media 
networks have existed since the earliest networking days. What is changing is 
theratio between the data speed when transmittingand the time available to 
transmit. Given the same number of stations in an area, I'll bet that old 
thinnet ethernet at 10Mb/s spent a significantly higher percentage of the time 
transmitting data than current Gb/s and immediate future 10Gb/s wireless 
networks. Just like wired network speeds are climbing with the MTU staying the 
ame, wireless network data rates are climbing but the time available for a given 
station is remaining the same (or shrinking), so the number of packets that get 
delayed until the next transmit slot are only going to keep climbing, no matter 
what anyone wants.

The asymmetrical nature of the networks is just addng insult to injury, not the 
cause of the issues.

Wireless networks are gaining the ability to transmit to multiple stations at 
once. But the nature of usage patterns and the physical geometry of the wired vs 
mobile ends of the link make the reality that only the wired end can effectively 
make use of this capability. this makes the availble downstream bandwidth on a 
network fabric grow much faster than the available upstream bandwidth. To some 
extent this will put less stress on the upstream side of the wired network it's 
attached to, but it will mean that the demand for mobile station transmit slots 
is only going to multiply. Just reducing the number of timeslots the base 
station uses isn't the answer because that will add latency to all the data 
downloads.

IIRC, I saw a story today where one of the contenders for 5G cell networks is 
already at a ratio of 24:1 or worse.

David Lang