Subject: [aqm] Comments on draft-ietf-aqm-recommendation-00, message 2 of several

From: David Collier-Brown <[email-masked]>
Date: Sun, 19 Jan 2014 18:30:09 -0500

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]

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jan 2014 11:17:31 -0800

On Jan 19, 2014, at 3:30 PM, David Collier-Brown <[email-masked]> wrote:

> 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.

IMO, "responsive" isn't correct.

TCP-friendly also means friendly to TCP, i.e., there are numerous responsive variants of TCP congestion control that are not particularly friendly to the current recommended standard.

Typically, when we mean congestion responsive we say that; when we say "TCP friendly", we mean that it gets no more than a similar proportion of resources as the current standard TCP when competing for resources.

> Regrettably, "congestion friendly" is not quite what we'd want (;-))  May I suggest "congestion-resistant"?

I don't think that's what's sought here, ultimately. There are a nearly infinite number of congestion resistant solutions that are not practical for use in the current Internet because of how they interact with the current TCP standards.

Joe

---

From: David Collier-Brown <[email-masked]>
Date: Mon, 20 Jan 2014 15:34:23 -0500

On 01/20/2014 02:17 PM, Joe Touch wrote:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>
Excellent, thanks!

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[email-masked]           |                      -- Mark Twain
(416) 223-8968