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

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

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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to