Subject: [aqm] working group rechartering

From: "Lautenschlaeger, Wolfram (Nokia - DE)" <[email-masked]>
Date: Thu, 2 Jun 2016 14:49:21 +0000

Hi,

I don't think that the AQM story is completed right now. There is a number of 
open issues that, I feel, are not well reflected by the currently discussed 
AQM proposals.

Some examples:

- Bi-directional congestion (simultaneous up and download) produces a coarse 
oscillation between the involved queues. Any heuristics on "standing" or 
"steady" queue size should misinterpret that effect. Has it been investigated 
for the actual AQMs?

- the "small RTT" issue (as Bob presented in Prague): At small RTT the AQM 
might want to lower the CWND to less than 2 packets, which TCP does not 
permit. As a result we get an uncontrolled queue growth despite AQM, ending up 
with drastic drop rates >20%, tail drop, retransmission timeouts, etc. This is 
a topic, not only, but also for AQM.

- degradation of per flow queuing in less-than-BDP buffers: AQMs are targeting 
small queues, i.e. less than BDP. FQ is understood as the perfect complement 
to achieve fairness. But at small buffers at a given moment only a fraction of 
the involved flows have packets in their queue. Empty queues are not 
participating in the round robin scheduling. The respective flows are not 
earning credits as supposed for fairness reasons.

Just to mention a few of the open issues.

Wolfram

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 13 Jun 2016 10:12:11 +0100

Wolfram,

> a topic, not only, but also for AQM.
This should (at least at first) be dealt with in the various transport 
protocol WGs that deal with TCP-like congestion controls (tcpm, on 
behalf of mptcp, sctcp, etc), because it is caused by TCP ignoring drops 
(or ECN) from the AQM when TCP's window ought to be less than 2 segments.
Nonetheless, it would be useful for the AQM WG to continue to exist in 
order to review work on this.

Longer term, it is possible that a policer might be needed to detect and 
drop packets from 'rogue' flows before they are allowed to increase the 
delay of a shared queue. I am thinking of something like AFD that checks 
packets randomly to determine potential rogue flows, rather than full 
per-flow queuing (in which case there would be no shared queue to 
protect). However, it would be pointless developing such a policer while 
it would find that all standard TCP flows were 'rogue'. We need to 
define a "better than rogue" behaviour for TCP first.

Up to now, AQM has avoided mission-creep into policing - perhaps that 
should be reconsidered? Given,  for addressing the queuing delay 
problem, flow policing is more appropriate than flow queuing, and the 
latter but not the former is included within the charter.

> earning credits as supposed for fairness reasons.
In general, this is a useful list of some new requirements, but 
solutions (at least proposals) would be needed before AQM could really 
get to grips with these.
(I'm trying to build a solution for the "small RTT" problem, but lots of 
other demands on time.)

Bob

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/