Nicolas KUHN <[email protected]> writes: > We tried to be the clearer the possible. > If you have any comments or proposals, we would be glad to hear them.
Well, one thing I believe is worth addressing is the issue of simulation vs experiments on real systems. I would not consider an algorithm that has never been subjected to real-world testing to be sufficiently evaluated. Another issue is how to obtain the data: if the AQM itself is inspected while running that might affect its performance, whereas if packet traces or application level measurements at another point are inspected, they might be showing behaviour that has very little to do with the behaviour of the AQM algorithm. As an example of the latter, on Linux it is very easy to end up measuring buffers in the network driver, unless care is taken to avoid it. I would like to see the draft address these issues and provide some guidance on how the most obvious pitfalls can be avoided. I'll be happy to draft some text on it, if it's not part of the planned methodology section. > I agree that methodology should be integrated in the draft. I will > include a dedicated section in the next version of the draft. Great (also, comments above)! > I think this is dealt with in section 3.3.1.5. (I'm assuming you mean 3.2.1.5 here). I suppose that scenario could cover this; however, I was also alluding to the methodological issue of distinguishing between the case where latency is measured by a separate flow (such as a straight 'ping' alongside the test) vs directly measuring the queueing delay of the packets making up the traffic scenario; I believe both kinds of measurements provide valuable data, but about different aspects of the algorithm behaviour... > The next version will be more specific with the expected output > (measuring the metrics separately for each class of traffic). The next > version will also detail that the TCp transfer can be operated with an > LBE congestion control. ACK. What about IW4 vs IW10? > The idea behind the draft was to be quite generic. Wi-Fi is a use case > for "Medium bandwidth, medium delay" scenario. We could go deeper into > details, but I am afraid that the draft will lose some of its > generically. This should be further discussed with the list. I'm not saying "get rid of the scenario", I'm saying "Don't call it wifi, because that mischaracterises the behaviour of wifi". And perhaps also "add a scenario where bandwidth varies on very small time scales". > I am not sure the current draft mention that AQM and scheduling are > interchangeable. I think the draft mentions that they may both reduce > the latency and the distinction between the two is clear. If some > sections lack of clarity, please point them out. I think it could be made clearer whether or not his document is meant as only a way to evaluate AQM algorithms, or if hybrid AQM/scheduling algorithms should also be in scope (I would argue for the latter). In the first many sections, whenever scheduling is mentioned (sections 2, 2.2.3, 3.2.3), the wording suggests that indeed AQM and scheduling can be complimentary and an algorithm might feasibly be a tightly coupled hybrid. However, the section specifically dealing with scheduling (4.4), discussing adding scheduling "on top of" the algorithm is mentioned as a requirement, which might imply that an algorithm that already includes (say) a tightly coupled scheduler would not be liable for consideration? Also, this paragraph: Both schedulers and AQMs can be introduced when packet are either enqued or dequed. If both schedulers and AQM are implemented when packet are enqued, their interaction should not be a major issue. However, if one is introduced when packets are enqued and the others when they are dequed, there may be destructive interactions. seems a bit speculative to me. Has the fact that the algorithms' activation time is a predictor of adverse side effects actually been demonstrated? > The draft claims that the impact of every externally tuned parameter > MUST be discussed. The tester SHOULD provide background material > showing control theoretic analysis but COULD use other ways to discuss > stability. That formulation would be fine with me. However, the last part of the latter sentence (the COULD part) is missing from the draft... :) -Toke
signature.asc
Description: PGP signature
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
