From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 7FF503B29D for ; Sun, 12 Apr 2020 07:02:42 -0400 (EDT) Received: by mail-lj1-x22f.google.com with SMTP id k21so6137422ljh.2 for ; Sun, 12 Apr 2020 04:02:42 -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=KjrqQX22CMmn1EmCYmV4qdyJZRR3hN0TW3C1UV+BST8=; b=lqQpBeLCTYQIvX1pE2ff9A9bNPoYTeBSEZfm1ZBqvzKm7CzW3OXGdhN4vTRjjeZ/yR vSReUIDkp4C+/Z3kbqydCvSaX8NJtOYOoESmI6G1Jy7Lm2hKPqAeVwcFME3JapWJWwNn 50e+LoGetKKL5wcDu0s5KXqIYZW1YKmatG24023LOfCenTvKPpSkpkj01V2QKmhXMx/C bbXkmg+InIydioitoW83x1OQahq2fYMXJ1aMImiASqG4r0n3O8L9RCI8M3+gxVCxEQkT a5Lj8UBjWnBlGpiJLHyN/d7IoowcY27ZshUC/JxH0WryiyHCbSvafrU5H+uRtmpoNPfi 4ycg== 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=KjrqQX22CMmn1EmCYmV4qdyJZRR3hN0TW3C1UV+BST8=; b=K7kRp8l18T8J1W2JG/pQgmhpgncz6SLsS9XxKfJOPgZGztQGYax1BTp7Oo+EhfUneQ PGXjOXH9wr3REA/+7kXh7QRJ09KGCbxYdsmW7KU/NfvowtztQVkN0lFly0SBeW//lr3g 7PLXlyO9ure0Oav7Nd0JqBxTUa30gwuHQbemf64QA+wuLKF6vkBO2ToN9yx/bEK/Uc45 RvU2weurB66dFnStpE4z53cdwHzh9YD80ktEC7qvnq2/21txmMxFiflJ/eoFY17VAOJi tcz9JiMvaA8Pf4lAilHgA4KP99y0EwlslzwYQtX+ZAXRX7qAlS76m0IiNc0EU8gWhmb4 QTwg== X-Gm-Message-State: AGi0PuZGckLtbRBePSOAVHHfzYGMprJMCVOdsYVDHukxJCTPMYqzKQlp DeunybLYRsnq4o9gM5Wf3zM= X-Google-Smtp-Source: APiQypKNAW1926cqNc+JXIzSwHNcVPZjTU59GaxTBh2dx5xCxH6p0sGTh4lC53FYa3+CApWUQSg40g== X-Received: by 2002:a2e:81c6:: with SMTP id s6mr3914988ljg.132.1586689361204; Sun, 12 Apr 2020 04:02:41 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-249-104-nat-p.elisa-mobile.fi. [83.245.249.104]) by smtp.gmail.com with ESMTPSA id z9sm7228896lfd.9.2020.04.12.04.02.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2020 04:02:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Sun, 12 Apr 2020 14:02:39 +0300 Cc: Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <43C11592-F4CF-484D-AFB7-037D1C961906@gmail.com> References: <7BD9FB5D-7577-477A-9FF0-7BF90043C27B@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] Thinking about ingress shaping & cake 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: Sun, 12 Apr 2020 11:02:42 -0000 > On 12 Apr, 2020, at 11:23 am, Kevin Darbyshire-Bryant = wrote: >=20 > I=E2=80=99m wondering what the relationship between actual incoming = rate vs shaped rate and latency peaks is? My brain can=E2=80=99t = compute that but I suspect is related to the rtt of the flow/s and hence = how quickly the signalling manages to control the incoming rate. There are two important cases to consider here: the slow-start and = congestion-avoidance phases of TCP. But in general, the bigger the = difference between the link rate and Cake's shaped rate, the less = latency peaks you will notice. Slow-start basically doubles the send rate every RTT until terminated by = a congestion signal. It's therefore likely that you'll get a full RTT = of queued data at the moment of slow-start exit, which then has to drain = - and most of this will occur in the dumb FIFO upstream of you. Typical = Internet RTTs are about 80ms. You should expect a slow-start related = latency spike every time you start a bulk flow, although some of them = will be avoided by the HyStart algorithm, which uses increases in = latency as a congestion signal specifically for governing slow-start = exit. In congestion avoidance, TCP typically adds one segment to the = congestion window per RTT. If you assume the shaper is saturated, you = can calculate the excess bandwidth caused by this "Reno linear growth" = as 8 bits per byte * 1500 bytes * flow count / RTT seconds. For a = single flow at 80ms, that's 150 Kbps. At 20ms it would be 600 Kbps. If = that number totals less than the margin you've left, then the peaks of = the AIMD sawtooth should not collect in the dumb FIFO and will be = handled entirely by Cake. - Jonathan Morton=