From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A47E23B29E for ; Mon, 25 Jun 2018 20:07:33 -0400 (EDT) Received: by mail-lf0-x230.google.com with SMTP id m13-v6so5332939lfb.12 for ; Mon, 25 Jun 2018 17:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WVPlSZ2PiEHyk4sC5D2B6I8B1NsVmrmKBvEEKNJhFg8=; b=GjovTIeVhffDQ0XQDPVxf488ufwWLxpTRTK8PRoMe6WeeEk/MJnrIrQii9B/mXOQ70 yu81kZQZtbF0j6oAnc0Qvw2IJoQntdjsOY3aFhD988wXI8UD21hxSRapfURXCPOTdT0b Jq5a5KmBjIx1bQ4cPdauMQjD0bWkII3C9SXuLDdqMi2LFCnPW6c/L6ZNBjmNLpQrZZFm C5vWoqLJ5zPjhw02yA4o3Qbk+S7NnVyN4i607aqYLQzy50pLZT68Yhp0aMBNsPQFGLlx Vpk5fhRjqg6vYXVNkiLHCpNS0+peAFY3fzsPjqi2Oufm1Rn3wsJd6BMWSwqy1ooBO58s ze5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WVPlSZ2PiEHyk4sC5D2B6I8B1NsVmrmKBvEEKNJhFg8=; b=r1bG8rjhqEtcwkNGNYE2dNGniQx37zRH1RVKsHH+senC51OO3zG/KUqO1z6+XH90cB 2wLI8AuggIntcnnNacTZyCxNvFupimxC6dBOn2DPDxMZf8MzzCv8P4F2N59Ql85ZTkPM 7iMB89o90HEfH1SHituWJOXJBXlM1ObV4DZlSQnmXOJu63YSTHOmOAt2iyGS20FQrirs dAWMDDmhn62Tu+1+61BQAgTKMDP4O+JGuP0f6EBK+qG1xQSIk2xMs6a1n5zjFxBn83iu iAupWgwyMJcGJaBEoxTnJox4qEMOcVwYhQXzpZXbW1mGmLq8I10O8I8vs6y6KLewTF7H qT1w== X-Gm-Message-State: APt69E0XaDpB5v9ERDQ7mm4YERH1yMPmuaefobkYVJGk+P4dmOyqVWcW /TNdUDMGl84xsUOI3lVUsIM= X-Google-Smtp-Source: ADUXVKLdsuC9tr4W12R7vsbmFtiqj3UVVPXEojSPY9JBP2a/EguO4HMurLxT6XMZyBkiPfMS87tmVA== X-Received: by 2002:a19:51db:: with SMTP id g88-v6mr7725713lfl.78.1529971652588; Mon, 25 Jun 2018 17:07:32 -0700 (PDT) Received: from [192.168.239.105] (83-245-237-65-nat-p.elisa-mobile.fi. [83.245.237.65]) by smtp.gmail.com with ESMTPSA id g1-v6sm25800ljj.81.2018.06.25.17.07.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 17:07:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Jonathan Morton In-Reply-To: Date: Tue, 26 Jun 2018 03:07:30 +0300 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> <87muvjnobj.fsf@toke.dk> To: Jim Gettys X-Mailer: Apple Mail (2.3445.8.2) Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 00:07:33 -0000 >> No, it's in the driver for ath9k. So it would be possible to delay it >> slightly to try to build a larger one. The timing constraints are too >> tight to do it reactively when the request is granted, though; so >> delaying would result in idleness if there are no other flows to = queue >> before then... There has to be some sort of viable compromise here. How about = initiating the request immediately, then building the aggregate when the = request completes transmission? That should give at least the few = microseconds required for the immediately following acks to reach the = queue, and be included in the same aggregate. > =E2=80=8B=E2=80=8B=E2=80=8BIsn't this sort of delay a natural = consequence of a busy channel? >=20 > What matters is not conserving txops *all the time*, but only when the = channel is busy and there aren't more txops available.... >=20 > So when you are trying to transmit on a busy channel, that contention = time will naturally increase, since you won't be able to get a transmit = opportunity immediately. So you should queue up more packets into an = aggregate in that case. >=20 > We only care about conserving txops when they are scarce, not when = they are abundant. >=20 > This principle is why a window system as crazy as X11 is competitive: = it naturally becomes more efficient in the face of load (more and more = requests batch up and are handled at maximum efficiency, so the system = is at maximum efficiency at full load. >=20 > Or am I missing something here? The problem is that currently every data aggregate received (one TXOP = each from the AP) results in two TXOPs just to acknowledge them, the = first one containing only a single ack. This is clearly wasteful, given = the airtime overhead per TXOP relative to the raw data rate of modern = wifi. Relying solely on backpressure would require that the channel was = sufficiently busy to prevent the second TXOP from occurring until the = following data aggregate is received, and that just seems too delicate = to me. - Jonathan Morton