From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C541421F0BD; Sun, 24 Mar 2013 10:33:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UJonG-0008Ak-Lq; Sun, 24 Mar 2013 18:33:18 +0100 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.100]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UJonG-0006B5-09; Sun, 24 Mar 2013 18:33:18 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: Date: Sun, 24 Mar 2013 18:33:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 3055 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A4C61C3AF56CC85B56CD14E0435803785266CF54 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 307 max/h 8 blacklist 0 greylist 0 ratelimit 0 X-Mailman-Approved-At: Sun, 24 Mar 2013 12:03:31 -0700 Cc: codel@lists.bufferbloat.net, bloat Subject: Re: [Codel] [Bloat] the iccrg presos and some meeting notes from tsvarea at ietf X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 17:33:23 -0000 Hi Dave, all, ICCRG minutes are not yet available, but will be, as always, by the = deadline announced under "important dates": = http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 In general, for slides, minutes, meeting agendas, just go to = http://www.ietf.org, look for the meeting you're interested in, and = click on links with names such as "proceedings" or "meeting material". e.g., the proceedings from the Orlando meeting are here: https://datatracker.ietf.org/meeting/86/materials.html For any material from previous meetings, follow the "Proceedings" link = from the main ietf page: http://www.ietf.org/meeting/proceedings.html It's all there. Cheers, Michael On Mar 24, 2013, at 3:22 PM, Dave Taht wrote: > I had been wiped out by prepping for the previous days' iccrg meeting > and overslept and didn't make the tsvarea meeting the next morning. >=20 > I'm rather sorry I missed it! >=20 > (portions of the iccrg were recorded, I don't know if there are > minutes available(?)) >=20 > Anyway, tsvarea minutes are up: >=20 > http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea >=20 > the net result was the new aqm mailing list at the ietf, which has > started up rip-roaringly. >=20 > http://www.ietf.org/mail-archive/web/aqm/current/maillist.html >=20 > I'm not sure if anyone is taking on "drop tail considered harmful" as > a BCP (?), there has been plenty of discussion of ECN over there... >=20 >=20 > Extract from the tsvarea minutes: >=20 > Discussion: >=20 > Jim Gettys - data shows it isn't just an AQM problem - the flow queing > is equally or more important - two together are dynamite - we don't > have a common term, but would say that bloated buffers must die - how > do we get queuing and signalling at the edge of the network sane >=20 > Wes - need aqm for ecn deployment >=20 > Matt Mathis - extremely important these algorithms are documented, but > don't need to be standardised - shepherd informational RFCs - strongly > encourage lightweight informational process, not standards process at > all >=20 > Tim Shepherd - important to realise that things like AQM and ECN are > things that need to happen wherever the queue may be in any kind of > networking equipment - not just TSV - as Internet gets layered on top > of other technologies those other techs need things like ECN to manage > their queues in boxes that aren't even IP routers, so I think we need > to take message that this isn't just an Internet thing >=20 > Lars Eggert - we need a drop-tail considered harmful BCP - should come > out of IETF process and have an RFC number for procurement - why TSV, > because this is where we've started seeing the effect >=20 > Andrew McGregor - queues can exist above the socket as well, partly > application consideration, also partly transport. while individual aqm > algorithms may be documented there does need to be standard on what > signals between various layers are, especially as some are implicit. > there is space for some standards that don't currently exist. >=20 > Gorry Fairhurst - disagree with Tim, agree with Lars - this is > entirely a transport problem - transport is responsible for finding a > path that works. publishing informational documents could help >=20 > Wes George - important for there to be some recommendations in this > space - tail-drop considered harmful would be a good first step. real > lack of direction on what is right choice - awful lot of AQM options - > operators are faced with wide variety of choices, not clear from > existing documentation how i should arrive at a decision for my > network, tuninng recommendations etc. >=20 > Jim Gettys - upstream OS that goes into CPE is the key - CPE vendors > are shipping firmware based on minimum 5-yr old OS implementations > that are misconfigured >=20 > Wes - this is a variant of the problem of getting good IPv6 support in = CPE >=20 > Richard Scheffeneger channeling Mikael Abrahamsson - well-known > problem of bufferbloat - need an RFC similar to 6204 perhaps called > queue handling and >=20 > Michael Welzl - iccrg can publish informational RFCs on AQM algorithms > - energy seems to be there on that topic >=20 > Janardhan Iyengar - very important to understand where boundaries of > these mechanisms lie. be clear about where AQM mechanisms work well, > and where they don't. second point is about deployment - i agree with > idea that we see effects in transport, but deployment needs to happen > below transport - how to incentivise deployment. connect tcp to ip > metrics to help incentivise deployment. >=20 > Toerless Eckert - you could leverage the ops area before coming up > with a WG in TSV >=20 > Wes, continues presenting >=20 > Dave Oran - comment on configuring legacy AQM - there is a > fundamentally random relationship between how RED is configured and > what it does - if we go down this path we have to do hard work of > producing datasets of whether settings actually produce expected > results - otherwise recommendations will be meaningless >=20 > Bob Briscoe - updates to ECN are in tsvwg, so this may be better there = as well >=20 > Lars Eggert - would like fifo considered harmful as first item, doing > in ietf (rather than irtf) can help flush out IPR - important for wide > implementation >=20 > Wes - we scheduled this meeting to get feedback - can we have a hum if > you think tsvarea should form a wg on this? >=20 > loud hum >=20 > Wes - sounds like we should look at forming a wg on this >=20 > Dave - let's not waste time comparing new AQM algorithms to tail-drop. >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat