Re: [aqm] ACK Suppression
Greg White <g.white@CableLabs.com> Wed, 07 October 2015 22:49 UTC
Return-Path: <g.white@CableLabs.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 5AD3C1B2A75 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 15:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 XIE7od71U4Pb for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 15:49:22 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 154E71B2A73 for <aqm@ietf.org>; Wed, 7 Oct 2015 15:49:22 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t97MnGaf022012; Wed, 7 Oct 2015 16:49:17 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 07 Oct 2015 16:49:16 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 7 Oct 2015 16:49:14 -0600
From: Greg White <g.white@CableLabs.com>
To: Jonathan Morton <chromatix99@gmail.com>, "Agarwal, Anil" <Anil.Agarwal@viasat.com>
Thread-Topic: [aqm] ACK Suppression
Thread-Index: AQHRATmwtjbtTfYXhEWK+oXXa0EwO55g3LyAgAAGUQCAAASXgP//uriA
Date: Wed, 07 Oct 2015 22:49:13 +0000
Message-ID: <D23AF606.54AC6%g.white@cablelabs.com>
References: <mailman.1487.1444233956.7953.aqm@ietf.org> <1444247538.3556484@apps.rackspace.com> <alpine.DEB.2.02.1510072200590.8750@uplift.swm.pp.se> <7A2801D5E40DD64A85E38DF22117852C8812629D@wdc1exchmbxp05.hq.corp.viasat.com> <06C46DC6-854F-4CDE-8C7B-745F3362FA9E@gmail.com>
In-Reply-To: <06C46DC6-854F-4CDE-8C7B-745F3362FA9E@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4E4A5B98A53A7A4CA39C7E957D2EB5F9@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/MFz2pz5_gpsZFGSwl647rzKq54o>
Cc: "dpreed@reed.com" <dpreed@reed.com>, "aqm@ietf.org" <aqm@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
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 22:49:23 -0000
Jonathan, You are making some assumptions about modem behavior that may or may not be true. RFC3449 does mention that DupACKs should be treated with care, but I honestly don't know what implementations do in this regard. (and btw, two MAC grant delays in DOCSIS would be more like 2-10ms) Others, Just so everyone is clear, DOCSIS modems have been doing these sorts of optimizations for close to 15 years. So, if your analysis concludes that the Internet will catch fire as a result, you may want to double check your math. I am interested in knowing about real issues, and whether we need to make more specific guidelines (or requirements) on what vendors do in this space, but I think they need to be pragmatic guidelines (and not assume that transports are going to become hyper L2-aware, or that modems are going to become hyper transport-aware). I like Mikael's suggestion that the TCP default behavior should be to try to send ACKs one per millisecond or 1/10th RTT (whichever is lower). Perhaps QUIC can raise the bar here.... -Greg On 10/7/15, 2:57 PM, "aqm on behalf of Jonathan Morton" <aqm-bounces@ietf.org on behalf of chromatix99@gmail.com> wrote: > >> On 7 Oct, 2015, at 23:40, Agarwal, Anil <Anil.Agarwal@viasat.com> wrote: >> >>> Since the cable modem link will lead to clumped ACKs the difference >>>between sending 100 ACKs vs. 1 ACK is probably not that big... >>> (except w.r.t. reliability). >> >> The difference may not be big in the spacing of new packets that a >>sender will send, unless the sender implements some sort of pacing or if >>the return link is very thin. > >> But with ABC, there will be a difference in the amount of cwnd increase >>at the sender. > >There is also a potential difference for detecting packet loss in the >forward direction. It¹s entirely possible that thinning would cause a >DupAck condition to be recognised only after three MAC grants in the >reverse direction have elapsed, rather than one. Receivers are REQUIRED >to send an ack for every received packet under these conditions, but that >would be subverted by the modem. AckCC would not induce this effect, >because the receiver would still produce the extra acks as required. > >Packet loss causes head-of-line blocking at the application level, which >is perceived as latency and jerkiness by the end-user, until the lost >packet is retransmitted and actually arrives. Hence the addition of two >MAC grant delays (60ms?) may make the difference between an imperceptible >problem and a noticeable one. > > - Jonathan Morton > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Mikael Abrahamsson
- Re: [aqm] ACK Suppression Agarwal, Anil
- Re: [aqm] ACK Suppression Jonathan Morton
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Christian Huitema
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression Jana Iyengar
- Re: [aqm] ACK Suppression Scharf, Michael (Michael)
- Re: [aqm] ACK Suppression Bless, Roland (TM)
- Re: [aqm] ACK Suppression Fred Baker (fred)
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Fred Baker (fred)
- Re: [aqm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Joe Touch
- Re: [aqm] [tcpm] ACK Suppression gorry
- Re: [aqm] [tcpm] ACK Suppression David Lang
- Re: [aqm] [tcpm] ACK Suppression Mikael Abrahamsson
- Re: [aqm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression Jonathan Morton
- Re: [aqm] ACK Suppression Jana Iyengar
- Re: [aqm] [tcpm] ACK Suppression Simon Barber
- Re: [aqm] ACK Suppression Simon Barber
- Re: [aqm] [tcpm] ACK Suppression David Lang
- Re: [aqm] ACK Suppression Bless, Roland (TM)
- Re: [aqm] [tcpm] ACK Suppression Greg White
- Re: [aqm] ACK Suppression dpreed
- Re: [aqm] ACK Suppression Jonathan Morton