From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 C9C193B29F for ; Tue, 27 Sep 2016 14:18:23 -0400 (EDT) Received: by mail-qt0-x236.google.com with SMTP id 11so11377667qtc.0 for ; Tue, 27 Sep 2016 11:18:23 -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=cwKFoRyoXtYcWRRY8h57r3wRsc6+ui4Va7V84detB98=; b=rOg41Z0zpDrv7Nol9WiYnoqMbJaJqOLCYg07SYhm6ZWWjjlg04bVVGqEhref2z9KdE tTm5NUtA9kgkvJcnCLD9y/Yzbdy8ou6wY5Wujrzd+PMRc3DMLXNX+goTkvnNIz8jq+WS +E4rDEzwUDPt0pbjpiKTWTDM7qgeDtG5CxdHROI/ZWZywrO+vqJA2CRaU1hYYldjsd/2 3mjEGPy5tKCUNp/QG4GVeZrXvJPh015wARloiWuMslLey+EzYdSoh43M9nFg4OTS46Kv ZwOyWmFCTNUjYrV+vARUInOc4fkt5OAQW8x7yX6vceKlFDpbj4MRDbcQZfZyhrFk6b8F jbRw== 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=cwKFoRyoXtYcWRRY8h57r3wRsc6+ui4Va7V84detB98=; b=EKPCwZ1O8oP2B/BtNvlyrnSORub06mGyVkeHVFAhK2fawnJkLcf93RcGknJwM8y3hJ YoFLJWppTWYSD3Cbi+nuKZ7G8pMP3k2Nqi/TQyyRXcz4NgkVMb2HJiCtMLqIvcURoHs6 xdYO12iFMbNwrUoQcPYmslzVevRmsxuBaYoEXR6nLpo67Ov0G8zQdzgGr6fG6xhjUVgU i7a55ky87bfulkFKcO9XiE6NW94PVieUAztgb6wJUb0mwKxbM2wEyMEHKxSZ2+Cj3gbY 1npW+lgOJDRAuydm66CGVJ//lkO5b1LL1r7TzhUQDflhPze1Bd9jOzB9/MfAjrjomrmV TwHg== X-Gm-Message-State: AA6/9RkxU5F5dHojGYGW3263nMX/E7te+ZV2BACjRN4pYO+USBg3xCdzULl2gFlUNy23LDTduYssWGTylpQZCQ== X-Received: by 10.200.45.113 with SMTP id o46mr29428245qta.93.1475000303351; Tue, 27 Sep 2016 11:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.214 with HTTP; Tue, 27 Sep 2016 11:18:22 -0700 (PDT) In-Reply-To: <32E6B0A0-6014-4510-9D97-02645F0EFDFD@gmail.com> References: <32E6B0A0-6014-4510-9D97-02645F0EFDFD@gmail.com> From: Dave Taht Date: Tue, 27 Sep 2016 11:18:22 -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: Tue, 27 Sep 2016 18:18:23 -0000 On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton w= rote: > >> 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_threshold= to 1ms to get the better-controlled result. But that effectively disables= the codel algorithm and turns it into a simple =E2=80=9Cmark all packets o= ver 1ms sojourn=E2=80=9D for ECN capable traffic, because it=E2=80=99s a ti= ghter limit than codel=E2=80=99s target. That=E2=80=99s too aggressive for= 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. ce_threshold 1ms is more like signaling loudly - "this is a solid indicator of your real OWD" and "you should fiddle with your TCP's 'gain' to compensate for it" - and it's certainly a lot simpler than codel to do it this way. I haven't got around to fully evaluating a comparison between BBR with ce_threshold and a non-ecn enabled TCP vs codel, concurrently (or implementing different behaviors for ECT(1) in the TCP negotiation step) ... and... 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. Also, in doing in my network this way, it became apparent to me that - like several ecn encapsulation rfcs suggest - that when a packet is already marked CE, and we want to also mark it CE, that the rightest answer is to drop the packet - not giving pre-CE-marked flows a free ride. > In these cases, I think you have to relax and let the FQ action take care= of it. And yes, FQ handles it nicely. Got pics of that somewhere. I did do a test with ce_threshold + ecn + bbr, vs no ecn and cubic, with the usual lovely fq'd result. > - Jonathan Morton > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org