some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

ICCRG agenda, IETF #86
Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6


Rong Pan: "A follow up on the PIE queue management algorithm", 30 min

Toke Hoeiland-Joergensen: "The State of the Art in Bufferbloat Testing
and Reduction on Linux", 30 min

Matt Mathis: "Drawing the line between transport and network
requirements", 30 min



There is still room on the agenda for more talks if anyone would like
to present.


http://irtf.org/iccrg


http://www.ietf.org/proceedings/86/agenda/agenda-86-iccrg



For those that don't attend ietf meetings in person, there is usually live
audio and jabber chat hooked up into the presentations.

See y'all there, next month, in one form or another.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]

Re: [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 10:53 AM, Dave Taht wrote:
> 
> For those that don't attend ietf meetings in person, there is usually
> live audio and jabber chat hooked up into the presentations.
> 
> See y'all there, next month, in one form or another.
> 


In the TSVAREA meeting, we've also set aside some time to talk
about AQM and whether there's interest and energy to do some
more specific work on AQM algs in the IETF (e.g. like CoDel and
PIE):

https://datatracker.ietf.org/meeting/86/agenda/tsvarea

I'm working with Martin on some slides to seed the discussion,
but we hope that it's mostly the community that we hear from,
following up in the higher-bandwidth face-to-face time from
the thread we had on the tsv-area@ietf.org mailing list a few
months ago.


-- 
Wes Eddy
MTI Systems

Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]


A small suggestion.  Instead of working on *algorithms*, focus on getting something actually *deployed* to fix the very real issues that we have today (preserving the option to upgrade later if need be).
 
The folks who built the Internet (I was there, as you probably know) focused on making stuff that worked and interoperated, not publishing papers or RFCs.
 
-----Original Message-----
From: "Wesley Eddy" <wes@mti-systems.com>
Sent: Thursday, February 28, 2013 1:11pm
To: "Dave Taht" <dave.taht@gmail.com>
Cc: bloat-announce@lists.bufferbloat.net, "Martin Stiemerling" <Martin.Stiemerling@neclab.eu>, cerowrt-devel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6



On 2/28/2013 10:53 AM, Dave Taht wrote:
> 
> For those that don't attend ietf meetings in person, there is usually
> live audio and jabber chat hooked up into the presentations.
> 
> See y'all there, next month, in one form or another.
> 


In the TSVAREA meeting, we've also set aside some time to talk
about AQM and whether there's interest and energy to do some
more specific work on AQM algs in the IETF (e.g. like CoDel and
PIE):

https://datatracker.ietf.org/meeting/86/agenda/tsvarea

I'm working with Martin on some slides to seed the discussion,
but we hope that it's mostly the community that we hear from,
following up in the higher-bandwidth face-to-face time from
the thread we had on the tsv-area@ietf.org mailing list a few
months ago.


-- 
Wes Eddy
MTI Systems
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 2313 bytes --]

Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Matt Mathis]

Two of the tests in my model based metrics draft (for IPPM) are for
AQM (like) tests.   One we have pretty good theory for (preventing
standing queues in congestion avoidance) and the other we don't
(exiting from slowstart at a reasonable window).

See: draft-mathis-ippm-model-based-metrics-01.txt

My intent is that these tests will become part of a future IPPM
standard on what a network must do in order to support modern
applications at specific performance levels.     Although the draft
will not specify AQM algorithms at all, it will forbid some non-AQM
behaviors such as unreasonable standing queues.   To the extent that
it gets traction as a standard, it will strongly encourage deployment,
even if we are not totally convinced that our current AQM algorithms
are 100% correct.

However, It is not clear that we need to standardize AQM - It strikes
me as one area where we can permit pretty much unfettered diversity in
the operational Internet as long as it meets a pretty low  "it seems
to work" bar.

For this reason it is important to deploy your favorite algorithm(s)
ASAP, because they are all infinitely better than none, and future
improvements will be relatively minor by comparison.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.


