Nicolas KUHN <nicolas.k...@telecom-bretagne.eu> writes: > Please let us know what you think of the current document.
Hi Nicolas and others Thank you for the draft; here are some comments, mostly of a more general nature (as opposed to concrete proposals for rewording). 1. TESTING METHODOLOGY AND REPRODUCIBILITY I think it is important to encourage good testing methodology in a document like this; and from the current draft the actual proposed testing method is not clear. I realise it is also important to leave some room for people to do things in the way that suits their work-flow, however I believe some minimum standards for methodology would be appropriate. Reproducibility is a part of this that is especially important, but other areas that spring to mind are: - A sufficiently detailed description of the test setup to allow others to replicate it. Including software and hardware versions etc. - Availability of the data used for analysis to allow others to check the conclusions drawn. Requiring a reference implementation to be available could also be relevant to this general point; I would think it would be a reasonable requirement to have. 2. COMPETING VS LOAD-INDUCING TRAFFIC CHARACTERISTICS Distinguishing between the effect an AQM has on the traffic that induces the congestion and traffic that competes with it is worthwhile, in my opinion. For some applications (e.g. background transfers), maximising goodput for the "offending" stream is less important than ensuring that other traffic is not experiencing added latency because of it, while for others (e.g. an adaptive video conference stream), the latency of the "offending" stream can be vital. Having this distinction in the measurements (by measuring both) makes it possible to evaluate this aspect of the AQM behaviour. 3. SOME COMMENTS ON THE SCENARIOS I have various comments on the proposed testing scenarios: - 10 Mbps is a fairly high bandwidth compared to the average connection to the internet. I believe it would be worthwhile to include lower bandwidth(s) in the "general" scenarios, and not just in the "optional" ones. - I don't believe the scenario dubbed "Wi-Fi" is a realistic representation of the behaviour of a wifi link. A comprehensive wifi test would include the presence of multiple hosts, bandwidth varying on very short time scales, and packet aggregation behaviour. I would suggest keeping the existing scenario, but calling it something else, and then adding a more comprehensive wifi scenario (which would probably need some hashing out). - I'm missing measurements of the behaviour of real-world traffic such as DNS lookups, HTTP requests, etc. Indeed, having bidirectional traffic included would be good. 4. SCHEDULING vs AQM In the first section(s) mention AQM and scheduling as though they are interchangeable, while a later section mentions AQM interaction with scheduling mechanisms. I believe it is worthwhile to both (a) distinguish clearly between what is mean by AQM resp scheduling, but also (b) make the recommendations apply equally to a "pure" AQM algorithm and to a combination scheme that includes both an AQM and a scheduler (which may or may not be intricately linked in their operation). 5. STABILITY ANALYSIS While I agree that it is important for an algorithm proposal to argue plausibly for its stability, I think it is wrong to *require* that argument to be made in the form of a control theoretic analysis. Such a requirement limits possible algorithms to those that can be described using that particular paradigm (loosely, things expressible and solvable by differential equations). For instance, the fluid dynamic TCP model commonly used for control theory stability analysis, discards a lot of the dynamics of TCP, most notably slow start and other transient behaviour, and focuses on the steady state. Since it is by no means clear that this is the only way to make the argument (and indeed focusing too much on the steady state can be counter-productive), I would suggest to at least reword the section to mention control theory as *a* way to make the argument, rather than the *only* way. Sorry if this got a bit long; I started with a much shorter list of notes, I swear! :) -Toke
signature.asc
Description: PGP signature
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
