Section, paragraph (page)
======= ========= ====
3.1 para 1 (p8)
We call a flow "TCP-friendly" when it has a congestion response that
approximates the average response expected of a TCP flow. One
example method of a TCP-friendly scheme is the TCP-Friendly Rate
Control algorithm [RFC5348]. In this document, the term is used more
generally to describe this and other algorithms that meet these
goals.
I'd move this definition into section 3.1, as it's first paragraph. The
last paragraph of section enumerates the three different types, it's
legitimate to defer the definition until one paragraph later, and make
it easier to understand a TCP-friendly flow
I have a question about the phrase "TCP-friendly". Responsive and
unresponsive are clearly applicable to bot TCP and UDP flows, which you
first discuss in section 3.2, just below. It appears you're discussing
it as a general "congestion friendliness", of which RFC 5348 is an
example, and as if the reasoning can apply to UDP, which you first
discuss in the following section, 3.2
If this is correct, you may wish to not use TCP in the term, as it
appears to limit it to TCP, and not UDP implementation that have
improved congestion avoidance.
Regrettably, "congestion friendly" is not quite what we'd want (;-))
May I suggest "congestion-resistant"?
3.3 title (p9)
Non-TCP-friendly Transport Protocols
Here I'd similarly suggest Non-Congestion-Resistant: they respond to
external signalling about congestion, but are not themselves resistant to it
3.3 para 2 (p9)
I'd split this into two paragraphs at "Others may", so you have a
series of paragraphs giving example of non-congestion-resistant flows.
You might wish to make them numbered examples.
In the first sentence, you note that some may have poor implementations:
can you cite one, preferably a current one, but a historical blunder if
we don't have a current example.
after 3.3 (p9)
The projected increase in the fraction of total Internet traffic for
more aggressive flows in classes 2 and 3 clearly poses a threat to
future Internet stability
[Niggle] Rather than classes 2 and 3, I'd recommend using their names,
non-responsive and non-congestion-resistant. We have several numbered
groups, and this one doesn't stand out, even though it's the most recent.
Do we have indications that these are becoming more prevalent? One
example might be Google's increasing their initial congestion window: if
so, it might be mentioned here, not necessarily by company-name.
after 3.3, para 2 (p10)
Another topic requiring consideration is the appropriate granularity
of a "flow" when considering a queue management method.
If flow is defined in another RFC, we probably will wish to use their
definition
I've often seen the address and port-number quad referred to as a flow,
sometimes with further granularity as to time, which would be your case (2)
End of second day: comments, suggestions and brickbats cordially accepted!
--dave
[If anyone would prefer this as amendments to an editable format, I have
it in a doc file
at https://github.com/davecb/draft-ietf-aqm-recommendation-edits]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
