Re: [aqm] [tcpm] TCP ACK Suppression

Dave Taht <dave.taht@gmail.com> Sat, 10 October 2015 23:06 UTC

Return-Path: <dave.taht@gmail.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 AD9451ACEF9; Sat, 10 Oct 2015 16:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 awMy6Jebpb4d; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3C81A1B7F; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: by oiar126 with SMTP id r126so21160626oia.0; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lSHgxMg8OkPHJwtYn6wJ2lVgFljJa6rpzInZDBVsBPk=; b=PJNsw97Jmqf0Sh7SbBcG138G+CTG7CqWfInl+hHRMcIYFPe6Et7vWr8dAw5Fmjs6jC 2hanL+dZbM426iLWAAacrVaaWW8J+l/DYNuPatDOYvTOPmY3anEjowdFBs/YDQZJOgln RgSBKo3FpJex0UjQfiDxF0hu/de02xElvo+OW902Bf9QHdoELmMOdvc6n16G9f5gHrSe 2VgUdSTND1ywiRYHxFGuWyky3v/v3KEE7PiBuc5VQrZFhb/SZEQjJn16S/ne4+YZ8FQi e77T4LdfLv5/V4jCku1tNsODx2ScouygKbvFY3JqBgLfDvNrZ4bjUggo5a/Iv0dTzR24 zlig==
MIME-Version: 1.0
X-Received: by 10.202.11.72 with SMTP id 69mr11563498oil.110.1444518394055; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: by 10.202.108.212 with HTTP; Sat, 10 Oct 2015 16:06:33 -0700 (PDT)
In-Reply-To: <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> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz>
Date: Sat, 10 Oct 2015 16:06:33 -0700
Message-ID: <CAA93jw64aE+to_=Q0suMBLuPDaZV+wU9mD4RWO55=NdD0jk_fw@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: David Lang <david@lang.hm>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/NciwY9B6ncjZHNDyZ5EO14hyhno>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <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: Sat, 10 Oct 2015 23:06:36 -0000

I have been busy with other matters and unable to keep up on this thread.

I just wanted to say that I'm with dlang here... aggregated and
asymmetric transmits in wifi, cell, and cable, are here to stay. Deal
with it.

I would certainly have preferred a wifi world that instead of all
stations and APs highly contending for bursty access to a single
320mhz channel, we had 160 dedicated, low latency, 5mhz channels, but
that is not what the IEEE has handed us.


On Fri, Oct 9, 2015 at 10:58 PM, David Lang <david@lang.hm> wrote:
> 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
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm



-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht