Re: [tcpm] Better QoS for TCP ACK question

[Gorry Fairhurst <[e-mail]>]

On 07/04/2018 06:10, Mikael Abrahamsson wrote:
> On Fri, 6 Apr 2018, Toerless Eckert wrote:
> 
>> A couple of years ago i was told that a range of home routers
>> would do some DPI based diffserv QoS, aka prioritizing TCP ACP
>> messages in the queue before any other packets 9sonded like
>> a strict priority queue for these packets). The goal was to
>> improve performance when you had separate up and downstream TCP
>> connections, especially when the upstream TCP connection delayed
>> the downstream TCP connections ACKs.
>>
>> I never could find a lot of good details about this, e.g.: quantitiative
>> measurements, so i was wondering if others here on the list
>> are aware of it. Of course, if something like this would
>> be significantly useful even in the face of current TCP congestion
>> control mechanisms (and not only bad older ones).
> 
> I know some people who have run two queues, one for packets less than 
> 200 byte in size, and one for larger packets. They didn't even do any 
> DPI, the setup was purely based on size of the packet. I am not aware of 
> any deeper analysis on pros/cons of this setup, but these people were 
> very happy with their setups for years and it solved their problems with 
> a single large file transfer ruining their interactive performance, plus 
> also "solved" the ACKs-get-stuck-behind-other-session-large-packets 
> problem.
> 
> This was used for platforms with otherwise quite limited QoS 
> capabilities, so flow based queueing wasn't available.
> 
Just to send something more to this list thread:

RFC 3449 from 2002 describes this in section 5.4.2 on ACKs-first 
Scheduling.

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