Re: [aqm] : draft-baker-aqm-sfq-implementation-00, minor comments

[[e-mail]]

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
>