From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6A91E21F107; Sun, 17 Mar 2013 11:32:53 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id ef5so4748881obb.11 for ; Sun, 17 Mar 2013 11:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=pPa8FtiXHjDrLsGw5oxv9K3GNx2b3lXaG3bkGlb1chs=; b=qKx43Ri/uMaRn/slBRfBZG8VzMs+cV2OapMGMJaO0rL86tazn9yYz3+swtErSPH9IB 7SwTW2uTMr3tBh52yZ5mhZo7bv/v8VrahGCorlw4pPNNu6IGiZokrkmyGYw1hY0LRaJY 3TOjPk5AUrTpT7EfUKg8arcaZvBTQzt+9ZeqkWR9PpKs3irIiCI//7deDcdV/v33GhmC nz/1dvYu720V/25FVQQWcyjgzuMVEkoCo1W2gMjyr1YAJmO28wHEY/qsRMcGsm5rTRw1 EWbGWD85oFNiV56uW2H/xSt3dcRKsJ/5wKIF0USbOvs4HhR4aGAr1mhwCy9slHVM7svl SWNA== MIME-Version: 1.0 X-Received: by 10.182.95.34 with SMTP id dh2mr4807864obb.65.1363545172316; Sun, 17 Mar 2013 11:32:52 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Sun, 17 Mar 2013 11:32:52 -0700 (PDT) Date: Sun, 17 Mar 2013 14:32:52 -0400 X-Google-Sender-Auth: 9GnOyddXdibLVAoX_5mNqcBSBJY Message-ID: From: Jim Gettys To: bloat , bloat-devel , "cerowrt-devel@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=089e015386d8a19df404d82319c8 Subject: [Cerowrt-devel] Replacing the "RED Manifesto" with an "AQM manifesto" in the IETF X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:32:53 -0000 --089e015386d8a19df404d82319c8 Content-Type: text/plain; charset=ISO-8859-1 The ICCRG meeting at last week's IETF went very well, as did a variety of live demos of fq_codel. You can find the ICCRG slide sets here: https://datatracker.ietf.org/meeting/86/materials.html and, though the sessions were not video'ed by the IETF, Dave and I used our phones and may put some low quality video up later. See: http://www.ietf.org/blog/ and https://plus.google.com/u/0/107942175615993706558/posts/A1seNKANmDg My great thanks to Dave Taht and Comcast to pull off a live demo of bufferbloat helping drive bufferbloat's reality home to people. Such live demos are always a huge amount of work. The tsvarea meeting resulted in consensus to work toward establishing a working group and updated set of best practices and RFCs regarding AQM recommendations. First up was establishing a new mailing list for "aqm", which can be joined here: https://www.ietf.org/mailman/listinfo/aqm Now is the time to see how standards sausage is made! Some advise was published in the ICCRG meeting about how to proceed further: http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-4.pdf Those of you familiar with RFC 2309 may know that it was informally called the "RED manifesto", and aware that RED's shortcomings doomed it. But such a document (as a public statement of the IETF that this problem must be urgently solved). Fred Baker (who was IETF chair recently) just issued an initial internet draft: http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation/?include_text=1 This one is intended to obsolete RFC2309, and is mostly RFC2309 with the old stuff ripped out, and not a lot of new added. YET! Please join the AQM list to discuss what the new advice (AQM manifesto) should look like. Since multiple AQM algorithms can co-exist (e.g. CoDel & PIE), and multiple flow queuing algorithms, we expect that "one size fits all" is unlikely, but documenting them (so that purchasing RFP's can reference them) and explaining their best areas of use; best guess is we'll see a number of informational RFC's and BCP's result, though standards track for the algorithms are not out of the question. The research and development in this area is still very young. This is the beginning of a long road. As Matt Mathis put it in the ICCRG meeting, the results (which you can see repeated in all the slide sets in the ICCRG meeting) are compelling, and it is important to start the deployment process without years of optimization: seldom do you see orders of magnitude improvement shown as everyone did at the meeting. I would like to thank all of you (and Dave Taht, Kathy Nichols and Van Jacobson in particular) for helping us to get to this point. I started as a lone voice in the wilderness and felt very alone. With all your help and support there is now a growing chorus and we have billions of devices to deploy to, and many problems yet to solve. Again, thanks to all. Jim --089e015386d8a19df404d82319c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The ICCRG meeting at last week's IETF went = very well, as did a variety of live demos of fq_codel.
=
You can find the ICCRG slide sets here:
https://= datatracker.ietf.org/meeting/86/materials.html
=A0
=A0and, though the sessions were= not video'ed by the IETF, Dave and I used our phones and may put some = low quality video up later.


https://plus.google.com/u/0/107942175615993706558/posts/= A1seNKANmDg

My great thanks to Dave Taht and Comcast to pull off a live demo o= f bufferbloat helping drive bufferbloat's reality home to people. =A0Su= ch live demos are always a huge amount of work.

The tsvarea meeting resulted in consensus to work toward establishing = a working group and updated set of best practices and RFCs regarding AQM re= commendations. First up was establishing a new mailing list for "aqm&q= uot;, which can be joined here:

https://www.= ietf.org/mailman/listinfo/aqm
=A0


Now is the = time to see how standards sausage is made!

Some advise was published= in the ICCRG meeting about how to proceed further:

http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-4.pdf=A0

Those of you familiar with RFC 2309 may know that it was informa= lly called the "RED manifesto", and aware that RED's shortcom= ings doomed it. But such a document (as a public statement of the IETF that= this problem must be urgently solved).

Fred Baker (who was IETF chair recently) just issued an init= ial internet draft:

http://datatracke= r.ietf.org/doc/draft-baker-aqm-recommendation/?include_text=3D1
=A0

This one is intended to obsolete RFC2309, an= d is mostly RFC2309 with the old stuff ripped out, and not a lot of new add= ed. YET! Please join the AQM list to discuss what the new advice (AQM manif= esto) should look like.

Since multiple AQM algorithms can co-= exist (e.g. CoDel & PIE), and multiple flow queuing algorithms, we expe= ct that "one size fits all" is unlikely, but documenting them (so= that purchasing RFP's can reference them) and explaining their best ar= eas of use; best guess is we'll see a number of informational RFC's= and BCP's result, though standards track for the algorithms are not ou= t of the question.

The research and development in this area i= s still very young. =A0This is the beginning of a long road. As Matt Mathis= put it in the ICCRG meeting, the results (which you can see repeated in al= l the slide sets in the ICCRG meeting) are compelling, and it is important = to start the deployment process without years of optimization: seldom do yo= u see orders of magnitude improvement shown as everyone did at the meeting.=

I would like to thank all of you (and= Dave Taht, Kathy Nichols and Van Jacobson in particular) for helping us to= get to this point. =A0I started as a lone voice in the wilderness and felt= very alone. =A0

With all your help and support there is now= a growing chorus and we have billions of devices to deploy to, and many pr= oblems yet to solve.

Again, thanks to = all.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Jim



=
--089e015386d8a19df404d82319c8--