Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

[Dave Taht <dave.taht@gmail.com>]

On Thu, Jun 21, 2018 at 9:43 AM, Kathleen Nichols <nichols@pollere.com> 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.

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



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619