Subject: [aqm] Alissa Cooper's Yes on draft-ietf-aqm-recommendation-09: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 16 Feb 2015 14:54:00 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-aqm-recommendation-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the hard work on this document. I have a few comments below.

-- General:
I think it would be useful to define "network devices" up front, and in
particular to clarify whether endpoint devices are subsumed in this
category. Are the recommendations in this document meant to apply to
queues in tablet/smartphone/laptop OSes as well as in routers, switches,
etc.?

-- Sec 1.2:
"instead it provides recommendations on how to select appropriate
   algorithms and recommends that algorithms should be used that a
   recommended algorithm is able to automate any required tuning for
   common deployment scenarios."

Seems like there are some extra words here.

-- Sec 3:
"There is a growing set of UDP-based applications whose congestion
       avoidance algorithms are inadequate or nonexistent (i.e, a flow
       that does not throttle its sending rate when it experiences
       congestion).  Examples include some UDP streaming applications
       for packet voice and video, and some multicast bulk data
       transport.  If no action is taken, such unresponsive flows could
       lead to a new congestion collapse.  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."

Would be nice to have a citation or two in this paragraph (though I can
see why you might not want to).

"Lastly, some applications (e.g. current web browsers) open a
       large numbers of short TCP flows for a single session.  This can
       lead to each individual flow spending the majority of time in the
       exponential TCP slow start phase, rather than in TCP congestion
       avoidance.  The resulting traffic aggregate can therefore be much
       less responsive than a single standard TCP flow."

I note that HTTP/2 is on its way to publication and there are a large
number of existing implementations, so the characterization of "current
web browsers" seems a bit off. I would suggest something like "(e.g. web
browsers primarily supporting HTTP 1.1)."

-- Sec 7:
I think there's actually a really important privacy aspect that should be
called out here, which is that by virtue of recommending that AQM
algorithms not be dependent on specific transport or application
behaviors, network devices need not gain insight into upper layer
protocol information for the purpose of supporting AQM. That is, the
document's explicit recommendation for algorithms to be able to operate
in a transport- and application-agnostic fashion is a privacy-enhancing
feature.

-- Sec 9:
I'm a little surprised that almost all of the research referenced in this
document is from the 1990s, given recent attention that has been paid to
this topic.