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

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

[Dave Taht]

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

Re: [Codel] [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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat