[Bloat] the iccrg presos and some meeting notes from tsvarea at ietf

[Michael Welzl]

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 <dave.taht at gmail.com> 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
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat