Re: [aqm] working group rechartering

Wolfram,

On 02/06/16 15:49, Lautenschlaeger, Wolfram (Nokia - DE) wrote:
> 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.
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.

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

>
> Just to mention a few of the open issues.
>
> Wolfram
>
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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