Subject: [tsvwg] Thoughts on AQM

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Mar 2013 11:37:24 +0000

As it turns out, I'm not going to be able to attend the tsvwg meeting, and specifically the AQM discussion, Thursday. For some reason I hd it in my head that it would be this morning, and was looking forward to it. Thursday, it conflicts with isis, and I will be presenting in isis.

To that end, let me express the considerations I hold with regard to AQM, RED, CoDel, and other alternatives. Please think of this as me standing at the mike and babbling...

Fred Baker, Random Router Vendor

In my opinion, AQM technologies and the recommendation of RFC 2309 are important to the Internet. As Jim Gettys has commented in the BufferBloat discussion and documents from RFCs 896 and 970 through SIGCOMM and INFOCOMM in the 1980's and 1990's have discussed, it is in the interest of all applications to manage their rate of flow to a dull roar, for for their own benefit and for others they compete with. CUBIC and NewReno, in their zeal to achieve maximum bandwidth, drive their traffic outstanding (effective window) to what Dr Jain calls the "cliff", resulting in them frequently having to recover from wasting time and bandwidth. Tools like ECN have not yet been worked out for effective service, but I continue to believe that it should be possible with experimentation, which is being done in some data center environments. AQM, whether implemented using signaling or loss, allows the network to communicate to the host about congestion before a catastrophic event happens, maximizing good put while and minimizing the impact of one flow on itself and those around it. This is good and should be supported.

RFC 2309 recommends AQM deployment, but doesn't require a specific algorithm. That is good, because the prototypical algorithm of the day (RED) is difficult to use. Van and Kathy have suggested CoDel, Rong Pan and I are investigating another algorithm called PIE, and there has been ample research on other algorithms. In my opinion, recommendations of specific algorithms are wisely kept off the table; they make future innovation difficult.

What I think may be of value - and would be willing to contribute to in tsvwg - is a set of recommendations regarding the technical use of AQM and congestion control. That document might recommend, for example, that 

a) Operational deployments SHOULD use AQM procedures.

b) Deployed AQM SHOULD use ECN as well as loss, and set thresholds to mark traffic earlier than it is lost. In this way, congestion control can be achieved in the general case without loss, and loss remains the backup when needed.

c) AQM algorithms deployed SHOULD not require operational (manual) tuning.

d) AQM algorithms deployed SHOULD be effective on all common Internet traffic, including traffic that uses TCP, SCTP, UDP, and DCCP as transports.

e) TCP congestion control algorithms SHOULD maximize their use of available bandwidth without incurring loss or undue delay when possible. In other words, in Jain's language, the TCP/SCTP effective window wants to be greater than or equal to the knee, but less than the cliff. 

There may also be other recommendations, but these address most of the issues I see.

Thanks. I'm sitting down now.

---

From: ken carlberg <[email-masked]>
Date: Tue, 12 Mar 2013 07:46:44 -0400

Fred,

> c) AQM algorithms deployed SHOULD not require operational (manual) tuning.

on the particular topic, would you see the eventual need for something like next generation COP (rfc-2478) to help manage the AQM algorithm(s)?

-ken

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 12 Mar 2013 08:08:22 -0400

On 3/12/2013 7:37 AM, Fred Baker (fred) wrote:
> As it turns out, I'm not going to be able to attend the tsvwg
> meeting, and specifically the AQM discussion, Thursday. For some
> reason I hd it in my head that it would be this morning, and was
> looking forward to it. Thursday, it conflicts with isis, and I will
> be presenting in isis.

The AQM discussion will be in *TSVAREA*, not TSVWG.  I will send a
reply with a couple questions on the [email-masked] list.

That said, this was a very welcome email, and very clear and useful
to the ADs; thanks!

-- 
Wes Eddy
MTI Systems

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Mar 2013 17:35:43 +0000

> on the particular topic, would you see the eventual need for something like next generation COP (rfc-2478) to help manage the AQM algorithm(s)?

Are you thinking about 2478 or 2748?

http://www.ietf.org/rfc/rfc2478.txt
2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize,
     D. Pinkas. December 1998. (Format: TXT=35581 bytes) (Obsoleted by
     RFC4178) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4178.txt
4178 The Simple and Protected Generic Security Service Application
     Program Interface (GSS-API) Negotiation Mechanism. L. Zhu, P. Leach,
     K. Jaganathan, W. Ingersoll. October 2005. (Format: TXT=46485 bytes)
     (Obsoletes RFC2478) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc2748
2748 The COPS (Common Open Policy Service) Protocol. D. Durham, Ed.,
     J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000.
     (Format: TXT=90906 bytes) (Updated by RFC4261) (Status: PROPOSED
     STANDARD)

https://tools.ietf.org/html/rfc4261
4261 Common Open Policy Service (COPS) Over Transport Layer Security
     (TLS). J. Walker, A. Kulkarni, Ed.. December 2005. (Format: TXT=28662
     bytes) (Updates RFC2748) (Status: PROPOSED STANDARD)

IMHO, the point of it being self-tuning is to not require configuration intervention. That said, trust me, if there is a way to make a simple thing complex, I'm sure we can find it, and then figure out how to manage it.

---

From: ken carlberg <[email-masked]>
Date: Wed, 13 Mar 2013 08:56:13 -0400

> Are you thinking about 2478 or 2748?
<snip>
>     (Format: TXT=90906 bytes) (Updated by RFC4261) (Status: PROPOSED
<snip>
> IMHO, the point of it being self-tuning is to not require configuration intervention. That said, trust me, if there is a way to make a simple thing complex, I'm sure we can find it, and then figure…

mea culpa.  i meant the latter, 2748.  I was thinking about the means of maintaining a uniformity of characteristics (eg, algorithms) for the AQM deployments within the administrative domain (eg, large and topologically disperse enterprise networks, or transits).  This, as opposed to AQM at a single ingress/egress point.

cheers,

-ken

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Mar 2013 13:03:35 +0000

> mea culpa.  i meant the latter, 2748.  I was thinking about the means of maintaining a uniformity of characteristics (eg, algorithms) for the AQM deployments within the administrative domain (eg, l…

AQM is a class of procedures for managing queue depth. Since every queue in the network requires a drop algorithm (no queue is infinitely deep, even if it appears that way), the question isn't whether such algorithms are necessary in a given place, it's what kind of algorithm to recommend. I think this would appear in every queue in the network, even if the queue doesn't as a rule become deep; such a queue would simply not normally find itself invoking the algorithm.