From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 810393B29E; Sat, 21 Jul 2018 16:24:14 -0400 (EDT) Received: by mail-lj1-x235.google.com with SMTP id l15-v6so13776105lji.6; Sat, 21 Jul 2018 13:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RBTIJStxbWxn/OWui7DT0w3XPUuupD1qYin1qmERgAM=; b=V2zspFjLJGXU/dbJVgNj51IE3tY0oAoccX8j9k6GjZ0TbjAh8dTD0CG5vU50IDTGtI Ok7PZ+g3UJRfFyvUZDy2SOAlZln9V1RB6TyRA+phhFXSyd5lCXJlhPWLseyQyfWf3J4k JABG7MVCCWTF8/jAtuOb2uVjHr3TXTsp9/89zE0vOHed1Z3LEiCnI3qPgZTf+INnBJWt tN5ZSUin/+BLbmPx2qxbwBwPFcpwngGJTJs3fxMnzbNOoCBearcqE/6s8/GIsY5nFVuN YwPTuZXWgEy6a7ACv8xSVXGYa2GD+LXXbxmplqpkmBMHx2Cz/ZIJWOMp+f6kuJr84DXb k3TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RBTIJStxbWxn/OWui7DT0w3XPUuupD1qYin1qmERgAM=; b=JfLnDbpa5BTfxFscvV8DAkc2DvaMl/nBkDNvmsQgY/DzLLJgOg5hLrHrLBQN3kzcN6 dpW3Wv0qh4Yt4eGegeLhbS/IQkKaOabDDtUfv45y1IHJPSP+xTahWCeDjpLo/9hFGV4S 5cr+dO5E9CAafq4D/euTg2OfxyRt6qnO4x0EQSh43biEuwGKMHOoPpujJKKMhZqqp1pP T0YyQipEpw1StdfoztoKz6qDAMO2nIxCjK4CTct7+GkfhpfywnFss4VFckwV6evs/rDk KbfCrM97zzkbtxGYSZamSRVlBu9MwI3+XHuf4Usqtl16srghbpkNzBMBVXdEeH9bNO5C ugzA== X-Gm-Message-State: AOUpUlF5QmDmAYjYDmePSas99n135oYhP8TJt/CbbwITQth69+M+9WHE VoAXqEnP4Y9gNspIBboHAJM= X-Google-Smtp-Source: AAOMgpewUHvk3T667q2DGUzco2QgJOAuMCkJfR2VzhJQIFXKz+3eZw24XyHBnk9mOpPNhZqVuxdLjA== X-Received: by 2002:a2e:291c:: with SMTP id u28-v6mr4721305lje.70.1532204653468; Sat, 21 Jul 2018 13:24:13 -0700 (PDT) Received: from [192.168.239.216] (83-245-233-124-nat-p.elisa-mobile.fi. [83.245.233.124]) by smtp.gmail.com with ESMTPSA id n19-v6sm983909lja.87.2018.07.21.13.24.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jul 2018 13:24:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Sat, 21 Jul 2018 23:24:11 +0300 Cc: George Amanakis , Cake List , cerowrt-devel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C129A60-21D3-4B78-A764-DC8E2CD7E4DF@gmail.com> <6839ba220fe4399eba3620620515fc1dd801a509.camel@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno 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: Sat, 21 Jul 2018 20:24:14 -0000 > On 21 Jul, 2018, at 11:01 pm, Dave Taht wrote: >=20 > The cmts buffer fills more rapidly, particularly in slow start, while > presenting packets to the inbound shaper at 100mbit. cake starts > signalling, late, trying to achieve but at that point the apparent > RTTs are still growing rapidly (because of the buffer building up in > the cmts inflicting that RTT), so as fast as we signal, we've got such > a big buffer built up in the CMTS that tcp only sees one signal per > RTT which is mismatched against what cake is trying to thwart. The > pathology persists. >=20 > the idea for bobbie was that the goal for codel is wrong for inbound > shaping, that instead of aiming for a rate, we needed to sum all the > overage over our rate and reduce that until it all drains from cmts > shaper. Another possibility, which I've previously mentioned but haven't got = around to implementing, is to give ECN more flexibility in signalling - = so that it can indicate impending congestion as well as actual = congestion. That is, as well as the present CE mark meaning "back off now", there = may be softer signals carried on the dual encodings of ECT, meaning = "ramp down now", "don't ramp up", and "ramp up only with caution". = These signals can be given without delay, according to instantaneous = conditions at the bottleneck, without needing to estimate path RTT. You = could think of it as a version of DCTCP that can actually be deployed in = the internet, because it doesn't destroy the existing meaning of CE. The main problem is with getting the endpoints (both receiver and = sender) to recognise these new signals and react appropriately to them. = Producing these signals at the AQM is relatively easy. I think I worked = out a way to do it with the two padding bytes that normally accompany = the Timestamp option in TCP - this requires replacing the Timestamp = option with one that has the same semantics, but also carries the extra = data about recent ECT marks, and doesn't require padding to be naturally = aligned in the packet. This would give a way to halt slow-start when it reaches roughly the = correct window size, instead of having it overshoot first. It would = also give a way to gently control the cwnd to the ideal value while in = steady-state, instead of oscillating around it. - Jonathan Morton