On Thu, Feb 28, 2013 at 10:47 AM, <dpreed@reed.com> wrote:
>
> A small suggestion.  Instead of working on *algorithms*, focus on getting something actually *deployed* to fix the very real issues that we have today (preserving the option to upgrade later if need be).
>
>
>
> The folks who built the Internet (I was there, as you probably know) focused on making stuff that worked and interoperated, not publishing papers or RFCs.
>
>
>
> -----Original Message-----
> From: "Wesley Eddy" <wes@mti-systems.com>
> Sent: Thursday, February 28, 2013 1:11pm
> To: "Dave Taht" <dave.taht@gmail.com>
> Cc: bloat-announce@lists.bufferbloat.net, "Martin Stiemerling" <Martin.Stiemerling@neclab.eu>, cerowrt-devel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6
>
> On 2/28/2013 10:53 AM, Dave Taht wrote:
> >
> > For those that don't attend ietf meetings in person, there is usually
> > live audio and jabber chat hooked up into the presentations.
> >
> > See y'all there, next month, in one form or another.
> >
>
>
> In the TSVAREA meeting, we've also set aside some time to talk
> about AQM and whether there's interest and energy to do some
> more specific work on AQM algs in the IETF (e.g. like CoDel and
> PIE):
>
> https://datatracker.ietf.org/meeting/86/agenda/tsvarea
>
> I'm working with Martin on some slides to seed the discussion,
> but we hope that it's mostly the community that we hear from,
> following up in the higher-bandwidth face-to-face time from
> the thread we had on the tsv-area@ietf.org mailing list a few
> months ago.
>
>
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 2:55 PM, Matt Mathis wrote:
> Two of the tests in my model based metrics draft (for IPPM) are for
> AQM (like) tests.   One we have pretty good theory for (preventing
> standing queues in congestion avoidance) and the other we don't
> (exiting from slowstart at a reasonable window).
> 
> See: draft-mathis-ippm-model-based-metrics-01.txt
> 
> My intent is that these tests will become part of a future IPPM
> standard on what a network must do in order to support modern
> applications at specific performance levels.     Although the draft
> will not specify AQM algorithms at all, it will forbid some non-AQM
> behaviors such as unreasonable standing queues.   To the extent that
> it gets traction as a standard, it will strongly encourage deployment,
> even if we are not totally convinced that our current AQM algorithms
> are 100% correct.


I like the idea.


> However, It is not clear that we need to standardize AQM - It strikes
> me as one area where we can permit pretty much unfettered diversity in
> the operational Internet as long as it meets a pretty low  "it seems
> to work" bar.


Fully agreed!  Publishing specs is only useful to get some
known-good algorithm(s) that folks can safely implement
without thinking too hard, and also to burn off any possible
ambiguities in the descriptions of the algorithms, catch any
corner cases, etc.


> For this reason it is important to deploy your favorite algorithm(s)
> ASAP, because they are all infinitely better than none, and future
> improvements will be relatively minor by comparison.
> 


Agreed, with the caveat that not *all* conceivable algorithms
are good :).  One of the things I think might be useful rather
than (or in addition to) specifying algorithms, is specifying
test setups or metrics that allow any algorithm to be checked
for sanity, as a black box.

-- 
Wes Eddy
MTI Systems

Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]


+1
 
-----Original Message-----
From: "Wesley Eddy" <wes@mti-systems.com>
Sent: Friday, March 1, 2013 1:29pm
To: "Matt Mathis" <mattmathis@google.com>
Cc: dpreed@reed.com, bloat-announce@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6



On 2/28/2013 2:55 PM, Matt Mathis wrote:
> Two of the tests in my model based metrics draft (for IPPM) are for
> AQM (like) tests.   One we have pretty good theory for (preventing
> standing queues in congestion avoidance) and the other we don't
> (exiting from slowstart at a reasonable window).
> 
> See: draft-mathis-ippm-model-based-metrics-01.txt
> 
> My intent is that these tests will become part of a future IPPM
> standard on what a network must do in order to support modern
> applications at specific performance levels.     Although the draft
> will not specify AQM algorithms at all, it will forbid some non-AQM
> behaviors such as unreasonable standing queues.   To the extent that
> it gets traction as a standard, it will strongly encourage deployment,
> even if we are not totally convinced that our current AQM algorithms
> are 100% correct.


I like the idea.


> However, It is not clear that we need to standardize AQM - It strikes
> me as one area where we can permit pretty much unfettered diversity in
> the operational Internet as long as it meets a pretty low  "it seems
> to work" bar.


Fully agreed!  Publishing specs is only useful to get some
known-good algorithm(s) that folks can safely implement
without thinking too hard, and also to burn off any possible
ambiguities in the descriptions of the algorithms, catch any
corner cases, etc.


> For this reason it is important to deploy your favorite algorithm(s)
> ASAP, because they are all infinitely better than none, and future
> improvements will be relatively minor by comparison.
> 


Agreed, with the caveat that not *all* conceivable algorithms
are good :).  One of the things I think might be useful rather
than (or in addition to) specifying algorithms, is specifying
test setups or metrics that allow any algorithm to be checked
for sanity, as a black box.

-- 
Wes Eddy
MTI Systems

[-- Attachment #2: Type: text/html, Size: 2909 bytes --]