Re: [aqm] TCP ACK Suppression

Is this specialized upstream TCP ACK handling, particularly the prioritization a general recommendation in all access technologies? Perhaps it should be, since otherwise up and downstream TCP flows interfere in a crazy queue oscillation that is typically misinterpreted by AQMs. Is this topic

Re: [aqm] PIE vs. RED

Delayed-based RED still would associate latency with drop probability: drop probability will only go up when queueing latency goes up. A higher drop probability can only be achieved via higher queueing latency. If following Bob's statements last IETF, this could even be a desirable feature:

Re: [aqm] WGLC on draft-ietf-aqm-eval-guidelines

Hi all, I read the latest version of the draft, and I found it useful. The draft addresses a comprehensive range of topics for AQM characterization. What I am not so happy with, is the description of the corresponding experiments. Some critical points of my first review

Re: [aqm] AQM hurts utilization with a single TCP stream?

In steady state and single flow operation for 100% link utilization Reno requires a full BDP queue, CUBIC requires 40% BDP. This is independent of AQM or not. A tail-drop queue of the same size as CoDel's drop level performs exactly the same way in these circumstances. (I did the experiments.)

Re: [aqm] Comments on draft-ietf-aqm-eval-guidelines-01?

Hi, Bi-directional traffic is mentioned in section 3.1 Topology and 4.5 Traffic Mix, but not further detailed. I suggest to add at least one scenario in section 4.5, where both directions are congested at the same time, e.g. two or more counter propagating bulk TCP transfers. Only in this

Re: [aqm] review draft-kuhn-aqm-eval-guidelines-02

recent modification of Section 2.6 has been practiced and useful conclusions could be drawn. Kind regards, Wolfram Von: aqm [mailto:aqm-boun...@ietf.org] Im Auftrag von Nicolas KUHN Gesendet: Donnerstag, 28. August 2014 17:40 An: LAUTENSCHLAEGER, Wolfram (Wolfram) Cc: aqm@ietf.org Betreff: Re: [aqm

[aqm] WG: New Version Notification for draft-lauten-aqm-gsp-01.txt

algorithm - an additional section on delay based operation Comments are highly welcome. Thanks, Wolfram Lautenschlaeger -Ursprüngliche Nachricht- Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Gesendet: Freitag, 4. Juli 2014 14:12 An: LAUTENSCHLAEGER, Wolfram (Wolfram

Re: [aqm] references on global sync lock-out

I published a paper that reveals the root cause of global synchronization: A Deterministic TCP Bandwidth Sharing Model, http://arxiv.org/pdf/1404.4173v1 The findings in the paper are the theoretical basis for the GSP AQM proposal in http://tools.ietf.org/html/draft-lauten-aqm-gsp-00 -- Wolfram

Re: [aqm] last call results on draft-ietf-aqm-recommendation

I strongly agree with Bob's concerns: - Congestion collapse cannot be prevented by AQM - Flow fairness is not a topic for AQM - AQM should be possible without any knowledge of particular flows. As such it is clearly a L2 mechanism (which does not mean that it cannot be applied in L3 boxes). Of

Re: [aqm] [AQM Evaluation Guidelines]

See comments in line Shouldn't we more concentrate on what we expect from a good AQM? I'd love to... The only thing we might expect from an AQM is to prevent greedy TCP sources from drawing buffers permanently towards full state, I'm not the least bit sure that's possible. :^(

[aqm] new I-D on Global Synchronization Protection for Packet Queues

Dear all, I submitted an I-D with a proposal for a particularly light weight AQM scheme that is solely focused on suppression of global synchronization. Despite its simplicity it is able to reduce the queuing size, delay, and jitter by an order of magnitude and more, if many flows are