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

[Kathleen Nichols <nichols@pollere.com>]

On 6/21/18 12:17 PM, Dave Taht wrote:
> 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.

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
> 
> 
>