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

[Bob Briscoe <[e-mail]>]

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:[e-mail]] On Behalf Of [e-mail]
> > Sent: Dienstag, 05. August 2014 12:24
> > To: [e-mail]
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/aqm
> > >
> >
> > _______________________________________________
> > aqm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/aqm
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT