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 <[email protected]> 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. > > I'm rather sorry I missed it! > > (portions of the iccrg were recorded, I don't know if there are > minutes available(?)) > > Anyway, tsvarea minutes are up: > > http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea > > the net result was the new aqm mailing list at the ietf, which has > started up rip-roaringly. > > http://www.ietf.org/mail-archive/web/aqm/current/maillist.html > > 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... > > > Extract from the tsvarea minutes: > > Discussion: > > 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 > > Wes - need aqm for ecn deployment > > 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 > > 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 > > 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 > > 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. > > 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 > > 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. > > 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 > > Wes - this is a variant of the problem of getting good IPv6 support in CPE > > Richard Scheffeneger channeling Mikael Abrahamsson - well-known > problem of bufferbloat - need an RFC similar to 6204 perhaps called > queue handling and > > Michael Welzl - iccrg can publish informational RFCs on AQM algorithms > - energy seems to be there on that topic > > 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. > > Toerless Eckert - you could leverage the ops area before coming up > with a WG in TSV > > Wes, continues presenting > > 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 > > Bob Briscoe - updates to ECN are in tsvwg, so this may be better there as well > > 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 > > Wes - we scheduled this meeting to get feedback - can we have a hum if > you think tsvarea should form a wg on this? > > loud hum > > Wes - sounds like we should look at forming a wg on this > > Dave - let's not waste time comparing new AQM algorithms to tail-drop. > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
