From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 63E213B29F for ; Wed, 28 Sep 2016 19:26:13 -0400 (EDT) Received: by mail-qt0-x231.google.com with SMTP id 38so29897170qte.1 for ; Wed, 28 Sep 2016 16:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F0l1HH332Ej76s+uDva7kheG/d9EdPdQFjCPzTt5IUc=; b=o7WoPLoNlpPGH8mbtw4GJ4MZXFH7YolucUxjlSRc43dK8xhl3Llqx/zkcH6NkURpTk a0QRGasNGoxRTmed6FPakjcZBA7NBwpoRiSaMNp+u04ZFDbR/j7jikcT/YffaX35Kc5X HogbpilnSZJjSTCh1R/2+cdQ4FjG46lxWr+ogl3YT9cfaMPHkLbDtYFFOBn6RwQLGukZ aaZ16bSXew12ZLgHDCLICYBxWbNHF7ODEHgzd5urKFA03gFIqvrXDjPziPGv2PxlIrBt xsBeYhtTM1MuCmxaxXxvUncRFgm0yH8qILOsqidj9NUu+XBuUh4eHgGaAEsMsQDq24Gv mbPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F0l1HH332Ej76s+uDva7kheG/d9EdPdQFjCPzTt5IUc=; b=mMMnyQ46Lv73KsEoRaNCpGMTXHZ2UZmREyw51zrc8u6kzumJDUNV0CQzfmluxhteyn M8itIsrVPs4sEh5bpSYGaROHr8O3PVXvDlms0g21t6KkxFrD4lEjQA6uOBOHfwGz0lRd lsPX8pWX+0u46qSqz7MYhBcFhB8uUzCwiIMHwzCE8DjUckbQV+z/61VwHIhS7F1eJS9Y 4/B4frvSRDGXft6v600yGma3O4tvSJe6Ii8HkcU/vyfuCYfKJcX+aPzb64yxWwlnWx1e ft1ewQQrGguF+cymWL1Jl7V7QvABbvZYObrOQJBoHdzsHVz1z6+k3L18JtJPW21ixqz0 KsEA== X-Gm-Message-State: AA6/9RnxMhmFgj1EqnSlRIAArK+n3H7NqQ9NDlR1x7qzpEkPGZp5hMOVIEUoDdynr0UySinLqQEq5AqDnq/lFQ== X-Received: by 10.200.52.124 with SMTP id v57mr35045493qtb.137.1475105172961; Wed, 28 Sep 2016 16:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Wed, 28 Sep 2016 16:26:12 -0700 (PDT) In-Reply-To: <27B5A7E3-203D-468F-B487-BFFC9294D857@gmail.com> References: <32E6B0A0-6014-4510-9D97-02645F0EFDFD@gmail.com> <27B5A7E3-203D-468F-B487-BFFC9294D857@gmail.com> From: Dave Taht Date: Wed, 28 Sep 2016 16:26:12 -0700 Message-ID: To: Jonathan Morton Cc: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake for net-next 4.8 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 23:26:13 -0000 On Tue, Sep 27, 2016 at 11:56 AM, Jonathan Morton w= rote: > >> On 27 Sep, 2016, at 21:18, Dave Taht wrote: >> >>> On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton wrote: >>> >>>> On 25 Sep, 2016, at 21:30, Dave Taht wrote: >>>> >>>> Judging from me tearing apart how TCP BBR works (presently) with ecn, >>>> it looks like we need to add the equivalent to fq_codel ce_threshold >>>> behaviors as well. >>> >>> If I=E2=80=99m reading the legend correctly, you are setting ce_thresho= ld to 1ms to get the better-controlled result. But that effectively disabl= es the codel algorithm and turns it into a simple =E2=80=9Cmark all packets= over 1ms sojourn=E2=80=9D for ECN capable traffic, because it=E2=80=99s a = tighter limit than codel=E2=80=99s target. That=E2=80=99s too aggressive f= or non-BBR traffic. >> >> Yes it is. :) However the consensus appears to be that ECN should be >> an earlier signal than drop, and the work over on the tcp-prague list >> centers around repurposing ECT(1) as more like a DCTCP multi-bit >> signal. > > My interpretation of the consensus is more subtle: we need a signal earli= er than we currently do, and with a weaker meaning, but we still need the s= trong, later signal. > > I don=E2=80=99t think we should use CE for that; it has a long-establishe= d and widely-deployed meaning. We *can* use ECT(1), which is presently unu= sed in practice. I have been avoiding the tcp-prague, l4s, etc debates, for health reasons, and it's possible I've misunderstood something. All along I'd been assuming that a specialized TCP of some new flavor yet-to-be-agreed-upon would negotiate ECN and most/all its packets would be marked ECT(1), rather than ECT(0), and a new AQM would treat a flow like that differently, but still mark that flow with a CE that the endpoint would interpret differently. Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE? >> I'm really not sure if what I've seen with ce_threshold is the >> desired behavior, vs a vs BBR, thus far - but I'd like to see the >> option for it enter cake. > > Before I even consider doing that, could you add a comparable run with th= e current version of cake to that graph? COBALT is not quite identical to = Codel, and this looks like a case where one of the differences could be imp= ortant. > > - Jonathan Morton > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org