Re: [tcpm] Better QoS for TCP ACK question

[Gorry Fairhurst <[e-mail]>]

On 16/04/2018 17:45, Toerless Eckert wrote:
> On Mon, Apr 16, 2018 at 04:42:12PM +0100, Gorry Fairhurst wrote:
>> Just to send something more to this list thread:
>>
>> RFC 3449 from 2002 describes this in section 5.4.2 on ACKs-first Scheduling.
> 
> Ah, great. Thanks. Something to point people to.
> 
>> I aware this method was implemented in a variety of equipment around that
>> time, although I suspect it can also cause some odd performance hits when
>> using app-limited TCP sessions (where many data segments are also small and
>> may also become reordered).
>> Gorry
> 
> I guess this would refer not to an actual TCP-ACK DPI based
> scheduling that you could easily do on CPU processing home
> gateways, but rather the packet-length based queuing Mikael
> brought up ? Otherwise i don't understand.
> 
> Toerless
> 
In those ancient days, I suspect most systems did do the "ACK-First" 
scheduling based only on estimating the size of the "ACK".

So I'm not saying TCP DPI-based could do special stuff when it sees data 
in the packet and try to smartly avoid reordering any segments, and that 
timestamps, SACK, and various other things could be taken into account. 
Whether this would be a great idea is another story.

Gorry