Subject: Re: [aqm] [tsvwg] Thoughts on AQM

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Mar 2013 11:57:47 +0000

FWIW:

I think, such a document should not be based on 2309 in text, but definitely in spirit.

(updates/obsoletes 2309 yes, but not a 2309bis draft).

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wesley Eddy
> Sent: Dienstag, 12. März 2013 13:17
> To: Fred Baker (fred)
> Cc: [email-masked]
> Subject: Re: [tsvwg] Thoughts on AQM
> 
> 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: Thu, 14 Mar 2013 13:14:36 +0000

> (updates/obsoletes 2309 yes, but not a 2309bis draft).

Works for me. My first instinct was as you suggest, and I took this approach partly at Wes' suggestion and partly because it was something I could hack together in an hour yesterday morning. But if 2309 makes an algorithmic recommendation, that is at best dated. I'd rather not make a recommendation, but instead agree on a set of requirements that the algorithm someone uses should meet. That way, we leave room for improvements over time.