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
- [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression LAUTENSCHLAEGER, Wolfram (Wolfram)
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Clark Gaylord
- Re: [aqm] TCP ACK Suppression Steve Bauer
- Re: [aqm] TCP ACK Suppression Francini, Andrea (Andrea)
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression Rick Jones
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Dave Taht
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Simon Barber
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang