From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 0F6B23B2A4 for ; Thu, 21 Jun 2018 15:54:23 -0400 (EDT) Received: by mail-qt0-x241.google.com with SMTP id y20-v6so3986532qto.8 for ; Thu, 21 Jun 2018 12:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LhdDEc1U33KUGsAsK3OJHRxctX4Id1b5RbpsCQfcqqQ=; b=GBmRinkClo+VXIsV/LMX7fvFdhpKwtYqiY4mT0S93XFp+LoGtxZKaJLruwJp0DCfIK kkAuKNok2NTPMQmSAoL+EMG2kRgjEPujqO98kkJG0X0iroSYQ1z9yjK20ESrS6QdYnOd DWmHw6yFa5iF232SuUopb/WaMAAzpmKrpVm/uqLg56Htkuzz7knbYGHhvmmAynTEBZ6c fCbAB3yM0OO0XFyFE7BCZ2b5r/rGpB0w8RI2FrBQmW9xOWDBLnMzKkFg1REB+QxltHVV usHrmKaVqS/ycqybYsCWqtv/wcKAtWGVHZ/chLtWd/GeGmZq6fxuvrG0lEMR2eDFlfhZ QrPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LhdDEc1U33KUGsAsK3OJHRxctX4Id1b5RbpsCQfcqqQ=; b=MAiO4WH6FezZ8H4RdvdjK3iwXuESsFmMmIEDBwMaP2mQzjCLTZP3MojhmtAeVohTL3 5HOXoaMNsa+gp+jX6yyJ9EbYwC5bM6YOgqgcu/t6bM/rLTynRurqj9hHxUtInQ/EPaj7 FdAKEbrHJXaMDXMlhPTjVuYmYym5f+E2SjjbPuUhTMHz2im+SASjKz2jjypocj4iYNOm Uco/xUzu3sDOKnnt+kFPANhF0ZrCuaa+HHl3MaVpX81D8BX4ASpGodEpFgdw1jo6a3Ew u46h3DkBM3An4iulBV+7tsMTROmLQnzcNlbEHeqbR0DdRm240dXMlivgumJt4Z52T8ZP sA3Q== X-Gm-Message-State: APt69E0IhHoN1jMrkN0sB5ErJqKvqxXULlMJNCkvi0axkHTOw1LfWICd jqLIh0srqkZcfpu6Xvg6CeRW3oAk5BoUq9weEzc= X-Google-Smtp-Source: ADUXVKLY92j/gDZ4CHFrY5f6OD0buHbjDDv8fJvOYK6v8yIjSby7mIm0eOkRZrWJWWbrlEVGOuvVIEgR/V50f5DxxBA= X-Received: by 2002:aed:2311:: with SMTP id h17-v6mr24436534qtc.144.1529610862495; Thu, 21 Jun 2018 12:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 12:54:21 -0700 (PDT) In-Reply-To: <6DCE29AF-5F91-4F06-93A8-0F5D197C9D06@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> From: Dave Taht Date: Thu, 21 Jun 2018 12:54:21 -0700 Message-ID: To: Sebastian Moeller Cc: Kathleen Nichols , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 19:54:23 -0000 On Thu, Jun 21, 2018 at 12:41 PM, Sebastian Moeller wrote= : > Hi All, > >> On Jun 21, 2018, at 21:17, 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 =3D 1 ack rule is going away. Still, an estimate, >> with a short timeout >> might help. > > That short timeout seems essential, just because a link is wirele= ss, 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 n= etwork). In a way such a solution should first figure out whether waiting h= as any chance of being useful, by looking at te typical delay between Data = packets and the matching ACKs. 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. 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. > >> >> 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... > > To make up for the fact that wireless uses unfortunately uses a v= ery 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...) 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 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. Has 802.11ad gone anywhere? >Now really from a latency perspective it clearly is better to ovoid overhe= ad instead of use "batching" to better amortize it since batching increases= latency (I stipulate that there are condition in which clever batching wil= l not increase the noticeable latency if it can hide inside another latency= increasing process). > >> >> 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... > > I note that for voip, waiting does not make sense as all packets = carry information and keeping jitter low will noticeably increase a calls p= erceived quality (if just by allowing the application yo use a small de-jit= ter buffer and hence less latency). There is a reason why wifi's voice acce= ss 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 q= uestion, answering which I do not feel competent). > I also think that on a docsis system it is probably a decent heur= istic to assume that the endpoints will be a few milliseconds away at most = (and only due to the coarse docsis grant-request clock). > > Best Regards > Sebastian > > >> >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> >> >> -- >> >> 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 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619