Roland, Fred,
Here is a simple example to illustrate the differences between FQ-AQM with AQM
per queue vs AQM per aggregate queue.
Let's take 2 flows, each mapped to separate queues in a FQ-AQM system.
Link rate = 100 Mbps
Flow 1 rate = 50 Mbps, source rate does not go over 50 Mbps
Flow 2 rate >= 50 Mbps, adapts based on AQM.
FQ-Codel, AQM per queue:
Flow 1 delay is minimal
Flow 1 packet drops = 0
Flow 2 delay is close to target value
FQ-Codel, AQM for aggregate queue:
Does not work at all
Packets are dequeued alternatively from queue 1 and queue 2
Packets from queue 1 experience very small queuing delay
Hence, CoDel does not enter dropping state, queue 2 is not controlled :(
FQ-PIE, AQM per queue:
Flow 1 delay is minimal
Flow 1 packet drops = 0
Flow 2 delay is close to target value
FQ-PIE, AQM for aggregate queue:
Flow 1 delay and queue 1 length are close to zero.
Flow 2 delay is close to 2 * target_del :(
qlen2 = target_del * aggregate_depart_rate
Flow 1 experiences almost the same number of drops or ECNs as flow 2 :(
Same drop probability and almost same packet rate for both flows
(If flow 1 drops its rate because of packet drops or ECNs, the analysis
gets slightly more complicated).
See if this makes sense.
If the analysis is correct, then it illustrates that flow behaviors are quite
different
between AQM per queue and AQM per aggregate queue schemes.
In FQ-PIE for aggregate queue,
- The total number of queued bytes will slosh between
queues depending on the nature and data rates of the flows.
- Flows with data rates within their fair share value will experience
non-zero packet drops (or ECN marks).
- Flows that experience no queuing delay will increase queuing delay of
other flows.
- In general, the queuing delay for any given flow will not be close to
target_delay and can be
much higher
Regards,
Anil
-----Original Message-----
From: aqm [mailto:[email protected]] On Behalf Of Bless, Roland (TM)
Sent: Friday, July 03, 2015 7:41 AM
To: Toke Høiland-Jørgensen; Polina Goltsman
Cc: [email protected]; Hironori Okano -X (hokano - AAP3 INC at
Cisco); Fred Baker (fred); AQM IETF list
Subject: Re: [aqm] FQ-PIE kernel module implementation
Hi,
Am 03.07.2015 um 12:16 schrieb Toke Høiland-Jørgensen:
> Polina Goltsman <[email protected]> writes:
>
>> As I understand the FQ-Codel draft, it seems to be fundamental to
>> FQ-Codel that each queue has separate state variables. So my question
>> is: is it indeed fundamental ?
>
> I suppose that becomes a matter of semantics: What exactly do you mean
> by 'fundamental'. If you mean "an integral part of the current
> algorithm", then yes. If you mean "it's unthinkable to build a similar
> algorithm without the separate state variables" then no. I understand
> Fred's comment to take the second interpretation. :)
I guess Polina's point was:
it is a question how "similar" two realizations of PIE would be if one applies
PIE per flow like in FQ-Codel or alternatively (as proposed by FQ-PIE) FQ first
and then PIE working on the aggregated queue.
Was it a deliberate choice for the latter and if so, why?
It would be good to document this difference to FQ-Codel explicitly.
Regards,
Roland
_______________________________________________
aqm mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=AwIF-g&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=pcEVvl4qisljUGX7ogOyVICZ56p8s6lOuh8toIjEWzE&s=z1oQXxfgw7lLAkyQS7rwBUBlhihe3hD8IY623asr6vs&e=
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
