Subject: [aqm] Comments on draft-ietf-aqm-recommendation-00, message 3 of what turns out to be three

From: David Collier-Brown <[email-masked]>
Date: Thu, 23 Jan 2014 22:50:34 -0500

Section, paragraph (page)
=======  =========  ====
4 para 1 (p10)
   The IRTF, in publishing [RFC2309], and the IETF in subsequent 
   discussion, has developed a set of specific recommendations regarding
   the implementation and operational use of AQM procedures.  This
   document updates these to include

As we have a list that is immediately followed by the same list in an
expanded form, I'd suggest a few words to tell the reader what they're
going to see. I'd end the paragraph with "some seven additional
considerations, expanded upon starting in section 4.1

   4, last para (p11)
       However, care should be taken in concluding that one's use  case
falls in that category;

Actually this would be stronger if it was the conclusion of the previous
sentence. I'd suggest the sentence start with "Therefore"

4.1, para 1 (p11) 
   AQM procedures are designed to minimize delay induced in the network by queues that have filled as a result of host behavior.

It's also true hat we're trying to prevent buffer overflow, so I'd
suggest changing "delay" to "delay and buffer exhaustion", to make the
argument for AQM a stronger one.

   4.2, para 5 (p12)
       To be conservative transport must the latter."

I think "assume" may be missing here.

4.5, para 3 
   AQM algorithms SHOULD NOT target or derive implicit assumptions about

   the characteristics desired by specific transports/applications.
   Transports and applications need to respond to the congestion signals
   provided by AQM (i.e. dropping or ECN-marking) in a timely manner
   (within a few RTT at the latest).

This reads like it should be the introductory paragraph of section 4.6, so
I'd move it there.

 4.6 para 3, now 4, (p 15)

       A common objective is to deliver data from its source end point to

   its destination in the least possible time.  When speaking of TCP
   performance, the terms "knee" and "cliff" area defined by [Jain94].
   They respectively refer to the minimum congestion window that
   maximises throughput and the maximum congestion window that avoids
   loss.  An application that transmits at the rate determined by this
   window has the effect of maximizing the rate or throughput.  For the
   sender, exceeding the cliff is ineffective, as it (by definition)
   induces loss; operating at a point close to the cliff has a negative
   impact on other traffic and applications, triggering operator
   activities, such as those discussed in [RFC6057].  Operating below
   the knee reduces the throughput, since the sender fails to use
   available network capacity.  As a result, the behavior of any elastic
   transport congestion control algorithm designed to minimise delivery
   time should seek to use an effective window at or above the knee and
   well below the cliff. 

This is not the case where one has a congestion control mechanism, and
it's inconsistent with Jain's later works or a modern understanding
of queues.  The knee is a region, between a gentle increase in latency
with increasing throughput and the cliff, or the "handle of the hockey
stick"
to use modern terminology.   He was using "knee" as the first upturn, and
"cliff" as the completion of the upturn.

Speaking of TCP only, one wants to run up to the point at which one sees
congestion,
then back off, exactly what we try to do. 

I'd therefor say something like

Common objectives of TCP/IP are deliver the maximum amount of data 
without inducing queuing delays when packets sit in a buffer waiting
to be sent on.  It is important to stay below the inflection point
(bend) in the load/delay curve, which is shaped like a hockey-
stick, "_/". Above the bend, congestion exists, delay rises without bound 
and TCP starts dropping packets due to the congestion.

Approaching the bend, delay starts to rise due to congestion, caused
by packets probabalistically arriving at overlapping times. Near-
maximum throughput and low latency are both achieved quite close to the
knee, so it is desirable to send at as rapid a rate as can be done without 
causing congestion.

Choice of an appropriate rate can therfore significantly impact the loss and 
delay experienced not only by a flow, but by other flows that share the same queue.

  This stays away from the possibly fuzzy language and calls out the
packet drop as
something that a queue modeler will recognize as non-standard.

Finally, in 6, I'd suggest that a DOS atatck "may probably be disguised
as" rather than "may create"
unresponsive flows that may be indistinguishable from normal
unresponseive ones.

End of third day: comments, suggestions and brickbats cordially accepted!

--dave
[If anyone would prefer this as amendments to an editable format, I have
it in a doc file
at https://github.com/davecb/draft-ietf-aqm-recommendation-edits]