From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7E64A3B29E for ; Fri, 22 Jun 2018 10:01:38 -0400 (EDT) X-MHO-RoutePath: a21uaWNob2xz X-MHO-User: c7352c2c-7624-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.160.239.168 X-Mail-Handler: DuoCircle Outbound SMTP Received: from kmnimac.local (unknown [67.160.239.168]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c7352c2c-7624-11e8-8837-614b7c574d04; Fri, 22 Jun 2018 14:01:37 +0000 (UTC) To: bloat References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> From: Kathleen Nichols Openpgp: preference=signencrypt Autocrypt: addr=nichols@pollere.com; prefer-encrypt=mutual; keydata= xsDiBEC83ecRBAC+SoOIjjcKTrEvMEA6p7BamLNoS5P/Pb51j184ZU2/s3aCLl3Q/BCkFxT+ cFCnthIsgxMXrSGELwRkevkTX8GUlBaKIvrp7Ye9NjbYBC1NZWFyAKzZUI1eF2AibUbXAFtV qAIPyCXuMdaOSrXTPAdbHIQxZk9zEa6Xh0zj1uwczwCg7iDV4fIclpmP8arjkQWm8grrwi8D /2Bb81fEGvF83KVNoPiy1hNfrIHmYevQiLaOVJkJPQzi+DxJSRCRkAV7z7nAhXXWVCWkshHL r5d07ElPZPgxft74pk3U6ygqFAGz97V8A2+7ZLa2RHwgb5ZIUeaSMgpXqUfxjDQuq34AQBWX 8xwwBR4JhuhxrN+8uZEMG0Neqm5SA/9wkL6moHBKl+PvV3O7ap+kVXC97NfVFG72b8EVvw5W HRUtUGdxFhNuAhS4QNWaCdYOm6VC9xlZGhykcXAzyC0tjB8Kbk44KzJrtIzpCWoI58PZSCPD n8PhFKKItcQ/hY8QNAeHEcEvInCjNz/w+7ik0gF8xQy2yA9eulVzg7l2380mS2F0aGxlZW4g TmljaG9scyA8bmljaG9sc0Bwb2xsZXJlLm5ldD7CYgQTEQIAIgUCVL1s9AIbAwYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ+dkULylClLYRYwCgzd2IlR14SGzqKWdxY5W4kJ1yAyQA oI6A9QUyuoz/5DDBN1o5g/nFXpS5zsFNBEC83ocQCACXUuOfleOzud5aRpG20cdZcmGwn46Y K7vXPKHrtKema3u3AhDhm/dpU2hnD/1bflCnHk2TX/MNnJ/9jVLVAMcj1GmXS4Zj/DMypQ2/ 5r213nBbWEjcS4wOhFEAcfApEU0d4LG/v/SPDJqqrvP5txXxox9z7JG0OEXeGzZU8Ro5LAkJ HJSBdSN1je61XYolMbPvZ8Wo9APIJnJEIc1DG2+3oHgJA1a2QN+xnia4hs90CnR/VDcBSH/l yFk0lWnBxeJLwqYTWgGRLAM4JtA3C3LYe/h6gK2o4ug0NRcKRBdJk4pHDJenjKx1LjjpGEBA L5FyZqAA+3Do9PH8Pzm4vDKDAAMGCACBSF4C01c4XJgm/qw0moM7sxcb2nBVIpEubl8OHQf3 zLX2UAoNy8SKjHZsyp984jTLBr/VHqY/+BsL9W1uPf0ssPnYieq58aMtRXEtFCF2i4m6CZoj a+hFImKhIIvvhGE1rYyK13AnvjywTDK0XadJwqNKNPwZasHnK7xx/foKmaMilZL4UwRDEs39 1FQfbhcm83NZ2xGEuK+fYAg8VA5pTIUcrhQEC9sORQ3g5Alw+2o13oC6fO/SyQ9iqnOZ0WBq +cJE10zM7K5aNuNI/853ot9fglOHRnlDnxd9pg+QxGq1L4O4l3rjoLbtiqtGOzJpUAguBsGu JZQJgyS9fkNjwkkEGBECAAkFAkC83ocCGwwACgkQ+dkULylClLYI6wCgtctwza77h+XplNbp hHp3WFniTxwAn1duX7R8SZX7KDSysitOQEXN3v6O Message-ID: <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> Date: Fri, 22 Jun 2018 07:01:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 22 Jun 2018 14:01:38 -0000 On 6/21/18 12:17 PM, Dave Taht wrote: > On Thu, Jun 21, 2018 at 9:43 AM, Kathleen Nichols wrote: >> On 6/21/18 8:18 AM, Dave Taht wrote: >> >>> This is a case where inserting a teeny bit more latency to fill up the >>> queue (ugh!), or a driver having some way to ask the probability of >>> seeing more data in the >>> next 10us, or... something like that, could help. >>> >> >> Well, if the driver sees the arriving packets, it could infer that an >> ack will be produced shortly and will need a sending opportunity. > > Certainly in the case of wifi and lte and other simplex technologies > this seems feasible... > > 'cept that we're all busy finding ways to do ack compression this > month and thus the > two big tcp packets = 1 ack rule is going away. Still, an estimate, > with a short timeout > might help. It would be a poor algorithm that assumed the answer was "1" or "2" or "42". It would be necessary to analyze data to see if something adaptive is possible and it may not be. Your original note was looking for a way for finding out if the probability of seeing more data in the next 10us was sufficiently large to delay "a teeny bit" so that would be the problem statement. > > Another thing I've longed for (sometimes) is whether or not an > application like a web > browser signalling the OS that it has a batch of network packets > coming would help... > > web browser: > setsockopt(batch_everything) > parse the web page, generate all your dns, tcp requests, etc, etc > setsockopt(release_batch) > >> Kathie >> >> (we tried this mechanism out for cable data head ends at Com21 and it >> went into a patent that probably belongs to Arris now. But that was for >> cable. It is a fact universally acknowledged that a packet of data must >> be in want of an acknowledgement.) > > voip doesn't behave this way, but for recognisable protocols like tcp > and perhaps quic... > >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > >