[Debloat-proposals] Initial SOW - feedback on other subprojects.

[Debloat-proposals] Initial SOW - feedback on other subprojects.

[Dave Taht]

I've taken some time to re-read the initial SOW and wanted to address
some issues in more detail. I'll break these comments into separate
mails for suitable discussion.

To start off: I was very pleased to see the SOW make clear, distinct
points throughout, that effectively captured and summarized many of
the points made in the initial 'Beating the bloat' document we
circulated in a far more business-like way than jg and I could
achieve.

That said, it also reflected one major flaw in that document, in that
it overfocused on the cerowrt test router project and not as much on
the 3 related, equally important projects. While these other projects
can and should be treated separately, the whole shmeer consists of a 4
legged stool that cannot stand without the other legs in place.

Those points were:

2) The Testbed Problem
3) The Test tools Problem
4) The data set problem

There is a fifth end goal not really broken out right in the original
document, of solving the bufferbloat/AQM problems, then writing code
for them, then testing them at scale, then getting them deployed, and
having gear that 'just works' across all the new demands being made
upon it (ipv6, media streaming, dnsec, etc, etc) for years, and years.

JG tells me he covered most of that front while I was lost in Philly
that morning, but I can't help but make the following points.

Without improvements in test tools, we cannot adequately diagnose the
problems we are facing.
Without better AQMs and buffer management we cannot fix the problems
we are facing.
Without a test platform (or several) we cannot produce reproducible
results with the problems we are facing, or the tests we are trying to
run, nor the fixes we are trying to put in place.
Without publishing the solutions derived we are kept prisoner by the
other non-solutions
Without testing at scale, and in multiple labs around the world, we
cannot determine the interoperability problems we face, nor problems
across the LFN.
Without collecting large, accurate amounts of data in a storable and
searchable manner, we cannot ensure that we've not screwed up
somewhere else.

I can go and elaborate on these points, but these general comments are
not really specific to that initial statement of work, (and my
assumption is that for clarity we need to break all these projects
apart, anyway)

Onwards!


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[Debloat-proposals] Status update on bufferbloat related matters(?)

[David Täht]

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

Hi ALL!

I've been terribly busy with the move to Paris, getting re-established, 
getting an apartment, and integrating myself with the congestion control 
researchers at the LINCs lab. The food and intellectual atmosphere are 
great!

Last week I gave a pretty good talk and demonstration of wireless 
bufferbloat via Cerowrt - there (see attached the result of the 
experiment the students performed with me - the bottleneck moved to 
their laptops!), and monday I'm repeating that talk/experiment at the 
University of Oslo...

as well as giving a far more commercially oriented  talk to the 
dsl-partners forum also held in Oslo, then going to linuxcon in Prague 
where John Linville is giving his presentation on bufferbloat... and 
after that I have nothing public scheduled until the talk in Britain in 
late January, so I hope to get some real work done.

1) If anybody else expresses interest in supporting the bufferbloat 
projects (people, hardware, and especially financially), where do I send 
them?

2) How goes the study proposal(s)? I am not capable of sustaining my own 
efforts much past january.

While I have hope of leveraging many EU resources at lincs, getting 
actually funded proposals past their processes is going to need a very 
long lead time, unless there is corporate support.

3) Any other news?

Misc updates:

The Lincs lab has access to and has offered resources for using the 
http://ict-openlab.eu/ which also has relationships with planetlab. I've 
acquired 1/2 a grad student to help.

I've made contact also with three prominent bittorrent researchers in 
Paris - it would be intriguing to take a TCP and LEDBAT simulation and 
feed it through a RED-light simulation!

Several people are using bloatlab #1 at isc now to test things like sack 
and ecn over the long haul, a dsack related bug has been fixed in 3.1, 
and work is ongoing to analyze/improve tcp sack behavior overall.

Did a bit of work on improving the babel protocol's behavior under 
wireless contention and analyzing it's metric...

Re: CeroWrt rc7:

There were enough bugs in the 3.0 release of Linux for me to not want to 
continue working on that.
kernel.org being down last month didn't help either. I've been working 
with various upstream developers to make sure the ipv6 and (nasty) ipsec 
bugs are fixed in 3.1 or 3.2 and plan to resume work after linuxcon. 
Whatever people want to add to/or take from my plate would be good to know

http://www.bufferbloat.net/projects/cerowrt/roadmap

As I've had to slip the dates a lot.

JG, Vint, etc, have an interview coming up in January CACM. Kathie 
Nichols and JG are also working on an article for the same issue

JG and I and others have been participating in the homenet working group 
discussions

Re: AQMs - I am working towards coming up with a viable API to the 
Minstrel algorithm. It's looking like major surgery to the network stack 
is going to be required that is very cross skill-set...



On 09/22/2011 10:44 PM, Dave Taht wrote:
> I've taken some time to re-read the initial SOW and wanted to address
> some issues in more detail. I'll break these comments into separate
> mails for suitable discussion.
>
> To start off: I was very pleased to see the SOW make clear, distinct
> points throughout, that effectively captured and summarized many of
> the points made in the initial 'Beating the bloat' document we
> circulated in a far more business-like way than jg and I could
> achieve.
>
> That said, it also reflected one major flaw in that document, in that
> it overfocused on the cerowrt test router project and not as much on
> the 3 related, equally important projects. While these other projects
> can and should be treated separately, the whole shmeer consists of a 4
> legged stool that cannot stand without the other legs in place.
>
> Those points were:
>
> 2) The Testbed Problem
> 3) The Test tools Problem
> 4) The data set problem
>
> There is a fifth end goal not really broken out right in the original
> document, of solving the bufferbloat/AQM problems, then writing code
> for them, then testing them at scale, then getting them deployed, and
> having gear that 'just works' across all the new demands being made
> upon it (ipv6, media streaming, dnsec, etc, etc) for years, and years.
>
> JG tells me he covered most of that front while I was lost in Philly
> that morning, but I can't help but make the following points.
>
> Without improvements in test tools, we cannot adequately diagnose the
> problems we are facing.
> Without better AQMs and buffer management we cannot fix the problems
> we are facing.
> Without a test platform (or several) we cannot produce reproducible
> results with the problems we are facing, or the tests we are trying to
> run, nor the fixes we are trying to put in place.
> Without publishing the solutions derived we are kept prisoner by the
> other non-solutions
> Without testing at scale, and in multiple labs around the world, we
> cannot determine the interoperability problems we face, nor problems
> across the LFN.
> Without collecting large, accurate amounts of data in a storable and
> searchable manner, we cannot ensure that we've not screwed up
> somewhere else.
>
> I can go and elaborate on these points, but these general comments are
> not really specific to that initial statement of work, (and my
> assumption is that for clarity we need to break all these projects
> apart, anyway)
>
> Onwards!
>
>


-- 
Dave Täht


[-- Attachment #2: reduced_bufferbloat_in_cerowrt.ps --]
[-- Type: application/postscript, Size: 25580 bytes --]

[-- Attachment #3: dave_taht.vcf --]
[-- Type: text/x-vcard, Size: 204 bytes --]

begin:vcard
fn;quoted-printable:Dave T=C3=A4ht
n;quoted-printable:T=C3=A4ht;Dave
email;internet:dave.taht@gmail.com
tel;home:1-239-829-5608
tel;cell:0638645374
x-mozilla-html:FALSE
version:2.1
end:vcard