Subject: [tcpm] Better QoS for TCP ACK question

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Apr 2018 03:27:36 +0200

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

Cheers
    Toerless

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 7 Apr 2018 07:10:17 +0200 (CEST)

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

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Apr 2018 16:42:12 +0100

On 07/04/2018 06:10, Mikael Abrahamsson wrote:
> 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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 16 Apr 2018 18:45:13 +0200

On Mon, Apr 16, 2018 at 04:42:12PM +0100, Gorry Fairhurst wrote:
> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Apr 2018 17:53:27 +0100

> brought up ? Otherwise i don't understand.
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