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 : draft-ietf-aqm-recommendation-07.txt
> > Pages : 28
> > Date : 2014-08-05
> >
> > Abstract:
> > This memo presents recommendations to the Internet community
> > concerning measures to improve and preserve Internet performance. It
> > presents a strong recommendation for testing, standardization, and
> > widespread deployment of active queue management (AQM) in network
> > devices, to improve the performance of today's Internet. It also
> > urges a concerted effort of research, measurement, and ultimate
> > deployment of AQM mechanisms to protect the Internet from flows that
> > are not sufficiently responsive to congestion notification.
> >
> > The note largely repeats the recommendations of RFC 2309, and
> > replaces these after fifteen years of experience and new research.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-aqm-recommendation-07
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-07
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > aqm mailing list
> > aqm@ietf.org
> > https://www.ietf.org/mailman/listinfo/aqm
> >
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
