Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt

[[e-mail]]

Bob, I see several issues that can easily be resolved by a very minor
revision to take care of this, and my suggested plan is below:

...

> The one about the 3 types of flows has missed my point in a
> couple of  ways, (A) & (B) explained below.

> Section 3 divides flows into 3 types:
> (1) TCP Friendly flows,
> (2) unresponsive flows, i.e., flows that do not slow
> down when congestion occurs, and
> (3) flows that are responsive but are not TCP-friendly.

> A) It might seem obvious to some that "not friendly", means "less
> than friendly", but given the definition of TCP-friendly, "not
> TCP-friendly" is ambiguous and could also mean "more friendly
> than TCP" (e.g. scavenger transports).

> Therefore, I suggest changing "not TCP-friendly" and
>”Non-TCP-friendly"  to "less responsive than TCP-Friendly" or some
>similar phrase.
>

+GF: Perfect, I like this a lot, and can use "less responsive than TCP" as
a basis for making this better.

> B) My main point was that (1) and (2) are points on a spectrum, and
> 3 is a region that spans the whole of the spectrum between these
> points. Then the rest of the doc talks about all three as if they
> are in the same set of types.
>
+GF: If we change the language above, we can explicitly say this, and I’ll
add text.

————>

> That's not a useful classification. Previous docs in the RFC series
> have been careful not to overclaim the importance of precise
> TCP-friendliness. It's not helpful to suggest that anything to the
> left of TCP-Friendly "clearly poses a threat to future Internet
> stability". It would be more useful to describe it as a spectrum
> with two reference points on it (as shown).

> Then say the closer to the
> unresponsive end that a flow is, the more it could pose a threat to
> the performance of other flows during times of excessive contention.
>
>          Unresponsive                     TCP-Friendly
>           |                                     |
>           v                                     v
> 5 5 5 5 5 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 1 4 4 4 4 4 4 4 4 4 4
4 4 4 4 4 4 4 4
<-Beyond-> <---responsive but less than TCP----> <--responsive but
more than TCP--->
Unrespons-
   ive

> In fact, there is (fairly common) behaviour to the left of
> unresponsive, where a flow adds redundancy. By turning the
> classification into a spectrum, it would be fairly natural
> to include that as well.
>
+GF: I think the new test should be closer, and I added this to the
"unresponsive" case to explicitly call this out:

Some applications can even increase their traffic volume in response to
congestion (e.g. by adding forward error correction when loss is
experienced), with the possibility that they contribute to congestion
collapse.

> Other than this, I don't want to tamper with the text on whether AQMs
> have a role in flow isolation, because it does well to leave the
> question open.
>
+GF: That was intended, good.

> C) Also (a new point I didn't mention before), the alarmist
> language in two places is rather over-the-top:
> * "The last two classes contain more aggressive flows that pose
> significant threats to Internet performance"
> * "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"
>
> Suggested text, respectively:
> * "The last two classes contain more aggressive flows
> that can pose  significant threats to Internet performance"
> * "The projected increase in the fraction of total Internet
> traffic for more aggressive flows in classes 2 and 3 could
> pose a threat to
> future Internet performance"

> Note, I've also suggested changing 'stability' to 'performance' -
> this doc has nothing to do with oscillations, etc.

+GF: Agree, this text was directly taken from RFC 2309… let's change it
... but how about “dependable performance”? (i'd like to capture that this
isn't performance tuning - but more expectation of performance.

> For instance, does VoIP pose a significant threat to
> Internet  performance? Nah. Still in some places maybe,
> but the Internet is generally coping. When the Internet was
> growing up we thought VoIP might cause collapse, but our
> concerns have waned as link capacities have grown. So the
> perception of threat depends on the bit-rate of
> the flow relative to average link capacities.
>

——

> Responsiveness is important, but I believe it is OK for unresponsive
> flows that are small in relative terms to only be responsive at very
> long timescales (even solely at flow set up - self-admission
> control). This even applies to aggregates of unresponsive flows,
> because they will tend to be deployed where even the aggregate is
> small relative to the link capacity.
> See http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf
> (comments to the PWE3 list pls).

+GF: I don’t see this needed in this draft.

> Bob

——

+GF: I’m also considering replacing /congestive collapse/ by /congestion
collapse/ which seems a more common term, as noted by John L.

+GF: And I'll rewrite the Acknowledgement text relating to RFC 2309, as
noted by John L.