On 11/18/13 4:44 AM, "Scheffenegger, Richard" <[email protected]> wrote:
>[chair hat off] > >Hi Michael, > >> >>------------------------------------------ >>>>>>>>>RP: Again, the tight delay control comes from narrow-band >>>>>>>>>bang-bang control with hard drops. The scenarios >that >>>>>>>>>throughputs are good are in higher congestion scenarios where >>>>>>>>>there are enough packets showing up to fill the >pipe. That is >>>>>>>>>not the effectiveness of AQM. Tail drop with shallow buffer will >>>>>>>>>have high throughput in those cases >too. Try a scenario when >>>>>>>>>link is congested and a burst comes, see how many packets of that >>>>>>>>>burst can go through. >>------------------------------------------ >> >> Maybe we disagree about the goals... why would you want to allow a >>burst on an already congested link? > >How do you define congested link? > >You will want to be burst-tolerant on a link running at full capacity - >but is such a link already congested? Great questions Richard. Defining congestion is probably the main point of contention here. Michael, thanks for mentioning about ICCRG discussions on this topic, I think it'd be worthwhile to go through that as well. If you can send everyone a pointer that'd be useful as well. Here is my humble opinion -- congestion should be defined based on its impact (to the applications). In that sense, there will be varying levels of congestion -- mild to severe. Symptoms of mild congestion could be slowly increasing (by some delta) buffering and queueing delay. Symptoms of severe congestion could be packet drops at the tail, blocking other flows etc. A full capacity + non-empty queue doesn't impact applications in any way, so this doesn't signify congestion. A latency-based AQM scheme should operate the queue at a specified queueing delay, which means the outgoing link is under some level of congestion already. Under these conditions, an AQM scheme should be able to handle bursts in an effective way. A mechanism's effectiveness in handling these bursts could be evaluated/determined by factors such as (i) how long does it take to bring burst under control, (ii) packet drops during this period, (iii) link utilization during this period, and may be others that I am missing. > >In any case, defining a scenario that would lead to excessive buffering >delay in the drop-tail case, and comparing this for various AQMs should >be documented. I agree. Thinking more, maybe we should evaluate an AQM for the varying levels of congestion. Document scenarios that'd create the different levels of congestion from mild to severe and compare AQMs for all these levels, not just empirically but also highlight their behavioral differences. Thanks, Preethi _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
