Subject: [aqm] adoption call: draft-baker-aqm-sfq-implementation

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Aug 2014 10:25:12 -0400

Based on feedback we've seen, it looks like there is significant
value in progressing draft-baker-aqm-sfq-implementation as a
working group document.

Assuming there is WG consensus and we have AD-approval, we would
like to add a milestone to develop this towards an Informational
RFC within ~6 months.

Please provide any comments, questions, support, or criticism for
adopting this within the next few weeks.

-- 
Wes Eddy
MTI Systems

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Aug 2014 10:26:09 -0400

For reference, the draft is at:
http://tools.ietf.org/html/draft-baker-aqm-sfq-implementation-00

-- 
Wes Eddy
MTI Systems

---

From: [email-masked]
Date: Wed, 13 Aug 2014 12:43:25 +0100

I support this as a work-item.

Gorry

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: [email-masked]
Date: Wed, 13 Aug 2014 12:45:16 +0100

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Aug 2014 00:30:25 +0000

> adopting this within the next few weeks.

FYI, Gorry and I discussed the draft off-list. What I have right now is attached.