From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 981FC21F393 for ; Fri, 3 Apr 2015 05:03:45 -0700 (PDT) Received: by obvd1 with SMTP id d1so169150321obv.0 for ; Fri, 03 Apr 2015 05:03:44 -0700 (PDT) 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=5FCh3sU41QykbKRSVN3AEwqVVQYSwjO59MUrDgyZyxc=; b=gzA8mZZ/Q2XXlyjDn+C7R1MFDO9x54vica5cTBnn8pjBDtXh2BGERganaDAVFIiEL9 VcVAnK5KIUy8WQjsVf7F7uZYeVvrD4ypI8lgYKJ5mK5MEuAI/fOPE/hkF/I3ArZfrWPK vwYyv255Exfp5PP2lZzbXy5eI31nIQ5cpYglqbmpvUGv6Dzin2eDNYNH+mNuGfs6bl9r NdPOBpYFNvexVISZIJ1H1wIrKU4+qM+hDyKjweajt88d3gGBA0YjasxCFadZ+c80BgS3 jXmJgeOxexurhWiqAYATPr0TKNtt29zeKcsylUVAlqNFeJeS1qqpA7QXmGpRcfYyY9er o4sw== MIME-Version: 1.0 X-Received: by 10.60.77.38 with SMTP id p6mr2549137oew.75.1428062624240; Fri, 03 Apr 2015 05:03:44 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Fri, 3 Apr 2015 05:03:44 -0700 (PDT) In-Reply-To: References: <551E364D.3070006@superduper.net> Date: Fri, 3 Apr 2015 05:03:44 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Keith Winstein , bloat Subject: Re: [Bloat] Computer generated congestion control 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: Fri, 03 Apr 2015 12:04:13 -0000 Several items about remy: 1) The core flaw in the work was that they targeted really long RTTs (>100ms) where here we are working in a range of RTTs, mostly shorter. I would have been much happier had the work continued (has it?) to look at solving for all RTTs passing through the network. That said, solving for long RTTs is a hard problem with real world use cases. 2) There is this persistent opinion in academia, notably in the e2e folk, that > 100ms of delay is "ok". We *never* defined a limit to bufferbloat in the original definition of the word - because we did not know what a good limit was! Several otherwise good papers then go forth to define "bufferbloat" as RTTs greater than 200ms, and then through statistical legerdemain show that it doesn=C2=B4t exist (my favorite was the one that discarded half the data just to start with, then chopped off everything above the 95th percentile). I referenced one of those papers in my rant at sigcomm: http://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf ... where we in the aqm world have settled on about 20-30ms as the outer bound for induced delay, and fq world, 5ms for sparse flows. I wish we could come up with another word, or better define bufferbloat than we have, to have real numbers in it. Closest we have come is: https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-= traditional-aqm-is-not-enough/ 3) I for one welcome our new congestion algorithm producing computer overlords! The job is too hard for humans! I thought this work on remy was astoundingly promising and hope that work continues. In particular, *thinking* about congestion control as a meta problem was a breakthrough. If remy could produce results that achieved 5-25ms added latency e2e - or it got extended to managing the routers inbetween - I could quit this and go back to working on spacecraft. Many of the other products of this group of people are really amazing (mosh for one, the mahimahi and delayshell stuff also https://github.com/ravinet/mahimahi ) If you are not using mosh for all your day to day interactive traffic, particularly on wifi you are annoying yourself for no good reason. But try the mosh-multipath work if you want to get on the bleeding edge... (note on mahimahi delayshell - there was a bug in that in that it assumes an infinite queue. I am not sure to what extent that was used in the remy work. There are patches for adding codel to it in a branch that I had discussed with keith a while back, I hope that got merged. (I meant to do it myself, forgot to take the day out I needed) I would like it if those producing test tools took a hard look at leveraging mahimahi in particular (I am looking at you... facebook) ) https://github.com/ravinet/mahimahi 4) Another MIT paper that I really liked was one that specified a FPGA in every router - not that that idea was cost feasible today - but it set me to thinking about what problems in this space could be better solved in gates, rather than code, what could be considered as massively parallel, and so on. I initially thought they were crazy... but after thinking about it a while I worked out a set of cool things that could be one day reduced to chips and would like to work on them.... That is partially why I have been backing this kickstarter project https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hard= ware-for-networking as it gets the cost down to something a grad student could afford... but it seems likely that they won=C2=B4t raise another 25k in the next 6 days to produce their first batch of boards. Note: They added a "get one give one" program at my request.... Anybody got a spare 25k to subsidize a whole bunch of really cool boards that cut the cost on a FPGA based home router re-design from 7k to 700 dollars? anyone??? I can think of a dozen+ people with the chops, if not the money, to work on FPGA based stuff.