RIchard,
All my points have been addressed, except one (below). Thank you, Fred Gorry.
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.
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.
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.
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.
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.
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).
Bob
At 14:24 08/08/2014, Scheffenegger, Richard wrote:
John, Bob,
had you the chance to review this new revision, which should address
the comments you had?
Best regards,
Richard Scheffenegger
-Original Message-
From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of go...@erg.abdn.ac.uk
Sent: Dienstag, 05. August 2014 12:24
To: aqm@ietf.org
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt
I've posted a new revision of the draft. This contains a reworked
introduction by Fred I, which seeks to clarify the intended status of
RFC 2309, and addresses all issues that we planned to address. We think
this is ready to proceed.
Gorry
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Active Queue Management and Packet
Scheduling Working Group of the IETF.
Title : IETF Recommendations Regarding Active Queue
Management
Authors : Fred Baker
Godred Fairhurst
Filename:
