From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4A795200AE8 for ; Thu, 22 Sep 2011 13:44:16 -0700 (PDT) Received: by iagv1 with SMTP id v1so5738871iag.16 for ; Thu, 22 Sep 2011 13:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4t10x9f3pABEegBCeUH4hsARtsFU6Ntgh8DAxVFL8Y4=; b=kAT8gZ61dcHw1wdYDJPh+31V4zioLaybypOay7gWyolFhWscERgF4d9WSITscjSBKu DGnGjoStbntI3j7DljkkASuXxRWVHi0IZsNN5Sl97MvX4CmWl/ZLWpiLZ9PIbBydZkHx 8/abdqACIqYbpPf0jkhOe+f+dZs7gInhOTgzk= MIME-Version: 1.0 Received: by 10.42.189.70 with SMTP id dd6mr2358175icb.9.1316724255293; Thu, 22 Sep 2011 13:44:15 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Thu, 22 Sep 2011 13:44:15 -0700 (PDT) Date: Thu, 22 Sep 2011 13:44:15 -0700 Message-ID: From: Dave Taht To: debloat-proposals@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Debloat-proposals] Initial SOW - feedback on other subprojects. X-BeenThere: debloat-proposals@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:44:16 -0000 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! --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com