On Tue, Jul 7, 2015 at 2:08 AM, Polina Goltsman < [email protected]> wrote:
> Hello all, > > Here are my thoughts about interaction of AQM and fair-queueing system. > > I think I will start with a figure. I have started a tcp flow with > netperf, and 15 seconds later unresponsive UDP flow with iperf with a send > rate a little bit above bottleneck link capacity. Both flows run together > for 50 seconds. > This figure plots the throughput of UDP flow that was reported by iperf > server. (Apparently netperf doesn't produce any output if throughput is > below some value, so I can't plot TCP flow.). The bottleneck is 100Mb/s > and RTT is 100ms. All AQMs were configured with their default values and > noecn flag. > > > Here is my example in theory. A link with capacity is C is shared between > two flows - a non-application-limited TCP flow and unresponsive UDP flow > with send rate 105%C. Both flows send max-sized packets, so round robin can > be used instead of fair-queueing scheduler. > > Per definition of max-min fair share both flows are supposed to get 50% of > link capacity. > > (1) Taildrop queues: > UDP packets will be dropped when its queue is full, TCP packets will be > dropped when its queue is full. As long as there are packets in TCP flow > queue, TCP should receive its fair share. ( As far as I understand, this > depends on the size of the queue) > > Well, no. Tail drop will misbehave here also. > (2) AQM with state per queue: > Drop probability of UDP flow will always be non-zero and should stabilize > around approximately 0.5. > Drop probability of TCP flow will be non-zero only when it starts sending > above 50%C. Thus, while TCP recovers from packet drops, it should not > receive another drop. > Yes. You will get an interesting result if you ECN enable the udp flows and ecn enable the aqm and fq-aqms, in that fq-codel presently has a very compute intensive means of dealing with that (at least on initial overload), that we have reduced the impact of a great deal in cake that may well one day go into fq_codel. Too many folk believe that once ECN is unleashed that everybody will play nice. The game theory win for treating ecn is to treat it as an earlier signal than drop, of course, and various folk are working on that. I would also like it if tcps treated CE marks with drops also as an even stronger signal of congestion. (cake drops, then marks, on serious overload) Also, sch_fq, at least, has a large initial quantum, so in this scenario small flows would at least get a bit of throughput. I don't know what fq-pie will do. > (3) AQM with state per aggregate: > UDP flow always creates a standing queue, so drop probability of aggregate > is always non-zero. Let's call it *p_aqm*. > The share of TCP packets in the aggregate *p_tcp = TCP send rate / (TCP > send rate + UDP send rate)* and the probability of dropping a TCP packet > is *p_aqm * p_tcp. *This probability is non-zero unless TCP doesn't send > at all. > > In (3) drop probability is at least different. I assume that it is larger > than in (2), which will cause more packet drops for TCP flow, and as result > the flow will reduce its sending rate below its fair share. > > Regards, > Polina > > > On 07/07/2015 10:06 AM, Bless, Roland (TM) wrote: > > Hi, > > thanks for your analysis. Indeed, Polina came up with > a similar analysis for an unresponsive UDP flow and > a TCP flow. Flow queueing can achieve link share fairness > despite the presence of unresponsive flows, but is ineffective > if the AQM is applied to the aggregate and not to the individual > flow queue. Polina used the FQ-PIE implementation > to verify this behavior (post will follow). > > Regards, > Roland > > > Am 04.07.2015 um 22:12 schrieb Agarwal, Anil: > > 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 > > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > > -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
