From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 352FE21F393 for ; Thu, 26 Feb 2015 13:50:30 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id i138so12296370oig.4 for ; Thu, 26 Feb 2015 13:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=u8D727PyjOuwjp9IUUb3HP+WFtNP5cySxGIUtgnYoL0=; b=b1nP+ECMZIJ5xGwNzNX2t2eyIAMRGgzA4JXioTOCQbyS0mwAyuDwlU7EeoY0nc8rV9 p2CWQbNsttMsMp59AbZLzgCkagVhubv8PyWbrtfcV3XQ13GKtSfVbosWlYdeCIH2euWD Gu3YX8dT0radclOcDlEnCNsEt4B50N85W43D48BRvR0jZH72VMj5hrmzrbG0YWBvirsq 60eUjspZPOuP3WjlpJ5ZEK7mLgf5xG9i0A6zBGBS83JbMMJSsg1EQBz8CjBBu8C6+jzJ OHM9SpBnrG/eX88T93POLaNs/ZO1fTJW5kw/1rEtWzxNTRcO0hZiKs8OvR+u5k/ji5Na u9/Q== MIME-Version: 1.0 X-Received: by 10.182.144.136 with SMTP id sm8mr7643316obb.63.1424987429714; Thu, 26 Feb 2015 13:50:29 -0800 (PST) Received: by 10.202.51.66 with HTTP; Thu, 26 Feb 2015 13:50:29 -0800 (PST) In-Reply-To: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> <4A80D1F9-F4A1-4D14-AC75-958C5A2E8168@gmx.de> <3F47B274-B0E4-44F2-A434-E3C9F7D5D041@ifi.uio.no> <87twyaffv3.fsf@toke.dk> <1D438EDC-358D-4DD5-9B8D-89182256F66C@gmx.de> <54EDD951.50904@orange.com> <54EE07C0.60703@orange.com> <54EF2877.8030302@orange.com> <54EF3932.6020007@orange.com> Date: Thu, 26 Feb 2015 13:50:29 -0800 Message-ID: From: Dave Taht To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 21:50:59 -0000 On Thu, Feb 26, 2015 at 10:59 AM, Mikael Abrahamsson wro= te: > On Thu, 26 Feb 2015, Dave Taht wrote: > >> First, everyone saying that fq_codel can't be done in hardware is *wrong= * >> See my last point far below, I know I write over-long emails... > > > What do you define as "hardware"? > >> YES, at the lowest level of the hardware, where packets turn into light = or >> fuzzy electrons, or need to be tied up in a an aggregate (as in cable) a= nd >> shipped onto the wire, you can't do it. BUT, as BQL has > > > I am talking about doing this in the NPUs that are available on the marke= t > today and in the future. > > We're talking about these kinds of devices: > > http://www.tilera.com/News/PressRelease/?ezchip=3D97 Wow. That is one impressive piece of hardware. > I'm afraid that your experience with CPU driven devices isn't a great mat= ch > here, and we're talking past each other. To a certain extent we were. Thank you for dropping the above link into the conversation. 1) I mostly care about fixing the end user devices. Which can easily have enough horsepower to cope with whatever cheap crap the ISP wants on their side. Sure, there are a lot of trendlines that are negative here, the world I wanted to live in had a standard for jack you plugged into a the wall, which you could then do anything you wanted with, from gear you could buy from any retailer. 2) I realize that you (at least) want to do the best job possible with the best gear available on the market, and I respectively submit that the best thing that you can do is to avoid vendor lock. 3) If that chipmaker is unable to run a simple benchmark of their shaper + qos system, vs the sqm-scripts with fq_codel, and not realize that that they could, indeed, do much better, I wouldn't do business with them. > I would love to be able to use my employers purchasing power to drive dem= and > on AQM, but I need to know what the requirements are, and that they're > feasable to do, preferrably with an engineering effort for the vendor in = the > range of few man years. I can't produce this document myself, I have alre= ady > tried pointing them in the direction of presentations etc, but I need "ha= rd" > documents, outlining exactly what they need to do. Sucks to be you. I am glad a few other people here care enough to help create the needed paperwork. As for me: I am *done* with doing big company's essential R&D for them for free. I spent my entire retirement savings on fixing bufferbloat in the first year alone, and have been living a hand to mouth existence ever since. I just went through a 4 month month period with no revenue at all. I live in a yurt, the cheapest housing I could find in california, just so I could maintain sufficient independence to kick the entire industry in the ass, and never have to filter a single word, or commit through, a patent attorney, ever again. Given that so much great stuff is now happening - I am thinking I can finally quit. Everybody gets it now, and I am really tired of it (and a lot of people are tired of me being such a nag about it!), and I want to go off and do something else - anything else! But it would have been nice somewhere along the way to have landed a position that kept a better roof over my head, and eliminated some of my stressors and uncertainty, and still let me keep kicking the industry in the ass on a regular basis. Maybe, I dunno, I will quit this and go for a PHD and get a chance to write a ton more stuff down, at least, and do something genuinely new... But - as much as I might want to quit - I can't quit yet. I have one *last* thing left on bufferbloat that I care about, and that is fixing wifi, for the 2.8+ billion current users and the billions of new devices left to come. While I am glad we have at least theoretically fixed the edge, wifi was the actual problem that I started with, and there had accumulated so many fundamental problems since I had last paid attention to it, that it has taken 2+ years since clearly identifying what the problems there were, to having come up with code-able fixes, to get ready to even start. There is still quite a bit of theory work left to be done to get it right, and a ton of rearchitectural work in the kernel and the device firmwares themselves left to do. Solving *wifi problems* is what has kept me awake at night - and despite stumping around the world for the last two years to try to raise sufficient awareness and funding to tackle the job, have still only raised 1/10th the funds I thought would be required to do it right. And I am going to go start doing it anyway, starting last week, with some of the fiercely talented volunteers we have here, pitching in to help - and some of the the few clued companies also pitching in - and we are going to get it done - and THEN I can quit this f-ing self-assigned job that I took on as a favor to jim and vint and esr, and go work on some VC's concept for the next pets.com and watch the money start rolling back into my 401k. If anyone here works at a company that cares that wifi gets genuinely better, for everybody, please contribute a resource, or ante up: https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb I know I am not the only person that cares deeply about wifi, but blows my mind how few seem to understand that it doesn't need to suck - given what we now understand about fixing bufferbloat. > Do we have this currently? In that case, whereto should I point them? Does the ID not help? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb