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