From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 1B5303CB35 for ; Wed, 18 Apr 2018 17:53:15 -0400 (EDT) Received: by mail-lf0-x22a.google.com with SMTP id m202-v6so4825063lfe.8 for ; Wed, 18 Apr 2018 14:53: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=P53xhSPENg4ai/rxU7aFpU7j4/ALWhO8EeXS6RBIo3s=; b=eBKzD624LWX58QNzpP6UBMKUAWVaSp1LlwE/Aa3BXuESb4s5p+LiYjGrrTx1NVdD68 YwPZpED7/gpJd3XguXirn7KR949pVS9GqxhFIpDRD5lOqac3fSdn1eFoGugPn45MPPfV 38TnZUX91yzLJNpWJjpV+fkivkxfAqs5awua4YP51Qv3qBE/TBBvkUyXMPVu0bysfdqY WGzVWyDDnezx8RpsToA/o6P/YI8OD+jEbAicdlrq+YMBeZNSc2N/w1tMY3fSQO8zi9p/ kIxr7uro4qTXLLL1w/thXfDIDKxbuSksTPUheJPO4bQHAcLz33iFp4wW5jJoJhImaUBX +97w== 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=P53xhSPENg4ai/rxU7aFpU7j4/ALWhO8EeXS6RBIo3s=; b=JjwQA61d4o4o1HmIv1LzV3PPo9dd9ARWKNeVbknZWbELW6UprcJiXm2zYbngsPm1Ez xQvzti/S7/od4WDbsyA2nbRm3A7gqBiHaNWthorcoHhMw3w4tq0vDCwNTlrOSKvXpqxE 5MUUGZwzgJTZ1U/lJJ84wouL2njoO/BxVXZwWukejETa5rSzateh0UK2PVx/BMlk7piv wOuPEZglwL+5WBY4303hesbE31LHBK7CdQRJxNl/vw+ByMT/fKTmJhdnQTs8V5OFp95U 2J1eEo6oTf0m0IUYtcvDLpeIYvsvnRgDPKNC8JXCQ8sxk9lPNQut+tFF19ifyU9/VW/2 FMVg== X-Gm-Message-State: ALQs6tCcnHD/J54DNBUpQIn6nKHL5Sza8ESb3CYJ+bA3SYTQuX4wrz0e 6reOZwA1m1uahCI01RfzBwk= X-Google-Smtp-Source: AIpwx49sZw6QRh6OmlgdENCsD77hNUu8pffV61PeudTl3CJiKVSUjjTdmrfOqB7PgbTyC/C1g/jOUw== X-Received: by 10.46.158.19 with SMTP id e19mr2564147ljk.47.1524088393919; Wed, 18 Apr 2018 14:53:13 -0700 (PDT) Received: from [192.168.239.216] (83-245-234-255-nat-p.elisa-mobile.fi. [83.245.234.255]) by smtp.gmail.com with ESMTPSA id h73-v6sm449490lfe.24.2018.04.18.14.53.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 14:53:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jonathan Morton In-Reply-To: Date: Thu, 19 Apr 2018 00:53:00 +0300 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <7EC1A95B-B398-451D-A234-E9C43DC34829@gmail.com> References: <87vacq419h.fsf@toke.dk> <874lk9533l.fsf@toke.dk> <87604o3get.fsf@toke.dk> <578552B2-5127-451A-AFE8-93AE9BB07368@gmail.com> <87r2nc1taq.fsf@toke.dk> <0BB8B1FD-6A00-49D6-806E-794BD53A449F@gmx.de> <3457DD8E-0292-4802-BD1E-B37771DCADA2@gmail.com> <87fu3s1om2.fsf@toke.dk> <5BD20E12-2408-4393-8560-3FDA52D86DB3@gmail.com> To: David Lang X-Mailer: Apple Mail (2.3445.6.18) Subject: Re: [Cake] A few puzzling Cake results 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, 18 Apr 2018 21:53:15 -0000 >> I'm saying that there's a tradeoff between intra-flow induced latency = and packet loss, and I've chosen 4 MTUs as the operating point. >=20 > Is there a reason for picking 4 MTUs vs 2 MTUs vs 2 packets, etc? To be more precise, I'm using a sojourn time equivalent to 4 MTU-sized = packets per bulk flow at line rate, as a modifier to existing AQM = behaviour. The worst case for packet loss within the AQM occurs when the inherent = latency of the links is very low but the available bandwidth per flow is = also low. This is easy to replicate using a test box flanked by GigE = links to endpoint hosts; GigE has sub-millisecond inherent delays. In = this case, the entire BDP of each flow exists within the queue. A general recommendation exists for TCP to use a minimum of 4 packets in = flight, in order to keep the ack-clock running smoothly in the face of = packet losses which might otherwise trigger an RTO (retransmit timeout). = This allows one packet to be lost and detected by the triple-repetition = ACK method, without SACK. It isn't necessary for these packets to all carry an MSS payload; = theoretically a TCP could reduce the payload per packet to maintain four = packets in flight with a congestion window below 4x MSS. I'm not aware = of any TCP which actually bothers to do that, though I might have missed = recent developments in Linux TCP. It's also possible for a TCP to pace its output so that fewer than 4 = packets are physically in flight at a time, but still functionally have = a congestion window that's significantly larger. BBR could be said to = fall into that category under some conditions. TSQ might also produce = this behaviour under some conditions. The vast majority of widely deployed TCPs, however, are unable to = operate efficiently at less than 4x MSS congestion windows. = Additionally, actual use of ECN remains deplorably low. That's the = reason for choosing 4 MTUs per bulk flow. Originally, Cake had a similar AQM tweak but imposing a flat minimum of = 1.5 MTUs, irrespective of flow count. This mechanism is what was = adapted into the present scheme. - Jonathan Morton