I have a few initial comments from re-reading draft draft-baker-aqm-sfq-implementation-00. These may be useful in preparing the next version:
As we noted in other discussions, "SFQ" is not helpful in the title. Section1 I wonder if the introduction could point to more scheduling algorithm options than simply the combination of "SFQ" with an AQM? Section 2.1 Normally I'd use "kbps" to indicate kilobits per second, to avoid confusion with the tendency of some TCP researchers to report kilobytes/sec. Saying TCP IW can be "any value", could be unpalatable in the RFC series, this at least needs a pointer to RFCs that specify IW. Maybe the term TSO is widely used, so you could say /TCP offload/TCP segment offload/ DSCP probably should be expanded on first use. 2.2.3 There could also be a "defer" processing when using encapsulations that support a suspend/resume function as in PPP (RFC2687). Section 3 It seems to suggest that delay (or even packet pair) is used by IETF transports such as SCTP of TCP - this isn't so for current IETF congestion controllers. It also seems (??) to suggest PacketPair is a useful technique in combination with link scheduling. On this I am not certain this is wise to say - the experience I recall is that scheduling results in rather unpredictable on the packet pair algorithm... but maybe I'm misreading this, and the idea is to suggest this as a measurement tool? Section 3.2 ECN needs a reference when first used. /completely separate/ seems to be stated twice in two successive sentences. Section 4 /It is however incorrect to discuss/ - This seems rather judgmental to prohibit discussion, is it possible to invert the argument and say what is useful? Gorry > For reference, the draft is at: > http://tools.ietf.org/html/draft-baker-aqm-sfq-implementation-00 > _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
