From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8F0063B2A4 for ; Thu, 21 Jun 2018 16:11:47 -0400 (EDT) Received: from hms-beagle2.lan ([79.192.246.80]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSp1l-1feAZI0spp-00RrYm; Thu, 21 Jun 2018 22:11:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 21 Jun 2018 22:11:43 +0200 Cc: Kathleen Nichols , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <15B9974E-13DE-4D07-B8C3-4AB007172F43@gmx.de> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <6DCE29AF-5F91-4F06-93A8-0F5D197C9D06@gmx.de> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.8.2) X-Provags-ID: V03:K1:UfH8YDvpdsb4b1GD/euKh+yG/RqShNktKetJ4X6Mp4kVmVhl3bK uzAJ2iDKUeNIosJMK+7l7gV17Z/ycq4yPoLxZGp0PNnX/Tqhw/Mp7OUA2eyAf3ylumFq1kt 0btQgY72pm/qznA6XHzYEwsPDKco6uxBHJwr67rWkfQsz3ulVJOR2RIqsSmsF+FcjrcAHID mllS0/63td/wr3laqfm9A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Na1v+QuRvYk=:xJJ5lA5WgPGWjyavur4fzq Fu2DLLioEa8dhicFL681iVTo6Cd+f9YNzX8/oGEymU/lZbYwcImDu5nw7t3xRzHd700Is3LLK 7yu6OcRvRmGAMKxN4tQQPhADJ6VbGkhrbArBtysqo5S1T+twD5UdRWxlec5Yk7De+HEtG5D+U 67Ffp9vb5zewmSlfCW8+EJt4FwZ+bqRxaTq+K7qkBR6JPe9hhmxeX/qZX1AOjEE3y8jsQElnx qIBtvUBi1fKRWpcBhMviDqTV+tY+v2tNR3EBfRPiKPsYC7qR9Vl8neblcGePqiaZoefUMtWME 1g3oJPw2UZB9fkAwWfrESDdozwXZg0uC+oJP44N4yUxSrrTr4zhhvoQIeVcES8J7eJZ/Ir0zD mme0V0iteT+IciHZx+VKFz73afPhxbFurEfEZi8QpfQRo31ll3XBuOGazndETrZBXLZtMQltH qer8HuIDoXe6MpQX1mXdh94AWMb1ogbkp6PcDtRWdUfMe4O08rIiIbC6GBo5GKX67WBCShXS9 OakHCfvBSP8rkv4BF1SCfJK/6Zir/FzH1Ld/SIukPglW5gjZOTZgRHpcgZgNHzokpZYgbQLmu Xxp+zsdI7JWKMx+1jClxXlGi5E2vlAKTnVmP3RNlY2hoJFNxStvO5Zf1WtSSkiQg22jrgvgDn BLMDH1958u7Cd9q3vrtKUGEiDlc7OgkyA4jkoT8xyCZym4oR1ZyPx6RpznF6EuQNFZfFHw/br XiRnKecoGu54Zw5RnyZP8nQ8/tHQhZOByO8BLEwAP7q0ZhOb4tmB2GxdZKEJqq3mOLJnAEOMX mo5V4hr 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: Thu, 21 Jun 2018 20:11:47 -0000 Hi Dave, > On Jun 21, 2018, at 21:54, Dave Taht wrote: >=20 > On Thu, Jun 21, 2018 at 12:41 PM, Sebastian Moeller = wrote: >> Hi All, >>=20 >>> On Jun 21, 2018, at 21:17, Dave Taht wrote: >>>=20 >>> On Thu, Jun 21, 2018 at 9:43 AM, Kathleen Nichols = wrote: >>>> On 6/21/18 8:18 AM, Dave Taht wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> Well, if the driver sees the arriving packets, it could infer that = an >>>> ack will be produced shortly and will need a sending opportunity. >>>=20 >>> Certainly in the case of wifi and lte and other simplex technologies >>> this seems feasible... >>>=20 >>> 'cept that we're all busy finding ways to do ack compression this >>> month and thus the >>> two big tcp packets =3D 1 ack rule is going away. Still, an = estimate, >>> with a short timeout >>> might help. >>=20 >> That short timeout seems essential, just because a link is = wireless, does not mean the ACKs for passing TCP packets will appear = shortly, who knows what routing happens after the wireless link (think = city-wide mesh network). In a way such a solution should first figure = out whether waiting has any chance of being useful, by looking at te = typical delay between Data packets and the matching ACKs. >=20 > We are in this discussion, having a few issues with multiple contexts. > Mine (and eric's) is in improving wifi clients (laptops, handhelds) > behavior, where the tcp stack is local. Ah, sorry, I got this wrong and was looking at this from the APs = perspective; sorry for the noise... and thanks for the patience >=20 > packet pairing estimates on routers... well, if you get an aggregate > "in", you should be able to get an aggregate "out" when it traverses > the same driver. routerwise, ack compression "done right" will help a > bit... it's the "done right" part that's the sticking point. How will ACK compression help? If done aggressively it will = sparse out the ACK stream potentially making aggregating ACK infeasible, = no? On the other hand if sparse enough maybe not aggregating is not too = painful? I guess I am just slow today... Best Regards Sebastian >=20 >>=20 >>>=20 >>> 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... >>=20 >> To make up for the fact that wireless uses unfortunately uses = a very high per packet overhead it just tries to "hide" by amortizing it = over more than one data packet. How about trying to find a better, less = wasteful MAC instead ;) (and now we have two problems...) >=20 > On my bad days I'd really like to have a do-over on wifi. The only > hope I've had has been for LiFi or a ressurection of >=20 > I haven't poked into what's going on in 5G lately (the mac is > "better", but towers being distant does not help), nor have I been > tracking 802.11ax for a few years. Lower latency was all over the > 802.11ax standard when I last paid attention. >=20 > Has 802.11ad gone anywhere? >=20 >=20 >> Now really from a latency perspective it clearly is better to ovoid = overhead instead of use "batching" to better amortize it since batching = increases latency (I stipulate that there are condition in which clever = batching will not increase the noticeable latency if it can hide inside = another latency increasing process). >>=20 >>>=20 >>> web browser: >>> setsockopt(batch_everything) >>> parse the web page, generate all your dns, tcp requests, etc, etc >>> setsockopt(release_batch) >>>=20 >>>> Kathie >>>>=20 >>>> (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.) >>>=20 >>> voip doesn't behave this way, but for recognisable protocols like = tcp >>> and perhaps quic... >>=20 >> I note that for voip, waiting does not make sense as all = packets carry information and keeping jitter low will noticeably = increase a calls perceived quality (if just by allowing the application = yo use a small de-jitter buffer and hence less latency). There is a = reason why wifi's voice access class, oith has the highest probability = to get the next tx-slot and also is not allowed to send aggregates = (whether that is fully sane is another question, answering which I do = not feel competent). >> I also think that on a docsis system it is probably a decent = heuristic to assume that the endpoints will be a few milliseconds away = at most (and only due to the coarse docsis grant-request clock). >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=20 >>>> _______________________________________________ >>>> Bloat mailing list >>>> Bloat@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/bloat >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Dave T=C3=A4ht >>> CEO, TekLibre, LLC >>> http://www.teklibre.com >>> Tel: 1-669-226-2619 >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619