From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 72BFD3B25D for ; Wed, 4 May 2016 07:41:30 -0400 (EDT) Received: by mail-lf0-x233.google.com with SMTP id u64so56299804lff.3 for ; Wed, 04 May 2016 04:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NAE2Ib6GeAFeIzSWC8/y6bhl1729R44CHVFRPeW180I=; b=u/4az+neVhmUKgfduszhDbWG+PFXyUrG0gDpgebB8RmI2VR5A271fxLkc1AXQvOCia 8zVOJkE1iDjsZmnO7C4fpWb8FSqvXWIuzbImndLMahZH3NqajEK/zxAchDV3f2/cnlm3 W1PqKvDyGmW7TqXenAAmrWOM9moSMRtwe6Pz+G2ynJelNPbtazTj+1KqoW3voioyguiw 0nh6STtPISiag/t6nTkXXfYaOLkInFluKe01/mYWcQA/+/qUc/hmitdT7rbGnpUrpe27 kL+XaUpUvre6z06RVVFpPoSU+OwG+7/89Plt5ZTpPQK4DNhRmo7DAEh+sc7cexrKHX6B MK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NAE2Ib6GeAFeIzSWC8/y6bhl1729R44CHVFRPeW180I=; b=lnzQmfH9yAY5nxBaTfl2Ve3h70U2PJh2AkCflM1j5v4+HX7YJV2h70UoN/ULA9yfpO 8y2v2xQbZTRuCdY7mzle/4zbayk9W/EpviWDTrzoAShzjJcEflQXZ8FOj0/IvVo9Tg+7 LqHasla8wc21T18ayV5ZRPnnDjpnNCDJmWHasZDcvWRS66m9eoio+iGu3MVXhVvIhwDV jB6xn457qj4Sy0a9U1hCKXPIVtzC20PBxjG8CYRtuuAXnmHpzKi/f534jemy9lVbCJ09 At9yLj1br49Q7i/Y2ehEwG1mZ9o8y22DbZgoOah5pV1Sappj5NOmML+tCe61q12DmjQ5 MDOQ== X-Gm-Message-State: AOPr4FUTehqXbaUACzQXHPZzd/NpSB2Ej8QvxVAzXmOZHhdFb+nk40vWYWJBy9UvH/Pu9w== X-Received: by 10.25.136.132 with SMTP id k126mr3317602lfd.134.1462362089024; Wed, 04 May 2016 04:41:29 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-231-241.bb.dnainternet.fi. [37.33.231.241]) by smtp.gmail.com with ESMTPSA id rn10sm539584lbb.41.2016.05.04.04.41.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 04:41:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <5729C7A0.40600@darbyshire-bryant.me.uk> Date: Wed, 4 May 2016 14:41:26 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <0B1F2C22-6F2C-4C06-904D-88065399BDCB@gmail.com> References: <5729C7A0.40600@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] cake, codel5.h, ecn marking & dropping. Confused 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, 04 May 2016 11:41:30 -0000 > On 4 May, 2016, at 12:57, Kevin Darbyshire-Bryant = wrote: >=20 > In essence my (mis)understanding of this code is something like: We've > got here because we've been dropping and codel is telling is to = continue > to drop. With that decided we enter a do..while, the first thing to > happen is to ECN mark and let that marked packet escape to send the > signal. Otherwise we appear to iterate around the loop. So here's = the > nub of my question: the INET_ECN_set_ce is done on every iteration of > that loop...with its potential early escape..do we escape on every > iteration? Do we need to twiddle the ECN bits on every packet that > we're about to drop? And we seem to mark the packet on exit of the = loop > anyway. It=E2=80=99s rather oddly structured code, to be sure. The vital clue for you may be that you can only set CE on an IPv{4,6} = packet which already has something *other* than Not-ECT set; it=E2=80=99s = impossible for non-IP packets, and not ECN compliant for Not-ECT IP = packets. So INET_ECN_set_ce() returns true only when it succeeds. On a UDP flood stream, typically Not-ECT is set, so the early-out never = triggers. Instead Codel drops a packet, schedules the next drop, and = checks whether the next drop schedule has already been reached (which = can happen for high drop rates and/or slow transmission rates). It then attempts to set CE on the first packet transmitted after a drop = sequence, just in case it was a mixed ECT/Not-ECT stream; strenuous = efforts to get the congestion signal heard as early as possible. This = is more likely when flow isolation isn=E2=80=99t in use, or when it is = per-host instead of per-flow. That=E2=80=99s also why the first attempt = to set CE is within the drop loop. - Jonathan Morton