Subject: Re: [tsvwg] Thoughts on AQM

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

On 3/12/2013 7:37 AM, Fred Baker (fred) wrote:
> 
> 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.
>

I agree, though we certainly would like some known good algorithm(s),
hopefully free of IPR issues, to be available to implementations
that don't want to invent their own algorithm.

There are also probably some algorithms that are not so good, and
it will be useful to know how that can be identified by people
developing / working with them.

> 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.

This is very helpful to hear.  This sounds like 2309bis to me, since
(a) is basically what 2309 already says, and I see b and c as basically
incorporating things that have happened since then (ECN and learning
that auto-tuning is good).  Do you see it as an update to 2309?

-- 
Wes Eddy
MTI Systems

---

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

> that auto-tuning is good).  Do you see it as an update to 2309?

Basically. It could be usefully written to replace 2309, incorporating much of the existing text and adding what we have learned in the 20 years intervening.